[Bug middle-end/47727] [x32] Many passes can't handle const symbol when Pmode != ptr_mode
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.
[Bug middle-end/47727] [x32] Many passes can't handle const symbol when Pmode != ptr_mode
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=gccview=revrev=177513 Log: Add testcases for PRs 47727/47372/47715. 2011-08-06 H.J. Lu hongjiu...@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
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
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=gccview=revrev=176289 Log: Permute the conversion and addition for zero-extending. 2011-07-10 H.J. Lu hongjiu...@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
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
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
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
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 0x70cf __CTOR_END__) (const_int -4 [0xfffc])) since (const_int -4 [0xfffc]) is converted to (const_int 4294967292 [0xfffc])
[Bug middle-end/47727] [x32] Many passes can't handle const symbol when Pmode != ptr_mode
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=gccview=revrev=170149 Log: Permute the conversion and addition if one operand is a constant. gcc/ 2011-02-14 H.J. Lu hongjiu...@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...@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
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 0x70cf __CTOR_END__)
(const_int -4 [0xfffc] 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=0x70d46900)
at /export/gnu/import/git/gcc-x32/gcc/emit-rtl.c:4791
#1 0x006f0e87 in emit_move_insn_1 (x=0x70d42dc0, y=0x70d42b40)
at /export/gnu/import/git/gcc-x32/gcc/expr.c:3305
#2 0x006f125a in emit_move_insn (x=0x70d42dc0, y=0x70d42b40)
at /export/gnu/import/git/gcc-x32/gcc/expr.c:3395
#3 0x006d503e in copy_to_mode_reg (mode=SImode, x=0x70d42b40)
at /export/gnu/import/git/gcc-x32/gcc/explow.c:637
#4 0x008d9656 in expand_binop_directly (mode=SImode,
binoptab=0x1809e20, op0=0x70d42b40, op1=0x70dea430,
target=0x70d42da0, unsignedp=1, methods=OPTAB_LIB_WIDEN,
last=0x70cf1980) at /export/gnu/import/git/gcc-x32/gcc/optabs.c:1461
#5 0x008d99c2 in expand_binop (mode=SImode, binoptab=0x1809e20,
op0=0x70d42b40, op1=0x70dea430, target=0x70d42da0,
unsignedp=1, methods=OPTAB_LIB_WIDEN)
at /export/gnu/import/git/gcc-x32/gcc/optabs.c:1551
#6 0x008d9185 in expand_simple_binop (mode=SImode, code=PLUS,
op0=0x70d42b40, op1=0x70dea430, target=0x70d42da0,
unsignedp=1, methods=OPTAB_LIB_WIDEN)
at /export/gnu/import/git/gcc-x32/gcc/optabs.c:1295
#7 0x00701383 in force_operand (value=0x70d473a8,
target=0x70d42da0) at /export/gnu/import/git/gcc-x32/gcc/expr.c:6452
#8 0x006d4fed in copy_to_mode_reg (mode=SImode, x=0x70d473a8)
---Type return to continue, or q return to quit---
at /export/gnu/import/git/gcc-x32/gcc/explow.c:633
#9 0x008df8d7 in maybe_emit_unop_insn (icode=2221,
target=0x70d42d80, op0=0x70d473a8, code=ZERO_EXTEND)
at /export/gnu/import/git/gcc-x32/gcc/optabs.c:3746
#10 0x008dfa49 in emit_unop_insn (icode=2221, target=0x70d42d80,
op0=0x70d473a8, code=ZERO_EXTEND)
at /export/gnu/import/git/gcc-x32/gcc/optabs.c:3776
#11 0x006e9df4 in convert_move (to=0x70d42d80,
from=0x70d473a8, unsignedp=1)
at /export/gnu/import/git/gcc-x32/gcc/expr.c:612
#12 0x006ea5de in convert_modes (mode=DImode, oldmode=SImode,
x=0x70d473a8, unsignedp=1)
at /export/gnu/import/git/gcc-x32/gcc/expr.c:791
#13 0x006d4971 in convert_memory_address_addr_space (to_mode=DImode,
x=0x70d473a8, as=0 '\000')
at /export/gnu/import/git/gcc-x32/gcc/explow.c:408
#14 0x006d488d in convert_memory_address_addr_space (to_mode=DImode,
x=0x70d43d10, as=0 '\000')
at /export/gnu/import/git/gcc-x32/gcc/explow.c:379
#15 0x009bceb1 in simplify_unary_operation_1 (code=ZERO_EXTEND,
mode=DImode, op=0x70d43d10)
at /export/gnu/import/git/gcc-x32/gcc/simplify-rtx.c:
#16 0x009bafa8 in simplify_unary_operation (code=ZERO_EXTEND,
---Type return to continue, or q return to quit---
mode=DImode, op=0x70d43d10, 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.
