Hi, > On Sat, May 25, 2013 at 3:24 AM, gcc frickler > <gccfrickler@xxxxxxxxxxxxxxxx> wrote: >> Hi, >>>> >>>> It does not seem to be a attribute of a VAR_DECL >>>> The static predicate in the bitfield is just saying it goes in the bss >>>> segment (true in all of the above cases) and has got nothing to do with >>>> the static keyword which just controls visibility on link time. >> I think i spotted it in the DECL_THIS_STATIC / DECL_THIS_EXTERN >> predicate which is held in lang_flag_6 for the c++ frontend. But im not >> sure about plain c. >>>> >>>> At which pass should this be examined? >>> >>> The name is handled entirely in the frontend. I don't think there is >>> anything in the tree structure that tells you that the variable got a >>> mangled name. That kind of information is C++ frontend specific. >> Hi> >> >> would be interesting to see where the mangled name travels along until >> the linker stage is reached. In the xxx.tu dumps there is clearly a node >> holding the mangled name. >> >> Basically i try to find occurences of silent link-time clashes. >> say lib1.so exports int global; >> and lib2.so also exports int global; >> >> Linking these two together to a main module, you will end up with one >> instance of int global (intentionally or not). >> If there is no shared information via "extern int global;" between say >> headers of lib1 / lib2 and main module the compiler is not able to >> detect the situation and there is no warning. The linker will simply >> assume them as one. (only in the case of not linking shared objects but >> static libs this is detected by the linker) >> >> Making them "static" will prevent that, because each of them is then >> meant to be "module global" and will be exported under different names. >> >> So far for my theory. >> It gets even worse if the globals have Ctors/dtors and internal memory / >> handle allocation. They get called twice and may cause double free >> disasters. >> I can provide a simple test case if you want to. > > > Please reply to the mailing list, not just to me. Thanks. sorry for that - wasn't my intention. Also sorry for the fullquote above, but otherwise the list would miss it. > > See the -fno-common option. > Good point, but i think that is dangerous. I have >5k source-Files and need to have this fixed in a semi-automatic way (ctags did not find all of them). I need a compiler warning on non-static/non-const globals because sometimes (< 2 %) they are meant to be as global as it gets. I am trying to build up a cross compilation unit database from the warnings to see where are unintended clashes and what was intended (imported elsewhere via the extern keyword). Regards
