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