public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/50640] [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03  -O  (internal compiler error)
Date: Fri, 07 Oct 2011 19:00:00 -0000	[thread overview]
Message-ID: <bug-50640-4-1Wip2mtHkV@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-50640-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-10-07 18:59:26 UTC ---
(In reply to comment #6)
> (In reply to comment #3)
> > Hmm, this is not as trivial as PR50638.  fortran frontend generates this
> > static variable local to MAIN:
> > 
> > static struct __vtype_MAIN___T1 __vtab_MAIN___T1 = {._hash=41707971, ._size=4,
> > ._extends=0B, ._def_init=&__def_init_MAIN___T1, ._copy=__copy_MAIN___T1};
> > 
> > (the reference to &__def_init_MAIN___T1 will later cause the segfault).
> > __vtab_MAIN___T1  will be referenced from __vtab_MAIN___T2 (also static local
> > in MAIN).  But __vtab_MAIN___T2 will _not_ be referenced from MAIN.
> > 
> > Instead references to __vtab_MAIN___T2 and __vtab_MAIN___T1 are emitted from
> > function 'fun'.  So far so good.  The problem lies in walking DECL_INITIAL
> > for these statics.  add_referenced_var will only walk it if
> > DECL_CONTEXT==current_function_decl (sensible).  Nobody calls
> > add_rerefenced_var(__vtab_MAIN___T1) for function MAIN (sensible, as there
> > are no references).
> > 
> > We will call add_rerefenced_var(__vtab_MAIN___T1) from function 'fun' (also
> > sane), which then won't walk DECL_INITIAL, i.e. nobody makes
> > __def_init_MAIN___T1 referenced.
> > 
> > The the code in tree-ssa-live comes and walks initializers of local variables
> > that are used.  It does so for function MAIN and variable __vtab_MAIN___T
> > (which is in local_decls, just not in referenced_vars), because it is marked
> > used (it's a non-local decl, therefore var_ann is still active from the calls
> > from function 'fun').  That one then walks the initializer and now notices
> > that nothing in it is marked referenced.
> > 
> > The non-triviality here lies in deciding who's wrong: add_referenced_var
> > (i.e. should it always mark referenced all initializers, even though they
> > might come from other function contexts), the tree-ssa-live code (should
> > it perhaps not look into initializers or at least expect them not necessarily
> > marked), or in the fortran frontend (should it perhaps call add_referenced_var
> > also for the local static in MAIN).
> 
> Huh, I don't see why tree-ssa-live would need to walk variable initializers
> (which generally don't exist unless for static storage duration vars).

Possibly for

void foo (void)
{
  static int i;
  static int *p = &i;
  return *p;
}

to make i used and thus retained in BLOCK_VARS and thus debuginfo.


  parent reply	other threads:[~2011-10-07 19:00 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-06 21:21 [Bug middle-end/50640] New: " dominiq at lps dot ens.fr
2011-10-06 21:38 ` [Bug middle-end/50640] " dominiq at lps dot ens.fr
2011-10-07  8:32 ` rguenth at gcc dot gnu.org
2011-10-07 16:15 ` dominiq at lps dot ens.fr
2011-10-07 16:46 ` matz at gcc dot gnu.org
2011-10-07 16:51 ` matz at gcc dot gnu.org
2011-10-07 16:58 ` burnus at gcc dot gnu.org
2011-10-07 18:54 ` rguenth at gcc dot gnu.org
2011-10-07 19:00 ` rguenth at gcc dot gnu.org [this message]
2011-10-10 15:29 ` rguenth at gcc dot gnu.org
2011-10-15  8:48 ` hp at gcc dot gnu.org
2011-10-15  9:14 ` janus at gcc dot gnu.org
2011-11-06 14:13 ` hp at gcc dot gnu.org
2011-11-06 17:08 ` tkoenig at gcc dot gnu.org
2011-11-06 17:21 ` dominiq at lps dot ens.fr
2011-11-06 17:48 ` hp at gcc dot gnu.org
2011-11-06 18:17 ` janus at gcc dot gnu.org
2011-11-06 19:22 ` dominiq at lps dot ens.fr
2011-11-06 19:43 ` burnus at gcc dot gnu.org
2011-11-06 20:04 ` hp at gcc dot gnu.org
2011-11-07  8:12 ` burnus at gcc dot gnu.org
2011-11-07 11:02 ` paul.richard.thomas at gmail dot com
2011-11-07 16:25 ` burnus at gcc dot gnu.org
2011-11-07 16:28 ` burnus at gcc dot gnu.org
2011-11-09 10:37 ` burnus at gcc dot gnu.org
2011-11-10 11:12 ` paul.richard.thomas at gmail dot com
2011-11-19  9:33 ` [Bug fortran/50640] [4.7 Regression] [OOP] " burnus at gcc dot gnu.org
2011-11-19 10:32 ` burnus at gcc dot gnu.org
2012-09-11 13:46 ` burnus 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-50640-4-1Wip2mtHkV@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).