[LLVMdev] Should remove calling NULL pointer or not
Yin Ma
yinma at codeaurora.org
Thu Nov 7 11:02:58 PST 2013
Hi John,
It seems the dereferencing a NULL pointer is undefined behavior but
Calling a function through a null pointer seems o.k.
If so , for this place, we need comment out the check.
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232
look at Notes from the October 2003 meeting.
Yin
From: John Criswell [mailto:criswell at illinois.edu]
Sent: Wednesday, November 06, 2013 6:28 PM
To: Yin Ma; 'llvmdev Dev'
Subject: Re: [LLVMdev] Should remove calling NULL pointer or not
On 11/6/13 6:36 PM, Yin Ma wrote:
Hi,
For a small case, that calls NULL pointer function. LLVM explicitly converts
It to a store because it thinks it is not reachable like calling undefvalue.
In InstCombineCalls.cpp:930
I think it is not a right approach because calling null pointer function
Will segfault the program. Converting to a store will make program pass
Silently. This changes the behavior of a program.
So we need remove the case if (isa<ConstantPointerNull>(Callee) at
InstCombineCalls.cpp:918 and treat calling Null pointer reachable.
How do you think? Is there any reason that we should convert
a calling null pointer to a store?
If calling a NULL function pointer yields undefined behavior (as defined by
the C/C++ standards), then the optimization is correct: since the behavior
is undefined, the compiler can change it as it sees fits. In other words,
the compiler is not required to maintain "incorrect" behavior.
The remaining question, then, is whether the C/C++ standards consider
calling a NULL function pointer undefined behavior. I suspect that it is
undefined behavior, but to be honest, I do not know for certain.
-- John T.
Thanks,
Yin
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131107/9bcdc80c/attachment.html>
More information about the llvm-dev
mailing list