--- Additional Comments From steven at gcc dot gnu dot org 2005-01-01
16:28 ---
Yup, -march=i686 does the trick for me:
$ ./cc1plus t.C -O -m32 -march=i686
A::A()
A::A()
A::A()
B::B(const A&)
B::B(const A&)
B::B(const A&)
void __static_initialization_and_destruction_0(in
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31
16:10 ---
(In reply to comment #5)
> I can still reproduce it with the above testcase:
> gcc version 4.0.0 20041230 (experimental) on i686-pc-linux-gnu.
>
> Maybe it is target dependant?
It is. You might have to use
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-31
16:08 ---
I can still reproduce it with the above testcase:
gcc version 4.0.0 20041230 (experimental) on i686-pc-linux-gnu.
Maybe it is target dependant?
Did you try larger array sizes than 6?
--
http://gcc.gnu
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-31
12:13 ---
I cannot reproduce this (it is monitored??).
I still think something like Andrew's patch is necessary,
but without a test case, well, how can we be sure??
--
What|Removed
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-22
12:43 ---
Looks like fall-out from PR18191. I'll try to take care of this.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21
16:10 ---
sra_hash_tree does not handle RANGE_EXPRs.
This implements them but it might not be the correct approach though:
Index: tree-sra.c
===
RCS fi
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-21
15:30 ---
This is more likely related to a bug which I filed.
--
What|Removed |Added
C
