Janis Johnson <jani...@codesourcery.com> writes: > On 06/29/2011 06:55 AM, Richard Earnshaw wrote: >> I'd posit a third option: >> >> 3. Add a new dg directive (perhaps dg-ignore-multilib) that instructs >> the framework to ignore the multilib options entirely (only supported >> for compile/assembly tests). >> >> There are a lot of target-specific tests that are not really testing >> execution, just that the compiler generates the right instruction under >> specific compilation options. It seems silly to force all this into the >> multi-lib framework. >> >> R. > > The MIPS tests have support for something like that that, but it seems > to me that if tests are being run for lots of multilibs then it's > better to test things like code generation for a variety of relevant > options instead of using the same options every time.
I might be misunderstanding what you mean, but the MIPS version tries to keep as many of the original options as possible, only overriding those that are known to be incompatible with the test. So e.g. a test for a MIPS IV feature will run normally on a MIPS IV-compatible target, but will override the architecture on other targets. That said, I wouldn't recommend the mips.exp approach to anyone. It's been useful, and it seems to do what it's meant to, but it's a very... heavy-weight approach. Richard
