PR81703 and Martin's fix for PR83501

[Prathamesh Kulkarni]

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 ?

Thanks,
Prathamesh
>
> Martin
>