[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2006-05-26 08:31 --- (In reply to comment #18) This patch is beyond my current understanding, so someone else needs to look at it. I think our best chance here is to find the exact patch that broke it. You said it's between r113373 and r113396. The revisions that could have introduced it (on a material basis, not speaking of how likely it is) are: r113375, r113376, r113378, r113382, r113388, r113389, r113395. It might be r113395 that did it: * config/rs6000/rs6000.c (rs6000_override_options): Enable TARGET_NO_FP_IN_TOC for section anchors. (optimization_options): Enable section anchors for all non-Objective languages. As I don't fully understand what this means, I'm adding dje to the Cc list. Maybe r113394 is worth testing, could someone do that? (i'm in no position to do any testing right now) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #20 from dje at gcc dot gnu dot org 2006-05-26 14:07 --- The patch you reference enables section anchors by default. Neither AIX nor PPC Linux show new Gfortran testsuite failures from the use of section anchors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #21 from dir at lanl dot gov 2006-05-26 17:45 --- It is rev 113395 that is causing the problem. I backed out that change and built today's version of gfortran - it now correctly runs one of the tests that has been failing - [dranta:~/tests/gfortran-D] dir% gfortran -O1 -o write_logical write_logical.f90 [dranta:~/tests/gfortran-D] dir% write_logical [dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.6.0 Configured with: ../gcc/configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.2.0 20060526 (experimental) [dranta:~/tests/gfortran-D] dir% cat write_logical.f90 ! PR 14334, L edit descriptor does not work ! ! this test uses L1 and L4 to print TRUE and FALSE logical true,false character*10 b true = .TRUE. false = .FALSE. b = '' write (b, '(L1)') true if (b(1:1) .ne. 'T') call abort b = '' write (b, '(L1)') false if (b(1:1) .ne. 'F') call abort b = '' write(b, '(L4)') true if (b(1:4) .ne. ' T') call abort b = '' write(b, '(L4)') false if (b(1:4) .ne. ' F') call abort end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #10 from dir at lanl dot gov 2006-05-25 13:36 --- I restored and rebuilt the 20060508 version that I had archived and I still get the error - [dranta:~/tests/gfortran-D] dir% gfortran -O1 -o write_logical write_logical.f90 [dranta:~/tests/gfortran-D] dir% write_logical At line 9 of file write_logical.f90 Fortran runtime error: Missing initial left parenthesis in format [dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.6.0 Configured with: ../gcc/configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.2.0 20060508 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2006-05-25 14:04 --- Dale, I am confused. Are you saying the breakage in gcc trunk goes as far back as 20060508? I was going to try a few builds here on my G5 to see if I can narrow down the svn revision numbers involved. What is the oldest revision that you have been able to reproduce this bug in and the newest revision that doesn't show it? Jack -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #12 from dir at lanl dot gov 2006-05-25 14:35 --- I rebuild version 20060508 from the full source tree that I had saved and I find the problem - I am beginning to wonder if the update to CCTOOLS or the system is causing the problem - except for the fact that I can build the current 4.1.1 and it works fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-05-25 14:44 --- Maybe go back farther than the email I just posted to gfortran list suggests. I am suspicious that this is not a gfortran problem, but then 4.1 is working. Take a shot at an April 1 version maybe. You can find the version numbers if you look on some of the testresults mailing list archives. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #14 from dir at lanl dot gov 2006-05-25 14:47 --- The version from the wiki also fails - [dranta:~/tests/gfortran-D] dir% gfortran -O1 -o write_logical write_logical.f90 [dranta:~/tests/gfortran-D] dir% write_logical At line 9 of file write_logical.f90 Fortran runtime error: Missing initial left parenthesis in format [dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin7.9.0 Configured with: ../gcc/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --with-gmp=/tmp/gfortran-20060512/gfortran_libs --enable-bootstrap Thread model: posix gcc version 4.2.0 20060512 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #15 from dir at lanl dot gov 2006-05-25 14:54 --- At last one that works (I knew that I did the testsuite on this one) - version 20060405 - [dranta:~/tests/gfortran-D] dir% gfortran -O1 -o write_logical write_logical.f90 [dranta:~/tests/gfortran-D] dir% write_logical [dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.6.0 Configured with: ../gcc/configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.2.0 20060405 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #16 from dir at lanl dot gov 2006-05-25 16:33 --- Works at rev 112998 just before the updates for bug 27138 on April 17 - [dranta:~/tests/gfortran-D] dir% gfortran -O1 -o write_logical write_logical.f90 [dranta:~/tests/gfortran-D] dir% write_logical [dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.6.0 Configured with: ../gcc/configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.2.0 20060417 (experimental) [dranta:~/tests/gfortran-D] dir% h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #17 from dir at lanl dot gov 2006-05-25 20:53 --- It runs after (bug fix 20257) rev 113373 and fails after (bug fix 27360) rev 113396. I think that narrows it down to one of two updates - if the problem was caused by changes to gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2006-05-26 00:08 --- All of the IO patches for both revs, before and after the failures, exist in 4.1 and 4.2. 4.1 is not failing, so this leads me to believe this is not a libgfortran failure. There is an alignment patch that went in on 4/18/06 with no associated PR. Perhaps this is it, but it is also in 4.1 and 4.2. It is I/O related, but on the frontend side. http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00633.html This patch is beyond my current understanding, so someone else needs to look at it. Andrew? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-24 06:14
---
Reduced testcase (fails at -O1 and higher):
character*1 b
b = ''
write (*, '()')
end
is compiled into (-gfump-original-tree):
MAIN__ ()
{
char b[1:1];
_gfortran_set_std (70, 127, 0);
_gfortran_copy_string (1, b, 0, );
{
struct __st_parameter_dt dt_parm.0;
dt_parm.0.common.filename = write_logical.f90;
dt_parm.0.common.line = 3;
dt_parm.0.common.unit = 6;
dt_parm.0.format = ();
dt_parm.0.format_len = 2;
dt_parm.0.common.flags = 4096;
_gfortran_st_write (dt_parm.0);
_gfortran_st_write_done (dt_parm.0);
}
}
but, when setting a breakpoint in _gfortran_st_write, we can see that the
format is wrong:
(gdb) p dtp-format
$4 = 0x2ffc
and I think it's an alignment issue, because the real format is just a bit
further down the dtp:
(gdb) p dtp-format+1
$5 = 0x2ffd ()
Jerry, which of your patches has been commited on mainline but not on 4.1?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu dot
||org, fxcoudert at gcc dot
||gnu dot org, pinskia at gcc
||dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-05-24 06:14:52
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-05-24 13:48 --- Look in Changelog and you will see the most recent two in trunk have not gone to 4.1 yet. The namelist patch for expanded reads does touch io.h The other was a simple problem. I changed a return; to return NULL; to get rid of a warning. That leaves the namelist patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #8 from dir at lanl dot gov 2006-05-24 18:27 --- Hi Jerry, I tried rev 113947 and rev 113923 that I think are just before your patches and gfortran still failed. I did a svn update -r 113923 gcc to create the old version. I hope that is the correct way to do it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-05-25 00:40 --- Dale, I believe this is the correct use of update to get back to previous versions if gcc is your main trunk directory and you were one directory above when you invoked the command. You may want to check in libgfortran/io/io.h and make sure there is no variable called expanded_read. If you were in the main top level directory, svn -r 113923 is sufficient, otherwise you may get the gcc subdirectory only that does not contain libgfortran So, assuming you got there correctly, this rules out any of my patches. Please let me know if you can confirm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #5 from dir at lanl dot gov 2006-05-23 19:16 ---
Has anybody else with a powerPC Macintosh tried the testsuite recently ?
I down loaded and rebuild 4.1.1 and 4.2.0 today. 4.1.1 is Ok. 4.2.0 has the
same errors.
The test problem in comment #3 works with -g, but when complied with -O1 the
address that should point to '(L1)' is pointing a null character before the '('
when it gets to the runtime print routine and so it generates the error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #2 from dir at lanl dot gov 2006-05-22 14:41 --- Hi Paul, I down loaded a completely new tree this morning and did a new build with about the same results - Test Run By dir on Mon May 22 07:08:14 2006 Native configuration is powerpc-apple-darwin8.6.0 === gfortran tests === Schedule of variations: unix Running target unix Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target. Using /Users/dir/gfortran/gcc/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /Users/dir/gfortran/gcc/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/char_result_5.f90 execution test FAIL: gfortran.dg/char_result_5.f90 execution test FAIL: gfortran.dg/char_result_5.f90 execution test FAIL: gfortran.dg/char_result_5.f90 execution test FAIL: gfortran.dg/char_result_5.f90 execution test FAIL: gfortran.dg/char_result_5.f90 execution test FAIL: gfortran.dg/char_result_5.f90 execution test FAIL: gfortran.dg/char_result_6.f90 execution test FAIL: gfortran.dg/char_result_6.f90 execution test FAIL: gfortran.dg/char_result_6.f90 execution test FAIL: gfortran.dg/char_result_6.f90 execution test FAIL: gfortran.dg/char_result_6.f90 execution test FAIL: gfortran.dg/char_result_6.f90 execution test FAIL: gfortran.dg/char_result_6.f90 execution test FAIL: gfortran.dg/eor_handling_1.f90 execution test FAIL: gfortran.dg/eor_handling_1.f90 execution test FAIL: gfortran.dg/eor_handling_1.f90 execution test FAIL: gfortran.dg/eor_handling_1.f90 execution test FAIL: gfortran.dg/eor_handling_1.f90 execution test FAIL: gfortran.dg/eor_handling_1.f90 execution test FAIL: gfortran.dg/eor_handling_1.f90 execution test FAIL: gfortran.dg/fmt_read_bz_bn.f90 execution test FAIL: gfortran.dg/fmt_read_bz_bn.f90 execution test FAIL: gfortran.dg/fmt_read_bz_bn.f90 execution test FAIL: gfortran.dg/fmt_read_bz_bn.f90 execution test FAIL: gfortran.dg/fmt_read_bz_bn.f90 execution test FAIL: gfortran.dg/fmt_read_bz_bn.f90 execution test FAIL: gfortran.dg/fmt_read_bz_bn.f90 execution test FAIL: gfortran.dg/fmt_white.f execution test FAIL: gfortran.dg/fmt_white.f execution test FAIL: gfortran.dg/fmt_white.f execution test FAIL: gfortran.dg/fmt_white.f execution test FAIL: gfortran.dg/fmt_white.f execution test FAIL: gfortran.dg/fmt_white.f execution test FAIL: gfortran.dg/fmt_white.f execution test FAIL: gfortran.dg/fmt_zero_digits.f90 execution test FAIL: gfortran.dg/fmt_zero_digits.f90 execution test FAIL: gfortran.dg/fmt_zero_digits.f90 execution test FAIL: gfortran.dg/fmt_zero_digits.f90 execution test FAIL: gfortran.dg/fmt_zero_digits.f90 execution test FAIL: gfortran.dg/fmt_zero_digits.f90 execution test FAIL: gfortran.dg/fmt_zero_digits.f90 execution test FAIL: gfortran.dg/inquire_6.f90 execution test FAIL: gfortran.dg/inquire_6.f90 execution test FAIL: gfortran.dg/inquire_6.f90 execution test FAIL: gfortran.dg/inquire_6.f90 execution test FAIL: gfortran.dg/inquire_6.f90 execution test FAIL: gfortran.dg/inquire_6.f90 execution test FAIL: gfortran.dg/inquire_6.f90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_2.F90 execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 execution test FAIL: gfortran.dg/large_real_kind_form_io_2.f90 execution test FAIL: gfortran.dg/list_read_5.f90 execution test FAIL: gfortran.dg/list_read_5.f90 execution test FAIL: gfortran.dg/list_read_5.f90 execution test FAIL: gfortran.dg/list_read_5.f90 execution test FAIL: gfortran.dg/list_read_5.f90 execution test FAIL: gfortran.dg/list_read_5.f90 execution test FAIL: gfortran.dg/list_read_5.f90 execution test FAIL: gfortran.dg/namelist_11.f execution test FAIL: gfortran.dg/namelist_11.f execution test FAIL: gfortran.dg/namelist_11.f execution test FAIL: gfortran.dg/namelist_11.f execution test FAIL: gfortran.dg/namelist_11.f execution test FAIL: gfortran.dg/namelist_11.f execution test FAIL: gfortran.dg/namelist_11.f execution test FAIL: gfortran.dg/namelist_14.f90 execution test FAIL: gfortran.dg/namelist_14.f90 execution test FAIL: gfortran.dg/namelist_14.f90 execution test FAIL: gfortran.dg/namelist_14.f90 execution test
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #3 from dir at lanl dot gov 2006-05-22 14:58 --- I grabbed one of the tests that failed and tried it with today's 4.2.0 version and version 4.1.1 and it failed with the new and passed with the old - [dranta:~/tests/gfortran-D] dir% gfortran -O1 -o write_logical write_logical.f90 [dranta:~/tests/gfortran-D] dir% write_logical At line 9 of file write_logical.f90 Fortran runtime error: Missing initial left parenthesis in format [dranta:~/tests/gfortran-D] dir% cat write_logical.f90 ! PR 14334, L edit descriptor does not work ! ! this test uses L1 and L4 to print TRUE and FALSE logical true,false character*10 b true = .TRUE. false = .FALSE. b = '' write (b, '(L1)') true if (b(1:1) .ne. 'T') call abort b = '' write (b, '(L1)') false if (b(1:1) .ne. 'F') call abort b = '' write(b, '(L4)') true if (b(1:4) .ne. ' T') call abort b = '' write(b, '(L4)') false if (b(1:4) .ne. ' F') call abort end [dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.6.0 Configured with: ../gcc/configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.2.0 20060522 (experimental) [dranta:~/tests/gfortran-D] dir% set path =(~/gfortran4.1/bin $path) [dranta:~/tests/gfortran-D] dir% gfortran -O1 -o write_logical write_logical.f90 [dranta:~/tests/gfortran-D] dir% write_logical [dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.6.0 Configured with: ../gcc/configure --prefix=/Users/dir/gfortran4.1 --enable-languages=c,f95 Thread model: posix gcc version 4.1.1 20060517 (prerelease) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #4 from dir at lanl dot gov 2006-05-22 20:51 --- There is no problem on LINUX or the Intel Macintosh version - only having trouble with the powerPC version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
[Bug fortran/27683] Many new GFORTRAN testsuite failures
--- Comment #1 from pault at gcc dot gnu dot org 2006-05-21 13:49 --- Dale, This looks like a library problem. Jerry committed a change that might have required a completely clean tree to build. I had no trouble with the trunk of two hours ago on FC5/Athlon. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
