------- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-18 06:19 -------
First this is a very bogus warning.
Second this is caused by SRA and BIT_FIELD_REF:
D.1509.x = 0;
D.1509.y = 0;
s.p = D.1509;
D.1511_10 = BIT_FIELD_REF <s, 32, 32>;
D.1512_12 = D.1511_10 != 0;
s.i = D.1512_12;
D.1513 = s;
The problem is that SRA does not look into seeing if s.i is needed so it does:
SR.25_11 = 0;
SR.24_26 = 0;
s$p$y_27 = SR.24_26;
s$p$x_28 = SR.25_11;
s.i = s$i_29;
s.p.y = s$p$y_27;
s.p.x = s$p$x_28;
D.1511_10 = BIT_FIELD_REF <s, 32, 32>;
D.1512_12 = D.1511_10 != 0;
s$i_33 = D.1512_12;
s.i = s$i_33;
s.p.y = s$p$y_27;
s.p.x = s$p$x_28;
D.1513 = s;
The wrong code part is not really wrong code, just a misunderstanding of what
the instruction does:
(insn 43 40 49 (set (reg/i:DI 0 ax [ <result> ])
(const_int 0 [0x0])) 81 {*movdi_1_rex64} (insn_list:REG_DEP_TRUE 35
(nil))
(nil))
It sign extends to the full register which means rax is 0 and not just the
bottom part.
Hmm, even the struct aliasing code does not know either:
# VUSE <SFT.3_7>;
# VUSE <SFT.4_8>;
# VUSE <SFT.5_9>;
D.1511_10 = BIT_FIELD_REF <s, 32, 32>;
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rth at gcc dot gnu dot org,
| |dberlin at gcc dot gnu dot
| |org
OtherBugsDependingO| |24639
nThis| |
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|x86_64-pc-linux-gnu |
GCC host triplet|x86_64-pc-linux-gnu |
GCC target triplet|x86_64-pc-linux-gnu |x86_64-*-* i?86-*-*
Last reconfirmed|0000-00-00 00:00:00 |2005-11-18 06:19:39
date| |
Summary|uninitialized structure |[4.0/4.1 Regression]
|member after assignment |uninitialized structure
| |member after assignment
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24931
