m68k/cpu32 TRAP instruction?

[Segher Boessenkool]

Hi Jeff,

On Sun, Oct 07, 2018 at 01:58:04PM -0600, Jeff Law wrote:
> 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:
> >>> 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.

That sounds great!

So why is it not in -Wall, and even not in -Wextra?  It probably needs
-fisolate-erroneous-paths-dereference but that is on at -O2 already (at
-Os even).


Segher