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 #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Manuel Köppen from comment #3)
> 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?
Correct it is undefined.
>
> What I don't get is how this is only done at optimization level 2
Because it is only enabled at -O2 and above (in similar fashion as strict [type
based] aliasing).
> 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?
YES. because C says deferencing null pointers is undefine behavior.
