https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Miko Vich <alexmudmiko at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |alexmudmiko at gmail dot com
--- Comment #56 from Miko Vich <alexmudmiko at gmail dot com> ---
I think Jeff is correct. While I have no experience with writing compilers,
I've been wrestling with this "feature" for about 3 years now. What's odd is
that it doesn't always manifest. It also seems to be restricted (at least in
my cases) to using std::optional with POD or enum types. Also, the volatile
thingy doesn't solve the issue if sizeof(T) is less than 16 bytes. (Again my
experience.)
Anyway... some findings which I think support Jeff's comment: about a year ago
I went so far as to memset to zero the memory in std::optional for sizeof(T).
This made the warning go away... defeats the purpose of optional of course, but
no more warning. But on inspecting the assembly generated, there was no
zero-ing of the memory (or any other assignment to 0). So the optimizer no
longer error'd on maybe-uninitialized, but knew enough to elide away the
memset.
So... is this maybe a case of the warning simply being emitted too soon in the
passes, i.e., before its completely finished optimizing? Because even without
the memset change, the final assembly generated under -O3 never has a path
where the value in the optional is accessed when uninitialized.
