Hi,
On Sat, 22 Jun 2019, Vincent Lefevre wrote:
> I keep having fun.
> In attach compile report under -fsanitize=undefined in gcc or clang.
> Take care.
I don't think we should care about alignment of 4 (when 8 would be needed).
The 64bit platforms we support all handle misaligned memory accesses quite
fine, and doing it "correctly" just wastes space.
Even if there are no issues with the processor, undefined behavior
may yield the generation of bad code due to optimizations.
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.
Usually that's ultimately dictated by the capabilities of the underlying
hardware (and not by -fsanitize when it ignores those capabilities!).
Our hosts support alignment of 4 even for 8byte quantities.
Now, you do have a point in that some compilers assume larger natural
alignment (e.g. that a void* has alignment 8), and that there are
transformations like bit propagation of low bits of addresses, or
vectorization making use of instructions actually requiring large
alignment, that might be affected by assumptions about alignment, leading
to wrong code when those assumptions are violated. When that actually
happens we can revisit, until then I personally prefer the space savings.
Ciao,
Michael.
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
