[Top][All Lists]

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

Re: [Tinycc-devel] undefined sanitizer

From: Vincent Lefevre
Subject: Re: [Tinycc-devel] undefined sanitizer
Date: Sun, 23 Jun 2019 13:17:58 +0200
User-agent: Mutt/1.12.1+33 (6a74e24e) vl-117499 (2019-06-23)

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

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

reply via email to

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