Hi, so it looks like there are other ia64 specific calls to plus_constant that need to be adjusted.
Tristan. On Jun 6, 2012, at 1:29 PM, Mailaripillai, Kannan Jeganathan wrote: >>>> What is the backtrace ? >> #0 0x6db96a0:0 in plus_constant (mode=RFmode, x=0x18, c=1) >> #13 0x6f68260:0 in expand_expr_real_1 (exp=0x651ab420, target=0x0, > > Full backtrace: > > #0 0x6db96a0:0 in plus_constant (mode=RFmode, x=0x18, c=1) > #1 0xd7503f0:0 in ia64_expand_tls_address (tls_kind=TLS_MODEL_INITIAL_EXEC, > op0=0x651ac120, op1=0x651ac0f0, orig_op1=0x651ac0f0, addend=0) > #2 0xd750dd0:0 in ia64_expand_move (op0=0x651ac120, op1=0x651ac0f0) > #3 0xd8c6e90:0 in gen_movsi (operand0=0x651ac120, operand1=0x651ac0f0) > #4 0x6ef9900:0 in emit_move_insn_1 (x=0x651ac120, y=0x651ac0f0) > #5 0x6efa6f0:0 in emit_move_insn (x=0x651ac120, y=0x651ac0f0) > #6 0x6dbdd30:0 in copy_to_mode_reg (mode=SImode, x=0x651ac0f0) > #7 0x8ba3c30:0 in maybe_legitimize_operand (icode=CODE_FOR_addsi3, opno=1, > op=0x7fffcf88) > #8 0x8ba46c0:0 in maybe_legitimize_operands (icode=CODE_FOR_addsi3, opno=0, > nops=3, ops=0x7fffcf80) > #9 0x8ba48c0:0 in maybe_gen_insn (icode=CODE_FOR_addsi3, nops=3, > ops=0x7fffcf80) > #10 0x8b6b620:0 in expand_binop_directly (mode=SImode, binoptab=0x40257fdc, > op0=0x651ac0f0, op1=0x653ba4f0, target=0x0, unsignedp=1, > methods=OPTAB_LIB_WIDEN, last=0x0) > #11 0x8b6bcb0:0 in expand_binop (mode=SImode, binoptab=0x40257fdc, > op0=0x651ac0f0, op1=0x653ba4f0, target=0x0, unsignedp=1, > methods=OPTAB_LIB_WIDEN) > #12 0x6f4fa30:0 in expand_expr_real_2 (ops=0x7fffdcd4, target=0x0, > tmode=SImode, modifier=EXPAND_NORMAL) > #13 0x6f68260:0 in expand_expr_real_1 (exp=0x651ab420, target=0x0, > tmode=SImode, modifier=EXPAND_NORMAL, alt_rtl=0x0) > #14 0x6f3c830:0 in expand_expr_real (exp=0x651ab420, target=0x0, tmode=SImode, > modifier=EXPAND_NORMAL, alt_rtl=0x0) > #15 0x6e7c5e0:0 in expand_expr (exp=0x651ab420, target=0x0, mode=SImode, > modifier=EXPAND_NORMAL) > #16 0x6f37cc0:0 in expand_expr_addr_expr_1 (exp=0x651a2900, target=0x0, > tmode=SImode, modifier=EXPAND_NORMAL, as=0 '\000') > #17 0x6f3adb0:0 in expand_expr_addr_expr (exp=0x651a8558, target=0x0, > tmode=SImode, modifier=EXPAND_NORMAL) > #18 0x6f67ff0:0 in expand_expr_real_1 (exp=0x651a8558, target=0x0, > tmode=SImode, modifier=EXPAND_NORMAL, alt_rtl=0x0) > #19 0x6f3c830:0 in expand_expr_real (exp=0x651a8558, target=0x0, tmode=SImode, > modifier=EXPAND_NORMAL, alt_rtl=0x0) > #20 0xaa49f90:0 in expand_expr (exp=0x651a8558, target=0x0, mode=SImode, > modifier=EXPAND_NORMAL) > #21 0xaa4ee60:0 in insert_value_copy_on_edge (e=0x655a4e40, dest=8, > src=0x651a8558, locus=1363692) > #22 0xaa53730:0 in eliminate_phi (e=0x655a4e40, g=0x404d6de0) > #23 0xaa54d70:0 in expand_phi_nodes (sa=0x4012623c) > #24 0x5f909d0:0 in gimple_expand_cfg () > #25 0x8d130d0:0 in execute_one_pass (pass=0x400451b8) > #26 0x8d137f0:0 in execute_pass_list (pass=0x400451b8) > #27 0x656d740:0 in expand_function (node=0x65550450) > #28 0x656eb60:0 in expand_all_functions () > #29 0x6571400:0 in compile () > #30 0x6571940:0 in finalize_compilation_unit () > #31 0x51bc8e0:0 in c_write_global_declarations () > #32 0x9c63b30:0 in compile_file () > #33 0x9c6b470:0 in do_compile () > #34 0x9c6b9c0:0 in toplev_main (argc=49, argv=0x7fffeee8) > #35 0xf564740:0 in main (argc=49, argv=0x7fffeee8) > > Regards, > Kannan > > -----Original Message----- > From: Mailaripillai, Kannan Jeganathan > Sent: Wednesday, June 06, 2012 4:42 PM > To: 'Tristan Gingold' > Cc: gcc@gcc.gnu.org > Subject: RE: regression due to r187199 explow.c? in target ia64-hp-hpux11.23. > > >> What is the backtrace ? > > #0 0x6db96a0:0 in plus_constant (mode=RFmode, x=0x18, c=1) > #1 0xd7503f0:0 in ia64_expand_tls_address (tls_kind=TLS_MODEL_INITIAL_EXEC, > op0=0x651ac120, op1=0x651ac0f0, orig_op1=0x651ac0f0, addend=0) > #2 0xd750dd0:0 in ia64_expand_move (op0=0x651ac120, op1=0x651ac0f0) > #3 0xd8c6e90:0 in gen_movsi (operand0=0x651ac120, operand1=0x651ac0f0) > #4 0x6ef9900:0 in emit_move_insn_1 (x=0x651ac120, y=0x651ac0f0) > #5 0x6efa6f0:0 in emit_move_insn (x=0x651ac120, y=0x651ac0f0) > #6 0x6dbdd30:0 in copy_to_mode_reg (mode=SImode, x=0x651ac0f0) > #7 0x8ba3c30:0 in maybe_legitimize_operand (icode=CODE_FOR_addsi3, opno=1, > op=0x7fffcf88) > #8 0x8ba46c0:0 in maybe_legitimize_operands (icode=CODE_FOR_addsi3, opno=0, > nops=3, ops=0x7fffcf80) > #9 0x8ba48c0:0 in maybe_gen_insn (icode=CODE_FOR_addsi3, nops=3, > ops=0x7fffcf80) > #10 0x8b6b620:0 in expand_binop_directly (mode=SImode, binoptab=0x40257fdc, > op0=0x651ac0f0, op1=0x653ba4f0, target=0x0, unsignedp=1, > methods=OPTAB_LIB_WIDEN, last=0x0) > #11 0x8b6bcb0:0 in expand_binop (mode=SImode, binoptab=0x40257fdc, > op0=0x651ac0f0, op1=0x653ba4f0, target=0x0, unsignedp=1, > methods=OPTAB_LIB_WIDEN) > #12 0x6f4fa30:0 in expand_expr_real_2 (ops=0x7fffdcd4, target=0x0, > tmode=SImode, modifier=EXPAND_NORMAL) > #13 0x6f68260:0 in expand_expr_real_1 (exp=0x651ab420, target=0x0, > > I remember seeing a patch related to this. But could not locate it in the > mail archive. > > Regards, > Kannan > > -----Original Message----- > From: Tristan Gingold [mailto:ging...@adacore.com] > Sent: Wednesday, June 06, 2012 4:05 PM > To: Mailaripillai, Kannan Jeganathan > Cc: gcc@gcc.gnu.org > Subject: Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23. > > > On Jun 6, 2012, at 12:27 PM, Mailaripillai, Kannan Jeganathan wrote: > >> Hi Tristan, >> >> After applying the patch (correctly) the build proceeded further. >> Now the build hits on another error, while compiling ..../libgomp/parallel.c: >> >> ..../libgomp/parallel.c: In function 'omp_get_ancestor_thread_num': >> ..../libgomp/parallel.c:166:1: internal compiler error: in plus_constant, at >> explow.c:88 >> omp_get_ancestor_thread_num (int level) >> ^ >> >> Is there another patch to solve this issue? >> Basically, my bootstrap build (ia64-hpux-11.23) is failing due to this. > > I haven't tried to build for ia64-hpux, only for ia64-openvms (which doesn't > support omp). > What is the backtrace ? > > Tristan. > >> >> Regards, >> Kannan >> >> -----Original Message----- >> From: Mailaripillai, Kannan Jeganathan >> Sent: Wednesday, June 06, 2012 2:15 PM >> To: 'Tristan Gingold' >> Cc: gcc@gcc.gnu.org >> Subject: RE: regression due to r187199 explow.c? in target ia64-hp-hpux11.23. >> >> Hi Tristan, >> >>> how result can be used uninitialized as it is assigned just before >> >> I am sorry. My mistake. I had replaced expand_expr_addr_expr_1 with >> convert_memory_address_addr_space. I overlooked the patch as >> >> - result = expand_expr_addr_expr_1 (inner, subtarget, tmode, modifier, as); >> + result = convert_memory_address_addr_space (tmode, result, as); >> >> Hence replaced expand_expr_addr_expr_1 with >> convert_memory_address_addr_space. >> >> Regards, >> Kannan >> >> -----Original Message----- >> From: Tristan Gingold [mailto:ging...@adacore.com] >> Sent: Wednesday, June 06, 2012 1:17 PM >> To: Mailaripillai, Kannan Jeganathan >> Cc: gcc@gcc.gnu.org >> Subject: Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23. >> >> >> On Jun 6, 2012, at 9:10 AM, Mailaripillai, Kannan Jeganathan wrote: >> >>> Hi Tristan, >>> >>>>> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00970.html >>>> I have not applied this patch. I will give it a try. >>> >>> This patch is not fixing the issue. >>> Moreover, on compiling expr.c I get this warning: >>> ..../gcc/expr.c: In function 'expand_expr_addr_expr_1': >>> ..../gcc/expr.c:7603:10: warning: 'result' may be used uninitialized in >>> this function. >> >> That's looking weird. I don't see how result can be used uninitialized as >> it is assigned just before. >> >> Tristan. >> >>> For the same testcase, now the ICE is happening in different place (while >>> compiling the same line of code): >>> test.c: In function 'main': >>> test.c:5:7: internal compiler error: Segmentation fault >>> boo (&iarr[1]); >>> ^ >>> >>> ---- Stack trace got through gdb: >>> >>> Program received signal SIGSEGV, Segmentation fault >>> si_code: 2 - SEGV_ACCERR - Invalid Permissions for object. >>> 0x6c9dd60:1 in adjust_address_1 (memref=0x6544a140, mode=SImode, offset=-4, >>> validate=1, adjust=1) >>> (gdb) bt >>> #0 0x6c9dd60:1 in adjust_address_1 (memref=0x6544a140, mode=SImode, >>> offset=-4, validate=1, adjust=1) >>> #1 0x957a110:0 in gen_lowpart_general (mode=SImode, x=0x6544a140) >>> #2 0x6ee33e0:0 in convert_modes (mode=SImode, oldmode=DImode, x=0x6544a140, >>> unsignedp=-1) >>> #3 0x6dbc600:0 in convert_memory_address_addr_space (to_mode=SImode, >>> x=0x6544a140, as=0 '\000') >>> #4 0x6f39a60:0 in expand_expr_addr_expr_1 (exp=0x6544a140, target=0x0, >>> tmode=SImode, modifier=EXPAND_NORMAL, as=0 '\000') >>> #5 0x6f3ad50:0 in expand_expr_addr_expr (exp=0x65453678, target=0x0, >>> tmode=SImode, modifier=EXPAND_NORMAL) >>> #6 0x6f67f90:0 in expand_expr_real_1 (exp=0x65453678, target=0x0, >>> tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) >>> #7 0x6f3c700:0 in expand_expr_real (exp=0x65453678, target=0x0, >>> tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) >>> #8 0x5d4dda0:0 in expand_normal (exp=0x65453678) >>> #9 0x5d8dce0:0 in precompute_register_parameters (num_actuals=1, >>> args=0x7fffd8a0, reg_parm_seen=0x7fffdc88) >>> #10 0x5da2160:0 in expand_call (exp=0x6544a258, target=0x0, ignore=1) >>> #11 0x6f637c0:0 in expand_expr_real_1 (exp=0x6544a258, target=0x0, >>> tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) >>> #12 0x5f6d760:0 in expand_call_stmt (stmt=0x6545c0b0) >>> #13 0x5f6da90:0 in expand_gimple_stmt_1 (stmt=0x6545c0b0) >>> >>> Testcase, GCC configuration, etc in the original post: >>> http://gcc.gnu.org/ml/gcc/2012-05/msg00371.html >>> >>> Regards, >>> Kannan >>> >>> -----Original Message----- >>> From: Mailaripillai, Kannan Jeganathan >>> Sent: Wednesday, May 30, 2012 2:44 PM >>> To: 'Tristan Gingold' >>> Cc: gcc@gcc.gnu.org >>> Subject: RE: regression due to r187199 explow.c? in target >>> ia64-hp-hpux11.23. >>> >>> Thanks Tristan. I have not applied this patch. I will give it a try. >>> >>> Regards, >>> Kannan >>> >>> -----Original Message----- >>> From: Tristan Gingold [mailto:ging...@adacore.com] >>> Sent: Wednesday, May 30, 2012 1:46 PM >>> To: Mailaripillai, Kannan Jeganathan >>> Cc: gcc@gcc.gnu.org >>> Subject: Re: regression due to r187199 explow.c? in target >>> ia64-hp-hpux11.23. >>> >>> Hi, >>> >>> did you try with this patch: >>> >>> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00970.html >>> >>> Tristan. >>> >>> On May 29, 2012, at 12:23 PM, Mailaripillai, Kannan Jeganathan wrote: >>> >>>> Hi, >>>> >>>> This modification (assertion) is causing failure in ia64-hp-hpux11.23: >>>> >>>> r187199 | rsandifo | 2012-05-05 10:41:49 -0700 (Sat, 05 May 2012) | 247 >>>> lines >>>> Changed paths: >>>> M /trunk/gcc/explow.c >>>> * explow.c (plus_constant, plus_constant_mode): Likewise. Assert that >>>> the mode is sensible. >>>> >>>> Haven't analyzed the issue. Thought of checking, if it is a known issue. >>>> >>>> Error: >>>> ------ >>>> test.c: In function 'main': >>>> test.c:5:7: internal compiler error: in plus_constant, at explow.c:88 >>>> boo (&iarr[1]); >>>> ^ >>>> >>>> Testcase (test.c): >>>> ------------------ >>>> int iarr[2]; >>>> extern int boo(int *); >>>> >>>> int main(void) { >>>> boo (&iarr[1]); >>>> return 0; >>>> } >>>> >>>> Compilation command: >>>> -------------------- >>>> gcc -c test.c >>>> ^ This compiler is built out of revision 187199 (trunk). Error attached >>>> above. >>>> >>>> Configuration: >>>> -------------- >>>> COLLECT_GCC=.../build-ia64-hp-hpux11.23-trunk/obj_gcc/gcc/xgcc >>>> Target: ia64-hp-hpux11.23 >>>> Configured with: ...gcc/src/configure --host=ia64-hp-hpux11.23 >>>> --build=ia64-hp-hpux11.23 --prefix=.../gcc-ia64-hp-hpux11.23-trunk \ >>>> --with-local-prefix=.../gcc-ia64-hp-hpux11.23-trunk --disable-nls \ >>>> --with-gmp=.../ia64-hp-hpux11.23 --with-mpfr=.../ia64-hp-hpux11.23 \ >>>> --with-mpc=.../ia64-hp-hpux11.23 --with-libelf=.../ia64-hp-hpux11.23 \ >>>> --disable-libmudflap --enable-libunwind-exceptions SED=/usr/bin/sed \ >>>> --enable-languages=c,c++,fortran >>>> Thread model: posix >>>> gcc version 4.8.0 20120505 (experimental) (GCC) >>>> COLLECT_GCC_OPTIONS='-B' '/.../build-ia64-hp-hpux11.23-trunk/obj_gcc/gcc/' >>>> '-c' '-v' >>>> GNU C (GCC) version 4.8.0 20120505 (experimental) (ia64-hp-hpux11.23) >>>> compiled by GNU C version 4.5.1, GMP version 4.2.4, MPFR version 2.4.1, >>>> MPC version 0.8 >>>> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 >>>> >>>> Regards, >>>> Kannan >>>> >>> >> >
