[llvm-dev] GEP with a null pointer base

[Chad Rosier via llvm-dev]

On 7/6/2017 3:05 PM, James Y Knight via llvm-dev wrote:
>
>
> On Thu, Jul 6, 2017 at 2:06 PM, Kaylor, Andrew via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     I've got a problem that I would like some input on.  The problem
>     basically boils down to a program that I am compiling, whose
>     source I don't control, doing something like this:
>
>       p = (char*)0 + n
>
>     where 'n' is an intptr_t-sized value that the program knows is
>     actually a valid address for a pointer.
>
>     clang translates this as
>
>       %p = getelementptr inbounds i8, i8* null, i64 %n
>
>     So far, so good.  The problem is that while LLVM seems to consider
>     the above IR to be valid, we officially do not allow dereferencing
>     a pointer constructed in this way (if I’m reading the rules
>     correctly).  Consequently, if this GEP ever gets close enough to a
>     load using the pointer, InstCombine will eliminate the GEP and the
>     load.
>
>     I've been told that the '(char*)0 + n' construct is invalid
>     according to the C standard.  However, this pattern appears in the
>     glibc malloc implementation, so I'd like to be able to handle it
>     anyway.
>
>
> glibc does accept patches...or are you talking about two separate 
> instances of this problem, both in glibc and something else?

FWIW and IIUC this same issue occurs in SPEC2017/gcc (with ref input) 
and I hear getting patches past the SPEC committee is incredibly 
difficult...

>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170706/4ce2448a/attachment.html>