[llvm-dev] GEP with a null pointer base

[Craig Topper via llvm-dev]

In this particular case, I believe llvm is really emitting a store of undef
to a nullptr. I think this later gets turned into a trap. Here's the
relevant code from instcombine.

  // load(gep null, ...) -> unreachable
  // load null/undef -> unreachable
  // TODO: Consider a target hook for valid address spaces for this xforms.
  if (canSimplifyNullLoadOrGEP(LI, Op)) {
    // Insert a new store to null instruction before the load to indicate
    // that this code is not reachable.  We do this instead of inserting
    // an unreachable instruction directly because we cannot modify the
    // CFG.
    new StoreInst(UndefValue::get(LI.getType()),
                  Constant::getNullValue(Op->getType()), &LI);
    return replaceInstUsesWith(LI, UndefValue::get(LI.getType()));
  }

~Craig

On Fri, Jul 7, 2017 at 3:44 PM, Chris Lattner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Jul 7, 2017, at 1:40 PM, Peter Lawrence <peterl95124 at sbcglobal.net>
> wrote:
> > Chris,
> >           The issue the original poster brought up is that instead of a
> compiler
> > that as you say “makes things work” and “gets the job done” we have a
> compiler
> > that intentionally deletes “undefined behavior”, on the assumption that
> since it
> > is the users responsibility to avoid UB this code must be unreachable and
> > is therefore safe to delete.
> >
> > It seems like there are three things the compiler could do with
> undefined behavior
> > 1)   let the code go through (perhaps with a warning)
> > 2)   replace the code with a trap
> > 3)   optimize the code as unreachable (no warning because we’re assuming
> this is the users intention)
>
> Hi Peter,
>
> I think you have a somewhat fundamental misunderstanding of how UB works
> (or rather, why it is so crappy and doesn’t really work :-).  The compiler
> can and does do all three of those, and it doesn’t have to have consistent
> algorithms for how it picks.  I highly recommend you read some blog posts I
> wrote about it years ago, starting with:
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
>
> John Regehr also has written a lot on the topic, including the recent post:
> https://blog.regehr.org/archives/1520
>
> What you should take from this is that while UB is an inseperable part of
> C programming, that this is a depressing and faintly terrifying thing.  The
> tooling built around the C family of languages helps make the situation
> “less bad”, but it is still pretty bad.  The only solution is to move to
> new programming languages that don’t inherit the problem of C.  I’m a fan
> of Swift, but there are others.
>
> In the case of this particular thread, we aren’t trying to fix UB, we’re
> trying to switch one very specific syntactic idiom from UB to defined.
>
> -Chris
>
> _______________________________________________
> 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/20170708/2376c6ba/attachment.html>