This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Unbreak ia64 bootstrap (PR debug/45006)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Richard Guenther <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 20 Jul 2010 20:35:05 +0200
- Subject: Re: [PATCH] Unbreak ia64 bootstrap (PR debug/45006)
- References: <20100720163614.GF19172@tyan-ft48-01.lab.bos.redhat.com> <4C45E313.email@example.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Jul 20, 2010 at 10:55:31AM -0700, Richard Henderson wrote:
> On 07/20/2010 09:36 AM, Jakub Jelinek wrote:
> > 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.
> How do the two modes get installed? Because, really, these two should
> match. That this isn't the case doesn't make sense in the type model.
TYPE_MODE in layout_type:
SET_TYPE_MODE (type, mode_for_size (FUNCTION_BOUNDARY, MODE_INT, 0));
and DECL_MODE in make_node_stat:
if (code == FUNCTION_DECL)
DECL_ALIGN (t) = FUNCTION_BOUNDARY;
DECL_MODE (t) = FUNCTION_MODE;
> > 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.
> &function on ia64 may be resolved by ld.so. I don't know if there's
> anything particularly useful we could install here in the debug section.
With the patch it emits
data8.ua .LVL18-.Ltext0 // Location list begin address (*.LLST8)
data8.ua .LVL24-.Ltext0 // Location list end address (*.LLST8)
data2.ua 0xa // Location expression size
data1 0x3 // DW_OP_addr
data1 0x9f // DW_OP_stack_value
data8.ua 0 // Location list terminator begin (*.LLST8)
data8.ua 0 // Location list terminator end (*.LLST8)
(for __func parameter of __gthread_once inline). If you want, I can leave
that first hunk of the patch out, so it will provide anything on ia64 again.
Or should we return NULL for ADDR_EXPR of FUNCTION_DECL in expand_debug_expr
on fndesc targets right away? Not sure if we have any macro for them
> > @@ -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);
> This bit certainly is ok. We obviously don't want to look through
> TREE_OPERAND when it isn't present.