--- Comment #24 from sje at cup dot hp dot com 2010-01-12 00:58 ---
Never mind, when I copied (and modified) the x86 tests for ia64 I forgot to put
a 'return 0' at the end of the main program so I was getting a non-zero exit.
I will test my patch tonight and if all looks good
--- Comment #22 from sje at cup dot hp dot com 2010-01-11 23:33 ---
I am looking at this on IA64 and fixing it for V2SI seems simple enough.
I will attach a patch. But I am not sure what to do for V4HI and V8QI.
The current code uses an 'unsigned saturating subtraction'
--- Comment #21 from sje at cup dot hp dot com 2010-01-11 23:32 ---
Created an attachment (id=19544)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19544&action=view)
ia64 patch (fixes int, not short or char)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42542
--- Comment #12 from sje at cup dot hp dot com 2009-05-05 17:54 ---
I retested the test case in comment#1 on a hppa2.0w-hp-hpux11.11 box and it
still gives an ICE with 4.4.0 and with ToT (r147128). I don't have a PA linux
box so I did not test the example from comment #9 on a linu
--- Comment #9 from sje at cup dot hp dot com 2009-01-29 18:57 ---
So far I have been unable to reproduce this problem. When compiling gsf-scan.i
I do not even reach the code that I changed in PR 38615 and I get the same code
with or without my change included.
Assuming there is a way
--- Comment #6 from sje at cup dot hp dot com 2009-01-29 17:00 ---
What GCC options was gsf-scan.i compiled with? I am trying to see what
variables are getting/not getting promoted during the compilation and I am not
seeing it affect any variables if I just compile gsf-scan.i with -O
--- Comment #5 from sje at cup dot hp dot com 2009-01-16 22:38 ---
Fixed on Trunk (4.4) and 4.3 branch. 4.2 branch is closed (or shortly will be)
so I am going to just close this as fixed.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--
sje at cup dot hp dot com changed:
What|Removed |Added
Known to fail|4.2.5 4.3.3 4.4.0 |4.2.5 4.3.3
Known to work|4.1.3 4.0.2 |4.1.3 4.0.2
--
sje at cup dot hp dot com changed:
What|Removed |Added
CC||sje at cup dot hp dot com
URL
--- Comment #29 from sje at cup dot hp dot com 2008-10-15 17:06 ---
See http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00647.html for a discussion
and proposed patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
--- You are receiving this mail because: ---
You are on
--- Comment #9 from sje at cup dot hp dot com 2008-08-18 21:51 ---
Kevin, I can no longer reproduce this bug. I think it was fixed by the same
patch that fixed PR 35659. Are you able to reproduce this or can we close it
as fixed?
--
sje at cup dot hp dot com changed
--- Comment #24 from sje at cup dot hp dot com 2008-08-04 17:34 ---
I bootstrapped the 3 patches on mainline and 4.3 branch and verified that they
fix the problem that is reported on the 4.3 branch with the patches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
--- You
--- Comment #22 from sje at cup dot hp dot com 2008-08-01 23:28 ---
Maxim, have you had time to look at this bug? Given that it is generating bad
code and is in 4.3.0 and 4.3.1 I was wondering if it will be fixed for 4.3.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
--- Comment #7 from sje at cup dot hp dot com 2008-06-05 23:02 ---
I now think this is a register scheduling bug. If I use -fno-schedule-insns2
then the bug doesn't happen even with "-O2 fno-automatic -frename-registers".
The problem seems to be scheduling the assignme
--- Comment #8 from sje at cup dot hp dot com 2008-06-03 17:59 ---
I looked at this bug and I can reproduce it using the precompiled archives from
the link. I have not tried to get the CERN sources to create a small 'real'
test case. I noticed that the bug does not happen
--- Comment #6 from sje at cup dot hp dot com 2008-05-23 15:02 ---
It looks like this is a bug in register renaming. register renaming is turned
on by -floop-unroll. You can reproduce the bug using -frename-registers in
place of -funroll-loops.
--
http://gcc.gnu.org/bugzilla
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #5 from sje at cup dot hp dot com 2008-05-22 18:52 ---
Created an attachment (id=15672)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15672&action=view)
cutdown test case
This smaller test case requires the same options as the original.
--
http://gcc.
--- Comment #4 from sje at cup dot hp dot com 2008-05-21 15:30 ---
Now I can reproduce it. I don't know if you intended this or not but the clean
target in the Makefile removed the good objects but left the bad one so that
when I rebuilt I still had the old bad object a
--- Comment #4 from sje at cup dot hp dot com 2008-05-20 21:01 ---
I wonder if this is related to PR target/35695, the floating point division bug
that Jim Wilson fixed. Could you try it with ToT or with the latest 4.3
branch, both of which have Jim's fix in them.
--
sje at cu
--- Comment #2 from sje at cup dot hp dot com 2008-05-20 20:50 ---
I cannot reproduce this error. I have compiled the test case with
various options and always get output that includes
Test# 1 ( C201 ): *** failed ***
and
Test# 1 ( GENT ): *** failed ***
I get this when I use
--- 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 be it
--- 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 #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 #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 #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
--- 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 will be
--- Comment #12 from sje at cup dot hp dot com 2006-08-04 21:18 ---
The bootstrap and testing on my ia64 HP-UX system also had no regressions with
this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28489
--- You are receiving this mail because: ---
You are on the
--- Comment #12 from sje at cup dot hp dot com 2006-08-03 16:39 ---
Fixed by backporting Nathan's patch and the fix for PR 27291.
--
sje at cup dot hp dot com changed:
What|Removed |
--- Comment #8 from sje at cup dot hp dot com 2006-08-01 18:22 ---
The time that this started occurring looks to be about the time that Maxim was
making scheduling changes for IA64 speculation. Maxim could you look at this
bug and see if it is related to any of your changes to IA64
--- Comment #10 from sje at cup dot hp dot com 2006-07-31 16:19 ---
My weekend bootstrapping and testing on ia64-hp-hpux11.23 and ia64 Linux on the
4.1 branch showed no regressions. I think I should send email to gcc-patches
before checking it in on the 4.1 branch since the first patch
--- Comment #8 from sje at cup dot hp dot com 2006-07-28 21:45 ---
If we apply the patch from
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02094.html first then we can apply
the patch for PR 27291. I did this on the 4.1 branch and the bug went away. I
have not done a full bootstrap
--- Additional Comments From sje at cup dot hp dot com 2005-07-19 20:58
---
Fixed on mainline for 4.1 and on 4.0.X branch for 4.0.2.
--
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 is. But
--- 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 for
--- 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
36 matches
Mail list logo
