Problem with intrinsic::trap insertion instead of null pointer dereference

Hi everyone,

Llvm detects zero pointer dereference in CFG simplify and insert intrinsic::trap (at least with –O1 or –O2).

Problem 1 : I find it unfortunate not to be able to disable it, and allow a specific target to handle it its own way (with MMU fault or dedicated HW stuff).

Is there a trick to avoid this ?

Problem 2 : Unless special care is taken in LLVM backend, DAG select will fail on trap, without a clear indication of the guilty C fragment

Should the frontend emit at least a warning ?

Thanks for your help.

Sorry for meaningless attachments of drafts, Outlook strikes back.

Llvm detects zero pointer dereference in CFG simplify and insert
intrinsic::trap (at least with –O1 or –O2).

Problem 1 : I find it unfortunate not to be able to disable it, and allow a
specific target to handle it its own way (with MMU fault or dedicated HW
stuff).

Is there a trick to avoid this ?

Not for Clang in general. This is a classic instance of C and C++'s
undefined behaviour. If you haven't seen them already, it would be a
good idea to read this series of blog posts:

But the essence is that being able to do this kind of transformation
is essential for the performance of C programs.

Problem 2 : Unless special care is taken in LLVM backend, DAG select will
fail on trap, without a clear indication of the guilty C fragment

Should the frontend emit at least a warning ?

The front-end can't know whether any given memory operation uses a
null pointer. Even where it does find out during compilation, it's
often only as a result of optimisations and we don't want the
diagnostics to depend on whether we're compiling at -O0 or -O3.

I believe Clang's static analysis mode would detect more of these problems.

Cheers.

Tim.