From: Jakub Jelinek <jakub@redhat.com>
To: Richard Guenther <rguenther@suse.de>
Cc: gcc-patches@gcc.gnu.org
Subject: [PATCH] Unbreak ia64 bootstrap (PR debug/45006)
Date: Tue, 20 Jul 2010 16:34:00 -0000 [thread overview]
Message-ID: <20100720163614.GF19172@tyan-ft48-01.lab.bos.redhat.com> (raw)
Hi!
My PR45003 fix apparently broke IA-64 bootstrap, because there
FUNCTION_DECLs have DECL_MODE DImode, while TYPE_MODE of FUNCTION_TYPE
is TImode. Guess that's related to fn descriptors.
The following patch is an attempt to fix that. For FUNCTION_DECLs,
I don't see how SIGN_EXTEND/ZERO_EXTEND on the MEM would be ever useful,
FUNCTION_DECLs ought to appear in DEBUG stmts only inside of ADDR_EXPR
where the MEM is not used anyway and we just use the address.
The adjust_mode path isn't hit just for unary expressions
(PAREN_EXPR/NOP_EXPR/CONVERT_EXPR), but also for decls and SSA_NAMEs.
The latter ones of course don't have TREE_OPERAND (exp, 0), while usually
the modes ought to match, it is IMHO better to try to be cautious.
Either of the hunks should fix the ICE, though without the first hunk
we just won't be able to emit useful debug info (as ADDR_EXPR <FUNCTION_DECL>
will return NULL on ia64 then), and without the second hunk we risk we hit
similar ICE later on.
Ok for trunk?
2010-07-20 Jakub Jelinek <jakub@redhat.com>
PR debug/45006
* cfgexpand.c (expand_debug_expr): Don't go through adjust_mode
path for FUNCTION_DECLs. Only look at TYPE_UNSIGNED of
operand's type if exp is tcc_unary class tree.
--- gcc/cfgexpand.c.jj 2010-07-20 12:12:14.000000000 +0200
+++ gcc/cfgexpand.c 2010-07-20 18:06:13.000000000 +0200
@@ -2369,7 +2369,10 @@ expand_debug_expr (tree exp)
below would ICE. While it is likely a FE bug,
try to be robust here. See PR43166. */
|| mode == BLKmode
- || (mode == VOIDmode && GET_MODE (op0) != VOIDmode))
+ || (mode == VOIDmode && GET_MODE (op0) != VOIDmode)
+ /* On some targets DECL_MODE of a FUNCTION_DECL is
+ different from TYPE_MODE of its type. */
+ || (TREE_CODE (exp) == FUNCTION_DECL && MEM_P (op0)))
{
gcc_assert (MEM_P (op0));
op0 = adjust_address_nv (op0, mode, 0);
@@ -2427,7 +2430,9 @@ expand_debug_expr (tree exp)
op0 = simplify_gen_subreg (mode, op0, inner_mode,
subreg_lowpart_offset (mode,
inner_mode));
- else if (TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (exp, 0))))
+ else if (TREE_CODE_CLASS (TREE_CODE (exp)) == tcc_unary
+ ? TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (exp, 0)))
+ : unsignedp)
op0 = gen_rtx_ZERO_EXTEND (mode, op0);
else
op0 = gen_rtx_SIGN_EXTEND (mode, op0);
Jakub
next reply other threads:[~2010-07-20 16:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-20 16:34 Jakub Jelinek [this message]
2010-07-20 17:55 ` Richard Henderson
2010-07-20 18:33 ` Jakub Jelinek
2010-07-20 20:11 ` Richard Henderson
2010-07-21 9:45 ` Jakub Jelinek
2010-07-20 21:59 ` cris-elf still broken with "[PATCH] Unbreak ia64 bootstrap (PR debug/45006)" Hans-Peter Nilsson
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=20100720163614.GF19172@tyan-ft48-01.lab.bos.redhat.com \
--to=jakub@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rguenther@suse.de \
/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).