<div dir="ltr"><div>This is essentially what I was doing.<br><br></div><div>So that's potentially bad even on x86_64, because optimizations are free to assume the lower order bits of the pointer are zero?<br></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 18, 2013 at 2:04 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Jan 18, 2013 at 4:21 AM, Martin Martin<br>
<<a href="mailto:martin@silverliningsystems.com">martin@silverliningsystems.com</a>> wrote:<br>
> Hi all,<br>
><br>
> sanitize=undefined is giving me an error message about unaligned access to a<br>
> size_t.  It's in a packed structure, and indeed is not 8 byte aligned<br>
> (although it is 4 byte aligned.)  This is in Linux on an x86_64<br>
> architecture.<br>
><br>
> My question is: why is this undefined behavior?  Can't modern Intel and AMD<br>
> processors accesses unaligned ints, although with a possible performance<br>
> penalty?  So this would be a performance problem, but not correctness?  Is<br>
> the problem that the compiler could use SSE or some other instructions that<br>
> require alignment and will seg fault or give wrong results with unaligned<br>
> access?<br>
<br>
</div></div>Please can you provide a code sample which triggers the issue? Packed<br>
structs are supported by -fsanitize=alignment. However, note that<br>
taking the address of a misaligned member of a packed struct will not<br>
in general work:<br>
<br>
struct __attribute__((packed)) S {<br>
  char c;<br>
  long l;<br>
} s;<br>
int f() { return s.l; } // ok<br>
int g() { return *&s.l; } // undefined behavior: long* access requires<br>
8 byte alignment<br>
</blockquote></div><br></div>