https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115770
Manuel Köppen <manuel.koeppen at gmx dot de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |FIXED
--- Comment #3 from Manuel Köppen <manuel.koeppen at gmx dot de> ---
I checked and...
You are right, using -fno-delete-null-pointer-checks "fixes" the problem.
Using a different address also fixes the problem, but I cannot do that, because
I have to read at 0.
I think this is at least not obvious.
The compiler is not deleting null-pointer-checks in this case, but rather
deleting my volatile asm block and replacing it with undefined code.
Is it, that without the option no-delete-null-pointer-checks the compiler
thinks, I am coding something with undefined behaviour and so it takes the
freedom to present something that crashes as undefined behaviour?
What I don't get is how this is only done at optimization level 2 and there is
absolutely no warning whatsoever, just the code that uses the seemingly
undefined value replaced by a crashing instruction? After all, the
dereferencing of NULL ( e.g. ldr r0, [r4] ) is left in, only the use of the
value is changed. I find this behaviour pretty strange. From the name of the
option I never would have guessed that this is even influencing this code
generation here, because there are no null-pointer checks to begin with.
So you're saying this is intentional and I just have to add
-fno-delete-null-pointer-checks to all microcontroller firmawares where 0 is a
valid address?
