public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/94147] mangling of lambdas in initializers is wrong
Date: Wed, 18 Mar 2020 12:17:10 +0000	[thread overview]
Message-ID: <bug-94147-4-ZF05ozUNq7@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-94147-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94147

--- Comment #1 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Nathan Sidwell <nathan@gcc.gnu.org>:

https://gcc.gnu.org/g:11cf25c40e3f586d19474108c78a2dfad7925902

commit r10-7243-g11cf25c40e3f586d19474108c78a2dfad7925902
Author: Nathan Sidwell <nathan@acm.org>
Date:   Wed Mar 18 05:16:28 2020 -0700

    PR c++/94147 - mangling of lambdas assigned to globals

    This patch implements Jason's suggestion of pushing a lambda scope
    when parsing a global variable initializer.  That bit worked fine, but
    happened to cause g++.dg/opt/dump1.C to not give any
    used-but-not-defined warnings.

    The reason was no_linkage_check, which considers any lambda that has
    an extra-scope to have linkage.  Which is technically correct.  Except
    that we think that all types that have linkage have external linkage.

    Our representation of linkage and visibility is somewhat inaccurate,
    particularly when it comes to types.  We have TREE_PUBLIC,
    DECL_EXTERNAL, DECL_VISIBILITY, DECL_COMDAT, DECL_NOT_REALLY_EXTERN.
    It could really do with a through cleanup, but that won't be a simple
    task.

    The best I could come up with was seeing if the extra scope was a
    VAR_DECL, and if that was TREE_PUBLIC and the var was inline (its
    COMDATness is sadly not set at that point) or a template
    instantiation, then the lambda had linkage.  Otherwise it's as-if it
    has no-linkage from the POV of compiler internals.

    This is an ABI change (so we should document it), but it's changing
    mangling from an unpredictable (in practice) counter, to something the
    ABI defines.  So I'm not concerned about mangling-changed warnings, or
    preserving the broken mangling under some ABI selection flag.  Code
    that did this worked by accident within a single TU.  It'll continue
    to work by design there, and across TUs.

            * parser.c (cp_parser_init_declarator): Namespace-scope variables
            provide a lambda scope.
            * tree.c (no_linkage_check): Lambdas with a variable for extra
            scope have a linkage from the variable.

  parent reply	other threads:[~2020-03-18 12:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-11 16:33 [Bug c++/94147] New: " nathan at gcc dot gnu.org
2020-03-11 16:33 ` [Bug c++/94147] " nathan at gcc dot gnu.org
2020-03-18 12:17 ` cvs-commit at gcc dot gnu.org [this message]
2020-03-18 12:17 ` nathan at gcc dot gnu.org
2022-11-28 22:29 ` pinskia at gcc dot gnu.org

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=bug-94147-4-ZF05ozUNq7@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).