Xcode 4 ships a buggy compiler

http://blog.phusion.nl/2011/12/30/xcode-4-ships-a-buggy-compiler/

by FooBarWidget • 15 years ago

52 65 15 years ago

blog.phusion.nl

Xuzz• 15 years ago

The Clang build shipped (called "LLVM Compiler" in Xcode) is also buggy: it has issues with some floating point operations on armv6 (edit: I think; it might only be THUMB, or THUMB and armv6) builds (for the iPhone). There isn't a non-LLVM GCC build for the iPhone anymore, however, so you'll probably have to choose between this bug and the floating point one when building for iPhone.

zyb09• 15 years ago

it helps to turn thumbs off if you encounter that problem on armv6 builds

forrestthewoods2• 15 years ago

"Calling alloca(0) should return a pointer to the top of the stack"

Eh? My understanding is that it's undefined behavior and varies per platform and compiler. Relying on it to return a stack pointer seems like a pretty terrible idea even if it should work.

saurik4• 15 years ago

As much as I hate LLVM, and as many times as I've been burned by bad code it has generated, I at least have to agree about this: alloca(0) tends to do random stuff on different systems (in fact, it often seems to be special-cased to clear the alloca area in library implementations).

However, assuming the actual compilation and test results reported in this article are true, I personally don't care what the function does: if (alloca(0) != NULL), then alloca(0) /should not/ return NULL. ;P

mikeash14• 15 years ago

Once you invoke undefined behavior, all bets are off. If the result of alloca(0) is undefined (and reading the man page, it appears to be) then any return value is valid. Likewise, the optimizer is allowed to assume that alloca(0) never happens, because once you invoke undefined behavior, anything can happen.

C is a dangerous language. A large part of that danger is to allow compilers to produce efficient code. A major point of "undefined behavior" is to allow compilers to assume that such things can never happen, and thus avoid generating code that has to deal with them.

To take a more sane example:

    int *x = ...;
    *x = 42;
    if(x == NULL)
        foo();

A C compiler would be entirely within its rights to completely delete both the if check and the call too foo() in this code. It's illegal to dereference a NULL pointer, so the compiler may assume that that code path can never happen.

Now, you may set up your system so that 0x0 is actually a valid address that can be written to, with clever mmap tricks or whatever. You may then initialize x with NULL and run this code, expecting the dereference to work, and foo() to be called. From a naive point of view, that's what should happen. However, even though 0x0 is a valid address in this environment, dereferencing it is still undefined behavior according to the language you're using. If you manually wrote the above in assembly you're fine, but the moment you do this in C, all bets are off.

It's the same deal with alloca(0). You can't count on the return value being anything in particular, and simultaneously the compiler can assume that the return value is anything it feels like.

Edit: thought of a more pertinent example. Consider the following:

    int x = INT_MAX;
    int y = 1;
    int z = -INT_MAX - 1;
    if(x + y == z)
        foo();
    else
        bar();

Directly translating this code to assembly and running it on any modern architecture would result in foo() being called (assuming I didn't screw up my arithmetic). The addition of x + y wraps around, and with a two's complement representation this results in the most negative integer being produced. That same integer is generated more directly in z, and the two compare equal.

But! integer overflow produces undefined results in C. The above program is ill-formed, and the compiler is completely within its rights to assume that the conditional is never true, because the moment you wrote x + y you gave up any right to expect any particular value in the result.

Interestingly, the version of clang on my computer optimizes the above to always call foo(), rather than always call bar(). However, either choice would be correct.

One certainly could get used to integer overflow always wrapping around according to two's complement and expect the above code to work. Upon encountering a compiler that optimizes the above to always call bar(), one might first suspect that the compiler is broken. However, it is the code that is broken, and the compiler is correct.

eschaton• 15 years ago

You lost me at "As much as I hate LLVM."

What's to hate?

asomiv3• 15 years ago

The point is that the behavior depends on the optimization setting. Worse: as you saw on the example, the optimizer actually expects the result to be non-NULL!

kev009• 15 years ago

Is that not the essence of undefined behavior?

mikeash14• 15 years ago

Bingo. Both returning NULL from alloc(0) and assuming that alloc() never returns NULL are correct behavior by the compiler. It's simply taking advantage of the nasal demons.

It seems that LLVM and Clang have generally been much more aggressive about taking advantage of undefined behavior, which has ended up breaking code that worked under gcc. For example, with some versions of Clang, if you try to write something like (int )0 = 0, it'll completely skip that line when generating code! Completely valid, since dereferencing NULL is undefined behavior, but not what one might expect after using a compiler that's more obedient.

There's a great post on undefined behavior in C, what it means for a compiler, and how LLVM and Clang deal with it here:

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

FooBarWidget9• 15 years ago

But where exactly is it specified that alloca(0) is undefined? None of the man pages I could find say that 'size' may not be 0.

EDIT: no idea why people vote me down for this, it is a legit question. Downvotes are for comments that don't contribute to discussion, not for comments that you disagree with.

Creating a file of 0 bytes is well-defined so why would it be such a strange idea to think that alloca(0) would also be well-defined, especially because none of the man pages mention that it's not allowed?

makmanalp• 15 years ago

Trivia about the nasal demons: http://catb.org/jargon/html/N/nasal-demons.html

chj• 15 years ago

I use gcc for code gen.

The idea to use undefined behavior for optimization is really terrible. Somehow they forget this is engineering project, not in researching. Breaking existing code costs a lot of time and money.

By the way, I don't see their optimization has any impact on the real project I am working on (highly cpu intensive).

jtc3312• 15 years ago

"The idea to use undefined behavior for optimization is really terrible. Somehow they forget this is engineering project, not in researching. Breaking existing code costs a lot of time and money."

Saying that using undefined behavior for optimization is really terrible is living in a pipe dream if you code in C at all. No performant C compiler does not use undefined behavior to optimize it's resultant code. In fact, GCC does a fair amount of this too.

The real value in using undefined behavior to optimize code is that it leads to a fair amount of layering of optimizations. And the real world tests so a significant improvement in program running speed because of the interaction of optimizations.

The real problem is that most C programmers expect far more defined behavior than the standard actually gives. For a long explanation and lots of examples of this, see the series of blog posts at: http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

BTW, breaking existing code happens all the time with new compiler version releases with LLVM or GCC.

A side note on GCC: back in school we actually had very simple programs that used only STL data structures (all calls being legal according to the lib specs) that would cause seg faults with certain levels of optimizations in GCC. What's worse: it didn't happen in the previous major X.Y version (i.e. the difference between 4.2 and 4.1.) But even on the breaking build it worked with -O1 but not any higher. That's inconsistent behavior in optimizations if I've ever seen it. But to be fair to the compiler: it's likely that the STL made assumptions that you technically can't make according to the C spec. Just like the OP's code. I love Ruby, but using MRI as an example of code that is a correct program is rather extreme. MRI makes tons of assumptions that often lead to noticeable bugs in the interpreter.

mahyarm• 15 years ago

Blocks in Objective-C are also buggy. If you chain 3+ in a row, the compiler craps out

  //Ex:
  [UIView animateWithDuration:1 animations:^{...} completion:^{
    [UIView animateWithDuration:1 animations:^{...} completion:^{
      [UIView animateWithDuration:1 animations:^{...} completion:^{
        //Compiler error here
      }]
    }]
  }];

pkaler2• 15 years ago

First of all, all compilers are buggy because all software is buggy. Software has bugs. Deal with it.

Second of all, if you are using alloca to allocate memory on the stack you are asking for trouble. There are so many filthy corner cases to deal with it is not worth it. Figure out another way to do what you are trying to accomplish. This has nothing to do with C or LLVM. This has to do with how a Von Neumann architecture works. http://stackoverflow.com/questions/1018853/why-is-alloca-not...

Third of all, alloca() is a compiler intrinsic. The compiler may choose to implement it in any way it wants to. http://en.wikipedia.org/wiki/Intrinsic_function

Fourth of all, sending a system function with a size_t of zero is undefined behaviour. This is not a bug. Undefined behaviour means that the compiler may do anything. http://en.wikipedia.org/wiki/Undefined_behavior

In general, LLVM does the most optimal thing when it hits undefined behaviour because it assumes that the Clang static analyzer will warn the programmer.

FooBarWidget9• 15 years ago

> First of all, all compilers are buggy because all software is buggy. Software has bugs. Deal with it.

This is a compiler we're talking about. Having a "deal with it" attitude is not a good thing to have. If there's a kernel bug that causes a crash would you also say "deal with it" or would you ask the creators to fix it?

> Figure out another way to do what you are trying to accomplish.

This is part of the code for the conservative garbage collector which is supposed to scan the stack for pointers. If you know a better way to do that, by all means let's hear it.

jey• 15 years ago

> This is part of the code for the conservative garbage collector which is supposed to scan the stack for pointers. If you know a better way to do that, by all means let's hear it.

Why does scanning the stack for pointers need to involve alloca(0)?

pilif• 15 years ago

you could of course alloca(1) which would also give you the address of the end of the stack plus one byte, but this time using functionality that's inside the specification of alloca()

pkaler2• 15 years ago

> This is a compiler we're talking about. Having a "deal with it" attitude is not a good thing to have. If there's a kernel bug that causes a crash would you also say "deal with it" or would you ask the creators to fix it?

It's not a bug. It's undefined behaviour for a compiler intrinsic.

> This is part of the code for the conservative garbage collector which is supposed to scan the stack for pointers. If you know a better way to do that, by all means let's hear it.

Keep two heaps. A long life heap and short life heap that is essentially a stack. http://engineering.twitter.com/2011/03/building-faster-ruby-...

Lua uses a struct called lua_State for this. http://www.lua.org/source/5.2/lstate.h.html

zitterbewegung• 15 years ago

I tried compiling the code they have in the example with llvm-gcc and it doesn't compile and returns an error?

Xcode 4 ships a buggy compiler

Related Stories