--- Comment #3 from sje at cup dot hp dot com 2009-01-27 17:54 ---
No, I don't have a user application. I believe the problem was that the user
was compiling a program with something like
-Wl,--section-start,.text=0x11000 and because the crt files weren't
compiled wit
gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
GCC target triplet: x86_64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #10 from sje at cup dot hp dot com 2009-01-22 00:08 ---
Pointer to http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00371.html where Martin
Jambor says he has looked at this bug and says he thinks it is a libmudflap bug
and not actually related to the patch that caused it to
--- Comment #5 from sje at cup dot hp dot com 2009-01-20 23:12 ---
I tested the patch on my original code (that the included test was cut down
from) and it compiled that program with no problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38857
--- Comment #3 from sje at cup dot hp dot com 2009-01-20 19:37 ---
Added documentation about syscall_linkage to 4.4.0 documentation.
Closing out defect.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- 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
--- Comment #8 from sje at cup dot hp dot com 2009-01-15 23:45 ---
Fixed with change to test.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #13 from sje at cup dot hp dot com 2009-01-15 23:23 ---
It looks like the test was changed to fix this failure. Marking as fixed.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #7 from sje at cup dot hp dot com 2009-01-15 23:09 ---
I think this should be closed as WONTFIX. There may or may not be a 3.3.6 GCC
bug that was causing a bootstrap failure but it isn't going to be fixed so we
may as well close this defect. If anyone objects the
--- Comment #32 from sje at cup dot hp dot com 2009-01-15 23:03 ---
*** Bug 30183 has been marked as a duplicate of this bug. ***
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #3 from sje at cup dot hp dot com 2009-01-15 23:03 ---
I agree that this is a duplicate of pr29478 so I am going to close it as such.
*** This bug has been marked as a duplicate of 29478 ***
--
sje at cup dot hp dot com changed:
What|Removed
--- Comment #6 from sje at cup dot hp dot com 2009-01-15 22:58 ---
It looks like this test is passing since the test was changed to include
the #ifdef HAVE_C99_RUNTIME. It looks OK on the 4.3 branch and trunk so
I think we can close it. Any objections?
--
sje at cup dot hp dot com
--- Comment #4 from sje at cup dot hp dot com 2009-01-15 22:16 ---
Bug was fixed before 4.3.0 was released. Closing as fixed.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #2 from sje at cup dot hp dot com 2009-01-15 22:09 ---
David, can we close this out? I don't see the failure with 4.3.0 or on ToT.
I am guessing this was fixed with the following change to
ssion] ICE in selective scheduler
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
G
--- Comment #11 from sje at cup dot hp dot com 2009-01-05 23:15 ---
Zdenek, are you still looking at this bug? As I mention in comment #7, I think
the fix that is checked in is good, it is just the test that is bad. I don't
see a good way to fix the test, I would support just rem
--- Comment #9 from sje at cup dot hp dot com 2009-01-05 18:46 ---
I found the same fix earlier and submitted a patch but forgot to update the PR
which is probably why you didn't notice it.
http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00663.html
My patch doesn't check for
--- Comment #9 from sje at cup dot hp dot com 2008-12-09 17:05 ---
Fixed by skipping the test on hppa64.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #3 from sje at cup dot hp dot com 2008-12-05 17:16 ---
Dave, I added a dg-timeout-factor to this test for HPPA so it shouldn't time
out on PA boxes anymore. I hadn't noticed the x86 timeout part of the report
when I first looked at it. Do you still have that pr
--- Comment #15 from sje at cup dot hp dot com 2008-12-04 00:27 ---
I noticed the reference to hppa in comment #13 of this bug report. hppa uses
stabs but does not define DBX_USE_BINCL so is probably not affected by this
bug. If hppa is the only reason not to close it we can probably
--- Comment #7 from sje at cup dot hp dot com 2008-11-20 19:05 ---
gcc.dg/20020425-1.c is a separate issue where the 'remove useless statements'
pass is very slow. I will add some comments to that bug report soon if I can't
come up with a fix.
Resolving this
--- Comment #5 from sje at cup dot hp dot com 2008-11-20 18:30 ---
The limits-fnargs.c tests pass on my IA64 platforms (HP-UX and Linux). It
still failed on hppa64-*-hpux* with a timeout but my PA box is quite slow and I
have other tests timing out there as well. I am willing to call
--- Comment #10 from sje at cup dot hp dot com 2008-11-18 23:25 ---
If you only get slow compilation at -O2 and above then your problem is probably
due to PR 37790. The original problem affected -O1 compiles as well as -O2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
--- Comment #22 from sje at cup dot hp dot com 2008-11-18 23:21 ---
Your plan sounds good to me. I am thinking that using the timeout-factor
on g++.dg/torture/pr31863.C, gcc.c-torture/compile/20001226-1.c, and
gcc.dg/20020425-1.c to deal with the compiler timeouts on these long
--- Comment #20 from sje at cup dot hp dot com 2008-11-18 22:39 ---
I see there were some patches submitted for this issue
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01098.html
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00267.html
I get timeouts on my slow hppa system and would be
--- Comment #12 from sje at cup dot hp dot com 2008-11-18 17:31 ---
The new test is also failing on IA64 HP-UX and PA HP-UX (32 and 64 bits). It
is not failing on IA64 Linux. Could the test have a big-endian/little-endian
issue?
--
sje at cup dot hp dot com changed
--- Comment #4 from sje at cup dot hp dot com 2008-11-18 17:11 ---
A dg-options to set -fpic would fix the test on hppa64 but I think we might
want to xfail it instead and fix it after 4.4. Technically, I don't think this
is a 4.4 Regression since the test is new and the behavio
--- Comment #2 from sje at cup dot hp dot com 2008-11-17 22:58 ---
hppa64 is setting __PIC__ because it sets flag_pic and generates PIC code by
default but it sets flag_pic to 2 in override_options after we have already
checked its value in decode_options and used its value to set
--- Comment #7 from sje at cup dot hp dot com 2008-11-17 18:41 ---
This also causes the failure of gcc.dg/pr37106-1.c on ia64-*-* targets.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #5 from sje at cup dot hp dot com 2008-11-14 20:19 ---
Fixed.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from sje at cup dot hp dot com 2008-11-13 22:55 ---
Submitted a test suite patch at
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00607.html
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #2 from sje at cup dot hp dot com 2008-11-13 16:57 ---
This seems to be the first non-386 specific test to use
__attribute__((optimize)).
It doesn't look like a regression, it has never worked but was never tested
before.
The problem is that normally ia64_override_op
--- Comment #4 from sje at cup dot hp dot com 2008-11-04 16:54 ---
I have submitted a patch at
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00125.html
and will check it in tomorrow. It should fix all the libgomp failures on IA64
Linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #2 from sje at cup dot hp dot com 2008-10-31 20:03 ---
It looks like it is Linux specific in addition to being IA64 specific. I can
make the included test case fail on my Debian Linux box but not on my HP-UX
box. If I do not optimize (-O0) then it fails more often then if
--- Comment #4 from sje at cup dot hp dot com 2008-10-29 19:49 ---
Fixed with patch to libgcov.c
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #7 from sje at cup dot hp dot com 2008-10-29 19:43 ---
Deleted test as it is no longer valid since we don't support
non-unit-at-a-time.
--
sje at cup dot hp dot com changed:
What|Removed |
--- Comment #4 from sje at cup dot hp dot com 2008-10-28 21:51 ---
I have posted a patch in which I propose removing this test. It has not gotten
any feedback yet.
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00826.html
--
sje at cup dot hp dot com changed:
What
--- Comment #9 from sje at cup dot hp dot com 2008-10-28 18:26 ---
Further investigation shows that it is not the size of common that is the
problem. The bug is related to the new union of st_parameter_43 and
st_parameter_44. Specifically, st_parameter_44 contains pos which is type
--- Comment #8 from sje at cup dot hp dot com 2008-10-20 15:02 ---
With respect to comment #5, the problem isn't changing the library side. It is
changing the compiler side. The compiler, as near as I can tell, doesn't
declare the structure the way the library does but buil
--- Comment #2 from sje at cup dot hp dot com 2008-10-16 23:17 ---
This test uses -fno-unit-at-a-time which basically no longer exists. I believe
it is currently accepted as an alias for -fno-toplevel-reorder. Does it make
sense to just remove this test?
--
sje at cup dot hp dot
--- Comment #7 from sje at cup dot hp dot com 2008-10-16 21:32 ---
The new test that was added fails for me on ia64-*-* platforms too. It looks
like the fix for the original bug is right in that it is preventing the
volatile assignment in being moved but the test is bad because other
t gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37853
--- Comment #3 from sje at cup dot hp dot com 2008-10-16 15:23 ---
While changing the compiler would not break the ABI it seems like it would be
pretty difficult. It looks to me like the compiler is building the
offsets/fields based on the types in ioparm.def and assumes no padding. I
org
ReportedBy: sje at cup dot hp dot com
GCC target triplet: ia64-*-hpux*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37839
--- 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
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
GCC target triplet: ia64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37790
--- Comment #8 from sje at cup dot hp dot com 2008-09-22 16:35 ---
I'll try to review the IA64 sel-sched patch over the next couple of weeks. I
can't approve the workaround since it is not IA64 specific (it is in
haifa-sched.c).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37381
--- Comment #6 from sje at cup dot hp dot com 2008-09-19 23:01 ---
I am not sure what I would be reviewing. Alexander, do you want me to review
the patch from comment #4 as a fix for this bug or is there another patch you
would like to propose to bring the ia64 sel-sched changes over
--- Comment #11 from sje at cup dot hp dot com 2008-09-10 21:22 ---
Created an attachment (id=16288)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16288&action=view)
Smaller test case
Here is a smaller test case cut down from GCC sources.
--
http://gcc.gnu.org/b
--- Comment #5 from sje at cup dot hp dot com 2008-09-08 21:47 ---
I wonder if the problem is the new call to force_gimple_operand. We now have:
src = force_gimple_operand (src, ..)
and then later we use src in the call to gimple_build_assign. I think the call
to
dot gnu dot org
ReportedBy: sje at cup dot hp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37167
--- 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 #2 from sje at cup dot hp dot com 2008-08-06 20:28 ---
I am resolving this as invalid since it is not a GCC bug (unless you consider
not using -Z to be a bug). There is a patch for libpam which should fix the
null pointer reference available from HP. It is HP patch
--- 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
--- 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 #1 from sje at cup dot hp dot com 2008-07-02 17:17 ---
I don't see any reason why my patch would cause this problem. Looking through
my old test logs I see this test failing before my patch as well as after it.
The failures go back to version 126651 which is the o
--- 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 #3 from sje at cup dot hp dot com 2008-04-25 15:34 ---
Fixed with patch that removes the bad check.
--
sje at cup dot hp dot com changed:
What|Removed |Added
.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33092
--- Comment #6 from sje at cup dot hp dot com 2007-08-15 20:12 ---
Fixed with patch to caller-save.c
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #4 from sje at cup dot hp dot com 2007-08-10 20:50 ---
This bug is related to Jan Hubicka's caller-save changes. Applying my division
code change to version 126878 results in working code, applying my division
code to version 126879 results in compilation failures.
--- Comment #7 from sje at cup dot hp dot com 2007-08-09 17:02 ---
Created an attachment (id=14047)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14047&action=view)
untested patch
I can't reliably reproduce the problem but the attached patch may fix it. It
removes
--- Comment #3 from sje at cup dot hp dot com 2007-08-03 22:10 ---
I no longer think this bug is due to how I convert types. I don't think there
is necessarily a bug in the division code but that the increased floating point
register pressure is triggering an existing bug. The fa
--- Comment #2 from sje at cup dot hp dot com 2007-08-03 22:05 ---
Created an attachment (id=14019)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14019&action=view)
New test case
The first test case only fails on HP-UX in 32 bit mode. This new test case
fails on HP-UX
--- Comment #1 from sje at cup dot hp dot com 2007-08-01 19:54 ---
Created an attachment (id=14005)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14005&action=view)
test program that will ICE at -O2
Attached is a Fortran test program that will ICE if compiled at -O2
register
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
GCC host triplet: ia64-*-*
GCC
--- Comment #4 from sje at cup dot hp dot com 2007-07-26 17:19 ---
Fix is checked in.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status
--- Comment #11 from sje at cup dot hp dot com 2007-07-26 16:44 ---
Sorry, I missed the fact that it was a regression. I will test the 4.2 branch
and then backport it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
--- Comment #9 from sje at cup dot hp dot com 2007-07-26 16:30 ---
The fix for this was approved and checked into mainline.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #4 from sje at cup dot hp dot com 2007-07-25 22:56 ---
The test case is still not working for me on IA64 HP-UX. I also still see
gfortran.dg/c_kind_params.f90 failing at all optimization levels.
c_char_tests.f03 also fails
--
sje at cup dot hp dot com changed
--- Comment #7 from sje at cup dot hp dot com 2007-07-25 16:52 ---
Carolyn has checked in a patch to var-tracking.c and I can bootstrap IA64 Linux
so I am going to close this out as fixed. The patch that fixed this was:
2007-07-18 Caroline Tice <[EMAIL PROTECTED]>
--- Comment #2 from sje at cup dot hp dot com 2007-07-25 16:49 ---
Yes, that patch (now in the main line) seems to have fixed the problem. The
failures have gone away so I will close this defect.
--
sje at cup dot hp dot com changed:
What|Removed
--- Comment #7 from sje at cup dot hp dot com 2007-07-25 16:20 ---
Well, that was silly. I couldn't reproduce the problem because I had a patch
in my local tree. Here is the patch I created, I will submit it to
gcc-patches.
Basically, get_vectype_for_scalar_type can return a NULL
function
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
GCC host triplet: ia64-*-lin
--- Comment #4 from sje at cup dot hp dot com 2007-07-03 20:19 ---
I just tried to reproduce this bug on IA64 Linux (and HP-UX) with ToT sources
(version 126242) and was not able to. Can anyone else reproduce this with ToT
sources?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from sje at cup dot hp dot com 2007-07-02 21:27 ---
I can make the warning message go away by using -fno-schedule-insns2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32338
--- Comment #7 from sje at cup dot hp dot com 2007-07-02 17:16 ---
Patch applied.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|NEW
--- Comment #5 from sje at cup dot hp dot com 2007-06-21 22:38 ---
The non-optimized infinite loop problem looks like some kind of memory
corruption problem. At the end of bitmap_element_allocate I put a line
"gcc_assert (element != head);" which should never trigger be
--- Comment #4 from sje at cup dot hp dot com 2007-06-21 17:13 ---
With optimization, it looks like we die because df_insn_change_bb can handle
insn_info being NULL but it can't handle insn_info->defs (or uses or eq_uses)
being NULL and that is what is happening with -O2.
--- Comment #3 from sje at cup dot hp dot com 2007-06-21 17:10 ---
Slightly shorter test case:
unsigned char inb_local(unsigned long port)
{
unsigned char value;
__asm__ __volatile__("in" "b" " %w1, %" "b" "0" : "
--- Comment #2 from sje at cup dot hp dot com 2007-06-21 16:30 ---
Here is a preprocessed test case"
typedef __builtin_va_list __gnuc_va_list;
typedef __gnuc_va_list va_list;
unsigned char inb_local(unsigned long port) { unsigned char value; __asm__
__vol
atile__("in" &
--- Comment #1 from sje at cup dot hp dot com 2007-06-19 21:12 ---
I proposed XFAIL'ing the test at one point but that patch was not accepted.
See http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02016.html
I get the same failure on IA64 HP-UX.
--
sje at cup dot hp dot com ch
--- Comment #1 from sje at cup dot hp dot com 2007-06-07 22:47 ---
I have looked into this bug and I think it is an HP math lib bug. The 64 bit
powf function is using %fr12R but not saving/restoring it the way it is
supposed to. I have a query in to the math lib folks to see if they
--- Comment #2 from sje at cup dot hp dot com 2007-06-07 17:49 ---
I don't think this defect is related to PR 32716. This problem only occurs
when the array size of X is 1. I posted a patch at
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00357.html
and tried to address Ri
--- Comment #2 from sje at cup dot hp dot com 2007-06-07 17:29 ---
This is fixed on HP-UX 11.* systems but is still an issue on HP-UX 10.*
systems.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #4 from sje at cup dot hp dot com 2007-06-07 15:38 ---
This is fixed with a testsuite change in version 125510. I forgot to put
the PR number in the ChangeLog file. I changed the test to do an approximate
comparision instead of an exact one.
--
sje at cup dot hp dot
--
sje at cup dot hp dot com changed:
What|Removed |Added
CC||sje at cup dot hp dot com
Status|UNCONFIRMED
--- Comment #1 from sje at cup dot hp dot com 2007-06-06 22:48 ---
Dave, I am not seeing this in my recent PA runs. Do you still get this failure
or can we close this defect out.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #3 from sje at cup dot hp dot com 2007-06-06 22:04 ---
Here is a cutdown test case, it looks like we have a roundoff difference
between the exponentiation done at compile time and the exponentiation done at
run time and thus a and b are not 'exactly the same'.
--- Comment #16 from sje at cup dot hp dot com 2007-06-04 16:03 ---
Fixed now. All testcases are working with ToT.
--
sje at cup dot hp dot com changed:
What|Removed |Added
: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
GCC target triplet: x86_64-*-* ia64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32087
--- Comment #1 from sje at cup dot hp dot com 2007-05-24 20:50 ---
HPPA HP-UX platforms do not support the dwarf debugging format.
*** This bug has been marked as a duplicate of 9468 ***
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #15 from sje at cup dot hp dot com 2007-05-24 20:50 ---
*** Bug 32070 has been marked as a duplicate of this bug. ***
--
sje at cup dot hp dot com changed:
What|Removed |Added
201 - 300 of 571 matches
Mail list logo
