g++.dg/tls/diag-1.C FAILs on Tru64 UNIX: FAIL: g++.dg/tls/diag-1.C (internal compiler error) FAIL: g++.dg/tls/diag-1.C (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/osf/gcc/testsuite/g++.dg/tls/diag-1.C:31:1: internal compiler error: in function_and_variable_visibility, at ipa.c:926
Still happens as of 20110715: $ cc1plus -quiet -fpreprocessed g++.dg/tls/diag-1.C g++.dg/tls/diag-1.C:31:1: internal compiler error: in function_and_variable_visibility, at ipa.c:887 Jan, any idea? Thanks. Rainer
This may be the same fault I'm seeing on AIX with GCC 4.6.1--does Tru64 use an "emulated TLS" as well? I reduced diag-1.C to this: template <typename T> struct B { static __thread T t; }; template <typename T> __thread T B<T>::t = 42; void bar () { int j = B<int>::t; } If it is the same fault, what's happening is, a weak, public reference is being created for the TLS emulation template for B<int>::t. When it is used to initialize j, the public flag is cleared--it's local, after all. (This is in tree-emutls.c at lines 238 to 247 in both 4.6.1 and SVN revision 180430.) But the assertion in ipa.c "knows" anything weak must be either public or extern--that's the error in the ICE message. I don't know if the error is in clearing the 'public' flag, or in assuming everything weak is public or extern. Note I haven't yet gotten the trunk code to build; we've got a bit of a shortage of AIX horsepower. As there are trunk changes in both ipa.c and tree-emutls.c, it is possible AIX is fine with trunk but Tru64 still has issues.
> --- Comment #2 from Graham Reed <greed at pobox dot com> 2011-10-25 20:04:32 UTC --- > This may be the same fault I'm seeing on AIX with GCC 4.6.1--does Tru64 use an > "emulated TLS" as well? It does: while the platform could support native TLS, it is so different from the usual ELF implementations that it hasn't been implemented in gcc. > I reduced diag-1.C to this: > > template <typename T> struct B { static __thread T t; }; > template <typename T> __thread T B<T>::t = 42; > void bar () { int j = B<int>::t; } I get the same ICE on that testcase with trunk as of r180287. Rainer
Created attachment 25617 [details] KLUDGE/workaround for ICE I worked around the ICE on AIX with this patch. THIS IS A WORKAROUND ONLY--I do not know the code anywhere near well enough to believe this is a correct fix. It changes tree-emutls.c so that a weak symbol remains public, which then lets it go through the assert in ipa.c.
(In reply to comment #4) Sorry, forgot to add: I made the patch against 4.6.1, and have run bootstrap and testing on AIX 5.3 TL4. I was able to apply it unchanged against trunk r180430, but have not yet gotten through a build of that source.
> I made the patch against 4.6.1, and have run bootstrap and testing on AIX 5.3 > TL4. I was able to apply it unchanged against trunk r180430, but have not yet > gotten through a build of that source. I've just done a quick rebuild of tree-emutls.o and cc1plus on Tru64 UNIX V5.1B, and now I can successfully compile both your minimized testcase and g++.dg/tls/diag-1.C passes as well. Thanks. Rainer
I've now gotten the trunk (SVN 180430) built on AIX 5.3 TL4; the problem is the same as 4.6.1 and is also "solved" with the same patch. So this is definitely not target-specific, it seems to be in the emulated TLS.
Removing the osf5.1b target because that's no longer supported. There's an error in rs6000.c when attempting to cross-compile to rs6000-ibm-aix5.3.0; I didn't spend too much time looking at it. But I reasoned that if this is really any target using emutls, I ought to be able to replicate it with --disable-tls on any host. I don't see the ICE, so I'm willing to believe that the problem has been fixed somewhere in the last 3 years.