This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Disable guality tests for powerpc*-linux*
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, David Edelsohn <dje dot gcc at gmail dot com>
- Date: Wed, 30 Mar 2016 09:28:03 +0200
- Subject: Re: [PATCH] Disable guality tests for powerpc*-linux*
- Authentication-results: sourceware.org; auth=none
- References: <1459211926 dot 12955 dot 37 dot camel at oc8801110288 dot ibm dot com> <20160329065325 dot GK3017 at tucnak dot redhat dot com> <1459257579 dot 12955 dot 59 dot camel at oc8801110288 dot ibm dot com> <20160329153308 dot GL3017 at tucnak dot redhat dot com> <1459270880 dot 12955 dot 78 dot camel at oc8801110288 dot ibm dot com> <20160329171637 dot GN3017 at tucnak dot redhat dot com>
On Tue, Mar 29, 2016 at 7:16 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Mar 29, 2016 at 12:01:20PM -0500, Bill Schmidt wrote:
>> Again, this is good information to know about. But the "stuff" we were
>> talking about was the failures on powerpc*, and I took what you said to
>> mean that nobody was working on those. It sounds like you're saying
>> that the community has spent time on debug improvements for optimized
>> code on x86_64/i?86, but only for that target. Is that a fair
>> statement? If so, it seems unsurprising that you would get more bug
>
> Well, most of the analysis has been done on x86_64/i?86. The bug fixes,
> DWARF enhancements etc. were then in various areas, if something has been
> improved through some GIMPLE change, then likely all targets benefited,
> if it was something at the RTL level (or var-tracking pass itself), then
> it really depends on the various properties of the machine descriptions,
> argument passing etc.
> I'm not saying it is possible to have all the guality tests pass at all
> optimization levels on all targets, sometimes the value of some variable
> is really lost through optimizations and can't be reconstructed in any way,
> sometimes it is too costly to track it, etc.
> In other cases we have yet to create new DWARF extensions, known stuff is
> e.g. debugging vectorized loops, what kind of user experience we want for
> users if single set of instructions handles multiple iterations of the loop?
> Do we want user to think he is seeing e.g. the first iteration, then the
> fifth one, then ninth etc., or provide enough info for the debuggers so that
> the user could find out he is in vectorized loop and explicitly request
> he is e.g. interested in the 3rd iteration instead of 1st?
> Then there will be certainly cases where even without adding any extensions
> one can just add some smarts to var-tracking, or change other GCC internals
> to handle some stuff better.
Yes, I think we _do_ need some dg-effective-target stuff for guality
as some tests
currently fail on arm (IIRC, I've only once did some non-x86 digging
into guality fails)
because of ABI issues that make a middle-end debuginfo fix incomplete (or
impossible, don't remember).
For powerpc somebody needs to look at a few regressions towards x86_64 and
see if there's a similar pattern - adding arch specific xfails (or
adding effective
targets) is a good way to make progress as well.
Hell, even slapping a xfail powerpc*-*-* on all current ppc FAILs
would be better
than simply disabling all of guality for ppc.
Richard.
> Jakub