Re: [Tinycc-devel] undefined sanitizer

[Vincent Lefevre]

On 2019-06-22 20:59:57 +0200, Michael Matz wrote:
> 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.

Yes, it's implementation defined, but I assume that -fsanitize=undefined
warns only when the implementation has decided that this was incorrectly
aligned.

> Usually that's ultimately dictated by the capabilities of the underlying
> hardware

No, I think that this is a decision from the ABI, which can cover
multiple kinds of hardware (e.g. some processors that can handle
alignment and others that can't). Some compiler options can also
relax requirements. For x86, GCC has -malign-double and -malign-data,
but I don't know how this will have an influence on the expected
requirements (i.e. if it just avoids misaligned accesses for its
generated code or if it also forbids misaligned accesses from how
the C source is written). For instance, the gcc(1) man page says:

           On x86-64, -malign-double is enabled by default.

(this covers "double", "long double" and "long long", but I'm
wondering about other 64-bit types such as pointers, as this
would make sense to have the same rule, IMHO).

> (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.

Yes, that's what might happen and may be the reason why
-fsanitize=undefined complains (it may now know whether the
generated code is actually broken or not, but the UB is a
sufficient condition under which the code may be broken).

> When that actually happens we can revisit, until then I personally
> prefer the space savings.

I'm wondering whether some compiler option (see above) could ensure
that misaligned accesses will not trigger any problem. In this case,
such an option could be recommended to build tcc.

-- 
Vincent Lefèvre <address@hidden> - 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)