------- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-10 11:29 -------
This is an aliasing problem (or rather a C++ FE problem):
# SFT.41_31 = VDEF <SFT.41_30(D)>
d.D.2508.a = 0;
x.0_10 = (struct A *) &d;
...
D.2747_16 = x.0_10 + D.2746_15;
# VUSE <SFT.44_27>
D.2748_17 = D.2747_16->a;
D.2749_18 = D.2748_17 + 1;
# SFT.44_34 = VDEF <SFT.44_27>
D.2747_16->a = D.2749_18;
# VUSE <SFT.41_31>
D.2707_1 = d.D.2508.a;
D.2706_2 = D.2707_1 != 1;
return D.2706_2;
note how we don't identify the contrived access through the virtual base
with the zero-initialization and use in main(). Instead, it seems to
alias with
iftmp.1_6 = (int (*__vtbl_ptr_type) (void) *) D.2735_5;
# SFT.44_21 = VDEF <SFT.44_20(D)>
d.D.2504._vptr.C = iftmp.1_6;
...
# SFT.44_27 = VDEF <SFT.44_21>
d.D.2504._vptr.C = &_ZTV1D[3];
Of course the original trees created for the virtual base access is
"somewhat" contrieved:
(void) ((struct A *) (struct D *) x + (long unsigned int) *(long int *)
(((struct D *) x)->D.2504._vptr.C + 0xffffffffffffffffffffffffffffffe8))->a++ ;
while in main() we manage to do:
struct D d;
<<cleanup_point <<< Unknown tree: expr_stmt
__comp_ctor (&d) >>>
>>;
<<cleanup_point <<< Unknown tree: expr_stmt
(void) (d.D.2508.a = 0) >>>
>>;
<<cleanup_point <<< Unknown tree: expr_stmt
h ((struct D &) &d) >>>
>>;
return <retval> = d.D.2508.a != 1;
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dberlin at gcc dot gnu dot
| |org, rguenth at gcc dot gnu
| |dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target triplet|arm-none-eabi |
Keywords| |alias, wrong-code
Known to fail| |4.2.0 4.2.1 4.3.0
Known to work| |4.1.2
Last reconfirmed|0000-00-00 00:00:00 |2007-07-10 11:29:31
date| |
Summary|Wrong code generation. |[4.2/4.3 Regression] Wrong
|Inlining problem. |code generation. Alias and
| |C++ virtual bases problem.
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
