Summary: | [4.5/4.6/4.7 Regression] Lifetime of local variables: global versus member function | ||
---|---|---|---|
Product: | gcc | Reporter: | Jan van Dijk <j.v.dijk> |
Component: | middle-end | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | jakub, jason |
Priority: | P3 | Keywords: | wrong-code |
Version: | 4.5.1 | ||
Target Milestone: | 4.5.3 | ||
Host: | Target: | x86_64-linux-gnu | |
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: | 2011-03-28 20:31:38 |
Description
Jan van Dijk
2011-03-28 20:00:56 UTC
+ .type _ZZN1C13class_scope_fEvE1i, @gnu_unique_object - .type _ZZN1C13class_scope_fEvE1i, @object - works but + does not. 4.4 produces object while 4.5 and above produce @gnu_unique_object. http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01240.html was the patch which changed to use @gnu_unique_object . Jason can you explain why this is causing an issue where the function passed to __cxa_atexit being called? It has nothing to do with __cxa_atexit. The dynamic linker sets if (map->l_type == lt_loaded) /* Make sure we don't unload this object by setting the appropriate flag. */ map->l_flags_1 |= DF_1_NODELETE; whenever doing successful symbol lookup of a STB_GNU_UNIQUE symbol, so that that symbol will always be found at that point afterwards. (In reply to comment #3) Sorry for being pedantic, but would you care to explain how your observation renders this report invalid? I am afraid I do not understand this resolution. Do you assert that the two cases (static local in global vs. class scope function) are deliberately treated differently? If so, is this an implementation choice, or is it based on a document that I should have read (which one)? If this isn't changed back, shouldn't this change at least be documented? It may break more user code, not just mine... Thanks again for your time. (In reply to comment #4) > (In reply to comment #3) > Sorry for being pedantic, but would you care to explain how your observation > renders this report invalid? I am afraid I do not understand this resolution. > > Do you assert that the two cases (static local in global vs. class scope > function) are deliberately treated differently? If so, is this an > implementation choice, or is it based on a document that I should have read > (which one)? Yes they are different because C::class_scope_f is a vague linkage while global_f is global linkage. So the i in each one is of different linkage. If you want C type to be local to the shared, then you need to use either the hidden attribute on it or use -fvisibility=hidden. |