[llvm-dev] GEP with a null pointer base

[Peter Lawrence via llvm-dev]

Chandler,
               The only thing David made clear that wasn’t already clear
is that he believes UB to be “comparatively rare”, which is in agreement
with what Hal already said which is that he does not expect deleting
UB will be of benefit to for example SPEC benchmarks.

Given that it is “comparatively rare”, why all the effort to delete it ?
And why make deleting it the default rather than warning about it ?

Peter


> On Jul 13, 2017, at 2:15 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> 
> On Thu, Jul 13, 2017 at 5:13 PM Peter Lawrence via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> David,
>           Here is the definition accepted by Hal of what we’re doing
> 
> > 1. Sometimes there are abstraction penalties in C++ code
> > 2. That can be optimized away after template instantiation, function inlining, etc
> > 3. When they for example exhibit this pattern
> >       if (A) {
> >               stuff;
> >       } else {
> >               other stuff including “undefined behavior”;
> >       }
> > 4. Where the compiler assumes “undefined behavior” doesn’t actually happen because
> >    In the C language standard it is the users responsibility to avoid it
> > 5. Therefore in this example the compiler can a) delete the else-clause
> >     b) delete the if-cond, c) assume A is true and propagate that information
> 
> 
> 
> We are actively deleting undefined behavior, and the question is why
> given that doing so potentially masks a real source code bug.
> At the very least deleting undefined behavior should not be the default.
> 
> You are asserting this (again), but others have clearly stated that they disagree. David gave detailed and clear reasons why. Continuing to re-state positions is not productive.
> 
> -Chandler

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170719/867bf94f/attachment.html>