https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120135
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2025-05-06
Ever confirmed|0 |1
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Bell from comment #5)
> The emitted warning is somewhat confusing because it doesn't reference the
> constructor, which is where the initialization is missing.
Because the constructor is not where the use happens which is later on. So it
is hard to point back to the constructor (if there is one in some cases).
>
> Also, this generates no warning:
>
> struct S
> {
> int i_;
> double d_;
>
> S() {}
> };
>
> S func()
> {
> return S();
> }
>
> and I'm not sure how returning an uninitialized structure is different from
> assigning it.
It is more likely due to some internal representation that causes the
difference (even with respect to arm vs x86 in this case too; due to target
tuning differences causes slightly difference in
>
> But I understand tracking such uninitialized data is difficult and it's fine
> to close this if you like.
I think it is a bug to track this because GCC should be better at warning in a
decent way.
Part of the problem is nobody has sat down to write down a solution yet and
ever y one else is either working on the improving the front-end (implementing
C++20/23/26/Fortran/etc features) or improving the optimizers. Working on
warnings are one thing which gets pushed back a lot; sometime of the time
improving the optimizers do improve the warnings.
I do hope one day I can sit down and improve some of the recent warnings that
happen due to optimizations but recently I don't have time.
