*** This bug has been marked as a duplicate of 556 ***

This is not a duplicate of 556. bug 556 had to do with the mechanism to detect
that only certain targets are built and to not execute target specific tests if
the target hasn't been built. That functionality was implemented a week ago so I
just closed 556.

This bug is about getting tests in the right directory, a wholly different problem.

Why do we even care about this? People shouldn't be running tests unless they have everything built.
Obviously, if they don't, they can cause regressions in the stuff they don't test.

You're missing the point, Chris.

Regardless of the targets they have specified as being built, if they run the
"Generic" tests, they should reasonably expect them to succeed. But, if those
"generic" tests require a specific target then they fail. Generic tests should
be generic, i.e. not target specific. This bug just asks that situation
actually be true.

BTW, I would expect that most users (not developers) would select to only
build the target for one machine. I certainly expect to do that with HLVM and
XPS. Its a waste to build targets that won't be used. It bloats executables
needlessly.

Fix some PowerPC tests:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070430/048726.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070430/048727.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070430/048728.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070430/048729.html

BTW, I would expect that most users (not developers) would select to only
build the target for one machine. I certainly expect to do that with HLVM and
XPS. Its a waste to build targets that won't be used. It bloats executables
needlessly.

You're confusing many different issues here reid.

1. Users vs developers. We care most about developers who want to test their stuff to ensure they are
   not causing regressions.
2. "It bloats executables needlessly." only if you link them in.

There are tests that run multiple different targets. This is by design and not something that should
change.

-Chris

You're confusing many different issues here reid.

There's no confusion.

1. Users vs developers. We care most about developers who want to test
   their stuff to ensure they are not causing regressions.

So, package managers for operating system distros just "don't count" in your
view? Developers of language front ends who want to check for regressions, don't
count? C'mon, I don't believe you actually believe this ridiculous statement.
Users count too.

2. "It bloats executables needlessly." only if you link them in.

Huh? The default is to link in every target configured to be built. The entire
POINT of this is that users are not likely to build all targets because they
don't want the bloat in the executables. That being the case, they will get
false regressions in the test suite, simply because their llc can't handle the
-march options that specify targets that they didn't build. This is not the
user's fault, it is the fault of the test suite which needs to make "generic"
tests truly target independent. All this bug is about is correcting this situation.

There are tests that run multiple different targets. This is by design and
not something that should change.

The only thing that is changing is that such tests are being replicated so that
they run on a per-target basis. This allows un-built targets to be excluded
instead of generating a false test failure because of -march= in
the test script. There's no loss of functionality here, just a rearrangement of
where the tests live to avoid false positives in the regression test regardless
of which targets were built.

Fine, go for it.

This has been implemented. Only target-independent test cases should go in
CodeGen. All test cases that had a -march= option have been moved or duplicated
into the target-specific subdirectories of test/CodeGen. From now on, please do
not use the -march option in the test/CodeGen/Generic directory.

mentioned in issue #928