From: Richard Biener <rguenther@suse.de>
To: gcc-patches@gcc.gnu.org
Cc: fortran@gcc.gnu.org, Jakub Jelinek <jakub@redhat.com>
Subject: [PATCH] Fix PR86321
Date: Fri, 29 Jun 2018 02:37:00 -0000 [thread overview]
Message-ID: <alpine.LSU.2.20.1806281108340.5043@zhemvz.fhfr.qr> (raw)
The fortran FE creates array descriptor types via build_distinct_type_copy
which ends up re-using the TYPE_FIELDs chain of FIELD_DECLs between
types in different type-variant chains. While that seems harmless
in practice it breaks once we try to generate C-like debug info for
it because dwarf2out doesn't expect such sharing to occur (and I
wouldn't be surprised of other odd behavior elsewhere that simply
doesn't manifest in a as fatal way as PR86321).
We generate C-like debug info when you use LTO and -g0 at compile-time
and -g at link-time (that's the way targets w/o debug-copy implementation
end up wired). For non-LTO we avoid directly generating debug for
the array descriptor types by detecting them via a langhook.
The solution seems to be to adhere to the invariant that TYPE_FIELDs
(and thus FIELD_DECL) sharing is only valid between variant types
and their main variant. Thus, copy the chain.
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
I suppose verify_type () could check proper ownership of the
FIELD_DECLs (simply verify that DECL_CONTEXT is TYPE_MAIN_VARIANT).
But I guess this may break in different ways. Honza - did you
originally try to verify that? It currently says
for (tree fld = TYPE_FIELDS (t); fld; fld = TREE_CHAIN (fld))
{
/* TODO: verify properties of decls. */
if (TREE_CODE (fld) == FIELD_DECL)
;
...
OK for trunk?
Thanks,
Richard.
2018-06-28 Richard Biener <rguenther@suse.de>
fortran/
PR lto/86321
* trans-types.c (gfc_get_array_type_bounds): Unshare TYPE_FIELDs
for the distinct type copy.
Index: gcc/fortran/trans-types.c
===================================================================
--- gcc/fortran/trans-types.c (revision 262132)
+++ gcc/fortran/trans-types.c (working copy)
@@ -1923,6 +1923,14 @@ gfc_get_array_type_bounds (tree etype, i
base_type = gfc_get_array_descriptor_base (dimen, codimen, restricted);
fat_type = build_distinct_type_copy (base_type);
+ /* Unshare TYPE_FIELDs. */
+ for (tree *tp = &TYPE_FIELDS (fat_type); *tp; tp = &DECL_CHAIN (*tp))
+ {
+ tree next = DECL_CHAIN (*tp);
+ *tp = copy_node (*tp);
+ DECL_CONTEXT (*tp) = fat_type;
+ DECL_CHAIN (*tp) = next;
+ }
/* Make sure that nontarget and target array type have the same canonical
type (and same stub decl for debug info). */
base_type = gfc_get_array_descriptor_base (dimen, codimen, false);
next reply other threads:[~2018-06-28 19:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-29 2:37 Richard Biener [this message]
2018-06-29 20:08 ` Janne Blomqvist
2018-06-29 18:45 Dominique d'Humières
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=alpine.LSU.2.20.1806281108340.5043@zhemvz.fhfr.qr \
--to=rguenther@suse.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@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).