[Bug middle-end/38851] [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #15 from rguenther at suse dot de  2009-01-25 19:59 -------
Subject: Re:  [4.4 regression] Compiler warns about
 uninitialized variable that is an object with a constructor

On Sun, 25 Jan 2009, mmitchel at gcc dot gnu dot org wrote:

> ------- Comment #14 from mmitchel at gcc dot gnu dot org  2009-01-25 19:45 -------
> Richard --
> 
> I don't agree that it's necessarily the FE's job to omit all stores to such
> types.  Our general theory is that FEs get to emit dumb code and the optimizers
> get to fix it up.  Of course, I don't object to making the FE generate simpler
> code, if that's easy to do; just that if our design relies on that, I think
> that's a mistake.

Oh, I agree.  See my attempt to fix it during gimplification.

> I can imagine ways this could come up in other languages as well.  For example,
> copying a C structure with an anonymous bit-field, but no other content, or an
> Ada record that uses Ada's layout directives to control size.
> 
> Therefore, I don't think that the key here is "zero-size".  Instead, it's the
> fact that structure cannot be initialized.  That's useful both for warnings and
> for optimization; it can't be initialized, so there's no point about warning
> about uninitialized uses, and there's no reason to actually generate code for
> the copies.

Ok, I think mapping cannot be initialized to zero-size is ok, as that is
the only thing we can currently query (and we even specialize this
for C++ to deal with the 1 byte vs. empty case).

> That leads to something I do think is something that the FEs could be asked to
> do: set a bit on the type to indicate that it is uninitializable or, if you
> like, logically empty.
> 
> I also don't see this as a P1 defect.  It's certainly annoying, but,
> fundamentally, it limits the utility of a warning which has been known to give
> false positives for a long time.  Important to fix, yes -- but as important as
> generating wrong code?

It's a P1 defect as we didn't warn for uninitialized structure
uses in any previous relelase.  While we can argue that it is safe
to downgrade this to P2 I think we should at least try to fix this
issue for 4.4.0.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38851