llvm dev - Nov 2006 - [LLVMdev] datapoint for recent llvm-gcc4 build failures

I routinely fetch the latest LLVM and LLVM-GCC4 and recompile, perhaps every few
days or so. I've not had success in some cases building LLVM-GCC4 on a
Gentoo Linux host, for perhaps the last week or so. My system compiler is GCC
4.1.1.
>>>
cc1: /usr/src/llvm/llvm/include/llvm/Target/TargetInstrInfo.h:151:const
llvm::TargetInstrDescriptor& llvm::TargetInstrInfo::get(llvm::MachineOpCode)
const: Assertion '(unsigned)Opcode < NumOpcodes' failed.
/usr/src/llvm/llvm-gcc4/gcc/crtstuff.c: At top level:
/usr/src/llvm/llvm-gcc4/gcc/crtstuff.c:314: internal compiler error: Aborted
<<<

This occurs only when building for Release. (Maybe I shouldn't do that with
fresh CVS and SVN checkouts? :-) I'd build Debug, but I prefer
sub-several-minute link times). If I switch the system compiler to GCC 3.4.6,
this failure goes away. I'm not sure how to interpret that, in light of the
many many changes between those two compiler versions, and the history of GCC
4.x codegen bugs.


Whenever I rebuild LLVM/LLVM-GCC4, I first clean all installed traces from the
machine, so there isn't a question of old binaries or old libraries perhaps
being pulled into the new build.

I have an older source tree from a few weeks back where this is most definitely
not a problem. I regret that I cannot be more precise about what commit produced
the breakage (for me).

In closing, please allow me to congratulate all of you for all of your hard
work. LLVM is very impressive and useful.


Andrew Purtell
SPARTA, Inc.
apurtell at yahoo.com

Opinions and communications made via this account should not be construed to be
either the opinion of or an official communication from SPARTA, Inc.

> This occurs only when building for Release. (Maybe I shouldn't do that
with fresh CVS and SVN checkouts? :-) I'd build Debug, but I prefer
sub-several-minute link times).
Maybe you have hit a binutils bug:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1543

Best Regards,
Rafael

Andrew Purtell wrote:
> I routinely fetch the latest LLVM and LLVM-GCC4 and recompile, perhaps
every few days or so. I've not had success in some cases building LLVM-GCC4
on a Gentoo Linux host, for perhaps the last week or so. My system compiler is
GCC 4.1.1.
>
>   
> cc1: /usr/src/llvm/llvm/include/llvm/Target/TargetInstrInfo.h:151:const
llvm::TargetInstrDescriptor& llvm::TargetInstrInfo::get(llvm::MachineOpCode)
const: Assertion '(unsigned)Opcode < NumOpcodes' failed.
> /usr/src/llvm/llvm-gcc4/gcc/crtstuff.c: At top level:
> /usr/src/llvm/llvm-gcc4/gcc/crtstuff.c:314: internal compiler error:
Aborted
> <<<
>   
Hi Andrew,

I too ran into this bug, which can be sidestepped by building LLVM with
optimisation
at the -O2 level (rather than the default -O3).  My make command was:
make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION='-O2 -g' tools-only

I was trying to track down the cause of the bug, but haven't had success
yet.

Hope this is useful.

Cheers,
Warren

Gentlemen,
>From the GettingStarted.html guide:
GCC 4.1.1: GCC fails to build LLVM with template concept check errors
compiling some files. At the time of this writing, GCC mainline (4.2)
did not share the problem.

I continue to use 3.4.6 because of 4.1.X failures and because it is
*very* slow to compile LLVM. Its not clear that 4.2 will fix the slow
compilation problems (lots of related GCC bugs still not fixed).

Reid.

On Fri, 2006-11-10 at 10:32 +1100, Warren Armstrong
wrote:
> Andrew Purtell wrote:
> > I routinely fetch the latest LLVM and LLVM-GCC4 and recompile, perhaps
every few days or so. I've not had success in some cases building LLVM-GCC4
on a Gentoo Linux host, for perhaps the last week or so. My system compiler is
GCC 4.1.1.
> >
> >   
> > cc1:
/usr/src/llvm/llvm/include/llvm/Target/TargetInstrInfo.h:151:const
llvm::TargetInstrDescriptor& llvm::TargetInstrInfo::get(llvm::MachineOpCode)
const: Assertion '(unsigned)Opcode < NumOpcodes' failed.
> > /usr/src/llvm/llvm-gcc4/gcc/crtstuff.c: At top level:
> > /usr/src/llvm/llvm-gcc4/gcc/crtstuff.c:314: internal compiler error:
Aborted
> > <<<
> >   
> 
> Hi Andrew,
> 
> I too ran into this bug, which can be sidestepped by building LLVM with
> optimisation
> at the -O2 level (rather than the default -O3).  My make command was:
> make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION='-O2 -g' tools-only
> 
> I was trying to track down the cause of the bug, but haven't had
success
> yet.
> 
> Hope this is useful.
> 
> Cheers,
> Warren
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

This looks suspiciously like a bug I had introduced recently. It  
should have been fixed.

Please try TOT llvm. If the problem persists, file a bug report and  
attach a reproducible test case (using llvm-gcc -c -emit-llvm to  
create a bytecode file). I'll take a look at it.

Evan
On Nov 9, 2006, at 11:45 AM, Andrew Purtell wrote:
> I routinely fetch the latest LLVM and LLVM-GCC4 and recompile,  
> perhaps every few days or so. I've not had success in some cases  
> building LLVM-GCC4 on a Gentoo Linux host, for perhaps the last  
> week or so. My system compiler is GCC 4.1.1.
>
>>>>
> cc1: /usr/src/llvm/llvm/include/llvm/Target/TargetInstrInfo.h: 
> 151:const llvm::TargetInstrDescriptor& llvm::TargetInstrInfo::get 
> (llvm::MachineOpCode) const: Assertion '(unsigned)Opcode <  
> NumOpcodes' failed.
> /usr/src/llvm/llvm-gcc4/gcc/crtstuff.c: At top level:
> /usr/src/llvm/llvm-gcc4/gcc/crtstuff.c:314: internal compiler  
> error: Aborted
> <<<
>
> This occurs only when building for Release. (Maybe I shouldn't do  
> that with fresh CVS and SVN checkouts? :-) I'd build Debug, but I  
> prefer sub-several-minute link times). If I switch the system  
> compiler to GCC 3.4.6, this failure goes away. I'm not sure how to  
> interpret that, in light of the many many changes between those two  
> compiler versions, and the history of GCC 4.x codegen bugs.
>
>
> Whenever I rebuild LLVM/LLVM-GCC4, I first clean all installed  
> traces from the machine, so there isn't a question of old binaries  
> or old libraries perhaps being pulled into the new build.
>
> I have an older source tree from a few weeks back where this is  
> most definitely not a problem. I regret that I cannot be more  
> precise about what commit produced the breakage (for me).
>
> In closing, please allow me to congratulate all of you for all of  
> your hard work. LLVM is very impressive and useful.
>
>
> Andrew Purtell
> SPARTA, Inc.
> apurtell at yahoo.com
>
> Opinions and communications made via this account should not be  
> construed to be either the opinion of or an official communication  
> from SPARTA, Inc.
>
>
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev