<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 01/03/2017 05:14 PM, Chandler
Carruth wrote:<br>
</div>
<blockquote
cite="mid:CAGCO0Kgw4qU7G8nyTJKWGpYLNB=Rzisbdu6DNWhXWiYf9-nJtg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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 moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
<br>
I know of some too.<br>
<br>
<blockquote
cite="mid:CAGCO0Kgw4qU7G8nyTJKWGpYLNB=Rzisbdu6DNWhXWiYf9-nJtg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div dir="ltr" class="gmail_msg">
<div class="gmail_quote gmail_msg">
<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.</div>
</div>
</div>
</div>
</blockquote>
<br>
I suspect that essentially everyone with a non-trivially-sized
codebase is in this boat.<br>
<br>
<blockquote
cite="mid:CAGCO0Kgw4qU7G8nyTJKWGpYLNB=Rzisbdu6DNWhXWiYf9-nJtg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div dir="ltr" class="gmail_msg">
<div class="gmail_quote gmail_msg">
<div class="gmail_msg"> 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>
</div>
</div>
</blockquote>
<br>
This definitely seems useful.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAGCO0Kgw4qU7G8nyTJKWGpYLNB=Rzisbdu6DNWhXWiYf9-nJtg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div dir="ltr" class="gmail_msg">
<div class="gmail_quote gmail_msg">
<div class="gmail_msg"><br>
</div>
<div class="gmail_msg">-Chandler</div>
</div>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>