llvm dev - Jul 2015 - [LLVMdev] C as used/implemented in practice: analysis of responses

> But having programs miscompiled so that they silently fail, in many cases
> starting only years after the code in question was written, is very much
not
> okay. That's far worse than documented portability problems.
When given a certain spin...

Tim.

Why do you say spin? I'm not making any of this up; there have been
published cases of bugs creeping into code that had worked correctly for
years, without any change to the code itself, because a new version of GCC
started applying a monkey's paw optimisation. That's the sort of thing
that
prompted the survey that started this thread.

On Wed, Jul 1, 2015 at 7:30 PM, Tim Northover <t.p.northover at gmail.com>
wrote:
> > But having programs miscompiled so that they silently fail, in many
cases
> > starting only years after the code in question was written, is very
much
> not
> > okay. That's far worse than documented portability problems.
>
> When given a certain spin...
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150701/3990bea7/attachment.html>

On 1 July 2015 at 11:34, Russell Wallace <russell.wallace at gmail.com>
wrote:
> Why do you say spin?
You're dismissing all use-cases other than this very narrow one I'd
(with my own spin) characterise as "Do What I Mean, I Can't Be
Bothered To Get My Code Right". Fair enough, you're arguing in favour
of a point; but it's not one I agree with.

Tim.

Ø  I'm not making any of this up; there have been published cases of bugs
creeping into code that had worked correctly

Ø  for years

The generated machine code may have implemented what the programmer intended. 
However, the bugs were there all along
in that the program relied on undefined behavior.  The specified semantics of
the programming language, or of LLVM IR since
that itself is a programming language is what the user (or FE that uses LLVM IR
as its output) can rely on, nothing else.

Kevin B. Smith

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Russell Wallace
Sent: Wednesday, July 01, 2015 11:35 AM
To: Tim Northover
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] C as used/implemented in practice: analysis of responses

Why do you say spin? I'm not making any of this up; there have been
published cases of bugs creeping into code that had worked correctly for years,
without any change to the code itself, because a new version of GCC started
applying a monkey's paw optimisation. That's the sort of thing that
prompted the survey that started this thread.

On Wed, Jul 1, 2015 at 7:30 PM, Tim Northover <t.p.northover at
gmail.com<mailto:t.p.northover at gmail.com>>
wrote:
> But having programs miscompiled so that they silently fail, in many cases
> starting only years after the code in question was written, is very much
not
> okay. That's far worse than documented portability problems.
When given a certain spin...

Tim.

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

On 1 July 2015 at 19:34, Russell Wallace <russell.wallace at gmail.com>
wrote:
> Why do you say spin? I'm not making any of this up; there have been
> published cases of bugs creeping into code that had worked correctly for
> years, without any change to the code itself, because a new version of GCC
> started applying a monkey's paw optimisation. That's the sort of
thing that
> prompted the survey that started this thread.
And yet, this thread died a long time ago in the GCC list, and it
seems you're not having luck here either.

You could say that it's confirmation bias, since we're all compiler
guys anyway, but go ask on the LKML and you'll find that they pretty
much ask for it.

Just maybe, you thought that this was a much bigger issue that it
really is, and most developers do like when they're told they messed
up, or when things explode in their faces.

If you like the safety of one-vendor buy-in implementation-defined,
maybe you ought to look at Java instead?

cheers,
--renato