The DejaGnu tests will now avoid running tests for targets that are not configured. Unfortunately, the Generic test suite contains test cases for specific targets. This causes false FAIL in test/CodeGen/Generic because the target specific options are not supported by llc. For example, the -march=ppc32 option is not supported in a test case if PowerPC is not configured to be built. This should be rectified by moving or copying the tests that use the -march option from Generic to the appropriate target directories.
*** 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=<unbuilt-target> 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.