--- Comment #4 from jv244 at cam dot ac dot uk 2008-12-09 21:04 ---
similar for gamma.F
#0 0x2b69b539a066 in realloc () from /lib64/libc.so.6
#1 0x2b69b44a698c in __gmp_default_reallocate () from
/usr/lib64/libgmp.so.3
#2 0x2b69b44bba21 in __gmpz_realloc () from /usr
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 38431
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38463
--- Comment #6 from jv244 at cam dot ac dot uk 2008-12-09 21:11 ---
ps_wavelet_util.F is now PR38463
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
--- Comment #1 from jv244 at cam dot ac dot uk 2008-12-09 21:12 ---
note that this trace also goes via cloog_clast_create so that might be a dup of
PR38459
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38463
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-09 21:18 ---
Created an attachment (id=16865)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16865action=view)
testcase
reduced.
at least, graphite tends to fail on code that is easy to reduce.
--
http://gcc.gnu.org
--- Comment #6 from jv244 at cam dot ac dot uk 2008-12-09 21:22 ---
same for cp_cfm_basic_linalg.F
#0 0x2ad7ad43d066 in realloc () from /lib64/libc.so.6
#1 0x2ad7ac54998c in __gmp_default_reallocate () from
/usr/lib64/libgmp.so.3
#2 0x2ad7ac55ea21 in __gmpz_realloc
--- Comment #7 from jv244 at cam dot ac dot uk 2008-12-09 21:44 ---
(In reply to comment #5)
I do already know about this bug, this is id-2.f90 problem.
OK, guess it is rather frequent in that case, following files trigger it as
well:
ps_wavelet_kernel.F
ai_moments.F
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38444
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-08 18:39 ---
(In reply to comment #1)
- gfc_error (msg, sym-name, where, gfc_basic_typename
(sym-ts.type));
+ gfc_fatal_error (msg, sym-name, where,
+ gfc_basic_typename (sym-ts.type
--- Comment #4 from jv244 at cam dot ac dot uk 2008-12-08 19:34 ---
|
\ ' /
-- (*) --
*
0
--- Comment #11 from jv244 at cam dot ac dot uk 2008-12-06 18:54 ---
(In reply to comment #10)
If the code layout (see comment #2) is indeed causing the slow-down, this
problem might have been fixed along with bug 38074.
No, timings are still identical:
gcc version 4.4.0 20081206
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
--- Comment #10 from jv244 at cam dot ac dot uk 2008-12-05 16:25 ---
Timings in 4.4 are essentially unchanged
gfortran -O3 -ffast-math -march=native PR25621.f90:
default loop 1.29208100
hand optimized loop 0.864053988
fun enough inverse timings with a recent
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-05 16:26 ---
still fails with 4.4
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Last reconfirmed
--- Comment #9 from jv244 at cam dot ac dot uk 2008-12-05 16:28 ---
updated testcase still fails:
subroutine a(p)
type t
integer :: t1
end type
type(t) :: p
p%t1 = 42
end subroutine
subroutine b
type u
integer :: u1
end type
type (u) :: q
call a(q)
write(6
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-05 16:30 ---
still fails in 4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34663
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38403
--- Comment #1 from jv244 at cam dot ac dot uk 2008-12-04 16:10 ---
Created an attachment (id=16824)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16824action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38403
--- Comment #9 from jv244 at cam dot ac dot uk 2008-12-04 16:11 ---
I tried -fschedule-insns on CP2K, which lead to an ICE (now PR38403)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-04 16:16 ---
Created an attachment (id=16825)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16825action=view)
shorter testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38403
--- Comment #3 from jv244 at cam dot ac dot uk 2008-12-04 16:21 ---
Created an attachment (id=16826)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16826action=view)
99 lines ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38403
--- Comment #5 from jv244 at cam dot ac dot uk 2008-12-04 17:22 ---
(In reply to comment #4)
I would suggest you don't spend too much time on reducing a test case, and
just
stop using -fschedule-insns on x86*. There is a reason why it is not enabled
by default ;-)
somewhat
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38351
--- Comment #4 from jv244 at cam dot ac dot uk 2008-11-30 16:17 ---
(In reply to comment #2)
Due to the high density of branches in the code this is easily a code layout
and/or padding issue. Different architectures have different constraints on
their decoders and branch predictors
--- Comment #5 from jv244 at cam dot ac dot uk 2008-11-30 16:26 ---
(In reply to comment #4)
4.3:
-O3 -march=native -funroll-loops -ffast-math == 4.376
-O3 -march=native -funroll-loops -ffast-math -fschedule-insns == 3.372
strangely:
http://gcc.gnu.org/onlinedocs
of temps out of loops.
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO
: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38303
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38303
org
ReportedBy: jv244 at cam dot ac dot uk
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
--- Comment #1 from jv244 at cam dot ac dot uk 2008-11-28 16:01 ---
Created an attachment (id=16788)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16788action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312
--- Comment #4 from jv244 at cam dot ac dot uk 2008-11-20 08:53 ---
so I guess this is up to the front end to generate 'better' code for size
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #7 from jv244 at cam dot ac dot uk 2008-11-20 11:03 ---
(In reply to comment #6)
great.. thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38181
--- Comment #4 from jv244 at cam dot ac dot uk 2008-11-20 18:54 ---
(In reply to comment #3)
duplicate of pr36935?
similar enough to make this one depend on PR36935. I think the testcases here
(certainly comment #1), are more difficult.
--
jv244 at cam dot ac dot uk changed
--- Comment #2 from jv244 at cam dot ac dot uk 2008-11-19 13:08 ---
(In reply to comment #1)
SUBROUTINE S(b,i,j)
INTEGER, DIMENSION(:) :: b
integer res(1)
INTEGER :: i,j
res = MINLOC(b(i:j))
END SUBROUTINE S
right.. the 'orginal' testcase was. Actually, these temps are all
--- Comment #2 from jv244 at cam dot ac dot uk 2008-11-19 13:18 ---
(In reply to comment #1)
Do you know of any compilers that catch this? As you say, it is not so easy
to
fix.
I believe ifort gets this right (compiled with 'ifort -S -heap-arrays 64), but
this is just looking
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38181
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from jv244 at cam dot ac dot uk 2008-11-14 08:34 ---
This could be somewhat similar, I really wonder if this needs a temp:
TYPE T1
INTEGER :: a(3)
END TYPE T1
TYPE(T1), POINTER :: x,y
ALLOCATE(x,y)
x%a=y%a
END
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36933
: missed-optimization
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 36854
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38111
: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 36854
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38112
--- Comment #1 from jv244 at cam dot ac dot uk 2008-11-14 08:50 ---
that might be an even simpler case:
SUBROUTINE S(a,i,j)
INTEGER, POINTER, DIMENSION(:) :: a
INTEGER, DIMENSION(:), ALLOCATABLE :: b
INTEGER :: i,j
ALLOCATE(b(10))
b(i:j)=a(i:j)
END SUBROUTINE S
--
http
: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38113
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 36854
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38114
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 36854
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38115
--- Comment #1 from jv244 at cam dot ac dot uk 2008-11-14 09:07 ---
I guess this one is similar enough to put here as well:
SUBROUTINE S1(a,i,j,k,m)
INTEGER :: a(3,6)
write(6,*) ALL(a(1:3,m).EQ.(/i,j,k/))
END
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38115
--- Comment #6 from jv244 at cam dot ac dot uk 2008-11-11 13:28 ---
reduced:
MODULE M1
IMPLICIT NONE
PRIVATE
TYPE T1
INTEGER :: I1
END TYPE T1
PUBLIC :: S1
CONTAINS
SUBROUTINE S1
CONTAINS
TYPE(T1) FUNCTION F1()
END FUNCTION F1
END SUBROUTINE S1
END MODULE M1
--- Comment #3 from jv244 at cam dot ac dot uk 2008-11-11 16:08 ---
just a note on the patch posted:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00407.html
the fortran standard guarantees that
E==TRANSFER(TRANSFER(E,D),E)
if the physical representation of D and E is the same length
--- Comment #8 from jv244 at cam dot ac dot uk 2008-11-11 14:14 ---
(In reply to comment #7)
As best I can see, your reduction of the problem is not correct; in it
subroutine S1 should be private, not public.
I don't think so. See your code, S1 ~ GeomMTF, which is public
--- Comment #8 from jv244 at cam dot ac dot uk 2008-11-11 06:00 ---
(In reply to comment #7)
Actually we can fold C - a == a only for odd C.
But more generally a +- b == a to b == 0.
right... that works as well for this optimization.
The original argument was on the range
--- Comment #3 from jv244 at cam dot ac dot uk 2008-11-09 17:22 ---
(In reply to comment #2)
Created an attachment (id=16640)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16640action=view) [edit]
the shell script seems to have a few lines referring to your home, but it looks
--- Comment #1 from jv244 at cam dot ac dot uk 2008-09-12 17:56 ---
the program is non-standard Fortran, but it is legacy, so an option would be
useful.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37486
--- Comment #7 from jv244 at cam dot ac dot uk 2008-09-12 18:02 ---
(In reply to comment #5)
It seems that declaring 'fonc' makes it external to the module, while without
any declaration, 'fonc' is found to be the internal procedure defined within
the module.
which is the correct
--- Comment #4 from jv244 at cam dot ac dot uk 2008-09-12 18:48 ---
(In reply to comment #2)
(In reply to comment #1)
the program is non-standard Fortran, but it is legacy, so an option would be
useful.
Why is it nonstandard?
Maybe not, I was guessing based on 16.5.6
--- Comment #2 from jv244 at cam dot ac dot uk 2008-09-12 18:50 ---
(In reply to comment #1)
I've not checked, but maybe this is related to PR 37199?
I can not reproduce that with the 4.3 branch:
gcc version 4.3.3 20080912 (prerelease) (GCC)
[EMAIL PROTECTED]:/data03/vondele/bug
--- Comment #6 from jv244 at cam dot ac dot uk 2008-09-10 06:38 ---
(In reply to comment #5)
Two or more accessible entities, other than generic interfaces or defined
operators, may have the same identifier only if the identifier is not used to
refer to an entity in the scoping unit
--- Comment #7 from jv244 at cam dot ac dot uk 2008-09-10 06:48 ---
(In reply to comment #6):
actually, I rather sure that gfortran gets it wrong. This would be a wrong-code
MODULE M1
CONTAINS
SUBROUTINE S1
write(6,*) M1 OK
CALL ABORT()
END SUBROUTINE
END MODULE
MODULE M2
USE
--- Comment #3 from jv244 at cam dot ac dot uk 2008-09-09 18:06 ---
reduced:
MODULE M1
INTERFACE putaline
MODULE PROCEDURE S1,S2
END INTERFACE
CONTAINS
SUBROUTINE S1(I)
END SUBROUTINE
SUBROUTINE S2(F)
END SUBROUTINE
END MODULE
MODULE M2
USE M1
CONTAINS
SUBROUTINE S3
CALL
--- Comment #9 from jv244 at cam dot ac dot uk 2008-09-06 09:09 ---
I believe this bug should be closed ? Or do you still want to add the testcase
to mainline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37251
: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 29975
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37300
--- Comment #1 from jv244 at cam dot ac dot uk 2008-08-31 17:11 ---
Created an attachment (id=16175)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16175action=view)
testcase
to reproduce:
gfortran -g -ffree-form f77_blas_extra.F f77_blas_generic.F f77_blas_poison.F
f77_blas.F
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Known to fail||4.4.0
Summary|-g causes internal compiler |[4.4 Regression
--- Comment #6 from jv244 at cam dot ac dot uk 2008-08-28 08:15 ---
(In reply to comment #5)
The patch solving the problem will be sent soon.
The patch you posted fixes the build of CP2K. Benchmark results will appear:
http://cp2k.berlios.de/gfortran/
the night after it hits
--- Comment #5 from jv244 at cam dot ac dot uk 2008-08-28 15:40 ---
current trunk still doesn't remove the if statement, despite the fact that it
could.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #14 from jv244 at cam dot ac dot uk 2008-08-28 15:55 ---
It looks like 4.4 performs even worse than 4.3 on the attached testcase.
gfortran -ffast-math -march=native -O3 PR17088.f90
trunk: 0.528032997
4.3.0: 0.492029997
ifort -xhost -O2 PR17088.f90
ifort
--- Comment #15 from jv244 at cam dot ac dot uk 2008-08-28 15:56 ---
Created an attachment (id=16158)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16158action=view)
ifort asm
ifort asm as a reference
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17088
--- Comment #16 from jv244 at cam dot ac dot uk 2008-08-28 16:08 ---
actually, I've been misreading the numbers... the timings for the library
function (MATMUL) is bad, not the generated code, which is reasonable also
with gfortran. I'll close the bug.
--
jv244 at cam dot ac dot
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 29975
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37251
--- Comment #1 from jv244 at cam dot ac dot uk 2008-08-27 06:26 ---
Created an attachment (id=16153)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16153action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37251
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37251
--- Comment #2 from jv244 at cam dot ac dot uk 2008-08-27 07:45 ---
Created an attachment (id=16154)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16154action=view)
shorter Fortran only testcase
gfortran -v -c -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native
--- Comment #3 from jv244 at cam dot ac dot uk 2008-08-27 07:53 ---
This is the minimal command line to reproduce the bug:
gfortran -c -O1 -ffast-math -march=core2 bug_PR37251.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37251
--- Comment #6 from jv244 at cam dot ac dot uk 2008-08-25 06:10 ---
today's trunk gets this right.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 29975
nThis:
http
--- Comment #1 from jv244 at cam dot ac dot uk 2008-08-24 18:05 ---
Created an attachment (id=16137)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16137action=view)
testcase
untar and compile with
gfortran -c -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native
-ffree
--- Comment #3 from jv244 at cam dot ac dot uk 2008-08-24 19:13 ---
(In reply to comment #2)
(In reply to comment #1)
Created an attachment (id=16137)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16137action=view) [edit]
testcase
untar and compile with
gfortran -c
--- Comment #4 from jv244 at cam dot ac dot uk 2008-08-24 20:00 ---
Created an attachment (id=16138)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16138action=view)
Fortran only testcase
compile as:
gfortran -c -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native
-ffree
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
OtherBugsDependingO 29975
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37174
--- Comment #1 from jv244 at cam dot ac dot uk 2008-08-20 07:36 ---
Created an attachment (id=16105)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16105action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37174
--- Comment #5 from jv244 at cam dot ac dot uk 2008-08-20 12:34 ---
(In reply to comment #4)
I am testing the following patch:
I checked that it fixed the problem with the original bug (PR37174.tgz)
Thanks!
Index: tree-vect-analyze.c
--- Comment #11 from jv244 at cam dot ac dot uk 2008-08-19 06:09 ---
Created an attachment (id=16095)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16095action=view)
new testcase
This (PR31079_11.f90) should be a replacement for comment #4, and illustrates
the vectorizer issue
--- Comment #12 from jv244 at cam dot ac dot uk 2008-08-19 06:11 ---
Created an attachment (id=16096)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16096action=view)
ifort's asm for PR31079_11.f90 at -O3 -xT -S
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31079
--- Comment #4 from jv244 at cam dot ac dot uk 2008-08-19 10:53 ---
(In reply to comment #2)
Note that the first complete unrolling pass unrolls loops that result in
smaller code. This interferes with vectorization in your case, so can
you try
unfortunately, the patch below
--- Comment #5 from jv244 at cam dot ac dot uk 2008-08-19 11:36 ---
Created an attachment (id=16098)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16098action=view)
ifort asm
added the ifort asm. The remaining difference seems to be related to how data
is being loaded
--- Comment #13 from jv244 at cam dot ac dot uk 2008-08-19 13:31 ---
(In reply to comment #11)
This (PR31079_11.f90) should be a replacement for comment #4, and illustrates
the vectorizer issue.
The patch Richard posted in PR37150 also improves this PR31079_11.f90 testcase
a lot
--- Comment #6 from jv244 at cam dot ac dot uk 2008-08-19 13:50 ---
Created an attachment (id=16099)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16099action=view)
non-reduced testcase
unfortunately, on the non-reduced testcase (attached as collocate_fast_2.f90)
the vectorization
: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37150
--- Comment #1 from jv244 at cam dot ac dot uk 2008-08-18 15:33 ---
Created an attachment (id=16082)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16082action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37150
--- Comment #8 from jv244 at cam dot ac dot uk 2008-08-19 05:43 ---
(In reply to comment #7)
That is, GCCs inner loop is
.L6:
addl$1, %eax
addsd %xmm12, %xmm11
cmpl$1, %eax
addsd %xmm14, %xmm3
addsd %xmm15, %xmm2
--- Comment #9 from jv244 at cam dot ac dot uk 2008-08-19 05:44 ---
Created an attachment (id=16093)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16093action=view)
comment #0 source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31079
--- Comment #10 from jv244 at cam dot ac dot uk 2008-08-19 05:45 ---
Created an attachment (id=16094)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16094action=view)
comment #0 intel's assembly (ifort 9.1 at -O2 -xT)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31079
--- Comment #4 from jv244 at cam dot ac dot uk 2008-08-13 06:47 ---
(In reply to comment #3)
Created an attachment (id=16062)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16062action=view) [edit]
Patch that may fix the bug
Thanks for the report. Wow, I was a bit surprised
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http
--- Comment #1 from jv244 at cam dot ac dot uk 2008-08-12 19:04 ---
some vta testing on CP2K as requested in
http://gcc.gnu.org/ml/gcc/2008-08/msg00160.html
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #2 from jv244 at cam dot ac dot uk 2008-08-12 19:25 ---
already happens at -O1:
gfortran -c -g -O1 all_cp2k_gfortran.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37098
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis
--- Comment #22 from jv244 at cam dot ac dot uk 2008-08-11 07:34 ---
as per comment #20 and comment #21
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #6 from jv244 at cam dot ac dot uk 2008-08-08 20:34 ---
(In reply to comment #5)
(In reply to comment #4)
If you look, the patch preceeded the PR. Toon posted the problem on the list,
promising to develop this testcase. This he duly did. Please keep it open
another
501 - 600 of 1178 matches
Mail list logo
