r192521 - Add missing flags -fexpensive-optimizations and -minline-all-stringops as noops.

[Richard Smith]

On Tue, Oct 15, 2013 at 2:07 PM, Chandler Carruth <chandlerc at google.com>wrote:

>
> On Tue, Oct 15, 2013 at 1:53 PM, Joerg Sonnenberger <
> joerg at britannica.bec.de> wrote:
>
>> On Mon, Oct 14, 2013 at 04:58:55PM -0700, Chandler Carruth wrote:
>> > Whether it is correct or not, people were not using
>> -minline-all-stringops
>> > to avoid calling out to libc for them, they were using it as equivalent
>> to
>> > -O9 or whatever. =/ By ignoring this flag we correctly compile a
>> nontrivial
>> > amount of code out there.
>>
>> My gut instinct tells me that it might be the path of least resistence
>> to silently accept -fexpensive-optimisations, but that it doesn't make
>> sense to give -minline-all-stringops the same threatment. I am going to
>> run some field study now to verify the intuition. I can already say that
>> there are a number of wtf moments ahead...
>
>
> For the record, we ran plenty of field experiments ourselves. We have had
> no problems with this.
>
> 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.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131015/1d5b4d67/attachment.html>