With revision 159779 this test passed. From revision 159784 and on, this test has failed as follows: Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/tls/tls.exp ... FAIL: gcc.dg/tls/alias-1.c (test for excess errors) With the message in the logfile being (copy-pasted): Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/ /tmp/hpaut\ otest-gcc1/gcc/gcc/testsuite/gcc.dg/tls/alias-1.c -ansi -pedantic-errors -isystem /tmp/hpautotest-gcc1/cris-elf/gc\ cobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include -B/tmp/hpautotest-gcc1/cris-e\ lf/gccobj/cris-elf/./libgloss/cris/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris -L/tmp/hpautotest-g\ cc1/gcc/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/ -L/tmp/hpautotest-gcc1/cris-elf/gccobj\ /cris-elf/./newlib -sim3 -lm -o alias-1.exe (timeout = 300) /tmp/ccZoLZBR.s: Assembler messages:^M /tmp/ccZoLZBR.s:43: Error: symbol `___emutls_v.bar' is already defined^M compiler exited with status 1 output is: /tmp/ccZoLZBR.s: Assembler messages:^M /tmp/ccZoLZBR.s:43: Error: symbol `___emutls_v.bar' is already defined^M FAIL: gcc.dg/tls/alias-1.c (test for excess errors) Excess errors: /tmp/ccZoLZBR.s:43: Error: symbol `___emutls_v.bar' is already defined Author of suspect patches in revision range CC:ed.
See also PR44137.
Yes, sorry, the list of emutls users grows... most likely it is my commit from r159781 to address PR44132 that caused this, 1/ Did the same commit improve PR44137 on your target? (PR44173 looks pretty much the same bug as 44132) 2/ Are you able to try the proposed "proper" solution to that bug (see comment #24 of PR44132) ? In the end we will have to address this if lto/whopr are to work with emulated tls.
I will need some help in tracking down how to solve this (since I don't have an emutls/visibility/alias target available). Also I can't find any reference in the gcc manual to alias applied to variables - only to functions. (although that might just be documentation lag). I guess we need to check for the alias attribute in emutls_decl and find our way back to the original aliased decl. Alternatively it might be enough to copy the alias attribute onto the emutls control var.
This also occurs on hppa64-hp-hpux11.11.
(In reply to comment #4) > This also occurs on hppa64-hp-hpux11.11. OK, I've built gcc & newlib for cris-elf and it's apparent that we need to deal with the fact that that aliased emutls symbols are named differently... that is the user writes alias(foo) ... but the emulated tls system needs to understand alias(__emutls_v.foo) ) I'll take a look at how to implement this... .. sorry for this fallout from the other fix The patch @ comment#24 of PR44132 also needs to understand this issue, and won't solve this problem yet.
Created attachment 20755 [details] fix up alias output this fixes it so that we don't try to emit emutls control vars if they are aliases. The reference will still be emitted when the original var alias is processed. This gives no fails on cris-elf (simulator, no pthreads) ..
(In reply to comment #2) Sorry I wasn't here to answer the basic simulator-target questions, but it seems you found the information needed to get you going. > 1/ Did the same commit improve PR44137 on your target? No. > 2/ Are you able to try the proposed "proper" solution to that bug (see comment > #24 of PR44132) ? I'll try when the tree builds again (PR44287) if you need it; from your later questions it seems you've verified this yourself. Thanks for looking into this!
(In reply to comment #7) > (In reply to comment #2) > > Sorry I wasn't here to answer the basic simulator-target questions, but it > seems you found the information needed to get you going. Yes, the wiki page is good and it all went pretty easily. One thing you could help with is whether there's a way of enabling threads on the simulator - and what I need to get to do it.. googling cris pthreads wasn't illuminating.. I want to keep this target around to test things that I can't do on darwin. > > 1/ Did the same commit improve PR44137 on your target? > > No. I see pretty much clean* output from check-gcc .... tls.exp=* * when clean=only fails I expect for non-tls reasons. > > 2/ Are you able to try the proposed "proper" solution to that bug (see comment > > #24 of PR44132) ? > > I'll try when the tree builds again (PR44287) if you need it; from your later > questions it seems you've verified this yourself. Hang fire on that - I've just re-made the "proper" solution to deal with the aliasing - but I need to re-reg-test on non-alias targets before posting; if you're interested in trying it, watch PR44132 (but I will use cris-elf as a test platform anyway).
(In reply to comment #8) > One thing you could help with is whether there's a way of enabling threads on > the simulator You mean "for cris-axis-elf"; no, there is no support for threads on cris-axis-elf. (I could reply "yes" to your original question, however, but that's irrelevant; the simulator supports cris-axis-linux-gnu too, but you don't want to build for that target, it's a slightly more complicated. :) Let's hope your patch gets reviewed post haste.
(In reply to comment #4) > This also occurs on hppa64-hp-hpux11.11. > Does the patch @ comment #6 resolve this for you? If so, and there are no more targets reporting the issue, I will post to gcc-patches as a proposed fix. thanks.
(In reply to comment #9) > (I could reply "yes" to your original question, however, but that's irrelevant; > the simulator supports cris-axis-linux-gnu too, but you don't want to build for > that target, it's a slightly more complicated. :) actually, on reflection, I do ... ... I assume that you're saying that building a sysroot is tricky? ... or is there one that's "downloadable" ? (BTW, this bug should be fixed v. soon)
(In reply to comment #11) > (In reply to comment #9) > > the simulator supports cris-axis-linux-gnu too, but you don't want to build for > > that target, it's a slightly more complicated. :) > > actually, on reflection, I do ... > > ... I assume that you're saying that building a sysroot is tricky? Yes, for different reasons. Sorry.
AFAICT, from testing on cris-elf Xf from i686-darwin9 this is fixed.
Subject: Re: [4.6 Regression]: gcc.dg/tls/alias-1.c > AFAICT, from testing on cris-elf Xf from i686-darwin9 this is fixed. It also appears fixed on hppa64-hp-hpux11.11.