FAIL: gcc.dg/tls/pr24428-2.c execution test FAIL: gcc.dg/tls/pr24428.c execution test have appeared on ia64-hp-hpux11.23 when those tests were added (20051018-20051020), on both mainline and 4.0 branch. These failures only appear with -milp32 not -mlp64, *except* that on mainline only FAIL: gcc.dg/tls/pr24428.c execution test appears also with -mlp64. This is a regression from 4.0 branch, and gcc-testresults shows it also appears on ia64-linux. The corresponding failure on IA32 is bug 24475.
Leaving as P2, pending analysis.
The testsuite patch that fixes IA32 tests (and should also fix IA64 issues reported here) is at http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01059.html. Patch is still waiting for review, however I can't test it on IA64.
This really needs to be investigated by someone with native hpux access. All that I can add is that the problem is not present on ia64-linux, so it could very well be a bug in hpux runtime or in hpux assembler or linker. On ia64-linux (and guess hpux -mlp64 as well) the assembly contains: addl r15 = @tprel(thrtest#+648), r2 addl r14 = @tprel(thrtest#), r2 so perhaps the toolchain can't cope with offseted tprel relocations.
These tests, along with g++.dg/tls/static-1.C are failing due to a bug in the HP linker. The linker has been fixed but not yet released. The problem is that the linker is using the SHF_HP_TLS (0x01000000) flag for thread local storage instead of SHF_TLS. I am going to see if I can get a patch accepted into binutils where we set both flags so that we don't need to wait for the patched linker. But first I need to figure out how to do it.
A patch to binutils was submitted and checked in for this. The test will pass with the latest binutils now. I am not sure if the defect should be closed or not. Binutils patch: http://sourceware.org/ml/binutils/2006-02/msg00045.html
I've closed this bug on two grounds: (1) there's nothing for GCC to do about it, as the problem is either a binutils or HP-UX linker bug, and (2) the binutils change has been checked in, so affected users can simply use the latest binutils.
This issue will not be resolved in GCC 4.1.0; retargeted at GCC 4.1.1.