RE: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.

[Mailaripillai, Kannan Jeganathan]

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.

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
> 

Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.

[Tristan Gingold]

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

RE: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.

[Mailaripillai, Kannan Jeganathan]

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

Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.

[Tristan Gingold]

On Jun 6, 2012, at 10:45 AM, Mailaripillai, Kannan Jeganathan wrote:

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

That explains the crash too!

Tristan.

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

GCC 4.7.1 Release Candidate available from gcc.gnu.org

[Richard Guenther]

The first release candidate for GCC 4.7.1 is available from

 ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.1-RC-20120606

and shortly its mirrors.  It has been generated from SVN revision 188257.

I have so far bootstrapped and tested the release candidate on
x86_64-linux.  Please test it and report any issues to bugzilla.

If all goes well, I'd like to release 4.7.1 at the end of next week.

RE: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.

[Mailaripillai, Kannan Jeganathan]

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.

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

Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.

[Tristan Gingold]

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

RE: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.

[Mailaripillai, Kannan Jeganathan]

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

RE: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.

[Mailaripillai, Kannan Jeganathan]

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

Re: [RFH] Uses of output.h in the front ends

[David Edelsohn]

On Tue, Jun 5, 2012 at 9:56 AM, Steven Bosscher  wrote:

>> BSS was a later addition and there is no ".bss" pseudo-op directive,
>> unlike the ".comm" directive. There only is the BSS storage class.
>
> Do you know where I could find documentation for how to write out
> something with BSS storage class? Is that something that GNU binutils
> support, so that I can try it out?

GNU Binutils is not up to date for AIX 6.1 and AIX 7.1, so it's
support currently is irrelevant because it cannot be used for newer
versions of AIX.

I seem to remember trying BSS a long time ago and something did not
work -- maybe the linker did not merge the section as GCC expected. I
don't remember the details of the experiment.

BSS is like the .text and .data sections:

.csect .text[PR]
.csect .data[RW]

We can try something like

.csect .bss[BS]

- David

Re: Option -pthread in test suite with cross compilers

[Dave Korn]

On 03/06/2012 04:43, Hans-Peter Nilsson wrote:
> On Fri, 18 May 2012, Ralf Corsepius wrote:
>> On 05/18/2012 09:24 AM, Sebastian Huber wrote:
>>> Hi,
>>>
>>> if I run the ARM GCC test suite for C and C++ with the arm-rtemseabi4.11
>>> target, then I get several unexpected errors due to:
>>>
>>> gcc/testsuite/gcc/gcc.log:xgcc: error: unrecognized command line option
>>> '-pthread'
>>> gcc/testsuite/g++/g++.log:g++: error: unrecognized command line option
>>> '-pthread'
>>>
>>> The -pthread option is not necessary in RTEMS for the pthread API. I
>>> don't think that a special case in the test suite is desirable, thus we
>>> should add a dummy -pthread option to the RTEMS target configurations.
>>> Is this possible? In which file do I have to look for this?
>> I am not sure, but AFAICT, -pthread is Linux-specific.
> 
> No, it's the canonical multi-os option to enable pthreads, as
> generic as it gets.

  According to the manual(*), it's a machine-dependent option for RS6000 and
Solaris 2 only!

cheers,
  DaveK

-- 
(*) -
http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Option-Summary.html#Option-Summary

Re: Option -pthread in test suite with cross compilers

[Florian Weimer]

On 06/06/2012 03:09 PM, Dave Korn wrote:

I am not sure, but AFAICT, -pthread is Linux-specific.


No, it's the canonical multi-os option to enable pthreads, as
generic as it gets.


   According to the manual(*), it's a machine-dependent option for RS6000 and
Solaris 2 only!


And there's a lot of confusion about whether you have to throw in 
-D_REENTRANT as well (on GNU/Linux and on other systems).


I think on GNU/Linux, pthread detection mostly happens at run time these 
days, and you ought to use the _r API variants (which are available 
without -pthread) in library code.  I even think you shouldn't link 
against the library unless you actually create threads.



--
Florian Weimer / Red Hat Product Security Team

Fw: Extending calling convention information in DWARF output for x86

[Roger Cruz]

I am interested in parsing DWARF debug output in order to know the calling 
convention of each function.  Reading the spec for DWARF-4, I can see that 
there is an attribute DW_AT_calling_convention but its only defined values are 
(pg 52):

DW_CC_normal
DW_CC_program
DW_CC_nocall


The spec also allows compilers to generate their own extensions (pg 153) which 
can be used to enhanced that attribute's information.

My questions are:  Is there a way to coax GCC to use these extensions to spell 
out the calling convention for each function for an x86 target?  If not, has 
anyone added these extensions for other targets which I can use to add support 
for x86?  Can someone estimate how big of an effort it would be for someone who 
has no knowledge of GCC's internals but may be able to use another target as a 
template?


Regards,

Roger R. Cruz

Re: Option -pthread in test suite with cross compilers

[Jonathan Wakely]

On Jun 6, 2012 2:14 PM, "Florian Weimer" wrote:
>
> On 06/06/2012 03:09 PM, Dave Korn wrote:

 I am not sure, but AFAICT, -pthread is Linux-specific.
>>>
>>>
>>> No, it's the canonical multi-os option to enable pthreads, as
>>> generic as it gets.
>>
>>
>>   According to the manual(*), it's a machine-dependent option for RS6000 and
>> Solaris 2 only!

That's http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16519

> And there's a lot of confusion about whether you have to throw in 
> -D_REENTRANT as well (on GNU/Linux and on other systems).
>
> I think on GNU/Linux, pthread detection mostly happens at run time these 
> days, and you ought to use the _r API variants (which are available without 
> -pthread) in library code.  I even think you shouldn't link against the 
> library unless you actually create threads.

Certainly true for C++ as linking to libpthread causes libstdc++ to
use atomic ops for reference-counting.

Re: Fw: Extending calling convention information in DWARF output for x86

[Michael Eager]

On 06/06/2012 06:40 AM, Roger Cruz wrote:

Adding dwarf-discuss@ to CC.



I am interested in parsing DWARF debug output in order to know the calling 
convention of each
function.  Reading the spec for DWARF-4, I can see that there is an attribute
DW_AT_calling_convention but its only defined values are (pg 52):

DW_CC_normal

> DW_CC_program
> DW_CC_nocall

The DW_CC_nocall attribute are used tell a debugger that the common calling 
conventions,
say for saving/restoring registers or passing arguments, are not being followed,
for example, by a function which is intended to be called as an interrupt 
handler.

Almost everything about calling functions is described in DWARF, including
where the arguments are saved and how to unwind the stack.

What are you trying to describe?


The spec also allows compilers to generate their own extensions (pg 153) which 
can be used to
enhanced that attribute's information.


Yes, DWARF can add extensions.


My questions are:  Is there a way to coax GCC to use these extensions to spell 
out the calling
convention for each function for an x86 target?  If not, has anyone added these 
extensions for
other targets which I can use to add support for x86?  Can someone estimate how 
big of an effort
it would be for someone who has no knowledge of GCC's internals but may be able 
to use another
target as a template?


What do you mean by "calling conventions"?   What information do you want that 
is not available?

The general answer to the question "how much effort for someone who doesn't know GCC 
internals"
is "lots".

--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: Fw: Extending calling convention information in DWARF output for x86

[Roger Cruz]

Hi Michael,

Thanks for replying to my questions.

What I like to obtain somehow is the calling convention of each routine so I 
can tell who is responsible for cleaning off the stack.  Two calling 
conventions of interest to me are: _stdcall and _cdecl which deal with the 
arguments in a slightly different way.  With _cdecl, the default calling 
convention for C and C++ programs, the calling function is responsible for 
cleaning off the stack (ie, adjusting SP by the number of bytes that were 
pushed onto the stack by the caller).  With _stdcall, it is the called function 
that is responsible for cleaning up the stack.  So I need to know the calling 
convention to know who is responsible for cleaning up the stack and by how many 
bytes.  In reality, I just need to know how much to move the SP after one of 
these functions is executed (emulated), the calling convention just helped 
detect which functions would have to have their stack pointer manipulated.


Now, you say that DWARF may already give me enough information to know how to 
unwind the stack.  Given what I have described here, what fields in DWARF can I 
use to determine when and by how much to manipulate the stack pointer?  Here is 
an example of the DWARF information I have available for each of the two types 
of calling convention:


A _cdecl function

<1><2641c>: Abbrev Number: 39 (DW_TAG_subprogram)
    <2641d>   DW_AT_name    : (indirect string, offset: 0x61d4): 
CLIPBOARD_SetClipboardOwner    
    <26421>   DW_AT_decl_file   : 2 
    <26422>   DW_AT_decl_line   : 81    
    <26423>   DW_AT_prototyped  : 1 
    <26424>   DW_AT_type    : <0x1a430> 
    <26428>   DW_AT_low_pc  : 0x25edc   
    <2642c>   DW_AT_high_pc : 0x25fe0   
    <26430>   DW_AT_frame_base  : 0xfa4 (location list)
    <26434>   DW_AT_sibling : <0x264c5> 

<2><26438>: Abbrev Number: 40 (DW_TAG_formal_parameter)
    <26439>   DW_AT_name    : (indirect string, offset: 0x868): hWnd    
    <2643d>   DW_AT_decl_file   : 2 
    <2643e>   DW_AT_decl_line   : 81    
    <2643f>   DW_AT_type    : <0x1a659> 
    <26443>   DW_AT_location    : 3 byte block: 91 ec 7e    (DW_OP_fbreg: 
-148)

 <2><26447>: Abbrev Number: 42 (DW_TAG_variable)
    <26448>   DW_AT_name    : (indirect string, offset: 0x62ac): bRet   
    <2644c>   DW_AT_decl_file   : 2 
    <2644d>   DW_AT_decl_line   : 83    
    <2644e>   DW_AT_type    : <0x1a430> 
    <26452>   DW_AT_location    : 2 byte block: 91 64   (DW_OP_fbreg: -28)

 <2><26455>: Abbrev Number: 43 (DW_TAG_variable)
    <26456>   DW_AT_name    : (indirect string, offset: 0x461): 
__FUNCTION__    
    <2645a>   DW_AT_type    : <0x264d5> 
    <2645e>   DW_AT_artificial  : 1 
    <2645f>   DW_AT_location    : 5 byte block: 3 ec 51 e 0 (DW_OP_addr: 
e51ec)

 <2><26465>: Abbrev Number: 44 (DW_TAG_lexical_block)
    <26466>   DW_AT_low_pc  : 0x25f08   
    <2646a>   DW_AT_high_pc : 0x25f48   
    <2646e>   DW_AT_sibling : <0x2648f> 

 <3><26472>: Abbrev Number: 42 (DW_TAG_variable)
    <26473>   DW_AT_name    : (indirect string, offset: 0x5a5): __dbch  
    <26477>   DW_AT_decl_file   : 2 
    <26478>   DW_AT_decl_line   : 85    
    <26479>   DW_AT_type    : <0x264da> 
    <2647d>   DW_AT_location    : 2 byte block: 91 74   (DW_OP_fbreg: -12)

 <3><26480>: Abbrev Number: 42 (DW_TAG_variable)
    <26481>   DW_AT_name    : (indirect string, offset: 0x861): __dbcl  
    <26485>   DW_AT_decl_file   : 2 
    <26486>   DW_AT_decl_line   : 85    
    <26487>   DW_AT_type    : <0x264df> 
    <2648b>   DW_AT_location    : 2 byte block: 91 70   (DW_OP_fbreg: -16)




A _stdcall function:

  <267a9>   DW_AT_name    : (indirect string, offset: 0x674b): 
RegisterClipboardFormatW   
    <267ad>   DW_AT_decl_file   : 2 
    <267ae>   DW_AT_decl_line   : 216   
    <267af>   DW_AT_prototyped  : 1 
    <267b0>   DW_AT_type    : <0x1a45c> 
    <267b4>   DW_AT_low_pc  : 0x2643c   
    <267b8>   DW_AT_high_pc : 0x26464   
    <267bc>   DW_AT_frame_base  : 0x10ac    (location list)
    <267c0>   DW_AT_sibling : <0x267d3> 
 
<2><267c4>: Abbrev Number: 40 (DW_TAG_formal_parameter)
    <267c5>   DW_AT_name    : (indirect string, offset: 0x117d6): name  
    <267c9>   DW_AT_decl_file   : 2 
    <267ca>   DW_AT_decl_line   : 216   
    <267cb>   DW_AT_type    : <0x1a509> 
    <267cf>   DW_AT_location    : 2 byte block: 91 74   (DW_OP_fbreg: -12)

How can the above information be used to discern how to change the stack 
pointer if these routines' stack behavior were to be emulated?

Kind regards and thanks in advance for any insight you or anyone else can 
provide.

Roger


- Original Message -
From: Michael Eager 
To: Roger Cruz 
Cc: "gcc@gcc.gnu.org" ; dwarf-disc...@lists.dwarfstd.org
Sent: Wednesday, June 6, 2012 11:29 AM
Subje

gcc enhancements for TI MSP430 and other chips with target-specific address/integer modes

[Peter Bigot]

Over the last couple months I've been updating an out-of-tree back end for
the TI MSP430 to support 20-bit functionality.  This is a 16-bit
microcontroller, where certain MCUs support 20-bit address and integer
operations with an extended ISA and registers that can hold slightly more
than one word.

GCC is not particularly ready to support such a chip, at least not with the
architectural features I wanted.  Some of the problems I encountered are
described at:

https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Gcc47:20-Bit_Design#mixedmode

My thanks to Bernd Schmidt and Paulo Matos for providing work-in-progress on
their enhancements to address similar issues.  Although neither approach
suited my needs, it was very helpful to see what they'd done.

20-bit capable MSP430 support in gcc is now available out-of-tree; see
http://www.mail-archive.com/mspgcc-users@lists.sourceforge.net/msg10989.html.
The relevance to gcc is that I needed to make a variety of changes to gcc
proper to support this architecture.  These include:

 * [5f4ab69e90] Correction of some uses of Pmode where FUNCTION_MODE was
   appropriate ;

 * [03e6eb6cdb9, others] Correction of some uses of GET_MODE_BITSIZE where
   GET_MODE_PRECISION was required;

 * [ac85f5a18] Addition of target hooks that allow choice of different
   pointer and address modes in the same program, based on type trees.
   Since named address spaces aren't legal in C++, and aren't supported for
   functions, the existing capability could not be used.  The changes
   include a refactoring of the current named address space infrastructure
   to obtain the address space from the type tree;

 * [822bc1e12d] Store the actual pointer and address modes in mem_attrs
   instead of assuming they can be reconstructed from the address space
   alone;

 * [803171c91e; 1eee7ac13b] Addition of target hooks for finer control of
   declaration placement in specific sections;

 * [5f0473808b] Addition of target hooks that permit a target-specific
   integer type to be used for SIZE_TYPE and PTRDIFF_TYPE.  Though this is a
   gross hack, gcc's normal solution of promoting the internal 20-bit
   MODE_PARTIAL_INT PSImode to SImode is unworkable: conversion between
   PSImode and SImode is an extremely expensive operation.

 * [ffb61fc7ed] Allow selection of an exact-match MODE_PARTIAL_INT mode when
   smallest_mode_for_size is asked for MODE_INT satisfying a particular
   precision.

Since none of these issues could be demonstrated in upstream gcc, I only
filed bugzilla reports for the ones that seemed obviously wrong.

At this time, integration of these changes upstream is out of scope, but I
thought other gcc developers might be interested in seeing the patches,
especially if they need to support a similar target.

The MSP430 git repository for gcc can be browsed at
http://mspgcc.git.sourceforge.net/git/gitweb.cgi?p=mspgcc/gcc;a=summary and
the readme on that page points to a description of the branching conventions
used in the repository.  The patches that might be of interest to upstream
gcc are in the commits identified in brackets in the list above.

Thanks to everybody who's helped with this over the past several months.

Peter

Re: Fw: Extending calling convention information in DWARF output for x86

[Michael Eager]

On 06/06/2012 09:28 AM, Roger Cruz wrote:

Hi Michael,

Thanks for replying to my questions.

What I like to obtain somehow is the calling convention of each routine so
I can tell who is responsible for cleaning off the stack.  Two calling

> conventions of interest to me are: _stdcall and _cdecl which deal with the
> arguments in a slightly different way.  With _cdecl, the default calling

convention for C and C++ programs, the calling function is responsible for
cleaning off the stack (ie, adjusting SP by the number of bytes that were
pushed onto the stack by the caller).  With _stdcall, it is the called
function that is responsible for cleaning up the stack.  So I need to
know the calling convention to know who is responsible for cleaning up
the stack and by how many bytes.  In reality, I just need to know how
much to move the SP after one of these functions is executed (emulated),
the calling convention just helped detect which functions would have to

> have their stack pointer manipulated.

Usually, syntactic tags like "_stdcall" or "_cdecl" are represented by
an attribute in the appropriate (in this case, DW_TAG_subprogram) DIE.
This can be used by the debugger to print out the tag as well as do
whatever different semantic processing may be needed.

You might add attributes for "_stdcall" or "_cdecl" as user extensions.


Now, you say that DWARF may already give me enough information to know

> how to unwind the stack.  Given what I have described here, what fields
> in DWARF can I use to determine when and by how much to manipulate the
> stack pointer?  Here is an example of the DWARF information I have available
> for each of the two types of calling convention:

The DWARF Call Frame Information (CFI) specified in Section 6.4 describes
how to unwind the stack from any arbitrary location in a function to
find the previous stack frame.  The CFI can be used to determine the value
of the stack pointer at the entry to the function.

The CFI is designed to track the (real or virtual) frame pointer, not
the stack pointer, so it will not tell you how the calling function modifies
the stack before or after the call.

--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

installing an older version of g++ on ubuntu 12.04

[mixpro]

i had a problem compiling from source , so i tried installing .deb from
http://packages.ubuntu.com/hardy-updates/g++-3.4
i installed :

cpp-3.4_3.4.6-6ubuntu5_i386.deb  
gcc-3.4-base_3.4.6-6ubuntu5_i386.deb
g++-3.4_3.4.6-6ubuntu5_i386.deb  
libstdc++6-dev_3.4.6-6ubuntu5_i386.deb
gcc-3.4_3.4.6-6ubuntu5_i386.deb


but when i compile 

#include 

int main(){
printf("hisss \n");

return 0;
}


using gcc-3.4 or g++-3.4 i get :

In file included from /usr/include/stdio.h:28,
from ./hi.c:1:
/usr/include/features.h:324:26: bits/predefs.h: No such file or directory
/usr/include/features.h:357:25: sys/cdefs.h: No such file or directory
/usr/include/features.h:389:23: gnu/stubs.h: No such file or directory
In file included from /usr/include/stdio.h:34,
from ./hi.c:1:
/usr/lib/gcc/i486-linux-gnu/3.4.6/include/stddef.h:213: error: syntax error
before "typedef"
In file included from ./hi.c:1:
/usr/include/stdio.h:36:25: bits/types.h: No such file or directory
In file included from ./hi.c:1:
/usr/include/stdio.h:49: error: syntax error before "typedef"
/usr/include/stdio.h:54: error: syntax error before "__USING_NAMESPACE_STD"
/usr/include/stdio.h: In function `__USING_NAMESPACE_STD':
/usr/include/stdio.h:65: error: storage class specified for parameter
`__FILE'
In file included from /usr/include/_G_config.h:20,
from /usr/include/libio.h:32,
from /usr/include/stdio.h:75,
from ./hi.c:1:
/usr/include/wchar.h:95: error: storage class specified for parameter
`__mbstate_t' 


and there's a lot more , what to do ??
thnx
-- 
View this message in context: 
http://old.nabble.com/installing-an-older-version-of-g%2B%2B-on-ubuntu-12.04-tp33971892p33971892.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: installing an older version of g++ on ubuntu 12.04

[Marc Glisse]

On Wed, 6 Jun 2012, mixpro wrote:


i had a problem compiling from source , so i tried installing .deb from
http://packages.ubuntu.com/hardy-updates/g++-3.4

[...]

using gcc-3.4 or g++-3.4 i get :

In file included from /usr/include/stdio.h:28,
from ./hi.c:1:
/usr/include/features.h:324:26: bits/predefs.h: No such file or directory

[...]

and there's a lot more , what to do ??


export LIBRARY_PATH=/usr/lib/i386-linux-gnu
export C_INCLUDE_PATH=/usr/include/i386-linux-gnu
export CPLUS_INCLUDE_PATH=/usr/include/i386-linux-gnu

--
Marc Glisse

Re: installing an older version of g++ on ubuntu 12.04

[mixpro]

Marc Glisse-6 wrote:
> 
> 
> export LIBRARY_PATH=/usr/lib/i386-linux-gnu
> export C_INCLUDE_PATH=/usr/include/i386-linux-gnu
> export CPLUS_INCLUDE_PATH=/usr/include/i386-linux-gnu
> 
> -- 
> Marc Glisse
> 
> 

know i get :
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status


-- 
View this message in context: 
http://old.nabble.com/installing-an-older-version-of-g%2B%2B-on-ubuntu-12.04-tp33971892p33972021.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: installing an older version of g++ on ubuntu 12.04

[Marc Glisse]

On Wed, 6 Jun 2012, mixpro wrote:


Marc Glisse-6 wrote:


export LIBRARY_PATH=/usr/lib/i386-linux-gnu
export C_INCLUDE_PATH=/usr/include/i386-linux-gnu
export CPLUS_INCLUDE_PATH=/usr/include/i386-linux-gnu


know i get :
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status


You could retry building from source. Or you could go to 
/usr/lib/gcc/i386-linux-gnu/3.4 (or a similar name) and fix the symbolic 
links (as root). Or you could install an old ubuntu in a virtual 
machine...


--
Marc Glisse

Re: installing an older version of g++ on ubuntu 12.04

[mixpro]

i found libgcc_s in :
/usr/lib/gcc/i686-linux-gnu/4.6/libgcc_s.so
/usr/lib/gcc/i486-linux-gnu/3.4.6/64/libgcc_s.so
/usr/lib/gcc/i486-linux-gnu/3.4.6/64/libgcc_s_64.so
/usr/lib/gcc/i486-linux-gnu/3.4.6/libgcc_s.so
/usr/lib/gcc/i486-linux-gnu/3.4.6/libgcc_s_64.so
/lib/i386-linux-gnu/libgcc_s.so.1

and i tried :
cd /usr/lib/i386-linux-gnu
sudo ln -s /usr/lib/gcc/i486-linux-gnu/3.4.6/libgcc_s.so libgcc_s.so

but i still get the same error 
-- 
View this message in context: 
http://old.nabble.com/installing-an-older-version-of-g%2B%2B-on-ubuntu-12.04-tp33971892p33972157.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: [RFH] Uses of output.h in the front ends

[Iain Sandoe]

Hi Steven,

On 5 Jun 2012, at 21:23, Steven Bosscher wrote:

> On Tue, Jun 5, 2012 at 8:55 PM, Iain Sandoe  wrote:
>> I would welcome a simple solution if one is available, although I don't 
>> quite see what you have in mind at present.
> 
> This is what I have in mind. Untested, but it shows the idea. What do
> you think of this?

Thanks, it looks like a good compromise given the small number of targets using 
it.

Just for the record, the NeXT ObjC runtime is open sourced, and could be ported 
to a non-Darwin target (as long as it has named sections) -  I do recall Nicola 
made the comment that it would be harder for targets other than x86/PPC since 
there is some asm in the message forwarding scheme. 

===

As for your patch, I've moved stuff around a bit and fixed up a couple of typos 
(notes below), but retained your scheme (hopefully as you intended).

The attached patch survives normal and lto bootstrap on i686-darwin9 and 
x86_64-darwin10.
No regressions for ObjC or Obj-C++.
Otherwise, lightly tested, but appears to solve PR 48109 on the way.

changes:

 o [minor] typo fixes and some changes to the comments, minor adjustments to 
make the asm indents match with other code.

 o  I moved the functions to config/darwin-c.c (I suspect that's what you 
originally intended, from the comments).

 o I made two (c-family) target hooks instead of generating new target macros -
 side benefits of this are:
  (i) that we can also remove tm.h from objc-next-runtime-abi-01.c
  (ii) we don't end up with dead code pathways on non-darwin builds.
  (iii) the actual implementation of the defs/refs is now private to Darwin.

if you think this good to go - given that Mike has already commented, then I 
guess we should move it to Patches for review.

thanks for the idea!
Iain

Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 188216)
+++ gcc/doc/tm.texi (working copy)
@@ -694,6 +694,14 @@ should use @code{TARGET_HANDLE_C_OPTION} instead.
 Targets may provide a string object type that can be used within and between 
C, C++ and their respective Objective-C dialects. A string object might, for 
example, embed encoding and length information. These objects are considered 
opaque to the compiler and handled as references. An ideal implementation makes 
the composition of the string object match that of the Objective-C 
@code{NSString} (@code{NXString} for GNUStep), allowing efficient interworking 
between C-only and Objective-C code. If a target implements string objects then 
this hook should return a reference to such an object constructed from the 
normal `C' string representation provided in @var{string}. At present, the hook 
is used by Objective-C only, to obtain a common-format string object when the 
target provides one.
 @end deftypefn
 
+@deftypefn {C Target Hook} void TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE 
(const char *@var{classname})
+Declare that Objective C class @var{classname} is referenced  by the current 
TU.
+@end deftypefn
+
+@deftypefn {C Target Hook} void TARGET_OBJC_DECLARE_CLASS_DEFINITION (const 
char *@var{classname})
+Declare that Objective C class @var{classname} is defined  by the current TU.
+@end deftypefn
+
 @deftypefn {C Target Hook} bool TARGET_STRING_OBJECT_REF_TYPE_P (const_tree 
@var{stringref})
 If a target implements string objects then this hook should return @code{true} 
if @var{stringref} is a valid reference to such an object.
 @end deftypefn
Index: gcc/c-family/c-target.def
===
--- gcc/c-family/c-target.def   (revision 188216)
+++ gcc/c-family/c-target.def   (working copy)
@@ -59,8 +59,22 @@ DEFHOOK
  common-format string object when the target provides one.",
  tree, (tree string),
  NULL)
- 
+
 DEFHOOK
+(objc_declare_unresolved_class_reference,
+ "Declare that Objective C class @var{classname} is referenced\
+  by the current TU.",
+ void, (const char *classname),
+ NULL)
+
+DEFHOOK
+(objc_declare_class_definition,
+ "Declare that Objective C class @var{classname} is defined\
+  by the current TU.",
+ void, (const char *classname),
+ NULL)
+
+DEFHOOK
 (string_object_ref_type_p,
  "If a target implements string objects then this hook should return\
  @code{true} if @var{stringref} is a valid reference to such an object.",
Index: gcc/objc/objc-next-runtime-abi-01.c
===
--- gcc/objc/objc-next-runtime-abi-01.c (revision 188216)
+++ gcc/objc/objc-next-runtime-abi-01.c (working copy)
@@ -26,7 +26,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
-#include "tm.h"
 #include "tree.h"
 
 #ifdef OBJCPLUS
@@ -49,7 +48,7 @@ along with GCC; see the file COPYING3.  If not see
 
 #include "ggc.h"
 #include "target.h"
-#include "output.h" /* for asm_out_file */
+#include "c-family/c-target.h"
 #in

Problem with target_flags_explicit and configure_default_options

[Steve Ellcey]

This is a followup mail to http://gcc.gnu.org/ml/gcc/2012-05/msg00400.html
now that I understand my problem better and can change the subject line to
reflect that.

I am trying to determine if a user specified the '-msynci' flag on his or her
GCC compile line or if it is on by default because when GCC was configured
and built it was configured with '--with-synci'.  David Edelsohn pointed me
at target_flags_explicit and I thought that was what I wanted but it doesn't
work because of how the '--with-synci' configure option is handled.

When I configure GCC with '--with-synci' the configure script puts
'synci' into the configure_default_options array and then the GCC
driver uses this array to add the '-msynci' flag to the cc1 call.
So now when cc1 checks target_flags_explicit for the MASK_SYNCI bit
it finds that it is set because the driver added it, even though it is
not on the users gcc command line and I cannot tell if the user had
-msynci on his or her GCC command line or if the driver added it automatically.

Does anyone have any ideas on telling the two cases apart?

Steve Ellcey
sell...@mips.com

Re: installing an older version of g++ on ubuntu 12.04

[mixpro]

mixpro wrote:
> 
> i found libgcc_s in :
> /usr/lib/gcc/i686-linux-gnu/4.6/libgcc_s.so
> /usr/lib/gcc/i486-linux-gnu/3.4.6/64/libgcc_s.so
> /usr/lib/gcc/i486-linux-gnu/3.4.6/64/libgcc_s_64.so
> /usr/lib/gcc/i486-linux-gnu/3.4.6/libgcc_s.so
> /usr/lib/gcc/i486-linux-gnu/3.4.6/libgcc_s_64.so
> /lib/i386-linux-gnu/libgcc_s.so.1
> 
> and i tried :
> cd /usr/lib/i386-linux-gnu
> sudo ln -s /usr/lib/gcc/i486-linux-gnu/3.4.6/libgcc_s.so libgcc_s.so
> 
> but i still get the same error 
> 


i looked at /usr/lib/gcc/i486-linux-gnu/3.4.6/libgcc_s.so and it was a
symbolic link to /lib/libgcc_s.so.1
so i looked for /lib/libgcc_s.so.1 and there was no such a file ?? what does
that mean ??
-- 
View this message in context: 
http://old.nabble.com/installing-an-older-version-of-g%2B%2B-on-ubuntu-12.04-tp33971892p33972446.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: [RFH] Uses of output.h in the front ends

[Steven Bosscher]

On Wed, Jun 6, 2012 at 10:07 PM, Iain Sandoe  wrote:
> Hi Steven,
> The attached patch survives normal and lto bootstrap on i686-darwin9 and 
> x86_64-darwin10.
> No regressions for ObjC or Obj-C++.
> Otherwise, lightly tested, but appears to solve PR 48109 on the way.
>
> changes:
>
>  o [minor] typo fixes and some changes to the comments, minor adjustments to 
> make the asm indents match with other code.
>
>  o  I moved the functions to config/darwin-c.c (I suspect that's what you 
> originally intended, from the comments).
>
>  o I made two (c-family) target hooks instead of generating new target macros 
> -
>     side benefits of this are:
>      (i) that we can also remove tm.h from objc-next-runtime-abi-01.c
>      (ii) we don't end up with dead code pathways on non-darwin builds.
>      (iii) the actual implementation of the defs/refs is now private to 
> Darwin.

Looks a lot prettier to me :-)

> if you think this good to go - given that Mike has already commented, then I 
> guess we should move it to Patches for review.

Sounds like a plan.

Ciao!
Steven

Re: Problem with target_flags_explicit and configure_default_options

[Eric Botcazou]

> This is a followup mail to http://gcc.gnu.org/ml/gcc/2012-05/msg00400.html
> now that I understand my problem better and can change the subject line to
> reflect that.

I'm not sure whether digging into the behavior of the driver is the best way to 
solve this kind of testsuite problems.  I think you should consider adding a
new dg-require-effective-target marker instead.

> When I configure GCC with '--with-synci' the configure script puts
> 'synci' into the configure_default_options array and then the GCC
> driver uses this array to add the '-msynci' flag to the cc1 call.
> So now when cc1 checks target_flags_explicit for the MASK_SYNCI bit
> it finds that it is set because the driver added it, even though it is
> not on the users gcc command line and I cannot tell if the user had
> -msynci on his or her GCC command line or if the driver added it
> automatically.
>
> Does anyone have any ideas on telling the two cases apart?

I think that there is no simple solution.  We needed something like that a 
while ago to implement the -s switch of the gnatmake command of the GNAT 
compiler and we ended up with a scheme where gnatmake prepends and appends 
special switches to the command line it is passed, sends the result to the 
driver which also prepends and appends its own stuff before calling the real 
compiler (gnat1 here), and we have parameterized the specs (lang-specs.h) so 
that the driver doesn't modify the order of the special switches wrt the -m 
switches.  As a result, gnat1 knows that any -m switch before the prepended 
special switch or after the appended special switch comes from the driver.

-- 
Eric Botcazou

Re: Problem with target_flags_explicit and configure_default_options

[Steve Ellcey]

On Wed, 2012-06-06 at 23:19 +0200, Eric Botcazou wrote:
> > This is a followup mail to http://gcc.gnu.org/ml/gcc/2012-05/msg00400.html
> > now that I understand my problem better and can change the subject line to
> > reflect that.
> 
> I'm not sure whether digging into the behavior of the driver is the best way 
> to 
> solve this kind of testsuite problems.  I think you should consider adding a
> new dg-require-effective-target marker instead.

You are probably right, I don't think I need a new
dg-require-effective-target marker though, for most (maybe all) of them
I can just specify that they use the -mno-synci flag.  The tests in
question are already mips specific tests that specify an older
architecture via some flag.

> > Does anyone have any ideas on telling the two cases apart?
> 
> I think that there is no simple solution.  We needed something like that a 
> while ago to implement the -s switch of the gnatmake command of the GNAT 
> compiler and we ended up with a scheme where gnatmake prepends and appends 
> special switches to the command line it is passed, sends the result to the 
> driver which also prepends and appends its own stuff before calling the real 
> compiler (gnat1 here), and we have parameterized the specs (lang-specs.h) so 
> that the driver doesn't modify the order of the special switches wrt the -m 
> switches.  As a result, gnat1 knows that any -m switch before the prepended 
> special switch or after the appended special switch comes from the driver.

Yuck.  I think that suppressing the warning is the right thing to do,
but I am not sure it is worth this much effort.  Changing the testsuite
is easier.

Steve Ellcey
sell...@mips.com

Re: installing an older version of g++ on ubuntu 12.04

[Jonathan Wakely]

On 6 June 2012 19:57, mixpro wrote:
>
> i had a problem compiling from source

Questions about building GCC are not appropriate on this mailing list,
as you've posted via Nabble you should have seen Nabble's description
of the list which clearly says:

"Please note this is NOT, I repeat NOT, a GCC users list - this is a
GCC developers list.
For user general questions, post to GCC - Help."

Please use the gcc-help mailing list instead, thanks.

Fw: Extending calling convention information in DWARF output for x86

[Roger Cruz]

Thanks Michael.  So it sounds like DWARF won't help me in determining how a 
called function should (or should not) clean up the stack and also if I want to 
determine the calling convention, I would have to modify GCC itself to produce 
those user extensions.

Roger




From: Michael Eager 
To: Roger Cruz  
Cc: "gcc@gcc.gnu.org" ; "dwarf-disc...@lists.dwarfstd.org" 
 
Sent: Wednesday, June 6, 2012 1:27 PM
Subject: Re: Fw: Extending calling convention information in DWARF output for 
x86

On 06/06/2012 09:28 AM, Roger Cruz wrote:
> Hi Michael,
> 
> Thanks for replying to my questions.
> 
> What I like to obtain somehow is the calling convention of each routine so
> I can tell who is responsible for cleaning off the stack.  Two calling
> conventions of interest to me are: _stdcall and _cdecl which deal with the
> arguments in a slightly different way.  With _cdecl, the default calling
> convention for C and C++ programs, the calling function is responsible for
> cleaning off the stack (ie, adjusting SP by the number of bytes that were
> pushed onto the stack by the caller).  With _stdcall, it is the called
> function that is responsible for cleaning up the stack.  So I need to
> know the calling convention to know who is responsible for cleaning up
> the stack and by how many bytes.  In reality, I just need to know how
> much
to move the SP after one of these functions is executed (emulated),
> the calling convention just helped detect which functions would have to
> have their stack pointer manipulated.

Usually, syntactic tags like "_stdcall" or "_cdecl" are represented by
an attribute in the appropriate (in this case, DW_TAG_subprogram) DIE.
This can be used by the debugger to print out the tag as well as do
whatever different semantic processing may be needed.

You might add attributes for "_stdcall" or "_cdecl" as user extensions.

> Now, you say that DWARF may already give me enough information to know
> how to unwind the stack.  Given what I have described here, what fields
> in DWARF can I use to determine when and by how much to manipulate the
> stack pointer?  Here is an example of the DWARF information I have available
> for each of the two types of calling convention:

The DWARF
Call Frame Information (CFI) specified in Section 6.4 describes
how to unwind the stack from any arbitrary location in a function to
find the previous stack frame.  The CFI can be used to determine the value
of the stack pointer at the entry to the function.

The CFI is designed to track the (real or virtual) frame pointer, not
the stack pointer, so it will not tell you how the calling function modifies
the stack before or after the call.

-- Michael Eager    ea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFH - Testing targets for the switch to C++

[Thomas Schwinge]

Hi!

A bit late to the game...  :-)

On Fri, 6 Apr 2012 18:55:28 -0400, Diego Novillo  wrote:
> I have started testing the switch to C++ and there is a pile of
> testing to be done.  The testing itself is trivial, but the number of
> targets that need to be tested is large and I don't have access to all
> these combinations.

i686-gnu would be mine.

This is based on 8b64dc3c58b54d07156c99a24576be76e8cbdc10 (2012-05-28)
sources, doing native builds on x86 Debian GNU/Linux as well as x86
Debian GNU/Hurd.

When --enable-build-with-cxx is enabled:

  * Build time mostly stays the same.

  * Looking at the build log, the build system's gcc (as opposed to g++)
is still being used for building libiberty, fixincludes, zlib,
libdecnumber, *_FOR_BUILD stuff in gcc/Makefile.  The latter seems to
have been addressed in a44c8c3b1ee8ae1779fd8ee1ad556ed86a608bd2
(2012-05-31), the others are probably expected to continue using gcc.

  * The size of the build directory stage1-gcc shrinks (!) from 1.1 GiB
to 0.4 GiB, such that the whole build tree then occupies 2.6 GiB
instead of 3.2 GiB.  I did notice that the C build uses
-fkeep-inline-functions, and the C++ build doesn't (my logs, and
confirmed in the top-level configure.ac), but don't know if that is
the (sole) reason; I have not looked at this in more detail -- but
0.6 GiB or 60 % less is quite a bit.

  * No difference in testsuite results.

When building a i686-linux-gnu to i686-gnu cross-compiler, there are
(expectedly) no surprises either.


Grüße,
 Thomas


pgppdH7dMrxNE.pgp
Description: PGP signature