[committed] MIPS testsuite improvements

[Richard Sandiford]

One of the problems with the dg framework is that options passed to
--target_board override options added by dg-options.  Thus:

  { dg-options "-mips1" }

has no effect when using a runtest option like:

  --target_board mips-sim-idt64/-mips3

And because there are so many possible MIPS combinations to test,
this problem actually occurs quite often in gcc.target/mips,
especially when using embedded configurations.

We have some logic in mips.exp to work out whether a particular set of
options will "stick"; i.e. whether they're compatible with the user's
current options.  This logic started out fairly simple, but it's grown
to be a bit unwieldly now.  Furthermore, you need to remember to use
dg-mips-options instead of dg-options, and it's easy to forget.

I think it would be better to go the other way, and override any user
options that are incompatible with the test options.  E.g., in the case
above, we'd remove the user's -mips3 if there's a conflicting test option,
but leave it in place otherwise.  And I think we should do this in a local
override of dg-options, rather than using a separate dg-mips-options routine.

This change also makes it easier to fix the problem that Adam
mentioned a few months back:

    http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00794.html

Namely, with something like:

    /* { dg-do compile { target mips16_attribute } } */
    /* { dg-mips-options "<blah>" } */
    /* { dg-add-options mips16_attribute } */

the mips16_attribute routines don't (and in general can't)
take <blah> into account.

With the new scheme we can avoid mips16_attribute altogether.
mips.exp needs to know how to handle "-mips16" anyway, and how to
engineer the options so that -mips16 is valid.  We can simply add
a new construct to say "make the options compatible with X without
adding X itself".  The syntax I chose was to wrap X in parentheses.
So e.g.:

    /* { dg-options "(-mips16) -O2 -mhard-float" } */

selects a MIPS16-compatible hard-float ABI without actually
passing -mips16 to GCC.

Also, if a test only runs on a subset of targets, we have tended to
specify a particular one.  E.g. the MIPS-3D tests use -mips64, even
though they ought to work with MIPS64r2, SB-1, -mips32r2 -mfp64 etc.
Many of the MIPS16e tests likewise specify a particular architecture.
The same is true for ISA feature tests like ins-1.c.

I'd like to avoid this whereever we can.  Instead, architecture
requirements should be left to the mips.exp harness where possible,
and specified using more general directives otherwise.  E.g. we can
teach mips.exp what the requirements for MIPS-3D are, removing the
need for any architecture directives in those tests.  And for cases
like MIPS16e and ins-1.c, we can use new directives to specify the
range of permissable ISA levels or ISA revisions.

This change has caught quite a few 64-bit bugs that were otherwise lying
unnoticed.  Over the last couple of weeks, I've committed fixes for the
ICEs and wrong code bugs, and today I've filed PRs for the missed
optimisations.

Finally, I think that mips.exp should try to downgrade unsupported
run tests to link tests, and unsupported link tests to assemble tests.
At least that way we get _some_ coverage, rather than leaving the code
path entirely untested.  ISTR this caught a couple of the problems just
mentioned.

With these changes, we can now run all mips.exp tests in some form on
all targets, whereas previously we tended to skip quite a few.

The patch and changelog are large, so I've attached them in compressed
form.  But it's probably useful to quote the new comment at the head
of mips.exp:

# There are many MIPS features that we want to test, and many of those
# features are specific to certain architectures, certain ABIs and so on.
# There are therefore many cases in which we want to test something that
# is incompatible with the user's chosen test options.
#
# In most dg testsuites, the options added by dg-options have a lower
# priority than the options chosen by the user.  For example, if a test
# specifies:
#
#    { dg-options "-mips1" }
#
# and the user passes the following option to runtest:
#
#    --target_board unix/-mips3
#
# the test would be compiled as MIPS III rather than MIPS I.  If the
# test really wouldn't work with -mips3, normal practice would be to
# have something like:
#
#    { dg-do compile { target can_force_mips1 } }
#
# so that the test is skipped when an option like -mips3 is passed.
#
# Sticking to the same approach here would cause us to skip many tests,
# even though the toolchain can generate the required code.  For example,
# there are 6 MIPS ABIs, plus variants.  Some configurations support
# more than one ABI, so it is natural to use something like:
#
#    --target_board unix{-mabi=n32,-mabi=32,-mabi=64}
#
# when testing them.  But these -mabi=* options would normally prevent any
# EABI and o64 tests from running.
#
# This testsuite therefore defines a local version of dg-options that
# overrides any user options that are incompatible with the test options.
# It tries to keep the other user options intact.
#
#
# Most of the tests in this testsuite are scan-assembler tests, but
# sometimes we need a link test instead.  In these cases, we must not
# try to link code with options that are incompatible with the current
# multilib, because xgcc is passed -L and -B options that are specific
# to that multilib.
#
# Normal GCC practice would be to skip incompatible link tests as
# unsupported, but in this particular case, it seems better to downgrade
# them to an assemble test instead.  At least that way we get some
# test-for-ICE and code-sanity coverage.
#
# The same problem applies to run tests.  If a test requires runtime
# support for a particular feature, and if the current target does not
# provide that support, normal practice would be to skip the test.
# But in this case it seems better to downgrade it to a link test instead.
# (We might then have to downgrade it to an assembler test according to
# the constraints just mentioned.)
#
# The local dg-options therefore checks whether the new options are
# link-compatiable with the user's options.  If not, it automatically
# downgrades link tests to assemble tests.  It does the same for run
# tests, but in addition, it downgrades run tests to link tests if the
# target does not provide runtime support for a required feature or ASE.
#
#
# Another problem is that many of the options we want to test require
# certain other features.  For example, -mips3d requires both 64-bit
# FPRs and a MIPS32 or MIPS64 target; -mfix-r10000 requires branch-
# likely instructions; and so on.  We could handle this by specifying
# a set of options that are guaranteed to give us what we want, such as:
#
#   dg-options "-mips3d -mpaired-single -mhard-float -mgp64 -mfp64 -mabi=n32 -march=mips64 -mips64"
#
# With the new dg-options semantics, this would override any troublesome
# user options like -mips3, -march=vr4100, -mfp32, -mgp32, -msoft-float,
# -mno-paired-single and so on.  But there are three major problems with
# this:
#
#   - It is easy to forget options.
#
#   - If a new option is added, all tests that are incompatible with that
#     option must be updated.
#
#   - We want to be able to test MIPS-3D with things like -march=mips32,
#     -march=mips64r2, -march=sb1, and so on.
#
# The local version of dg-options therefore works out the requirements
# of each test option.  As with the test options themselves, the local
# dg-options overrides any user options that incompatible with these
# requirements, but it keeps the other user options the same.
#
# For example, if the user passes -mips3, a MIPS-3D test will choose
# a different architecture like -mips64 instead.  But if the user
# passes -march=sb1, MIPS-3D tests will be run with that option.
#
#
# Sometimes it is useful to say "I want an environment that is compatible
# with option X, but I don't want to pass option X itself".  The main example
# of this is -mips16: we want to be able to test __attribute__((mips16))
# without requiring the test itself to be compiled as -mips16.  The local
# version of dg-options lets you do this by putting X in parentheses.
# For example:
#
#   { dg-options "(-mips16)" }
#
# selects a MIPS16-compatible target without passing -mips16 itself.
#
# It is also useful to say "any architecture within this ISA range is fine".
# This can be done using special pseudo-options of the form:
#
#   PROP=VALUE PROP<=VALUE PROP>=VALUE
#
# where PROP can be:
#
#   isa:
#	the value of the __mips macro.
#
#   isa_rev:
#	the value of the __mips_isa_rev macro, or 0 if it isn't defined.
#
# For example, "isa_rev>=1" selects a MIPS32 or MIPS64 processor,
# "isa=4" selects a MIPS IV processor, and so on.  There are also
# the following special pseudo-options:
#
#   isa=loongson:
#	select a Loongson processor
#
#   addressing=absolute
#	force absolute addresses to be used
#
#
# In summary:
#
#   (1) Try to avoid { target ... } requirements wherever possible.
#       Specify the requirements as dg-options instead.
#
#   (2) Don't worry about the consequences of (1) for link and run tests.
#       If the test uses { dg-do link } or { dg-do run }, and its
#       dg-options are incompatible with the current target, the
#       testsuite will downgrade them where necessary.
#
#   (3) Try to use the bare minimum of options and leave dg-options
#       to work out the dependencies.  For example, if you want
#       a MIPS-3D test, you should generally just specify -mips3d.
#       Don't specify an architecture option like -mips64 unless
#       the test really doesn't work with -mips32r2, -mips64r2,
#       -march=sb1, etc.
#
#   (4) If you want something compatible with a particular option,
#       but don't want to pass the option itself, wrap that option
#       in parentheses.  In particular, pass '(-mips16)' if you
#       want to use "mips16" attributes.
#
#   (5) When testing a feature of a generic ISA (as opposed to a
#	processor-specific extension), try to use the "isa" and
#	"isa_rev" pseudo-options instead of specific architecture
#	options.  For example, if the feature is present on revision 2
#	processors and above, try to use "isa_rev>=2" instead of
#	"-mips32r2" or "-mips64r2".

Tested on

   mips-elf
   mips64-elf
   mipsisa32-elf
   mipsisa64-elf
      {-EL,-EB}{,-msoft-float}

   mipsisa32r2-elfoabi
      {-EL,-EB}{,-msoft-float,-mfp64}{,-mips16}

   mipsisa64-elfoabi
   mipsisa64r2-elfoabi
      {-EL,-EB}{,-msoft-float}{,-mips16}

   mips64el-linux-gnu
      {-mabi=n32,-mabi=32,-mabi=64}

The only testsuite failure was atomic-memory-1.c on mips-elf, where the
expected error is not printed due to the lack of LL/SC support.  This
failure existed before the patch too.

Applied.  Please let me know if you come across any problems.

Richard


-------------- next part --------------
A non-text attachment was scrubbed...
Name: mips-testsuite-rewrite.patch.bz2
Type: application/octet-stream
Size: 20412 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20081221/617741fb/attachment.obj>