[llvm-dev] GEP with a null pointer base

[Hal Finkel via llvm-dev]

On 07/10/2017 01:36 PM, Peter Lawrence wrote:
> Chris,
>            nice segue to Swift !  :-),   but...
>
> The question is what should LLVM do with UB in general, saying that
> we are going to change one specific idiom from undefined to defined glosses
> over the real question: why should we ever optimize / delete any UB at all ?
>
> This “depressing and faintly terrifying thing” as you call it, should be viewed not as
> an opportunity for optimization, but rather as the source of bugs that need to be
> warned about at the very least.
>
> The current action is to delete UB (without warning), is that really right ?
> Who can possibly benefit from this optimization ?
> And how can that ever outweigh the harm in not reporting an error ?
> Why are we expending any effort at all to optimize something that just
> about everyone agrees should always be avoided ?
>
> These last questions are all rhetorical so no need to answer them, the problem
> as I see it now is that everyone CC'ed on this email probably by now would agree
> privately that optimizing away undefined behavior is wrong, but no one wants
> to be the first to say so publicly.

I'm certain this hypothesis is false.

  -Hal

>   We’re stuck in a log-jam. We need someone like
> you to take that first step so the rest can go along.
>
> Please help in un-jamming the current log-jam.
>
>
> Peter Lawrence.
>
>
>
>
>> On Jul 7, 2017, at 3:44 PM, Chris Lattner <clattner at nondot.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
>>

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory