This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix wrong-debug with i?86/x86_64 _GLOBAL_OFFSET_TABLE_ (PR debug/82630)
- From: Richard Biener <rguenther at suse dot de>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Uros Bizjak <ubizjak at gmail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 23 Oct 2017 10:04:35 +0200 (CEST)
- Subject: Re: [PATCH] Fix wrong-debug with i?86/x86_64 _GLOBAL_OFFSET_TABLE_ (PR debug/82630)
- Authentication-results: sourceware.org; auth=none
- References: <20171023072214.GZ14653@tucnak> <alpine.LSU.2.20.1710230948300.8202@zhemvz.fhfr.qr> <20171023080030.GB14653@tucnak>
On Mon, 23 Oct 2017, Jakub Jelinek wrote:
> On Mon, Oct 23, 2017 at 09:48:50AM +0200, Richard Biener wrote:
> > > --- gcc/targhooks.c.jj 2017-10-13 19:02:08.000000000 +0200
> > > +++ gcc/targhooks.c 2017-10-20 14:26:07.945464025 +0200
> > > @@ -177,6 +177,14 @@ default_legitimize_address_displacement
> > > return false;
> > > }
> > >
> > > +bool
> > > +default_const_not_ok_for_debug_p (rtx x)
> > > +{
> > > + if (GET_CODE (x) == UNSPEC)
> >
> > What about UNSPEC_VOLATILE?
>
> This hook is called on the argument of CONST or SYMBOL_REF.
> UNSPEC_VOLATILE can't appear inside of CONST, it wouldn't be CONST then.
>
> UNSPEC appearing outside of CONST is rejected unconditionally in
> mem_loc_descriptor:
> ...
> case UNSPEC:
> ...
> /* If delegitimize_address couldn't do anything with the UNSPEC, we
> can't express it in the debug info. This can happen e.g. with some
> TLS UNSPECs. */
> break;
> and for UNSPEC_VOLATILE we just ICE, because var-tracking shouldn't let
> those through:
> default:
> if (flag_checking)
> {
> print_rtl (stderr, rtl);
> gcc_unreachable ();
> }
> break;
Ok. The patch looks fine from a middle-end point of view.
Thanks,
Richard.