public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: gcc-patches List <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Emit DWARF5 DW_AT_reference and DW_AT_rvalue_reference
Date: Mon, 24 Oct 2016 19:09:00 -0000	[thread overview]
Message-ID: <20161024190938.GU7282@tucnak.redhat.com> (raw)
In-Reply-To: <CADzB+2=iAi4awAqZGFABCOJOtDSyPjoKK8vgQYeYjihxF-BMRw@mail.gmail.com>

On Mon, Oct 24, 2016 at 02:34:04PM -0400, Jason Merrill wrote:
> On Mon, Oct 24, 2016 at 10:29 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> > This is another addition in DWARF5.  The patch emits these attributes
> > only for DW_TAG_subprogram for non-static ref-qualified member functions.
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> OK.

Thanks, committed.

> > We really should emit it also for DW_TAG_subroutine_type for PMF types,
> > the problem is that for FUNCTION_TYPE/METHOD_TYPE, dwarf2out.c uses
> > type_main_variant and get_qualified_type, neither of them understand
> > ref-qualifies.  I think we'd need to change get_qualified_type to use
> > some lang-hook which for C++ would also check the ref qualifiers, and then
> > for these two avoid type_main_variant and instead use get_qualified_type
> > to get the non-const/volatile/restrict etc. qualified one (and only then
> > we can use the decl_dwarf_attribute langhook to ask the FE whether the
> > attribute should be emitted).  Does that make sense, or do you have another
> > approach?
> 
> Can we pull out the ref-qualifier before we clobber the qualifiers on the type?

We could handle it like "reverse" flag, basically replace bool reverse with
int that would hold bitmask of the flags, but I really don't understand how
the reverse flag works right now, I don't see how it can work reliably when
we use and rely on equate_type_number_to_die/lookup_type_die mechanism where
we store just a single DIE for each type.  We either equate it to a type
with DW_AT_endianity present, or not, and then the rest of the lookups will
be just random.  I'm afraid to make it work reliably we'd need to somehow
store both the "reverse" and "!reverse" DIEs for each type DIE, and
similarly for the & and && flags.

Or by changing get_qualified_die (in particular check_base_type) to use a
langhook, we could at least for DW_AT_{reference,rvalue_reference} just use
equate_type_number_to_die/lookup_type_die reliably (DW_AT_endianity issue
remains).

	Jakub

  reply	other threads:[~2016-10-24 19:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-24 14:29 Jakub Jelinek
2016-10-24 18:34 ` Jason Merrill
2016-10-24 19:09   ` Jakub Jelinek [this message]
2016-10-31 13:56     ` Jason Merrill
2016-11-01 13:56       ` Jakub Jelinek
2016-11-01 18:05         ` Jason Merrill
2016-11-01 18:44           ` Jason Merrill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161024190938.GU7282@tucnak.redhat.com \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).