[Bug fortran/38404] Warning message identifies incorrect line
--- Comment #4 from steve dot chapel at a2pg dot com 2010-05-13 16:28 --- :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38404
[Bug fortran/38404] Warning message identifies incorrect line
--- Comment #2 from steve dot chapel at a2pg dot com 2010-05-13 13:15 --- Excellent! The new warning is far more understandable than the old. X'"R" IN CALL RANDOM MAY NOT BE USED OUTSIDE THE BLOCK CONTAINING T 1 Warning: Initialization string starting at (1) was truncated after 72 characters to match the variable If it's difficult to place the error marker at the location the string was truncated, would it be easy to list the number of characters in the initialization string, so that one would not have to count characters to determine how many characters need to be removed, or how much larger to make the variable? Example: X'"R" IN CALL RANDOM MAY NOT BE USED OUTSIDE THE BLOCK CONTAINING T 1 Warning: Initialization string of 73 characters starting at (1) was truncated after 72 characters to match the variable -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38404
[Bug fortran/38404] New: Warning message identifies incorrect line
When the following program (truncbug.f) is compiled with gfortran 4.3.2: SUBROUTINE ERRMSG(N,STRING,LST) CHARACTER*72 TEXT(2) DATA (TEXT(I),I=1,2)/ X'MUST BE "CALL SIMEPS(EPS)"', X'"R" IN CALL RANDOM MAY NOT BE USED OUTSIDE THE BLOCK CONTAINING T XHE CALL.'/ END This warning message results: truncbug.f:4.72: X'MUST BE "CALL SIMEPS(EPS)"', 1 Warning: initialization string truncated to match variable at (1) This is two lines before the line that the string truncation occurs on. Ideally, gfortran should put the (1) mark at the character in the string where the truncation occurs. -- Summary: Warning message identifies incorrect line Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: steve dot chapel at a2pg dot com GCC build triplet: i386-redhat-linux GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38404
[Bug libfortran/32784] [win32] Using 'CONOUT$', 'CONIN$', or 'CONERR$' as assigned file generates Fortran runtime error: Bad file descriptor
--- Comment #30 from steve dot chapel at a2pg dot com 2008-11-18 12:59 --- Although bug 38122 causes NONMEM to not run as is, all it takes is a simple one-line change to get it to run normally on Linux. This bug, on the other hand, makes it effectively impossible to run NONMEM normally on Windows, that is, sending output to the console output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32784
[Bug libfortran/32784] [win32] Using 'CONOUT$', 'CONIN$', or 'CONERR$' as assigned file generates Fortran runtime error: Bad file descriptor
--- Comment #28 from steve dot chapel at a2pg dot com 2008-11-17 15:01 --- I'm changing the summary of this bug report to better indicate the problem that the patch fixes. Could we get the patch into gfortran 4.5? There is discussion on the NONMEM users mailing list about how to get NONMEM to work with gfortran on Windows, and users are waiting for a resolution to this issue. Thanks. -- steve dot chapel at a2pg dot com changed: What|Removed |Added Summary|[win32] Using 'con' or |[win32] Using 'CONOUT$', |'CONOUT$' as assigned file |'CONIN$', or 'CONERR$' as |generates Fortran runtime |assigned file generates |error: File 'con' does not |Fortran runtime error: Bad |exist |file descriptor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32784
[Bug fortran/38122] "file already opened in another unit" error when opening /dev/null or /dev/tty twice
--- Comment #2 from steve dot chapel at a2pg dot com 2008-11-14 20:19 --- It's not a bug in my program. It's a bug in NONMEM VI. That is, assuming that /dev/tty and /dev/null are files, which they're not. They're devices. Regardless, it's code that runs in an older version that doesn't run in a new version. This problem will cause people to use the old version of the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38122