On 2016.01.19 at 15:23 +0100, Richard Biener wrote: > On Tue, Jan 19, 2016 at 2:18 PM, Trevor Saunders <tbsau...@tbsaunde.org> > wrote: > > On Tue, Jan 19, 2016 at 01:11:44PM +0100, Jan Hubicka wrote: > >> Hi, > >> according to Trevor, the assumption about THIS pointer being non-NULL > >> breaks > > > > That was Markus, not me. > > > >> several bigger C++ packages (definitly including Firefox, but I believe > >> kdevelop was mentioned, too). This patch makes the feature to be > >> controlable > >> by a dedicated flag. I am not sure about the default. We now have ubsan > >> check > >> for the bug so I would hope the codebases to be updated soon, but it did > >> not > >> happen for Firefox for quite a while despite the fact that Martin Liska > >> reported > >> it. > >> > >> This patch defaults to -fno-null-this-pointer, but I would be OK with > >> changing > > > > fwiw I find the naming a bit confusing maybe I'm just tired but it takes > > some puzlling for me to know which way is being strict and which way is > > allowing this. > > > >> the default and setting it on only in GCC 6. Main point of the patch is to > >> avoid need of those packages to be built with > >> -fno-delete-null-pointer-checks > >> (which still subsumes the flag). > > > > Personally I'd rather try and be strict. I suspect it often will be > > easy to find and fix the bugs when the optimization is enabled. Of > > course if some projects don't care they can pass flags themselves. > > Agreed. As we already have a flag that can be used as a workaround I don't > see > a reason to add another more specific one. That just makes it a > lesser incentive > for people to fix their code.
Well, -fno-delete-null-pointer-checks is a big hammer, that disables way to many optimizations than really necessary. -- Markus
