--- Comment #7 from hjl dot tools at gmail dot com 2008-11-07 07:43 ---
Gcc 4.3.3 revision 141662 works fine.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #9 from hjl dot tools at gmail dot com 2008-11-07 14:28 ---
(In reply to comment #8)
> Any recommendation on how to work around it with GCC 4.3.2? Seemingly
> unrelated code changes make it go away. Thanks - Chris.
>
Add "-fno-if-conversion" should
--- Comment #6 from hjl dot tools at gmail dot com 2008-11-11 06:49 ---
The current patch is at
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00180.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
doesn't work on ia64
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org
unction
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: i686-linux-gn
Version: 4.3.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC build triplet: hubicka
GCC target triplet: i686-pc-linux
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34851
--- Comment #4 from hjl dot tools at gmail dot com 2008-01-20 03:06 ---
Revision 131671 passed the last failure point.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34851
--- Comment #5 from hjl dot tools at gmail dot com 2008-01-20 07:53 ---
Revision 131671 is OK.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
--- Comment #13 from hjl dot tools at gmail dot com 2008-01-20 15:57
---
It happens for me on Linux/Intel64 with -m32:
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00907.html
My configuration is
configure flags: --enable-clocale=gnu --with-system-zlib
--enable-decimal-float=bid
--- Comment #7 from hjl dot tools at gmail dot com 2008-01-20 16:43 ---
Oops. This one
--- regmove.c.freq 2008-01-17 07:31:56.0 -0800
+++ regmove.c 2008-01-20 08:42:42.0 -0800
@@ -1695,7 +1695,7 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
rtx p;
rtx
--- Comment #6 from hjl dot tools at gmail dot com 2008-01-20 16:42 ---
Does this patch make any senses?
--- regmove.c.freq 2008-01-17 07:31:56.0 -0800
+++ regmove.c 2008-01-20 08:40:34.0 -0800
@@ -1695,7 +1695,7 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
rtx
--- Comment #5 from hjl dot tools at gmail dot com 2008-01-20 16:34 ---
Should we also update REG_FREQ_CALLS_CROSSED whenever REG_N_CALLS_CROSSED
is updated? In regmove.c, there are
delete_insn (q);
INC_REG_N_SETS (REGNO (src), -1
--- Comment #8 from hjl dot tools at gmail dot com 2008-01-21 03:09 ---
Add -ffloat-store seems to fix the problem. I will verify it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34852
--- Comment #1 from hjl dot tools at gmail dot com 2008-01-21 04:26 ---
Revision 131678 seems OK:
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00926.html
It looks like revision 131679
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00925.html
is the cause.
--
http
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34896
--- Comment #13 from hjl dot tools at gmail dot com 2008-01-21 15:14
---
I tried -mpc64. It also works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34852
t org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34904
--- Comment #14 from hjl dot tools at gmail dot com 2008-01-21 15:51
---
(In reply to comment #12)
> Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel
>
> and haydn tester using -O3 -funroll-loops -fpeel-loops -ffast-math
> -march=native -
--- Comment #1 from hjl dot tools at gmail dot com 2008-01-21 20:40 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00969.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #16 from hjl dot tools at gmail dot com 2008-01-21 20:53
---
(In reply to comment #15)
> Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel
>
> > I tried -mpc64. It also works.
> I would declare this a proof that it is extra precc
--- Comment #10 from hjl dot tools at gmail dot com 2008-01-21 21:43
---
(In reply to comment #9)
>
> HJ, Richi, I can find a lot of confused versions of HJ's patch in that thread,
> which starts here:
> http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01170.html
--- Comment #12 from hjl dot tools at gmail dot com 2008-01-21 21:57
---
(In reply to comment #11)
> Subject: Re: gas version style changed causes
> warnings with configure
>
> On Mon, Jan 21, 2008 at 09:43:09PM -0000, hjl dot tools at gmail dot com
> wrote:
--- Comment #13 from hjl dot tools at gmail dot com 2008-01-21 23:34
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00974.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32287
--- Comment #3 from hjl dot tools at gmail dot com 2008-01-22 13:36 ---
*** Bug 34847 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34921
--- Comment #1 from hjl dot tools at gmail dot com 2008-01-22 13:36 ---
*** This bug has been marked as a duplicate of 34921 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #16 from hjl dot tools at gmail dot com 2008-01-22 14:14
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #4 from hjl dot tools at gmail dot com 2008-01-22 14:26 ---
(In reply to comment #2)
> I bet if you put jj in struct and don't have a nested function, this will be
> the same issue.
>
struct works for me:
bash-3.2$ cat x.c
#include
#include
#include
#if
--- Comment #6 from hjl dot tools at gmail dot com 2008-01-23 15:47 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01062.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2008-01-24 18:58 ---
Fixed on trunk.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Known to fail
--- Comment #10 from hjl dot tools at gmail dot com 2008-01-24 22:37
---
Revision 131801 is OK.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #13 from hjl dot tools at gmail dot com 2008-01-24 22:37
---
Revision 131801 is OK.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
t: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34984
--- Comment #1 from hjl dot tools at gmail dot com 2008-01-26 18:02 ---
Revision 131827 is OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34984
--- Comment #2 from hjl dot tools at gmail dot com 2008-01-26 18:07 ---
Revision 131849 is OK and revision 131855 is bad. It looks like revision
131855:
http://gcc.gnu.org/ml/gcc-cvs/2008-01/msg00616.html
may be the cause.
--
hjl dot tools at gmail dot com changed
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Known to fail|4.1.0 4.2.0 |4.1.0 4.2.0 4.3.0
Target Milestone|4.1.3
Summary: gfortran.dg/missing_optional_dummy_5.f90 doesn't work
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedB
--- Comment #1 from hjl dot tools at gmail dot com 2008-01-28 00:17 ---
With -m32, we got
doit ()
{
real(kind=4) doit1[2];
{
struct array1_real(kind=4) parm.6;
parm.6.dtype = 281;
parm.6.dim[0].lbound = 1;
parm.6.dim[0].ubound = 2;
parm.6.dim[0].stride = 1
for errors, line 13)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target tri
--- Comment #6 from hjl dot tools at gmail dot com 2008-02-01 18:48 ---
Revision 131984 seems the cause:
http://gcc.gnu.org/ml/gcc-cvs/2008-01/msg00747.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from hjl dot tools at gmail dot com 2008-02-01 18:40 ---
The test works on Linux/Intel64 with -m32:
[EMAIL PROTECTED] g++]$
/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/g++/../../g++
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/g++/../../
/net/gnu
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35084
--- Comment #1 from hjl dot tools at gmail dot com 2008-02-05 05:52 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00114.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2008-02-05 05:53 ---
With the patch, I got
lake:pts/2[10]> ./xgcc -B./ -m32 -mno-sse -S x.i
x.i: In function âtestâ:
x.i:5: error: Calling âessefâ with attribute sseregparm without SSE/SSE2
enabled
--
http://gcc.gnu.
iority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35093
--- Comment #5 from hjl dot tools at gmail dot com 2008-02-05 14:52 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
/vector13.C doesn't work
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
--- Comment #20 from hjl dot tools at gmail dot com 2008-02-07 00:04
---
FYI, stack alignment branch will look like
if (TREE_STATIC (decl))
return (alignment <= MAX_OFILE_ALIGNMENT);
else if (MAX_VECTORIZE_STACK_ALIGNMENT)
{
gcc_assert (!c
ponent: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35116
--- Comment #1 from hjl dot tools at gmail dot com 2008-02-07 05:10 ---
Revision 132088:
http://gcc.gnu.org/ml/gcc-cvs/2008-02/msg00100.html
is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
tsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35126
--- Comment #4 from hjl dot tools at gmail dot com 2008-02-07 15:55 ---
Can we move them into gcc.dg/torture?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2008-02-07 15:53 ---
My point is those dg-options aren't applied to the testcases. We should
either remove them or make sure that they are used.
--
hjl dot tools at gmail dot com changed:
What|Re
3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35127
--- Comment #21 from hjl dot tools at gmail dot com 2008-02-07 22:15
---
The real problem is i386 gcc expects 16 byte stack boundary while the
psABI specifies 4 byte. When you link a callee, which expects incoming
stack at 16 byte boundary, with a caller, which only guarantees 4 byte
--- Comment #1 from hjl dot tools at gmail dot com 2008-02-09 16:23 ---
A patch is posted at
http://sourceware.org/ml/binutils/2008-02/msg00068.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #7 from hjl dot tools at gmail dot com 2008-02-09 16:55 ---
I posted a patch for gcc 4.2 at
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00283.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31868
--- Comment #14 from hjl dot tools at gmail dot com 2008-02-12 23:45
---
(In reply to comment #13)
> > I think it is wrong to set STACK_BOUNDARY to 128 for 32bit since it is
> > hardware related, not ABI related. They should set
> > PREFERRED_STACK_BOUNDARY
>
--- Comment #12 from hjl dot tools at gmail dot com 2008-02-12 18:52
---
(In reply to comment #11)
> (In reply to comment #10)
>
> > I think it is wrong to set STACK_BOUNDARY to 128 for 32bit since it is
> > hardware related, not ABI related. They should set PREFER
--- Comment #16 from hjl dot tools at gmail dot com 2008-02-13 06:41
---
(In reply to comment #15)
> Subject: Re: [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal
> compiler error: in expand_call, at calls.c:2785
>
> STACK_BOUNDARY
> >>
> &g
--- Comment #10 from hjl dot tools at gmail dot com 2008-02-12 15:46
---
(In reply to comment #3)
> Reproducible even with x86_64-linux -> i686-darwin9 cross, at -Os as well as
> -O2 -mno-accumulate-outgoing-args. The difference between i686-linux and
> i686-darwin9 that
--- Comment #18 from hjl dot tools at gmail dot com 2008-02-13 15:39
---
(In reply to comment #17)
>
> It is to be expected that this proposal usually has no effect on
> Darwin, because the problem it is trying to solve, of local variables
> that require alignment grea
gn 64 symtab -1208442048 alias set -1 canonical type 0xb7ca0c98
precision 64 min max
RM size constant invariant 33>>
(gdb)
--
Summary: Ada doesn't follow i386 psABI
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priori
--- Comment #3 from hjl dot tools at gmail dot com 2008-02-13 19:37 ---
Ada should either define its own alignment, independent of psABI, or it
should just follow psABI for alignment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35186
--- Comment #2 from hjl dot tools at gmail dot com 2008-02-13 19:35 ---
maybe_pad_type has
if (align == TYPE_ALIGN (type))
align = 0;
if (align == 0 && !size)
return type;
...
record = make_node (RECORD_TYPE);
That is Ada expects 8 byte alignment for DIm
--- Comment #5 from hjl dot tools at gmail dot com 2008-02-13 21:44 ---
(In reply to comment #4)
> This is confirmed. H.J., are you waiting for something to commit to 4.2 or
> should this be closed?
>
I requested it for 4.2:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg0
rsion: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35189
--- Comment #3 from hjl dot tools at gmail dot com 2008-02-14 00:11 ---
-mno-sse4.1 and -mno-sse4.2 shouldn't turn off SSE4A.
-mno-sse3/-mno-sse2/-mno-sse should turn off SSE4A. But
I am not sure about -mno-ssse3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35189
--- Comment #5 from hjl dot tools at gmail dot com 2008-02-14 01:44 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00483.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35195
--- Comment #1 from hjl dot tools at gmail dot com 2008-02-14 19:52 ---
Created an attachment (id=15152)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15152&action=view)
A testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35200
ation
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35200
--- Comment #4 from hjl dot tools at gmail dot com 2008-02-14 20:16 ---
The first time we saw it is last Nov. But it is very hard to reproduce.
Any changes in input will make the warning to disappear. Here is what
Xuepeng got
The warning are caused by SSA and type-punning:
[EMAIL
--- Comment #6 from hjl dot tools at gmail dot com 2008-02-14 20:54 ---
(In reply to comment #5)
> Can you when you debug the function, please dump the VOPs also since then it
> should become obvious the issue.
>
> Anyways I don't think this an bogus warning and reall
--- Comment #10 from hjl dot tools at gmail dot com 2008-02-14 22:56
---
Binutils is fixed by
http://sourceware.org/ml/binutils/2008-02/msg00152.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35200
--- Comment #6 from hjl dot tools at gmail dot com 2008-02-19 02:29 ---
Won't fix 4.2:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00715.html
--
hjl dot tools at gmail dot com changed:
What|Removed |
D
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35254
: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35262
--- Comment #1 from hjl dot tools at gmail dot com 2008-02-20 15:50 ---
Revision 132439 is bad:
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01322.html
Revision 132433 is OK:
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01318.html
The only change in 4.4 between those 2
--- Comment #6 from hjl dot tools at gmail dot com 2008-02-23 23:12 ---
Weak and hidden aren't really compatible. Linker should enforce it.
I opened a linker bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=5789
As for gcc, I think it is OK since it is a user error and l
--- Comment #7 from hjl dot tools at gmail dot com 2008-02-25 22:16 ---
It is a compiler bug after all. From:
http://groups.google.com/group/generic-abi/browse_thread/thread/4364eb484397ebe0
A hidden symbol must be defined in the same component, *if it is
defined at all*. That last
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org
--- Comment #2 from hjl dot tools at gmail dot com 2008-02-26 19:30 ---
(In reply to comment #1)
> Could you suggest a more robust testcase?
>
> Or if that is not possible, there should be a way to only compile the testcase
> for valid targets. Ideas?
>
You can u
--- Comment #11 from hjl dot tools at gmail dot com 2008-02-29 05:54
---
I don't think it is a linker bug. This bug looks very similar
to PR 34249. Uros, you fixed PR 34249. Maybe there is another
similar problem elsewhere in dwarf2.out.c.
--
http://gcc.gnu.org/bug
g/tree-ssa/ldist-4.c
don't work
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl d
size and alignment for x86
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gn
: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35415
.cc
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla
: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35418
--- Comment #1 from hjl dot tools at gmail dot com 2008-03-01 22:50 ---
The code looks like
SUBROUTINE RESID(U,V,R,N,A)
INTEGER N
REAL*8 U(N,N,N),V(N,N,N),R(N,N,N),A(0:3)
INTEGER I3, I2, I1
DO 600 I3=2,N-1
DO 600 I2=2,N-1
DO 600 I1=2,N-1
N is
--- Comment #4 from hjl dot tools at gmail dot com 2008-03-02 01:11 ---
I got
Running 172.mgrid ref base o2 default
*** Miscompare of mgrid.out, see
/export/gnu/import/rrs/spec/2000/spec/benchspec
/CFP2000/172.mgrid/run/0002/mgrid.out.mis
Invalid run; unable to continue. If you
mmary: Improve -mpcXXX handling
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot co
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35453
--- Comment #3 from hjl dot tools at gmail dot com 2008-03-04 19:24 ---
Fixed for both gcc 4.3/4.4.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
2bit and 64bit hosts
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35466
--- Comment #1 from hjl dot tools at gmail dot com 2008-03-05 04:27 ---
The difference comes from tree_expand_cfg pass:
[EMAIL PROTECTED] stage1-gcc]$ diff -up 32/x.i.132r.expand 64
--- 32/x.i.132r.expand 2008-03-04 20:25:21.0 -0800
+++ 64/x.i.132r.expand 2008-03-04 20:25
--- Comment #8 from hjl dot tools at gmail dot com 2008-03-06 22:03 ---
This is a known issue with mgrid. The absolute tolerance is too
small. After increasing absolute tolerance from 1.0e-12 to
1.0e-11, the miscomparison is gone.
--
hjl dot tools at gmail dot com changed
--- Comment #8 from hjl dot tools at gmail dot com 2008-03-07 04:24 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status
--- Comment #1 from hjl dot tools at gmail dot com 2008-03-07 04:26 ---
There is no problem. TARGET_128BIT_LONG_DOUBLE is enabled in 64bit:
/* By default, 64-bit mode uses 128-bit long double. */
#undef TARGET_SUBTARGET64_DEFAULT
#define TARGET_SUBTARGET64_DEFAULT
901 - 1000 of 3390 matches
Mail list logo
