--- Comment #12 from sje at cup dot hp dot com 2006-08-22 16:46 ---
The patch mentioned in comment #11 also works for me. Note that I had to only
use the patch that fixed the bug, the sencond patch / rest of the patch that is
for improved debuggability caused warnings during bootstraps
--- Comment #16 from sje at cup dot hp dot com 2006-08-28 16:07 ---
Yes, I did some performance measurements with SPEC2000. Allowing any (symbol +
offset) resulted in slightly slower code overall, allowing no (symbol + offset)
resulted in slightly faster code overall. I
--- Comment #5 from sje at cup dot hp dot com 2006-09-11 17:12 ---
I will see if I can find the checkin on the 4.1 branch that caused the failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28604
--- Comment #6 from sje at cup dot hp dot com 2006-09-11 20:39 ---
It looks like this failure was introduced with r115620.
+2006-07-20 Paul Brook [EMAIL PROTECTED]
+
+ Backport from mainline.
+ PR 27363
+ * cse.c (cse_insn): Add destination addresses to hash table
--- Comment #15 from sje at cup dot hp dot com 2006-09-11 22:31 ---
Bryce, have you looked at ifdef'ing the use of _Unwind_GetIPInfo in the Java
library? Would you be willing to do so? I have created an autoconf test
(GCC_CHECK_UNWIND_GETIPINFO) in trunk/config/unwind_ipinfo.m4
--- Comment #2 from sje at cup dot hp dot com 2006-09-12 16:36 ---
I wonder if it would be possible to implement something like 'dg-timeout 600'
so that the timeout could be changed for just some tests and possibly just on
some hosts by using the target option with dg-timeout. Most
--- Comment #1 from sje at cup dot hp dot com 2006-09-13 20:32 ---
I had someone try to use 64 bit PA GCC code with HP Java and they ran into two
unsats, __cxa_finalize and _Jv_RegisterClasses. In GCC 4.0.3 there is a weak
definition of __cxa_finalize in libstdc++.sl, but in GCC 4.1.1
--- Comment #2 from sje at cup dot hp dot com 2006-09-13 20:37 ---
Well, I guess I should have read comment 1 before adding comment 2,
sorry for the extra mail David.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28821
--- Comment #4 from sje at cup dot hp dot com 2006-09-13 21:08 ---
The underlying problem here is twofold, The C++ configure script will only
check for mbstate_t if wchar is enabled. On IA64 HP-UX wchar is not enabled
because we are missing a define that makes the wchar type visible
--- Comment #2 from sje at cup dot hp dot com 2006-09-13 21:21 ---
I tried the test case with ToT, Top of 4.1 branch, and Top of 4.0 branch, the
results are below. My header files show the second argument to shmget to be
size_t (64 bits) but the man page on my system says the second
--- Comment #9 from sje at cup dot hp dot com 2006-09-14 22:37 ---
I don't see any way to delete a block without deleting the attached jumptable
so the only fix I can see is to not delete the block in the first place. The
block is being deleted on IA64 because it is a 'then block
--- Comment #2 from sje at cup dot hp dot com 2006-09-15 16:46 ---
I took a quick look at this bug, the fix is easy, I have included a patch I
created. The problem is that there are 172 tests in the g++ and libstdc++
test suites that have empty enums in them. If we give an error
--- Comment #11 from sje at cup dot hp dot com 2006-09-20 16:49 ---
Fix is now checked in.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status
--- Comment #7 from sje at cup dot hp dot com 2006-09-20 21:23 ---
This bug is weird. If I remove the code in cse_insn where the dest_addr_elt
field is used, I still get the bug. So the problem occurs when creating the
dest_addr_elt data, not when using it. This makes no sense to me
--- Comment #9 from sje at cup dot hp dot com 2006-10-03 17:42 ---
I submitted a patch for this defect,
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01108.html
however the failure seems to have gone away even without applying this patch.
I think (but did not verify) that this patch went
--- Comment #1 from sje at cup dot hp dot com 2006-10-03 17:55 ---
I think ia64-hp-hpux11.23 is having a problem here too. I get a failure with
the test gfortran.dg/large_real_kind_form_io_2.f90, which uses the nearest
intrinsic. I use mpfr 2.2 to build. I think the bug may
--- Comment #12 from sje at cup dot hp dot com 2006-10-04 21:08 ---
The uses of __Unwind_GetIPInfo in libstdc++ and libjava have been fixed. It
looks like the report in PR 29342 is due to the use of __Unwind_GetIPInfo in
gcc/unwind-c.c. I will create a patch for this use.
--
http
--- Comment #22 from sje at cup dot hp dot com 2006-10-09 18:27 ---
Backported the change to 4.1 and 4.0 branches. Closing as fixed.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #14 from sje at cup dot hp dot com 2006-10-09 18:31 ---
With the patch I just checked in, I believe that this defect is now fixed.
The uses of GetIPInfo in libstdc++ and libjava were fixed earlier, this latest
patch fixes the use in unwind-c.c and that should
--- Comment #3 from sje at cup dot hp dot com 2006-10-09 20:58 ---
William, can you reproduce this problem with a newer GCC? I have tried several
versions of GCC and all I get is an error from shmget (Invalid argument).
Given that the shmget fails, the memcpy is obviously going
--- Comment #5 from sje at cup dot hp dot com 2006-10-12 17:36 ---
Fixed with a testsuite change to check for File Entry: or .file. Platforms
that set DWARF2_ASM_LINE_DEBUG_INFO will output a .file line but not a File
Entry: line and the test now checks for either.
--
sje at cup
--- Comment #4 from sje at cup dot hp dot com 2006-10-18 18:16 ---
Looking at my old logs it looks like gfortran.dg/actual_array_constructor_1.f90
has been failing on hppa64 since it first went in on April 21, 2006. Someone
is creating a TImode variable even though hppa64 doesn't
--- Comment #6 from sje at cup dot hp dot com 2006-10-18 20:49 ---
Well, I have tracked it back a little ways. gfc_trans_vla_type_sizes_1 calls
gfc_trans_vla_one_sizepos with:
gfc_trans_vla_one_sizepos (TYPE_SIZE (type), body);
If I print out type-type.size I see:
gdb) p debug_tree
--- Comment #8 from sje at cup dot hp dot com 2006-10-19 18:09 ---
Well, I found that the TImode is getting introduced in layout_type. For an
ARRAY_TYPE tree there is this line:
TYPE_SIZE (type) = size_binop (MULT_EXPR, element_size
--- Comment #5 from sje at cup dot hp dot com 2006-10-31 18:15 ---
I forgot to include the PR number in my ChangeLog entry but this defect is
fixed with the patch in comment #4. It has been backported to the 4.0, 4.1,
and 4.2 branches as well as being checked in on the ToT.
--
sje
--
What|Removed |Added
CC||sje at cup dot hp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20376
--- Additional Comments From sje at cup dot hp dot com 2005-03-10 23:21
---
I have submitted a patch to xfail this test. I do not think we should change
the ia64-hpux platform to build the GCC unwind library. It currently uses the
system unwind library instead and I think
--- Additional Comments From sje at cup dot hp dot com 2005-03-17 18:21
---
See the GCC email thread starting at
http://gcc.gnu.org/ml/gcc/2005-03/msg00483.html for more information. GCC
generates bad code but the test is bogus and fixing it leads to a number of
complications
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ia64-*-*
GCC host triplet: ia64-*-*
GCC
--- Additional Comments From sje at cup dot hp dot com 2005-03-28 18:08
---
Fixed by skipping the test on IA64 HP-UX.
--
What|Removed |Added
Status|NEW
--- Additional Comments From sje at cup dot hp dot com 2005-03-28 18:11
---
Fixed by increasing arena_size on HP-UX.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From sje at cup dot hp dot com 2005-03-28 23:21
---
Fixed by not running the test on IA64 HP-UX in ILP32 mode.
--
What|Removed |Added
--- Additional Comments From sje at cup dot hp dot com 2005-03-29 17:51
---
Fixed with change to testsuite.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From sje at cup dot hp dot com 2005-03-30 23:26
---
I think this defect is fixed with the patch:
http://gcc.gnu.org/ml/gcc/2005-01/msg00589.html
that was checked in back in January of 2005.
Jan, can you confirm that the defect is fixed? It looks OK to me
--- Additional Comments From sje at cup dot hp dot com 2005-03-31 17:04
---
Fixed by not running the test suite on HP-UX.
--
What|Removed |Added
Status
--- Additional Comments From sje at cup dot hp dot com 2005-04-11 21:34
---
This also came up in the string starting at
http://gcc.gnu.org/ml/gcc/2005-03/msg00483.html
I gave a patch in
http://gcc.gnu.org/ml/gcc/2005-03/msg00729.html
but having GCC generate this error gives a bunch
--- Additional Comments From sje at cup dot hp dot com 2005-04-11 23:14
---
The problem is that the inline divide instructions are generating frcpa
instructions that use the floating point status register (fpsr) 1 when
they should be using fpsr 0.
I will test a patch overnight
--- Additional Comments From sje at cup dot hp dot com 2005-04-22 20:22
---
I submitted a patch, http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02284.html,
but as the mail says it results in a lot of regressions in the compat and
vector tests.
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From sje at cup dot hp dot com 2005-04-27 19:44
---
It looks like most of the compat tests have been fixed but I still get two
failures. They are tmpdir-gcc.dg-struct-layout-1/t002 and
tmpdir-gcc.dg-struct-layout-1/t027. I cut down t002 and wound up with
void
--- Additional Comments From sje at cup dot hp dot com 2005-05-27 18:23
---
I am not sure the underlying problem is fixed. The assembly language error
seems to come from the line:
.pred.rel.mutex p0, p1
p0 is a fixed predicate register and should never show up here. p1 is not used
: unknown
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
CC: gcc-bugs at gcc dot gnu dot org
--- Additional Comments From sje at cup dot hp dot com 2005-05-31 17:38
---
This seems more likely to be an HP library bug. I recommend trying the latest
libc patch for HP-UX 11.11, PHCO_31903. There is a reference to the HP defect
JAGad41604 that may be causing your problem. I don't
--- Additional Comments From sje at cup dot hp dot com 2005-05-31 21:10
---
It looks like this is due to code in ia64/ia64.c (ia64_compute_frame_size).
If we need to store any predicate register (before a call I presume), the code
stores them all and sets regs_ever_live[regno] to 1
--- Additional Comments From sje at cup dot hp dot com 2005-06-01 22:08
---
It is not clear to me if this bug is about whether or not we should put out the
message or if it is about the format of the message, I.e. that the quotes are
messed up.
--
What|Removed
--
Bug 14300 depends on bug 10865, which changed state.
Bug 10865 Summary: [ia64] gcc -pthread does not add -D_REENTRANT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10865
What|Old Value |New Value
--- Additional Comments From sje at cup dot hp dot com 2005-06-02 18:23
---
I am going to resolve this as invalid since I can't find any documentation to
fix. All the existing documentation I checked, even 3.2.2, is generic about what
flags pthread sets. None of them mention _REENTRENT
--- Additional Comments From sje at cup dot hp dot com 2005-06-02 21:18
---
I built a 3.4.2 GCC on an IA64 Linux box and tried to reproduce the bug but
could not. The included test case compiled with no problem.
--
What|Removed |Added
--- Additional Comments From sje at cup dot hp dot com 2005-06-02 22:46
---
This has been fixed for 4.1 because the whole sync code has been redone.
__sync_bool_compare_and_swap_di is no longer a builtin function, although
__sync_bool_compare_and_swap
__attribute__((vector_size(2048)))
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
--- Comment #4 from sje at cup dot hp dot com 2006-02-02 22:41 ---
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 (0x0100) flag
--- Comment #4 from sje at cup dot hp dot com 2006-02-03 18:05 ---
Fixed on mainline and on the 4.1 branch.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #2 from sje at cup dot hp dot com 2006-02-03 18:09 ---
Proposed patch at: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00139.html
Waiting for approval.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #2 from sje at cup dot hp dot com 2006-02-03 18:44 ---
It looks like we have an interaction between the alignment attribute and the
IA64 calling conventions. In this example GCC is treating my_t type as an
aligned pointer and not as a pointer to aligned data. Is that what
--- Comment #3 from sje at cup dot hp dot com 2006-02-04 00:04 ---
Following up to my own comment, the HP ABI expert I talked to thinks the
generated code is OK. His rationale is that to fill up the parameter
registers, you lay things out as they would be in memory and then map
--- Comment #5 from sje at cup dot hp dot com 2006-02-09 18:55 ---
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
--- Comment #2 from sje at cup dot hp dot com 2006-02-16 20:40 ---
This header worked with GCC 3.* but 4.0 is pickier about having an array of an
unknown type. I will submit a fixincludes patch to fix the header.
--
sje at cup dot hp dot com changed:
What|Removed
: sje at cup dot hp dot com
GCC build triplet: ia64-hp-hpux11.23
GCC host triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26345
--- Comment #1 from sje at cup dot hp dot com 2006-02-17 18:38 ---
Created an attachment (id=10868)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10868action=view)
Test Case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26345
--- Comment #3 from sje at cup dot hp dot com 2006-02-17 19:18 ---
I don't know how I missed your proposed patch for PR 19061. I tested it on the
test case in that bug and on my bootstrap bug that I reported here and both
look good. I used ToT sources for both tests and had to put
--- Comment #1 from sje at cup dot hp dot com 2006-02-18 00:04 ---
I believe this is the same as PR 24476 and like that problem, will work now
with the latest CVS binutils. I don't know if we want to resolve this or wait
until there is a binutils release that contains the fix
--- Comment #9 from sje at cup dot hp dot com 2006-02-23 17:44 ---
I am still seeing this fail on ia64-hp-hpux11.23 which uses real*16. I believe
the problem is in io/write.c (output_float). While write_real sets the maximum
width to 40 for real*16, output_float still uses a 32 char
--- Comment #2 from sje at cup dot hp dot com 2006-02-23 22:37 ---
I have been unable to reproduce this. I am on 11.11 and using the same
binutils and GCC sources. The main difference I see is that I am using GCC
4.0.2 to bootstrap with and you are using GCC 3.2.3 as your starting
--- Comment #12 from sje at cup dot hp dot com 2006-03-15 16:44 ---
At least on IA64, I don't think there is a way to make this test work. I tried
a change similar to yours. I also changed the setting of ndigits (uses the
magic number 27 in a couple of places), changed the number 31
--- Comment #2 from sje at cup dot hp dot com 2006-03-16 21:45 ---
I am resolving this bug as fixed with the same resolution as PR 24476, since
the change I made for PR 24476 also fixes this failure. See PR 24476 for more
information on the problem fix. Basically, you have to use
--- Comment #6 from sje at cup dot hp dot com 2006-03-16 22:03 ---
Fixed on 4.0 line for 4.0.4, 4.1 line for 4.1.1 and on ToT for 4.2.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #6 from sje at cup dot hp dot com 2006-03-16 22:25 ---
Here is a cut down test case, I guess GCC is trying to map the strncpy into an
integer move without taking alignment into account.
extern char *strncpy (char *, const char *, __SIZE_TYPE__);
int main()
{
const char
--- Comment #7 from sje at cup dot hp dot com 2006-03-16 23:06 ---
It looks to me like this is due to Richard Guenther's patch at:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00737.html
When I removed the non-structure part of this patch the problem went away.
specifically I changed
--- Comment #11 from sje at cup dot hp dot com 2006-03-16 23:16 ---
I compiled the test case at -O1 on IA64 HP-UX to get the bus error due to the
unaligned access. IA64 HP-UX does require STRICT_ALIGNMENT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26721
: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
GCC host triplet: ia64-hp-hpux11.23
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
--- Comment #4 from sje at cup dot hp dot com 2006-03-17 21:25 ---
I already fixed the problem in comment 3 with an 'obvious' checkin to
config/ia64/ia64.opts.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26734
--- Comment #5 from sje at cup dot hp dot com 2006-03-17 21:47 ---
The debugger shows:
(gdb) p debug_rtx(*unused_listp)
(deps_list 34 (nil) 0 [0x0])
(gdb) p debug_rtx(prev_link)
(UnKnown Unknown)
When I print unused_insn_list I get a long RTL that I couldn't capture.
Here
--- Comment #6 from sje at cup dot hp dot com 2006-03-17 22:34 ---
I applied the patch that Maxim created for PR 26725 but it did not seem to help
this problem. I verified the problem happened on ia64-hp-hpux11.23 in LP64
mode as well as ILP32 mode so that makes it more surprising
--- Comment #5 from sje at cup dot hp dot com 2006-04-07 17:02 ---
I believe this patch is causing a bunch of IO failures on ia64-hp-hpux11.23.
Specifically, the setting of pad looks bad to me. pad, in this case, is not
a padding on the end of the structure but a parallel array
--- Comment #8 from sje at cup dot hp dot com 2006-04-07 18:55 ---
I am not sure why it was created the way it was or why it doesn't just use
sizeof(p). I haven't looked back into SVN/email to see if there are any
comments on why it was done the way it was done. Do you know where
--- Comment #11 from sje at cup dot hp dot com 2006-04-07 22:36 ---
I think putting pad back to where it was is a good first step and I will see if
there is room on a 64 bit machine, I think we need some kind of test to make
sure that pad is always equal to or greater than the size
--- Comment #13 from sje at cup dot hp dot com 2006-04-10 18:22 ---
Putting the size of pad back seems OK on IA64 in both ILP32 and LP64 modes. In
ILP32 mode I get:
The DTP
Size of p: 136
Size of pad: 200
Size of char *: 4
Size if int: 4
In LP64 mode, both on HP-UX and Linux, I get
--- Comment #8 from sje at cup dot hp dot com 2006-04-18 18:34 ---
I tried Geoff's patch from
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00651.html
and that fixed my bootstrap failure on ia64-hp-hpux11.23.
--
sje at cup dot hp dot com changed:
What|Removed
--- Comment #3 from sje at cup dot hp dot com 2006-05-02 23:34 ---
I am not seeing this failure in my recent builds, should I go ahead and close
this defect?
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #2 from sje at cup dot hp dot com 2006-05-04 16:05 ---
My nightly build based on SVN version 113509 bootstrapped fine. What
source/SVN version were you building? I built using a GCC 4.0.2.
--
sje at cup dot hp dot com changed:
What|Removed
: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
GCC host triplet: hppa64-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27449
--- Comment #8 from sje at cup dot hp dot com 2006-05-05 21:19 ---
Is it time to close this defect out? I tried to reproduce this on HP-UX with
3.4.5, 4.0.1, and 4.1 but they all worked. The 3.2 (and I think 3.3) branches
are closed aren't they?
--
sje at cup dot hp dot com
--- Comment #8 from sje at cup dot hp dot com 2006-05-05 21:36 ---
Since this looks like an installation problem and not a real bug I am closing
it out as invalid.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #4 from sje at cup dot hp dot com 2006-05-05 21:47 ---
PR 21613 (same bug on a different platform) was closed with the comment that
this got fixed when tree-ssa was merged in and that it would hard to fix in the
3.4 branch. I verified I can still see it on 3.4.5
--- Comment #3 from sje at cup dot hp dot com 2006-05-05 22:11 ---
I don't see this failure anymore so I think we can assume it was the same bug
as PR 25168. Resolving as fixed.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #13 from sje at cup dot hp dot com 2006-05-05 22:21 ---
Dave, it looks like this defect has been fixed. Is there any reason not to
close the defect?
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #1 from sje at cup dot hp dot com 2006-05-05 22:32 ---
This is an HP linker bug and it is in PHSS_33033 and possibly in some earlier
linker patches too. There is a replacement for PHSS_33033 now. For HP-UX
11.00 the new patch is PHSS_33034 and for HP-UX 11.11 the new patch
--- Comment #10 from sje at cup dot hp dot com 2006-05-05 22:51 ---
For GCC 4.1 we changed the documentation to say that we require (rather than
just recommend) using GAS and not the HP assembler so I am going to resolve
this as invalid since it is using the HP assembler (based
--- Comment #12 from sje at cup dot hp dot com 2006-05-10 22:54 ---
I believe the patch checked in for this defect is causing
g++.old-deja/g++.other/static14.C and
g++.old-deja/g++.other/static20.C to fail.
--
sje at cup dot hp dot com changed:
What|Removed
--- Comment #9 from sje at cup dot hp dot com 2006-05-22 14:56 ---
The proposed patch fixed the failure of transfer_array_intrinsic_2.f90 on my
hppa64-hp-hpux11.11 system and I saw no regressions. I also had no regressions
on the other systems I build nightly (hppa1.1-hp-hpux11.11
--- Comment #1 from sje at cup dot hp dot com 2006-05-30 18:06 ---
My bootstraps are working fine. What maxssiz are you using?
$ grep maxssiz /stand/system
tunable maxssiz_64bit 0x4000
tunable maxssiz 0x1000
How about swap space? (swapinfo will tell you) I have 8 Gig
--- Comment #1 from sje at cup dot hp dot com 2006-06-02 22:40 ---
I believe this is because you are configuring with --with-system-libunwind and
your system unwind does not have _Unwind_GetIPInfo. This routine was added to
the GCC libunwind back in February by Jakub Jelinek to fix PR
--- Comment #3 from sje at cup dot hp dot com 2006-06-02 23:10 ---
I should have mentioned that for HP-UX, where the system unwind also does not
have _Unwind_GetIPInfo, I added it to libgcc. See
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01285.html
--
http://gcc.gnu.org
--- Comment #4 from sje at cup dot hp dot com 2006-06-05 15:37 ---
Fixed for 4.2, not a regression so not backporting for 4.0 or 4.1.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #7 from sje at cup dot hp dot com 2006-06-05 15:44 ---
Fixed on 4.1 branch and ToT (4.2) by not running the test on IA64. The test is
not valid given the IA64 run-time architecture.
--
sje at cup dot hp dot com changed:
What|Removed
--- Comment #1 from sje at cup dot hp dot com 2006-06-05 16:40 ---
This test is not failing for me. It looks like it was fixed by including
cstdio in the test source and changing the unlink to remove.
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00876.html
--
sje at cup dot hp dot
--- Comment #2 from sje at cup dot hp dot com 2006-06-05 16:43 ---
The test init5 has been xfailed on platforms where __cxa_atexit is not
implemented. Without __cxa_atexit, the test cannot pass.
--
sje at cup dot hp dot com changed:
What|Removed
--- Comment #3 from sje at cup dot hp dot com 2006-06-05 17:47 ---
I shrank my stack to match yours and still can't reproduce this problem.
What were the configure options on this? Did it use --enable-checking=all
or something like that? Also, the log makes it look like it died when
--- Comment #4 from sje at cup dot hp dot com 2006-06-05 18:22 ---
It doesn't look like we have gotten a simple test case for this. Is it time to
close it out as a duplicate of PR 12455. Handong Yeh, have you tried this with
a 4.1 (or later) GCC?
--
sje at cup dot hp dot com
--- Comment #3 from sje at cup dot hp dot com 2006-06-05 20:16 ---
I backported the change to the 4.0 and 4.1 branches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27811
--- Comment #6 from sje at cup dot hp dot com 2006-06-06 19:52 ---
Created an attachment (id=11612)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11612action=view)
Cut down test case
Here is a cutdown test case. I reproduced the problem on hppa64-hp-hpux11.11
with this cutdown
1 - 100 of 566 matches
Mail list logo
