[Bug fortran/38404] Warning message identifies incorrect line

[steve dot chapel at a2pg dot com]

--- 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] Warning message identifies incorrect line

[steve dot chapel at a2pg dot com]

--- 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] New: Warning message identifies incorrect line

[steve dot chapel at a2pg dot com]

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

[steve dot chapel at a2pg dot com]

--- 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

[steve dot chapel at a2pg dot com]

--- 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

[steve dot chapel at a2pg dot com]

--- 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