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

Reid Kleckner rnk at google.com
Mon Oct 21 16:10:01 PDT 2013


On Mon, Oct 21, 2013 at 3:50 PM, Joerg Sonnenberger <joerg at britannica.bec.de
> wrote:

> > That's pretty problematic now that we're erroring on unsupported -m
> > options where we weren't before and changing all of the code in the
> > world to get rid of their unfortunate use of compiler options is a bit
> > extra for work. Basically I think this patch is only going back to the
> > previous behavior and should be fine. Now, I agree that deciding
> > whether or not we want to implement this and how we should is
> > important, but I don't know that this is worth holding up things for
> > since in the freestanding world you'll have an unresolved symbol at
> > link time and otherwise we error out on code that we would
> > successfully compile in the past?
>
> There are various changes in clang that break building software all the
> time. Please, let's not try to create a GCC wrapper that is just
> dropping hundreds of random flags because one person in the past decided
> that it would be a good idea to fine tune compilation.
>

What you just outlined is basically a design goal of the clang driver.
 Dropping hundreds of useless flags that somebody added 10 years ago is a
feature, not a bug.  I'd link you to mail supporting this point, but my
search skills are failing me.

People have talked about creating a pure clang driver that doesn't do this,
but it hasn't really gone anywhere.


> -fexpensive-optimisations and -fstrength-reduce are at least somewhat
> wildly used. Both are bad enough understood that making them nops is
> harmless. From the large list I posted in the other thread, I don't
> think that holds for most of the other options and I don't think those
> are popular enough to justify it either.
>
> Joerg
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131021/aa2bbe18/attachment.html>


More information about the cfe-commits mailing list