On 7/25/19 1:42 PM, Martin Sebor wrote:
> 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.)
Well, the "test for excess errors" should be an indicator that something
went wrong before trying to execute. Typically these are compile-time
warnings/errors or occasionally a link time error due to an undefined
symbol.
I don't have access to the tester, so I can't really look at it until I
return though.
>
>>> 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.
No problem. When I'm back from PTO I'll review state in the tester and
pass along anything else related.
Jeff
