On Tue, Oct 15, 2013 at 2:07 PM, Chandler Carruth <[email protected]>wrote:
> > On Tue, Oct 15, 2013 at 1:53 PM, Joerg Sonnenberger < > [email protected]> 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
