ppl-0.10.2 check thorough test fail
Hello, With ppl-0.10.2, several Mac OS X fink users (including myself) have observed the following single test failure on 10.5 and 10.6, using Apple's gcc-4.2, arch i686-apple-darwin{9,10}, with thorough tests enabled:
/usr/bin/grep -E "^Optimum value: " ../../../demos/ppl_lpsol/expected_mpz
expected_optima && /usr/bin/grep -E "^Optimum value: " obtained obtained_optima && diff -u expected_optima obtained_optima
--- expected_optima 2011-03-22 21:05:58.000000000 -0400 +++ obtained_optima 2011-03-22 21:05:58.000000000 -0400 @@ -1,9 +1,10 @@ -Optimum value: -3 -Optimum value: 2 +Optimum value: -2 +Optimum value: 1 Optimum value: 24.33333333 Optimum value: 43 Optimum value: 3089 Optimum value: 5201 +Optimum value: -2 Optimum value: 0 Optimum value: 225494.9632 Optimum value: -464.7531429 @@ -15,8 +16,8 @@ Optimum value: -73.36896911 Optimum value: 149.5887662 Optimum value: 964.30053 -Optimum value: -3.75 -Optimum value: 2.5 +Optimum value: -2 +Optimum value: 1 Optimum value: -1749.90013 Optimum value: 0 Optimum value: 834.6823529 @@ -44,9 +45,10 @@ Optimum value: 0 Optimum value: -70 Optimum value: 0 +Optimum value: -2 Optimum value: 0 Optimum value: 3438.2921 -Optimum value: 2.5 +Optimum value: 1 Optimum value: 46.42857143 Optimum value: 0 Optimum value: 0 make[4]: *** [check-local] Error 1
Most fink users that reported this have built ppl against gmp-4.3.2. I tested a build against gmp-5.0.1 and got the exact same result on i686-apple-darwin10.
However, the same set of tests (check thorough) pass *cleanly* on powerpc-apple-darwin8 apple-gcc-4.0.1 (ppl-0.10.2 using gmp-4.3.2), which took over 4 days to run.
Has anyone else observed this failure on this version/configuration? How severe is this test failure?
(Unrelated note: ppl-0.11's tests run cleanly on i686-darwin10.)
Fang
David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/
On 03/29/11 02:39, David Fang wrote:
With ppl-0.10.2, several Mac OS X fink users (including myself) have observed the following single test failure on 10.5 and 10.6, using Apple's gcc-4.2, arch i686-apple-darwin{9,10}, with thorough tests enabled:
/usr/bin/grep -E "^Optimum value: " ../../../demos/ppl_lpsol/expected_mpz
expected_optima && /usr/bin/grep -E "^Optimum value: " obtained obtained_optima && diff -u expected_optima obtained_optima
--- expected_optima 2011-03-22 21:05:58.000000000 -0400 +++ obtained_optima 2011-03-22 21:05:58.000000000 -0400 @@ -1,9 +1,10 @@ -Optimum value: -3 -Optimum value: 2 +Optimum value: -2 +Optimum value: 1 Optimum value: 24.33333333 Optimum value: 43 Optimum value: 3089 Optimum value: 5201 +Optimum value: -2 Optimum value: 0 Optimum value: 225494.9632 Optimum value: -464.7531429 @@ -15,8 +16,8 @@ Optimum value: -73.36896911 Optimum value: 149.5887662 Optimum value: 964.30053 -Optimum value: -3.75 -Optimum value: 2.5 +Optimum value: -2 +Optimum value: 1 Optimum value: -1749.90013 Optimum value: 0 Optimum value: 834.6823529 @@ -44,9 +45,10 @@ Optimum value: 0 Optimum value: -70 Optimum value: 0 +Optimum value: -2 Optimum value: 0 Optimum value: 3438.2921 -Optimum value: 2.5 +Optimum value: 1 Optimum value: 46.42857143 Optimum value: 0 Optimum value: 0 make[4]: *** [check-local] Error 1
Most fink users that reported this have built ppl against gmp-4.3.2. I tested a build against gmp-5.0.1 and got the exact same result on i686-apple-darwin10.
However, the same set of tests (check thorough) pass *cleanly* on powerpc-apple-darwin8 apple-gcc-4.0.1 (ppl-0.10.2 using gmp-4.3.2), which took over 4 days to run.
Hi David,
yes, `make check' is heavy. However, our experience suggests no tests in the regression test suite is really redundant.
Has anyone else observed this failure on this version/configuration?
Not that I know, but it would be useful to know the compiler version used. In the (rather distant) past I remember some users had problems with some Apple-modified versions of GCC.
How severe is this test failure?
I would consider it severe, as it might indicate that the PPL has been miscompiled. This is my first suspect. Of course, we cannot exclude the cause is an architecture/compiler/platform-dependent bug in PPL 0.10.2 that went undetected up to now: perhaps `git bisect' could help locating it.
(Unrelated note: ppl-0.11's tests run cleanly on i686-darwin10.)
PPL 0.11.2 is the latest version of the PPL and the one we warmly recommend to anyone. If for some reason you cannot switch to PPL 0.11.2, please try compiling PPL 0.10.2 with a different compiler and see if the problem persists. If it does, we may investigate other possibilities. All the best,
Roberto
Hi, Adding fink-devel.
On 03/29/11 02:39, David Fang wrote:
With ppl-0.10.2, several Mac OS X fink users (including myself) have observed the following single test failure on 10.5 and 10.6, using Apple's gcc-4.2, arch i686-apple-darwin{9,10}, with thorough tests enabled:
/usr/bin/grep -E "^Optimum value: " ../../../demos/ppl_lpsol/expected_mpz
expected_optima && /usr/bin/grep -E "^Optimum value: " obtained obtained_optima && diff -u expected_optima obtained_optima
--- expected_optima 2011-03-22 21:05:58.000000000 -0400 +++ obtained_optima 2011-03-22 21:05:58.000000000 -0400
Most fink users that reported this have built ppl against gmp-4.3.2. I tested a build against gmp-5.0.1 and got the exact same result on i686-apple-darwin10.
However, the same set of tests (check thorough) pass *cleanly* on powerpc-apple-darwin8 apple-gcc-4.0.1 (ppl-0.10.2 using gmp-4.3.2), which took over 4 days to run.
yes, `make check' is heavy. However, our experience suggests no tests in the regression test suite is really redundant.
Has anyone else observed this failure on this version/configuration?
Not that I know, but it would be useful to know the compiler version used. In the (rather distant) past I remember some users had problems with some Apple-modified versions of GCC.
Compiler version: apple-gcc-4.2.1 configured for i686-apple-darwin10
An interesting data point we could use is powerpc-apple-darwin9-gcc-4.2.1, which uses the same version compiler, but different arch. (Any fink-10.5/ppc volunteers willing to donate some CPU cycles to test this? : "fink -m build ppl" )
How severe is this test failure?
I would consider it severe, as it might indicate that the PPL has been miscompiled. This is my first suspect. Of course, we cannot exclude the cause is an architecture/compiler/platform-dependent bug in PPL 0.10.2 that went undetected up to now: perhaps `git bisect' could help locating it.
It is posible this was never covered earlier, in my packaging, I had to apply a tiny patch to name an anonymous enum that prevented gcc-4.0.x from compiling one of the headers. At some point the documentation said gcc-4.0 was not supported, but my testing on powerpc-darwin8 was successful.)
(Unrelated note: ppl-0.11's tests run cleanly on i686-darwin10.)
PPL 0.11.2 is the latest version of the PPL and the one we warmly recommend to anyone. If for some reason you cannot switch to PPL 0.11.2, please try compiling PPL 0.10.2 with a different compiler and see if the problem persists. If it does, we may investigate other possibilities.
According to Jack Howarth (on this list, I believe), gcc-4.4 depends on ppl-0.10.x and is incompatible with ppl-0.11.x.
Thank you for the reply.
Fang
David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 3/29/11 3:44 PM, David Fang wrote:
Hi, Adding fink-devel.
On 03/29/11 02:39, David Fang wrote:
With ppl-0.10.2, several Mac OS X fink users (including myself) have observed the following single test failure on 10.5 and 10.6, using Apple's gcc-4.2, arch i686-apple-darwin{9,10}, with thorough tests enabled:
/usr/bin/grep -E "^Optimum value: " ../../../demos/ppl_lpsol/expected_mpz
expected_optima && /usr/bin/grep -E "^Optimum value: " obtained obtained_optima && diff -u expected_optima obtained_optima
--- expected_optima 2011-03-22 21:05:58.000000000 -0400 +++ obtained_optima 2011-03-22 21:05:58.000000000 -0400
Most fink users that reported this have built ppl against gmp-4.3.2. I tested a build against gmp-5.0.1 and got the exact same result on i686-apple-darwin10.
However, the same set of tests (check thorough) pass *cleanly* on powerpc-apple-darwin8 apple-gcc-4.0.1 (ppl-0.10.2 using gmp-4.3.2), which took over 4 days to run.
yes, `make check' is heavy. However, our experience suggests no tests in the regression test suite is really redundant.
Has anyone else observed this failure on this version/configuration?
Not that I know, but it would be useful to know the compiler version used. In the (rather distant) past I remember some users had problems with some Apple-modified versions of GCC.
Compiler version: apple-gcc-4.2.1 configured for i686-apple-darwin10
An interesting data point we could use is powerpc-apple-darwin9-gcc-4.2.1, which uses the same version compiler, but different arch. (Any fink-10.5/ppc volunteers willing to donate some CPU cycles to test this? : "fink -m build ppl" )
How severe is this test failure?
I would consider it severe, as it might indicate that the PPL has been miscompiled. This is my first suspect. Of course, we cannot exclude the cause is an architecture/compiler/platform-dependent bug in PPL 0.10.2 that went undetected up to now: perhaps `git bisect' could help locating it.
It is posible this was never covered earlier, in my packaging, I had to apply a tiny patch to name an anonymous enum that prevented gcc-4.0.x from compiling one of the headers. At some point the documentation said gcc-4.0 was not supported, but my testing on powerpc-darwin8 was successful.)
(Unrelated note: ppl-0.11's tests run cleanly on i686-darwin10.)
PPL 0.11.2 is the latest version of the PPL and the one we warmly recommend to anyone. If for some reason you cannot switch to PPL 0.11.2, please try compiling PPL 0.10.2 with a different compiler and see if the problem persists. If it does, we may investigate other possibilities.
According to Jack Howarth (on this list, I believe), gcc-4.4 depends on ppl-0.10.x and is incompatible with ppl-0.11.x.
Thank you for the reply.
Fang
David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/
I've uploaded a build log and build directory for a darwin10/powerpc build of ppl-0.10.2 using gcc-4.2 from Apple:
$ g++-4.2 --version powerpc-apple-darwin9-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5577)
The log and build directory are at:
http://akh.users.finkproject.org/finklogs/archives/2011-03.html#e2011-03-30T...
- -- Alexander Hansen, Ph.D. Fink User Liaison http://finkakh.wordpress.com/
Il 29/03/2011 02:39, David Fang ha scritto:
Hello, With ppl-0.10.2, several Mac OS X fink users (including myself) have observed the following single test failure on 10.5 and 10.6, using Apple's gcc-4.2, arch i686-apple-darwin{9,10}, with thorough tests enabled:
/usr/bin/grep -E "^Optimum value: " ../../../demos/ppl_lpsol/expected_mpz
expected_optima && /usr/bin/grep -E "^Optimum value: " obtained obtained_optima && diff -u expected_optima obtained_optima
--- expected_optima 2011-03-22 21:05:58.000000000 -0400 +++ obtained_optima 2011-03-22 21:05:58.000000000 -0400 @@ -1,9 +1,10 @@ -Optimum value: -3 -Optimum value: 2 +Optimum value: -2 +Optimum value: 1
I agree with Roberto that all of the symptoms suggest that Apple gcc-4.2 is miscompiling something (and we would really appreciate if someone can try out using a newer gcc).
The first differences above are related to a very simple MIP problem test. Can you please provide us with the output of the following command:
$ cd <PATH_TO_PPL_BUILD>/demos/ppl_lpsol $ ./ppl_lpsol -s -p1 -v 4 -c -M <PATH_TO_PPL_SRC>/demos/ppl_lpsol/examples/ex1.mps
This will also show the problem as read from the input, which should be something like: ============= Integer variables: x1 x2 Constraints: -2*x1 - x2 >= -5 4*x1 - 4*x2 >= -5 x1 >= 0 x2 >= 0 Objective function: x1 - 2*x2 Maximizing. ============= We would like to be sure that we are not stumbling on (a miscompilation causing) an input-parsing bug well before entering the optimization code.
Also note that the same command above can be used (in this specific case only!) as a quick replacement for the lengthy 'make check' for those building the ppl with a newer gcc. If the bug is still there, you will obtain something different wrt the following: ============= Optimum value: 2 Optimum location: x1 = 2 x2 = 0 =============
Thanks, Enea.
Il 29/03/2011 02:39, David Fang ha scritto:
Hello, With ppl-0.10.2, several Mac OS X fink users (including myself) have observed the following single test failure on 10.5 and 10.6, using Apple's gcc-4.2, arch i686-apple-darwin{9,10}, with thorough tests enabled:
/usr/bin/grep -E "^Optimum value: " ../../../demos/ppl_lpsol/expected_mpz
expected_optima && /usr/bin/grep -E "^Optimum value: " obtained obtained_optima && diff -u expected_optima obtained_optima
--- expected_optima 2011-03-22 21:05:58.000000000 -0400 +++ obtained_optima 2011-03-22 21:05:58.000000000 -0400 @@ -1,9 +1,10 @@ -Optimum value: -3 -Optimum value: 2 +Optimum value: -2 +Optimum value: 1
I agree with Roberto that all of the symptoms suggest that Apple gcc-4.2 is miscompiling something (and we would really appreciate if someone can try out using a newer gcc).
The first differences above are related to a very simple MIP problem test. Can you please provide us with the output of the following command:
$ cd <PATH_TO_PPL_BUILD>/demos/ppl_lpsol $ ./ppl_lpsol -s -p1 -v 4 -c -M <PATH_TO_PPL_SRC>/demos/ppl_lpsol/examples/ex1.mps
This will also show the problem as read from the input, which should be something like: ============= Integer variables: x1 x2 Constraints: -2*x1 - x2 >= -5 4*x1 - 4*x2 >= -5 x1 >= 0 x2 >= 0 Objective function: x1 - 2*x2 Maximizing. =============
Hi, On 10.6/i686, apple-gcc-4.2, gmp-5.0.1, I get:
fang@fangbook 4> ./ppl_lpsol -s -p1 -v 4 -c -M ../../../demos/ppl_lpsol/examples/ex1.mps Integer variables: x1 x2 Constraints: -2*x1 - x2 >= -5 4*x1 - 4*x2 >= -5 x1 >= 0 -x1 >= -1 x2 >= 0 -x2 >= -1 Objective function: x1 - 2*x2 Maximizing. Optimum value: 1 Optimum location: x1 = 1 x2 = 0
Different indeed! Does this indicate an earlier parse error?
Fang
We would like to be sure that we are not stumbling on (a miscompilation causing) an input-parsing bug well before entering the optimization code.
Also note that the same command above can be used (in this specific case only!) as a quick replacement for the lengthy 'make check' for those building the ppl with a newer gcc. If the bug is still there, you will obtain something different wrt the following: ============= Optimum value: 2 Optimum location: x1 = 2 x2 = 0 =============
Thanks, Enea.
Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/
Il 01/04/2011 18:45, David Fang ha scritto:
Il 29/03/2011 02:39, David Fang ha scritto:
Hello, With ppl-0.10.2, several Mac OS X fink users (including myself) have observed the following single test failure on 10.5 and 10.6, using Apple's gcc-4.2, arch i686-apple-darwin{9,10}, with thorough tests enabled:
/usr/bin/grep -E "^Optimum value: " ../../../demos/ppl_lpsol/expected_mpz
expected_optima && /usr/bin/grep -E "^Optimum value: " obtained obtained_optima && diff -u expected_optima obtained_optima
--- expected_optima 2011-03-22 21:05:58.000000000 -0400 +++ obtained_optima 2011-03-22 21:05:58.000000000 -0400 @@ -1,9 +1,10 @@ -Optimum value: -3 -Optimum value: 2 +Optimum value: -2 +Optimum value: 1
I agree with Roberto that all of the symptoms suggest that Apple gcc-4.2 is miscompiling something (and we would really appreciate if someone can try out using a newer gcc).
The first differences above are related to a very simple MIP problem test. Can you please provide us with the output of the following command:
$ cd <PATH_TO_PPL_BUILD>/demos/ppl_lpsol $ ./ppl_lpsol -s -p1 -v 4 -c -M <PATH_TO_PPL_SRC>/demos/ppl_lpsol/examples/ex1.mps
This will also show the problem as read from the input, which should be something like: ============= Integer variables: x1 x2 Constraints: -2*x1 - x2 >= -5 4*x1 - 4*x2 >= -5 x1 >= 0 x2 >= 0 Objective function: x1 - 2*x2 Maximizing. =============
Hi, On 10.6/i686, apple-gcc-4.2, gmp-5.0.1, I get:
fang@fangbook 4> ./ppl_lpsol -s -p1 -v 4 -c -M ../../../demos/ppl_lpsol/examples/ex1.mps Integer variables: x1 x2 Constraints: -2*x1 - x2 >= -5 4*x1 - 4*x2 >= -5 x1 >= 0 -x1 >= -1 x2 >= 0 -x2 >= -1 Objective function: x1 - 2*x2 Maximizing. Optimum value: 1 Optimum location: x1 = 1 x2 = 0
Different indeed! Does this indicate an earlier parse error?
Fang
Well ... ppl_lpsol uses glpk to parse the input file. Apparently, the installed glpk is parsing the input file differently. Which version of glpk do you have?
If I am to guess, I would say that the installed glpk is flagging the two variables as being *binary* variables, rather than *integer* ones. But this is just a guess, I will have to check the documentation for the input file format as well as the changelog for glpk.
Apart from this, ppl_lpsol seems to be correctly doing its job in optimizing the problem (and use of option -c seems to confirm that glpk is computing the very same optimal value).
Enea.
Hi,
I agree with Roberto that all of the symptoms suggest that Apple gcc-4.2 is miscompiling something (and we would really appreciate if someone can try out using a newer gcc).
The first differences above are related to a very simple MIP problem test. Can you please provide us with the output of the following command:
$ cd <PATH_TO_PPL_BUILD>/demos/ppl_lpsol $ ./ppl_lpsol -s -p1 -v 4 -c -M <PATH_TO_PPL_SRC>/demos/ppl_lpsol/examples/ex1.mps
This will also show the problem as read from the input, which should be something like: ============= Integer variables: x1 x2 Constraints: -2*x1 - x2 >= -5 4*x1 - 4*x2 >= -5 x1 >= 0 x2 >= 0 Objective function: x1 - 2*x2 Maximizing. =============
Hi, On 10.6/i686, apple-gcc-4.2, gmp-5.0.1, I get:
fang@fangbook 4> ./ppl_lpsol -s -p1 -v 4 -c -M ../../../demos/ppl_lpsol/examples/ex1.mps Integer variables: x1 x2 Constraints: -2*x1 - x2 >= -5 4*x1 - 4*x2 >= -5 x1 >= 0 -x1 >= -1 x2 >= 0 -x2 >= -1 Objective function: x1 - 2*x2 Maximizing. Optimum value: 1 Optimum location: x1 = 1 x2 = 0
Different indeed! Does this indicate an earlier parse error?
Fang
Well ... ppl_lpsol uses glpk to parse the input file. Apparently, the installed glpk is parsing the input file differently. Which version of glpk do you have?
If I am to guess, I would say that the installed glpk is flagging the two variables as being *binary* variables, rather than *integer* ones. But this is just a guess, I will have to check the documentation for the input file format as well as the changelog for glpk.
I have glpk-4.44:
fang@fangbook 6> fink list -t glpk Information about 10198 packages read in 9 seconds. i glpk 4.44-1 GNU Linear Programming Kit i glpk-dev 4.44-1 GNU Linear Programming Kit glpk-java 4.19-1 Java bindings for GLPK i glpk-shlibs 4.44-1 GNU Linear Programming Kit
Apart from this, ppl_lpsol seems to be correctly doing its job in optimizing the problem (and use of option -c seems to confirm that glpk is computing the very same optimal value).
Enea.
That's good to know that ppl is doing its part of the work 'correctly'. Anything else I can test for you?
Fang
David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/
Il 01/04/2011 19:46, David Fang ha scritto:
Hi,
[...]
Different indeed! Does this indicate an earlier parse error?
Fang
Well ... ppl_lpsol uses glpk to parse the input file. Apparently, the installed glpk is parsing the input file differently. Which version of glpk do you have?
If I am to guess, I would say that the installed glpk is flagging the two variables as being *binary* variables, rather than *integer* ones. But this is just a guess, I will have to check the documentation for the input file format as well as the changelog for glpk.
I have glpk-4.44:
So, my guess was correct and it turns out that Roberto had already asked about the problem on a glpk mailing list:
http://lists.gnu.org/archive/html/bug-glpk/2010-01/msg00005.html
Here is the answer
http://lists.gnu.org/archive/html/bug-glpk/2010-01/msg00006.html
saying that glpk 4.29 changed its mps file reading routines. I suspect there is a typo in the answer and maybe 4.39 or above was meant (because I have 4.38 installed and my variables are not detected as binary).
So, the good news is that the ppl is not miscompiled on your system. The bad news is that the output of ppl_lpsol now depends on glpk version.
Enea.
Well ... ppl_lpsol uses glpk to parse the input file. Apparently, the installed glpk is parsing the input file differently. Which version of glpk do you have?
If I am to guess, I would say that the installed glpk is flagging the two variables as being *binary* variables, rather than *integer* ones. But this is just a guess, I will have to check the documentation for the input file format as well as the changelog for glpk.
I have glpk-4.44:
So, my guess was correct and it turns out that Roberto had already asked about the problem on a glpk mailing list:
http://lists.gnu.org/archive/html/bug-glpk/2010-01/msg00005.html
Here is the answer
http://lists.gnu.org/archive/html/bug-glpk/2010-01/msg00006.html
saying that glpk 4.29 changed its mps file reading routines. I suspect there is a typo in the answer and maybe 4.39 or above was meant (because I have 4.38 installed and my variables are not detected as binary).
So, the good news is that the ppl is not miscompiled on your system. The bad news is that the output of ppl_lpsol now depends on glpk version.
Enea.
Thank you for helping to resolve this issue. I bet the reason I did not see this failure on powerpc-darwin8-gcc-4.0.1 was because I happened to test it against an older glpk (< 4.29) way back then. I can at least patch the test case to work with glpk >= 4.29 (and require said version in our TestDepends), and move on from there. Is this test also present in ppl-0.11.x? Will it require the same adjustment?
Fang
David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/
Il 01/04/2011 21:58, David Fang ha scritto:
Well ... ppl_lpsol uses glpk to parse the input file. Apparently, the installed glpk is parsing the input file differently. Which version of glpk do you have?
If I am to guess, I would say that the installed glpk is flagging the two variables as being *binary* variables, rather than *integer* ones. But this is just a guess, I will have to check the documentation for the input file format as well as the changelog for glpk.
I have glpk-4.44:
So, my guess was correct and it turns out that Roberto had already asked about the problem on a glpk mailing list:
http://lists.gnu.org/archive/html/bug-glpk/2010-01/msg00005.html
Here is the answer
http://lists.gnu.org/archive/html/bug-glpk/2010-01/msg00006.html
saying that glpk 4.29 changed its mps file reading routines. I suspect there is a typo in the answer and maybe 4.39 or above was meant (because I have 4.38 installed and my variables are not detected as binary).
So, the good news is that the ppl is not miscompiled on your system. The bad news is that the output of ppl_lpsol now depends on glpk version.
Enea.
Thank you for helping to resolve this issue. I bet the reason I did not see this failure on powerpc-darwin8-gcc-4.0.1 was because I happened to test it against an older glpk (< 4.29) way back then. I can at least patch the test case to work with glpk >= 4.29 (and require said version in our TestDepends), and move on from there. Is this test also present in ppl-0.11.x? Will it require the same adjustment?
The two tests (ex1.mps and unboundedmin.mps) were adapted by Roberto on January 2010, but that changes did not get into PPL 0.10.2. There relevant commits are:
http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=97ce932e01294...
http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=56ee86b9ccf00...
Hence, the output of PPL 0.11.x should be stable even when using the newer glpk versions.
Cheers, Enea.
Fang
David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/
On 04/02/11 08:29, Enea Zaffanella wrote:
Il 01/04/2011 21:58, David Fang ha scritto:
Thank you for helping to resolve this issue. I bet the reason I did not see this failure on powerpc-darwin8-gcc-4.0.1 was because I happened to test it against an older glpk (< 4.29) way back then. I can at least patch the test case to work with glpk>= 4.29 (and require said version in our TestDepends), and move on from there. Is this test also present in ppl-0.11.x? Will it require the same adjustment?
The two tests (ex1.mps and unboundedmin.mps) were adapted by Roberto on January 2010, but that changes did not get into PPL 0.10.2. There relevant commits are:
http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=97ce932e01294...
http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=56ee86b9ccf00...
Hence, the output of PPL 0.11.x should be stable even when using the newer glpk versions.
Thanks Enea: I had completely forgotten all that. Can you please add an item to http://www.cs.unipr.it/ppl/Bugs/archive?
I am glad to know that the code produced for PPL 0.10.2 is OK.
Said that, the following is a common misconception:
On 03/29/11 21:44, David Fang wrote:
According to Jack Howarth (on this list, I believe), gcc-4.4 depends on ppl-0.10.x and is incompatible with ppl-0.11.x.
Having studied the way PPL is used in GCC 4.4 I can tell you there is absolutely no incompatibility. In other words, if you just change the configuration stuff that insists in wanting PPL 0.10.2 so that PPL 0.11.* is also accepted, there is no way a GCC 4.4 user can complain. In summary, at this stage insisting on using PPL 0.10.2 is a mistake.
Thanks for your report, David. And thanks to Alexander for testing on the PowerPC. All the best,
Roberto
participants (4)
-
Alexander Hansen -
David Fang -
Enea Zaffanella -
Roberto Bagnara