This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR81703 and Martin's fix for PR83501


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.

Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]