Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski: > On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc <gcc@gcc.gnu.org> wrote: > > > > Hi Richard, > > > > I have a question regarding reodering of volatile > > accesses and trapping operations. My initial > > assumption (and hope) was that compilers take > > care to avoid creating traps that are incorrectly > > ordered relative to observable behavior. > > > > I had trouble finding examples, and my cursory > > glace at the code seemed to confirm that GCC > > carefully avoids this. But then someone showed > > me this example, where this can happen in GCC: > > > > > > volatile int x; > > > > int foo(int a, int b, _Bool store_to_x) > > { > > if (!store_to_x) > > return a / b; > > x = b; > > return a / b; > > } > > > > > > https://godbolt.org/z/vq3r8vjxr > > The question becomes what is a trapping instruction vs an undefined > instruction? > For floating point types, it is well defined what is a trapping > instruction while for integer types it is not well defined. > On some (many?) targets dividing by 0 is just undefined and does not > trap (powerpc, aarch64, arm and many others; MIPS it depends on the > options passed to GCC if the conditional trap should be inserted or > not).
> The other side is if there is undefined code on the path, should > observable results happen first (stores to volatile/atomics, etc.)? I think for volatile stores and I/O, I think it would be nice of we could guarantee that those happen before the UB ruins the day. (I am not sure about atomics, those are not directly obsevable) For I/O this is probably already the case (?). For volatile, it seems this would need some tweaks. I am trying to figure out whether this is feasible. > GCC assumes by default that divide is trappable but stores not are not > observable. This is where -fnon-call-exceptions come into play. Ok, thanks! I will look at this! > In the second case, GCC assumes reducing trappable instructions are > fine. -fnon-call-exceptions would treat trapping instructions as defined (and trapping) instead of UB? This is then probably even stronger than the requirement above. > Note I thought -fno-delete-dead-exceptions would fix the sink > but it didn't. Martin