[Bug target/47727] New: [x32] internal compiler error: Segmentation fault

[Bug target/47727] New: [x32] internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

           Summary: [x32] internal compiler error: Segmentation fault
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hjl.tools@gmail.com


[hjl@gnu-6 ilp32-14]$ cat c.i
typedef void (*func_ptr) (void);
static func_ptr __CTOR_END__[1]
  __attribute__((section(".ctors"), aligned(sizeof(func_ptr))))
  = { (func_ptr) 0 };
static void __attribute__((used))
__do_global_ctors_aux (void)
{
  func_ptr *p;
  for (p = __CTOR_END__ - 1; *p != (func_ptr) -1; p--)
    (*p) ();
}
[hjl@gnu-6 ilp32-14]$ make c.s
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o c.s -mx32 -O2 -g
-fPIC    c.i
c.i: In function \u2018__do_global_ctors_aux\u2019:
c.i:11:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [c.s] Error 1
[hjl@gnu-6 ilp32-14]$

[Bug target/47727] [x32] internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> 2011-02-14 03:36:51 UTC ---
Program received signal SIGSEGV, Segmentation fault.
0x0000000000599a9f in init_alias_analysis ()
    at /export/gnu/import/git/gcc-x32/gcc/alias.c:2863
2863              else if (DF_REG_DEF_COUNT (regno) == 1
(gdb) bt
#0  0x0000000000599a9f in init_alias_analysis ()
    at /export/gnu/import/git/gcc-x32/gcc/alias.c:2863
#1  0x00000000007e0407 in one_pre_gcse_pass ()
    at /export/gnu/import/git/gcc-x32/gcc/gcse.c:4141
#2  0x00000000007e2b95 in execute_rtl_pre ()
    at /export/gnu/import/git/gcc-x32/gcc/gcse.c:5346
#3  0x00000000008fad8f in execute_one_pass (pass=0x17a29e0)
    at /export/gnu/import/git/gcc-x32/gcc/passes.c:1561
#4  0x00000000008faf7e in execute_pass_list (pass=0x17a29e0)
    at /export/gnu/import/git/gcc-x32/gcc/passes.c:1616
#5  0x00000000008faf9f in execute_pass_list (pass=0x17a2fe0)
    at /export/gnu/import/git/gcc-x32/gcc/passes.c:1617
#6  0x0000000000a84ad0 in tree_rest_of_compilation (fndecl=0x7ffff0cddf00)
    at /export/gnu/import/git/gcc-x32/gcc/tree-optimize.c:422
#7  0x0000000000d26b86 in cgraph_expand_function (node=0x7ffff0ce2160)
    at /export/gnu/import/git/gcc-x32/gcc/cgraphunit.c:1570
#8  0x0000000000d26d45 in cgraph_expand_all_functions ()
    at /export/gnu/import/git/gcc-x32/gcc/cgraphunit.c:1629
#9  0x0000000000d273bc in cgraph_optimize ()
    at /export/gnu/import/git/gcc-x32/gcc/cgraphunit.c:1893
#10 0x0000000000d24ead in cgraph_finalize_compilation_unit ()
    at /export/gnu/import/git/gcc-x32/gcc/cgraphunit.c:1090
#11 0x00000000004ae5a4 in c_write_global_declarations ()
---Type <return> to continue, or q <return> to quit---
    at /export/gnu/import/git/gcc-x32/gcc/c-decl.c:9872
#12 0x00000000009f1632 in compile_file ()
    at /export/gnu/import/git/gcc-x32/gcc/toplev.c:591
#13 0x00000000009f37c2 in do_compile ()
    at /export/gnu/import/git/gcc-x32/gcc/toplev.c:1900
#14 0x00000000009f390f in toplev_main (argc=17, argv=0x7fffffffe2c8)
    at /export/gnu/import/git/gcc-x32/gcc/toplev.c:1963
#15 0x0000000000587744 in main (argc=17, argv=0x7fffffffe2c8)
    at /export/gnu/import/git/gcc-x32/gcc/main.c:36
(gdb)

[Bug target/47727] [x32] internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> 2011-02-14 03:53:52 UTC ---
cse1 generates:

;; Succ edge  EXIT [100.0%]  (fallthru)

;; Insn is not within a basic block
(insn 63 57 64 (set (reg:SI 100)
        (symbol_ref:SI ("__CTOR_END__") [flags 0x2]  <var_decl 0x7ffff0ced000
__CTOR_END__>)) -1
     (nil))

;; Insn is not within a basic block
(insn 64 63 65 (parallel [
            (set (reg:SI 99) 
                (plus:SI (reg:SI 100)
                    (const_int -4 [0xfffffffffffffffc])))
            (clobber (reg:CC 17 flags))
        ]) -1
     (nil))

;; Insn is not within a basic block
(insn 65 64 0 (set (reg:DI 98)
        (zero_extend:DI (reg:SI 99))) -1
     (nil))

This may lead to the DF problem.

[Bug target/47727] [x32] internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> 2011-02-14 05:18:23 UTC ---
(In reply to comment #2)
> cse1 generates:
> 
> ;; Succ edge  EXIT [100.0%]  (fallthru)
> 
> ;; Insn is not within a basic block
> (insn 63 57 64 (set (reg:SI 100)
>         (symbol_ref:SI ("__CTOR_END__") [flags 0x2]  <var_decl 0x7ffff0ced000
> __CTOR_END__>)) -1
>      (nil))
> 
> ;; Insn is not within a basic block
> (insn 64 63 65 (parallel [
>             (set (reg:SI 99) 
>                 (plus:SI (reg:SI 100)
>                     (const_int -4 [0xfffffffffffffffc])))
>             (clobber (reg:CC 17 flags))
>         ]) -1
>      (nil))
> 
> ;; Insn is not within a basic block
> (insn 65 64 0 (set (reg:DI 98)
>         (zero_extend:DI (reg:SI 99))) -1
>      (nil))
> 
> This may lead to the DF problem.

This is because cse_insn calls fold_rtx with

(gdb) call debug_rtx (x)
(zero_extend:DI (reg/f:SI 95))
(gdb) call debug_rtx (insn)
(insn 37 36 38 3 (set (reg/f:DI 94)
        (zero_extend:DI (reg/f:SI 95))) c.i:7 115 {*zero_extendsidi2_rex64}
     (nil))
(gdb)

It leads to

  switch (GET_RTX_CLASS (code))
    {    
    case RTX_UNARY:
      {    
        /* We can't simplify extension ops unless we know the
           original mode.  */
        if ((code == ZERO_EXTEND || code == SIGN_EXTEND)
            && mode_arg0 == VOIDmode)
          break;

        new_rtx = simplify_unary_operation (code, mode,
                                        const_arg0 ? const_arg0 : folded_arg0,
                                        mode_arg0);
      }                                      
      break;

Breakpoint 7, emit_insn (x=0x7ffff0d46900)
    at /export/gnu/import/git/gcc-x32/gcc/emit-rtl.c:4791
4791      rtx last = get_last_insn();
(gdb) bt
#0  emit_insn (x=0x7ffff0d46900)
    at /export/gnu/import/git/gcc-x32/gcc/emit-rtl.c:4791
#1  0x00000000006f0e87 in emit_move_insn_1 (x=0x7ffff0d42dc0, y=0x7ffff0d42b40)
    at /export/gnu/import/git/gcc-x32/gcc/expr.c:3305
#2  0x00000000006f125a in emit_move_insn (x=0x7ffff0d42dc0, y=0x7ffff0d42b40)
    at /export/gnu/import/git/gcc-x32/gcc/expr.c:3395
#3  0x00000000006d503e in copy_to_mode_reg (mode=SImode, x=0x7ffff0d42b40)
    at /export/gnu/import/git/gcc-x32/gcc/explow.c:637
#4  0x00000000008d9656 in expand_binop_directly (mode=SImode, 
    binoptab=0x1809e20, op0=0x7ffff0d42b40, op1=0x7ffff0dea430, 
    target=0x7ffff0d42da0, unsignedp=1, methods=OPTAB_LIB_WIDEN, 
    last=0x7ffff0cf1980) at /export/gnu/import/git/gcc-x32/gcc/optabs.c:1461
#5  0x00000000008d99c2 in expand_binop (mode=SImode, binoptab=0x1809e20, 
    op0=0x7ffff0d42b40, op1=0x7ffff0dea430, target=0x7ffff0d42da0, 
    unsignedp=1, methods=OPTAB_LIB_WIDEN)
    at /export/gnu/import/git/gcc-x32/gcc/optabs.c:1551
#6  0x00000000008d9185 in expand_simple_binop (mode=SImode, code=PLUS, 
    op0=0x7ffff0d42b40, op1=0x7ffff0dea430, target=0x7ffff0d42da0, 
    unsignedp=1, methods=OPTAB_LIB_WIDEN)
    at /export/gnu/import/git/gcc-x32/gcc/optabs.c:1295
#7  0x0000000000701383 in force_operand (value=0x7ffff0d473a8, 
    target=0x7ffff0d42da0) at /export/gnu/import/git/gcc-x32/gcc/expr.c:6452
#8  0x00000000006d4fed in copy_to_mode_reg (mode=SImode, x=0x7ffff0d473a8)
---Type <return> to continue, or q <return> to quit---
    at /export/gnu/import/git/gcc-x32/gcc/explow.c:633
#9  0x00000000008df8d7 in maybe_emit_unop_insn (icode=2221, 
    target=0x7ffff0d42d80, op0=0x7ffff0d473a8, code=ZERO_EXTEND)
    at /export/gnu/import/git/gcc-x32/gcc/optabs.c:3746
#10 0x00000000008dfa49 in emit_unop_insn (icode=2221, target=0x7ffff0d42d80, 
    op0=0x7ffff0d473a8, code=ZERO_EXTEND)
    at /export/gnu/import/git/gcc-x32/gcc/optabs.c:3776
#11 0x00000000006e9df4 in convert_move (to=0x7ffff0d42d80, 
    from=0x7ffff0d473a8, unsignedp=1)
    at /export/gnu/import/git/gcc-x32/gcc/expr.c:612
#12 0x00000000006ea5de in convert_modes (mode=DImode, oldmode=SImode, 
    x=0x7ffff0d473a8, unsignedp=1)
    at /export/gnu/import/git/gcc-x32/gcc/expr.c:791
#13 0x00000000006d4971 in convert_memory_address_addr_space (to_mode=DImode, 
    x=0x7ffff0d473a8, as=0 '\000')
    at /export/gnu/import/git/gcc-x32/gcc/explow.c:408
#14 0x00000000006d488d in convert_memory_address_addr_space (to_mode=DImode, 
    x=0x7ffff0d43d10, as=0 '\000')
    at /export/gnu/import/git/gcc-x32/gcc/explow.c:379
#15 0x00000000009bceb1 in simplify_unary_operation_1 (code=ZERO_EXTEND, 
    mode=DImode, op=0x7ffff0d43d10)
    at /export/gnu/import/git/gcc-x32/gcc/simplify-rtx.c:1111
#16 0x00000000009bafa8 in simplify_unary_operation (code=ZERO_EXTEND, 
---Type <return> to continue, or q <return> to quit---
    mode=DImode, op=0x7ffff0d43d10, op_mode=SImode)
    at /export/gnu/import/git/gcc-x32/gcc/simplify-rtx.c:526
#17 0x0000000001044375 in fold_rtx (x=0x7ffff0d43d20, insn=0x7ffff0d463f0)
    at /export/gnu/import/git/gcc-x32/gcc/cse.c:3350
#18 0x00000000010470f8 in cse_insn (insn=0x7ffff0d463f0)
    at /export/gnu/import/git/gcc-x32/gcc/cse.c:4501

It generates a bunch of orphaned instructions.

[Bug middle-end/47727] [x32] Many passes can't handle const symbol when Pmode != ptr_mode

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |middle-end
            Summary|[x32] internal compiler     |[x32] Many passes can't
                   |error: Segmentation fault   |handle const symbol when
                   |                            |Pmode != ptr_mode

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> 2011-02-14 06:16:04 UTC ---
Various passes can't handle

(insn 36 62 37 3 (set (reg/f:SI 95)
        (const:SI (plus:SI (symbol_ref:SI ("__CTOR_END__") [flags 0x2] 
<var_dec
l 0x7ffff0cf0000 __CTOR_END__>)
                (const_int -4 [0xfffffffffffffffc])))) c.i:7 64
{*movsi_internal
}
     (nil))

(insn 37 36 38 3 (set (reg/v/f:DI 93 [ p ])
        (zero_extend:DI (reg/f:SI 95))) c.i:7 115 {*zero_extendsidi2_rex64}
     (expr_list:REG_EQUAL (const:DI (reg:DI 98))
        (nil)))

properly when Pmode != ptr_mode. cse, cprop and combine do things
like

#0  emit_insn (x=0x7ffff0d46900)
    at /export/gnu/import/git/gcc-x32/gcc/emit-rtl.c:4791
#1  0x00000000006f0e87 in emit_move_insn_1 (x=0x7ffff0d42dc0, y=0x7ffff0d42b40)
    at /export/gnu/import/git/gcc-x32/gcc/expr.c:3305
#2  0x00000000006f125a in emit_move_insn (x=0x7ffff0d42dc0, y=0x7ffff0d42b40)
    at /export/gnu/import/git/gcc-x32/gcc/expr.c:3395
#3  0x00000000006d503e in copy_to_mode_reg (mode=SImode, x=0x7ffff0d42b40)
    at /export/gnu/import/git/gcc-x32/gcc/explow.c:637
#4  0x00000000008d9656 in expand_binop_directly (mode=SImode, 
    binoptab=0x1809e20, op0=0x7ffff0d42b40, op1=0x7ffff0dea430, 
    target=0x7ffff0d42da0, unsignedp=1, methods=OPTAB_LIB_WIDEN, 
    last=0x7ffff0cf1980) at /export/gnu/import/git/gcc-x32/gcc/optabs.c:1461
#5  0x00000000008d99c2 in expand_binop (mode=SImode, binoptab=0x1809e20, 
    op0=0x7ffff0d42b40, op1=0x7ffff0dea430, target=0x7ffff0d42da0, 
    unsignedp=1, methods=OPTAB_LIB_WIDEN)
    at /export/gnu/import/git/gcc-x32/gcc/optabs.c:1551
#6  0x00000000008d9185 in expand_simple_binop (mode=SImode, code=PLUS, 
    op0=0x7ffff0d42b40, op1=0x7ffff0dea430, target=0x7ffff0d42da0, 
    unsignedp=1, methods=OPTAB_LIB_WIDEN)
    at /export/gnu/import/git/gcc-x32/gcc/optabs.c:1295
#7  0x0000000000701383 in force_operand (value=0x7ffff0d473a8, 
    target=0x7ffff0d42da0) at /export/gnu/import/git/gcc-x32/gcc/expr.c:6452
#8  0x00000000006d4fed in copy_to_mode_reg (mode=SImode, x=0x7ffff0d473a8)
---Type <return> to continue, or q <return> to quit---
    at /export/gnu/import/git/gcc-x32/gcc/explow.c:633
#9  0x00000000008df8d7 in maybe_emit_unop_insn (icode=2221, 
    target=0x7ffff0d42d80, op0=0x7ffff0d473a8, code=ZERO_EXTEND)
    at /export/gnu/import/git/gcc-x32/gcc/optabs.c:3746
#10 0x00000000008dfa49 in emit_unop_insn (icode=2221, target=0x7ffff0d42d80, 
    op0=0x7ffff0d473a8, code=ZERO_EXTEND)
    at /export/gnu/import/git/gcc-x32/gcc/optabs.c:3776
#11 0x00000000006e9df4 in convert_move (to=0x7ffff0d42d80, 
    from=0x7ffff0d473a8, unsignedp=1)
    at /export/gnu/import/git/gcc-x32/gcc/expr.c:612
#12 0x00000000006ea5de in convert_modes (mode=DImode, oldmode=SImode, 
    x=0x7ffff0d473a8, unsignedp=1)
    at /export/gnu/import/git/gcc-x32/gcc/expr.c:791
#13 0x00000000006d4971 in convert_memory_address_addr_space (to_mode=DImode, 
    x=0x7ffff0d473a8, as=0 '\000')
    at /export/gnu/import/git/gcc-x32/gcc/explow.c:408
#14 0x00000000006d488d in convert_memory_address_addr_space (to_mode=DImode, 
    x=0x7ffff0d43d10, as=0 '\000')
    at /export/gnu/import/git/gcc-x32/gcc/explow.c:379
#15 0x00000000009bceb1 in simplify_unary_operation_1 (code=ZERO_EXTEND, 
    mode=DImode, op=0x7ffff0d43d10)
    at /export/gnu/import/git/gcc-x32/gcc/simplify-rtx.c:1111
#16 0x00000000009bafa8 in simplify_unary_operation (code=ZERO_EXTEND, 
---Type <return> to continue, or q <return> to quit---
    mode=DImode, op=0x7ffff0d43d10, op_mode=SImode)
    at /export/gnu/import/git/gcc-x32/gcc/simplify-rtx.c:526

But they are not prepared to deal with the new instruction
sequence nor new pseudo registers. Those passes should skip
them.

[Bug middle-end/47727] [x32] Many passes can't handle const symbol when Pmode != ptr_mode

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> 2011-02-14 13:51:27 UTC ---
Does this patch make any senses?

diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index ce4eab4..e7e7890 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -1099,10 +1099,13 @@ simplify_unary_operation_1 (enum rtx_code code, enum
mac
hine_mode mode, rtx op)
 #if defined(POINTERS_EXTEND_UNSIGNED) && !defined(HAVE_ptr_extend)
       /* As we do not know which address space the pointer is refering to,
      we can do this only if the target does not support different pointer
-     or address modes depending on the address space.  */
+     or address modes depending on the address space.  Since we will
+     generate new instructions, we must be currently emitting into a
+     sequence.  */
       if (target_default_pointer_address_modes_p ()
       && POINTERS_EXTEND_UNSIGNED > 0
       && mode == Pmode && GET_MODE (op) == ptr_mode
+      && in_sequence_p ()
       && (CONSTANT_P (op)
           || (GET_CODE (op) == SUBREG
           && REG_P (SUBREG_REG (op))

[Bug middle-end/47727] [x32] Many passes can't handle const symbol when Pmode != ptr_mode

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> 2011-02-14 14:21:32 UTC ---
On Mon, 14 Feb 2011, hjl.tools at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47727
> 
> --- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> 2011-02-14 13:51:27 UTC ---
> Does this patch make any senses?
> 
> diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
> index ce4eab4..e7e7890 100644
> --- a/gcc/simplify-rtx.c
> +++ b/gcc/simplify-rtx.c
> @@ -1099,10 +1099,13 @@ simplify_unary_operation_1 (enum rtx_code code, enum
> mac
> hine_mode mode, rtx op)
>  #if defined(POINTERS_EXTEND_UNSIGNED) && !defined(HAVE_ptr_extend)
>        /* As we do not know which address space the pointer is refering to,
>       we can do this only if the target does not support different pointer
> -     or address modes depending on the address space.  */
> +     or address modes depending on the address space.  Since we will
> +     generate new instructions, we must be currently emitting into a
> +     sequence.  */
>        if (target_default_pointer_address_modes_p ()
>        && POINTERS_EXTEND_UNSIGNED > 0
>        && mode == Pmode && GET_MODE (op) == ptr_mode
> +      && in_sequence_p ()
>        && (CONSTANT_P (op)
>            || (GET_CODE (op) == SUBREG
>            && REG_P (SUBREG_REG (op))

Not really.  simplify-rtx should never emit new instuctions.  Probably
Ulrich, when introducing address-spaces didn't properly think about
this in convert_memory_address_addr_space ().

Richard.

[Bug middle-end/47727] [x32] Many passes can't handle const symbol when Pmode != ptr_mode

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> 2011-02-14 14:34:30 UTC ---
(In reply to comment #6)
> Not really.  simplify-rtx should never emit new instuctions.  Probably
> Ulrich, when introducing address-spaces didn't properly think about
> this in convert_memory_address_addr_space ().
> 

I am not sure if that piece of code:

#if defined(POINTERS_EXTEND_UNSIGNED) && !defined(HAVE_ptr_extend)
      /* As we do not know which address space the pointer is refering to,
         we can do this only if the target does not support different pointer
         or address modes depending on the address space.  */
      if (target_default_pointer_address_modes_p ()
          && POINTERS_EXTEND_UNSIGNED > 0
          && mode == Pmode && GET_MODE (op) == ptr_mode
          && (CONSTANT_P (op)
              || (GET_CODE (op) == SUBREG
                  && REG_P (SUBREG_REG (op))
                  && REG_POINTER (SUBREG_REG (op))
                  && GET_MODE (SUBREG_REG (op)) == Pmode)))
        return convert_memory_address (Pmode, op);
#endif       

has ever worked before since convert_memory_address was there
before Ulrich added address-spaces. For x32, convert_memory_address
will generate new instructions when converting from SImode
to DImode. Should we simply remove them?

[Bug middle-end/47727] [x32] Many passes can't handle const symbol when Pmode != ptr_mode

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> 2011-02-14 17:24:56 UTC ---
The problem may be in convert_memory_address_addr_space:

    case PLUS:
    case MULT:
      /* For addition we can safely permute the conversion and addition
         operation if one operand is a constant and converting the constant
         does not change it or if one operand is a constant and we are
         using a ptr_extend instruction  (POINTERS_EXTEND_UNSIGNED < 0).
         We can always safely permute them if we are making the address
         narrower.  */
      if (GET_MODE_SIZE (to_mode) < GET_MODE_SIZE (from_mode)
          || (GET_CODE (x) == PLUS 
              && CONST_INT_P (XEXP (x, 1))
              && (XEXP (x, 1) == convert_memory_address_addr_space
                                   (to_mode, XEXP (x, 1), as)
                 || POINTERS_EXTEND_UNSIGNED < 0))) 
        return gen_rtx_fmt_ee (GET_CODE (x), to_mode,
                               convert_memory_address_addr_space
                                 (to_mode, XEXP (x, 0), as), 
                               XEXP (x, 1)); 


It will generate new instructions for

(plus:SI (symbol_ref:SI ("__CTOR_END__") [flags 0x2] <var_decl 0x7ffff0cf0000
__CTOR_END__>)
    (const_int -4 [0xfffffffffffffffc]))

since 

(const_int -4 [0xfffffffffffffffc])

is converted to

(const_int 4294967292 [0xfffffffc])

[Bug middle-end/47727] [x32] Many passes can't handle const symbol when Pmode != ptr_mode

[hjl at gcc dot gnu.org]

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

--- Comment #9 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> 2011-02-14 19:00:55 UTC ---
Author: hjl
Date: Mon Feb 14 19:00:52 2011
New Revision: 170149

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170149
Log:
Permute the conversion and addition if one operand is a constant.

gcc/

2011-02-14  H.J. Lu  <hongjiu.lu@intel.com>

    PR middle-end/47727
    * explow.c (convert_memory_address_addr_space): Permute the
    conversion and addition if one operand is a constant.

gcc/testsuite/

2011-02-14  H.J. Lu  <hongjiu.lu@intel.com>

    PR middle-end/47727
    * gcc.dg/pr47727.c: New.

Added:
    branches/x32/gcc/testsuite/gcc.dg/pr47727.c
Modified:
    branches/x32/gcc/ChangeLog.x32
    branches/x32/gcc/explow.c
    branches/x32/gcc/testsuite/ChangeLog.x32

[Bug middle-end/47727] [x32] Many passes can't handle const symbol when Pmode != ptr_mode

[hjl at gcc dot gnu.org]

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

--- Comment #10 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> 2011-07-14 22:50:29 UTC ---
Author: hjl
Date: Thu Jul 14 22:50:26 2011
New Revision: 176289

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176289
Log:
Permute the conversion and addition for zero-extending.

2011-07-10  H.J. Lu  <hongjiu.lu@intel.com>

    PR middle-end/47727
    * explow.c (convert_memory_address_addr_space): Permute the
    conversion and addition if one operand is a constant and we
    are zero-extending.  Call convert_memory_address_addr_space_1
    instead convert_memory_address_addr_space.

Modified:
    branches/x32/gcc/ChangeLog.x32
    branches/x32/gcc/explow.c

[Bug middle-end/47727] [x32] Many passes can't handle const symbol when Pmode != ptr_mode

[ubizjak at gmail dot com]

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

--- Comment #11 from Uros Bizjak <ubizjak at gmail dot com> 2011-07-28 09:22:29 UTC ---
With recent changes in mainline, the testcase from Comment #0 compiles OK:

__do_global_ctors_aux:
.LFB0:
    .cfi_startproc
    mov    -4+__CTOR_END__(%rip), %eax
    pushq    %rbx
    .cfi_def_cfa_offset 16
    .cfi_offset 3, -16
    cmpl    $-1, %eax
    je    .L1
    leal    -4+__CTOR_END__(%rip), %ebx
    .p2align 4,,10
    .p2align 3
.L3:
    leal    -4(%rbx), %ebx
    call    *%rax
    mov    (%rbx), %eax
    cmpl    $-1, %eax
    jne    .L3
.L1:
    popq    %rbx
    .cfi_def_cfa_offset 8
    ret
    .cfi_endproc

Probably, the patch is not needed at all.

[Bug middle-end/47727] [x32] Many passes can't handle const symbol when Pmode != ptr_mode

[hjl at gcc dot gnu.org]

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

--- Comment #12 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> 2011-08-06 14:50:12 UTC ---
Author: hjl
Date: Sat Aug  6 14:50:05 2011
New Revision: 177513

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177513
Log:
Add testcases for PRs 47727/47372/47715.

2011-08-06  H.J. Lu  <hongjiu.lu@intel.com>

    PR middle-end/47727
    * gcc.dg/pr47727.c: New.

    PR target/47372
    * gcc.dg/pr47372-1.c: New.
    * gcc.dg/pr47372-2.c: Likewise.

    PR target/47715
    * gcc.dg/tls/pr47715-5.c: New.

Added:
    trunk/gcc/testsuite/gcc.dg/pr47372-1.c
    trunk/gcc/testsuite/gcc.dg/pr47372-2.c
    trunk/gcc/testsuite/gcc.dg/pr47727.c
    trunk/gcc/testsuite/gcc.dg/tls/pr47715-5.c
Modified:
    trunk/gcc/testsuite/ChangeLog

[Bug middle-end/47727] [x32] Many passes can't handle const symbol when Pmode != ptr_mode

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.7.0

--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> 2011-08-08 15:56:30 UTC ---
Fixed.