On 2019-06-23 08:53:33 +0000, Pascal Cuoq wrote: > Indeed. The thing is that such "mis"-alignment isn't generically undefined > behaviour (and hence shouldn't even be part of -fsanitize=undefined). It's > implementation defined what it means for a pointer to an object type to be > correctly aligned (e.g. one where the natural alignment of all types is 1 is > fully conforming). Accessing something via an incorrectly aligned pointer > is undefined, but what incorrectly aligned means is implementation defined.
Yes, but once the "correctly aligned" conditions have been defined by the implementation, if a condition is not met, this falls under -fsanitize=undefined. Note also that the implementation can also decide that some alignment condition is supported but deserves a warning. > Probably everyone has already seen this blog post about GCC > generating code that crashes if pointers to uint32_t are not aligned > to 4, but I will post the URL just in case: > > http://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html This shows again that one should rely on documentation from the implementation (e.g. implementation-defined things) rather that one can normally observe when running the code. Thus -fsanitize=undefined may give warnings even if the generated code actually works. In particular, optimizations can "break" expectations by the user, e.g. due to additional alignment requirement for automatic vectorization or dead-code detection. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
