Buildbot

Project Infrastructure LLVM Dev List Archives
1

Do the buildbots only build debug components? I am seeing lots of this on
trunk with release-style builds:

[x86_64-off-opt]: Failed with signal(SIGABRT) at line 1
[x86_64-off-opt]: while running: llvm-as < /ptmp/dag/llvm-
project.official/llvm/tags/RELEASE_25/test/Transforms/TailDup/basictest2.ll |
opt -tailduplicate -disable-output
[x86_64-off-opt]: Value still in symbol table! Type = 'i64' Name = 'poscnt.1'
[x86_64-off-opt]: Value still in symbol table! Type = 'i64' Name = 'tmp.289'
[x86_64-off-opt]: llvm-as: /ptmp/dag/llvm-
project.official/llvm/tags/RELEASE_25/lib/VMCore/ValueSymbolTable.cpp:29:
llvm::ValueSymbolTable::~ValueSymbolTable(): Assertion `vmap.empty() &&
"Values remain in symbol table!"' failed.
[x86_64-off-opt]: 0 llvm-as 0x000000000056812a
[x86_64-off-opt]: 1 libc.so.6 0x00002af9d6424c10
[x86_64-off-opt]: 2 libc.so.6 0x00002af9d6424b95 gsignal + 53
[x86_64-off-opt]: 3 libc.so.6 0x00002af9d6425f90 abort + 272
[x86_64-off-opt]: 4 libc.so.6 0x00002af9d641e256 __assert_fail + 246
[x86_64-off-opt]: 5 llvm-as 0x00000000004f84f2
[x86_64-off-opt]: 6 llvm-as 0x00000000004b973e llvm::Function::~Function()
+ 238
[x86_64-off-opt]: 7 llvm-as 0x00000000004e3b7f llvm::Module::~Module() +
287
[x86_64-off-opt]: 8 llvm-as 0x000000000044af07 main + 1319
[x86_64-off-opt]: 9 libc.so.6 0x00002af9d6412154 __libc_start_main + 244
[x86_64-off-opt]: 10 llvm-as 0x000000000044a1a9 __gxx_personality_v0 + 169

                                            -Dave

2

No, some build release, and some build release-asserts.

Historically, this is a typical sign of llvm being miscompiled, see
the broken-gcc list.

- Daniel

3

Yep, that's it. We've been happily using gcc 4.1.2 on OpenSUSE for test
builds for some time without problem (we don't use it for releases yet, and
won't now!). I guess something changed to make the issue visible to us.

BTW, how sure are we that all these are gcc issues and not some incorrect
code somewhere that triggers undefined behavior?

                                    -Dave

4

Which means it could break my CentOS tests also. One missing feature that I know of
for this configuration is that 4.1.2 on this platform does not support gcc atomic builtins.
I need to upgrade this environment anyway.

Garrison

5

No, some build release, and some build release-asserts.

Historically, this is a typical sign of llvm being miscompiled, see
the broken-gcc list.

Yep, that's it. We've been happily using gcc 4.1.2 on OpenSUSE for test
builds for some time without problem (we don't use it for releases yet, and
won't now!). I guess something changed to make the issue visible to us.

BTW, how sure are we that all these are gcc issues and not some incorrect
code somewhere that triggers undefined behavior?

Medium sure? :slight_smile:

I spent a little while hunting this particular bug, and it acted very
much like a compiler bug. I never narrowed it down to a test case,
though.

- Daniel

6

Is there a gcc bug for this testcase? I'd like to understand better exactly
what the issue is.

Looking at http://llvm.org/docs/GettingStarted.html#brokengcc here's the
current recommendation:

   We routinely use GCC 3.3.3, 3.4.0, and Apple 4.0.1 successfully with them
  (however, see important notes below).

Is this really still true? Is there a later version of gcc that's
recommended? 3.4.x is ancient. Does the page need an update?

What are people out there using today?

                                               -Dave

7

SnowLeopard had a 4.2 derivative as well and seems to be working fine.

-eric

8

I have successfully used gcc 4.2, 4.3, and 4.4 with LLVM.
gcc 3.4 (and older) is no longer good for me, since it doesn't support
the atomic builtins, hence no multithreading support for LLVM.
Other than that it still builds LLVM (or at least it used to a few
months ago).

gcc 4.0.x/4.1.0 is broken on x86 for other reasons, so I haven't tried
it with LLVM. Haven't tried Apple gcc 4.0/ppc, it might work.

Best regards,
--Edwin