similar to: [LLVMdev] llvm-gcc bootstrap failures

See below. This is on Ubuntu Hardy on ia32. Thanks, John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.

Hi all, There's been a recent bootstrap failure that might be covered up because of another failure. I just wanted to point this out so that people can take a look: -bw Here's the failure from our buildbot: Assertion failed: (DestReg == VirtReg && "Unknown load situation!"), function RewriteMBB, file /Volumes/Sandbox/Buildbot/llvm/build.llvm-

Hello, Everyone. I'm currently trying to bootstrap llvm-gcc4 on mingw32 platform. Everything (except some small fixes) seems to be fine: stage1 finished successfully. I'm linking with debug variant of LLVM, since linker bug prevents release builds. Unfortunately, stage2 failes immediately with this cryptic message: $/f/tmp/llvm/gccbuild/gcc/xgcc -B/f/tmp/llvm/gccbuild/gcc/

On Aug 30, 2009, at 10:18 AM, Paul Melis wrote: > Hello, > > Bill Wendling wrote: >> Before we had buildbots, a random patch would break the system. It >> would sometimes take a whole day to determine which patch broke it. > I see the buildbots are currently showing no problem on 32-bit linux > but > I get the following build error with TOT (out-of-source autoconf

I'm getting the error below on Ubuntu Hardy on ia32 on r55688. John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc

While keeping up-to-date the nouveau mesa driver (either classic or gallium), or doing regression testing, the big majority of my rebuilds resulted in segfaults. I am not talking about autogen or configure detection. I believe this also works automatically in other projects and doesn't with mesa, but forgetting to do this usually causes a build failure. Then autogen/configure can be run and

Hello all, I am trying to install the llvm-gcc front end to use it in one of my projects, but I got stuck.. I am working on a Sun workstation: SunOS xxx 5.10 Generic_137137-09 sun4u sparc SUNW,Sun-Fire-V240 and I have gcc version 3.4.6: Reading specs from /sw/gcc-3.4.6/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs Configured with: /.scratch/andjo/lsw/src/gcc/gcc-3.4.6/configure

I'm getting the following when building llvm-gcc with an optimized set of LLVM libraries: /ptmp/dag/build.llvm-gcc-4.2.trunk.official.opt/x86_64-unknown-linux-gnu/./gcc/xgcc -B/ptmp/dag/build.llvm-gcc-4.2.trunk.official.opt/x86_64-unknown-linux-gnu/./gcc/ -B/cray/iss/compiler/cost/tools/llvm-tools/llvm/install.trunk.official.opt/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/bin/

Hello, Bill Wendling wrote: > Before we had buildbots, a random patch would break the system. It > would sometimes take a whole day to determine which patch broke it. I see the buildbots are currently showing no problem on 32-bit linux but I get the following build error with TOT (out-of-source autoconf build): [...] make[1]: Leaving directory `/home/melis/c/llvm-svn-release/tools'

On Aug 31, 2009, at 6:48 AM, Paul Melis wrote: > Paul Melis wrote: >> Jim Grosbach wrote: >>> >>> On Aug 30, 2009, at 10:18 AM, Paul Melis wrote: >>> >>>> Hello, >>>> >>>> Bill Wendling wrote: >>>>> Before we had buildbots, a random patch would break the system. It >>>>> would sometimes take a

Hi, I am having some difficulties building llvm on Itanium. My procedure for building LLVM is: cd /liberty/llvm.ia64/llvm-2.1 ./configure make ENABLE_OPTIZED=1 cd /liberty/llvm.ia64/obj /liberty/llvm.ia64/llvm-gcc4.2-2.1.source/configure --prefix=/liberty/llvm.ia64/install --enable-llvm=/liberty/llvm.ia64/llvm-2.1/ --enable-languages=c,c++ --disable-shared The build of llvm seems to

Jim Grosbach wrote: > > On Aug 30, 2009, at 10:18 AM, Paul Melis wrote: > >> Hello, >> >> Bill Wendling wrote: >>> Before we had buildbots, a random patch would break the system. It >>> would sometimes take a whole day to determine which patch broke it. >> I see the buildbots are currently showing no problem on 32-bit linux >> but >> I

On Fri, Mar 13, 2009 at 2:38 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi, the versions of llvm-gcc and llvm you are using are > not synchronized. Probably one is from subversion while > the other is not. > > Ciao, > > Duncan. > Ok, I 'synchronized' both of them, but now I am getting a different error. On running make, the output ends with the

Hi, I've figured out a little more. #if defined DBX_DEBUGGING_INFO || XCOFF_DEBUGGING_INFO guards the declaration of type_queue, however, neither is defined on Intanium. In gt-dbxout.h type_queue's uses are unguarded and thus are undefined on Itanium. When I compared llvm-gcc's gt-dbxout.h with FSF gcc's, I found that type_queue was never used in FSF gcc's version. Does

Where I work, we have an application that has been merrily running away (and being built) on FC1 (yes, you read that right). One of my assignments is to bring this up to CentOS, but on my first effort, I ran into this interesting "feature." The original build process (FC1) uses mkdep to generate the dependency files that are subsequently used by the makes to build the app. mkdep does

Paul Melis wrote: > Jim Grosbach wrote: >> >> On Aug 30, 2009, at 10:18 AM, Paul Melis wrote: >> >>> Hello, >>> >>> Bill Wendling wrote: >>>> Before we had buildbots, a random patch would break the system. It >>>> would sometimes take a whole day to determine which patch broke it. >>> I see the buildbots are currently

Devang Patel wrote: > On Jan 10, 2008, at 10:29 AM, Thomas Jablin wrote: > > >> Hi, >> >> I've figured out a little more. #if defined DBX_DEBUGGING_INFO || >> XCOFF_DEBUGGING_INFO guards the declaration of type_queue, however, >> neither is defined on Intanium. In gt-dbxout.h type_queue's uses are >> unguarded and thus are undefined on

On Jan 10, 2008, at 10:29 AM, Thomas Jablin wrote: > Hi, > > I've figured out a little more. #if defined DBX_DEBUGGING_INFO || > XCOFF_DEBUGGING_INFO guards the declaration of type_queue, however, > neither is defined on Intanium. In gt-dbxout.h type_queue's uses are > unguarded and thus are undefined on Itanium. When I compared llvm- > gcc's > gt-dbxout.h

Duncan Sands dixit: >Can you bootstrap llvm-gcc (configure with --enable-bootstrap)? Nope, probably because it uses the host C++ compiler instead of the one built in stage1 during stage2: /usr/ports/lang/llvm-gcc/w-llvm-gcc4.2-58935-1/llvm-gcc4.2/host-i386-ecce-mirbsd10/prev-gcc/xgcc -B/usr/ports/lang/llvm-gcc/w-llvm-gcc4.2-58935-1/llvm-gcc4.2/host-i386-ecce-mirbsd10/prev-gcc/

Bugs 1519 and 1521 currently prevent a clean bootstrap on Linux x86_64. I was able to hack it to work :-) The attached patch includes two parts. One is a tentative fix bug 1519: just set LastFieldStartsAtNonByteBoundry in allFieldsAreNotBitFields. The other one is a plain hack. llvm-gcc and gcc disagree on how to pass some structures, so stage2 gcc fails to use the libcpp compiled by gcc. So I