> Date: Thu, 10 Mar 2005 17:36:37 -0800 > On Thu, 2005-03-10 at 16:55, Hans-Peter Nilsson wrote: > > But that requires source-level instrumentation. > > Isn't a compiler option -fglobalize-symbol also a form of source-level > instrumentation? Either way, you need the source, and you get different > code emitted.
This isn't a source-level modification, by definition. > If you are interested in implementing this, you should consider how this > will interact with other compiler features such as __asm__, attribute > ((alias)), and C++/Java name mangling. Of course! The simple (and best) way out is to define what happens in all those situations as the equivalent of removing "static" for such an identifier in file scope (including emitting errors where that results in invalid/erroneous/your-name-for-wrong code). Errors to be emitted when "conflicts" occur. (If there is no matching identifier SYMNAME in file scope for -fglobalize-symbol=SYMNAME, I think it's best if nothing happens.) > Also, I think the IPA support > will rename variables behind your back to try to avoid conflicts, e.g. > if you try to compile two source files into one object file. No, I don't think so. What will happen is the same as when there would (wrongly) be two globals by the same name: an error would be emitted. No surprises. brgds, H-P
