$ /scratch/obj.i686/gcc-4.3/./gcc/xgcc -B/scratch/obj.i686/gcc-4.3/./gcc/ -B/opt/i686/gcc-4.3//i686-linux-gnu/bin/ -B/opt/i686/gcc-4.3//i686-linux-gnu/lib/ -c f?.i -combine -o /dev/null /tmp/ccqmLD9J.s: Assembler messages: /tmp/ccqmLD9J.s:3: Error: symbol `__gthrw_pthread_once' is already defined $ cat f1.i static __gthrw_pthread_once __attribute__ ((__weakref__ ("pthread_once"))); $ cat f2.i static __gthrw_pthread_once __attribute__ ((__weakref__ ("pthread_once"))); It fails to drop duplicate weakrefs: $ /scratch/obj.i686/gcc-4.3/./gcc/xgcc -B/scratch/obj.i686/gcc-4.3/./gcc/ -B/opt/i686/gcc-4.3//i686-linux-gnu/bin/ -B/opt/i686/gcc-4.3//i686-linux-gnu/lib/ -S f?.i -combine -o - .file "f1.i" .weakref __gthrw_pthread_once,pthread_once .weakref __gthrw_pthread_once,pthread_once .ident "GCC: (GNU) 4.3.0 20070410 (experimental)" .section .note.GNU-stack,"",@progbits
Created attachment 13363 [details] inaccurate bypass Not a patch. By marking ultimate target's asm_written_flag and bailing if it was already set, one could bypass this, perhaps..
Since these are both 'static', shouldn't they be named things like __gthrw_pthread_once.247 in the assembler?
Richi suggested it was a FE bug.
The following testcase should be equivalent to the original one but not involve IMA: void f1() { static __gthrw_pthread_once __attribute__ ((__weakref__ ("pthread_once"))); } void f2() { static __gthrw_pthread_once __attribute__ ((__weakref__ ("pthread_once"))); }
Without combine, the attribute is ignored: $ gcc-4.3.orig-HEAD -c pr.c -o /dev/null pr.c: In function 'f1': pr.c:3: warning: '__weakref__' attribute ignored pr.c: In function 'f2': pr.c:7: warning: '__weakref__' attribute ignored while with combine and the original testcase, current trunk still gives: $ gcc-4.3.orig-HEAD -c f1.i f2.i -combine -o /dev/null /tmp/ccmg6Twk.s: Assembler messages: /tmp/ccmg6Twk.s:3: Error: symbol `__gthrw_pthread_once' is already defined
Any update? Current trunk still produces wrong code for weakrefs..
Testing a patch.
Mine. $ cat pr31537.i static int __gthrw_pthread_once __attribute__ ((__weakref__ ("pthread_once"))); $ gcc-4.3-HEAD -S -o - -Os pr31537.i pr31537.i pr31537.i \ pr31537.i pr31537.i pr31537.i -fno-tree-vnhoist -combine .file "pr31537.i" .weakref __gthrw_pthread_once,pthread_once .ident "GCC: (GNU) 4.3.0 20080125 (experimental)" .section .note.GNU-stack,"",@progbits Regression-testing still in progress..
Created attachment 15053 [details] patch in testing This is a simple fix to adjust the respective vector (that get's filled/finalized far too early, AFAICT; furthermore it's never pruned and if a new target is added the alias is never rejected). This patch warns -- conditionally, should most likely be a warning(0.. -- if the target changes and adjust the vector accordingly. Should a subsequent weakref to a new target invalidate the weak?
unassigning. The BE workaround bypasses it for me, no time to look further.
Oh, the temptation to close this as WONTFIX.... Objections?
Well, without it fixed it's impossible to build libgfortran (and other apps) with combine, which would be a very nice thing to have. The sample patch above exposed no regressions fwiw.
We are getting LTO (and maybe LIPO), no need for -combine being fixed.