On 10/6/18 3:12 PM, Segher Boessenkool wrote: > On Sat, Oct 06, 2018 at 01:52:03PM -0600, Jeff Law wrote: >> On 10/5/18 3:53 PM, Segher Boessenkool wrote: >>> On Fri, Oct 05, 2018 at 03:30:47PM -0600, Jeff Law wrote: >>>> On 10/5/18 3:14 PM, Josef Wolf wrote: >>>>> >>>>> - If the compiler can detect such a serious problem, then it should emit a >>>>> warning AT COMPILE TIME. >>>> We don't for various reasons. Frankly, I think we should as well, but I >>>> lost that battle. >>> >>> There is -Wnull-dereference. >> Yea, but our implementation is so lame that it's effectively useless. >> It only warns out of the front-end and only does so for an explicit *0 >> that can be seen without any constant propagation or path isolation. > > Ah, that is not so great :-( Actually, I'll have to correct myself. It looks like we do warn for *0 in the path isolation code, so I guess I was able to push that through back when I wrote the path isolation code. I didn't look to see if it was on by default. > >>> If you want the compiler to warn every time there *could* be a null >>> dereference, well, how many false positives will that be? ;-) >> It's really not bad if you do it late and focus just on whether or not >> you can see a NULL pointer flowing into a dereference. > > If you can see under some given condition there will definitely be a null > deref, then yeah that will be useful. Could put a trap there too. Or > don't do the test for it if not otherwise needed, just warn at compile > time. That's precisely what the path isolation bits do. When they see a NULL as a PHI arg and the result of the PHI is unconditionally dereferenced, we isolate the path with the NULL arg replace the dereference with a trap and let DCE clean things up. jeff
