Re: Caveat with lua_pushlightuserdata(L, (void *)&key)

[Mike Pall <mikelu-0606@...>]

Hi,

I wrote:
> The bug might be just in the specific (heavily-patched) GCC 4.0
> Apple is using. Or only in combination with the Mach linker.

Ok, the problem has been identified! The culprit is the Mach-O
specific code emitter for GCC. It does not properly handle the
merge constants flag.

It confuses labelled constants and constant literals and puts
them into a section which is coalesced by the linker (in this
case: __TEXT,__literal4). Thus all const variables with the same
value get the same address (which violates the C/C++ standards).

The logic in gcc/config/darwin.c machopic_select_section() is
broken. The configuration variable "flag_merge_constants" has two
values: 1 (-fmerge-constants) is the default with optimization
and 2 (-fmerge-all-constants) is non-standards-compliant and NOT
enabled by default. But the code does not differentiate these two
cases and makes the wrong decisions.

The standard section selector code gets it right, of course (see
gcc/varasm.c categorize_decl_for_section()). The comments in the
code clearly indicate the potential problem, too:

| C and C++ don't allow different variables to share the same
| location.  -fmerge-all-constants allows even that (at the
| expense of not conforming).

I'm sorry, but I cannot contribute a patch because I don't know
enough about the internal GCC logic to get it right.

This is a long standing bug and affects all GCC 3.x and GCC 4.x
versions on Mac OS X (PPC and Intel Macs). The code for the
Mach-O code emitter has been contributed by Apple.

I'm not sure where to report this. If anyone has either close
ties to Apple or the GCC team -- please can you take over to
report it and track its progress? Thank you!

[Of course the test program can be used for the bug report.]

Thanks to Adam for helping me diagnose this problem.

Bye,
     Mike