On Mon, Mar 9, 2020 at 12:36 PM Joerg Sonnenberger <jo...@bec.de> wrote: > > On Mon, Mar 09, 2020 at 09:50:50AM -0400, Aaron Ballman wrote: > > On Sun, Mar 8, 2020 at 2:30 PM Taylor R Campbell > > > I ask because in principle a conformant implementation could compile > > > the NetBSD kernel into a useless blob that does nothing -- we rely on > > > all sorts of behaviour relative to a real physical machine that is not > > > defined by the letter of the standard, like inline asm, or converting > > > integers from the VM system's virtual address allocator into pointers > > > to objects. But such an implementation would not be useful. > > > > Whether an optimizer elects to use this form of UB to make > > optimization decisions is a matter of QoI. My personal feeling is that > > I don't trust this sort of optimization -- it takes code the > > programmer wrote and makes it behave in a fundamentally different > > manner. I'm in support of UBSan diagnosing these constructs because it > > is UB and an optimizer is definitely allowed to optimize based on it > > but I wouldn't be in support of an optimizer that aggressively > > optimizes on this. > > I consider it as something even worse. Just like the case of passing > NULL pointers to memcpy and friends with zero as size, this > interpretation / restriction in the standard is actively harmful to some > code for the sake of potential optimisation opportunities in other code. > It seems to be a poor choice at that. I.e. it requires adding > conditional branches for something that behaves sanely everywhere but > may the DS9k.
+1 -- I'm personally not a fan of allowing these kinds of optimizations. I refer to the entire class of similar operations as "exploiting undefined behavior" for this reason. ~~Aaron > > Joerg