[Bug testsuite/83483] [8 Regression] gcc.dg/memcpy-6.c FAILs

["msebor at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83483

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
I can reproduce the failure with a sparc-sun-solaris2.11 cross-compiler.

The test is my mistake.  I shouldn't have checked it in as it's not finished. 
I created it after a discussion with Richard to verify that GCC would fold
calls to memcpy and memove with small sizes.  Verifying this seemed important
because the change that Richard and I were discussing avoided the folding when
the accesses overlapped, yet nothing in the test suite pointed it out.

That GCC doesn't always fold these calls is apparent not just from this failure
but also from the code in gimple-fold.c which uses MOVE_MAX as the maximum
size.  MOVE_MAX is defined to be anywhere from 1 (avr.h) to 8 (sparc.h) to 16
(i386.h).  The test assumes that accesses of up to 8 bytes will be folded so it
will fail on all the targets where MOVE_MAX is less than 8.  Even for sizes
that do fit the limit the back end can decide not to fold if the access is not
aligned (as the sparc back end does), and so the test will also fail on a bunch
of targets where MOVE_MAX is 8 or more.

To pass across the board, the test would need to be parameterized on these
variables.  Hardcoding them into the test would make it fragile, so it would
need to somehow extract them from the config file(s).  If that's even possible,
I'm not sure it's worth the effort.  I think the should probably only run on a
very small set of well-known targets, perhaps just x86/x86_64.  Let me make
that change.