Re: PR81703 and Martin's fix for PR83501

[Jeff Law <law at redhat dot com>]

On 01/12/2018 09:23 AM, Martin Sebor wrote:
> On 01/11/2018 11:44 PM, Prathamesh Kulkarni wrote:
>> On 12 January 2018 at 06:15, Martin Sebor <msebor@gmail.com> wrote:
>>> On 01/11/2018 02:48 PM, Rainer Orth wrote:
>>>>
>>>> Hi Martin,
>>>>
>>>>>> I am not sure why constant string is not emitted for
>>>>>> arm-linux-gnueabihf
>>>>>> ?
>>>>>> As far as this issue is concerned, should I simply XFAIL it on arm
>>>>>> for
>>>>>> now ?
>>>>>
>>>>>
>>>>> This is not unique to the arm back end but affects other targets
>>>>> as well, including powerpc64.  There's a bug open (PR 83462) for
>>>>> one of the tests I recently added with the same root cause:
>>>>> a case not being handled by the strlen pass.  I'm tracking this
>>>>> missed optimization in PR 83543.   I would expect handling it
>>>>> to be fairly easy but it seems that every I think that it turns
>>>>> out to be anything but.  Either way, either fixing 83543 or
>>>>> marking this failure (and those in PR 83462) XFAIL until it
>>>>> the optimization is added should work.
>>>>
>>>>
>>>> I'm seeing the same failure on sparc*-sun-solaris*, and gcc-testresults
>>>> shows it on mips64el-unknown-linux-gnu and powerpc-ibm-aix7.2.0.0, too.
>>>> XFAILing may become unwieldly if more targets are affected.
>>>
>>>
>>> Thanks for pointing it out.  I see it there as well with
>>> Prathamesh's test case, though not with the test case in
>>> bug 83543.  It is the same root cause in both.  I agree
>>> that enhancing the strlen pass to handle this case would
>>> be preferable to just xfailing the test.  I'm just not
>>> sure it's possible before stage 3 closes.  If not, I'll
>>> work on it in GCC 9.  Although the details are target-
>>> specific, the limitation affects all targets and so
>>> having a solution will benefit all all of them.
>> Indeed, however for now I am not sure what would be the best approach ?
>> If the test-case starts failing for many targets, not sure if XFAIL
>> would be the right choice.
>> Should I just restrict it to x86_64 target for now ?
> 
> That sounds like a good approach in the interim, until we have
> a general solution.  It will avoid having to maintain a list
> of targets where it's known to fail.
Agreed and pre-approved.
jeff