public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Eric Botcazou <ebotcazou@adacore.com>
To: gcc-patches@gcc.gnu.org
Subject: [patch] Fix PR lto/48492 (partially)
Date: Mon, 18 Apr 2011 00:50:00 -0000	[thread overview]
Message-ID: <201104180056.51119.ebotcazou@adacore.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]

Hi,

this (partially) fixes the LTO bootstrap failure with Ada enabled on the 
mainline.  The problem is an ICE whose origin is as follows:
  1. during LTO stage, copy-prop eliminates a DECL_IN_CONSTANT_POOL variable
from the GIMPLE IR, except for a reference in a GIMPLE_DEBUG statement
(ADDR_EXPR of the variable is the debug value),
  2. the variable is streamed out in the object file, as well as its associated
varpool entry,
  3. during WPA stage, both are streamed in, then reachability analysis is run
and computes that the variable is unreachable so removes the varpool entry.
As a consequence, when the variable is streamed out again, its initializer gets
replaced with ERROR_MARK.
  4. during LTRANS stage, the variable is again streamed in, with ERROR_MARK as
initializer and this blows up when the GIMPLE_DEBUG statement is processed.

So the root problem is in the reachability analysis during the WPA stage but, 
as pointed out by Jakub, this is so by design for GIMPLE_DEBUG statements.

There are already cases for which expand_debug_expr simply gives up:

    case VAR_DECL:
    case PARM_DECL:
    case FUNCTION_DECL:
    case LABEL_DECL:
    case CONST_DECL:
    case RESULT_DECL:
      op0 = DECL_RTL_IF_SET (exp);

      /* This decl was probably optimized away.  */
      if (!op0)
	{
	  if (TREE_CODE (exp) != VAR_DECL
	      || DECL_EXTERNAL (exp)
	      || !TREE_STATIC (exp)
	      || !DECL_NAME (exp)
	      || DECL_HARD_REGISTER (exp)
	      || DECL_IN_CONSTANT_POOL (exp)
	      || mode == VOIDmode)
	    return NULL;

the attached patch adds DECL_IN_CONSTANT_POOL to them.  This makes it possible 
to eliminate the ICE (but LTO bootstrap still fails because of an unrelated 
ICE in dwarf2out.c later).  OK for the mainline?


2011-04-17  Eric Botcazou  <ebotcazou@adacore.com>

	PR lto/48492
	* cfgexpand.c (expand_debug_expr) <VAR_DECL>: Return NULL for a
	DECL_IN_CONSTANT_POOL without RTL.


-- 
Eric Botcazou

[-- Attachment #2: p.diff --]
[-- Type: text/x-diff, Size: 386 bytes --]

Index: cfgexpand.c
===================================================================
--- cfgexpand.c	(revision 172617)
+++ cfgexpand.c	(working copy)
@@ -2495,6 +2495,7 @@ expand_debug_expr (tree exp)
 	      || !TREE_STATIC (exp)
 	      || !DECL_NAME (exp)
 	      || DECL_HARD_REGISTER (exp)
+	      || DECL_IN_CONSTANT_POOL (exp)
 	      || mode == VOIDmode)
 	    return NULL;
 

             reply	other threads:[~2011-04-17 22:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-18  0:50 Eric Botcazou [this message]
2011-04-18  9:39 ` Richard Guenther

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=201104180056.51119.ebotcazou@adacore.com \
    --to=ebotcazou@adacore.com \
    --cc=gcc-patches@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).