--- 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 a
--- 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
--- 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'
--- 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.o
--- 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
--- 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
--- 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
c
--- 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
--- 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
--- 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
--- 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 "
--- 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&#
--- 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&q
--- 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
--- 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 (&
--- 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
--- 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
--- 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
--- 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(*)', -fb
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
> t
--- 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-d
--- 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 tru
--- 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
--- 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
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
e-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
--- 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
--- 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 compile
--- 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
--- 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
xpr.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
--- 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 &quo
--- 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
--- 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 subrou
--- 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 e
--- 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
--- 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>
/
--- 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
--- 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
> \
--- 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
--- 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
--- 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
--- 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 &#
--- 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 comp
--- 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.
--
h
--- 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
--- 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 &#
--- 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
lts/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
ot 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
--- 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
--- 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 (
--- 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 ===
--- 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 &quo
--- 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
--- 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.5
--- 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 repl
--- 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, -ffas
--- 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 = &q
--- 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
--- 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.c
--- 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
--- 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 syst
--- 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
--- 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
--- 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
--- 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)=''
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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:
--- 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
--- 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" * "orig
--- 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.
--
--- 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 pri
--- 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
--- 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
--- 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 'c
--- 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
1 - 100 of 2230 matches
Mail list logo
