https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91358
Michael Matz <matz at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |matz at gcc dot gnu.org
--- Comment #1 from Michael Matz <matz at gcc dot gnu.org> ---
No wrong code involved here. The uninitialized register that valgrind
complains
about is only uninitialized in exactly the case when %ebp (aka .m_initialized)
is zero. So the insn sequence
=> 0x00000000004007af <+31>: test %rbx,%rbx
0x00000000004007b2 <+34>: je 0x4007b9 <process(optional<NoPtr1>)+41>
0x00000000004007b4 <+36>: test %bpl,%bpl
0x00000000004007b7 <+39>: jne 0x4007c0 <process(optional<NoPtr1>)+48>
0x00000000004007b9 <+41>: add $0x8,%rsp
goes to 0x4007b9 no matter what. (if %rbx==uninit happens to be zero, then
directly, otherwise via the not-taken jump at 0x4007b7, because %ebp is zero).
The read from the uninitialized memory itself (from .ptr) is harmless as well,
because the memory backing that access must be there, as the structure is
large enough.
So, if you've seen a real problem somewhere (and not just valgrind complaining
about uninitialized registers in comparisons), then you've reduced the testcase
too much. (The abort() in the testcase leads me to think that this was once
a larger testcase where the abort was triggered unexpectedly. I'll note that
it isn't triggered with this testcase.)
