This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode
- From: "ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 15 Jul 2011 12:01:33 +0000
- Subject: [Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode
- Auto-submitted: auto-generated
- References: <bug-49541-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49541
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-07-15 12:01:02 UTC ---
> The problem is that the testsuite (lib/libgomp.exp) unconditionally
> links with -lgomp even for the -fno-openmp testcases. I'd argue that
> this is a testsuite-only problem (pilot error, actually) and can be
> worked around by use of dg-add-options tls.
On second thought, it seems better to just remove the explicit -lgomp.
The following patch worked for me on sparc-pc-solaris2.8,
i386-pc-solaris2.10, and x86_64-unknown-linux-gnu:
diff --git a/libgomp/testsuite/lib/libgomp.exp
b/libgomp/testsuite/lib/libgomp.exp
--- a/libgomp/testsuite/lib/libgomp.exp
+++ b/libgomp/testsuite/lib/libgomp.exp
@@ -137,7 +137,6 @@ proc libgomp_init { args } {
lappend ALWAYS_CFLAGS "ldflags=-L${blddir}/.libs"
}
lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/.."
- lappend ALWAYS_CFLAGS "ldflags=-lgomp"
# We use atomic operations in the testcases to validate results.
if { ([istarget i?86-*-*] || [istarget x86_64-*-*])
Rainer