On Mon, Oct 21, 2013 at 3:50 PM, Joerg Sonnenberger <[email protected] > 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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
