[llvm-dev] Problem with intrinsic::trap insertion instead of null pointer dereference

[Tim Northover via llvm-dev]

On 21 October 2015 at 05:46, HEITZMANN Frédéric 218168
<llvm-dev at lists.llvm.org> wrote:
> 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:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

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.