make check-all failing 18 tests with --enable-optimized

As part of our automated testing, I'm running make check-all to watch
for failures. One of my builds uses the --enable-optimized option to
configure. When I build the latest trunk, I'm now seeing 18 failing
tests:
    Clang :: Preprocessor/macro_paste_c_block_comment.c
    LLVM :: CodeGen/ARM/2011-05-04-MultipleLandingPadSuccs.ll
    LLVM :: CodeGen/ARM/2011-11-14-EarlyClobber.ll
    LLVM :: CodeGen/ARM/lsr-unfolded-offset.ll
    LLVM :: CodeGen/Generic/2003-05-28-ManyArgs.ll
    LLVM :: CodeGen/Generic/print-arith-fp.ll
    LLVM :: CodeGen/Thumb/2009-08-20-ISelBug.ll
    LLVM :: CodeGen/Thumb/asmprinter-bug.ll
    LLVM :: CodeGen/X86/2006-10-13-CycleInDAG.ll
    LLVM :: CodeGen/X86/2008-02-08-LoadFoldingBug.ll
    LLVM :: CodeGen/X86/2009-09-10-SpillComments.ll
    LLVM :: CodeGen/X86/2010-02-19-TailCallRetAddrBug.ll
    LLVM :: CodeGen/X86/2010-04-13-AnalyzeBranchCrash.ll
    LLVM :: CodeGen/X86/2011-10-11-SpillDead.ll
    LLVM :: CodeGen/X86/2011-10-12-MachineCSE.ll
    LLVM :: CodeGen/X86/2011-11-09-FoldImpDefs.ll
    LLVM :: CodeGen/X86/Atomics-64.ll
    LLVM :: CodeGen/X86/fold-pcmpeqd-2.ll

17 of these tests started failing with the commit r145975, "First chunk
of MachineInstr bundle support." on 12/6/2011. I've verified that the
tests pass with commit r145974.

The build is running on a CentOS 5.6 machine with gcc version 4.1.2.
The build process is basically:
git clone http://llvm.org/git/llvm.git source
git clone http://llvm.org/git/clang.git source/tools/clang
mkdir build
cd build
../source/configure --prefix=$(dirname $PWD)/install --enable-optimized
make
make check-all

Is anyone else seeing this? Or are these tests known to fail in trunk
right now?

Brendan

As part of our automated testing, I'm running make check-all to watch
for failures. One of my builds uses the --enable-optimized option to
configure. When I build the latest trunk, I'm now seeing 18 failing
tests:
   Clang :: Preprocessor/macro_paste_c_block_comment.c
   LLVM :: CodeGen/ARM/2011-05-04-MultipleLandingPadSuccs.ll
   LLVM :: CodeGen/ARM/2011-11-14-EarlyClobber.ll
   LLVM :: CodeGen/ARM/lsr-unfolded-offset.ll
   LLVM :: CodeGen/Generic/2003-05-28-ManyArgs.ll
   LLVM :: CodeGen/Generic/print-arith-fp.ll
   LLVM :: CodeGen/Thumb/2009-08-20-ISelBug.ll
   LLVM :: CodeGen/Thumb/asmprinter-bug.ll
   LLVM :: CodeGen/X86/2006-10-13-CycleInDAG.ll
   LLVM :: CodeGen/X86/2008-02-08-LoadFoldingBug.ll
   LLVM :: CodeGen/X86/2009-09-10-SpillComments.ll
   LLVM :: CodeGen/X86/2010-02-19-TailCallRetAddrBug.ll
   LLVM :: CodeGen/X86/2010-04-13-AnalyzeBranchCrash.ll
   LLVM :: CodeGen/X86/2011-10-11-SpillDead.ll
   LLVM :: CodeGen/X86/2011-10-12-MachineCSE.ll
   LLVM :: CodeGen/X86/2011-11-09-FoldImpDefs.ll
   LLVM :: CodeGen/X86/Atomics-64.ll
   LLVM :: CodeGen/X86/fold-pcmpeqd-2.ll

17 of these tests started failing with the commit r145975, "First chunk
of MachineInstr bundle support." on 12/6/2011. I've verified that the
tests pass with commit r145974.

The build is running on a CentOS 5.6 machine with gcc version 4.1.2.
The build process is basically:
git clone http://llvm.org/git/llvm.git source
git clone http://llvm.org/git/clang.git source/tools/clang
mkdir build
cd build
../source/configure --prefix=$(dirname $PWD)/install --enable-optimized
make
make check-all

Is anyone else seeing this? Or are these tests known to fail in trunk
right now?

Everything is passing for me and all the buildbots are happy. How are they failing for you?

Evan

As part of our automated testing, I'm running make check-all to watch
for failures. One of my builds uses the --enable-optimized option to
configure. When I build the latest trunk, I'm now seeing 18 failing
tests:
   Clang :: Preprocessor/macro_paste_c_block_comment.c
   LLVM :: CodeGen/ARM/2011-05-04-MultipleLandingPadSuccs.ll
   LLVM :: CodeGen/ARM/2011-11-14-EarlyClobber.ll
   LLVM :: CodeGen/ARM/lsr-unfolded-offset.ll
   LLVM :: CodeGen/Generic/2003-05-28-ManyArgs.ll
   LLVM :: CodeGen/Generic/print-arith-fp.ll
   LLVM :: CodeGen/Thumb/2009-08-20-ISelBug.ll
   LLVM :: CodeGen/Thumb/asmprinter-bug.ll
   LLVM :: CodeGen/X86/2006-10-13-CycleInDAG.ll
   LLVM :: CodeGen/X86/2008-02-08-LoadFoldingBug.ll
   LLVM :: CodeGen/X86/2009-09-10-SpillComments.ll
   LLVM :: CodeGen/X86/2010-02-19-TailCallRetAddrBug.ll
   LLVM :: CodeGen/X86/2010-04-13-AnalyzeBranchCrash.ll
   LLVM :: CodeGen/X86/2011-10-11-SpillDead.ll
   LLVM :: CodeGen/X86/2011-10-12-MachineCSE.ll
   LLVM :: CodeGen/X86/2011-11-09-FoldImpDefs.ll
   LLVM :: CodeGen/X86/Atomics-64.ll
   LLVM :: CodeGen/X86/fold-pcmpeqd-2.ll

17 of these tests started failing with the commit r145975, "First chunk
of MachineInstr bundle support." on 12/6/2011. I've verified that the
tests pass with commit r145974.

The build is running on a CentOS 5.6 machine with gcc version 4.1.2.
The build process is basically:
git clone http://llvm.org/git/llvm.git source
git clone http://llvm.org/git/clang.git source/tools/clang
mkdir build
cd build
../source/configure --prefix=$(dirname $PWD)/install --enable-optimized
make
make check-all

Is anyone else seeing this? Or are these tests known to fail in trunk
right now?

Everything is passing for me and all the buildbots are happy. How are they failing for you?

Evan

I'm not sure what you mean. I'm getting blocks of "Machine code for
function" for some of the failing tests. In other cases I'm getting
what looks like a memory dump. I have the output from the latest run at
the following URL if that helps:
https://dmz-portal.mips.com/bb/builders/LLVM%20optimize%20install/builds/30/steps/make%20check-all/logs/stdio

Brendan

I don't know about the LLVM errors, but I have seen the Clang error before. It occurs because the test is not path independent. In Preprocessor/macro_paste_c_block_comment.c you have 'nog grep scratch', which means that you can't have 'scratch' in your path. I think this should be reported as a bug.

Regards,
Patrik Hägglund

I have now made a report at http://llvm.org/bugs/show_bug.cgi?id=11552.

Patrik Hägglund

Hi Brendan,
Have you tried with -O2 instead of -O3 ?

$ svn diff ../llvm/configure
Index: ../llvm/configure

Thanks for this, I noticed this recently also (and internally expect it to
fail).

Behalf Of Patrik Hägglund H

http://llvm.org/docs/GettingStarted.html#brokengcc

-Eli

Thanks. I had been wondering about that one as well. I'll try this
without scratch in the path.

Brendan

It's strange that this had been working up until commit r145975, then.
Any idea what that commit would have changed to break the tests again?

Brendan

>> As part of our automated testing, I'm running make check-all to watch
>> for failures. One of my builds uses the --enable-optimized option to
>> configure. When I build the latest trunk, I'm now seeing 18 failing
>> tests:
>> Clang :: Preprocessor/macro_paste_c_block_comment.c
>> LLVM :: CodeGen/ARM/2011-05-04-MultipleLandingPadSuccs.ll
>> LLVM :: CodeGen/ARM/2011-11-14-EarlyClobber.ll
>> LLVM :: CodeGen/ARM/lsr-unfolded-offset.ll
>> LLVM :: CodeGen/Generic/2003-05-28-ManyArgs.ll
>> LLVM :: CodeGen/Generic/print-arith-fp.ll
>> LLVM :: CodeGen/Thumb/2009-08-20-ISelBug.ll
>> LLVM :: CodeGen/Thumb/asmprinter-bug.ll
>> LLVM :: CodeGen/X86/2006-10-13-CycleInDAG.ll
>> LLVM :: CodeGen/X86/2008-02-08-LoadFoldingBug.ll
>> LLVM :: CodeGen/X86/2009-09-10-SpillComments.ll
>> LLVM :: CodeGen/X86/2010-02-19-TailCallRetAddrBug.ll
>> LLVM :: CodeGen/X86/2010-04-13-AnalyzeBranchCrash.ll
>> LLVM :: CodeGen/X86/2011-10-11-SpillDead.ll
>> LLVM :: CodeGen/X86/2011-10-12-MachineCSE.ll
>> LLVM :: CodeGen/X86/2011-11-09-FoldImpDefs.ll
>> LLVM :: CodeGen/X86/Atomics-64.ll
>> LLVM :: CodeGen/X86/fold-pcmpeqd-2.ll
>>
>> 17 of these tests started failing with the commit r145975, "First chunk
>> of MachineInstr bundle support." on 12/6/2011. I've verified that the
>> tests pass with commit r145974.
>>
>> The build is running on a CentOS 5.6 machine with gcc version 4.1.2.
> http://llvm.org/docs/GettingStarted.html#brokengcc
>
> -Eli

It's strange that this had been working up until commit r145975, then.
Any idea what that commit would have changed to break the tests again?

FWIW, that commit also completely broke compiling clang on PPC with gcc
4.1.2, even at -O1 (which used to be okay). Using newer versions of gcc
work, however, and it definitely looks like a compiler bug in 4.1.2.

-Hal

As part of our automated testing, I'm running make check-all to watch
for failures. One of my builds uses the --enable-optimized option to
configure. When I build the latest trunk, I'm now seeing 18 failing
tests:
   Clang :: Preprocessor/macro_paste_c_block_comment.c
   LLVM :: CodeGen/ARM/2011-05-04-MultipleLandingPadSuccs.ll
   LLVM :: CodeGen/ARM/2011-11-14-EarlyClobber.ll
   LLVM :: CodeGen/ARM/lsr-unfolded-offset.ll
   LLVM :: CodeGen/Generic/2003-05-28-ManyArgs.ll
   LLVM :: CodeGen/Generic/print-arith-fp.ll
   LLVM :: CodeGen/Thumb/2009-08-20-ISelBug.ll
   LLVM :: CodeGen/Thumb/asmprinter-bug.ll
   LLVM :: CodeGen/X86/2006-10-13-CycleInDAG.ll
   LLVM :: CodeGen/X86/2008-02-08-LoadFoldingBug.ll
   LLVM :: CodeGen/X86/2009-09-10-SpillComments.ll
   LLVM :: CodeGen/X86/2010-02-19-TailCallRetAddrBug.ll
   LLVM :: CodeGen/X86/2010-04-13-AnalyzeBranchCrash.ll
   LLVM :: CodeGen/X86/2011-10-11-SpillDead.ll
   LLVM :: CodeGen/X86/2011-10-12-MachineCSE.ll
   LLVM :: CodeGen/X86/2011-11-09-FoldImpDefs.ll
   LLVM :: CodeGen/X86/Atomics-64.ll
   LLVM :: CodeGen/X86/fold-pcmpeqd-2.ll

17 of these tests started failing with the commit r145975, "First chunk
of MachineInstr bundle support." on 12/6/2011. I've verified that the
tests pass with commit r145974.

The build is running on a CentOS 5.6 machine with gcc version 4.1.2.

http://llvm.org/docs/GettingStarted.html#brokengcc

-Eli

It's strange that this had been working up until commit r145975, then.
Any idea what that commit would have changed to break the tests again?

FWIW, that commit also completely broke compiling clang on PPC with gcc
4.1.2, even at -O1 (which used to be okay). Using newer versions of gcc
work, however, and it definitely looks like a compiler bug in 4.1.2.

-Hal

I'm compiling with -O2 now, but it sounds like that isn't going to
work. Thanks for the information. I guess I'll need to upgrade to
CentOS 6.

Brendan