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

Nick Lewycky nlewycky at google.com
Mon Oct 14 16:53:27 PDT 2013


On 14 October 2013 15:25, Joerg Sonnenberger <joerg at britannica.bec.de>wrote:

> On Mon, Oct 14, 2013 at 02:45:22PM -0700, Nick Lewycky wrote:
> > As a practical matter, I'm adding these so that I can continue to build
> > software that used to build. They're marked clang_ignored_[fm]_Group so
> > that we can find which flags aren't implemented.
>
> I have a certain issue with adding misguided flags that might have made
> seen two decades ago and got C&P around.


GCC compatible driver.

 > I'm not sure what you're saying -- are you arguing that implementing
> > -minline-all-stringops is dangerous, or that silently ignoring
> > -minline-all-stringops is dangerous?
>
> Silently ignoring it is wrong. The behavior it is supposed to provide is
> not available.
>

I'm restoring behaviour after r191328/191394 -- it makes more sense if you
think of this patch as being a part of those patches. We're moving from
silently accepting all unknown flags to a whitelist of known gcc flags
which we'll silently ignore. This keeps us closer to honest by documenting
in the .td file which flags we know we don't implement. It's a step in the
right direction.

The alternative is to revert r191328 and r191394, and go back to silently
allowing all flags. Breaking builds that used to work really isn't
acceptable. If I had known in advance how long it would take to find all
the unsupported flags in my build, I would have reverted.

Longer term, we should implement the ones that are sensible and warn on the
ones that aren't.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131014/df6dcf44/attachment.html>


More information about the cfe-commits mailing list