Buildbots: Apology and Explanation

I need to apologize to many of you, especially Gabor, for my vitriol over buildbot breakages. I get very enraged by breakages that occur over long periods of time. Here's an attempt to explain why I fly off the handle at these.

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 came up with the idea of using builbots. We started using them internally at Apple (unfortunately, those machines are still unavailable to non-Apple employees). It quickly spread so that some were set up at Google. It was a huge win for us.

However, it's only a huge win if people pay attention to the error reports. People didn't. At first, there were a lot of "false negatives". Those were fixed. Then the reporting scheme wasn't great. Those were also fixed. Still, people would break the builds and let things go for hours or days at a time. This feels like a slap in the face to me. After so much hard work, people are ignoring the one piece of quality assurance that we are afforded in the LLVM community. In the meantime, many many patches are going in which aren't being tested. If something breaks after the initial breakage, then it's that much harder to determine what's going on. It's a lot of wasted effort.

Couple that with the fact that we at Apple (and other place, to be sure) rely upon ToT to be fairly stable so that we can create branches from ToT at a moment's notice, and you get a really bad and stressful situation.

So, yes, I take it personally when breakages are ignored. It's an unfortunate part of my personality that I'm trying to work on, but on occasion gets the better of me, and I lash out.

Again, my apologies. Please watch what the buildbots have to say. Even if you can't see the log file message, try to see if there's something you might have missed. Someone with access to the Apple-only machines would be happy to forward the error message to you if you think your patch might be the cause.

Sincerely,
Bill (Monkeypox)

people would break the builds and let
things go for hours or days at a time.

"Hours or days".
Instead of months or years. Isn't OS wonderful?
You have high standards and I admire the importance you assign to perfection

    M

Hi Bill,

... Still, people would break the builds and let things go for hours or days at a time.

don't forget the time-zone effect. I regularly get build
failures in the morning, presumably because someone in the
US committed just before going to bed. I guess they are
happily snoring away when the build-bots (and humans) start
complaining! So when hours go by without a fix, it might be
because the committer is getting some beauty sleep (or is at
work, and can't do anything from there).

Ciao,

Duncan.

At my old job, we were expected to stay after doing a commit at least
long enough for the buildbot to complain if the build was broken. Of
course our buildbots took about 10 minutes after commit to finish a
build, so that wasn't much of a burden...

Hi Bill,

... Still, people would break the builds and let
things go for hours or days at a time.

don't forget the time-zone effect. I regularly get build
failures in the morning, presumably because someone in the
US committed just before going to bed. I guess they are
happily snoring away when the build-bots (and humans) start
complaining!

I don't buy this, see below ...

So when hours go by without a fix, it might be

because the committer is getting some beauty sleep (or is at
work, and can't do anything from there).

Ciao,

Duncan.

At my old job, we were expected to stay after doing a commit at least
long enough for the buildbot to complain if the build was broken. Of
course our buildbots took about 10 minutes after commit to finish a
build, so that wasn't much of a burden...

The x86_64 builders take less than 5 minutes to test and build llvm.
See,e.g., http://google1.osuosl.org:8011/builders/llvm-x86_64-linux/builds/7168

Elapsed 4 mins, 31 secs

It is basically never behind (IE maybe once a week is a build queued).

Unless you think 4 mins 31 seconds after you commit is a huge burden,
there is basically no excuse for breaking the build (at least on
x86_64), which still happens.
Not to mention, a lot of the failing revisions i checked randomly are
failing tests on every platform.

Much like Bill, i don't see any excuse for this.
Things that fail on every platform are a great indication that someone
didn't bother to actually run make test and check the results.

It is rare that you have the magic configuration that it works on.
This is all pretty common sense and courtesy:
Test your code before committing
Don't commit if you aren't going to be around to fix it the next few
hours. (it's one thing to commit something that passes all tests and
gets discovered to have broken something untested 5 days later. It's
another to commit something and go to bed in your timezone without
having tested it, breaking the build for everyone else).

If someone wants to complain there machine isn't fast enough to run
the tests in a reasonable time period, i'm happy to set up a try
server on the x86_64 machine and you can get your patches tested fast.

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'
make[1]: Entering directory `/home/melis/c/llvm-svn-release/runtime'
make[2]: Entering directory
`/home/melis/c/llvm-svn-release/runtime/libprofile'
llvm[2]: Compiling BasicBlockTracing.ll to BasicBlockTracing.bc for
Release build (bytecode)
/home/melis/c/llvm-svn-release/Release/bin/llvm-as:
/home/melis/c/llvm-svn-release/runtime/libprofile/Release/BasicBlockTracing.ll:1:2:
error: expected top-level entity
    .file "BasicBlockTracing.c"
    ^
/home/melis/c/llvm-svn-release/Release/bin/opt: Invalid bitcode signature
make[2]: ***
[/home/melis/c/llvm-svn-release/runtime/libprofile/Release/BasicBlockTracing.bc]
Error 1
make[2]: Leaving directory
`/home/melis/c/llvm-svn-release/runtime/libprofile'
make[1]: *** [libprofile/.makeall] Error 2
make[1]: Leaving directory `/home/melis/c/llvm-svn-release/runtime'
make: *** [all] Error 1

It seems BasicBlockTracing.ll contains assembly instead of LLVM IR.

Also, llvm-gcc also doesn't build for me. Here the error is related to
exception handling:

make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/libdecnumber'
make[3]: Entering directory `/home/melis/c/llvm-gcc-svn-build/gcc'
/home/melis/local/bin/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 -fno-common -DHAVE_CONFIG_H -I. -I.
-I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/.
-I../../llvm-gcc-svn/gcc/../include
-I../../llvm-gcc-svn/gcc/../libcpp/include
-I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber
gtype-desc.c -o gtype-desc.o
gtype-desc.c:5862: error: 'sjlj_fc_type_node' undeclared here (not in a
function)
make[3]: *** [gtype-desc.o] Error 1
make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/melis/c/llvm-gcc-svn-build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/melis/c/llvm-gcc-svn-build'
make: *** [all] Error 2

Is there something suddenly wrong with my system (which hasn't changed
in any way)? I used to be able to build LLVM(GCC) without problems a few
weeks ago...

Regards,
Paul

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'
make[1]: Entering directory `/home/melis/c/llvm-svn-release/runtime'
make[2]: Entering directory
`/home/melis/c/llvm-svn-release/runtime/libprofile'
llvm[2]: Compiling BasicBlockTracing.ll to BasicBlockTracing.bc for
Release build (bytecode)
/home/melis/c/llvm-svn-release/Release/bin/llvm-as:
/home/melis/c/llvm-svn-release/runtime/libprofile/Release/BasicBlockTracing.ll:1:2:
error: expected top-level entity
   .file "BasicBlockTracing.c"
   ^
/home/melis/c/llvm-svn-release/Release/bin/opt: Invalid bitcode signature
make[2]: ***
[/home/melis/c/llvm-svn-release/runtime/libprofile/Release/BasicBlockTracing.bc]
Error 1
make[2]: Leaving directory
`/home/melis/c/llvm-svn-release/runtime/libprofile'
make[1]: *** [libprofile/.makeall] Error 2
make[1]: Leaving directory `/home/melis/c/llvm-svn-release/runtime'
make: *** [all] Error 1

It seems BasicBlockTracing.ll contains assembly instead of LLVM IR.

Also, llvm-gcc also doesn't build for me. Here the error is related to
exception handling:

make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/libdecnumber'
make[3]: Entering directory `/home/melis/c/llvm-gcc-svn-build/gcc'
/home/melis/local/bin/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 -fno-common -DHAVE_CONFIG_H -I. -I.
-I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/.
-I../../llvm-gcc-svn/gcc/../include
-I../../llvm-gcc-svn/gcc/../libcpp/include
-I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber
gtype-desc.c -o gtype-desc.o
gtype-desc.c:5862: error: 'sjlj_fc_type_node' undeclared here (not in a
function)
make[3]: *** [gtype-desc.o] Error 1
make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/melis/c/llvm-gcc-svn-build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/melis/c/llvm-gcc-svn-build'
make: *** [all] Error 2

Is there something suddenly wrong with my system (which hasn't changed
in any way)? I used to be able to build LLVM(GCC) without problems a few
weeks ago...

SJLJ exception handling is only implemented on ARM Darwin. It looks like your target is pulling in bits of that?

And for the folks who keep multiple patches in the same SVN checkout dir, you should test your patch alone before you submit.

Clearly, patching in your change into a new clean SVN workspace and rebuilding and re-running all tests will take some time; for this, I recommend using a compiler cache, e.g. ccache, which should allow everyone to have a single SVN workspace per logical change, so that you’re testing exactly what you’re about to commit.

Misha

I get the same error when trying to build the LLVM2.6 prerelease1 on
x86-64 Linux.
FWIW building TOT llvm/llvm-gcc doesn't have this problem.

Best regards,
--Edwin

Jim Grosbach 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
build):

[...]
make[1]: Leaving directory `/home/melis/c/llvm-svn-release/tools'
make[1]: Entering directory `/home/melis/c/llvm-svn-release/runtime'
make[2]: Entering directory
`/home/melis/c/llvm-svn-release/runtime/libprofile'
llvm[2]: Compiling BasicBlockTracing.ll to BasicBlockTracing.bc for
Release build (bytecode)
/home/melis/c/llvm-svn-release/Release/bin/llvm-as:
/home/melis/c/llvm-svn-release/runtime/libprofile/Release/
BasicBlockTracing.ll:1:2:
error: expected top-level entity
   .file "BasicBlockTracing.c"
   ^
/home/melis/c/llvm-svn-release/Release/bin/opt: Invalid bitcode
signature
make[2]: ***
[/home/melis/c/llvm-svn-release/runtime/libprofile/Release/
BasicBlockTracing.bc]
Error 1
make[2]: Leaving directory
`/home/melis/c/llvm-svn-release/runtime/libprofile'
make[1]: *** [libprofile/.makeall] Error 2
make[1]: Leaving directory `/home/melis/c/llvm-svn-release/runtime'
make: *** [all] Error 1

It seems BasicBlockTracing.ll contains assembly instead of LLVM IR.

Also, llvm-gcc also doesn't build for me. Here the error is related to
exception handling:

make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/
libdecnumber'
make[3]: Entering directory `/home/melis/c/llvm-gcc-svn-build/gcc'
/home/melis/local/bin/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 -fno-common -DHAVE_CONFIG_H -I. -I.
-I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/.
-I../../llvm-gcc-svn/gcc/../include
-I../../llvm-gcc-svn/gcc/../libcpp/include
-I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber
gtype-desc.c -o gtype-desc.o
gtype-desc.c:5862: error: 'sjlj_fc_type_node' undeclared here (not
in a
function)
make[3]: *** [gtype-desc.o] Error 1
make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/melis/c/llvm-gcc-svn-build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/melis/c/llvm-gcc-svn-build'
make: *** [all] Error 2

Is there something suddenly wrong with my system (which hasn't changed
in any way)? I used to be able to build LLVM(GCC) without problems a
few
weeks ago...

SJLJ exception handling is only implemented on ARM Darwin. It looks
like your target is pulling in bits of that?

Well, I don't know what changed to make this suddenly happen. FYI, here is
the configure line I have been using for quite some time:

../llvm-gcc-svn/configure \
    --prefix=/home/melis/llvm \
    --program-prefix=llvm- \
    --with-llvm=/home/melis/c/llvm-svn \
    --enable-languages=c,c++ \
    --target=i686-pc-linux-gnu \
    --with-tune=generic \
    --with-arch=pentium4

Paul

Paul Melis wrote:

Jim Grosbach 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
build):

[...]
make[1]: Leaving directory `/home/melis/c/llvm-svn-release/tools'
make[1]: Entering directory `/home/melis/c/llvm-svn-release/runtime'
make[2]: Entering directory
`/home/melis/c/llvm-svn-release/runtime/libprofile'
llvm[2]: Compiling BasicBlockTracing.ll to BasicBlockTracing.bc for
Release build (bytecode)
/home/melis/c/llvm-svn-release/Release/bin/llvm-as:
/home/melis/c/llvm-svn-release/runtime/libprofile/Release/
BasicBlockTracing.ll:1:2:
error: expected top-level entity
   .file "BasicBlockTracing.c"
   ^
/home/melis/c/llvm-svn-release/Release/bin/opt: Invalid bitcode
signature
make[2]: ***
[/home/melis/c/llvm-svn-release/runtime/libprofile/Release/
BasicBlockTracing.bc]
Error 1
make[2]: Leaving directory
`/home/melis/c/llvm-svn-release/runtime/libprofile'
make[1]: *** [libprofile/.makeall] Error 2
make[1]: Leaving directory `/home/melis/c/llvm-svn-release/runtime'
make: *** [all] Error 1

It seems BasicBlockTracing.ll contains assembly instead of LLVM IR.

Also, llvm-gcc also doesn't build for me. Here the error is related to
exception handling:

make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/
libdecnumber'
make[3]: Entering directory `/home/melis/c/llvm-gcc-svn-build/gcc'
/home/melis/local/bin/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 -fno-common -DHAVE_CONFIG_H -I. -I.
-I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/.
-I../../llvm-gcc-svn/gcc/../include
-I../../llvm-gcc-svn/gcc/../libcpp/include
-I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber
gtype-desc.c -o gtype-desc.o
gtype-desc.c:5862: error: 'sjlj_fc_type_node' undeclared here (not
in a
function)
make[3]: *** [gtype-desc.o] Error 1
make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/melis/c/llvm-gcc-svn-build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/melis/c/llvm-gcc-svn-build'
make: *** [all] Error 2

Is there something suddenly wrong with my system (which hasn't changed
in any way)? I used to be able to build LLVM(GCC) without problems a
few
weeks ago...

SJLJ exception handling is only implemented on ARM Darwin. It looks
like your target is pulling in bits of that?

Well, I don't know what changed to make this suddenly happen. FYI, here is
the configure line I have been using for quite some time:

../llvm-gcc-svn/configure \
    --prefix=/home/melis/llvm \
    --program-prefix=llvm- \
    --with-llvm=/home/melis/c/llvm-svn \
    --enable-languages=c,c++ \
    --target=i686-pc-linux-gnu \
    --with-tune=generic \
    --with-arch=pentium4

It seems my installed version of llvm-gcc had lost its ability to generate
LLVM IR (-c -emit-llvm was ignored, it simply produced assembly in that
case). That caused LLVM itself not to build, as the stuff in runtime/
picked up the flaky llvm-gcc.

Cleaning out my LLVM install and completely rebuilding from scratch fixed
the LLVM build. However, llvm-gcc still has the SJLJ error.

Paul

Please try pulling in the changes from r80588. I suspect that'll take care of your issue. Unfortunately, I can't reproduce the failure here to verify directly.

-Jim

It fixes it for me: with that patch I can bootstrap llvm2.6 now.
I think it should be pulled into the 2.6 branch.

Best regards,
--Edwin

Jim Grosbach wrote:

Paul Melis wrote:

Jim Grosbach 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
build):

[...]
make[1]: Leaving directory `/home/melis/c/llvm-svn-release/tools'
make[1]: Entering directory `/home/melis/c/llvm-svn-release/runtime'
make[2]: Entering directory
`/home/melis/c/llvm-svn-release/runtime/libprofile'
llvm[2]: Compiling BasicBlockTracing.ll to BasicBlockTracing.bc for
Release build (bytecode)
/home/melis/c/llvm-svn-release/Release/bin/llvm-as:
/home/melis/c/llvm-svn-release/runtime/libprofile/Release/
BasicBlockTracing.ll:1:2:
error: expected top-level entity
  .file "BasicBlockTracing.c"
  ^
/home/melis/c/llvm-svn-release/Release/bin/opt: Invalid bitcode
signature
make[2]: ***
[/home/melis/c/llvm-svn-release/runtime/libprofile/Release/
BasicBlockTracing.bc]
Error 1
make[2]: Leaving directory
`/home/melis/c/llvm-svn-release/runtime/libprofile'
make[1]: *** [libprofile/.makeall] Error 2
make[1]: Leaving directory `/home/melis/c/llvm-svn-release/runtime'
make: *** [all] Error 1

It seems BasicBlockTracing.ll contains assembly instead of LLVM IR.

Also, llvm-gcc also doesn't build for me. Here the error is
related to
exception handling:

make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/
libdecnumber'
make[3]: Entering directory `/home/melis/c/llvm-gcc-svn-build/gcc'
/home/melis/local/bin/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 -fno-common -DHAVE_CONFIG_H -I. -I.
-I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/.
-I../../llvm-gcc-svn/gcc/../include
-I../../llvm-gcc-svn/gcc/../libcpp/include
-I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber
gtype-desc.c -o gtype-desc.o
gtype-desc.c:5862: error: 'sjlj_fc_type_node' undeclared here (not
in a
function)
make[3]: *** [gtype-desc.o] Error 1
make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/melis/c/llvm-gcc-svn-build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/melis/c/llvm-gcc-svn-build'
make: *** [all] Error 2

Is there something suddenly wrong with my system (which hasn't
changed
in any way)? I used to be able to build LLVM(GCC) without problems a
few
weeks ago...

SJLJ exception handling is only implemented on ARM Darwin. It looks
like your target is pulling in bits of that?

Well, I don't know what changed to make this suddenly happen. FYI,
here is
the configure line I have been using for quite some time:

../llvm-gcc-svn/configure \
   --prefix=/home/melis/llvm \
   --program-prefix=llvm- \
   --with-llvm=/home/melis/c/llvm-svn \
   --enable-languages=c,c++ \
   --target=i686-pc-linux-gnu \
   --with-tune=generic \
   --with-arch=pentium4

It seems my installed version of llvm-gcc had lost its ability to
generate
LLVM IR (-c -emit-llvm was ignored, it simply produced assembly in that
case). That caused LLVM itself not to build, as the stuff in runtime/
picked up the flaky llvm-gcc.

Cleaning out my LLVM install and completely rebuilding from scratch
fixed
the LLVM build. However, llvm-gcc still has the SJLJ error.

Please try pulling in the changes from r80588. I suspect that'll take
care of your issue. Unfortunately, I can't reproduce the failure here
to verify directly.

Well, that seems to have fixed it with TOT, thanks!

Paul

Paul Melis wrote:

Paul Melis wrote:
  

Jim Grosbach 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
build):

[...]
make[1]: Leaving directory `/home/melis/c/llvm-svn-release/tools'
make[1]: Entering directory `/home/melis/c/llvm-svn-release/runtime'
make[2]: Entering directory
`/home/melis/c/llvm-svn-release/runtime/libprofile'
llvm[2]: Compiling BasicBlockTracing.ll to BasicBlockTracing.bc for
Release build (bytecode)
/home/melis/c/llvm-svn-release/Release/bin/llvm-as:
/home/melis/c/llvm-svn-release/runtime/libprofile/Release/
BasicBlockTracing.ll:1:2:
error: expected top-level entity
   .file "BasicBlockTracing.c"
   ^
/home/melis/c/llvm-svn-release/Release/bin/opt: Invalid bitcode
signature
make[2]: ***
[/home/melis/c/llvm-svn-release/runtime/libprofile/Release/
BasicBlockTracing.bc]
Error 1
make[2]: Leaving directory
`/home/melis/c/llvm-svn-release/runtime/libprofile'
make[1]: *** [libprofile/.makeall] Error 2
make[1]: Leaving directory `/home/melis/c/llvm-svn-release/runtime'
make: *** [all] Error 1

It seems BasicBlockTracing.ll contains assembly instead of LLVM IR.

Also, llvm-gcc also doesn't build for me. Here the error is related to
exception handling:

make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/
libdecnumber'
make[3]: Entering directory `/home/melis/c/llvm-gcc-svn-build/gcc'
/home/melis/local/bin/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 -fno-common -DHAVE_CONFIG_H -I. -I.
-I../../llvm-gcc-svn/gcc -I../../llvm-gcc-svn/gcc/.
-I../../llvm-gcc-svn/gcc/../include
-I../../llvm-gcc-svn/gcc/../libcpp/include
-I../../llvm-gcc-svn/gcc/../libdecnumber -I../libdecnumber
gtype-desc.c -o gtype-desc.o
gtype-desc.c:5862: error: 'sjlj_fc_type_node' undeclared here (not
in a
function)
make[3]: *** [gtype-desc.o] Error 1
make[3]: Leaving directory `/home/melis/c/llvm-gcc-svn-build/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/melis/c/llvm-gcc-svn-build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/melis/c/llvm-gcc-svn-build'
make: *** [all] Error 2

Is there something suddenly wrong with my system (which hasn't changed
in any way)? I used to be able to build LLVM(GCC) without problems a
few
weeks ago...

SJLJ exception handling is only implemented on ARM Darwin. It looks
like your target is pulling in bits of that?
      

Well, I don't know what changed to make this suddenly happen. FYI, here is
the configure line I have been using for quite some time:

../llvm-gcc-svn/configure \
    --prefix=/home/melis/llvm \
    --program-prefix=llvm- \
    --with-llvm=/home/melis/c/llvm-svn \
    --enable-languages=c,c++ \
    --target=i686-pc-linux-gnu \
    --with-tune=generic \
    --with-arch=pentium4
    
It seems my installed version of llvm-gcc had lost its ability to generate
LLVM IR (-c -emit-llvm was ignored, it simply produced assembly in that
case). That caused LLVM itself not to build, as the stuff in runtime/
picked up the flaky llvm-gcc.
  

After rebuilding LLVM and llvm-gcc a couple of times now (after rm -rf
*-ing the build directories and reconfiguring) I keep having the problem
that -S -emit-llvm does not produce LLVM IR, e.g.

22:11|melis@juggle2:~> llvm-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../llvm-gcc-svn/configure --prefix=/home/melis/llvm
--program-prefix=llvm- --with-llvm=/home/melis/llvm
--enable-languages=c,c++ --target=i686-pc-linux-gnu --with-tune=generic
--with-arch=pentium4 : (reconfigured) ../llvm-gcc-svn/configure
--prefix=/home/melis/llvm --program-prefix=llvm-
--with-llvm=/home/melis/llvm --enable-languages=c,c++
--target=i686-pc-linux-gnu --with-tune=generic --with-arch=pentium4
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5649)
22:11|melis@juggle2:~> cat doh.c
#include <stdio.h>
int main()
{
    printf("Doh!\n");
}
22:11|melis@juggle2:~> llvm-gcc -S -emit-llvm doh.c
22:11|melis@juggle2:~> ls -l doh.*
-rw-r--r-- 1 melis melis 56 Aug 31 22:10 doh.c
-rw-r--r-- 1 melis melis 310 Aug 31 22:11 doh.s
22:11|melis@juggle2:~> cat doh.s
    .file "doh.c"
    .section .rodata
.LC0:
    .string "Doh!"
    .text
.globl main
    .type main, @function
main:
    pushl %ebp
    movl %esp, %ebp
    subl $24, %esp
    movl $.LC0, (%esp)
    call puts
    leave
    ret
    .size main, .-main
    .ident "GCC: (GNU) 4.2.1 (Based on Apple Inc. build 5649)"
    .section .note.GNU-stack,"",@progbits

I figured perhaps the --with-llvm value I used was wrong (should it be
llvm build-dir or final installation dir?), but after trying different
values it still makes no difference. What would cause llvm-gcc to loose
the capability of writing out LLVM IR?

Thanks,
Paul

Does --enable-llvm=<path> instead of --with-llvm=<path> yield the same results?

-Jim

Hello, Paul

>> ../llvm-gcc-svn/configure \
>> --prefix=/home/melis/llvm \
>> --program-prefix=llvm- \
>> --with-llvm=/home/melis/c/llvm-svn \

You need to use --enable-llvm, not --with-llvm

gcc version 4.2.1 (Based on Apple Inc. build 5649)

As you can see - this is not llvm-enabled gcc

Hi Paul,

I figured perhaps the --with-llvm value I used was wrong (should it be
llvm build-dir or final installation dir?), but after trying different
values it still makes no difference. What would cause llvm-gcc to loose
the capability of writing out LLVM IR?

maybe you built an llvm-gcc with LLVM disabled (in which case you get
an ordinary Apple GCC, or at least you're supposed to)? Did you specify
--enable-llvm when configuring GCC?

Ciao,

Duncan.

Anton Korobeynikov wrote:

Hello, Paul

../llvm-gcc-svn/configure \
    --prefix=/home/melis/llvm \
    --program-prefix=llvm- \
    --with-llvm=/home/melis/c/llvm-svn \
        

You need to use --enable-llvm, not --with-llvm
  

Ok

gcc version 4.2.1 (Based on Apple Inc. build 5649)
    

As you can see - this is not llvm-enabled gcc
  

Ok, how would an enabled one report its version number?

Thanks,
Paul

Hello, Paul

Ok, how would an enabled one report its version number?

Something like this:
  .ident "GCC: (GNU) 4.2.1 (Based on Apple Inc. build 5649) (LLVM build)"