[PPL-devel] Fwd: ppl 0.11.2 vs llvm

[Jack Howarth]

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 at cs.unipr.it
> _______________________________________________
> PPL-devel mailing list
> PPL-devel at cs.unipr.it
> http://www.cs.unipr.it/mailman/listinfo/ppl-devel