[Bug fortran/114618] New: Format produces incorrect output when contains 1x, ok when uses " "

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618 Bug ID: 114618 Summary: Format produces incorrect output when contains 1x, ok when uses " " Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal

[Bug libfortran/107031] endfile truncates file at wrong position

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 urbanjost at comcast dot net changed: What|Removed |Added CC||urbanjost at comcast dot n

[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223 --- Comment #4 from urbanjost at comcast dot net --- User-defined types work and as I read the ISO standard are supported, and TYPE(REAL) works; it is only when a parameter is added that it fails; nvfortran fails for user-defined type declared be

[Bug fortran/109226] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109226 urbanjost at comcast dot net changed: What|Removed |Added Resolution|--- |DUPLICATE Sta

[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223 --- Comment #1 from urbanjost at comcast dot net --- *** Bug 109226 has been marked as a duplicate of this bug. ***

[Bug fortran/109226] New: parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109226 Bug ID: 109226 Summary: parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails Product: gcc Version: 12.2.0 Status: UNCONFIR

[Bug fortran/109223] New: parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223 Bug ID: 109223 Summary: parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails Product: gcc Version: 12.2.0 Status: UNCONFIR

[Bug fortran/109171] initialization using %re causes segfault, as an assignment does not

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109171 --- Comment #4 from urbanjost at comcast dot net --- Try that again. 101047. Not sure what happened to the paste buffer to get that other number. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101047

[Bug fortran/109171] initialization using %re causes segfault, as an assignment does not

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109171 --- Comment #3 from urbanjost at comcast dot net --- When you said you thought it was a duplicate I spent some time rechecking, and I think this is covered by 50991? Very different keywords and example, but if no pointer allocation is working at

[Bug fortran/109171] initialization using %re causes segfault, as an assignment does not

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109171 --- Comment #1 from urbanjost at comcast dot net --- per discussion in https://groups.google.com/g/comp.lang.fortran/c/zBaOPfeFrOU

[Bug fortran/109171] New: initialization using %re causes segfault, as an assignment does not

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109171 Bug ID: 109171 Summary: initialization using %re causes segfault, as an assignment does not Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/109099] Assignment in NAMELIST input does not fill in row-column order

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109099 --- Comment #3 from urbanjost at comcast dot net --- So I think you are right and this is not standard; so instead of an error at most it would be nice to get a warning/error message indicating too many values were used or that an extension is us

[Bug fortran/109099] Assignment in NAMELIST input does not fill in row-column order

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109099 --- Comment #2 from urbanjost at comcast dot net --- Created attachment 54640 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54640&action=edit interactive program for trying out NAMELIST group input This may be an "oops" after all; looks l

[Bug fortran/109099] New: Assignment in NAMELIST input does not fill in row-column order

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109099 Bug ID: 109099 Summary: Assignment in NAMELIST input does not fill in row-column order Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/82480] KIND array returned by STAT too small for many values on CygWin platforms (and probably others)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82480 --- Comment #6 from urbanjost at comcast dot net --- Never mind. Wrong bug report. Ignore comment #5

[Bug fortran/109080] A write of a NAMELIST group containing an allocatable array is incorrect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109080 --- Comment #2 from urbanjost at comcast dot net --- A cannot update, but on https://godbolt.org I found 12.2 was available, and it worked there, so I suppose this can be closed. Program returned: 0 Program stdout &ARGS LINES="Xx","Yy","Zz",

[Bug fortran/109080] New: A write of a NAMELIST group containing an allocatable array is incorrect

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109080 Bug ID: 109080 Summary: A write of a NAMELIST group containing an allocatable array is incorrect Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: nor

[Bug fortran/108168] New: ICE in a simple module that almost any change eliminates

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108168 Bug ID: 108168 Summary: ICE in a simple module that almost any change eliminates Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Pr

[Bug fortran/95947] PACK intrinsic returns blank strings when an allocatable character array with allocatable length is used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95947 --- Comment #4 from urbanjost at comcast dot net --- FYI: Still occurs in 12.2.0.

[Bug fortran/107716] Getting negative values with NINT when using doubleprecision values in range on i386

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716 --- Comment #1 from urbanjost at comcast dot net --- I am on a Linux mint box using KVM and running a virtual box that is OpenBSD mo.my.domain 7.2 GENERIC#381 i386 using GNU Fortran (GCC) 11.2.0 and am getting negative values from NINT() on

[Bug fortran/107716] New: Getting negative values with NINT when using doubleprecision values in range on i386

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716 Bug ID: 107716 Summary: Getting negative values with NINT when using doubleprecision values in range on i386 Product: gcc Version: 11.2.0 Status: UNCONFIRMED S

[Bug fortran/107659] New: C procedure with no global scope is seen as global

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107659 Bug ID: 107659 Summary: C procedure with no global scope is seen as global Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Compon

[Bug fortran/103782] [9/10/11/12 Regression] internal error occurs when overloading intrinsic since r9-1566-g87c789f1c0b2df41

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103782 --- Comment #6 from urbanjost at comcast dot net --- Thanks for the quick response! Fantastic! That gets me below a dozen bug reports. I'll have to go break something new :> g95/gfortran saved fortran IMHO. Thanks to all the gfortran heroes ou

[Bug fortran/103782] New: internal error occurs when overloading intrinsic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103782 Bug ID: 103782 Summary: internal error occurs when overloading intrinsic Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Componen

[Bug libfortran/98507] timezone is incorrect on last day of year for "TZ" hours

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507 --- Comment #4 from urbanjost at comcast dot net --- Thanks! nice to have this fixed!

[Bug fortran/102582] allocate treats all variables as type CHARACTER after use of CHARACTER(LEN=NNN)::

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102582 --- Comment #1 from urbanjost at comcast dot net --- Never mind. It looks like C934 (R927) If type-spec appears, it shall specify a type with which each allocate-object is type compatible. it should do that, and nvfortran and ifort are the ones

[Bug fortran/102582] New: allocate treats all variables as type CHARACTER after use of CHARACTER(LEN=NNN)::

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102582 Bug ID: 102582 Summary: allocate treats all variables as type CHARACTER after use of CHARACTER(LEN=NNN):: Product: gcc Version: 10.3.0 Status: UNCONFIRMED Seve

[Bug fortran/101399] Horizonal tab character not ignored on print statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101399 --- Comment #4 from urbanjost at comcast dot net --- Wow. I cannot get a pizza delivered that fast. Thanks! I have -Wtabs set in my compiler script and the script I use for editing codes does a :retabs after turning off tabs in vim(1) and runs an

[Bug fortran/101399] Horizonal tab character not ignored on print statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101399 --- Comment #2 from urbanjost at comcast dot net --- I agree tabs are not part of the standard, but even by default it is a very common extension ( I tried it with gfortran, ifort, nvfortran just today). I not not use the extension normally mysel

[Bug fortran/101399] New: Horizonal tab character not ignored on print statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101399 Bug ID: 101399 Summary: Horizonal tab character not ignored on print statement Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Com

[Bug fortran/82480] KIND array returned by STAT too small for many values on CygWin platforms (and probably others)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82480 --- Comment #5 from urbanjost at comcast dot net --- Since it is an extension that makes perfect sense to me. Backward-compatible and solves the problem.

[Bug fortran/98507] New: timezone is incorrect on last day of year for "TZ" hours

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507 Bug ID: 98507 Summary: timezone is incorrect on last day of year for "TZ" hours Product: gcc Version: 8.3.1 Status: UNCONFIRMED Severity: normal Prior