[Bug target/63435] Bad code with weak vs localalias on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63435 Andrew Pinski changed: What|Removed |Added CC||streibel.2003 at gmx dot net --- Comment #7 from Andrew Pinski --- *** Bug 67950 has been marked as a duplicate of this bug. ***
[Bug target/63435] Bad code with weak vs localalias on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63435 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Eric Gallager --- So, if this is only a problem in 4.9 and earlier, I'm assuming I can close this as FIXED, since GCC 5 branch is now closed
[Bug target/63435] Bad code with weak vs localalias on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63435 --- Comment #5 from Jan Hubicka hubicka at ucw dot cz --- There are three problems in 4.9 and earlier - the aliases are produced incorrectly because AIX's as alias keyword does not do what is expected (it does kind of syntactic replacement combined with something else) - MAKE_ONE_ONLY is not defined making compiler to believe that linker does not perfrom garbage collection - Linker's garbage collection was disabled, so in particular all duplicated comdats stays in the code. Lack of MAKE_ONE_ONLY makes GCC to produce a lot more local aliases, because it makes sense to refer to a function by local relocation instead of lgobal when we know it is going to stay. Together with the as issue this leads to wrong code. You can work around by forcing local alias to return NULL for AIX to disable some of local aliases. There are other two cases where GCC produce such symbols (in addition of user declaring it by hand in source code via the alias attribute). It is the thunk generation (I suppose this one works as it is there for ages) and the new comdat local code in C++ (that is used only by -Os codegen path at 4.9).
[Bug target/63435] Bad code with weak vs localalias on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63435 --- Comment #4 from Andrew Dixie gcc at dixie dot net.nz --- I tried gcc-5-20140928 snapshot This snapshot doesn't generate a localalias for the testcase, and it generates very few localalias symbols in general. There was only one localalias symbol produced in the entire gcc build tree: [1228] m 0x041c 1 10x6b 0x ._ZNKSt14error_category23default_error_conditionEi.localalias.7 [1492] m 0x0b30 2 10x6b 0x _ZNKSt14error_category23default_error_conditionEi.localalias.7 [1578] m 0x0c6c 2 10x6b 0x _ZNKSt14error_category23default_error_conditionEi.localalias.7 Maybe there is something else wrong with gcc-4.9 that is causing it to generate localalias symbols too aggressively? We forced symtab_node::noninterposable_alias to return NULL on AIX. This resolved all the failures we were seeing in our application testsuite.
[Bug target/63435] Bad code with weak vs localalias on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63435 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-03 Ever confirmed|0 |1 --- Comment #3 from David Edelsohn dje at gcc dot gnu.org --- I have not seen any problems, although the coverage is limited.
[Bug target/63435] Bad code with weak vs localalias on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63435 --- Comment #2 from Jan Hubicka hubicka at ucw dot cz --- Yes, good to remind me. The aliases are quite broken on AIX pre 4.9 and becasue some of them are now auto generated, we probably ought to fix it. One solution would be to disable generation of aliases, other would be to backport this patch. David, I think we did not encounter any issues with the new code? Honza
