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

[Hal Finkel via cfe-dev]

On 04/18/2018 02:54 PM, Tim Northover via llvm-dev 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.
>
> 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.

But then we're back to auditing everything (FWIW, I'm not sure there's
going to be a great alternative to an audit). What behavior would you
like under LTO? We could use a different address space by default
(although, unless you also change the address space used for allocas,
you're going to end up with addressspace casts all over the place).

 -Hal

>  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).
>
> And the name really is terrible, we should change it if at all feasible
>
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory