Xcode 4 ships a buggy compiler

Re:Xcode 4 ships a buggy compiler by pkaler on Friday December 30, 2011 @11:30PM (#3410170)

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.

[ Parent | on HN ]

Re:Xcode 4 ships a buggy compiler by FooBarWidget on Saturday December 31, 2011 @04:31AM (#3410551)

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

[ Parent | on HN ]

Re:Xcode 4 ships a buggy compiler by pkaler on Saturday December 31, 2011 @06:29AM (#3410701)

> 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

[ Parent | on HN ]

Re:Xcode 4 ships a buggy compiler by jey on Saturday December 31, 2011 @04:36AM (#3410558)

> 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)?

[ Parent | on HN ]

Re:Xcode 4 ships a buggy compiler by FooBarWidget on Saturday December 31, 2011 @04:41AM (#3410565)

alloca(0) is used as a way to get the end of the stack. There's a bunch of fallback #ifdefs in the code: on platforms that don't have alloca, it detects the end of the stack by calling a forced-non-inline function which returns the address of its sole local variable, but that assumes that the compiler supports the 'noinline' keyword. In any case, all of versions depend on highly platform-specific behavior. See:

https://github.com/FooBarWidget/rubyenterpriseedition187-330...

[ Parent | on HN ]

Re:Xcode 4 ships a buggy compiler by Someone on Saturday December 31, 2011 @04:48AM (#3410574)

He isn't claiming it is the only way, he is claiming it is the best way he knows of to do what he needs/thinks he needs.

I guess he wants the cleanest way to obtain the stack pointer. alloca(1) would work, too, but that runs the risk of producing a stack overflow.

[ Parent | on HN ]

Re:Xcode 4 ships a buggy compiler by pilif on Saturday December 31, 2011 @04:52AM (#3410582)

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()

[ Parent | on HN ]

Re:Xcode 4 ships a buggy compiler by FooBarWidget on Saturday December 31, 2011 @05:07AM (#3410604)

That's what I did, I replaced alloca(0) with alloca(sizeof(void *)). Unfortunately llvm-gcc still emitted wrong code in other parts of the program which caused Ruby to crash in strange ways. The post is not so much a complaint about alloca(0), it was just an example of where I thought llvm-gcc is broken.

[ Parent | on HN ]

Re:Xcode 4 ships a buggy compiler by kenferry on Saturday December 31, 2011 @06:06AM (#3410675)

llvm-gcc is not going to be globally broken or not broken. Like all software, it has bugs, and the bugs may or may not affect you. An 'example' that is actually a bug in the program is not very convincing of generic broken-ness. Try again if you want to make that case.

Do you want __builtin_frame_address, by the way? Still target specific, but explicit.

[ Parent | on HN ]

Re:Xcode 4 ships a buggy compiler by FooBarWidget on Saturday December 31, 2011 @06:19AM (#3410690)

It is not just one example. Take a look at http://llvm.org/bugs/show_bug.cgi?id=9891 which is marked as WONTFIX. Shipping an unmaintained compiler certainly screams broken to me.

__builtin_frame_address looks interesting, I'll take a look.

[ Parent | on HN ]