<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Dec 16, 2011, at 12:39 PM, Kostya Serebryany wrote:</div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div class="HOEnZb"><div class="h5">> Do we consider the above transformation legal?<br></div></div></blockquote></div></blockquote><div><br></div><div>Yes, the transformation is perfectly legal for the normal compiler.</div><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div class="HOEnZb"><div class="h5">> I would argue that it should not be legal. We don't actually know what<br>
> comes after the 22 byte object. Is it another memory object? A<br>
> memory-mapped I/O device? Unmapped memory? Padded junk space? Reading<br>
> memory-mapped I/O could have nasty side effects, and accessing unmapped<br>
> memory could cause the program to fault even though it was written correctly<br>
> as the source-language level.<br></div></div></blockquote></div></blockquote><div><br></div><div>Device memory accesses need to be done with volatile. This can't cause a paging problem (e.g. causing an additional page fault where none existed before) on systems that use power-of-two sized pages.</div><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div class="HOEnZb"><div class="h5">Having the load hit unmapped memory is impossible on common</div></div>
architectures given the alignment we're talking about here. And if<br>
memory-mapped IO comes after the memory object, the object itself also<br>
has some sort of unusual semantics, so it should be using volatile<br>
loads anyway.<br></blockquote><div><br></div><div>Would would be the right way to disable load widening when AddressSanitizer (or SAFECode) is enabled? </div></div></blockquote><br></div><div>This is a good question. Would it be possible for ASan to do its instrumentation earlier? I supposed we could add a "do not widen" metadata hint on load instructions or something like that.</div><div><br></div><div>-Chris</div><div><br></div><br></body></html>