summary for lhf: llvm-* compiler bug against Lua 5.2.2 (was Re: Bus error on MacOS)

[Jay Carlson <nop@...>]

On May 8, 2013, at 12:44 AM, Eric Wing wrote:
> On 5/7/13, Jay Carlson <nop@nop.com> wrote:
>> [latest Xcode toolchain on OS X 10.7/10.8]

>> To be clear, typing "gcc" at a shell prompt gets you llvm-gcc. Which is the
>> one that has the optimization bug at the start of this whole thread. "cc"
>> gets you clang.
>> 
>> [...] gcc isn't a symlink to llvm-gcc [on 10.6]. 

> Yes, everything I said is correct.

[leans back in chair] "What did we learn?" [1]

I'm gonna sum up and put labels on all the things I think we know. I'm going to use "Mac-recent" to describe "Mac OS X 10.7 or 10.8 with the April 2013 Xcode", and "Mac-10.6" to describe "Mac OS X 10.6 with Xcode 3.2.6".

J1: Invoking llvm-gcc-4.2 on Mac-recent or Mac-10.6 using the -m32 model results in a miscompilation of liolib.c
J1.1: The error is detectable with "src/lua -e 'io.open("/dev/null"):close()'"
J1.2: Examination of generated assembly shows a tailcall function pointer being clobbered with 0.

J1.f: Adding "asm(""):" to liolib.c:aux_close() before "p->closef = NULL;" works around the bug.

J2: Invoking clang in the "-m32" model on Mac-10.6 results in the same miscompilation as J1.
J2.f: As in J1.f, adding asm(""); fixes it.

J3: Invoking gcc-4.2 on Mac-10.6 using the -m32 model does NOT result in a miscompilation.

J4: Invoking clang on Mac-recent using the -m32 model does NOT result in a miscompilation.

S for Steve Donovan:

S1: Invoking unnamed version of clang in an unnamed processor model on some Linux boxes results in the same miscompilation as J1.
S1.f: As in J1.f, adding asm(""); fixes it.

> There is a distinction between gcc,llvm-gcc, and clang.

M1: On Mac-recent, typing "gcc" or "gcc-4.2" gets you llvm-gcc-4.2, not gcc-4.2. There is no gcc-4.2.

M2: There is no gcc-4.2 on Mac-recent, but there is a "gcc-4.2" command for backwards compatibility.

M3: "gcc" invokes "gcc-4.2".

L1: Lua 5.2.2 uses the command "gcc" to compile for the macosx target.

L1.1: By M3+M2+M1, Lua 5.2.2 on Mac-recent invokes llvm-gcc-4.2.
L1.2: By L1.1+J1, Lua 5.2.2 is miscompiled on Mac-recent.

> llvm-gcc still ships, but all maintenance on the source is stopped.
> (Apple closes their bug reports on llvm-gcc and gcc now.)

M3: llvm-gcc is not supported on Mac-recent and bugs are auto-closed.

L2: By M3 +L1, on Mac-recent, "make macosx" invokes an unsupported compiler.
L2.1: On Mac-recent, "make macosx" invokes a compiler pointless to report bugs on.

E1: On Mac-recent, there is no supported compiler available with source.

> Invoking cc will invoke clang. Clang is the default compiler.

M4: Invoking cc is the official way to get a "reasonable" compiler.

> 10.8 is the current OS X.

I don't think that tells us anything in the context of this bug.

> Also, all still supported Macs are 64-bit capable and Objective-C
> developers have huge incentives to target 64-bit and ignore 32-bit.
> Perhaps little surprise that there was a 32-bit bug in llvm-gcc.

M5: If you're targeting Mac-recent, there's no compatibility motivation for using -m32
M5.1: If you're targeting Mac-10.6 there is.

E2: I have no clue how you're supposed to develop for 10.6 from Mac-recent, since there is no supported compiler.
E2.1: Note to self: be sure to keep a 10.6 box around for builds, not just testing.

> If there is a bug in clang (the Ubuntu discussion), please report it
> to the LLVM community. They have been very good about fixing bugs once
> reported.
> http://clang-analyzer.llvm.org/filing_bugs.html

J3: By J1, J2, and S1, there are multiple versions of llvm-backed compilers in the field which can't compile Lua 5.2.2, at least in the i386 mode.
J3.1 Mac-recent clang is the only non-buggy one so far.

E3: There's no source for J3.1.
E3.1: The fix may be public, just not in Ubuntu pulls.

E4: Somebody else can report this, I'm done worrying about it.

J5: There's a single hack which seems to fix all of them.
J5.1: The hack appears to be benign against clang and llvm-gcc-4.2.
J5.2: It doesn't break Mac-recent clang.

lhf1: We want to support as many compilers and processor models as possible.

J6: The smallest cover for all of these problems is defined(__llvm__) && defined(__i386__)
J6.1: This applies the hack even to the working Mac-recent clang, but without apparent error.

Jay

(the "E" stands for either "editorial" or "exhausted", I'm not sure which)

[1]: _Burn After Reading_. Quotes reflect actual language used in workplaces, and therefore are Not Safe For Work. Welcome to the US. http://www.imdb.com/title/tt0887883/trivia?tab=qt#qt0494490