<div dir="ltr"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Jan 3, 2017 at 3:10 PM Hal Finkel via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
    <p class="gmail_msg">On the one hand, GCC has already started optimizing based on the
    nonnull attribute on memcpy, and so that ship has sailed.</p></div></blockquote></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">I know of a large number of libraries that only behave correctly with recent GCCs by using the flag Eli mentioned to disable all nonnull optimizations wholesale. =/</div><div class="gmail_msg"><br></div><div class="gmail_msg">If the standards committees actually change their mind here, I think we could reasonably enable exactly this flag for Clang and LLVM when built with a GCC version not implementing the fix.</div><div class="gmail_msg"><br></div><div class="gmail_msg">And even if not, even if we do actually have to fix all of our code to work in the face of those optimizations, I at least have a large body of users that aren't sure they will ever finish fixing all of these issues. They don't have any good way to test and discover *all* of them, only the ones hit in code paths today. So I'd still like to give them a toolchain that will protect the places in their software where they erroneously relied on a guarantee not provided and have no tests or ability to go and fix.</div><div class="gmail_msg"><br></div><div class="gmail_msg">-Chandler</div></div></div></div>