Re: [PPL-devel] Fwd: ppl 0.11.2 vs llvm
Roberto, The complete set of failures reported for ppl-0.11.2 when built under Xcode 4.1's clang are...
Box --- affineimage1 frompolyhedron1 frompolyhedron2 propagateconstraints2 refinewithconstraint1 nnc_frompolyhedron1
BD_Shape -------- closure1
Again this appears to be an issue with the llvm backend as both llvm-gcc and clang exhibit these failures (and both use different llvm releases for their backends). I'll look into reproducing these failures under Linux. Jack
On 08/03/11 16:09, Jack Howarth wrote:
Roberto, The complete set of failures reported for ppl-0.11.2 when built under Xcode 4.1's clang are...
Box
affineimage1 frompolyhedron1 frompolyhedron2 propagateconstraints2 refinewithconstraint1 nnc_frompolyhedron1
BD_Shape
closure1
Again this appears to be an issue with the llvm backend as both llvm-gcc and clang exhibit these failures (and both use different llvm releases for their backends). I'll look into reproducing these failures under Linux. Jack
Hi Jack,
thanks for your report. I have just compiled the Git version of PPL (master branch) with clang, and fixed a few warning (all were innocuous).
I am now running `make check' under Linux, using a version of clang compiled with assertions (so compilation proceeds very slowly).
Enea Zaffanella, a fellow PPL developer, advanced the hypothesis that the warning
clang: warning: argument unused during compilation: '-frounding-math'
may be the cause of the problem. Indeed, the failures you observe are compatible with this hypothesis: can you please check whether the Box and BD_Shape failures occur for instantiations with floating point numbers? If really clang has no way to obtain the effect of `-frounding-math', then we have to detect clang in `configure' and disable all the floating-point instantiations. Thanks again,
Roberto
On 08/03/11 16:09, Jack Howarth wrote:
The complete set of failures reported for ppl-0.11.2 when built underXcode 4.1's clang are...
Box
affineimage1 frompolyhedron1 frompolyhedron2 propagateconstraints2 refinewithconstraint1 nnc_frompolyhedron1
BD_Shape
closure1
`make check' passed on directory BD_Shape for me (under GNU/Linux). I am now trying on Box.
On Thu, Aug 04, 2011 at 05:06:26AM +0200, Roberto Bagnara wrote:
On 08/03/11 16:09, Jack Howarth wrote:
The complete set of failures reported for ppl-0.11.2 when built underXcode 4.1's clang are...
Box
affineimage1 frompolyhedron1 frompolyhedron2 propagateconstraints2 refinewithconstraint1 nnc_frompolyhedron1
BD_Shape
closure1
`make check' passed on directory BD_Shape for me (under GNU/Linux). I am now trying on Box.
Roberto, Attached is a bzip2 compressed build log for ppl 0.11.2 against the clang/clang++ compilers from Xcode 4.1 with the failing make check. Let me know what additional information I can provide or if you have any test patches to try (under the assumption that this is fall-out from the absence of -frounding-math support in llvm-based compilers). Jack
-- Prof. Roberto Bagnara Applied Formal Methods Laboratory Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it _______________________________________________ PPL-devel mailing list PPL-devel@cs.unipr.it http://www.cs.unipr.it/mailman/listinfo/ppl-devel
Roberto, I am rather baffled that you can't reproduce this problem on Linux. Attached is a build and make check log from x86_64 Fedora 10 using the ppl 0.11.2 release and the binary distribution of the clang 2.9 compilers from http://llvm.org/releases/2.9/clang+llvm-2.9-x86_64-linux.tar.bz2. With CC set to clang and CXX set to clang++, I see the same failures as under the clang compilers from Xcode 4.1 under Lion. Jack
Il 06/08/2011 14:14, Jack Howarth ha scritto:
Roberto, I am rather baffled that you can't reproduce this problem on Linux. Attached is a build and make check log from x86_64 Fedora 10 using the ppl 0.11.2 release and the binary distribution of the clang 2.9 compilers from http://llvm.org/releases/2.9/clang+llvm-2.9-x86_64-linux.tar.bz2. With CC set to clang and CXX set to clang++, I see the same failures as under the clang compilers from Xcode 4.1 under Lion. Jack
Hello Jack.
I have downloaded the binaries above on my (Ubuntu) system and I managed to reproduce the first failure.
This is test08() in tests/Box/affineimage1.cc, compiled with -DBOX_INSTANCE=ld_r_oc (that is, using long doubles).
If you run the test as follows:
$ PPL_NOISY_TESTS=1 ./affineimage1
you will get some debugging output.
The relevant bits regarding test08() are the following: ======================================================================= === test08 === *** box *** A in [0, 1], B in [-1, 2] Containment does not hold: computed result is A in (-3689348814741910323/4611686018427387904, 3228180212899171533/2305843009213693952), B in [-1, 2] known result is A in [-4/5, 7/5], B in [-1, 2] Individual dimensions where containment does not hold (Variable: computed-result known-result): A: (-3689348814741910323/4611686018427387904, 3228180212899171533/2305843009213693952) [-4/5, 7/5] *** box.affine_image(A, -2*A - 3*B + 1, -5) *** A in (-0.79999999999999999995663191310057982263970188796520233154296875, 1.4000000000000000000867361737988403547205962240695953369140625), B in [-1, 2] =======================================================================
The relevant part here is the computed lower bound for space dimension named "A" (the first one), which should be lower than -0.8 (known result is -4/5) in order to be on the safe side: the computed value -0.79999...) was instead obtained by rounding towards the unsafe side, leading to the failure.
If compiled using gcc, the output is as follows: ======================================================================= === test08 === *** box *** A in [0, 1], B in [-1, 2] *** box.affine_image(A, -2*A - 3*B + 1, -5) *** A in (-0.8000000000000000000108420217248550443400745280086994171142578125, 1.4000000000000000000867361737988403547205962240695953369140625), B in [-1, 2] =======================================================================
So, my hypothesis seems to be correct: the cause is the missing support for -frounding-math in llvm/clang.
I will soon check some of the other failing tests and will report if I see anything new with respect to what said above.
Cheers, Enea.
Il 06/08/2011 15:35, Enea Zaffanella ha scritto:
Il 06/08/2011 14:14, Jack Howarth ha scritto:
Roberto, I am rather baffled that you can't reproduce this problem on Linux. Attached is a build and make check log from x86_64 Fedora 10 using the ppl 0.11.2 release and the binary distribution of the clang 2.9 compilers from http://llvm.org/releases/2.9/clang+llvm-2.9-x86_64-linux.tar.bz2. With CC set to clang and CXX set to clang++, I see the same failures as under the clang compilers from Xcode 4.1 under Lion. Jack
Hello Jack.
I have downloaded the binaries above on my (Ubuntu) system and I managed to reproduce the first failure.
I forgot to add that, in order to see the failure, the library should be configured with optimization turned on (the default). We usually turn them off when in debugging mode: this could maybe explain why Roberto was not seeing the failures.
Enea.
Jack --
On Sat, Aug 6, 2011 at 6:14 AM, Jack Howarth howarth@bromo.med.uc.edu wrote:
Attached is a build and make check log from x86_64 Fedora 10
Just by-the-by, Fedora 10 is ancient in Fedora terms. (Fedora 13 has already been "end of life"ed.)
http://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
http://fedoraproject.org/wiki/Releases/HistoricalSchedules#Fedora_10_.28Code...
It might be worth upgrading your system just to make sure it's not an outdated library that happens to be causing some of these problems. (Not that it's not still valuable information, but sometimes developers have to decide whether they spend time supporting old infrastructure vs. adding/improving features, and I know which I'd prefer...)
(Having said that, RHEL5 is probably about as modern as Fedora 10, and lots of people are still there, so compile issues on that platform are probably still relevant...)
Best regards, Tony
On Sun, Aug 07, 2011 at 12:44:56AM -0600, Anthony Foiani wrote:
Jack --
On Sat, Aug 6, 2011 at 6:14 AM, Jack Howarth howarth@bromo.med.uc.edu wrote:
Attached is a build and make check log from x86_64 Fedora 10
Just by-the-by, Fedora 10 is ancient in Fedora terms. (Fedora 13 has already been "end of life"ed.)
http://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
http://fedoraproject.org/wiki/Releases/HistoricalSchedules#Fedora_10_.28Code...
It might be worth upgrading your system just to make sure it's not an outdated library that happens to be causing some of these problems. (Not that it's not still valuable information, but sometimes developers have to decide whether they spend time supporting old infrastructure vs. adding/improving features, and I know which I'd prefer...)
(Having said that, RHEL5 is probably about as modern as Fedora 10, and lots of people are still there, so compile issues on that platform are probably still relevant...)
Best regards, Tony
Tony, The same exact failures are seen with the llvm based compilers under darwin10/11. This has nothing to do with the other devtools on the system but rather with the fact that llvm-based compilers currently don't support -frounding-math (which ppl assumes will be present in some form). Jack
PPL-devel mailing list PPL-devel@cs.unipr.it http://www.cs.unipr.it/mailman/listinfo/ppl-devel
On 08/06/11 14:14, Jack Howarth wrote:
I am rather baffled that you can't reproduce this problem on Linux.Attached is a build and make check log from x86_64 Fedora 10 using the ppl 0.11.2 release and the binary distribution of the clang 2.9 compilers fromhttp://llvm.org/releases/2.9/clang+llvm-2.9-x86_64-linux.tar.bz2. With CC set to clang and CXX set to clang++, I see the same failures as under the clang compilers from Xcode 4.1 under Lion.
Hi Jack,
please try configuring the PPL with --disable-fpmath on both platforms and let us know if `make check' passes this way. Cheers,
Roberto
On Sun, Aug 07, 2011 at 09:31:46AM +0200, Roberto Bagnara wrote:
On 08/06/11 14:14, Jack Howarth wrote:
I am rather baffled that you can't reproduce this problem on Linux.Attached is a build and make check log from x86_64 Fedora 10 using the ppl 0.11.2 release and the binary distribution of the clang 2.9 compilers fromhttp://llvm.org/releases/2.9/clang+llvm-2.9-x86_64-linux.tar.bz2. With CC set to clang and CXX set to clang++, I see the same failures as under the clang compilers from Xcode 4.1 under Lion.
Hi Jack,
please try configuring the PPL with --disable-fpmath on both platforms and let us know if `make check' passes this way. Cheers,
Roberto
Roberto, Building ppl9 with...
$ ../configure --prefix=/sw --mandir=/sw/share/man --infodir=/sw/share/info --disable-static --enable-pch --with-java=/System/Library/Frameworks/JavaVM.framework/Home CFLAGS=-g -O2 -pipe -fpch-preprocess -fPIC -fwrapv CXXFLAGS=-g -O2 -pipe -fpch-preprocess -fPIC -fwrapv CPPFLAGS=-I/System/Library/Frameworks/JavaVM.framework/Headers --enable-check=thorough --disable-fpmath -C
produces no testsuite failures when using clang3.0svn from Xcode 4.1. I'll repeat this with the stock llvm-gcc-4.2 system compilers from Xcode 4.1 as well. Jack ps Will --disable-fpmath introduce any problems for using the resulting ppl build with graphite in FSF gcc or cloog-ppl?
-- Prof. Roberto Bagnara Applied Formal Methods Laboratory Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it _______________________________________________ PPL-devel mailing list PPL-devel@cs.unipr.it http://www.cs.unipr.it/mailman/listinfo/ppl-devel
On 08/07/11 16:56, Jack Howarth wrote:
On Sun, Aug 07, 2011 at 09:31:46AM +0200, Roberto Bagnara wrote:
On 08/06/11 14:14, Jack Howarth wrote:
I am rather baffled that you can't reproduce this problem on Linux.Attached is a build and make check log from x86_64 Fedora 10 using the ppl 0.11.2 release and the binary distribution of the clang 2.9 compilers fromhttp://llvm.org/releases/2.9/clang+llvm-2.9-x86_64-linux.tar.bz2. With CC set to clang and CXX set to clang++, I see the same failures as under the clang compilers from Xcode 4.1 under Lion.
Hi Jack,
please try configuring the PPL with --disable-fpmath on both platforms and let us know if `make check' passes this way.
Building ppl9 with...$ ../configure --prefix=/sw --mandir=/sw/share/man --infodir=/sw/share/info --disable-static --enable-pch --with-java=/System/Library/Frameworks/JavaVM.framework/Home CFLAGS=-g -O2 -pipe -fpch-preprocess -fPIC -fwrapv CXXFLAGS=-g -O2 -pipe -fpch-preprocess -fPIC -fwrapv CPPFLAGS=-I/System/Library/Frameworks/JavaVM.framework/Headers --enable-check=thorough --disable-fpmath -C
produces no testsuite failures when using clang3.0svn from Xcode 4.1. I'll repeat this with the stock llvm-gcc-4.2 system compilers from Xcode 4.1 as well.
Great, thanks!
ps Will --disable-fpmath introduce any problems for using the resulting ppl build with graphite in FSF gcc or cloog-ppl?
Not that I know: neither GCC nor any cloog-ppl used any floating-point based approximation. And if they do you will have an error as soon as you try compiling them. So, no, I do not foresee any problems. Cheers,
Roberto
On Sun, Aug 07, 2011 at 05:23:15PM +0200, Roberto Bagnara wrote:
On 08/07/11 16:56, Jack Howarth wrote:
On Sun, Aug 07, 2011 at 09:31:46AM +0200, Roberto Bagnara wrote:
On 08/06/11 14:14, Jack Howarth wrote:
I am rather baffled that you can't reproduce this problem on Linux.Attached is a build and make check log from x86_64 Fedora 10 using the ppl 0.11.2 release and the binary distribution of the clang 2.9 compilers fromhttp://llvm.org/releases/2.9/clang+llvm-2.9-x86_64-linux.tar.bz2. With CC set to clang and CXX set to clang++, I see the same failures as under the clang compilers from Xcode 4.1 under Lion.
Hi Jack,
please try configuring the PPL with --disable-fpmath on both platforms and let us know if `make check' passes this way.
Building ppl9 with...$ ../configure --prefix=/sw --mandir=/sw/share/man --infodir=/sw/share/info --disable-static --enable-pch --with-java=/System/Library/Frameworks/JavaVM.framework/Home CFLAGS=-g -O2 -pipe -fpch-preprocess -fPIC -fwrapv CXXFLAGS=-g -O2 -pipe -fpch-preprocess -fPIC -fwrapv CPPFLAGS=-I/System/Library/Frameworks/JavaVM.framework/Headers --enable-check=thorough --disable-fpmath -C
produces no testsuite failures when using clang3.0svn from Xcode 4.1. I'll repeat this with the stock llvm-gcc-4.2 system compilers from Xcode 4.1 as well.
Great, thanks!
Roberto, The results for llvm-gcc-4.2 from Xcode 4.1 weren't as positive. The testcase...
/bin/sh: line 1: 91482 Segmentation fault: 11 ${dir}$tst FAIL: simplifyusingcontext1
segfaults with --disable-fpmath. I wouldn't worry too much about that as Apple is using a much older llvm release for llvm-gcc-4.2 than clang3.0svn in Xcode 4.1. Also, their usual response to llvm-gcc bugs is that it is being depreciated in favor of clang and to use that compiler instead. Is --disable-fpmath our only option here? I ask because only a small subset of testcases are failing and, from the response of the llvm/clang developers, it doesn't apear that -frounding-math support will be implemented in llvm/clang anytime soon. Jack
ps Will --disable-fpmath introduce any problems for using the resulting ppl build with graphite in FSF gcc or cloog-ppl?
Not that I know: neither GCC nor any cloog-ppl used any floating-point based approximation. And if they do you will have an error as soon as you try compiling them. So, no, I do not foresee any problems. Cheers,
Roberto
-- Prof. Roberto Bagnara Applied Formal Methods Laboratory Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it _______________________________________________ PPL-devel mailing list PPL-devel@cs.unipr.it http://www.cs.unipr.it/mailman/listinfo/ppl-devel
On 08/07/11 17:33, Jack Howarth wrote:
On Sun, Aug 07, 2011 at 05:23:15PM +0200, Roberto Bagnara wrote:
On 08/07/11 16:56, Jack Howarth wrote:
On Sun, Aug 07, 2011 at 09:31:46AM +0200, Roberto Bagnara wrote:
On 08/06/11 14:14, Jack Howarth wrote:
I am rather baffled that you can't reproduce this problem on Linux.Attached is a build and make check log from x86_64 Fedora 10 using the ppl 0.11.2 release and the binary distribution of the clang 2.9 compilers fromhttp://llvm.org/releases/2.9/clang+llvm-2.9-x86_64-linux.tar.bz2. With CC set to clang and CXX set to clang++, I see the same failures as under the clang compilers from Xcode 4.1 under Lion.
Hi Jack,
please try configuring the PPL with --disable-fpmath on both platforms and let us know if `make check' passes this way.
Building ppl9 with... $ ../configure --prefix=/sw --mandir=/sw/share/man --infodir=/sw/share/info --disable-static --enable-pch --with-java=/System/Library/Frameworks/JavaVM.framework/Home CFLAGS=-g -O2 -pipe -fpch-preprocess -fPIC -fwrapv CXXFLAGS=-g -O2 -pipe -fpch-preprocess -fPIC -fwrapv CPPFLAGS=-I/System/Library/Frameworks/JavaVM.framework/Headers --enable-check=thorough --disable-fpmath -Cproduces no testsuite failures when using clang3.0svn from Xcode 4.1. I'll repeat this with the stock llvm-gcc-4.2 system compilers from Xcode 4.1 as well.
Great, thanks!
Roberto, The results for llvm-gcc-4.2 from Xcode 4.1 weren't as positive. The testcase...
/bin/sh: line 1: 91482 Segmentation fault: 11 ${dir}$tst FAIL: simplifyusingcontext1
segfaults with --disable-fpmath. I wouldn't worry too much about that as Apple is using a much older llvm release for llvm-gcc-4.2 than clang3.0svn in Xcode 4.1. Also, their usual response to llvm-gcc bugs is that it is being depreciated in favor of clang and to use that compiler instead.
I am pretty confident this is a compiler bug.
Is --disable-fpmath our only option here?
The only other option I see is to debug the compiler bug. I guess it will not be an easy task though. Cheers,
Roberto
On Sun, Aug 07, 2011 at 05:41:28PM +0200, Roberto Bagnara wrote:
On 08/07/11 17:33, Jack Howarth wrote:
On Sun, Aug 07, 2011 at 05:23:15PM +0200, Roberto Bagnara wrote:
On 08/07/11 16:56, Jack Howarth wrote:
On Sun, Aug 07, 2011 at 09:31:46AM +0200, Roberto Bagnara wrote:
On 08/06/11 14:14, Jack Howarth wrote:
I am rather baffled that you can't reproduce this problem on Linux.Attached is a build and make check log from x86_64 Fedora 10 using the ppl 0.11.2 release and the binary distribution of the clang 2.9 compilers fromhttp://llvm.org/releases/2.9/clang+llvm-2.9-x86_64-linux.tar.bz2. With CC set to clang and CXX set to clang++, I see the same failures as under the clang compilers from Xcode 4.1 under Lion.
Hi Jack,
please try configuring the PPL with --disable-fpmath on both platforms and let us know if `make check' passes this way.
Building ppl9 with... $ ../configure --prefix=/sw --mandir=/sw/share/man --infodir=/sw/share/info --disable-static --enable-pch --with-java=/System/Library/Frameworks/JavaVM.framework/Home CFLAGS=-g -O2 -pipe -fpch-preprocess -fPIC -fwrapv CXXFLAGS=-g -O2 -pipe -fpch-preprocess -fPIC -fwrapv CPPFLAGS=-I/System/Library/Frameworks/JavaVM.framework/Headers --enable-check=thorough --disable-fpmath -Cproduces no testsuite failures when using clang3.0svn from Xcode 4.1. I'll repeat this with the stock llvm-gcc-4.2 system compilers from Xcode 4.1 as well.
Great, thanks!
Roberto, The results for llvm-gcc-4.2 from Xcode 4.1 weren't as positive. The testcase...
/bin/sh: line 1: 91482 Segmentation fault: 11 ${dir}$tst FAIL: simplifyusingcontext1
segfaults with --disable-fpmath. I wouldn't worry too much about that as Apple is using a much older llvm release for llvm-gcc-4.2 than clang3.0svn in Xcode 4.1. Also, their usual response to llvm-gcc bugs is that it is being depreciated in favor of clang and to use that compiler instead.
Roberto, I tried a build with dragonegg 3.0svn and FSF gcc 4.5.3 using --disable-fpmath. This combination builds ppl 0.11.2 without regressions in the testsuite. So the llvm-gcc-4.2 issue in Xcode 4.1 is likely a bug in their older llvm release used there and can be ignored since clang3.0svn in Xcode 4.1 works fine.
I am pretty confident this is a compiler bug.
Is --disable-fpmath our only option here?
The only other option I see is to debug the compiler bug.
You are talking about the failures seen without --disable-fpmath, correct? Is this really a compiler bug with clang? I thought it was due to the fact that ppl is coded to expect a functional -frounding-math option to be present. This isn't really a compiler bug but a compiler limitation, no? Jack
I guess it will not be an easy task though. Cheers,
Roberto
-- Prof. Roberto Bagnara Applied Formal Methods Laboratory Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it _______________________________________________ PPL-devel mailing list PPL-devel@cs.unipr.it http://www.cs.unipr.it/mailman/listinfo/ppl-devel
On 08/07/11 18:20, Jack Howarth wrote:
On Sun, Aug 07, 2011 at 05:41:28PM +0200, Roberto Bagnara wrote:
On 08/07/11 17:33, Jack Howarth wrote:
On Sun, Aug 07, 2011 at 05:23:15PM +0200, Roberto Bagnara wrote:
I am pretty confident this is a compiler bug.
Is --disable-fpmath our only option here?The only other option I see is to debug the compiler bug.
You are talking about the failures seen without --disable-fpmath, correct? Is this really a compiler bug with clang? I thought it was due to the fact that ppl is coded to expect a functional -frounding-math option to be present. This isn't really a compiler bug but a compiler limitation, no?
Perhaps I misinterpreted you. You wrote:
The results for llvm-gcc-4.2 from Xcode 4.1 weren't as positive. The testcase.../bin/sh: line 1: 91482 Segmentation fault: 11 ${dir}$tst FAIL: simplifyusingcontext1
segfaults with --disable-fpmath. I wouldn't worry too much about that as Apple is using a much older llvm release for llvm-gcc-4.2 than clang3.0svn in Xcode 4.1. Also, their usual response to llvm-gcc bugs is that it is being depreciated in favor of clang and to use that compiler instead.
I took that as "the PPL testsuite segfaults with some old compiler version (and only that one) even when configure with --disable-fpmath". My guess is that that old compiler version is miscompiling the PPL.
On Sun, Aug 07, 2011 at 07:47:39PM +0200, Roberto Bagnara wrote:
On 08/07/11 18:20, Jack Howarth wrote:
On Sun, Aug 07, 2011 at 05:41:28PM +0200, Roberto Bagnara wrote:
On 08/07/11 17:33, Jack Howarth wrote:
On Sun, Aug 07, 2011 at 05:23:15PM +0200, Roberto Bagnara wrote:
I am pretty confident this is a compiler bug.
Is --disable-fpmath our only option here?The only other option I see is to debug the compiler bug.
You are talking about the failures seen without --disable-fpmath, correct? Is this really a compiler bug with clang? I thought it was due to the fact that ppl is coded to expect a functional -frounding-math option to be present. This isn't really a compiler bug but a compiler limitation, no?
Perhaps I misinterpreted you. You wrote:
The results for llvm-gcc-4.2 from Xcode 4.1 weren't as positive. The testcase.../bin/sh: line 1: 91482 Segmentation fault: 11 ${dir}$tst FAIL: simplifyusingcontext1
segfaults with --disable-fpmath. I wouldn't worry too much about that as Apple is using a much older llvm release for llvm-gcc-4.2 than clang3.0svn in Xcode 4.1. Also, their usual response to llvm-gcc bugs is that it is being depreciated in favor of clang and to use that compiler instead.
I took that as "the PPL testsuite segfaults with some old compiler version (and only that one) even when configure with --disable-fpmath". My guess is that that old compiler version is miscompiling the PPL.
Roberto, What I said was the --disable-fpmath is sufficient to allow clang from Xcode 4.1 of Mac OS X 10.7 (Lion) to build ppl 0.11.2 without testsuite regressions. However, llvm-gcc, which is the default system compiler under Mac OS X 10.7 (Lion) suffers from the simplifyusingcontext1 failure even with --disable-fpmath. This is unsurprising because the two compilers use different llvm backend releases...
[MacPro:~] howarth% llvm-gcc -v Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
[MacPro:~] howarth% clang -v Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.0.0 Thread model: posix
The llvm-gcc compiler shipping with Lion is based on a much older llvm release than the clang compiler in Xcode 4.1. I wouldn't worry too much about llvm-gcc as upstream is aiming to depreciate it in llvm 3.0 in favor of the dragonegg solution to using the llvm backend with the FSF gcc frontend. Note that I have confirmed that the current dragonegg svn compiles ppl fine with --disable-fpmath so that it doesn't suffer from the same llvm backend bug as the llvm-gcc system compiler in Lion. Also, Apple is aiming to depreciate llvm-gcc in favor of clang. If you look carefully at bug reports against llvm-gcc in llvm.org, they are routinely closed as won't fix with the recommendation to use the clang compilers instead. Jack
-- Prof. Roberto Bagnara Applied Formal Methods Laboratory Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it _______________________________________________ PPL-devel mailing list PPL-devel@cs.unipr.it http://www.cs.unipr.it/mailman/listinfo/ppl-devel
participants (4)
-
Anthony Foiani -
Enea Zaffanella -
Jack Howarth -
Roberto Bagnara