On 12 January 2018 at 23:25, Jakub Jelinek <ja...@redhat.com> wrote:
> On Fri, Jan 12, 2018 at 10:38:39AM -0700, Jeff Law wrote:
>> >>> 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.
>
> Just please test with
> RUNTESTFLAGS='--target_board=unix\{-m64,-m32,-m32/-mno-sse\}
> dg.exp=strlenopt-*.c'
> and restrict to { i?86-*-* x86_64-*-* }, e.g. on Solaris it is i?86-*-*
> canonical target, even when it supports -m64 multilib.
> If you need x86_64 64-bit, that would be { { i?86-*-* x86_64-*-* } && lp64 }
> or ! ia32, depending on if -mx32 works or not.
Thanks, committed in r256657 after verifying that -m32 works.
Thanks,
Prathamesh
>
> Jakub
