https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126554
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The current behavior is what is documented, according to the chosen model after
some optimizations (GIMPLE passes), the function is checked whether it has any
addressable objects of the vulnerable category (based on exact option) and if
it has, it is instrumented, if it doesn't, it is not.
In the second function, GIMPLE passes do optimize it into something that
doesn't have such addressable objects, so it is not protected.
In the first function, that is not the case (can't, we don't support
COMPLEX_TYPE with RECORD_TYPE as element type). What is in the IL at expansion
time does use the addressable memory, stores to it, reads from it, if you'd
actually say return expected afterwards it would adjust it based on the atomic
operation, then read again.
During expansion is the point where we do emit the stack protector
instrumentation.
Later optimization passes partially optimize some of this away (but only some
of it, e.g. the stack allocation isn't optimized away (very long time ago we
had during expansion a way to do conditional stack allocations which very soon
could be optimized away if they actually didn't need to be addressed, but with
the addition of tree-ssa that was shortly afterwards removed, in the common
case GIMPLE passes optimize away addressable vars that aren't needed to be
addressable.
Now, consider a different case, a struct with say 67 bytes, in that case there
will be a libatomic call. Are you also suggesting we shouldn't instrument that
either? Create a list of calls which are considered always correct and where
we think it is impossible to trigger buffer overflow?
