public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
Date: Tue, 04 Dec 2012 15:11:00 -0000	[thread overview]
Message-ID: <bug-55395-4-B6kY9bNTBX@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-55395-4@http.gcc.gnu.org/bugzilla/>


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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-04 15:10:00 UTC ---
(In reply to comment #8)
> OK, the aim was mostly to get rid of large constructors. Is it possible to tell
> when the DECL_INITIAL will be needed?  This problem also exists with LTO where > we do not stream initializers of variables not assigned to a given partition.

It is always used if available and there is no other way to generate the
location info for it (which for vars that were removed from the varpool is
probably always, I bet those aren't assigned memory locations).  The question
is of course if it can successfully generate something out of it or not, but
you can't guess that before it tried.
For the invalid error part of this PR, it would be just important that it
doesn't set DECL_INITIAL to error_mark_node, but some other magic value which
says, this decl had non-zero initializer, but ignore the other details about
it.  Of course to make the debug info more complete you really should keep the
initializer.
Aren't you building mozilla with LTO without -g anyway, given that LTO screws
up debug info so terribly that it isn't useful at all?
Can you come up with some short testcase that would show what kind of large
constructors you care about?


  parent reply	other threads:[~2012-12-04 15:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-19 17:38 [Bug fortran/55395] New: [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu doko at gcc dot gnu.org
2012-11-19 23:02 ` [Bug fortran/55395] " doko at gcc dot gnu.org
2012-11-19 23:10 ` [Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi burnus at gcc dot gnu.org
2012-11-21  4:08 ` doko at gcc dot gnu.org
2012-11-21  4:10 ` pinskia at gcc dot gnu.org
2012-11-21  4:14 ` pinskia at gcc dot gnu.org
2012-11-21  4:19 ` doko at gcc dot gnu.org
2012-11-25 15:52 ` rguenth at gcc dot gnu.org
2012-12-04 10:14 ` jakub at gcc dot gnu.org
2012-12-04 14:47 ` hubicka at ucw dot cz
2012-12-04 15:11 ` jakub at gcc dot gnu.org [this message]
2012-12-04 16:26 ` hubicka at ucw dot cz
2012-12-04 16:42 ` jakub at gcc dot gnu.org
2012-12-06 13:52 ` jakub at gcc dot gnu.org
2012-12-06 20:35 ` jakub at gcc dot gnu.org
2012-12-07  0:02 ` jakub at gcc dot gnu.org
2012-12-07 16:05 ` jakub at gcc dot gnu.org
2012-12-10 20:32 ` jakub 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-55395-4-B6kY9bNTBX@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).