[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] undefined sanitizer

From: Christian Jullien
Subject: Re: [Tinycc-devel] undefined sanitizer
Date: Sun, 23 Jun 2019 06:51:04 +0200

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

It's nice to have this warning even if implementation supports incorrect 
alignment. Suppose I provide a portable C library which will be compiled with 
on different architectures. As developer, I want what has a high risk to hang 
on machines I'm not even aware of.

For example, double can be misaligned on Intel core i7, but while also 
supported on older generation, misalignment had performance penalty (IIRC first 
i386 generation does not support misaligned doubles).

If I write a code with misaligned double, it will work on my Core i7 and I'll 
push this version with my lib. An ARM user will protest because my lib will do 
a SIGSEGV on its RPi (ARM).

Misalignment is an undefined behavior because a valid code that compiles wo 
error/warning (possibly with the right casts) can:
- works perfectly with no performance penalty
- works perfectly but with a small to very big performance penalty (sometimes 
with OS help as on sparc solaris)
- Do a SIGSEV (as with misaligned doubles on ARM).

Static analyzer as those we find now on VC++, gcc, clang or with external tools 
like splint (I love this one) help to find portability issues.

-----Original Message-----
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=address@hidden] On 
Behalf Of Vincent Lefevre
Sent: Saturday, June 22, 2019 22:29
To: address@hidden
Subject: Re: [Tinycc-devel] undefined sanitizer

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

> 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)

Tinycc-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]