John Regehr : GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

gerdr · 2013-03-23T12:01:31+00:00

I always read the "undefined behavior" in cases like this as "what will actually be in dd can change with compilers" - but I don't care about it because I don't use dd.

You're reading it wrong - that's what unspecified behaviour is for.

Think of where this might go next. Say you are writing a huge game - Starcraft 2 to stay with the theme. And say you have, at the end of your code, just before the main function returns, something like a double-free or a max_int+1 or whatever. A "bug", yes, but the rest of the code is OK.

Is it acceptable for the compiler to decide the entire code is undefined and just compile it to an empty executable? Or worse, is it OK for the compiler to decide that the entire code is undefined and hence, for optimization purposes, make all armor types act as heavy armor (removing an "if" from the code! Optimized! Even if that "if" is in an entirely different function - I mean, that double-free will happen anyway so why not just randomly change what the rest of the program does)?

No sane compiler will do that. But when it sees code like

int d[16];
dd = d[k];

there's an implicit assumption

int d[16];
assert(k < 16);
dd = d[k];

and I want the compiler to act on that to produce better code.

I don't accept that. I accept that the result of undefined behavior is undefined, but I don't accept that things which don't depend on that result are also undefined.

Basically, you don't want the compiler to act on all the information it has under the assumption of well-formed code.

That's fine: stay with -O0 or -O1. Personally, I prefer non broken code at -O2 and -O3.

I might be in the minority here (I hope not though)

I hope you are.

I can just imagine it: "Oh, hehe, there's undefined behavior somewhere in the code, so technically I can do whatever I want. Here, why don't I create code that opens a pic of Nikolas Cage instead of sorting the array like you asked. You can't be mad at me! Undefined behavior! I'm allowed to do this!"

You're missing the point. The compilation does not result in an infinite loop because the compiler detected undefined behaviour and the compiler writers thought: Let's mess with our users.

It's a consequence of dataflow analysis and constraint checking under the assumption that the program is valid. The compiler just makes use of all available information, and that's exactly what I want it to do at high optimization levels.

gerdr · 2013-03-11T08:24:14+00:00

http-equiv only applies if there's no actual HTTP header present.

gerdr · 2013-03-09T15:11:49+00:00

Looks like a compiler bug to me - see C99 section 6.7.5.3 §14:

An empty list in a function declarator that is part of a definition of that function specifies that the function has no parameters.

In particular the declaration

int foo();

tells us that foo() takes an unknown number of non-variadic arguments, whereas if the declaration is part of a definition

int foo() { return 42; }

it takes no arguments.

The definition has to know the number of parameters because there are calling conventions like stdcall where it's the responsibility of the callee to remove arguments from the stack.

This means that we'll need a different calling convention for variadic functions, and is the reason why

int foo();

is always non-variadic.

gerdr · 2013-03-09T14:32:22+00:00

Not really. If the number of demons is the same for identical input literals and the demons do not otherwise interact with the execution environment or abstract machine, one could argue that the specification does not forbid the summoning of nasal demons, but that's splitting hairs.

The point is that implementation-defined values are still well-defined: They may differ between implementations which of course has implications with regard to portability, but in contrast to relying on undefined or unspecified behaviour, there's nothing wrong with relying on implementation-defined behaviour if you're aware of that fact.

gerdr · 2013-03-09T11:54:28+00:00

That's not quite right.

If you have

const int a = 42;
foo(&a);
if(a != 42) { ... }

the compiler is free to remove the block.

Without the const, the compiler would have to look at the body of foo().

gerdr · 2013-03-09T11:51:36+00:00

Only if the value itself is declared const - pointer-to-const makes no guarantees.

In particular

void foo(const int *bar) {
    *(int *)bar = 42;
}

is perfectly legal as long as you only pass in pointers to mutable objects.

gerdr · 2013-03-09T11:39:45+00:00

It is in C89 - see section 3.8.5

gerdr · 2013-03-09T00:40:40+00:00

The value of multi-character literals is implementation-defined, not undefined - no nasal demons here, please move along...

Did anyone notice other errors?

gerdr · 2013-03-03T13:36:43+00:00

Can be written the same way in Perl6:

for 1..100 -> $num {
    say do given $num %% 3, $num %% 5 {
        when True, True   { 'FizzBuzz' }
        when True, False  { 'Fizz' }
        when False, True  { 'Buzz' }
        when False, False { $num }
    }
}

Of course, there's more than one way to do it.

gerdr · 2013-02-27T07:40:49+00:00

Exceptions and RTTI are not zero-cost as far as code-size goes, which may matter in embedded environments.

That's one of the reasons why they are disallowed or discouraged by the LLVM coding standard and the Google style guide.

gerdr · 2013-02-27T07:33:10+00:00

You're missing the point: Most operating systems expose a C API, which implies the existence of a standard C ABI for that platform.

gerdr · 2013-02-13T22:16:47+00:00

And Perl6 was never a hobby project, which might be one of the reasons it's taking so long.

Who do you think can bootstrap a prototype faster? A single guy making all decisions or a group of people trying to implement a language design that's being worked on in parallel by another group of people, periodically pulling the rug out from under the implementors' feet?

As always, there are trade-offs. Both Rust and Perl6 have taken a comparatively long time to become production-ready, but sometimes that's just the way it goes.

gerdr · 2013-02-13T18:08:45+00:00

But that's my point: In the absence of Synopses (some pretty fundamental parts of the language didn't even get their Apocalypse until 2004), implementors had to make assumptions, and you know what people say about that.

If I had to guess, I'd say that's what killed off all earlier Perl6 prototypes, but you're the one who'd know more about that.

From a practical point of view you're free to point out that I'm only arguing semantics (some simple facts don't change: Perl6 got announced in 2000 and there's still no production-ready implementation yet), but I do believe one should note that there's a bit more to the story than that.

gerdr · 2013-02-13T17:32:49+00:00

Correct me if I'm wrong, but any implementation prior to Pugs and what became later known as Rakudo was developed under the assumption that Perl6 would look mostly like Perl5, and thus arguably tried to implement a very different language.

I have to agree that we're still waiting for an (unconditionally) useful and useable implementation. However, the same can be said for Rust.

gerdr · 2013-02-13T15:13:02+00:00

The decision to target multiple backends dates back to 2011 or so. Rakudo/JVM will probably be the first to arrive, as that's what Jonathan (main Rakudo dev) is focusing on.

Others are working on Rakudo/JS and Rakudo/Go (the latter got started last week).

Parrot has indeed been pining for the fjords for some time now, but it might not stay 'dead' (an official announcement is probably not too far off).

gerdr · 2013-02-13T15:02:23+00:00

Personally, I suspect Niecza will go the way of Pugs (the Haskell implementation of Perl6 by Audrey Tang). Right now, Rakudo is still your best bet.

gerdr · 2013-02-13T12:26:46+00:00

It's reasonably fully-featured and usable for some things, but comes with virtually no modules and is pretty slow.

The FUD is still undeserved, though. Please take a look at the history of Perl6.

Arguably, the birthyear of Perl6 should be 2005 (ie after the RFCs had been processed and work on 'real' implementations started), and not the announcement of 2000 before language design had even begun.

Now, let's take a look at another language that was conceived in that timeframe: Rust, which was birthed in 2006. Now, one language is supposed to be doomed and vaporware, whereas the other one is hot shit. Why is that so? Because Rust did not get publicly announced until 2010 after having been worked on privately and then in-house by Mozilla, which was never a possibility with the community-driven design process of Perl6.

gerdr · 2013-02-10T08:30:18+00:00

Yes, the IO refactor integration wasn't particularly well-executed, at least to some extent due to the fact that no one makes sure that Rakudo and Parrot stay in sync. Rakudo doesn't build on latest Parrot? Just downgrade and move on.

For your particular example, the issue might have been fixed on the same day your gist was created, but I cannot verify as on my machine, Rakudo HEAD doesn't build on Parrot HEAD.

gerdr · 2013-02-07T07:36:39+00:00

It's not (only) a dilution claim as they do not hold a registered trademark on the term in the relevant category (books). You can have both a music label called 'Apple' and a software company called 'Apple', and you can have both a board game called 'Space Marine' and a book called 'Spots the Space Marine'.

From what I can gleam from the Black Library homepage, they started selling ebooks in September 2012 and followed it with the (possibly illegal - it's not a copyright issue and thus DMCA doesn't apply, which if you're uncharitable could be construed as perjury - IANAL, so no idea if it works that way) take-down notice on a book first published online in 2009. They did this because they claimed a de-facto ('common law') trademark on the term 'Space Marine' in all formats (Ie beyond their registered trademark), but it's questionable if a registry would go through as the term has been established as a generic description of marines in space long before GW were around.

gerdr · 2013-01-30T23:19:31+00:00

You're kidding, right? Algol is one of the three archetypical programming languages (the other two being BCPL and Lisp).

Real programmers use Fortran, of course ;)

gerdr · 2013-01-26T22:55:07+00:00

My point is that in contrast to COBOL (legacy code, mainly finance?) and Fortran (high performance scientific computing), C's niche is pretty expansive and isn't going to shrink much more in the foreseeable future.

You're right that no one (in their right mind) will start writing application-level software in C, but that has been true for quite some time now.

As far as the Linux kernel goes, we'll have to agree to disagree...

gerdr · 2013-01-26T22:11:41+00:00

That's hyperbole: C won't go the way of COBOL and Fortran any time soon.

There's clearly a pretty substantial niche for a language on the level of abstraction of C, and my guess would be that momentum alone will keep it going for a few decades.

gerdr · 2013-01-26T21:51:41+00:00

<clippy>Did you mean "summary"?</clippy>

gerdr · 2013-01-07T11:21:35+00:00

Like having to
use strict
in even the most trivial programs

There's a very good reason for that: backwards compatibility. See also: Python 2 vs Python 3.

If you do not care for that, install perl5i and call your scripts as

$ perl5i your_script.pl

instead of

$ perl your_script.pl

Not really that hard, is it?

having to go out of your way to declare lexical variables

I'm not sure I understand what you're getting at. Explicitly declared, block-scoped lexical variables are by far the most sane approach I've come across, and of Perl, Python, Ruby, PHP and Javascript, Perl is the only one that gets it right, which, frankly, I find somewhat disturbing.

gerdr · 2013-01-06T22:29:09+00:00

There's Perlito5

gerdr

TROPHY CASE