[LLVMdev] C as used/implemented in practice: analysis of responses

[Yury Gribov]

On 07/01/2015 03:10 PM, Peter Sewell wrote:
> On 1 July 2015 at 10:17, Renato Golin <renato.golin at linaro.org> wrote:
>> On 1 July 2015 at 03:53, Sean Silva <chisophugis at gmail.com> wrote:
>>> Unfortunately in other cases it is very hard to communicate what the user
>>> should assert/why they should assert it, as Chris talks about in his blog
>>> posts. So it realistically becomes sort of black and white -- either don't
>>> optimize based on UB or do. For what is probably just social reasons, the
>>> desire to optimize wins out; from an economic standpoint (e.g. power saved)
>>> it overall may be the right choice (I haven't run any ballpark figures
>>> though and don't claim this to be true).
>>
>> This is *so* true. There's a natural progression of programmers as
>> they age. Initially, people are adverse of side effects and they hate
>> "misbehaviours" from their compiler. As time passes and their
>> experiences grow, they start to like some of the side effects, and as
>> maturity reaches them, they are already *relying* on them. C/C++
>> undefined behaviour and Perl's utter disregard for clarity are some of
>> the examples.
>>
>> Chandler said something at the last US LLVM meeting that stuck with
>> me: "you guys expect hardware to behave in ways that hardware can't".
>> Undefined behaviour and implementation defined features in the C/C++
>> standards is what it is, on purpose. If it wasn't for that, C/C++
>> couldn't perform well on most hardware architectures of today.
>
> I fear that this:
>
>> Programmers *must* learn not to rely on their particular desires or
>> compilers, to understand the language for what it is, and to exploit
>> its perks while still being platform independent. It is possible, but
>> *very* hard.
>
> while attractive from the compiler-writer point of view, is just not
> realistic, given the enormous body of C code out there which does
> depend on some particular properties which are not guaranteed by the
> ISO standard.
> That code is not necessarily all gospel, of course, far from it - but
> its existence does have to be taken seriously.

Sounds like endless compiler writers vs. maintainers dispute.

-Y