Hi, so I am not sure what is the consensus. Here are my two cents. I added the code motivated by looking into multiple inheritance code, where we often wind to
if (this != null) foo = this + offset; else foo = NULL; which is redundant. I built libreoffice+LTO with and without this change and get the following text data bss dec 61207687 3461668 480368 65149723 trunk 60849535 3461612 480496 64791643 disabling special code for THIS 60599827 3461612 480496 64541935 -fno-delete-null-pointer-checks I.e. about 0.6% code size increase for this analysis ;) This reproduce over other libreoffice's libraries. While it is not goal of this optimization to increase the size of libreoffice binary, I would say that the new coe seems surprisingly active on this codebase (more than I would expect for one liner of this type). I think it makes sense to shoot towards making this a default and convincing users to clean the codebases. Given that we already have sanitizer feature for few releases reporitng this (I believe, did not double check), having flag disabled for this release and enabled for next is only delaying the trouble by a year. I don't see much extra pain in maintaining this flag and we may document it as meant for transition and that it will be obsoletted eventually. If I imagine I was a maintainer of a package that breaks now, I think I would find an explicit flag in Makefile a decade later more infrmative than having -fno-delete-null-pointer-checks but no longer being sure if my codebase doesn't break the rule some other way. So if we get into consensus that we want flag I will be happy to take care of the patch (there was suggestion for better name that I can't find right now). If we decide to get w/o a flag I am happy with current status where the situation is documented in the changes.html and porting document and there is well defined workaround. Honza
