https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115770
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |INVALID
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Manuel Köppen from comment #5)
> Even if something is "undefined", the compiler should not output broken
> code, without any warning (nothing, even with -pedantic).
No undefined code means anything can happen. And most compilers can't always
warn about undefined code especially when it is not ever executed.
>
> The optimizer is optimizing out my perfectly fine asm volatile block, just
> because it thinks the value passed to it is undefined? Then he replaces it
> with an invalid instruction. I struggle to even call this an optimization!
It is not fine. as
>
> The standard does not actually define reading memory at address 0 as
> undefined, because NULL and 0 don't necessarily need to be the same (athough
> they almost always are).
Well kinda of. it is undefined to access NULL addresses and for all GCC targets
NULL is 0 address (the exception is dealing with address spaces but that is not
the topic here).
>
> Following your argumentation, when an undefined value from stack is used,
> also this udf opcode should be inserted, to be consistent.
Well that is unspecified value rather than undefined. THere is a slight
difference. Plus GCC does insert traps for some other undefined code but not
all. And even some code that depends on undefined code dealing with aliasing
GCC might produce code that will work based on type based aliasing but not work
for what the user had (incorrectly) expected.
See https://blog.regehr.org/archives/213 for more information on undefined
code.
Oh one more thing, the asm block in this case comes after the undefined code so
it just happens to be removed because the undefined code happens and is
replaced with traps.
