This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
C++ frontend generating bogous trees
- From: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 15 Feb 2005 19:01:56 +0100 (CET)
- Subject: C++ frontend generating bogous trees
Hi!
The C++ frontend creates from cp/call.c:3864 (build_new_op
(code=PLUS_EXPR, flags=3, ...)) with arg1
(gdb) call debug_tree(arg1)
<var_decl 0x2a95dd4680 _S_free_list
type <array_type 0x2a95dd4ea0
type <pointer_type 0x2a95dd4b60 type <union_type 0x2a95dd4340
_Obj>
volatile unsigned type_6 DI
size <integer_cst 0x2a958acc30 constant invariant 64>
unit size <integer_cst 0x2a958acc60 constant invariant 8>
align 64 symtab -1780663408 alias set -1
pointer_to_this <pointer_type 0x2a95dd5750>>
BLK
size <integer_cst 0x2a95a67990 constant invariant 1024>
unit size <integer_cst 0x2a95a5ff30 constant invariant 128>
align 64 symtab -1780664448 alias set -1
domain <integer_type 0x2a95981dd0 type <integer_type 0x2a958b34e0
long unsigned int>
DI size <integer_cst 0x2a958acc30 64> unit size <integer_cst
0x2a958acc60 8>
align 64 symtab 0 alias set -1 precision 64 min <integer_cst
0x2a958ac5d0 0> max <integer_cst 0x2a958accf0 15>>
pointer_to_this <pointer_type 0x2a95df5b60>>
side-effects addressable volatile used public protected static
external nonlocal decl_3 decl_5 decl_6 BLK file
/net/pherkad/scratch/rguenth/gcc-obj2/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/pool_allocator.h
line 91 size <integer_cst 0x2a95a67990 1024> unit size <integer_cst
0x2a95a5ff30 128>
align 64 context <record_type 0x2a95dd2750 __pool_alloc_base>
chain <var_decl 0x2a95dd2a90 _S_start_free>>
in
#5 0x0000000000515552 in build_binary_op (code=PLUS_EXPR,
orig_op0=0x2a95dd4680, orig_op1=0x2a95df5ea0, convert_p=1)
at /net/pherkad/scratch/rguenth/gcc/gcc/cp/typeck.c:2819
2819 return cp_pointer_int_sum (PLUS_EXPR, op0, op1);
(gdb) call debug_tree(op0)
<nop_expr 0x2a95df6300
type <pointer_type 0x2a95dd5750
type <pointer_type 0x2a95dd4b60 type <union_type 0x2a95dd4340
_Obj>
volatile unsigned type_6 DI
size <integer_cst 0x2a958acc30 constant invariant 64>
unit size <integer_cst 0x2a958acc60 constant invariant 8>
align 64 symtab -1780663408 alias set -1
pointer_to_this <pointer_type 0x2a95dd5750>>
asm_written unsigned type_6 DI size <integer_cst 0x2a958acc30 64>
unit size <integer_cst 0x2a958acc60 8>
align 64 symtab -1780663488 alias set -1>
constant invariant
arg 0 <addr_expr 0x2a95df62c0
type <pointer_type 0x2a95df5b60 type <array_type 0x2a95dd4ea0>
unsigned DI size <integer_cst 0x2a958acc30 64> unit size
<integer_cst 0x2a958acc60 8>
align 64 symtab 0 alias set -1>
constant invariant
arg 0 <var_decl 0x2a95dd4680 _S_free_list type <array_type
0x2a95dd4ea0> side-effects addressable volatile used public
protected static external nonlocal decl_3 decl_5 decl_6 BLK file
/net/pherkad/scratch/rguenth/gcc-obj2/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/pool_allocator.h
line 91
size <integer_cst 0x2a95a67990 constant invariant 1024>
unit size <integer_cst 0x2a95a5ff30 constant invariant 128>
align 64 context <record_type 0x2a95dd2750 __pool_alloc_base>
chain <var_decl 0x2a95dd2a90 _S_start_free>>>>
which will fail gimplify.c:4403 because the type of the ADDR_EXPR is not
0x2a95dd4b60 like the type of the array element.
I guess this may origin from some stuff in decay_conversion, though
I don't have time to investigate this ATM.
Maybe someone has an idea.
Richard.
--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/