[Bug middle-end/38074] [4.4 Regression] missed inlining since IRA merge on Core2 Duo
--- Comment #2 from dominiq at lps dot ens dot fr 2008-11-11 20:37 --- Subject: Re: [4.4 Regression] missed inlining since IRA merge on Core2 Duo > I don't see how there can be a connection to the IRA merge. I don't see either, but the behavior changed between Aug 23 and Sep 2. At this time the IRA merge was the major shaking and I did not see what else can have caused that. The merge may have exposed a latent bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38074
[Bug fortran/38094] [4.4 regression] gfortran.dg/private_type_4.f90 -O doesn't work
--- Comment #2 from dominiq at lps dot ens dot fr 2008-11-12 16:12 ---
With the patch for pr38065, compiling gfortran.dg/private_type_4.f90 without
-std=f95 does not return the expected error:
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/private_type_4.f90:14.24:
type(t1) function f1() ! { dg-error "cannot be of PRIVATE type" }
1
Error: PUBLIC function 'f1' at (1) cannot be of PRIVATE type 't1'
So if the code is f2003 compliant the fix is obvious: just add the -std=f95 as
a dg option.
In this case I have a question: if 'f1' is public, how is it supposed to be
used in the program?
There is also a glitch: with -std=f95 the error
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/private_type_4.f90:14.24:
type(t1) function f1() ! { dg-error "cannot be of PRIVATE type" }
1
Error: Fortran 2003: PUBLIC variable 'f1' at (1) of PRIVATE derived type 't1'
is emitted twice and with gfortran 4.3.2 I get
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/private_type_4.f90:14.24:
type(t1) function f1() ! { dg-error "cannot be of PRIVATE type" }
1
Error: Fortran 2003: PUBLIC variable 'f1' at (1) of PRIVATE derived type 't1'
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/private_type_4.f90:14.24:
type(t1) function f1() ! { dg-error "cannot be of PRIVATE type" }
1
Error: Fortran 2003: PUBLIC variable 'f1' at (1) of PRIVATE derived type 't1'
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/private_type_4.f90:14.24:
type(t1) function f1() ! { dg-error "cannot be of PRIVATE type" }
1
Error: PUBLIC function 'f1' at (1) cannot be of PRIVATE type 't1'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38094
[Bug fortran/38094] [4.4 regression] gfortran.dg/private_type_4.f90 -O doesn't work
--- Comment #5 from dominiq at lps dot ens dot fr 2008-11-12 21:02 --- The test is still failing, now with two failures. One is due to the mismatch between the expected error: "cannot be of PRIVATE type" and the actual one "Fortran 2003: PUBLIC variable 'f1' at (1) of PRIVATE derived type 't1'". I think the second is due to the error being emitted twice, as noted in comment #2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38094
[Bug fortran/38095] character ICE
--- Comment #4 from dominiq at lps dot ens dot fr 2008-11-12 21:09 --- > Whoop, it is valid Fortran 2003. I forgot that > Lahey's checker does not understand the F2003 array syntax. I was about to say that the code is compiled by ifort and g95. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38095
[Bug fortran/38094] [4.4 regression] gfortran.dg/private_type_4.f90 -O doesn't work
--- Comment #9 from dominiq at lps dot ens dot fr 2008-11-12 21:31 --- > Revision 141798 gave: see comment #5. I have forgotten to give the revision: it was r141798. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38094
[Bug fortran/38095] character ICE
--- Comment #6 from dominiq at lps dot ens dot fr 2008-11-12 22:26 --- > I hope someone will mark the bug as "confirmed". I have tried, but If I am allowed to do it, I did not find how. Did you try yourself? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38095
[Bug testsuite/37517] gcc.target/i386/quad-sse.c fails with -fPIC
--- Comment #3 from dominiq at lps dot ens dot fr 2008-11-13 15:11 --- > Also note this fails by default for i686-darwin. The test succeeds with -m64 with and without -fno-PIC. The lines call___i686.get_pc_thunk.cx call___i686.get_pc_thunk.cx call___i686.get_pc_thunk.cx are emitted only in 32 bit mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37517
[Bug target/29090] gcc.dg-struct-layout-1 failures on Darwin PPC at -m64
--- Comment #10 from dominiq at lps dot ens dot fr 2008-11-13 22:28 --- At revision 141798 I have similar failures: FAIL: tmpdir-g++.dg-struct-layout-1/t003 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t006 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t007 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t008 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t010 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t011 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t020 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t027 cp_compat_x_tst.o-cp_compat_y_tst.o execute and FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t016 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t024 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o execute see also pr38099 for two similar failures on i686-apple-darwin9 (one with -m32 and the other with -m64). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29090
[Bug c++/37105] stackalign failures
--- Comment #1 from dominiq at lps dot ens dot fr 2008-11-18 09:26 --- This is probably a duplicate of pr37012. Still here at revision 141951. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37105
[Bug tree-optimization/38051] [4.4 Regression] Miscompilation of glibc's memcmp
--- Comment #11 from dominiq at lps dot ens dot fr 2008-11-18 13:38 --- The test fails on powerpc-apple-darwin9 (revision 141945, 32 and 64 bit modes): FAIL: gcc.c-torture/execute/pr38051.c execution, -O0 FAIL: gcc.c-torture/execute/pr38051.c execution, -O1 FAIL: gcc.c-torture/execute/pr38051.c execution, -O2 FAIL: gcc.c-torture/execute/pr38051.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/pr38051.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/pr38051.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/pr38051.c execution, -O3 -g FAIL: gcc.c-torture/execute/pr38051.c execution, -Os -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38051
[Bug fortran/38152] ICE for procedure pointer assignment
--- Comment #4 from dominiq at lps dot ens dot fr 2008-11-18 19:54 --- With the patches in comment #2 and #3, compiling the test in comment #0 on i686-apple-darwin9 in 32 bit mode gives: /var/tmp//ccMx60VC.s:13:non-relocatable subtraction expression, "_procptr" minus "L001$pb" /var/tmp//ccMx60VC.s:13:symbol: "_procptr" can't be undefined in a subtraction expression Note that g95 compiles the test while ifort 11 returns: pr38152.f90(4): error #8169: The specified interface is not declared. [TEST] PROCEDURE(test), POINTER :: procptr ^ pr38152.f90(11): error #6437: A subroutine or function is calling itself recursively. [TEST] CALL bar (test) --^ pr38152.f90(12): error #8191: The procedure target must be a procedure or a procedure pointer. [TEST] procptr => test ---^ compilation aborted for pr38152.f90 (code 1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug fortran/38171] [regression] equivalence and nested modules broken
--- Comment #6 from dominiq at lps dot ens dot fr 2008-11-19 12:40 --- I don't know if the code in comment #0 is valid or not, but if the file h5global.mod does not exist compiling it with gfortran r141995 gives: pr38171.f90:2.14: USE H5GLOBAL 1 Fatal Error: Can't open module file 'h5global.mod' for reading at (1): No such file or directory This error disappears if the module order is changed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38171
[Bug fortran/38152] ICE for procedure pointer assignment
--- Comment #5 from dominiq at lps dot ens dot fr 2008-11-19 16:29 --- On powerpc-apple-darwin9 I have the same kind of error as reported in comment #4: /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cctJDhJw.s:21:non-relocatable subtraction expression, "_procptr" minus "L001$pb" /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cctJDhJw.s:21:symbol: "_procptr" can't be undefined in a subtraction expression /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cctJDhJw.s:19:non-relocatable subtraction expression, "_procptr" minus "L001$pb" /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cctJDhJw.s:19:symbol: "_procptr" can't be undefined in a subtraction expression in this case for 32 and 64 bit modes. The errors disappear if I compile with -fno-PIC (ppc/intel). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug fortran/38181] calls to SIZE not optimized out of loops
--- Comment #2 from dominiq at lps dot ens dot fr 2008-11-19 21:38 --- It seems that the problem is a missed vectorization. For INTEGER FUNCTION F1(a) integer :: a(:,:), m, n m=SIZE(a,1) n=SIZE(a,2) F1=0 DO k=1,n DO j=1,m F1=F1+a(j,k) ENDDO ENDDO END FUNCTION F1 I get with gfortran pr38181_2.f90:6: note: not vectorized: too many BBs in loop. pr38181_2.f90:7: note: not vectorized: data ref analysis failed D.1605_54 = (*a.0_10)[D.1604_53]; pr38181_2.f90:1: note: vectorized 0 loops in function. while ifort reports: pr38181_2.f90(9): (col. 3) remark: LOOP WAS VECTORIZED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38181
[Bug fortran/27766] [meta] -fbounds-check related bugs
--- Comment #6 from dominiq at lps dot ens dot fr 2008-11-23 00:32 ---
(1) It seems that the failure of gfortran.dg/array_memset_2.f90 comes from a
too broad regexp for scan-tree-dump-times: grep memset
array_memset_2.f90.003t.original gives
_gfortran_runtime_error_at (&"At line 8 of file
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/array_memset_2.f90"[1]{lb: 1 sz:
1}, &"Array reference out of bounds, upper bound of dimension 2 of array \'a\'
exceeded (%ld > %ld)"[1]{lb: 1 sz: 1}, 1, () ubound.2);
_gfortran_runtime_error_at (&"At line 8 of file
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/array_memset_2.f90"[1]{lb: 1 sz:
1}, &"Array reference out of bounds, upper bound of dimension 2 of array \'a\'
exceeded (%ld > %ld)"[1]{lb: 1 sz: 1}, () NON_LVALUE_EXPR
, () ubound.2);
_gfortran_runtime_error_at (&"At line 8 of file
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/array_memset_2.f90"[1]{lb: 1 sz:
1}, &"Array reference out of bounds for array \'a\', upper bound of dimension 1
exceeded (%ld > %ld)"[1]{lb: 1 sz: 1}, 1, () ubound.0);
(void) __builtin_memset ((void *) &b, 0, 8);
(void) __builtin_memset ((void *) &c, 0, 8);
Either the regexp or the name of the test should be changed.
(2) The failure of gfortran.dg/bound_2.f90 comes from " Incorrect size in
SOURCE argument to RESHAPE intrinsic: is 9, should be 4". This is wrong, the
standard says:
"If PAD is absent or of size zero, the size of SOURCE shall be greater than or
equal to PRODUCT (SHAPE)."
(3) I think the failure of gfortran.dg/forall_13.f90: "Array reference out of
bounds for array 'p', upper bound of dimension 1 exceeded (4 > 3)", is also
wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
[Bug libstdc++/38210] num_put<>::do_put(void*) performs padding incorrectly when adjustfield==internal
--- Comment #4 from dominiq at lps dot ens dot fr 2008-11-23 11:12 --- On *-apple-darwin9, the following tests are now failing: FAIL: 22_locale/num_put/put/char/38210.cc execution test FAIL: 22_locale/num_put/put/wchar_t/38210.cc execution test -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||paolo dot carlini at oracle ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38210
[Bug testsuite/38235] gfortran.dg/pr37243.f has undefined variables / bounds error
--- Comment #1 from dominiq at lps dot ens dot fr 2008-11-23 10:08 --- The variable II in "CALL DAXPY(N,DUM,V(1,II),1,V(1,I),1)" is not initialized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38235
[Bug libstdc++/38210] num_put<>::do_put(void*) performs padding incorrectly when adjustfield==internal
--- Comment #5 from dominiq at lps dot ens dot fr 2008-11-23 12:02 --- Apparently the failures I have reported in comment #4 disappear if I rebuild libstdc++. Sorry for the noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38210
[Bug fortran/27766] [meta] -fbounds-check related bugs
--- Comment #8 from dominiq at lps dot ens dot fr 2008-11-23 20:52 --- For gfortran.dg/g77/dnrm2.f the failure comes from the old style array declaration: double precision dx(1), cutlo, cuthi, hitest, sum, xmax,zero,one If 'dx(1)' is replaced by 'dx(*)', -fbounds-check does not detect any error (which may be wrong, but I don't think there is any way to detect the problem with a local analysis). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
[Bug fortran/27766] [meta] -fbounds-check related bugs
--- Comment #9 from dominiq at lps dot ens dot fr 2008-11-23 21:02 --- In addition to comment #8, the bound check would be possible using: double precision dx(n), cutlo, cuthi, hitest, sum, xmax,zero,one -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
[Bug fortran/27766] [meta] -fbounds-check related bugs
--- Comment #10 from dominiq at lps dot ens dot fr 2008-11-23 22:39 --- With the following changes: Only in ../_gcc_clean/gcc/testsuite/gfortran.dg/: array_memset_2.f90 Only in gcc/testsuite/gfortran.dg/: array_setmem_2.f90 --- ../_gcc_clean/gcc/testsuite/gfortran.dg/pr37243.f 2008-09-04 19:10:20.0 +0200 +++ gcc/testsuite/gfortran.dg/pr37243.f 2008-11-23 22:54:23.0 +0100 @@ -34,7 +34,7 @@ IF (J .GT. N) GO TO 320 DO 240 K = 1,N 240 V(K,I) = ZERO - CALL DAXPY(N,DUM,V(1,II),1,V(1,I),1) + CALL DAXPY(N,DUM,V(1,I),1,V(1,I),1) 260 CONTINUE DUMI = ZERO DO 280 K = 1,N --- ../_gcc_clean/gcc/testsuite/gfortran.dg/g77/dnrm2.f 2007-11-07 10:25:55.0 +0100 +++ gcc/testsuite/gfortran.dg/g77/dnrm2.f 2008-11-23 22:53:37.0 +0100 @@ -26,7 +26,7 @@ double precision function dnrm2 ( n, dx, incx) integer i, incx, ix, j, n, next - double precision dx(1), cutlo, cuthi, hitest, sum, xmax,zero,one + double precision dx(n), cutlo, cuthi, hitest, sum, xmax,zero,one data zero, one /0.0d0, 1.0d0/ data cutlo, cuthi / 8.232d-11, 1.304d19 / j = 0 I only get the following failures with -fbounds-check: FAIL: gfortran.dg/forall_13.f90 -O0 execution test FAIL: gfortran.dg/forall_13.f90 -O1 execution test FAIL: gfortran.dg/forall_13.f90 -O2 execution test FAIL: gfortran.dg/forall_13.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/forall_13.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/forall_13.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/forall_13.f90 -O3 -g execution test FAIL: gfortran.dg/forall_13.f90 -Os execution test FAIL: gfortran.dg/ldist-1.f90 -O scan-tree-dump-times ldist "distributed: split to 4 loops" 1 FAIL: gfortran.dg/ltrans-7.f90 -O scan-tree-dump-times ltrans "transformed loop" 1 FAIL: gfortran.dg/reassoc_4.f -O scan-tree-dump-times reassoc1 "[0-9] \* " 22 FAIL: gfortran.dg/vect/vect-3.f90 -O scan-tree-dump-times vect "Alignment of access forced using peeling" 1 FAIL: gfortran.dg/vect/vect-3.f90 -O scan-tree-dump-times vect "Vectorizing an unaligned access" 1 FAIL: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times vect "Alignment of access forced using peeling" 1 FAIL: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times vect "Vectorizing an unaligned access" 1 FAIL: gfortran.dg/vect/pr19049.f90 -O scan-tree-dump-times vect "complicated access pattern" 1 So, but for pr36091, the failures are expected regexps changed by -fbounds-check which is not too surprising. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin
--- Comment #18 from dominiq at lps dot ens dot fr 2008-11-26 15:34 --- This pr has been fixed by revision 130998. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34025
[Bug target/30518] error from system header file
--- Comment #12 from dominiq at lps dot ens dot fr 2008-11-26 15:39 --- Fixed on Darwin 8 and 9. Closing. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30518
[Bug c++/37105] stackalign failures
--- Comment #3 from dominiq at lps dot ens dot fr 2008-11-27 15:31 --- *** This bug has been marked as a duplicate of 37012 *** -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37105
[Bug c++/37012] numerous stackalign related testsuite failures on i686-apple-darwin9
--- Comment #52 from dominiq at lps dot ens dot fr 2008-11-27 15:31 --- *** Bug 37105 has been marked as a duplicate of this bug. *** -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37012
[Bug c++/38076] FAIL: g++.dg/other/anon5.C
--- Comment #3 from dominiq at lps dot ens dot fr 2008-11-27 15:33 --- Fixed by revision 142163. Closing. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38076
[Bug fortran/38312] poor error message
--- Comment #1 from dominiq at lps dot ens dot fr 2008-11-28 21:11 --- Boy! I had o use ifort to see it! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312
[Bug middle-end/38347] New: [4.4 Regression] gfortran.dg/alloc_comp_constructor_1.f90 ICE with -O2 -fdefault-integer-8
rt_tree = 0xafafafaf,
rt_bb = 0xafafafaf,
rt_mem = 0xafafafaf,
rt_reg = 0xafafafaf,
rt_constant = 0xafafafaf
}},
block = 0x1b,
offset = 2
},
rv = {
cl = 0,
decimal = 0,
sign = 0,
signalling = 0,
canonical = 0,
uexp = 0,
sig = {1, 2947526575, 1769472, 0, 2}
},
fv = {
data = {
low = 1,
high = -5787213829991890944
},
mode = 0
}
}
}
--
Summary: [4.4 Regression]
gfortran.dg/alloc_comp_constructor_1.f90 ICE with -O2 -
fdefault-integer-8
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc-apple-darwin9
GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38347
[Bug fortran/38324] Wrong lbound given to allocatable components
--- Comment #1 from dominiq at lps dot ens dot fr 2008-12-01 13:54 --- AFAICT this pr is the cause of half of the failures of gfortran.dg/alloc_comp_constructor_1.f90 on i686-apple-darwin9 with -fdefault-integer-8: FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O0 execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O0 scan-tree-dump-times original "builtin_free" 21 FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O1 execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O1 scan-tree-dump-times original "builtin_free" 21 FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O2 execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O2 scan-tree-dump-times original "builtin_free" 21 FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer scan-tree-dump-times original "builtin_free" 21 FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-loops scan-tree-dump-times original "builtin_free" 21 FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions scan-tree-dump-times original "builtin_free" 21 FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -g execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -O3 -g scan-tree-dump-times original "builtin_free" 21 FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -Os execution test FAIL: gfortran.dg/alloc_comp_constructor_1.f90 -Os scan-tree-dump-times original "builtin_free" 21 The second half is due to 24 "builtin_free" in the "original" dump. This is the cause of some failures of this test on powerpc-apple-darwin9 (-O0/1, I have filled pr38347 against the middle-end for the ICE got with higher optimizations). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38324
[Bug fortran/35937] Wrong type for charlength of function
--- Comment #11 from dominiq at lps dot ens dot fr 2008-12-02 20:03 --- On powerpc-apple-darwin9, the test in comment #4 returns 0 with -m32 (no bus error) instead of 1 with -m64. I have applied the proposed patches in comment #4 and #5 (one at a time!-), but they don't fix the wrong code (note also that gfortran with patch #4 pass the test suite without regression). > Since I cannot reproduce the bug, even at -m32, I am unassigning myself. Did you get the expected result also? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
[Bug fortran/38382] Open(Unit=6 fails
--- Comment #2 from dominiq at lps dot ens dot fr 2008-12-03 17:03 --- Is not this pr a duplicate of an older one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38382
[Bug tree-optimization/37853] [4.4 Regression] gcc.dg/vect/vect-67.c failing since PRE rewrite
--- Comment #2 from dominiq at lps dot ens dot fr 2008-12-06 23:56 --- The output of -ftree-vectorizer-verbose=6 gives: /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:30: note: not vectorized: too many BBs in loop. /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][8] and ia[i_91][1][9] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][8] and ia[i_91][1][10] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][8] and ia[i_91][1][11] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][8] and ia[i_91][1][12] ... /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][20] and ia[i_91][1][21] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][20] and ia[i_91][1][22] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][20] and ia[i_91][1][23] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][21] and ia[i_91][1][22] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][21] and ia[i_91][1][23] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: Detected interleaving ia[i_91][1][22] and ia[i_91][1][23] /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:17: note: not vectorized: complicated access pattern. /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/vect-67.c:9: note: vectorized 0 loops in function. The failure appeared between revisions 137614 (passed) and 137631, most of them are branches or FE patches but 137620 (IPA->unlikely?) and 137631. Compiling with -fno-tree-pre does not help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37853
[Bug tree-optimization/37853] [4.4 Regression] gcc.dg/vect/vect-67.c failing since PRE rewrite
--- Comment #3 from dominiq at lps dot ens dot fr 2008-12-07 00:11 --- Fails also on x86_64-unknown-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00519.html ia64-unknown-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00518.html, powerpc64-suse-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00517.html, i686-pc-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00515.html powerpc-unknown-eabisim: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00503.html ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37853
[Bug tree-optimization/37853] [4.4 Regression] gcc.dg/vect/vect-67.c failing since PRE rewrite
--- Comment #4 from dominiq at lps dot ens dot fr 2008-12-07 00:17 --- The failure appeared at revision 137631 (not in r137630, see http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg01011.html). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37853
[Bug tree-optimization/36792] [4.4 Regression] Revision 137631 causes many failures
--- Comment #10 from dominiq at lps dot ens dot fr 2008-12-07 10:35 --- > Those 3 still aren't fixed: > > FAIL: gcc.dg/vect/vect-67.c scan-tree-dump-times vect "vectorized 1 loops" 1 see pr37853#2 for the output of -ftree-vectorizer-verbose=6. > FAIL: gcc.dg/vect/no-scevccp-outer-13.c scan-tree-dump-times vect "OUTER LOOP > VECTORIZED." 1 > FAIL: gcc.dg/vect/no-scevccp-outer-7.c scan-tree-dump-times vect "OUTER LOOP > VECTORIZED." 1 For these two failures the output of -ftree-vectorizer-verbose=6 are similar. no-scevccp-outer-7.c gives: /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:19: note: vect_model_store_cost: inside_cost = 1, outside_cost = 1 . /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:19: note: vect_model_load_cost: aligned. /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:19: note: vect_model_load_cost: inside_cost = 1, outside_cost = 0 . /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:19: note: vect_model_load_cost: aligned. /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:19: note: vect_model_load_cost: inside_cost = 1, outside_cost = 0 . /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:19: note: vect_model_simple_cost: inside_cost = 2, outside_cost = 0 . /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:19: note: vect_model_simple_cost: inside_cost = 2, outside_cost = 1 . /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:19: note: not vectorized: relevant stmt not supported: D.2045_21 = D.2043_18 >> D.2044_20; /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:13: note: vectorized 0 loops in function. /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:31: note: vectorized 0 loops in function. /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:63: note: not vectorized: too many BBs in loop. /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:53: note: vect_model_induction_cost: inside_cost = 2, outside_cost = 2 . /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:53: note: vect_model_simple_cost: inside_cost = 1, outside_cost = 0 . /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:53: note: vect_model_simple_cost: inside_cost = 1, outside_cost = 1 . /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:53: note: vect_model_store_cost: inside_cost = 1, outside_cost = 0 . /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:53: note: vect_model_simple_cost: inside_cost = 1, outside_cost = 0 . /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:53: note: vect_model_store_cost: inside_cost = 1, outside_cost = 0 . /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:53: note: vect_model_simple_cost: inside_cost = 2, outside_cost = 1 . /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:53: note: Cost model analysis: Vector inside of loop cost: 7 Vector outside of loop cost: 2 Scalar iteration cost: 6 Scalar outside cost: 0 prologue iterations: 0 epilogue iterations: 0 Calculated minimum iters for profitability: 1 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:53: note: Profitability threshold = 7 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:53: note: LOOP VECTORIZED. /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/no-scevccp-outer-7.c:44: note: vectorized 1 loops in function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36792
[Bug c++/38410] g++.dg/eh/crossjump1.C (internal compiler error)
--- Comment #2 from dominiq at lps dot ens dot fr 2008-12-07 16:01 --- Confirmed. This is a regression (it should appear in the subject otherwise it would be missed). The batch of failures is: FAIL: g++.dg/eh/crossjump1.C (internal compiler error) FAIL: g++.dg/eh/crossjump1.C (test for excess errors) WARNING: g++.dg/eh/crossjump1.C compilation failed to produce executable FAIL: g++.dg/inherit/covariant1.C (internal compiler error) FAIL: g++.dg/inherit/covariant1.C (test for excess errors) WARNING: g++.dg/inherit/covariant1.C compilation failed to produce executable FAIL: g++.dg/inherit/ptrmem2.C (internal compiler error) FAIL: g++.dg/inherit/ptrmem2.C (test for excess errors) FAIL: g++.dg/init/array25.C (internal compiler error) FAIL: g++.dg/init/array25.C (test for excess errors) WARNING: g++.dg/init/array25.C compilation failed to produce executable FAIL: g++.dg/init/value1.C (internal compiler error) FAIL: g++.dg/init/value1.C (test for excess errors) WARNING: g++.dg/init/value1.C compilation failed to produce executable FAIL: g++.old-deja/g++.abi/empty2.C (internal compiler error) FAIL: g++.old-deja/g++.abi/empty2.C (test for excess errors) FAIL: g++.old-deja/g++.mike/virt2.C (internal compiler error) FAIL: g++.old-deja/g++.mike/virt2.C (test for excess errors) WARNING: g++.old-deja/g++.mike/virt2.C compilation failed to produce executable -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38410
[Bug fortran/37829] ICE in resolve_symbol
--- Comment #3 from dominiq at lps dot ens dot fr 2008-12-09 08:41 --- The patch in comment #2 fixes the ICE without regression on i686-apple-darwin9. Is not the "obvious rule" applying here? Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
[Bug fortran/35937] Wrong type for charlength of function
--- Comment #13 from dominiq at lps dot ens dot fr 2008-12-10 15:17 --- In comment #11, I wrote: > I have applied the proposed patches in comment #4 and #5 (one at a time!-), > but > they don't fix the wrong code (note also that gfortran with patch #4 pass the > test suite without regression). Sorry, but I have applied the patches to the wrong tree (my reference one and not the working one). The patch in comment #4 needs to be updated by replacing 'gfc_add_modify_expr' with 'gfc_add_modify', see "2008-07-28 ... Merge from gimple-tuples-branch." in gcc/fortran/ChangeLog. The patch in comment #5 has a typo and should be: se.expr = gfc_evaluate_now (fold_convert (gfc_charlen_type_node, se.expr), &se.pre); I have applied the first patch on powerpc-apple-darwin9 and the second on i686-apple-darwin9. They both fix the problem and pass my tests. Regtesting started. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
[Bug fortran/35937] Wrong type for charlength of function
--- Comment #14 from dominiq at lps dot ens dot fr 2008-12-10 16:18 --- > The patch in comment #5 has a typo and should be: > > se.expr = gfc_evaluate_now (fold_convert (gfc_charlen_type_node, se.expr), > &se.pre); This patch regtested without regression on i686-apple-darwin9. I'll try it later on powerpc-apple-darwin9. Unless someone come with a test that requires the patch in comment #4 (failing with the above change), I'll think the one line change will be better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
[Bug fortran/35937] Wrong type for charlength of function
--- Comment #15 from dominiq at lps dot ens dot fr 2008-12-10 19:15 --- No regression also on powerpc-apple-darwin9 (patch in comment#4). If I understand the two proposed patches, the only difference is that the FX's one create a temporary if CONSTANT_CLASS_P (se.expr) is not true. Is this really necessary? For what "se.expr" will CONSTANT_CLASS_P return false? -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
[Bug testsuite/29071] gcc.dg/20020919-1.c compilation test fails on powerpc-apple-darwin8 at -m64
--- Comment #8 from dominiq at lps dot ens dot fr 2008-12-10 20:31 --- PING! see comment #5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29071
[Bug fortran/35937] Wrong type for charlength of function
--- Comment #17 from dominiq at lps dot ens dot fr 2008-12-11 10:00 --- > Hah! My VMware Fedora catches the bug and demonstrates that my simple fix of > comment #5 does the job; ie. unconditionally do the constant fold to a > gfc_charlen_type_node. This can never do any harm! I have looked a litte bit closer to the patch in comment #4. AFAICT it implements what gfc_evaluate_now does with the difference that var = gfc_create_var (TREE_TYPE (expr), NULL); is replaced with + tree tmp = gfc_create_var (gfc_charlen_type_node, "slength"); Has "slength" any chance to make a difference compared to NULL? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
[Bug bootstrap/38508] New: [4.4 Regression] Bootstrap of r142717 broken in libstdc++-v3
+-v3/include/cstdlib:195: error: '::atoll' has not been declared /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/cstdlib:196: error: '::strtoll' has not been declared /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/cstdlib:197: error: '::strtoull' has not been declared /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/cstdlib:199: error: '::strtof' has not been declared /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/cstdlib:200: error: '::strtold' has not been declared /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/cstdlib:207: error: '__gnu_cxx::lldiv_t' has not been declared /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/cstdlib:212: error: '__gnu_cxx::llabs' has not been declared /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/cstdlib:213: error: '__gnu_cxx::div' has not been declared /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/cstdlib:214: error: '__gnu_cxx::lldiv' has not been declared /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/cstdlib:216: error: '__gnu_cxx::atoll' has not been declared /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/cstdlib:217: error: '__gnu_cxx::strtof' has not been declared /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/cstdlib:218: error: '__gnu_cxx::strtoll' has not been declared /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/cstdlib:219: error: '__gnu_cxx::strtoull' has not been declared /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/cstdlib:220: error: '__gnu_cxx::strtold' has not been declared make[4]: *** [atomic.lo] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-target-libstdc++-v3] Error 2 make: *** [all] Error 2 -- Summary: [4.4 Regression] Bootstrap of r142717 broken in libstdc++-v3 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38508
[Bug middle-end/38520] New: [graphite] wrong code with -O3 -fgraphite-identity on polyhedron benchmarks
mdbx nf protein rnflow test_fpu tfft
Maximum Times : 300.0
Target Error % : 0.200
Minimum Repeats : 2
Maximum Repeats : 5
Benchmark Compile Executable Ave Run Number Estim
Name(secs) (bytes)(secs) Repeats Err %
- --- -- --- --- --
ac 2.31 42560 12.28 2 0.0163
aermod 85.67 1266448 29.84 4 0.1498
air 5.44 77336 8.36 2 0.1975
capacita 3.39 72760 53.92 2 0.0649
channel 2.09 38648 2.27 2 0.0220
doduc 11.30 195928 42.78 2 0.1204
fatigue 4.93 89024 10.87 5 0.2098
gas_dyn 6.51 708584 10.35 5 0.6354
induct 10.01 181168 34.47 2 0.0899
linpk 1.63 42536 27.15 2 0.0147
mdbx 3.26 73000 14.79 2 0.0270
nf 23.89 161416 31.64 2 0.0095
protein 10.24 126424 47.02 2 0.0532
rnflow 10.80 179616 36.22 2 0.0028
test_fpu 10.23 166512 12.30 2 0.0651
tfft 1.16 26432 2.80 2 0.0714
Geometric Mean Execution Time = 16.95 seconds
Polyhedron Benchmark Validator
Copyright (C) Polyhedron Software Ltd - 2004 - All rights reserved
--
Summary: [graphite] wrong code with -O3 -fgraphite-identity on
polyhedron benchmarks
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: i686-apple-darwin9
GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38520
[Bug bootstrap/38508] [4.4 Regression] Bootstrap of r142717 broken in libstdc++-v3
--- Comment #1 from dominiq at lps dot ens dot fr 2008-12-13 22:46 --- Apparently fixed without regression at revision 142742. Closing. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38508
[Bug middle-end/38520] [graphite] wrong code with -O3 -fgraphite-identity on polyhedron benchmarks
--- Comment #2 from dominiq at lps dot ens dot fr 2008-12-14 14:10 --- The test protein.f90 fails when compiled with "-O1 -fstrict-overflow -fgraphite-identity". It works with "-O3 -fno-strict-overflow -fgraphite-identity". The test capacita.f90 fails when compiled with "-O1 -fstrict-aliasing -fstrict-overflow -fgraphite-identity" and works with "-O3 -fno-strict-aliasing -fno-strict-overflow -fgraphite-identity". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38520
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #12 from dominiq at lps dot ens dot fr 2008-12-14 15:54 --- Could you try with the addition of " -fno-strict-aliasing -fno-strict-overflow"? See pr38520. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38520] [graphite] wrong code with -O3 -fgraphite-identity on polyhedron benchmarks
--- Comment #3 from dominiq at lps dot ens dot fr 2008-12-14 17:32 --- Compiling mdbx.f90 with "-m64 -O3 -fgraphite-identity -floop-block -ftree-loop-linear -fno-strict-overflow" gives an ICE: mdbx.f90: In function 'mstep': mdbx.f90:822: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. The test compiles and gives a correct excutable if -m64 is removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38520
[Bug fortran/38530] New: ICE with the example for c_funloc
I tried to compile the test given for c_funloc in http://gcc.gnu.org/onlinedocs/gfortran/C_005fFUNLOC.html#C_005fFUNLOC and I got an ICE with trunk and 4.3.2: funloc.f90: In function 'main': funloc.f90:20: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6836 -- Summary: ICE with the example for c_funloc Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38530
[Bug fortran/37829] ICE in resolve_symbol
--- Comment #6 from dominiq at lps dot ens dot fr 2008-12-15 12:48 --- Compiling the test in comment #4 gives: pr37829_2.f90:21.6: d = c_funloc (g) 1 Error: Can't convert TYPE(_gfortran_iso_c_binding_c_funptr) to TYPE(c_funptr) at (1) looking the gfortran sources for "c_funptr" I get: in gcc/fortran/iso-c-binding.def, line 145 DERIVED_TYPE (ISOCBINDING_FUNPTR, "c_funptr", \ get_int_kind_from_node (ptr_type_node)) and in gcc/fortran/symbol.c, line 3507 generate_isocbinding_symbol (module_name, ptr_id == ISOCBINDING_NULL_PTR ? ISOCBINDING_PTR : ISOCBINDING_FUNPTR, (const char *) (ptr_id == ISOCBINDING_NULL_PTR ? "_gfortran_iso_c_binding_c_ptr" : "_gfortran_iso_c_binding_c_funptr")); line 3591 if (iso_c_sym_id == ISOCBINDING_F_PROCPOINTER) c_ptr_type = "_gfortran_iso_c_binding_c_funptr"; else c_ptr_type = "_gfortran_iso_c_binding_c_ptr"; line 4158 (const char *)(s == ISOCBINDING_FUNLOC ? "_gfortran_iso_c_binding_c_funptr" : "_gfortran_iso_c_binding_c_ptr")); I fail to see what is the difference between "c_funptr" and "_gfortran_iso_c_binding_c_funptr". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
[Bug fortran/38538] ICE with elemental character function
--- Comment #1 from dominiq at lps dot ens dot fr 2008-12-16 07:24 --- Confirmed on (powerpc|i686)-apple-darwin9 revision 142767. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug fortran/38538] ICE with elemental character function
--- Comment #3 from dominiq at lps dot ens dot fr 2008-12-16 16:03 ---
If the subroutine
subroutine xmain()
call foo(func("_"//bar()))
end subroutine xmain
is replaced with
subroutine xmain()
character (len=2) :: zz(2)
zz=func("_"//bar())
call foo(zz)
end subroutine xmain
the code compiles and seems to give a sensible executable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug fortran/38538] ICE with elemental character function
--- Comment #8 from dominiq at lps dot ens dot fr 2008-12-18 21:20 --- With the patch in comment #6, this pr is fixed but now the code character(len=1) :: string print *, transfer(((transfer(string,"x",1))), "x") end and friends (from pr31608) gives a bus error: pr31608_1.f90: In function 'MAIN__': pr31608_1.f90:1: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. Note also that I have been unable to read the test in comment #7. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug fortran/38538] ICE with elemental character function
--- Comment #9 from dominiq at lps dot ens dot fr 2008-12-18 21:36 ---
Another bus error with
! { dg-do run }
! Test fix of PR28118, in which a substring reference to an
! actual argument with an array reference would cause a segfault.
!
! Contributed by Paul Thomas
!
program gfcbug33
character(12) :: a(2)
a(1) = "abcdefghijkl"
a(2) = "mnopqrstuvwx"
call foo ((a(2:1:-1)(6:)))
call bar ((a(:)(7:11)))
contains
subroutine foo (chr)
character(7) :: chr(:)
if (chr(1)//chr(2) .ne. "rstuvwxfghijkl") call abort ()
end subroutine foo
subroutine bar (chr)
character(*) :: chr(:)
if (trim(chr(1))//trim(chr(2)) .ne. "ghijkstuvw") call abort ()
end subroutine bar
end program gfcbug33
pr28118.f90: In function 'gfcbug33':
pr28118.f90:10: internal compiler error: Bus error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug fortran/38538] ICE with elemental character function
--- Comment #13 from dominiq at lps dot ens dot fr 2008-12-20 13:01 ---
The patch in comment #12 fixes the pr without causing the regressions reported
in comments #8 and #9.
Compiling gcc/testsuite/gfortran.dg/char_length_7.f90 gives an ICE:
gimplification failed:
2
constant 2>
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/char_length_7.f90: In function
'xx':
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/char_length_7.f90:30: internal
compiler error: gimplification failed
and the following code:
[ibook-dhum] f90/bug% cat pr31608_4_red_1.f90
character(len=1) :: string = "z"
character(len=20) :: tmp = ""
tmp = Upper ("abcdefgh")
print *, tmp
contains
Character (len=20) Function Upper (string)
Character(len=*) string
print *, len(string)
print *, size(transfer(string,"xy",len(string)))
Upper = ""
Upper(1:2) =
&
transfer(merge(transfer(string,"xy",len(string)),&
string(1:2), .true.), "xy")
return
end function Upper
end
yields a wrong code: the executable gives
8
4
ab
while it gives
8
8
ab
when compiled with ifort.
Currently regtesting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug fortran/38538] ICE with elemental character function
--- Comment #14 from dominiq at lps dot ens dot fr 2008-12-20 14:27 --- Regtested with -m32 and -m64 without other regression that gcc/testsuite/gfortran.dg/char_length_7.f90. The offending line is: ! This was another bug, uncovered when the PR was fixed. if (any(ccopy(z//mz(:)(i:j)) .ne. (/"zzgh ","zzjk "/))) call abort () while if (any(ccopy(z//mz(:)(2:3)) .ne. (/"zzgh ","zzjk "/))) call abort () is compiled without problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug fortran/37472] bad output on default-format write of double in common block with -m64 flag i
--- Comment #14 from dominiq at lps dot ens dot fr 2008-12-21 13:34 ---
> This little patch eliminates the misalignment of output characters with -m32
> and gets rid of a many many valgrind errors.
>
> @@ -628,7 +637,7 @@ output_float_FMT_G_ ## x (st_parameter_d
> \
> while (low <= high)\
> { \
> - GFC_REAL_ ## x temp;\
> + float temp;\
>mid = (low + high) / 2;\
> \
>temp = 0.1 * calculate_exp_ ## x (mid) - 0.5\
Do you understand why? Such a change is the opposite of what I understand of
the GFC_REAL_* machinery, although I have no knowledge about mixed calculations
in C.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37472
[Bug fortran/37472] bad output on default-format write of double in common block with -m64 flag i
--- Comment #16 from dominiq at lps dot ens dot fr 2008-12-22 16:29 ---
>From http://gcc.gnu.org/ml/fortran/2008-12/msg00284.html:
> With Steve Kargl's help, the following simple patch was found to eliminate
> this output
> problem on x86-64. I plan to commit under simple and makes sense to do rule.
Is not the same problem lurking in
if ((m > 0.0 && m < 0.1 - 0.05 / exp_d) || (m >= exp_d - 0.5 ) ||\
with 0.1 and 0.05?
Also there is probably some room for optimization in this piece of code. For
instance calculate_exp_* computes 10**d through an algorithm linear in d, while
it could be computed in O(log2(d)) (see poweri in gcc/builtins.c). Also the
following change:
--- /opt/gcc/_gcc_clean/libgfortran/io/write_float.def 2008-12-21
22:31:05.0 +0100
+++ /opt/gcc/gcc-4.4-work/libgfortran/io/write_float.def2008-12-22
16:27:10.0 +0100
@@ -640,8 +640,8 @@
GFC_REAL_ ## x temp;\
mid = (low + high) / 2;\
\
- temp = 0.1 * calculate_exp_ ## x (mid) - 0.5\
-* calculate_exp_ ## x (mid - d - 1);\
+ temp = calculate_exp_ ## x (mid) \
+* (1.0 - 0.5 / exp_d) / 10;\
\
if (m < temp)\
{ \
speeds up by ~2s the following test:
character(80) s
real*8 x, y
integer i
x=1.0
y=0.0
do i = 1, 1000
write(s,*) y
y = y + x
end do
print *, s
end
(still twice slower with gfortran than ifort or g77).
Note that "temp = calculate_exp_ ## x (mid-1) * (1.0 - 0.5 / exp_d)" is
slightly slower.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37472
[Bug fortran/38618] internal compiler error: in gfc_add_modify
--- Comment #4 from dominiq at lps dot ens dot fr 2008-12-24 15:36 --- Midair collision! I was about to send: The test in comment#2 compiles fine for me on i686-apple-darwin9 with the options I have tried with gfortran 4.2.3, 4.3.2, and 4.4.0 (trunk). One thing is strange is the config: --enable-languages=fortran,c++. What about c? It is the first time I notice a build of gfortran without C. Is it implied by c++?. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38618
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
--- Comment #3 from dominiq at lps dot ens dot fr 2008-12-27 11:40 --- With the patch in comment#2, I see two regressions: [ibook-dhum] f90/bug% gfc /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/pr32601.f03 /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/pr32601.f03:10: internal compiler error: in gfc_iso_c_func_interface, at fortran/resolve.c:2064 ... [ibook-dhum] f90/bug% gfc /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/repack_arrays_1.f90 f951: internal compiler error: in gfc_iso_c_func_interface, at fortran/resolve.c:2064 They are due to the new line: gcc_assert (args->expr->expr_type == EXPR_VARIABLE); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
--- Comment #4 from dominiq at lps dot ens dot fr 2008-12-27 13:00 ---
If I remove the assert gfortran.dg/repack_arrays_1.f90 passes, while
gfortran.dg/pr32601.f03 gives:
print *, c_loc(get_ptr()) ! { dg-error "has PRIVATE components" }
1
Error: Parameter 'get_ptr' to 'c_loc' at (1) must be either a TARGET or an
associated pointer
instead of
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/pr32601.f03:22.19:
print *, c_null_ptr, t ! { dg-error "has PRIVATE components" }
1
Error: Derived type 'c_ptr' at (1) has PRIVATE components
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/pr32601.f03:22.24:
print *, c_null_ptr, t ! { dg-error "has PRIVATE components" }
1
Error: Derived type 'c_ptr' at (1) has PRIVATE components
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/pr32601.f03:23.11:
print *, t ! { dg-error "has PRIVATE components" }
1
Error: Derived type 'c_ptr' at (1) has PRIVATE components
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/pr32601.f03:25.25:
print *, c_loc(get_ptr()) ! { dg-error "has PRIVATE components" }
1
Error: Derived type 'c_ptr' at (1) has PRIVATE components
Note that I do not understand a single word of this private business: what can
be the use of a PUBLIC derived type with PRIVATE components?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr->ref
--- Comment #8 from dominiq at lps dot ens dot fr 2009-01-04 12:27 --- Withe the patch in comment #5 the problems reported in comment #4 disappear, the test in comment #6 gives a bus error at compile time: pr38536_3.f90: In function 'MAIN__': pr38536_3.f90:1: internal compiler error: Bus error and the test in comment #7 gives the reported error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
[Bug fortran/38726] gfortran.dg/elemental_subroutine_7.f90 fail on Linux/ia64
--- Comment #4 from dominiq at lps dot ens dot fr 2009-01-05 14:14 --- (In reply to comment #3) > Please can someone test on older revisions/provide more information? The test passes with gfortran 4.2.3, but not 4.3.2 on powerpc-apple-darwin9. Hence it is a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38726
[Bug fortran/38726] gfortran.dg/elemental_subroutine_7.f90 fail on Linux/ia64
--- Comment #1 from dominiq at lps dot ens dot fr 2009-01-05 13:54 --- The executable aborts on powerpc-apple-darwin9 (r143074) when compiled with -m32, but passes when compiled with -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38726
[Bug fortran/38726] [4.3/4.4 Regression] gfortran.dg/elemental_subroutine_7.f90 fail on Linux/ia64
--- Comment #6 from dominiq at lps dot ens dot fr 2009-01-05 14:47 --- If compiled with -fbounds-check, the executable yields: At line 29 of file /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/elemental_subroutine_7.f90 Fortran runtime error: Array reference out of bounds for array 'p', lower bound of dimension 1 exceeded(-2 < 1) The problem comes from ... p = 20 * r - 10 ... call tq_tvgh (q(k_lev:), (p(p(k_lev: if (any (p(p) /= q)) call abort where min(p)=-10, outside the bounds of p(1:42). If I use ' p = 41 * r + 1', the test passes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38726
[Bug fortran/38726] gfortran.dg/elemental_subroutine_7.f90 fail on Linux/ia64
--- Comment #2 from dominiq at lps dot ens dot fr 2009-01-05 13:57 --- See also http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00421.html for powerpc-apple-darwin8.5.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38726
[Bug testsuite/38790] New: syntax error in target selector
Due to revision 143234:
Author: joel
Date: Fri Jan 9 21:12:36 2009 UTC (14 hours, 12 minutes ago)
Log Message:
2009-01-09 Joel Sherrill
* lib/target-supports.exp: Add method to determine if the effective
target is really a ppc405 after applying all compile options.
* gcc.target/powerpc/405-mulhhwu-2.c: Add dg-skip-if not ppc405.
* gcc.target/powerpc/405-nmachhw-1.c: Likewise.
* gcc.target/powerpc/405-nmaclhw-1.c: Likewise.
...
regtesting gcc fails with:
ERROR: gcc.target/powerpc/405-dlmzb-strlen-1.c: syntax error in target selector
"target powerpc_405_nocache" for " dg-skip-if 6 "other options override
-mcpu=405" { ! powerpc_405_nocache } { "*" } { "" } "
UNRESOLVED: gcc.target/powerpc/405-dlmzb-strlen-1.c: syntax error in target
selector "target powerpc_405_nocache" for " dg-skip-if 6 "other options
override -mcpu=405" { ! powerpc_405_nocache } { "*" } { "" } "
ERROR: gcc.target/powerpc/405-macchw-1.c: syntax error in target selector
"target powerpc_405_nocache" for " dg-skip-if 6 "other options override
-mcpu=405" { ! powerpc_405_nocache } { "*" } { "" } "
UNRESOLVED: gcc.target/powerpc/405-macchw-1.c: syntax error in target selector
"target powerpc_405_nocache" for " dg-skip-if 6 "other options override
-mcpu=405" { ! powerpc_405_nocache } { "*" } { "" } "
ERROR: gcc.target/powerpc/405-macchw-2.c: syntax error in target selector
"target powerpc_405_nocache" for " dg-skip-if 6 "other options override
-mcpu=405" { ! powerpc_405_nocache } { "*" } { "" } "
UNRESOLVED: gcc.target/powerpc/405-macchw-2.c: syntax error in target selector
"target powerpc_405_nocache" for " dg-skip-if 6 "other options override
-mcpu=405" { ! powerpc_405_nocache } { "*" } { "" } "
...
on powerpc (see http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00879.html and
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00883.html).
--
Summary: syntax error in target selector
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc*-*-*
GCC host triplet: powerpc*-*-*
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38790
[Bug testsuite/38791] New: FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
On i686-apple-darwin9 the test gcc/testsuite/gcc.dg/graphite/block-3.c introduced in revision 143159 fails with: [ibook-dhum] f90/bug% gcc44 /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/graphite/block-3.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/graphite/block-3.c:6: error: size of array 'A' is too large -- Summary: FAIL: gcc.dg/graphite/block-3.c (test for excess errors) Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38791
[Bug testsuite/38791] FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
--- Comment #1 from dominiq at lps dot ens dot fr 2009-01-10 11:49 --- I have forgotten to say that the failure occurs in 32 bit mode, but disappears with -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38791
[Bug testsuite/38791] FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
--- Comment #4 from dominiq at lps dot ens dot fr 2009-01-10 22:03 ---
> Does the attached patch fix the fail?
With the patch the test compiles (it does with M up to 812) and the "Strip
Mining" is done for the second nested loops:
for (s_1=0;s_1<=1;s_1++) {
for (s_3=0;s_3<=1;s_3++) {
for (s_5=0;s_5<=1;s_5++) {
for (s_7=64*s_1;s_7<=min(64*s_1+63,99);s_7++) {
for (s_9=64*s_3;s_9<=min(64*s_3+63,99);s_9++) {
for (s_11=64*s_5;s_11<=min(64*s_5+63,99);s_11++) {
S13(s_1,s_3,s_5,s_7,s_9,s_11) ;
}
}
}
}
}
}
I don't know how I can test this file alone without regtesting all gcc (I
tried: make -k check-gcc RUNTESTFLAGS="dg.exp=graphite/block-3.c" without
success).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38791
[Bug testsuite/38791] FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
--- Comment #6 from dominiq at lps dot ens dot fr 2009-01-10 22:09 --- > Try make -k check-gcc RUNTESTFLAGS="graphite.exp=block-3.c" Thanks, then I get: Running /opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.dg/graphite/graphite.exp ... === gcc Summary === # of expected passes1 /Volumes/MacBook/opt/gcc/i686-darwin/gcc/xgcc version 4.4.0 20090110 (experimental) [trunk revision 143247p1] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38791
[Bug testsuite/38791] FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
--- Comment #7 from dominiq at lps dot ens dot fr 2009-01-11 11:13 ---
Before closing this pr as fixed, I have a question: usually tests having
-fdump-* in dg-options are doing some search of patterns in the dumped file,
e.g. in gcc/testsuite/gcc.dg/pr35729.c
/* { dg-options "-Os -fdump-rtl-loop2_invariant" } */
...
/* { dg-final { scan-rtl-dump-times "Decided to move invariant" 0
"loop2_invariant" } } */
I noticed that gcc/testsuite/gcc.dg/graphite/block-3.c has only the cleaning
dg-final, but no scan-* one(s). I don't see anything in
gcc/testsuite/gcc.dg/graphite/graphite.exp that could supply it either.
Is this the intended behavior or is there something missing in this test (and
possibly other graphite ones)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38791
[Bug fortran/38802] Seg fault for RESULT with allocatable components
--- Comment #1 from dominiq at lps dot ens dot fr 2009-01-11 13:26 --- Confirmed on i686-apple-darwin9 with -m64 or -m32 with optimization -O1 and above: Thread 0 Crashed: 0 a.out 0x1dec __mod_a_MOD_a_fun + 30 1 a.out 0x1daf MAIN__ + 141 2 a.out 0x1f98 main + 40 3 a.out 0x1cf6 start + 54 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38802
[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly
--- Comment #3 from dominiq at lps dot ens dot fr 2009-01-13 11:37 --- > - Mathematica: > -2^2 = 4, -2.0^2.0 = -4.0 > 2.0^1.9 = -3.73213 <--- probably -2.0^1.9! Apparently Mathematica parse "-2.0^a" as "-(2.0^a)". (-2.0)^1.9 gives "3.54947- 1.15329 I". I don't know if the fortran standard says how "-a**b" should be parsed (nor have the time right now to decipher the legalese). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823
[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly
--- Comment #2 from dominiq at lps dot ens dot fr 2009-01-13 11:30 --- > The question is whether one needs to reject it completely or only with > -std=f95. I vote for "only with -std=f95" with may be a warning otherwise. I think it is a legitimate optimization to replace A**B by A**I (with I=B) when B is known to be an integer, hence to accept negative values for A in this case. I find upsetting to have to cheat with variables when constant folding does not give the same result as a similar code with variables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823
[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly
--- Comment #10 from dominiq at lps dot ens dot fr 2009-01-13 21:13 --- > I intend to change this, conditional on perhaps -ffast-math and/or -pedantic, I don't understand the "and/or": -ffast-math and -pedantic at the same time does not make any sense for me, -ffast-math allows some sloppiness with respect to the standard, while -pedantic does not. > You can use A**I directly if you want to accept negative values. I have never said that (-2.0)**2.0 is in my coding style. My point is that a pedantic implementation triggers too many bug reports and are not worth the time spent on it (see -2**31). I agree with comment#0 "gfortran should print a diagnostic for -std=f95/f2003/f2008", but not without -std=*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823
[Bug fortran/34955] transfer_assumed_size_1.f90: Valgrind error: invalid read of size 3
--- Comment #21 from dominiq at lps dot ens dot fr 2009-01-14 08:15 ---
On i686-apple-darwin9 I cannot test the valgrind part of this pr, however with
the patch in http://gcc.gnu.org/ml/fortran/2009-01/msg00162.html the following
test now succeeds:
character(len=1) :: string = "z"
character(len=20) :: tmp = ""
tmp = Upper ("abcdefgh")
print *, tmp
contains
Character (len=20) Function Upper (string)
Character(len=*) string
integer :: ij
print *, len(string)
print *, size(transfer(string,"xy",len(string)))
i = size(transfer(string,"xy",len(string)))
if (i /= len(string)) call abort()
Upper = ""
Upper(1:2) =
&
transfer(merge(transfer(string,"xy",len(string)),&
string(1:2), .true.), "xy")
return
end function Upper
end
(coming from pr31608). I saw one regression on char_cast_1.f90 which needs some
adjustment of the test, the following change allows it to pass:
--- ../_gcc_clean/gcc/testsuite/gfortran.dg/char_cast_1.f90 2008-05-19
14:20:35.0 +0200
+++ gcc/testsuite/gfortran.dg/char_cast_1.f90 2009-01-14 07:37:03.0
+0100
@@ -27,5 +27,5 @@
end
! The sign that all is well is that [S.5][1] appears twice.
! Platform dependent variations are [S$5][1], [__S_5][1], [S___5][1]
-! { dg-final { scan-tree-dump-times "5\\\]\\\[1\\\]" 2 "original" } }
+! { dg-final { scan-tree-dump-times "6\\\]\\\[1\\\]" 2 "original" } }
! { dg-final { cleanup-tree-dump "original" } }
>From the comment the test seems fragile and should probably changed to
something more robust.
Thanks for the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34955
[Bug fortran/38852] UBOUND fails for negative stride triplets
--- Comment #1 from dominiq at lps dot ens dot fr 2009-01-14 22:08 --- Confirmed on i686-apple-darwin9/trunk, it also fails with gfortran 4.2.3 and 4.3.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38852
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #10 from dominiq at lps dot ens dot fr 2009-01-16 10:00 --- I don't see any problem on powerpc-apple-darwin9, but I confirm it on i686-apple-darwin9 on 32 bit mode. The problem disappear with either -m64 and/or -fno-pic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #19 from dominiq at lps dot ens dot fr 2009-01-17 12:29 ---
Further reduced test case:
PROGRAM testcase
IMPLICIT NONE
INTEGER NENERT
PARAMETER (NENERT=62)
LOGICAL QENER(NENERT)
CHARACTER*4 ANER(NENERT)
CHARACTER*80 LINE
INTEGER NTERMS, J, START, STOP, PUNIT
PUNIT = 6
qener = .false.
qener(5:10) = .true.
aner = ''
ANER(5)='BOND'
ANER(6)='ANGL'
ANER(7)='DIHE'
ANER(8)='IMPR'
ANER(9) ='VDW '
ANER(10)='ELEC'
LINE=' '
LINE(2:2)='|'
LINE(80:80)='|'
NTERMS=2
DO J=1,NENERT
! IF (QENER(J).AND.ANER(J).NE.'') THEN
IF (QENER(J)) THEN
IF (NTERMS.GE.4) THEN
WRITE(PUNIT,'(A80)') LINE
LINE=' '
LINE(2:2)='|'
LINE(80:80)='|'
NTERMS=0
write(10,*) LINE
END IF
NTERMS=NTERMS+1
START=(NTERMS-1)*19 +3
STOP=NTERMS*19+2
write (10,*) stop, LINE(80:80)
WRITE(LINE(START:STOP),'(4A)') ' E(',ANER(J),')='
END IF
END DO
IF (NTERMS.GE.1) WRITE(PUNIT,'(A80)') LINE
END
gives at -O3
| E(BOND)= E(ANGL)=
| E(DIHE)= E(IMPR)= E(VDW )= E(ELEC)=
|
If I replace the line
IF (QENER(J)) THEN
by the commented one, I get
| E(BOND)= E(ANGL)=
| E(DIHE)= E(IMPR)= E(VDW )= E(ELEC)=
The content of fort.10 show that the content of LINE(80:80) is wrong.
One thing I did not realized when writing comment #10, is that I don't build
gcc with graphite on my G5:
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w
--mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info
--build=powerpc-apple-darwin9
--enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/usr --with-system-zlib --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib
Thread model: posix
gcc version 4.4.0 20090116 (experimental) [trunk revision 143431] (GCC)
while I have it on i686-apple-darwin9:
Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w
--mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info
--build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java
--with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--with-cloog=/opt/cloog/build --with-ppl=/opt/ppl/build
Thread model: posix
gcc version 4.4.0 20090116 (experimental) [trunk revision 143431p3] (GCC)
Somehow I got the impression that graphite is now enabled at -O2, although I
may have misunderstood what I read. Could the correlation of this pr with
graphite be checked? Just in case I cc Sebastian Pop.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
CC||sebpop at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug fortran/38152] [4.4 Regression] procedure pointers as module variables
--- Comment #12 from dominiq at lps dot ens dot fr 2009-01-17 13:20 --- (In reply to comment #11) > This PR can be closed, provided there are no remaining issues on darwin9 (see > comment #4 and #5). I cannot check this myself (since I don't have access to a > darwin system), but maybe Dominique can? AFAICT all the tests I have run passed, so this PR can probably be closed. If I see anything I'll reopen it and report. Thanks for the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug middle-end/38846] [Graphite] 70% slower using -floop* than without graphite (gas_dyn of Polyhedron)
--- Comment #4 from dominiq at lps dot ens dot fr 2009-01-17 18:12 --- I have similar results as comment #0 on i686-apple-darwin9 (Core2) trunk revision 143468: Date & Time : 17 Jan 2009 17:41:32 Test Name : pbharness Compile Command : gfc %n.f90 -m64 -O3 -ffast-math -funroll-loops -fgraphite -fgraphite-identity -floop-block -floop-strip-mine -floop-interchange -ftree-loop-linear -fomit-frame-pointer -finline-limit=600 --param min-vect-loop-bound=2 -o %n Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft Maximum Times : 300.0 Target Error % : 0.200 Minimum Repeats : 2 Maximum Repeats : 5 Benchmark Compile Executable Ave Run Number Estim Name(secs) (bytes)(secs) Repeats Err % - --- -- --- --- -- ac 4.86 42560 12.31 5 0.2625 aermod 87.72 1270544 30.36 5 0.2338 air 5.73 77336 8.38 5 0.0536 capacita 4.13 72760 45.60 2 0.0055 channel 1.69 30456 2.71 2 0.0368 doduc 11.71 200024 42.88 2 0.0501 fatigue 4.26 76736 12.91 2 0.0852 gas_dyn 5.83 692200 22.24 5 0.4693 induct 10.17 177072 34.38 2 0.1440 linpk 1.67 42536 28.21 5 0.3051 mdbx 3.43 73000 14.79 2 0.0068 nf 14.82 112264 32.25 2 0.1612 protein 9.92 114136 45.90 2 0.1961 rnflow 11.24 171464 37.49 2 0.0960 test_fpu 9.49 154224 13.06 2 0.1263 tfft 1.15 26432 2.88 5 0.2609 Geometric Mean Execution Time = 18.18 seconds ... Finished Testing 16 benchmarks - 16 passed, and 0 failed compared to Date & Time : 17 Jan 2009 18:03:59 Test Name : pbharness Compile Command : gfc %n.f90 -m64 -O3 -ffast-math -funroll-loops -ftree-loop-linear -fomit-frame-pointer -finline-limit=600 --param min-vect-loop-bound=2 -o %n Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft Maximum Times : 300.0 Target Error % : 0.200 Minimum Repeats : 2 Maximum Repeats : 5 Benchmark Compile Executable Ave Run Number Estim Name(secs) (bytes)(secs) Repeats Err % - --- -- --- --- -- ac 2.38 42560 12.33 5 0.3327 aermod 86.86 1270544 29.86 2 0.0151 air 5.53 77336 8.39 5 0.2713 capacita 3.40 72760 55.49 5 0.5426 channel 1.98 38648 2.27 2 0. doduc 11.42 200024 42.93 2 0.1456 fatigue 4.94 89024 10.83 5 0.2533 gas_dyn 6.61 708584 10.38 2 0.1541 induct 9.95 181168 34.41 2 0.0727 linpk 1.50 42536 27.98 2 0.0804 mdbx 3.30 73000 14.81 2 0.0911 nf 24.30 161416 32.06 4 0.1922 protein 10.54 126424 46.18 2 0.1646 rnflow 10.93 179616 36.00 2 0.0014 test_fpu 10.26 166512 12.45 2 0.0723 tfft 1.10 26432 2.86 5 0.2793 Geometric Mean Execution Time = 17.05 seconds The 70% for gas_dyn turns to be more than a factor 2, and capacita is faster by almost 20% with floop-block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38846
[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #25 from dominiq at lps dot ens dot fr 2009-01-17 23:28 --- In the reduced case in comment #19 ANER is initialized and the output is still wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #26 from dominiq at lps dot ens dot fr 2009-01-17 23:48 --- Further reduced test case: PROGRAM testcase IMPLICIT NONE INTEGER NENERT PARAMETER (NENERT=62) CHARACTER*4 ANER(NENERT) CHARACTER*80 LINE INTEGER PUNIT PUNIT = 6 aner = '' ANER(5)='BOND' ANER(6)='ANGL' LINE=' ' LINE(2:2)='|' LINE(80:80)='|' write (10,*) "'", line, "'" WRITE(PUNIT,'(A80)') LINE END [ibook-dhum] f90/bug% cat fort.10 ' | ' If I comment one of the two lines: ANER(5)='BOND' ANER(6)='ANGL' the bug disappears. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #27 from dominiq at lps dot ens dot fr 2009-01-18 12:00 --- Further reduced test case: PROGRAM testcase IMPLICIT NONE CHARACTER*4 ANER(18) CHARACTER*80 LINE aner = '' ANER(1)='A ' ANER(2)='' LINE=' ' LINE(78:80)='xyz' WRITE(*,'(A82)') "'"//LINE//"'" END With this test almost any change remove the bug: the lenght of line has to be 80, the size of the array ANER has to be 18 or larger, LINE has to be initialized with ' ' and not '', the two ANER elements have to contain at least one nonblank character, ANER has to be initialized before its two elements, ... . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #28 from dominiq at lps dot ens dot fr 2009-01-18 12:06 ---
The difference between the results of -fdump-tree-optimized for the cases
aner = ''
ANER(1)='A '
ANER(2)=''
and
ANER(1)='A '
ANER(2)=''
aner = ''
is ('pre' with the bug, 'rev' without it)
--- pr38868_red_2.f90-pre 2009-01-18 12:42:15.0 +0100
+++ pr38868_red_2.f90-rev 2009-01-18 12:41:33.0 +0100
@@ -16,6 +16,8 @@
:
_gfortran_set_options (8, &options.0);
+ aner[0] = "A ";
+ aner[1] = "";
ivtmp.33 = 0;
:
@@ -27,8 +29,6 @@
goto ;
:
- aner[0] = "A ";
- aner[1] = "";
__builtin_memcpy (&line, &" "[1]{lb: 1 sz: 1}, 1);
__builtin_memset (&line[2]{lb: 1 sz: 1}, 32, 79);
__builtin_memcpy (&line[78]{lb: 1 sz: 1}, &"xyz"[1]{lb: 1 sz: 1}, 3);
Can anyone see the difference between the two marked lines? The hexdump for the
diff without -u is:
31 38 61 31 39 2c 32 30 0a 3e 20 20 20 61 6e 65 |18a19,20.> ane|
0010 72 5b 30 5d 20 3d 20 22 41 20 20 20 22 3b 0a 3e |r[0] = "A ";.>|
0020 20 20 20 61 6e 65 72 5b 31 5d 20 3d 20 22 20 20 | aner[1] = " |
0030 20 20 22 3b 0a 33 30 2c 33 31 64 33 31 0a 3c 20 | ";.30,31d31.< |
0040 20 20 61 6e 65 72 5b 30 5d 20 3d 20 22 41 20 20 | aner[0] = "A |
0050 20 22 3b 0a 3c 20 20 20 61 6e 65 72 5b 31 5d 20 | ";.< aner[1] |
0060 3d 20 22 20 20 20 20 22 3b 0a|= "";.|
The difference between the assembly is:
--- pr38868_red_2.s-pre 2009-01-18 12:50:15.0 +0100
+++ pr38868_red_2.s-rev 2009-01-18 12:51:04.0 +0100
@@ -26,34 +26,34 @@
leal_options.0.1497-"L001$pb"(%ebx), %eax
movl%eax, 4(%esp)
callL__gfortran_set_options$stub
- xorl%eax, %eax
+ movlLC0-"L001$pb"(%ebx), %eax
leal-96(%ebp), %edx
+ movl%eax, -96(%ebp)
+ movlLC1-"L001$pb"(%ebx), %eax
+ movl%eax, -92(%ebp)
+ xorl%eax, %eax
.align 4,0x90
L2:
movl$538976288, (%edx,%eax,4)
addl$1, %eax
cmpl$18, %eax
jne L2
- movlLC0-"L001$pb"(%ebx), %eax
leal-172(%ebp), %edi
- movl$19, %ecx
- leal-176(%ebp), %esi
- movb$32, -176(%ebp)
- movb$32, -175(%ebp)
- movl%eax, -96(%ebp)
- movlLC1-"L001$pb"(%ebx), %eax
- movw$8224, -174(%ebp)
- movw$31096, -99(%ebp)
- movb$122, -97(%ebp)
- movl%eax, -92(%ebp)
movl$538976288, %eax
+ movl$19, %ecx
rep stosl
lealLC2-"L001$pb"(%ebx), %eax
leal-680(%ebp), %edi
movl%eax, -672(%ebp)
lealLC3-"L001$pb"(%ebx), %eax
+ leal-176(%ebp), %esi
movl%eax, -632(%ebp)
movl%edi, (%esp)
+ movb$32, -176(%ebp)
+ movb$32, -175(%ebp)
+ movw$8224, -174(%ebp)
+ movw$31096, -99(%ebp)
+ movb$122, -97(%ebp)
movl$11, -668(%ebp)
movl$5, -628(%ebp)
movl$4096, -680(%ebp)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #29 from dominiq at lps dot ens dot fr 2009-01-18 12:50 --- Created an attachment (id=17133) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17133&action=view) Assembly corresponding to the test case in comment #27 When I compile the attached file with gfortran 4.3, the executable shows the bug. Could this file be compiled on linux? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #30 from dominiq at lps dot ens dot fr 2009-01-18 13:13 --- If I compile the test in comment #27 with -O1 and all the other flags supposed to be turned on by -O2 (taken from http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options) the bug does not show up. What are the missing differences between -O1 and -O2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug target/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #45 from dominiq at lps dot ens dot fr 2009-01-19 19:31 --- The patch in comment #44 fixes the problem (as far as I can test it) on i686-apple-darwin9 without regression for gcc, g++, gfortran, objc, and obj-c++, full test this night. Thanks for the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug fortran/38907] [4.3/4.4 Regression ] ICE when contained function has same name as module function and used in expression
--- Comment #5 from dominiq at lps dot ens dot fr 2009-01-19 22:39 --- > This removes the ICE: ... Do you understand why? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38907
[Bug c++/38930] [4.4 Regression] Revision 143546 failed to bootstrap
--- Comment #3 from dominiq at lps dot ens dot fr 2009-01-21 19:58 --- It failed to bootstrap on i686-apple-darwin9 too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38930
[Bug middle-end/38968] New: Complex matrix product is not vectorized
As shown by the following code, the complex matrix product is not vectorized,
even with the patch in http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01174.html:
program mymatmul
implicit none
integer, parameter :: kp = 4
integer, parameter :: n = 2000
real(kp), dimension(n,n) :: rr, ri
complex(kp), dimension(n,n) :: a,b,c
real :: t1, t2
integer :: i, j, k
call random_number (rr)
call random_number (ri)
a = cmplx (rr, ri)
call random_number (rr)
call random_number (ri)
b = cmplx (rr, ri)
call cpu_time (t1)
c = cmplx (0._kp, 0._kp)
do j = 1, n
do k = 1, n
do i = 1, n
c(i,j) = c(i,j) + a(i,k) * b(k,j)
end do
end do
end do
call cpu_time (t2)
write (*,'(F8.4)') t2-t1
end program mymatmul
[ibook-dhum] bug/timing% gfc -m64 -O3 -ffast-math -funroll-loops
-fomit-frame-pointer -ftree-vectorizer-verbose=2 mymatmul_v_c4.f90
mymatmul_v_c4.f90:22: note: not vectorized: can't calculate alignment for data
ref.
mymatmul_v_c4.f90:15: note: not vectorized: complicated access pattern.
mymatmul_v_c4.f90:15: note: not vectorized: can't calculate alignment for data
ref.
mymatmul_v_c4.f90:12: note: not vectorized: complicated access pattern.
mymatmul_v_c4.f90:12: note: not vectorized: can't calculate alignment for data
ref.
mymatmul_v_c4.f90:1: note: vectorized 0 loops in function.
The real corresponding code is vectorized.
--
Summary: Complex matrix product is not vectorized
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: i686-apple-darwin9
GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38968
[Bug fortran/37744] ICE-on-invalid with ISO_C_BINDING and TYPEs
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 09:06 --- Also ICE on trunk r147065 powerpc-apple-darwin9 or r147085 i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37744
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 08:59 ---
This test has been introduced by the patch in
http://gcc.gnu.org/ml/fortran/2007-01/msg00425.html.
The tests gfortran.dg/array_memcpy_[1-3].f90 use
! { dg-final { scan-tree-dump-times "memcpy" * "original" } }
So a simple fix would be to replace
! { dg-final { scan-tree-dump-times "d = " 1 "original" } }
with
! { dg-final { scan-tree-dump-times "memcpy" 1 "original" } }
but I don't understand why array_memcpy_4.f90 used to give a different
construct and this change could mask a more serious problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug bootstrap/39968] [4.5 Regression] ./plugin-version.h:11: error: 'gcc_version' defined but not used
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-04 11:42 --- This pr is fixed as long as *-apple-darwin9 is concerned. Due to comments #3 to #5, I don't close it as fixed. If someone wants to keep this PR open, (s)he should change subject and priority. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39968
[Bug bootstrap/39929] [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-apple-darwin9 and powerpc-ibm-aix
--- Comment #15 from dominiq at lps dot ens dot fr 2009-05-04 11:45 --- This pr is fixed as long as *-apple-darwin9 is concerned. Due to comments #11 to #13, I don't close it as fixed. If someone wants to keep this PR open, (s)he should change subject, platform, and priority. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 17:54 --- With thee patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html without type cheating, all the ICEs in my tests are gone. It even fixes pr37744!-(it may give a clue on how to fix it without -fwhole-file). For the test arr_fun.f90, I now get: arr_fun.f90:10.6: res = test(2) 1 Error: The reference to function 'test' at (1) either needs an explicit INTERFACE or the rank is incorrect which seems right (without -fwhole-file I get a "bus error" at run time). Test gcc/testsuite/gfortran.dg/hollerith.f90 and friends won't probably pass regtesting: call test (8h hello) 1 Error: Type mismatch in argument 'h' at (1); passed HOLLERITH to INTEGER(8) I have to run the polyhedron tests and to regtest, so it is all for this time. Thanks for the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40018] ICE in output_constructor
--- Comment #1 from dominiq at lps dot ens dot fr 2009-05-04 19:19 --- Confirmed on trunk and 4.4.0. Works with 4.3.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40018
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #5 from dominiq at lps dot ens dot fr 2009-05-04 21:52 --- With the patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html gas_dyn.f90 fails as in commet #0, except for -O1: [ibook-dhum] lin/test% gfc -O1 -fwhole-file gas_dyn.f90 gas_dyn.f90: In function 'chozdt': gas_dyn.f90:216: internal compiler error: Bus error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-04 22:20 ---
Regtest gives:
=== gfortran Summary ===
# of expected passes117714
# of unexpected failures576
# of expected failures 78
# of unsupported tests 906
for RUNTESTFLAGS="--target_board=unix'{,-m64,/-fwhole-file,-m64/-fwhole-file}'"
with no "unexpected failures" for {,-m64}. 444 failures come from
cc1: warning: command line option "-fwhole-file" is valid for Fortran but not
for C
I think I know how to filter them.
---> generic_actual_arg.f90 fails with
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/generic_actual_arg.f90:40.64:
CALL F(CALCULATION2) ! OK because there is a same name specific
1
Error: More actual than formal arguments in procedure call at (1)
False positive?
---> global_references_1.f90 fails with
SUBROUTINE j (x)! { dg-error "is already being used as a FUNCTION" }
2
Error: Global name 'j' at (1) is already being used as a SUBROUTINE at (2)
/opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/global_references_1.f90:39.6:
T = j () ! { dg-error "is already being used as a FUNCTION" }
1
Error: Missing actual argument for argument 'x' at (1)
/opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/global_references_1.f90:68.64:
---> hollerith.f90 fails with
call test (8h hello)
1
Error: Type mismatch in argument 'h' at (1); passed HOLLERITH to INTEGER(8)
---> hollerith_legacy.f90 same failure
---> import6.f90 fails with
opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/import6.f90:42.13:
call func1(x)
1
Error: Type mismatch in argument 'param' at (1); passed TYPE(my_type) to
TYPE(my_type)
Obviously some tests will require adjustments to pass with -fwhole-file.
More tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
