[llvm-dev] GEP with a null pointer base

[David Blaikie via llvm-dev]

On Wed, Aug 2, 2017 at 7:02 AM Peter Lawrence <peterl95124 at sbcglobal.net>
wrote:

> Paul,
>          The proposition under discussion is this
>
> Deleting UB, rather than warning about UB, should not be the default,
> as this is contrary to the essentially universal software engineering
> practice of writing software that is compiler warning free, static
> analyzer warning free, and dynamic analyzer warning free.
>

There seems to be disagreement between you & most/everyone else who've
discussed this.

I (& I believe others) don't see a contrtadiction here. Deleting UB code is
based on the assumption that someone is writing code that is warning,
static analysis, and dynamic analysis warning free. The belief is that the
code is dead, that's why it's deleted. & not that the user wrote dead code,
but it's contextually dead based on inlining, etc - as examples have been
given (& one can question/discuss the validity of those examples - but
they're certainly proof of existence of steps where benign/good/reasonable
code still produces UB-dead code after optimizations that can be removed by
the compiler while maintaining the developers intend and potentially
improving the performance, code size, etc, of the program).

If I understand correctly, you disagree that this happens in practice (that
the only time UB code is ever removed is because the user's code was buggy
in the first place) - there are some paths (suggested) to discover whether
that's the case.


>
> This is based on the assumption that in order for llvm to be useful to its
> users it should mitigate rather than exacerbate the problems inherent
> in the language w.r.t. UB.
>
> No one is debating in this thread what the standard does or should say.
>
> After suggesting that the user should have an opt-in option for deleting
> UB it was suggested that this would be awkward to implement in llvm.
> I disagree, but it seems that the burden of proof falls on me, so in the
> fullness of time I will do this. (In particular I believe there should be a
> UBCE pass, just like there is a DCE pass).
>
>
> Peter Lawrence.
>
>
>
>
>
> > On Aug 2, 2017, at 6:29 AM, Robinson, Paul <paul.robinson at sony.com>
> wrote:
> >
> >> Saying “The C++ language lets me assume that that won’t happen, &
> >> optimize on that basis” is an assumption that that’s what the user
> >> wants, but you haven’t asked you’ve just assumed, and AFAICT it is an
> >> incorrect assumption.
> >
> > Well, by using C++, the programmer agrees that the rules of the language
> > apply to their program, and the rules of the language say that the
> > compiler can do whatever it likes.  So whether the user wants it or not,
> > that's what they have effectively agreed to.
> >
> >  undefined behavior
> >  behavior for which this International Standard imposes no requirements
> >  [ Note: Undefined behavior may be expected when this International
> >  Standard omits any explicit definition of behavior or when a program
> >  uses an erroneous construct or erroneous data. Permissible undefined
> >  behavior ranges from ignoring the situation completely with
> >  unpredictable results, to behaving during translation or program
> >  execution in a documented manner characteristic of the environment
> >  (with or without the issuance of a diagnostic message), to terminating
> >  a translation or execution (with the issuance of a diagnostic message).
> >  Many erroneous program constructs do not engender undefined behavior;
> >  they are required to be diagnosed.
> >  —end note ]
> >
> > If you want to argue that it is *more useful* to the programmer to have
> > diagnostics for undefined behavior as represented in their source code,
> > I expect you would get essentially universal agreement.  But what I am
> > understanding from this thread is an argument that it's a *requirement*
> > to diagnose UB, and that is just not what the language requires, and
> > consequently not what the user is entitled to.
> >
> > If I'm misunderstanding, I'd love to be corrected.
> > Thanks,
> > --paulr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170802/67fae9f5/attachment.html>