[llvm-dev] GEP with a null pointer base

[Daniel Berlin via llvm-dev]

On Mon, Jul 10, 2017 at 11:42 AM, Hal Finkel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> 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.
>

It's definitely false.
I think it's quite right to optimize way undefined behavior.

I'm in the camp of "if you want better programming languages, take full
advantage of what you can in the current ones, and if people don't like it,
awesome, let them use a language that has more guarantees".

(Though i'm usually in the camp of using flags and defaults to achieve
this, since i'm somewhat pragmatic)

If you don't take advantage at all, or only of some things, in the name of
pragmatics, now every compiler does something different, and users can't
even know what to expect.

In practice, taking advantage is also the only way this stuff gets fixed.
It becomes enough of a pain that either later revisions of the same
programming language, or a new programming language, fix it.

I'm emphatically not a fan of "well, the language designers suck at giving
users what they want and need, so we should fix it for them in the
compiler".  Down this path, madness lies.

Instead, i'd rather make these folks do their job ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170710/f92bf07a/attachment.html>