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.
Jakub
