This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] handle multibyte stores larger than char in strlen (PR 91183, 86888)


On 7/24/19 8:39 PM, Jeff Law wrote:
On 7/24/19 8:17 PM, Martin Sebor wrote:
Committed in r273783 after retesting and including a test for
the warning that I had left out of the patch I posted here.

Martin

PS I suspect some of the tests I added might need tweaking on
big-endian systems.  I'll deal with them tomorrow.

And maybe also strictly aligned targets.  A sparc-solaris2.11 cross
shows these failures.  It looks like it doesn't like something about
some of the 64 bit stores in the tests.

FAIL: gcc.dg/strlenopt-70.c scan-tree-dump-times optimized "strlen" 0
FAIL: gcc.dg/strlenopt-70.c scan-tree-dump-times optimized
"_not_eliminated_" 0
FAIL: gcc.dg/strlenopt-71.c (test for excess errors)
FAIL: gcc.dg/strlenopt-72.c scan-tree-dump-times optimized "strlen" 0
FAIL: gcc.dg/strlenopt-72.c scan-tree-dump-times optimized
"_not_eliminated_" 0


msp430-elf failures:


New tests that FAIL (5 tests):

msp430-sim: gcc.dg/strlenopt-70.c (test for excess errors)
msp430-sim: gcc.dg/strlenopt-70.c scan-tree-dump-times optimized "_not_eliminated_" 0

This one is due to bugs in the endian macros the test defines
to try to handle both big and little-endian.  I've fixed those/

msp430-sim: gcc.dg/strlenopt-71.c (test for excess errors)

Same here, though this is a runtime test so it will also fail
to link outside of an emulator.  (Changing the test harness to
report these tests as UNSUPPORTED instead would avoid this sort
of ambiguity.)

msp430-sim: gcc.dg/strlenopt-72.c scan-tree-dump-times optimized "_not_eliminated_" 0
msp430-sim: gcc.dg/strlenopt-72.c scan-tree-dump-times optimized "strlen" 0

This failure is due to to a combination of the absence of early
store merging in pr83821.  The former prevents the stores below

  char a[4];
  a[0] = 'X';
  a[1] = 0;
  a[2] = a[3] = 0;

from turning into:

  MEM <unsigned int> [(char * {ref-all})&b] = 49;

pr83821 causes the strlen pass to invalidate strlen information
when it sees the assignment to a[2] (or beyond).  I need to dust
off and resubmit my patch for that from last year.

Until that patch is approved I have disabled the test on strictly
aligned targets.

The failure in gcc.dg/Wstringop-overflow-14.c on visium-elf was
because of a difference between strictly aligned targets and
the rest, which triggers different warnings between the two sets.
I disabled the unexpected warning and the test passes.

I've just committed r273812 and r273814 with these changes.

Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]