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.