<div dir="ltr">On Tue, Oct 15, 2013 at 2:07 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Oct 15, 2013 at 1:53 PM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On Mon, Oct 14, 2013 at 04:58:55PM -0700, Chandler Carruth wrote:<br>


> Whether it is correct or not, people were not using -minline-all-stringops<br>
> to avoid calling out to libc for them, they were using it as equivalent to<br>
> -O9 or whatever. =/ By ignoring this flag we correctly compile a nontrivial<br>
> amount of code out there.<br>
<br>
</div>My gut instinct tells me that it might be the path of least resistence<br>
to silently accept -fexpensive-optimisations, but that it doesn't make<br>
sense to give -minline-all-stringops the same threatment. I am going to<br>
run some field study now to verify the intuition. I can already say that<br>
there are a number of wtf moments ahead...</blockquote></div><br></div></div><div class="gmail_extra">For the record, we ran plenty of field experiments ourselves. We have had no problems with this.</div><div class="gmail_extra">


<br></div><div class="gmail_extra">And in fact, I'm moderately confident we wont run into any *new* ones because as Nick pointed out ages ago in this thread, Clang used to ignore this flag, and every clang release has ignored this flag! We have never released a Clang compiler which rejected this flag.</div>

</div></blockquote><div><br></div><div>Right. Instead of thinking about this change making us silently accept -minline-all-stringops, let's think about this change plus r191328 adding diagnostics for all *other* unknown -m options. I don't think anyone is claiming that in the long term we should keep silently ignoring -minline-all-stringops, but r191328 introduces a regression without this patch, reverting r191328 is worse than keeping this change, and there aren't really any other options on the table for the immediate future.</div>

</div></div></div>