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

Joerg Sonnenberger joerg at britannica.bec.de
Mon Oct 21 15:50:34 PDT 2013


On Mon, Oct 21, 2013 at 03:42:43PM -0700, Eric Christopher wrote:
> On Mon, Oct 21, 2013 at 12:06 PM, Joerg Sonnenberger
> <joerg at britannica.bec.de> wrote:
> > On Mon, Oct 14, 2013 at 02:45:22PM -0700, Nick Lewycky wrote:
> >> -minline-all-stringops: povray
> >
> > Which version of povray?
> 
> I'd assume the one in testsuite.
> 
> > What I have in pkgsrc includeds a test that the
> > option works. Given that I haven't found a single user and that it won't
> > work in all cases as expected, I would like to see it removed again.
> >
> 
> 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.
-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



More information about the cfe-commits mailing list