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.