On 10/06/11 01:04, Janis Johnson wrote: > On 06/08/2011 03:39 AM, Richard Earnshaw wrote: >> On 08/06/11 03:14, Janis Johnson wrote: >>> On 06/07/2011 06:25 PM, Mike Stump wrote: >>>> On Jun 7, 2011, at 4:24 PM, Janis Johnson wrote: >>>>> On 06/07/2011 02:07 PM, Joseph S. Myers wrote: >>>>>> On Tue, 7 Jun 2011, Janis Johnson wrote: >>>>>> >>>>>>> Several tests in gcc.target/arm use dg-options with -mcpu=xxxx, which >>>>>>> causes compiler warnings or errors when the multilib flags include >>>>>>> -march=yyyy. This patch causes those tests to be skipped. It also >>>>>>> prevents gcc.target/arm/20090811-1.c from running with multilibs that >>>>>>> would override -mcpu or -mfloat-abi options specified for the test. >>>>>> >>>>>> I think you should allow compatible -march options - for example, if >>>>>> dg-options has -mcpu=cortex-a8, allow -march=armv7-a but disallow all >>>>>> other -march options. >>>>>> >>>>> Is this one OK? >>>> >>>> Not sure if the arm people want to review this or would rather I review >>>> it... >>>> >>>> Let's give the arm folks a couple days to comment, if no objections, Ok. >>>> >>>> A point of warning, eventually, you'll discover that when a compiler >>>> defaults to the argument you want to skip, that you'll needs slightly more >>>> power to skip them. darwin ran into this with things like -m64, and >>>> eventually had to do something like lp64. configure options like >>>> --with-cpu=arm9 are the sort that can change the default. >>> >>> Yes, I hope to hear from ARM people. >>> >>> On ARM, the default from --with-cpu= is overridden by -march at >>> compile so it's not a problem for this particular set of tests. >>> As I said originally, this set is the tip of the iceberg and they >>> get more difficult. >>> >>> Janis >>> >>> >> >> >> I'm worried by this whole approach of command-line checking. It works, >> just about, for testsuite variations set with target_list, but it won't >> work with options used to configure the compiler (eg --with-mode=thumb, >> or --with-cpu=...). Perhaps a better approach would be a new dg- test >> that built a trivial file with all the options and disabled the test if >> that test failed for any reason. Something like: >> >> dg-target-compatible (target, <compile|link>, additional-opts) >> >> The test is only performed if target matches the current target. >> >> I'm not sure if this is something that can be easily cached (well, it >> might be possible if you could index off additional-opts and the default >> opts), so it might be that this test has to be re-run every time there >> is a test that needs it. >> >> R. > > As I said earlier, the testsuite already provides effective-target support > that checks for complicated things and it's easy enough to add more. > > Given that there are lots of spurious failures right now due to tests > being compiled with conflicting options, or during dg-final checks when the > expected code isn't being generated because multilib options override the > ones given in the test, is this patch to skip tests using -mcpu if the > multilibs use -march OK? I have made the change Joseph suggested to allow > -march values that do not conflict. > > Expect lots more of these patches, with perhaps different solutions for > different tests. >
Don't get me wrong, I wasn't objecting to the patch as it is (it's a useful step forward). I'm just raising a concern that I don't think it's a total solution. Janice, I haven't done it, but a compiler built with --with-mode=thumb would be a useful test to run. R.
