[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2007-07-09 08:15 --- Note: The program fails with call sub(c+f()) where c is a parameter and dimensions of c and f are (2,2). If one has dimension(2) it works. Working with 2007-05-08-r124539, failing with 2007-05-09-r124566. The follwing has been checked in during that time: r124550 | pault | 2007-05-08 16:40:58 +0200 (Tue, 08 May 2007) | 7 lines PR 31630 * resolve.c (resolve_symbol): Remove the flagging mechanism from the... r124546 | pault | 2007-05-08 14:45:31 +0200 (Tue, 08 May 2007) | 11 lines PR 31692 * trans-array.c (gfc_conv_array_parameter): Convert full array references to the result of the procedure enclusing the call. r124541 | pault | 2007-05-08 13:58:25 +0200 (Tue, 08 May 2007) | 18 lines PR 29397, PR 29400 * decl.c (add_init_expr_to_sym): Expand a scalar initializer for a parameter array into an array expression with the right shape. * array.c (spec_dimen_size): Remove static attribute. * gfortran.h : Prototype for spec_dimen_size. http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00406.html I think the last-shown commit caused the regression. -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
[Bug fortran/32704] New: -static-libgfortran is undocumented
PR 31400 added -static-libgfortran, but a documentation is missing. (One should probably also update http://gcc.gnu.org/wiki/GFortranGettingStarted) -- Summary: -static-libgfortran is undocumented Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32704
[Bug fortran/32646] INQUIRE (by UNIT) for (un)formatted always returns YES...
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2007-07-06 13:50 --- I think this is invalid. The normative words are, from 9.6.1.11 The scalar-default-char-variable in the FORMATTED= specifier is assigned the value YES if FORMATTED is included in the set of allowed forms for the file, NO is FORMATTED is not included in the set of allowed forms for the file, and UNKNOWN if the processor is unable to determine whether or not FORMATTED is included in the set of allowed forms for the file. gfortran/g95: yes, yes openf95/ifort: no, yes NAG f95: unknown, yes I think NAG's answer is most correct: It formatted=Yes as it seemingly works (the file is open) while one does not know whether it can be opened as unformatted. ifort/openf95 simply assume it cannot be whereas g95/gfortran assume that one can do so. If the file is empty the answer YES is correct. If the file is not empty, reading a formatted file as unformatted will probably not work, but still it may work. I personally regard this part of the inquiry function as useless. See also: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/30719cf69f699d34 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32646
[Bug middle-end/32006] New: [Regression 4.3] ICE (segv) with
Using test_fpu.f90 of the Polyhedron testsuite, http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html, fails since 2007-05-15 (r124736) on x86_64-unknown-linux-gnu, 2007-05-14 (r124708) was still ok. Last tested: 2007-05-20 (r124860). The ICE occures with: gfortran -O3 -ftree-vectorize -ffast-math -funroll-loops test_fpu.f90 With -m32 the ICE does not occure. Running GCC through valgrind shows: ==30881== Conditional jump or move depends on uninitialised value(s) ==30881==at 0x7A2E38: vrp_evaluate_conditional_warnv (tree-vrp.c:4803) ==30881==by 0x7A34D9: vrp_evaluate_conditional (tree-vrp.c:4935) ==30881==by 0x76488B: substitute_and_fold (tree-ssa-propagate.c:1131) ==30881==by 0x79E418: vrp_finalize (tree-vrp.c:5914) ==30881==by 0x7A006A: execute_vrp (tree-vrp.c:6000) ==30881==by 0x609540: execute_one_pass (passes.c:1065) ==30881==by 0x6096FB: execute_pass_list (passes.c:1117) ==30881==by 0x60970D: execute_pass_list (passes.c:1118) ==30881==by 0x6D3337: tree_rest_of_compilation (tree-optimize.c:406) ==30881==by 0x810D9F: cgraph_expand_function (cgraphunit.c:1086) ==30881==by 0x813241: cgraph_optimize (cgraphunit.c:1155) ==30881==by 0x466F5C: gfc_be_parse_file (f95-lang.c:307) -- Summary: [Regression 4.3] ICE (segv) with Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32006
[Bug middle-end/31935] [Regression 4.3] ICE with -O3 -ftree-loop-linear -ftree-vectorize
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2007-05-20 10:03 --- The problem disappeared meanwhile: 4.3.0 20070519 is no longer crashing :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31935
[Bug fortran/29713] New: ICE [regression, trunk, 4.2]: in gfc_set_constant_character_len decl.c:762
This is with: gcc 42 r118474 *and* gcc-trunk r118474 on x86_64. gfortran.dg/constant_substring.f fails with: constant_substring.f:0: internal compiler error: Aborted Minimal testcase: character*2 a character*4 b parameter (a=12) parameter (b = a(1:2)) end Backtrace (with trunk): Breakpoint 2, 0x2ae861d6f880 in abort () from /lib64/libc.so.6 (gdb) bt #0 0x2ae861d6f880 in abort () from /lib64/libc.so.6 #1 0x2ae861daa920 in malloc_printerr () from /lib64/libc.so.6 #2 0x0041466f in gfc_set_constant_character_len (len=0, expr=0xdd46a0) at /home/tob/projects/gcc/gcc/fortran/decl.c:762 #3 0x00414869 in gfc_match_parameter () at /home/tob/projects/gcc/gcc/fortran/decl.c:3825 #4 0x0043fdd3 in match_word (str=0xd97700 12, subr=0x4146e0 gfc_match_parameter, old_locus=0x7fff493fd560) at /home/tob/projects/gcc/gcc/fortran/parse.c:65 #5 0x00440529 in decode_statement () at /home/tob/projects/gcc/gcc/fortran/parse.c:254 #6 0x00440d6b in next_statement () at /home/tob/projects/gcc/gcc/fortran/parse.c:493 #7 0x00442b6c in parse_spec (st=ST_PARAMETER) at /home/tob/projects/gcc/gcc/fortran/parse.c:1869 #8 0x00443036 in parse_progunit (st=14251776) at /home/tob/projects/gcc/gcc/fortran/parse.c:2870 #9 0x00443560 in gfc_parse_file () at /home/tob/projects/gcc/gcc/fortran/parse.c:3206 #10 0x0046031e in gfc_be_parse_file (set_yydebug=value optimized out) at /home/tob/projects/gcc/gcc/fortran/f95-lang.c:305 #11 0x007634f3 in toplev_main (argc=value optimized out, argv=value optimized out) at /home/tob/projects/gcc/gcc/toplev.c:1033 #12 0x2ae861d5bae4 in __libc_start_main () from /lib64/libc.so.6 #13 0x00404f59 in _start () -- Summary: ICE [regression, trunk, 4.2]: in gfc_set_constant_character_len decl.c:762 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29713
[Bug fortran/29713] ICE [regression, trunk, 4.2]: in gfc_set_constant_character_len decl.c:762
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-11-04 17:24 --- Fix: Reverting the change in gcc/fortran/expr.c of the following patch (which I don't understand): r118338 | fxcoudert | 2006-10-31 21:15:22 +0100 (Tue, 31 Oct 2006) | 12 lines PR fortran/29067 * expr.c (gfc_simplify_expr): NULL-terminate the substring character constant. --- expr.c (revision 118337) +++ expr.c (revision 118338) @@ -1438,7 +1438,7 @@ gfc_extract_int (p-ref-u.ss.end, end); s = gfc_getmem (end - start + 1); memcpy (s, p-value.character.string + start, end - start); - s[end] = '\0'; /* TODO: C-style string for debugging. */ + s[end-start+1] = '\0'; /* TODO: C-style string for debugging. */ gfc_free (p-value.character.string); p-value.character.string = s; p-value.character.length = end - start; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29713
[Bug other/29717] New: Make pdf fails, make info/html works; invoke.texi:1079: @include @value{srcdir}
Current SVN trunk.
gcc-build/gcc make info
gcc-build/gcc make html
works, however:
gcc-build/gcc make pdf
texi2pdf -I . -I /home/tob/projects/gcc/gcc/doc -I
/home/tob/projects/gcc/gcc/doc/include -o doc/gcc.pdf
/home/tob/projects/gcc/gcc/doc/gcc.texi
[...]
/home/tob/projects/gcc/gcc/doc/invoke.texi:1079: I can't find file `'.
to be read again
@begingroup
@value -@begingroup
@makevalueexpandable @valuexxx
@temp -@input @value
{srcdir}/../libiberty/at-file.texi
@includezzz ...mp [EMAIL PROTECTED] #1 [EMAIL PROTECTED] [EMAIL PROTECTED]
@popthisfilestack
l.1079 [EMAIL PROTECTED]/../libiberty/at-file.texi
Please type another input file name:
The line is:
@include @value{srcdir}/../libiberty/at-file.texi
--
Summary: Make pdf fails, make info/html works; invoke.texi:1079:
@include @value{srcdir}
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29717
[Bug fortran/29677] minimally informative gfortran -fbounds-check
--- Comment #4 from tobias dot burnus at physik dot fu-berlin dot de 2006-11-01 14:01 --- This has been fixed in the meanwhile. (Don't forget, gfortran is not that old.) Possibilities: - Use a GCC 4.1 branch build (newer than 4.1.1) - Use a GCC 4.2 branch build - Use a GCC 4.3 trunk build For openSUSE 10.x and SLED/SLES exist such packages (made by SUSE), for SL/SLES/SLED 9.x unfortunally not. I would suggest to download a gfortran 4.2 or gfortran 4.3 build, both available e.g. at http://www.physik.fu-berlin.de/~tburnus/gcc-trunk/ You probably need also lib64-gmp4.2.1-mpfr2.2.0.tar.gz * * * Alternatively, run the program in gdb: gdb ./yourExecutable (gdb) b _exit Function _exit not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (_exit) pending. (gdb) run [...] (gdb) bt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29677
[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-31 21:37 --- Steve Lionel from Intel wrote http://groups.google.com/group/comp.lang.fortran/tree/browse_frm/thread/062ce3447e5ef570/7e2c6b5723c3b228#doc_a7f0b804f755e27b For a record length greater than 2,147,483,639 bytes, the record is divided into subrecords. The subrecord can be of any length from 1 to 2,147,483,639, inclusive. The sign bit of the leading length field indicates whether the record is continued or not. The sign bit of the trailing length field indicates the presence of a preceding subrecord. The position of the sign bit is determined by the endian format of the file. A subrecord that is continued has a leading length field with a sign bit value of 1. The last subrecord that makes up a record has a leading length field with a sign bit value of 0. A subrecord that has a preceding subrecord has a trailing length field with a sign bit value of 1. The first subrecord that makes up a record has a trailing length field with a sign bit value of 0. -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added CC||tobias dot burnus at physik ||dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug fortran/29625] Octal edit descriptors allow real variables, even with -std=f95
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-28 13:34 --- Probably the same for binary and hexadecimal? io/transfer.c(formatted_transfer_scalar): case FMT_O: seems to be a good place for adding notify_std (dtp-common, GFC_STD_GNU,...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29625
[Bug fortran/29267] different length non-constant strings in array constructors ICE
--- Comment #14 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-28 13:09 --- Do g95 and ifort also compile the original testcase and do The Right Thing? No. g95 has a run-time error, ifort garbage at the beginning (but no crash); f95 and sunf95 don't compile. gfortran: ICE for x, for x: compiles, but garbage (extra 1.000) at run time, for x//31characters: ok like all the other compilers g95 ice29267.f90 ./a.out Fortran runtime error: Inconsistent string size in array constructor ifort ice4.f90 ./a.out # with print *, a: xw~D##65533;*'@x$#65533; 1.000 NAGf95: Array constructor values have differing CHARACTER lengths (1 and 32) sunf95: Line = 3, Column = 23: ERROR: Array constructor values of type character must all have the same length. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29578] inquire(...) returns formatted==YES for unreadable and unformatted files
--- Comment #4 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-27 08:06 --- Close as invalid then. -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29578
[Bug fortran/29616] New: Run-time check using nullified pointers
I think there are essentially two problems possible with pointers: (a) Uninitialized pointer (i.e. neither NULL nor associated) (b) Using an unassociated pointer I think checking (a) is not easily doable as one would need to pass this status (has been initialized? yes/no) on to subroutines. (NAG f95 does so, but one needs to compile all parts of the program with this option as the variable status is passed on to the subroutines. This -C=uninitialized options is still great to find uninitialized variables, esp. those (e.g. integer) which can not be pre-autoinitialized by NaN.) Thus this is a request for enhancement for the second type. Example: program pointtest implicit none real, pointer :: r nullify(r) call foo(r) ! Error one r = 5.0 ! Error two contains subroutine foo(bar) real, target, intent(in) :: bar ! The error occures already here and not in the next line! print *, bar end subroutine foo end program pointtest Both are caught by NAG f95 with -C=pointer and by ifort with -check pointer: Reference to disassociated POINTER R and forrtl: severe (408): fort: (7): Attempt to use pointer R when it is not associated with a target However, the error analysis could be improved for both: Ifort gives a trace, but even with -g it does not show where. NAG at least coredumps and thus one can find out where it crashes: gdb - bt ... #3 0x2af4962e5e1a in __NAGf90_badptr1 () from /opt/nag/lib/libf98.so.1 #4 0x00403338 in main (argc=1, argv=0x7fff14a00578) at pointest.f90:6 We should try to find something, which is easily debuggable (e.g. spitting out the file and line number?). If we say that the user should use gdb himself [as we used to with boundary check], then we should at least tell, were to set the break point [unless we coredump, the one can use bt]. At least I didn't found it obvious to set a break point at exit__ (or something like that), which was also in a library not loaded when loading the program in gdb. Well, fortunally -fbounds-check now prints file and line :-) (The two pointer tests of Polyhedron's diagnotic check, by the way, only the first type.) -- Summary: Run-time check using nullified pointers Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29616
[Bug fortran/29267] different length non-constant strings in array constructors ICE
--- Comment #12 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-26 20:29 --- why is there no problem with this code? PROGRAM test_constructor CHARACTER(len=32), DIMENSION(1,2) :: a a = reshape((/ one arg, another arg /), (/ 1, 2 /)) END PROGRAM Because this doesn't trigger the buggy codepath :-) Sometime in the past someone went to some lengths to support this kind of invalid code. Had they read the standard closely, they could have saved themselves some work. The question is whether one wants to support such code or not? NAG f95 gives an error even with -dusty. sunf95 gives an error. g95 and ifort compile by default, but with -std=f95 / -stand f95 the give an error / warning (respectively). gfortran does not give such warning/error. See also: bug 27998 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29578] New: inquire(...) returns formatted==YES for unreadable and unformatted files
Inquire returns for formatted YES for the following cases: - not opened file, which is not readable. How should gfortran know? - opened or unopend, finite-size unformatted file. This is clearly wrong. Test program attached -- Summary: inquire(...) returns formatted==YES for unreadable and unformatted files Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29578
[Bug fortran/29578] inquire(...) returns formatted==YES for unreadable and unformatted files
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-24 12:27 --- Created an attachment (id=12482) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12482action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29578
[Bug fortran/29578] inquire(...) returns formatted==YES for unreadable and unformatted files
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-24 13:31 --- I'm actually not any more sure what is meant by formatted in inquire(). The Fortran 2003 standard says: The scalar-default-char-variable in the FORMATTED= specifier is assigned the value YES if FORMATTED is included in the set of allowed forms for the file, NO if FORMATTED is not included in the set of allowed forms for the file, and UNKNOWN if the processor is unable to determine whether or not FORMATTED is included in the set of allowed forms for the file. What makes an UNFORMATTED file allowed for FORMATTED access? Currently, the check is (libgfortran/io/unix.c; inquire_formatted): Empty string/file does not exist: UNKNOWN Directory: NO Regular file, block device, character device, pipe: YES. Is YES what one would expect for a binary file? Ifort writes NO if one has open()ed an unformatted file [and simply UNKNOWN otherwise]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29578
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #12 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-23 18:52 --- Cf. also bug 29471. In the Intel Fortran Compiler real :: r data r/some BOZ/ gives the same result as using the Fortran 2003 statement in ifort: real :: r r = real(some boz) (At least with the -switch fe_new_BOZ_constants.) Therefore, with Fortran 2003 BOZ support in place, implementing this in gfortran should then become easier. (Working around will also become easier.( (As gfortran accepts [integer] BOZ everywhere, it will also have the problem whether real( z'F' ) is meant as convert integer BOZ to integer and then to real or as convert real BOZ to real. Ifort gives a default warning for both -stand f95 and -stand f03, treating the BOZ differently for those two cases.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug fortran/29549] New: matmul slow for complex matrices
Comparison by Francois-Xavier: http://www.eleves.ens.fr/home/coudert/timing.png (bottom row: complex numbers; black gfortran matmul, others: optimized libraries). See also http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00343.html -- Summary: matmul slow for complex matrices Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29549
[Bug fortran/29550] New: Optimize -fexternal-blas calls for transpose()/conj()
Often, matrix multiplications contain transpose() or conj(), e.g. matmul(transpose(A),B) or matmul(A,conj(transpose(B)) matmul(A,transpose(conj(B)) The *gemm subroutines of BLAS anticipate this via the TRANSA and TRANSB options: - 'N' (unchanged) - 'T' (transpose) - 'C' (hermitian conjugate / transpose+complex conjugate) Thus for -fexternal-blas these extra options should be used, if possible. -- Summary: Optimize -fexternal-blas calls for transpose()/conj() Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550
[Bug fortran/29505] New: Should give an error when using: real :: r; r(j) = ...
The following program compiles in gfortran. I don't know how easily it could be detected, but defining a scalar and using it as an array should be detectable? For what it is worth: ifort also does not detect this error. Changing the integer :: j = 1 into integer :: j; j = 1 causes gfortran to emit an error: Unexpected STATEMENT FUNCTION statement (and also ifort now writes: This name has not been declared as an array or a function.) program bug implicit none real :: del integer :: j = 1 del(j)=sin(10.0) print *, del(3) end -- Summary: Should give an error when using: real :: r; r(j) = ... Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29505
[Bug fortran/29505] Should give an error when using: real :: r; r(j) = ...
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-18 21:11 --- Yes, you are right. I somehow missed those. 12.5.4 Statement function A statement function is a function defined by a single statement. R1238 stmt-function-stmt is function-name ( [ dummy-arg-name-list ] ) = scalar-expr -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29505
[Bug fortran/29452] Keyword check for specifiers in WRITE, READ and OPEN/CLOSE
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-17 15:31 ---
The library problems are due to an error in the string comparison; one only
compares the first (fortran string length) characters, but never checks whether
the strings are of identical length.
Patch:
Index: libgfortran/runtime/string.c
===
--- libgfortran/runtime/string.c(revision 117796)
+++ libgfortran/runtime/string.c(working copy)
@@ -44,6 +44,7 @@
/* Strip trailing blanks from the Fortran string. */
len = fstrlen (s1, s1_len);
+ if(len != strlen(s2)) return 0; /* don't match */
return strncasecmp (s1, s2, len) == 0;
}
Similarly for WRITE(*,*,ADVANCE='YES/NO'):
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c(revision 117796)
+++ gcc/fortran/io.c(working copy)
@@ -2697,8 +2697,8 @@
if (expr-expr_type == EXPR_CONSTANT expr-ts.type == BT_CHARACTER)
{
const char * advance = expr-value.character.string;
- not_no = strncasecmp (advance, no, 2) != 0;
- not_yes = strncasecmp (advance, yes, 2) != 0;
+ not_no = strcasecmp (advance, no) != 0;
+ not_yes = strcasecmp (advance, yes) != 0;
}
else
{
I will submit a patch in the next days.
(The other suggested checks for READ/WRITE are not yet needed as those options
are not supported, yet.
I don't know in how far strcasencmp problems occurre at other places as well.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29452
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-16 13:34 --- Note that there is a change in meaning: BOZ-everywhere extension: a = real(z'F') is the same as real(int(z'F')) = 15.0 (This is what gfortran does and Intel does by default) Fortran 2003: a = real(z'F') = 2.1019477E-44 Intel gives a default warning in such cases: fortcom: Warning: boz2.f90, line 2: The Fortran 2003 Standard will use this bit pattern directly and NOT convert it to REAL as if it were an INTEGER constant (try -switch fe_new_BOZ_constants). a = real(z'F') ^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-16 17:12 --- (In reply to comment #2) Fortran 2003: a = real(z'F') = 2.1019477E-44 Are you sure this is the only correct value? The F2003 says nothing about the other 28 bits. It also says nothing about whether z'F' applies to most significant bits or least significant bits of the 32-bit real. Well, that is the value ifort gave me (using -switch fe_new_BOZ_constants); I think it is a valid value, but I'm not sure whether it is the only one. As NAG f95, g95 and sunf95 do not yet support F2003's BOZ, I cannot compare with what they give. I also found the F2003 standard not so detailed, but maybe I missed the right spot. Best to ask at comp.lang.fortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] New: Warn with -std=f95/f2003 when BOZ is used at invalid places
gfortran allows everywhere to use a BOZ. However, there are constrains in Fortran 95 and 2003 on where to use them. - Fortran 95: Only in DATA and only integer - Fortran 2003: Only in DATA or as argument of INT, REAL, DBLE, CMPLX Expected: An ERROR (or WARNING) is shown, when -std=f95/f2003 is used. Fortran 95: R407 boz-literal-constant [...] Constraint: A boz-literal-constant may appear only in a DATA statement.[...] If a data-statement-constant is a boz-literal-constant, the corresponding object shall be of type integer. Fortran 2003: C410 (R411) A boz-literal-constant shall appear only as a data-stmt-constant in a DATA statement, as the actual argument associated with the dummy argument A of the numeric intrinsic functions DBLE, REAL or INT, or as the actual argument associated with the X or Y dummy argument of the intrinsic function CMPLX. -- Summary: Warn with -std=f95/f2003 when BOZ is used at invalid places Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29452] New: Do compile-time specifier checks for WRITE and READ
http://gcc.gnu.org/ml/fortran/2006-10/msg00241.html adds compile-time checking for the specifier arguments of CLOSE and OPEN. This should be done analogously for (cf. 9.5.1 in Fortran 2003) WRITE/READ (some only in READ allowed; some sre not yet implemented in gfortran): - ADVANCE: 'YES', 'NO' - ASYNCHRONOUS: 'YES', 'NO' - BLANK: 'NULL', 'ZERO' - DECIMAL: 'COMMA', 'POINT' - DELIM: 'APOSTROPHE', 'QUOTE', 'NONE - PAD: 'YES', 'NO' - ROUND: 'UP', 'DOWN', 'ZERO', 'NEAREST', 'COMPATIBLE'. 'PROCESSOR_DEFINED' - SIGN: PLUS, SUPPRESS, PROCESSOR_DEFINED -- Summary: Do compile-time specifier checks for WRITE and READ Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29452
[Bug fortran/29453] New: [g77 support] chmod intrinsic function not implemented in gfortran
I don't know whether anyone needs this, but g77 has according to
http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77.pdf
this intrinsic function whereas gfortran only provides the subroutine.
program chmod_test
implicit none
intrinsic chmod
integer :: status
call chmod('test.dat','u=rwx',status)
print *, 'Status: ', status
print *, 'Status: ', chmod('test.dat','u=rwx')
end program chmod_test
--
Summary: [g77 support] chmod intrinsic function not implemented
in gfortran
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29453
[Bug fortran/29452] Keyword check for specifiers in WRITE, READ and OPEN/CLOSE
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-13 10:13 --- Some tests show: open(13,file='foo',form='format') close(13,status='del') compiles and runs in gfortran. Expected: - A run-time error is shown. - A compile-time-error is shown (probably fixed by FX patch, not checked) * * * write(13,'(a)',advance='N') 'Hello:' This gives a compile-time error, whereas str = 'N' write(13,'(a)',advance=str) 'Hello:' gives not a run-time error. write(13,'(a)',advance='Not') 'Hello:' gives no compile-time error, but a run-time error. -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added Summary|Do compile-time specifier |Keyword check for specifiers |checks for WRITE and READ |in WRITE, READ and ||OPEN/CLOSE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29452
[Bug fortran/29403] New: print ('(a)') not working, print '(a) works
From http://gcc.gnu.org/ml/fortran/2006-10/msg00274.html
gfortran shows:
print ('(z20.8)'), i
1
Error: Syntax error in PRINT statement at (1)
The (optional) parentheses are allow (see below) and it works in ifort, NAG f95
and g95.
From Fortran 2003 standard Section 9.5 and 9.5.1.1:
R911 write-stmt is WRITE (io-control-spec-list) [output-item list]
R912 print-stmt is PRINT format[, output-item-list]
where format is:
R914 format is default-char-expr
or label
or *
Note that default-char-expr is:
R726 default-char-expr is expr
C707 (R726) default-char-expr shall be of type default character.
If one goes through all the expr, level-5-expr, ... one ends up at
R701 primary is constant
[...]
or ( expr )
In other words: A default-char-expr may have parentheses around.
--
Summary: print ('(a)') not working, print '(a) works
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29403
[Bug fortran/29407] New: namelist: overriding the host association does not work (rejects valid code)
--- program main implicit none contains subroutine my end subroutine my subroutine bar integer :: my namelist /ops/ my end subroutine bar end program main --- gives in gfortran the error message: namelist /ops/ my 1 Error: PROCEDURE attribute conflicts with NAMELIST attribute in 'my' at (1) With other compilers it works and Brooks Moses writes: Gfortran is wrong. The INTEGER declaration in BAR declares MY as a local variable, thus overriding the host association of MY as the subroutine from the main program. Thus, as far as NAMELIST is concerned, this is an ordinary integer variable. -- Summary: namelist: overriding the host association does not work (rejects valid code) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29407
[Bug fortran/29383] New: Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support
See chapter 14 of the Fortran 2003 standard.
Example, cf.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/642578db8949fd2f
--
program ieee
use,intrinsic :: ieee_arithmetic
implicit none
if(.not. IEEE_support_standard(1.0d0)
.or. .not.IEEE_support_halting(IEEE_INVALID)
.or. .not.IEEE_support_halting(IEEE_DIVIDE_BY_ZERO))
stop 'No IEEE support available!'
call ieee_set_halting_mode([IEEE_INVALID, IEEE_DIVIDE_BY_ZERO],
.false.)
call printLog(1.0d0)
call printLog(0.0d0)
call printLog(-1.0d0)
call printLog(2.0d0)
contains
subroutine printLog(x)
double precision, intent(in) :: x
double precision :: y
y = log(x)
if(.not. ieee_is_finite(y)) then
write(*,*) 'Ignoring calculation for x = ', x,'; result is: ',y
else
print *, 'Result is: log(',x,') = ',y
end if
end subroutine printLog
end program ieee
--
Expected result (NAG f95 gives the following):
Result is: log( 1. ) =0.
Ignoring calculation for x =0. ; result is:
-Infinity
Ignoring calculation for x = -1. ; result is: NaN
Result is: log( 2. ) =0.6931471805599453
Warning: Floating invalid operand occurred
Warning: Floating divide by zero occurred
--
Summary: Fortran 2003/F95[TR15580:1999]: Floating point exception
(IEEE) support
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383
[Bug fortran/29371] New: Coredump when using -fbounds-check with pointer nullify
The following program coredumps at nullify() when compiled with -fbounds-check, otherwise it does work as supposed. If I remove one of the nullify()s or remove the loop, it works ok. - program test implicit none type projector_t real, pointer :: ket(:, :), bra(:, :) end type projector_t type(projector_t),pointer, dimension(:) :: p integer :: stat,i allocate(p(2),stat=stat) print *, 'state = ',stat do i = 1, 2 nullify(p(i)%bra) nullify(p(i)%ket) end do end program - -- Summary: Coredump when using -fbounds-check with pointer nullify Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29371
[Bug fortran/29364] New: No error given if using a non-defined type in a type definition
If one compiles - module test implicit none type epot_t integer :: c type(nonexist),pointer :: l end type epot_t end module test - no error (and no warning) is shown. If one removes the keyword pointer, the error message Derived type at (1) has not been previously defined is shown. Expected: Also for pointers, such a message is shown! (ifort, g95, NAG f95 all give an error.) -- Summary: No error given if using a non-defined type in a type definition Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29364
[Bug fortran/27588] -fbounds-check should catch substring out of range accesses
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-02 15:15 --- From Francois-Xavier Coudert 2006-06-08 I'm writing a patch to add substring bounds checking. I hope to post it in the next few days. What is the status? If you have something, I'd save my time of looking at trans-expr.c's gfc_conv_substring and trying to understand how to add it there. Looking at http://www.polyhedron.com/pb05/linux/diagnose.html, this seems to be the last area where gfortran is worse than all others. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27588
[Bug fortran/29277] New: Formated stream output: Translate \n / achar(10) into \r\n on some platforms
See http://gcc.gnu.org/ml/fortran/2006-09/msg00415.html Brooks Moses wrote: when a file is connected for stream access, the runtime library could very easily do a s/\n/\r\n/ on the output stream before writing it to the file. In fact, if we consider \r\n to be a record marker (on a given system), and we do wish to implement the behavior described in this paragraph [10.6.3] then it would be required to do so. Actually, now that I read section 9.2.2.3 (and particularly note 9.9) on the Fortran 2003 Standard, I'm pretty sure it was the intent of the standard committee that this sort of substitution be done. Note 9.9 states: There may be some character positions in the file that do not correspond to characters written; this is because on some processors a record marker may be written to the file as a carriage-return/linefeed or other sequence. The means of determining the position in a file connected for stream access is via the POS= specifier in an INQUIRE statement (9.9.1.21). Note, in particular, that this whole matter only applies to _formatted_ stream files -- that is, files which are expected to contain human-readable text that could be edited in a text editor. For unformatted stream files -- which are the only ones that should be containing binary data that would be corrupted by the substitution -- this doesn't apply, and no substitution would be made. Thus, I think it's pretty clear that NEW_LINE should return ACHAR(10), and that for formatted stream-access files, the runtime library should convert that character to the appropriate system-specific line-ending string when writing to files. (This substitution would not be a regression against g77, because files opened for stream access do not exist in g77 code, and the substitution would not be made for non-stream files.) -- Summary: Formated stream output: Translate \n / achar(10) into \r\n on some platforms Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29277
[Bug fortran/29232] New: No warning/error for duplicate construct name
The code MODULE test TYPE vertex INTEGER :: k END TYPE vertex CONTAINS SUBROUTINE S1() TYPE(vertex) :: a vertex : DO i=1,2 ENDDO vertex END SUBROUTINE END MODULE test is invalid Fortran code, but gfortran -std=f2003 -c -W -Wall label.f90 accepts it without any error or warning. Short reasoning (by Richard Main): Both [type(vertex), label vertex:] are class 1 local identifiers. Actually, almost everything is a class 1 local identifier. See the list of them in c16. You can't have 2 different class 1 entities with the same identifier See for the longer discussion: http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/a869ba11f828f208/6b95093a4a9bf34a#6b95093a4a9bf34a -- Summary: No warning/error for duplicate construct name Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29232
[Bug fortran/28494] Unclear run time error message
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-09-20 08:27 --- I looked what other are writing: gfortran: Fortran runtime error: Array reference out of bounds for array 'r', upper bound of dimension 1 exceeded (in file 'array2.f90', at line 4) NAG f95: Subscript 1 of R (value 5) is out of range (1:4) Intel Fortran Compiler ifort: forrtl: severe (408): fort: (2): Subscript #1 of the array R has value 5 which is greater than the upper bound of 4 Sun f95: ** FORTRAN RUN-TIME SYSTEM ** Subscript out of range. Location: line 4 column 5 of 'array2.f90' Subscript number 1 has value 5 in array 'R' Personal favourite would be: Fortran runtime error: Array reference out of bounds. Subscript 1 of array 'r' (value 5) exceeds upper bound of 4 (in file 'array2.f90', at line 4) The place to change would be trans-array.c. I looked at it, but I fail to extract a asprintf-able number from the trees index etc. -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added CC||tobias dot burnus at physik ||dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28494
[Bug fortran/23375] show location for runtime errors
--- Comment #9 from tobias dot burnus at physik dot fu-berlin dot de 2006-09-20 11:57 --- I think this is fixed. If there are other errors, not covered, one could still reopen this bug or create a new one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23375
[Bug fortran/27989] -fbounds-check should check for too small arrays on subroutine calls
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-09-10 19:23 --- Maybe this should not be done with -fbounds-check, but put into a different option. (NAG uses not -C=array but -C=call for this.) The reason is that some programs (e.g. Exciting.sf.net) passes an array(n-1) to a subroutine foo(n,b) with real :: b(n) but only accesses the first n-1 elements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27989
[Bug fortran/28276] EXPONENT() broken for real constants
--- Comment #5 from tobias dot burnus at physik dot fu-berlin dot de 2006-09-10 22:43 --- Can you try this patch? It required MPFR 2.2.0. Tested on openSUSE/AMD64 with current gfortran trunk + patch and mpfr-2.2.0-9. It works ok with kind = 4 and kind = 8. However, with kind = 10 I get a NaN for print *, scale (fraction (a), exponent (a)) / a My test case: integer, parameter :: k = 10 real(k), parameter :: one = 1.0_k real(k) :: a a = one print *, This ratio should be 1: print *, scale (fraction (a), exponent (a)) / a end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28276
[Bug fortran/28005] [4.1 only] gfortran: matmul produces wrong result
--- Comment #8 from tobias dot burnus at physik dot fu-berlin dot de 2006-08-24 19:43 --- *ping* -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28005
[Bug fortran/28809] [gfortran] internal compiler error: in gfc_conv_ss_descriptor, at fortran/trans-array.c:1265
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-08-22 21:08 --- Using gfortran 4.1.2 20060705 (prerelease) (SUSE Linux) and GNU Fortran 95 (GCC) 4.2.0 20060822 (experimental) it compiles and gives the output (from the program): det for matrices bigger than 4x4 not implemented John Chodera, I would really recommend to update to 4.1.x or to 4.2-snapshots as gfortran in GCC 4.0.x is rather buggy. See http://gcc.gnu.org/wiki/GFortranBinaries for binary GCC versions. In addition: As the NAG compiler points out: --- Error: Explicit interface required for DET from MAIN - argument A (no. 1) is an assumed-shape array --- The problem is that Fortran passes an array differently for A(*) or A(n) than for A(:). The latter is called assumed-shaped array and is an addition to Fortran 90 (the former also work with Fortran 77). In order to let the compiler know that you want to pass an assumed-shaped array, you need to either create a module, which contains the function det, or you put it below contains in the program section or you write an interface in the program section. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28809
[Bug fortran/20441] -finit-local-zero is missing from gfortran
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de 2006-08-20 20:51 --- Besides zero initialization (of Real, complex, integer, (what about logical?)), a initialization to a (signaling) NaN (for complex, real) would be also nice to find uninitialized variables. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20441
[Bug libfortran/27740] libgfortran should use versioned symbols
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de 2006-08-16 17:44 --- Isn't this fixed as Steve bumped 4.2/TRUNK to libgfortran.so.2 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27740
[Bug fortran/28662] New: fpp call of gfortran: -traditional-cpp versus newer macros like #x
See http://gcc.gnu.org/ml/fortran/2006-08/msg00145.html Currently gfortran calls cpp with the option -traditional-cpp. Using this option, newer macros like #define msg(x) print *, #x don't work (the #x causes the argument to be quoted). (See url/email for example.) I couldn't find any standard for fpp. I assume that it is only a Fortran-aware CPP, which is defined in the C99 standard (ISO/IEC 9899:1999, section 6.10.3.2 The # operator). I would expect that the newer constructs work by default with gfortran, or at least that one can force that mode. The first would simply mean to remove -traditional-cpp from the argument list. Other compilers: Sun Studio f95 and Intel Fortran Compiler both support #x by default. g95 and NAGware f95 seem to work as gfortran: msg(test) is converted into print *,#hello -- Summary: fpp call of gfortran: -traditional-cpp versus newer macros like #x Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28662
[Bug fortran/28662] fpp call of gfortran: -traditional-cpp versus newer macros like #x
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-08-09 18:10 --- One problem without using -tranditional-cpp is that some tokens in C are not tokens in Fortran so you could get the wrong result. This is why -tranditional-cpp is used. I though the -lang-fortran, which is passed (according to gfortran -###), takes care of this? There is no standard for Preprocessed Fortran Source at all. Well, that I assumed. But it is still (somehow) based on ISO C's preprocessor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28662
[Bug fortran/28655] New: [F2003] In/output: DECIMAL=/dp/dc; SIGN=/S/SP/SS BLANK=/PAD=; DELIM=; ENCODING=
(should block F2003 meta PR 20585) gfortran should support: - DECIMAL= 'COMMA' or 'POINT' specifier in OPEN, READ, WRITE and INQUIRE (9.4.5.5, 9.5.1.6 in F2003 standard) - DP and DC as edit descriptors (10.7.8) - SIGN= 'PLUS', 'SUPPRESS' or 'PROCESSOR_DEFINED' specifier for OPEN, WRITE and INQUIRE (9.4.5.14, 9.5.1.13) - SS, SP and S edit descriptors (10.7.4) - DELIM= 'APOSTROPHE', 'QUOTE' or 'NONE' also for WRITE (9.4.5.6, 9.5.1.7) - BLANK= 'NULL'/'ZERO' and PAD= 'YES'/'NO' specifiers: Now also for READ (9.4.5.10, 9.4.5.4; new: 9.5.1.5, 9.5.1.9) - ENCODING= 'DEFAULT'/'UTF-8' (open); 'UTF-8'/'UNDEFINED'/'UNKNOWN'/... for INQUIRE (9.4.5.7, 9.9.1.9) - program iotests implicit none character(len=45) :: a real, parameter :: pi = 3.14159265358979323846 ! write(*,'(f10.3,s,f10.3,sp,f10.3,ss,f10.3)',SIGN='PLUS') pi, pi, pi, pi ! write(*,'(f10.3,dc,f10.3,dp,f10.3)',DECIMAL='COMMA') pi, pi, pi ! write(6,*,delim='quote') 'Hello' open(99,file='test.dat',form='formatted',status='new') write(99,'(a)') 'hello' close(99) open(99,file=test.dat,form='formatted',status='old', PAD='YES',BLANK='NULL',ENCODING='DEFAULT') read(99,*,PAD='NO',BLANK='NULL') a close(99) end program iotests - The current diagnostic for 'sp' is strange: write(*,'(f10.3,dc,f10.3,f10.3)') pi, pi, pi 1 Warning: Positive width required in format string at (1) -- and -- Fortran runtime error: Nonnegative width required in format (f10.3,dc,f10.3,f10.3) ^ -- Summary: [F2003] In/output: DECIMAL=/dp/dc; SIGN=/S/SP/SS BLANK=/PAD=; DELIM=; ENCODING= Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28655
[Bug fortran/28585] New: Fortran 2003: Support NEW_LINE intrinsic
Currently, gfortran does not support the NEW_LINE intrinsic.
Expected: It is supported.
Testcase:
-
program newline
implicit none
WRITE(*,'(A)') 'This is record 1.'//NEW_LINE('A')//'This is record 2.'
end program newline
-
From Fortran 2003 standard:
13.7.85 NEW LINE (A)
Description. Returns a newline character.
Class. Inquiry function.
Argument. A shall be of type character. It may be a scalar or an array.
Result Characteristics. Character scalar of length one with the same kind type
parameter as A.
Result Value.
Case (i): If A is of the default character type and the character in
position of the ASCII collating sequence is representable in the default
character set, then the result is ACHAR(10).
Case (ii): If A is of the ASCII character type or the ISO 10646 character
type, then the result is CHAR(10,KIND(A)).
Case (iii): Otherwise, the result is a processor-dependent character that
represents a new line in output to files connected for formatted stream output
if there is such a character.
Case (iv): Otherwise, the result is the blank character.
--
Summary: Fortran 2003: Support NEW_LINE intrinsic
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28585
[Bug fortran/28339] gfortran misses a record from a format statement
--- Comment #8 from tobias dot burnus at physik dot fu-berlin dot de 2006-07-28 10:16 --- Resolution: FIXED Fixed on 4.2 What about 4.1.x? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28339
[Bug fortran/28484] New: system_clock with real-type count_rate does not compile
When compiling the following program, -- real :: cntrate call system_clock(count_rate=cntrate) end -- gfortran (4.2.0 20060725) shows the error: call system_clock(count_rate=cntrate) 1 Error: 'count_rate' argument of 'system_clock' intrinsic at (1) must be INTEGER Expected: No error is shown as the Fortran standard (quoting from Fortran 2003) allows this: 13.7.117 SYSTEM_CLOCK ([COUNT, COUNT_RATE, COUNT_MAX]) Arguments. COUNT (optional) shall be scalar and of type integer. COUNT RATE (optional) shall be scalar and of type integer or real. COUNT MAX (optional) shall be scalar and of type integer. -- Summary: system_clock with real-type count_rate does not compile Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28484
[Bug fortran/28276] EXPONENT() broken for real constants
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de 2006-07-17 17:54 --- (CC myself) I see the same problem for real(8) and for real(10) as for real = real(4), except for print *, scale (fraction (a), exponent (a)) / a where I get NaN with real(10) instead of the correct 1.0, which one gets for real and real(8). -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added CC||tobias dot burnus at physik ||dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28276
[Bug fortran/28353] ICE: Segmentation fault
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de 2006-07-12 06:30 --- Created an attachment (id=11863) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11863action=view) mpif.h (from MPICH) This file alone is not going to be able to reproduce this bug. Can you attach mpif.h also? INCLUDE 'mpif.h' Hmm, I though I checked that no other files are needed. Anyway, here it is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28353
[Bug fortran/28335] New: flush() / write() statement on closed units - error?
The Fortran 2003 standard declares: Every input/output statement except an OPEN, CLOSE, INQUIRE, or WAIT statement shall refer to a unit that is connected to a file gfortran does not give a run-time error. However, I don't know whether one should enforce the standard (and thus do this check). program test write(*,*) 'Hello' flush(6) ! preconnected unit (stdout) flush(99)! preconnected unit ! flush() ! invalid close(88) ! close preconnected unit close(88) ! close once more ! wait(88) ! not supported by gfortran flush(88) ! invalid write(88,*) 'This should also produce an error' ! end program test Expected: Like NAG f95 (or g95) Hello Unit 88 is not connected Program terminated by fatal I/O error In TEST, line 9 of flush.f90 -- Summary: flush() / write() statement on closed units - error? Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28335
[Bug fortran/28353] New: ICE: Segmentation fault
gfortran -c mpi_bc_all.f mpi_bc_all.F: In function 'mpi_bc_all': mpi_bc_all.F:276: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. GNU Fortran 95 (GCC) 4.2.0 20060711 (experimental) -- Summary: ICE: Segmentation fault Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28353
[Bug fortran/28353] ICE: Segmentation fault
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-07-11 23:01 --- Created an attachment (id=11862) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11862action=view) Test file: mpi_bc_all.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28353
[Bug fortran/28309] New: -std=f2003 and call flush()
If I compile the program --- program test write(*,*) 'Hello' call flush() end program test --- without options, it works. However, using -std=f2003: /tmp/cc4pdLnc.o: In function `MAIN__': flush.f90:(.text+0x77): undefined reference to `flush_' Expected: As flush is part of Fortran 2003, it should work. -- Summary: -std=f2003 and call flush() Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28309
[Bug fortran/28005] [4.1 only] gfortran: matmul produces wrong result
--- Comment #7 from tobias dot burnus at physik dot fu-berlin dot de 2006-07-05 09:23 --- The patch did not apply to 4.1, so I will have to submit a back port. Thanks, Paul. I think this is the most serious bug in gfortran 4.1.x as it silently produces wrong results. -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added Summary|[4.1 only] gfortran: mathmul|[4.1 only] gfortran: matmul |produces wrong result |produces wrong result http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28005
[Bug fortran/28245] New: Warn when having superflous comma after read() or write()
It would be nice if -Wall would warn that the syntax is wrong if one has a comma after write() or read() [see example below]. program test implicit none write(*,*), 'Hello' end program test Such commas are not part of the standard, though several compilers digest them happily, but not all. Thus it would be nice if such non-standard things could be found. NAG f95,e.g., stumbles over the ,: Error: test.f90, line 3: syntax error detected at )@, ***Malformed statement [f95 terminated - errors found by pass 1] -- Summary: Warn when having superflous comma after read() or write() Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28245
[Bug fortran/28245] Warn when having superflous comma after read() or write()
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-07-04 12:03 --- I reall should create a gfortran script which inclueds -std=f95 by default :-( LANG=C gfortran -std=f95 test.f90 In file test.f90:3 write(*,*), 'Hello' 1 Error: Extension: Comma before output item list at (1) is an extension -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28245
[Bug fortran/28224] New: gfortran should support namelist (nml) for internal file units
If I'm not completely mistaken, Fortran 2003 allows to read namelists from internal files whereas it was forbidden in Fortran 95. At least I find in the F95/2005 book (in the f95 section) that it is forbidden, but I cannot find it in the Fortran 2003 standard. And also Richard E Maine (http://www.codecomments.com/archive271-2005-3-438971.html) seems to recall that this restriction was dropped in Fortran2003. Currently: Error: Internal file at (1) is incompatible with namelist Expected: Allow this. For std=f95 you might want to spit out an error/warning, though. -- Summary: gfortran should support namelist (nml) for internal file units Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28224
[Bug fortran/27996] Compile time warn for: character(2) :: str = 'ABC' (expression truncated)
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-06-23 13:01 --- Additional remarks (which I forget to make): Both cases are valid Fortran as: (1) If the length of 'variable' is less than that of 'expr', the value of 'expr' is truncated from the right until it is the same length as the 'variable'. (2) If the length of 'variable' is greater than that of 'expr', the value of 'expr' is extended on the right with blanks until it is the same length as the variable. However, I still think it is useful to give a compile-time warning. This for example should produce a warning: program test character(20),parameter :: path = 'mypath/' character(20),parameter :: file = path // 'myfile.txt' print *, trim(file) end program test whereas using trim(path) // 'myfile.txt' should not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27996
[Bug fortran/28129] New: gfortran -fbounds-check: Shows invalid array out of bounds error
(This PR should probably added as dependency to bug 27766) This is with my GCC/gfortran build x86_64-2006-06-21-r114837. If I run the following program, which I think is completely valid, with gfortran -fbounds-check I get: Fortran runtime error: Array reference out of bounds, upper bound of dimension 2 exceeded (in file 'gftest.f90', around line 2) However, I think the program (see below) is completely valid and it also works flawlessly with all checks turned on with NAG f95 and ifort. (And with gfortran and no checks it does not crash.) - subroutine wavefmt(ld,wfmt) implicit none integer, intent(in) :: ld complex(8), intent(out) :: wfmt(ld,*) wfmt(:,1)=0.d0 end subroutine wavefmt program test implicit none integer, parameter :: lmmaxvr = 64, nrcmtmax = 107 complex(8), allocatable :: wfmt1(:,:) allocate(wfmt1(lmmaxvr,nrcmtmax)) call wavefmt(lmmaxvr,wfmt1) end program test - -- Summary: gfortran -fbounds-check: Shows invalid array out of bounds error Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28129
[Bug fortran/28105] New: Check for memory allocations bigger than size_t
sizeof(size_t) on ia32 is 4 thus 2^32 = 4,294,967,296 Byte can be accessed by unsigned. real(4), dimension(1025*1024*1024) :: m can thus not be accessed on ia32. Currently, gfortran does detect this overflow at compile time. Expected: The same as ifort: fortcom: Error: mem.f, line 3: A common block or variable may not exceed 2147483647 bytes REAL(4), DIMENSION(1074790400) :: T ---^) (2147483647 = 2^31-1 - signed int32.) Analogously for allocate() of pointers and arrays. Currently this does not fail even if sizeof(datatype)*size overflows size_t. As size_t is always possitive, the malloc() works sucessfully. In my case it produces: 1074790400*4 = 4194304. I get a coredump if I access T(1048577) as I only allocated T(1:1048576:1). Other compilers seem to have an overflow check somewhere. Maybe it works the following [symbolically written] if(size 2**sizeof(size_t)/sizeof(datatype)) call error() at least they return a non-successful status with allocate. -- Summary: Check for memory allocations bigger than size_t Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28105
[Bug fortran/26801] -fbounds-check generates segfault
--- Comment #7 from tobias dot burnus at physik dot fu-berlin dot de 2006-06-17 10:57 --- The test case of comment #4 is invalid as the Fortran standard says that a pointer is undefined unless it is associated (allocated, assigned) or deassociated (nullifyed). In this case it is undefined. (What gfortran should do in this case is a matter of taste, crashing is completely acceptable.) However, the test case of comment #3 is valid Fortran 2003, nonetheless gfortran crashes here, which should be fixed (and seems to be fixed by patch in comment 6). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26801
[Bug fortran/28039] New: Warn when ignoring extra characters in the format specification
Assume the following case: One had somewhere '(3(a,),f)', now one copies this and realizes that one does not need the 3(..) anymore. Result: '(a,),f)' Ups, the ,f) is ignored. Currently, gfortran does not warn in such a case. Expected: gfortran warns at compile time Ifort (9.1) even default warns in such a case: fortcom: Warning: test.f90, line 5: The extra characters in the format specification will be ignored ['(a),f)'] write(*,'(a),f)') 'Hello', r --^ Test case: -- program test implicit none real :: r r = 1.0 write(*,'(a),f)') 'Hello', r end program test -- -- Summary: Warn when ignoring extra characters in the format specification Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28039
[Bug fortran/27998] character arrays: warn if erray constructor values have different lengths
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-06-15 12:26 --- .so, an error is definitely in order. Maybe one could spit out a default warning and only with -std=f90 an error as this is might be a commonly used Fortran extension. Or one simply always regards it as error. NAG's f95 gives even with -dusty an error ifort gives not error/warning by default, unless -std95 is specified, then an error message is given. g95 gives no warning (not even with -Wall -Wextra) unless -std=f95 is used (then it is an error) Sun Studio's f95 gives always an error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27998
[Bug fortran/28004] Warn if intent(out) dummy variable is not set
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-06-14 09:17 --- Paul, I presented a patch for this problem and for detected unassigned r-values that was rejected. I don't know what to say; I think that it's a bug, in principle, but the standard does not require it. Well, that was the reason why one should only warn. But I think it is bad enough to valid a default warning (as the other compilers have). But I'm also fine with -Wall. Tobias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28004
[Bug fortran/27996] New: Compile time warn for: character(2) :: str = 'ABC' (expression truncated)
In the following, the assignment to str gets truncated twice. gfortran -Wall does not give any warning. Expected: As similar warning as NAG gives: Warning: trunc.f90, line 2: Initialisation expression for STR truncated At least the first initalization should be detected, possibly also the second. Such error messaging works for real, dimension(3) :: [1.0, 2.0, 3.0] at both places: Error: different shape for Array assignment at (1) on dimension 1 (2/3) --- program test character(2) :: c = 'AAA' c = 'ABC' print *, c end program test --- -- Summary: Compile time warn for: character(2) :: str = 'ABC' (expression truncated) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27996
[Bug fortran/27997] New: Fortran 2003: Support type-spec for array constructor, i.e. (/ real :: 1., 2., 3. /)
See Fortran 2003 standard, section 4.8. Example (F2003, Note 4.70): (/ CHARACTER(LEN=7) :: Takata, Tanaka, Hayashi /) Currently, this gives the error: a = (/ character(len=7) :: 'Takata', 'Tanaka', 'Hayashi' /) 1 Error: Syntax error in array constructor at (1) - program test character(15) :: a(3) a = (/ character(len=7) :: 'Takata', 'Tanaka', 'Hayashi' /) print '(a)',a end program test - -- Summary: Fortran 2003: Support type-spec for array constructor, i.e. (/ real :: 1., 2., 3. /) Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27997
[Bug fortran/27998] New: character arrays: warn if erray constructor values have different lengths
The following constructor seems to be invalid according to the Fortran 2003 standard: (/ 'Takata', 'Tanaka', 'Hayashi' /) as first two strings are 6 whereas the last one is 7 character long. NAG f95 fails with the following error: Error: string.f90, line 3: Array constructor values have differing CHARACTER lengths (6 and 7) [f95 error termination] Thus a warning would be nice, at least with -Wall, maybe even a default warning. In the Fortran 2003 standard, I cannot find the line which forbids the usage of different length strings. However, in NOTE 4.70 of implicitly states that it is not allowed: An example of an array constructor that specifies a nonkind type parameter: (/ CHARACTER(LEN=7) :: Takata, Tanaka, Hayashi /) In this constructor, without the type specification, it would have been necessary to specify all of the constants with the same character length. (This currently does not work in gfortran, see bug 27997.) Example: program test character(15) :: a(3) ! invalid as the constants have different character lengths a = (/ 'Takata', 'Tanaka', 'Hayashi' /) ! This is valid Fortran 95/2003 !a = (/ 'Takata ', 'Tanaka ', 'Hayashi' /) ! And this is valid Fortran 2003 !a = (/ character(len=7) :: 'Takata ', 'Tanaka ', 'Hayashi' /) print '(a)',a end program test -- Summary: character arrays: warn if erray constructor values have different lengths Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27998
[Bug fortran/28004] New: Warn if intent(out) dummy variable is not set
GNU Fortran 95 (GCC) 4.2.0 20060612. If I write a program with a intent(out) variable and this varibale is not set, gfortran only writes: warning: unused variable C Expected: Default warning like ifort/NAG f95/g95: In file ff.f90:7 subroutine sub(a) 1 Warning (158): INTENT(OUT) variable 'a' at (1) is never set --- Warning: ff.f90, line 11: INTENT(OUT) dummy argument A never set --- fortcom: Warning: ff.f90, line 7: A dummy argument with an explicit INTENT(OUT) declaration is not given an explicit value. [A] subroutine sub(a) ---^ Test program: - program test implicit none real :: a call sub(a) end program test subroutine sub(a) implicit none real, intent(out) :: a print *,a end subroutine sub - If you want, you can also -Wall warn that 'a' is used before it has gotten any value assiged. (And Fortran does not guarantee for intent(out) that the variable is set, even if I had add an a = 4.0 before the call sub(a).) Actually, none of the other compilers detects this at compile time, at run time NAG f95 (-nan or -C=undefined) does. -- Summary: Warn if intent(out) dummy variable is not set Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28004
[Bug fortran/28005] New: gfortran: mathmul produces wrong result
From http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/cf9a1ed1754c6f4a/ed236efb2be07bc0?tvc=1#ed236efb2be07bc0 The program -- program tmatmul implicit none integer, parameter :: nmax = 3 integer:: n = 2 real, dimension(nmax,nmax) :: B=0.0, C=1.0, X=0.0 B(1,1) = 1.0 B(1,2) = 2.0 B(2,1) = 3.0 B(2,2) = 5.0 X(1:n,1) = matmul( B(2,1:n),C(1:n,1:n) ) print *, X(:,1) print *, Should be: 8.0 8.0 0.0 end program tmatmul -- produces with gfortran (4.2.0 20060612 and 4.1.0 (SUSE Linux)): 3.00 3.00 0.00 Should be: 8.0 8.0 0.0 ifort, g95 and NAG f95 give the correct result (8. 8. 0.0). -- Summary: gfortran: mathmul produces wrong result Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28005
[Bug fortran/28006] New: Negative-sized array should be empty array, not try to allocate negative memory
Based on http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/c46c14d9d8879bad/14517cbe22d222bc#14517cbe22d222bc If one uses an array with a upper bound lower than the lower bound, the array contains zero items. However, gfortran tries to allocate negative MEMORY when one uses this. Example: - program xint_func print *, 'intfunc', -1, int_func(-3) contains function int_func(n) result(ivec) integer, intent(in) :: n integer :: ivec(n) integer :: i forall (i=1:n) ivec(i) = i end function int_func end program xint_func - This produces in gfortran: Fortran runtime error: Attempt to allocate a negative amount of memory. intfunc -1 Tested with 4.2.0 20060612 (experimental) and 4.1.0 (SUSE Linux). -- Summary: Negative-sized array should be empty array, not try to allocate negative memory Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28006
[Bug fortran/27989] New: -fbounds-check should check for too small arrays on subroutine calls
This is with GNU Fortran 95 (GCC) 4.2.0 20060608 (experimental) and 4.1.0 (SUSE Linux). The following program has a problem as the passed array is shorter than the array expected by the subroutine. Currently, gfortran does not detect this problem. Expected: Something like Actual argument for dummy array A too small - 3 elements instead of 5 (this is the NAG -C=all output) --cut--- program test implicit none real :: b(3) b = 42.0 call sub(5,b) end program test subroutine sub(n,a) implicit none integer, intent(in) :: n real, intent(in) :: a(n) print *,a end subroutine sub ---cut -- Summary: -fbounds-check should check for too small arrays on subroutine calls Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27989
[Bug fortran/27989] -fbounds-check should check for too small arrays on subroutine calls
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-06-11 20:05 --- This should probably marked as blocking -fbounds-check meta bug 27786. -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27989
[Bug fortran/27965] New: gfortran gives Array bound mismatch for valid program
The following valid Fortran 95 program gives Fortran runtime error: Array bound mismatch for GNU Fortran 95 (GCC) 4.1.0 (SUSE Linux) and Fortran runtime error: Array bound mismatch, upper bound of dimension 1 of array 'rho' exceeded (in file 'main.f90', at line 12) for GNU Fortran 95 (GCC) 4.2.0 20060608 (experimental). ---cut-- program test implicit none real(8) :: rftp(4) rftp = 42.0_8 call xcifc(n=4,rho=rftp) contains subroutine xcifc(n,rho) implicit none integer, optional, intent(in) :: n real(8), optional, intent(in) :: rho(*) if(present(n).and.present(rho)) then print *,rho(1:n) end if end subroutine xcifc end program test -- Compiled as: gfortran -Wall -g -O0 -fbounds-check -Wconversion main.f90 If compiled without -fbounds-check, the output is ok. Other compilers: ~ f95 -C=all -C=undefined -kind=byte main.f90 ; ./a.out 42. 42. 42. 42. ~ ifort -C -check all -warn all,nodec,interfaces -gen_interfaces -traceback -fpe0 -fpstkchk -g -O0 main.f90; ./a.out 42.042.042.0 42.0 -- Summary: gfortran gives Array bound mismatch for valid program Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27965
[Bug fortran/27965] gfortran gives Array bound mismatch for valid program
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-06-08 19:53 --- This could be the same as gfortran.fortran-torture/execute/assumed_size.f90, I'm not completely sure, though. -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27965
[Bug fortran/27866] New: Warn when casting, e.g. assigning a double precision to a real
In the following program there is clearly a problem with the r = d assignment. In most real programs such drastic case does not happen. However, simple precision loss or worse things may occure. gfortran -Wall should warn, but it does not deserve a default warning. program test double precision :: d real :: r d = 4d99 r = d print *, d, r end program test g95 -Wall shows: r = d 1 Warning (140): Implicit conversion at (1) may cause precision loss -- Summary: Warn when casting, e.g. assigning a double precision to a real Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27866
[Bug fortran/27868] New: Array reference out of bounds check should state file/line number or should at least crash
It is really helpful to have a program which stops with Fortran runtime error: Array reference out of bounds when compiled with -fbounds-check. Because one has no idea where this happens. Expected: At least crash so that one can do a backtrace in the debugger. Or write out the file/line number/variable name ... (Sorry for being sarcastic. The program runs ok with all checks turned on in the ifort 9.1, but crashes very early with gfortran 4.1 [glibc reports a double free].) -- Summary: Array reference out of bounds check should state file/line number or should at least crash Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27868
[Bug fortran/22629] Would like to access long double equivalent type as real*16
--- Comment #6 from tobias dot burnus at physik dot fu-berlin dot de 2006-05-24 22:11 --- Gfortran will never support a real*16 data type on IA32 hardware. This would require software emulation of all of basic floating-point arthimetic This is what Intel's Fortran Compiler does - it emulates quads in software on IA32/EM64T/Itanium. Steve Lionel mentions another possibilty: IBM has an odd implementation where they use two doubles with offset exponents. It's fast but it isn't a uniform type and doesn't give you extended range, so it's useless for a lot of what people use higher precision types for. See http://softwareforums.intel.com/ids/board/message?board.id=5message.id=17632 g95, NAGWare f95, Pathscale and Portland's pgf95 all fail to compile real(16) [most of them use GCC as backend, though] on AMD64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22629
[Bug fortran/27583] New: ICE for (invalid) save on automatic object
The following invalid program --- program test_save call foo(3) contains subroutine foo(n) implicit none integer :: n real, dimension(n), save :: r ! ERROR: save and variable-dependent dim r = 1.0 write(*,*) r end subroutine foo end program test_save --- Should emit a nice error message. However, it creates an ICE: test.f90: In function foo: test.f90:7: internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3418 Please submit a full bug report, g95 does: In file test.f90:7 real, dimension(n), save :: r 1 Error: Automatic variable 'r' at (1) cannot have the SAVE attribute and ifort does: fortcom: Error: test.f90, line 7: An automatic object must not appear in a SAVE statement or be declared with the SAVE attribute. [R] real, dimension(n), save :: r --^ -- Summary: ICE for (invalid) save on automatic object Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27583
[Bug fortran/27584] New: ICE on invalid associate(x,(y))
I get an ICE using: -- program test implicit none real, pointer :: x real, target :: y if(ASSOCIATED(X,(Y))) print *, 'Hello' end program test -- (If one corrects the error and uses associated(x,y), gfortran is happy.) test2.f90:0: internal compiler error: in gfc_check_associated, at fortran/check.c:535 g95: In file test2.f90:5 if(ASSOCIATED(X,(Y))) print *, 'Hello' 1 Error: 'target' argument of 'associated' intrinsic at (1) must be a POINTER or a TARGET ifort: fortcom: Error: test2.f90, line 5: The TARGET argument must have the POINTER or TARGET attribute. [ASSOCIATED] if(ASSOCIATED(X,(Y))) print *, 'Hello' ^ NAGf95: Error: test2.f90, line 5: TARGET arg to ASSOCIATED intrinsic not pointer/target -- Summary: ICE on invalid associate(x,(y)) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27584
[Bug fortran/27586] New: Compile-time warn if arguments don't match in terms of precision
The following test case uses single precision arguments to a double precision function. Expected: Warn during compiling Actual: No warning is given. ./a.out shows: 0.00 3.0132665E+23 ! initialized with 2 sqrt(2) In order to make it work across files, the .mod file should contain such information (and it should be used). From http://www.polyhedron.com/pb05/linux/diagnose.html For the following file gfortran should issue a warning as x,y are once real and once double precision. ---ARG1.F ! argument mismatch - same file program arg1 call sub(x,y) print * , x,y end subroutine sub(x,y) double precision x,y x = 2.0 y = sqrt(x) end gfortran-4.2 -Wall -pedantic -fbounds-check ARG1.F produces no warning Whereas ifort64-9.1 -C -check all -warn all,nodec,interfaces -gen_interfaces -traceback -fpe0 -fpstkchk ARG1.F fortcom: Error: ARG1.F, line 3: The type of the actual argument differs from the type of the dummy argument. [X] call sub(x,y) ---^ fortcom: Error: ARG1.F, line 3: The type of the actual argument differs from the type of the dummy argument. [Y] call sub(x,y) -^ g95 -Wall -pedantic -fbounds-check -ftrace=full ARG1.F In file ARG1.F:3 call sub(x,y) 1 In file ARG1.F:6 subroutine sub(x,y) 2 Warning (155): Inconsistent types (REAL(4)/REAL(8)) in actual argument lists at (1) and (2) NAG: f95 -C=all -C=undefined -info -g -gline ARG1.F Error: /tmp/ARG1.020753.f: Argument X (no. 1) in reference to SUB from ARG1 has the wrong data type Error: /tmp/ARG1.020753.f: Argument Y (no. 2) in reference to SUB from ARG1 has the wrong data type A meaner test is the following: ---ARG2A.F--- ! argument mismatch - different file program arg2 call sub(x,y) print * , x,y end --- ---ARG2B.F--- ! argument mismatch - different file subroutine sub(x,y) double precision x,y x = 2.0 y = sqrt(x) end --- gfortran does not catch the problem either, of g95, ifort and NAGf95 only the Intel compiler catches this - when compiling ARG2B.F ARG2A.F. (ARG2A.F ARG2B.F no compiler catches.) Actually, none of the compilers catches this at run time either. ifort64-9.1 -C -check all -warn all,nodec,interfaces -gen_interfaces -traceback -fpe0 -fpstkchk ARG2B.F ARG2A.F fortcom: Error: ARG2A.F, line 3: The type of the actual argument differs from the type of the dummy argument. [X] call sub(x,y) ---^ fortcom: Error: ARG2A.F, line 3: The type of the actual argument differs from the type of the dummy argument. [Y] call sub(x,y) -^ compilation aborted for ARG2A.F (code 1) -- Summary: Compile-time warn if arguments don't match in terms of precision Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27586
[Bug fortran/27587] New: Warn when Scalar constant passed to array dummy argument
Taken from http://www.polyhedron.com/pb05/linux/diagnose.html ARG7.FOR--- real function same(x) implicit none real x(1) same = x(1) end program xtwice implicit none real same external same print*,same(10.0) print*,'Bug not caught!' end -- Current behaviour: prints 10.0 Expected: Warn/error that argument is not an array. ~ gfortran-4.2 -Wall -pedantic -fbounds-check ARG7.F ARG7.F:34: warning: no newline at end of file ~ ./a.out 10.0 Bug not caught! Comparison with other compilers: ifort64-9.1 -C -check all -warn all,nodec,interfaces -gen_interfaces -traceback -fpe0 -fpstkchk ARG7.F fortcom: Error: ARG7.F, line 31: If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argu ment is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element. [X] print*,same(10.0) -^ compilation aborted for ARG7.F (code 1) NAG: f95 -C=all -C=undefined -info -g -gline ARG7.F Error: /tmp/ARG7.022067.f: Argument X (no. 1) in reference to SAME from XTWICE is not an array [f95 error termination] -- Summary: Warn when Scalar constant passed to array dummy argument Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27587
[Bug fortran/27588] New: -fbounds-check should catch substring out of range accesses
Taken from http://www.polyhedron.com/pb05/linux/diagnose.html --CBND1.F--- ! character bound error - local variable program cbnd1 character*10 zz i = 2 j = i+9 zz(i:j) = 'abcdef' print * , zz end -- gfortran-4.2 -Wall -pedantic -fbounds-check CBND1.F ./a.out ^Aabcdef Expected: Issue a run-time error message. Examples of other compilers: ifort64-9.1 -C -check all -warn all,nodec,interfaces -gen_interfaces -traceback -fpe0 -fpstkchk CBND1.F ./a.out forrtl: severe (408): fort: (4): Variable ZZ has substring ending point 11 which is greater than the variable length of 10 g95 -Wall -pedantic -fbounds-check -ftrace=full CBND1.F ./a.out At line 6 of file CBND1.F Traceback: (Innermost first) Fortran runtime error: Substring reference out of bounds: (2:11) in string of length 10 NAG: f95 -C=all -C=undefined -info -g -gline CBND1.F Out of range: substring ending position 11 is greater than length 10 Program terminated by fatal error In CBND1, line 6 of CBND1.F The following is even detected at compile time by the intel and NAGf95 compilers (gfortran does not detect it at compile or runtime): CBND3.F-- ! Check character bound error - assign to dummy argument which is larger than actual arg program cbnd3 character*10 zz,zzz common /aaa/zz,zzz zz = '00' zzz = '11' call sub(zz) print * , zzz end subroutine sub(zz) character*11 zz zz = 'abcdef' print * , zz end --- -- Summary: -fbounds-check should catch substring out of range accesses Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27588
[Bug fortran/27588] -fbounds-check should catch substring out of range accesses
-- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27588
[Bug fortran/27589] New: Add compiler flag to check for uninitalized values at runtime
Currently, gfortran does not seem to have any option to catch uninitialized variables at run time. Example (from http://www.polyhedron.com/pb05/linux/diagnose.html): UNIN1 program uin1 integer x,y,a,b x=y a=b print *,x,a b=1 end --- Other compilers have an options to catch those, e.g.: ifort64-9.1 -C -check all -warn all,nodec,interfaces -gen_interfaces -traceback -fpe0 -fpstkchk UIN1.F ./a.out forrtl: severe (193): Run-Time Check Failure. The variable 'uin1_$Y' is being used without being defined NAG: f95 -C=all -C=undefined -info -g -gline UIN1.F ./a.out Reference to undefined variable Y Program terminated by fatal error In UIN1, line 5 of UIN1.F -- Summary: Add compiler flag to check for uninitalized values at runtime Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27589
[Bug fortran/27589] Add compiler flag to check for uninitalized values at runtime
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-05-13 14:17 --- Post scriptum: In this case, using -Wuninitialized -O the compiler detects that the variable is uninitialized; however, for the other UIN*.FOR examples at polyhdron.com they are not detected at compile-time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27589
[Bug fortran/27594] New: Warn/Error when number of arguments of a function does not match
The following testcase has a function with 13 arguments, but 14 are passed. gfortran-4.2 -Wall does not show a warning. Other compilers: NAG's f95 (no options): Error: test2.f: Wrong number of arguments to TRNS from TEST: 14 found, 13 expected g95 (Default-on warning): In file test2.f:19 ,NCNF1,ACNF1,ICNF1,ACNF2,ICNF2,NORD) 12 Warning (154): Inconsistent number of arguments in reference to 'trns' at (1) and (2) Testfile: -- SUBROUTINE TRNS(NCNF ,ACNF,ICNF,NTRN,ATRN,NORD,AORD,IORD ,NCNF1,ACNF1,ICNF1,ACNF2,ICNF2) PARAMETER(NCNFM=5,NORDM=100) CHARACTER*16 ACNF(NCNFM),ACNF1(NCNFM),ACNF2(NCNFM),AORD(NORDM) DIMENSIONICNF(NCNFM),ICNF1(NCNFM),ICNF2(NCNFM),IORD(NORDM) CHARACTER*16 ATRN,AT,AC,APPND DIMENSIONIW(100) END SUBROUTINE TRNS PROGRAM TEST IMPLICIT REAL*8 (A-H,O-Z) PARAMETER(NCNFM=5,IUIN=3,IUOUT=1,NORDM=100) CHARACTER*16 ACNF(NCNFM),ACNF1(NCNFM),ACNF2(NCNFM),ATRN(100) ,AORD(NORDM) DIMENSIONICNF(NCNFM),ICNF1(NCNFM),ICNF2(NCNFM),ITRN(100) ,IORD(NORDM) CALL TRNS(NCNF,ACNF,ICNF,ITRN(L),ATRN(L),NORD,AORD,IORD ,NCNF1,ACNF1,ICNF1,ACNF2,ICNF2,NORD) END PROGRAM TEST -- -- Summary: Warn/Error when number of arguments of a function does not match Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27594
[Bug fortran/27586] Compile-time warn if arguments don't match in terms of precision
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-05-13 23:01 --- The following is also not caught: - subroutine foo(y) character(len=20) :: y y = 'hello world' end program test character(len=10) :: x call foo(x) write(*,*) 'X=',x pause end - NAG's f95 spits out this error: Error: test17.f90: Argument Y (no. 1) in reference to FOO from TEST is too short a character string -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27586
[Bug other/27541] New: Support Cluster OpenMP (distributed-memory OpenMP)
Currently, GCC only supports OpenMP on shared-memory systems. It would be nice if it could be extended to support OpenMP via the ethernet, infiniband etc. (distributed-memory systems). There exists (at least) one implementation of distributed-memory OpenMP: The Intel Compilers 9.1's Cluster OpenMP. Intel's Whitepaper: http://www.intel.com/cd/software/products/asmo-na/eng/compilers/285865.htm Intel's Cluster OpenMP User manual: http://softwareforums.intel.com/attachments/ids/11/3796/1/UsersGuide.pdf Intel's Extentions to OpenMP: the sharable directive. The sharable directive identifies variables that are referenced by more than one thread. These variables are the ones that are managed by the DSM system. (Some are automatically marked shareable, see whitepaper, p. 5) The whitepaper also describes some implemenation details to deal with global memory. Running such a Intel-Cluster-OpenMP program: ./a.out, which first reads the config file then starts the program on the remote computer via rsh or ssh. The data transfer via TCP or Direct Access Provider Library (DAPL.sf.net). * * * Besides OpenMP there exists another multi-processor extention which works at compile time: Cray's co-arrays, scheduled (in modified form) to be included into the Fortran 2008 standard (see http://www.co-array.org/). Having a look at the co-array specs shouldn't harm, when implementing this. Maybe some different or further things should be considered. -- Summary: Support Cluster OpenMP (distributed-memory OpenMP) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27541
[Bug other/27541] Support Cluster OpenMP (distributed-memory OpenMP)
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-05-10 22:46 --- Is there really a standard for this or just an extension of OpenMP? I'm not sure whether I understand the question. Directive wise it is OpenMP augmented by a single directive: shareable. This seems to be a single-vendor extension by Intel. I think they simply took the OpenMP standard and looked how to implement it for distributed memory. The problem in inplementing is, as far as I understood, that plainly speaking OpenMP assumes everything is global whereas distributed programs want to minimize 'global' (better: shared) variables as they have to be synchronized and are thus expensive. Intel added sharable to denote explictly such a variable; however, some variables are automatically marked as shareable. Thus: Syntaxwise it is a rather small change quickly to be implemented in GOMP. But the library system behind is a bigger task: - wrapper main() which initializes helper library, finds settings and starts the program on m computers (incl. forking of n threads) via rsh/ssh. - provides synchronization (barrier, data exchange, collection of data etc.) via TCP or DAPL, especially for global variables Though this is useful a little bit for the Cell where you don't really have a distrubuted machine but the memory will be distributed though. Well, I'm primarily interested to run a number-crunching program (exciting.sf.net) on more nodes. As it is only parallized using OpenMP (and not e.g. via MPI), I'm currently limited to 2 CPUs (or one dualcore) on our cluster. Using Cluster OpenMP with infiniband I could use 2*120 CPUs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27541
[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #18 from tobias dot burnus at physik dot fu-berlin dot de 2006-05-09 20:15 --- Subject: Re: gfortran: Warn/abort when format in write does not fit passed arguments @resolution : FIXED This looks like you have an old version of the library around, and that it's used instead of that of the newer compiler. Try compiling with -static or setting LD_LIBRARY_PATH before execution. I'm an idiot. Generally, I call gfortran via ~/bin/gfortran-4.2 containing exec /opt/gcc-4.2-svn/bin/gfortran -Wl,-rpath,/opt/gcc-4.2-svn/lib64 $@ but seemingly this time not :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug fortran/27436] New: gfortran: Abort compiling if there are insufficient data descriptors in format after reversion
Split off of bug 27304
Currently, gfortran only detects that the IO format descriptor contains
insufficient data at run time. It would be great (though of low priority) if it
would find them at compile time. Examples:
write(*,'(abc)') n
write(10,(i7,(' abcd')), err=10) n, n
As of fixing bug 27304 this gives an run-time error message. As in my case the
write(*,*) is deeply buried in an if(very rarely true) write(*,*), the
compile-time error would be of great help [run time of the program one day].
Reference: In the 2004-05 Fortran 2003 draft (10.3) I find:
If an input/output list specifies at least one effective list item, at
least one data edit descriptor shall exist in the format specification.
--
Summary: gfortran: Abort compiling if there are insufficient data
descriptors in format after reversion
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27436
[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #15 from tobias dot burnus at physik dot fu-berlin dot de 2006-05-04 19:09 --- I probably do something wrong, but with GNU Fortran 95 (GCC) 4.2.0 20060504 (experimental) from http://quatramaran.ens.fr/~coudert/gfortran/gfortran-x86_64-linux.tar.gz I still don't get a run-time error message. Using fmt_exhaust.f90 it crashes (abort()) rather than going to 10 (err=10). As does my test case. -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #14 from tobias dot burnus at physik dot fu-berlin dot de
2006-05-02 08:37 ---
Fixed on 4.1 and 4.2
Thanks for fixing :-)
Still it would be nice if it would be detected during compile time. In
my case it was burried in an
if(something that rarely happens) write(*,'(''n'')') n
which I wouldn't have found easily without the compile-time warning of
the NAG compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug fortran/27304] gfortran: Warn/abort when format in write does not fit passed arguments
--- Comment #4 from tobias dot burnus at physik dot fu-berlin dot de 2006-04-26 06:22 --- Subject: Re: gfortran: Warn/abort when format in write does not fit passed arguments I wonder if this is a case of illegal code. Intel errors on infinite format. Well, current g95, ifort 9/9.1, pgf95 6.0, pathscale and NAG f95 regard it as such and abort the execution or (NAG, today's g95) error on compilation. In the 2004-05 Fortran 2003 draft (10.3) I find: If an input/output list specifies at least one effective list item, at least one data edit descriptor shall exist in the format specification. For the compile-time I thus would really regard it as error. What the best behaviour for the run time is, is however debatable. (Abort [most compilers], ignore [g77, gfortran], ignore warn [no compiler?].) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27304
[Bug fortran/27327] New: Warn or give error, when common blocks don't match
gfortran compiles SUBROUTINE OPT1 (IB) IMPLICIT REAL*8 (A-H,O-Z) COMMON /INTNEW/ VL,EPS,BEGIN,STEP END SUBROUTINE OPT0(E0,H0,P0,NUMB,X,Y) IMPLICIT double precision (A-H,O-Z) COMMON /INTNEW/ V,EPS,BEGIN,STEP,PP,DOM,PIMEAN,AA,A0,BB,B0,PI0,G,G1,G2 END -- without any warning (as does ifort). However, you should either warn or give an error if two commons don't match. NAGWare compiler fails with an ERROR: -- Error: test5.f90: Inconsistent definitions of COMMON block INTNEW in program-units OPT1 and OPT0 -- g95 compiler (with only -c and not -Wall) compiles, but spits out the warning: -- In file test5.f90:8 COMMON /INTNEW/ V,EPS,BEGIN,STEP,PP,DOM,PIMEAN,AA,A0,BB,B0,PI0,G,G1,G2 1 In file test5.f90:3 COMMON /INTNEW/ VL,EPS,BEGIN,STEP 2 Warning (121): COMMON block 'intnew' is 120 bytes at (1) and 32 bytes at (2) -- -- Summary: Warn or give error, when common blocks don't match Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27327
