[PATCH] Fix PR c++/42556

Jakub Jelinek jakub@redhat.com
Tue Mar 23 22:19:00 GMT 2010


On Tue, Mar 23, 2010 at 10:58:25PM +0100, Eric Botcazou wrote:
> > We cannot remove the CONSTRUCTOR in C++ front end since it's not empty.
> > But gimplifier does not know v[2] and v[3] have already been initialized
> > by the front end. So after it turns v[0] and v[1] into separate
> > initializations, it doesn't remove the empty CONSTRUCTOR.
> 
> OK, thanks for the detailed explanation.  Could you provide a third testcase 
> that explicitly exercises the latter case?

It is still very fragile and not very general.  Fragility is e.g. in
whether the counted elements initialized separately realy must be not
mentioned in the constructor, and lack of generality in that if you do
A i = { 0, 0, 0, 0};
i.a = 1;
i.b = 2;
i.c = 3;
i.d = 4;
that gcc won't optimize it.  Doing the redundant zero store elimination
optimization on trees would be much more useful.
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00635.html
was my unsuccessful attempt (then I decided to implement it in RTL DSE,
because it was easier).
I still wonder why the optimization isn't able to optimize this on ARM,
perhaps the ARM backend just doesn't set up everything it should
(MEM_SIZE?).

	Jakub



More information about the Gcc-patches mailing list