Unexpected failures in the DejaGNU test collection

Hi all,

When using "make check" with the DejaGNU test collection, I encounter
two unexpected failures (they seem to be closely related).
My question: are they well known, and if so what's the problem and how
can I fix it?

This is the error text I get:

FAIL: /var/data/common/trunk/llvm/test/FrontendC/2008-05-19-AlwaysInline.c
Failed with exit(1) at line 1
while running: /var/data/common/template_wc//install/bin/llvm-gcc
-emit-llvm -w /var/data/common/trunk/llvm/test/FrontendC/2008-05-19-AlwaysInline.c
-S -fno-unit-at-a-time -emit-llvm -O0 -o - | not /bin/grep sabrina
/var/data/common/trunk/llvm/test/FrontendC/2008-05-19-AlwaysInline.c:12:
error: inlined_to pointer is set but no predecessors found
sabrina/2: (inline copy in bar/1) availability:available(0) needed
tree finalized always_inline
  called by:
  calls:
/var/data/common/trunk/llvm/test/FrontendC/2008-05-19-AlwaysInline.c:12:
internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.

FAIL: /var/data/common/trunk/llvm/test/FrontendC/always-inline.c
Failed with exit(1) at line 1
while running: /var/data/common/template_wc//install/bin/llvm-gcc
-emit-llvm -w -S
/var/data/common/trunk/llvm/test/FrontendC/always-inline.c -o - |
/bin/grep call | not /bin/grep foo
/var/data/common/trunk/llvm/test/FrontendC/always-inline.c:12: error:
inlined_to pointer is set but no predecessors found
foo/4: (inline copy in i_want_bar/3) availability:available(1) 16
insns needed tree finalized always_inline
  called by:
  calls: bar/0
/var/data/common/trunk/llvm/test/FrontendC/always-inline.c:12:
internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.

Harel Cain

Hello Harel,

Failures in the FrontendC test suite usually means that your llvm-gcc is older than your LLVM tree.

Try compiling llvm-gcc from top-of-tree and see if the failures remain.

Regards,
/jakob

Since it came up, what is blocking us from putting these tests in the
llvm-gcc test suite instead of in the LLVM test suite?

- Daniel

Usually we want to check these tests regularly against llvm backend
changes. The nightly tester does not svn update and rebuild llvm-gcc
hence these tests are in LLVM Test Suite. BTW, llvm-gcc test suite
already has llvm.objc and llvm-obj-c++ folders for llvm related tests.

Since it came up, what is blocking us from putting these tests in the

llvm-gcc test suite instead of in the LLVM test suite?

Usually we want to check these tests regularly against llvm backend
changes. The nightly tester does not svn update and rebuild llvm-gcc
hence these tests are in LLVM Test Suite. BTW, llvm-gcc test suite
already has llvm.objc and llvm-obj-c++ folders for llvm related tests.

Do the nightly testers even run the llvm-gcc test suite or keep track of those results? I’m pretty sure they don’t.

It is also not our release criteria. So something to keep in mind.

-Tanya

There is no point running llvm-gcc test suite if llvm-gcc is not updated :slight_smile:

Hi Daniel,

Since it came up, what is blocking us from putting these tests in the
llvm-gcc test suite instead of in the LLVM test suite?

they are useful for testing the llvm gcc plugin. This is llvm-gcc
implemented as a gcc plugin. As such, it is not possible to make
modifications to the underlying gcc tree, such as adding testcases,
except by pushing changes upstream to mainline gcc. I doubt they will
except llvm-gcc testcases, but you never know :slight_smile:

Ciao,

Duncan.

Hi Jakob,

We're using unmodified release version 2.5 of both llvm and
llvm-gcc-4.2 and that same problem I mentioned shows up in both the
DejaGNU tests and in the test-suite, and I even checked on two
different boxes. Everything else works perfectly.

Nobody encountered those failures?

Harel

Since it came up, what is blocking us from putting these tests in the
llvm-gcc test suite instead of in the LLVM test suite?

Usually we want to check these tests regularly against llvm backend
changes.

Thats fine, but meaningless. If the backend changes and llvm-gcc isn't
built, it accomplishes nothing. There is a fundamental flaw in
checking in the tests for tool FOO into the repository for tool BAR.

The nightly tester does not svn update and rebuild llvm-gcc
hence these tests are in LLVM Test Suite.

This is a solvable problem.

BTW, llvm-gcc test suite already has llvm.objc and llvm-obj-c++ folders for
llvm related tests.

Ok.

- Daniel

Since it came up, what is blocking us from putting these tests in the

llvm-gcc test suite instead of in the LLVM test suite?

Usually we want to check these tests regularly against llvm backend
changes. The nightly tester does not svn update and rebuild llvm-gcc
hence these tests are in LLVM Test Suite. BTW, llvm-gcc test suite
already has llvm.objc and llvm-obj-c++ folders for llvm related tests.

Do the nightly testers even run the llvm-gcc test suite or keep track of
those results? I'm pretty sure they don't.

I think it wouldn't be too hard to incorporate this; we could only
check the llvm specific directories.

It is also not our release criteria. So something to keep in mind.

If its incorporated into the nightlytest, it automatically becomes
part of the release criteria, right?

- Daniel

Hi Daniel,

Since it came up, what is blocking us from putting these tests in the
llvm-gcc test suite instead of in the LLVM test suite?

they are useful for testing the llvm gcc plugin. This is llvm-gcc
implemented as a gcc plugin. As such, it is not possible to make
modifications to the underlying gcc tree, such as adding testcases,
except by pushing changes upstream to mainline gcc. I doubt they will
except llvm-gcc testcases, but you never know :slight_smile:

Tests for the llvm gcc plugin should be in the llvm gcc plugin repository.

I think it is worth solving this problem, because it currently makes
the public buildbot results less than useful, it frequently breaks on
Frontend changes. I also personally find this pretty annoying that I
am forced to update llvm-gcc more frequently than I would otherwise
need to, if I want clean local test results. I don't think most LLVM
developers would appreciate clang tests being in the LLVM repo,
either.

- Daniel

Since it came up, what is blocking us from putting these tests in the

llvm-gcc test suite instead of in the LLVM test suite?

Usually we want to check these tests regularly against llvm backend

changes. The nightly tester does not svn update and rebuild llvm-gcc

hence these tests are in LLVM Test Suite. BTW, llvm-gcc test suite

already has llvm.objc and llvm-obj-c++ folders for llvm related tests.

Do the nightly testers even run the llvm-gcc test suite or keep track of

those results? I’m pretty sure they don’t.

I think it wouldn’t be too hard to incorporate this; we could only
check the llvm specific directories.

I’d be fine with that. I don’t know if gcc’s test suite runs cleanly on its own, so avoiding running everything is preferred because that would be a lot of noise if no one is going to fix the issues that are not llvm specific.

It is also not our release criteria. So something to keep in mind.

If its incorporated into the nightlytest, it automatically becomes
part of the release criteria, right?

Most likely. Things that become release criteria are things that are regularly tested and people are actively fixing the failures that occur.

-Tanya