[llvm-dev] GEP with a null pointer base

[Mehdi AMINI via llvm-dev]

2017-07-21 21:27 GMT-07:00 Peter Lawrence <peterl95124 at sbcglobal.net>:

> Sean,
>      Let me re-phrase a couple words to make it perfectly clear
>
> On Jul 21, 2017, at 6:29 PM, Peter Lawrence <peterl95124 at sbcglobal.net>
> wrote:
>
> Sean,
>
> Dan Gohman’s “transform” changes a loop induction variable, but does not
> change the CFG,
>
> Hal’s “transform” deletes blocks out of the CFG, fundamentally altering it.
>
> These are two totally different transforms.
>
>
>
> And even the analysis is different,
>
> The first is based on an *assumption* of non-UB (actually there is no
> analysis to perform)
>
>                        the *absence* of UB
>
>
> the second Is based on a *proof* of existence of UB (here typically some
> non-trivial analysis is required)
>
>                         the *presence* of UB
>
> These have, practically speaking, nothing in common.
>
>
>
> In particular, the first is an optimization, while the second is a
> transformation that
> fails to be an optimization because the opportunity for it happening in
> real world
> code that is expected to pass compilation without warnings, static
> analysis without
> warnings, and dynamic sanitizers without warnings, is zero.
>
> Or to put it another way, if llvm manages to find some UB that no analyzer
> or
> sanitizer does, and then deletes the UB, then the author of that part of
> llvm
> is in the wrong group, and belongs over in the analyzer and/or sanitizer
> group.
>

I don't understand your claim, it does not match at all my understand of
what we managed to get on agreement on in the past.

The second transformation (dead code elimination to simplify) is based on
the assumption that there is no UB.

I.e. after inlining for example, the extra context of the calling function
allows us to deduce the value of some conditional branching in the inline
body based on the impossibility of one of the path *in the context of this
particular caller*.

This does not mean that the program written by the programmer has any UB
inside.

This is exactly the example that Hal gave.

This can't be used to expose any meaningful information to the programmer,
because it would be full of false positive. Basically a program could be
clean of any static analyzer error, of any UBSAN error, and totally
UB-free, and still exhibit tons and tons of such issues.

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170721/0f72fe5b/attachment.html>