[cfe-dev] [llvm-dev] RFC: Implementing -fno-delete-null-pointer-checks in clang

James Y Knight via cfe-dev cfe-dev at lists.llvm.org
Thu Apr 19 18:12:04 PDT 2018

On Wed, Apr 18, 2018 at 3:54 PM Tim Northover via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> > Despite the name, the flag actually has rather straightforward semantics
> > from the compiler's perspective.  From the gcc docs for
> > -fdelete-null-pointer-checks: "Assume that programs cannot safely
> > dereference null pointers, and that no code or data element resides at
> > address zero."  (-fno-delete-null-pointer-checks is the opposite.)
> Ah, now that's quite a bit more palatable. I really should have read
> the docs before spouting "my favourite rant #1". Then my main concern
> is that we end up with a sufficiently clear (and documented)
> definition that we're not promising more than we intend. I get very
> grumpy if I can't tell someone with UB that they're Doing It Wrong

+1 for implementing the feature.

> Of the two options, I still think the second is a non-starter.

Something between the two might be a datalayout flag specifying
> addrspace(0) behaviour. It's pretty easy to argue that it'd be good if
> code used some kind of
> "DataLayout::isPointerIntrinsicallyInvalid(Value *)" for this kind of
> thing anyway (rename or relocate at will)

Whether or not this is put into DataLayout, moving all the null-related
addrSpace != 0 checks into an accessor seems like a great idea. Besides
this feature request, presumably there's also other uses of non-zero
address spaces for which the pointer 0 could usefully be treated as

And the name really is terrible, we should change it if at all feasible

Yep. "-fnull-pointer-is-valid" has been suggested before.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180420/5f98a8d2/attachment.html>

More information about the cfe-dev mailing list