m68k/cpu32 TRAP instruction?

[Segher Boessenkool]

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 :-(

> > 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.

Such a warning whould be fine for -Wall, too, which makes it a lot more
useful.  If the current implementation is so restricted, why is it not
in -Wall?  It shouldn't give many fals positives?

> I'd certainly agree that it'd be too noisy to warn if you had a random
> pointer of unknown value that gets dereferenced.  It could be zero and
> warning for all those would be useless in practice.

Yeah exactly :-)


Segher