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 >> >
