This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libgomp/46967] lots of testsuite failures with libgomp on hppa-hp-hpux11.31
- From: "dave.anglin at bell dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 20 Aug 2011 15:45:46 +0000
- Subject: [Bug libgomp/46967] lots of testsuite failures with libgomp on hppa-hp-hpux11.31
- Auto-submitted: auto-generated
- References: <bug-46967-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967
--- Comment #8 from dave.anglin at bell dot net 2011-08-20 15:45:46 UTC ---
The pthread change was applied in r170290. If it doesn't fix the bug,
then further
debugging is needed. I can say the tests don't fail with 11.11. You
also indicated
the tests don't fail with 11.23. So, these fails either have to do
with differences in
linking, or processor architecture.
The linking issue mentioned in comment #2 is a libtool issue. It
incorrectly links in libc
in shared library links. It is possible to hack libtool to not link
in libtool on hppa*-*-hpux*.
Some other targets do this, so there is sample code. If the non
functional pthread
stubs are used, races will result causing test failures. The for-*.C
tests are especially
sensitive to this as they create many threads to parallelize loops.
The libtool project is essentially dormant, and none of the
maintainers have responded
to my patches or bug reports in recent months.
I believe there are subtle differences in the behavior of the dynamic
linker in different
hpux versions.
There is also the issue that 11.31 usually only runs on PA8800/PA8900
servers. These
CPUs have much larger instruction and data caches (32 MB), and the
caches do not
support non equivalent aliasing. From experience, I know that it is
much more difficult
to do a good pthread implementation on these CPUs. More cache
flushing is needed
than on earlier CPUs, and this changes program timing quite a bit.
It's quite tricky to
avoid the aliasing issues and cache corruption.
--
John David Anglin dave.anglin@bell.net