<div dir="auto"><div>Sounds great!<br><div class="gmail_extra"><br><div class="gmail_quote">On Mar 22, 2017 5:22 AM, "Chandler Carruth" <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">FYI, this is landed in r298491; thanks for the reviews.<div><br></div><div>I'm hoping to have papers for standards bodies (and also useful for libc maintainers) by next week.</div></div><div class="elided-text"><br><div class="gmail_quote"><div dir="ltr">On Sat, Mar 18, 2017 at 2:36 AM Philip Reames <<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000" class="m_-1654382616947296291gmail_msg">
<div class="m_-1654382616947296291m_8972152876394780548moz-cite-prefix m_-1654382616947296291gmail_msg">I'm in support of unblocking the LLVM
side optimization changes. I'm definitely not qualified to speak
towards the direction of the clang changes though. :)</div></div><div bgcolor="#FFFFFF" text="#000000" class="m_-1654382616947296291gmail_msg"><div class="m_-1654382616947296291m_8972152876394780548moz-cite-prefix m_-1654382616947296291gmail_msg"><br class="m_-1654382616947296291gmail_msg">
<br class="m_-1654382616947296291gmail_msg">
Philip</div></div><div bgcolor="#FFFFFF" text="#000000" class="m_-1654382616947296291gmail_msg"><div class="m_-1654382616947296291m_8972152876394780548moz-cite-prefix m_-1654382616947296291gmail_msg"><br class="m_-1654382616947296291gmail_msg">
<br class="m_-1654382616947296291gmail_msg">
On 03/16/2017 03:39 PM, Chandler Carruth via cfe-dev wrote:<br class="m_-1654382616947296291gmail_msg">
</div></div><div bgcolor="#FFFFFF" text="#000000" class="m_-1654382616947296291gmail_msg">
<blockquote type="cite" class="m_-1654382616947296291gmail_msg">
<div dir="ltr" class="m_-1654382616947296291gmail_msg">Are there blockers to landing <a href="https://reviews.llvm.org/D30806" class="m_-1654382616947296291gmail_msg" target="_blank">https://reviews.llvm.<wbr>org/D30806</a> ?
<div class="m_-1654382616947296291gmail_msg"><br class="m_-1654382616947296291gmail_msg">
</div>
<div class="m_-1654382616947296291gmail_msg">I'm committed to following through with the respective
standards bodies and anyone else we feel is prudent, but I
would somewhat like to unblock the optimization work in this
area in parallel as I suspect that the communication and
establishment of a rational plan will require a lot of time.</div>
</div>
<br class="m_-1654382616947296291gmail_msg">
<div class="gmail_quote m_-1654382616947296291gmail_msg">
<div dir="ltr" class="m_-1654382616947296291gmail_msg">On Tue, Mar 14, 2017 at 2:54 PM Chandler Carruth
via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="m_-1654382616947296291gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a>>
wrote:<br class="m_-1654382616947296291gmail_msg">
</div>
<blockquote class="gmail_quote m_-1654382616947296291gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="m_-1654382616947296291gmail_msg">I'm happy to handle at least
the standards side of this; I don't really have great
connections on the libc front, but happy to help folks do
that.</div>
<br class="m_-1654382616947296291gmail_msg">
<div class="gmail_quote m_-1654382616947296291gmail_msg">
<div dir="ltr" class="m_-1654382616947296291gmail_msg">On Tue, Mar 14, 2017 at
2:35 PM James Y Knight <<a href="mailto:jyknight@google.com" class="m_-1654382616947296291gmail_msg" target="_blank">jyknight@google.com</a>> wrote:<br class="m_-1654382616947296291gmail_msg">
</div>
<blockquote class="gmail_quote m_-1654382616947296291gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="m_-1654382616947296291gmail_msg">
<div class="gmail_extra m_-1654382616947296291gmail_msg">
<div class="gmail_quote m_-1654382616947296291gmail_msg">Just to
reiterate...</div>
<div class="gmail_quote m_-1654382616947296291gmail_msg"><br class="m_-1654382616947296291gmail_msg">
</div>
<div class="gmail_quote m_-1654382616947296291gmail_msg">I would really like
to see us communicate this decision, with an
appropriately persuasive argument, both to the glibc
authors and to the standards committees, and treat
this as a *transitional* hack, which is needed until
glibc (and any other libc if there are any?) can
remove the erroneous nonnull declarations from their
headers, and everyone has upgraded.</div>
</div>
</div>
<div dir="ltr" class="m_-1654382616947296291gmail_msg">
<div class="gmail_extra m_-1654382616947296291gmail_msg">
<div class="gmail_quote m_-1654382616947296291gmail_msg"><br class="m_-1654382616947296291gmail_msg">
</div>
<div class="gmail_quote m_-1654382616947296291gmail_msg">On Thu, Mar 9, 2017
at 11:04 PM, Chandler Carruth <span dir="ltr" class="m_-1654382616947296291gmail_msg"><<a href="mailto:chandlerc@google.com" class="m_-1654382616947296291gmail_msg" target="_blank">chandlerc@google.com</a>></span>
wrote:<br class="m_-1654382616947296291gmail_msg">
<blockquote class="gmail_quote m_-1654382616947296291gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="m_-1654382616947296291gmail_msg">I've sent a patch
to implement this here: <a href="https://reviews.llvm.org/D30806" class="m_-1654382616947296291gmail_msg" target="_blank">https://reviews.llvm.<wbr>org/D30806</a>
<div class="m_-1654382616947296291gmail_msg"><br class="m_-1654382616947296291gmail_msg">
</div>
<div class="m_-1654382616947296291gmail_msg">It turns out to be both
easier and I hope less controversial than I
had imagined. Neither Clang nor LLVM ever
actually got nonnull onto these declarations
even when they were suitable annotated. We
didn't carry that annotation across to the
declaration. Oops.</div>
<div class="m_-1654382616947296291gmail_msg"><br class="m_-1654382616947296291gmail_msg">
</div>
<div class="m_-1654382616947296291gmail_msg">So I've fixed that, but
*also* disabled it for the libc functions that
we have library builtin recognition for. We
can extend this to cover any set of library
functions folks want, just let me know. The
use of it will even be correctly controlled by
-fno-builtin and friends.</div>
<div class="m_-1654382616947296291gmail_msg"><br class="m_-1654382616947296291gmail_msg">
</div>
<div class="m_-1654382616947296291gmail_msg">The net result is that
this should not regress optimizations for
*anyone*, and actually enable a bunch of
optimizations outside of libc functions, while
preserving safety on those libc functions.</div>
<div class="m_-1654382616947296291gmail_msg"><br class="m_-1654382616947296291gmail_msg">
</div>
<div class="m_-1654382616947296291gmail_msg">We still have the
nullability attributes which can be used to
annotate more interfaces in a way that will
provide warnings and static analysis aid, but
not optimize on and so not run the risk of
changing behavior of existing code. Those
would be good candidates (IMO) for libc++ to
use on any relevant interfaces which match the
criteria outlined in this thread: pointers
paired with a size should allow null+zero.</div>
<div class="m_-1654382616947296291gmail_msg"><br class="m_-1654382616947296291gmail_msg">
</div>
<div class="m_-1654382616947296291gmail_msg">Hopefully this makes
everyone happy, please feel free to chime in
on the review thread if more discussion is
needed.</div>
</div>
<br class="m_-1654382616947296291gmail_msg">
<div class="gmail_quote m_-1654382616947296291gmail_msg">
<div class="m_-1654382616947296291gmail_msg">
<div class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753h5 m_-1654382616947296291gmail_msg">
<div dir="ltr" class="m_-1654382616947296291gmail_msg">On Wed, Jan
4, 2017 at 11:24 AM Aaron Ballman via
cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="m_-1654382616947296291gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a>>
wrote:<br class="m_-1654382616947296291gmail_msg">
</div>
</div>
</div>
<blockquote class="gmail_quote m_-1654382616947296291gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="m_-1654382616947296291gmail_msg">
<div class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753h5 m_-1654382616947296291gmail_msg">On Wed, Jan 4, 2017 at 2:01 PM,
James Y Knight <<a href="mailto:jyknight@google.com" class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg" target="_blank">jyknight@google.com</a>>
wrote:<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> On Wed, Jan 4, 2017 at 12:54 PM, Hal
Finkel <<a href="mailto:hfinkel@anl.gov" class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg" target="_blank">hfinkel@anl.gov</a>>
wrote:<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>> On 01/04/2017 11:43 AM, James Y
Knight via cfe-dev wrote:<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>> On Wed, Jan 4, 2017 at 11:12 AM,
Aaron Ballman via cfe-dev<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>> <<a href="mailto:cfe-dev@lists.llvm.org" class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a>>
wrote:<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>>><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>>> So I would be opposed to
ignoring those attributes in<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>>><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>>> Sema (I think we should still
warn when users do nonportable things),<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>>> but in favor of not changing
the optimizer to capitalize on this<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>>> "opportunity."<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>> I'd be opposed to ignoring the
attributes only in some places and not in<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>> others. It should be ignored
totally, as if it wasn't present on those<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>> functions. Doing anything else
sends the wrong message -- that libc
authors<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>> should continue to use nonnull on
these functions because they might be<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>> helpful, and won't do anything
bad.<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>> I think that we have a
responsibility to our users to continue to
warn<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>> (statically, in ubsan, etc.) on
non-portable behavior, which this is and<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>> will continue to be in practice
for at least a decade or two, regardless
of<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>> the message we'd like to send
libc authors. We cannot undo history here
and<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>> this will be relevant to
production systems for at least a decade.
We can<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>> talk to libc developers directly
-- they're a much smaller set -- and we
can<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>> pursue change at the standards
level while still providing the most
useful<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
>> set of tools to our users in the
mean time.<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> But, this is an entirely different
question.<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> - Should clang warn about
non-portable usage of passing NULL to
memcpy/etc?<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> Sounds like a fine warning to add.<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> - Should that warning be dependent on
the libc headers having nonnull<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> annotations on these functions, which
will be used only for warnings, and<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> ignored for semantics, on this given
list of hardcoded functions?<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> No.<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> Firstly: I'd note that nearly all
libc implementations don't use these<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> attributes today. In some cases,
because they've simply not thought about<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> it, but in others because they
explicitly decided to NOT break their
users'<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> code by introducing this problem!
Glibc is the outlier, here.<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> So: what portability do you want to
warn for? Portability assuming the same<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> libc, but a different compiler which
might fail to ignore the nonnull<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> attribute? Or portability to other
libc? If the latter, depending on the<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> nonnull attribute being present
doesn't and can't work.<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
My preference is for portability for both,
but you bring up a good<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
point about other libc implementations not
being annotated. So long as<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
we retain the ability to tell users their
code is not portable *and*<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
we get rid of the dangerous optimizations,
I'm happy. I just don't<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
want to lose the diagnostics because of
the optimizations.<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
~Aaron<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> Secondly: if we already have a
hardcoded list of functions to special
case,<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> that could just as well be used to
generate a nonportable-stringfunc-null<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
> warning, as well.<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
</div>
</div>
<span class="m_-1654382616947296291gmail_msg">
______________________________<wbr>_________________<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
cfe-dev mailing list<br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
<a href="mailto:cfe-dev@lists.llvm.org" class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br class="m_-1654382616947296291m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg m_-1654382616947296291gmail_msg">
</span></blockquote>
</div>
</blockquote>
</div>
<br class="m_-1654382616947296291gmail_msg">
</div>
</div>
</blockquote>
</div>
______________________________<wbr>_________________<br class="m_-1654382616947296291gmail_msg">
cfe-dev mailing list<br class="m_-1654382616947296291gmail_msg">
<a href="mailto:cfe-dev@lists.llvm.org" class="m_-1654382616947296291gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a><br class="m_-1654382616947296291gmail_msg">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" class="m_-1654382616947296291gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br class="m_-1654382616947296291gmail_msg">
</blockquote>
</div>
<br class="m_-1654382616947296291gmail_msg">
<fieldset class="m_-1654382616947296291m_8972152876394780548mimeAttachmentHeader m_-1654382616947296291gmail_msg"></fieldset>
<br class="m_-1654382616947296291gmail_msg">
<pre class="m_-1654382616947296291gmail_msg">______________________________<wbr>_________________
cfe-dev mailing list
<a class="m_-1654382616947296291m_8972152876394780548moz-txt-link-abbreviated m_-1654382616947296291gmail_msg" href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
<a class="m_-1654382616947296291m_8972152876394780548moz-txt-link-freetext m_-1654382616947296291gmail_msg" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<p class="m_-1654382616947296291gmail_msg"><br class="m_-1654382616947296291gmail_msg">
</p>
</div></blockquote></div>
</div></blockquote></div><br></div></div></div>