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

2024-04-05 Thread urbanjost at comcast dot net via Gcc-bugs
ty: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- The format gen2 does what I would expect the format gen1 does, but get very strange output when use 1x (in gen1

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

2024-03-25 Thread urbanjost at comcast dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 urbanjost at comcast dot net changed: What|Removed |Added CC||urbanjost at comcast dot

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

2023-03-21 Thread urbanjost at comcast dot net via Gcc-bugs
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

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

2023-03-20 Thread urbanjost at comcast dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109226 urbanjost at comcast dot net changed: What|Removed |Added Resolution|--- |DUPLICATE

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

2023-03-20 Thread urbanjost at comcast dot net via Gcc-bugs
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

2023-03-20 Thread urbanjost at comcast dot net via Gcc-bugs
: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- This fails on the IMPLICIT statement program testit use, intrinsic

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

2023-03-20 Thread urbanjost at comcast dot net via Gcc-bugs
: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- This fails on the IMPLICIT statement program testit use, intrinsic

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

2023-03-17 Thread urbanjost at comcast dot net via Gcc-bugs
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

2023-03-17 Thread urbanjost at comcast dot net via Gcc-bugs
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

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

2023-03-17 Thread urbanjost at comcast dot net via Gcc-bugs
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

2023-03-17 Thread urbanjost at comcast dot net via Gcc-bugs
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- program boom implicit none complex, save, target :: a(4) #ifdef INITIALIZE real, pointer :: p(:) => a(1:3:2)%re #e

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

2023-03-11 Thread urbanjost at comcast dot net via Gcc-bugs
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

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

2023-03-11 Thread urbanjost at comcast dot net via Gcc-bugs
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=edit interactive program for trying out NAMELIST group input This may be an "oops" after all;

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

2023-03-10 Thread urbanjost at comcast dot net via Gcc-bugs
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- program testit integer, allocatable :: x(:,:); namelist / group / x character(len=80) :: input(3) allocate( x(3,4),source=999

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

2023-03-09 Thread urbanjost at comcast dot net via Gcc-bugs
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

2023-03-09 Thread urbanjost at comcast dot net via Gcc-bugs
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 LINES="Xx"

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

2023-03-09 Thread urbanjost at comcast dot net via Gcc-bugs
: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Sometimes it runs and writes out ALINES incorrectly, and sometimes the same executable segfaults. program gnubug

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

2022-12-18 Thread urbanjost at comcast dot net via Gcc-bugs
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Extracted a reproducer that is only a few lines from a large module, but do not see what is going on. Even moving the order

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

2022-12-14 Thread urbanjost at comcast dot net via Gcc-bugs
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

2022-11-16 Thread urbanjost at comcast dot net via Gcc-bugs
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

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

2022-11-16 Thread urbanjost at comcast dot net via Gcc-bugs
Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: ---

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

2022-11-11 Thread urbanjost at comcast dot net via Gcc-bugs
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Created attachment 53886 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53886=edit single file source appears to be required to reproduce the prob

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

2022-01-14 Thread urbanjost at comcast dot net via Gcc-bugs
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 her

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

2021-12-20 Thread urbanjost at comcast dot net via Gcc-bugs
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- program runtest implicit none ! ! if overload an intrinsic like dble or real this fails ! ! internal compiler error: in gfc_trans_array_constructor_subarray

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

2021-12-16 Thread urbanjost at comcast dot net via Gcc-bugs
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)::

2021-10-03 Thread urbanjost at comcast dot net via Gcc-bugs
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

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

2021-10-03 Thread urbanjost at comcast dot net via Gcc-bugs
Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Created attachment 51544 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51544=edit example of ALLOCATE

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

2021-07-09 Thread urbanjost at comcast dot net via Gcc-bugs
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

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

2021-07-09 Thread urbanjost at comcast dot net via Gcc-bugs
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

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

2021-07-09 Thread urbanjost at comcast dot net via Gcc-bugs
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Although gfortran defaults to allowing tab characters in source input as an extension, a PRINT statement followed immediately by a horizontal tab character

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

2021-01-10 Thread urbanjost at comcast dot net via Gcc-bugs
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

2021-01-03 Thread urbanjost at comcast dot net via Gcc-bugs
ty: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Created attachment 49870 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49870=edit call date_and_time and print timezone

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

2020-06-28 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95947 --- Comment #2 from urbanjost at comcast dot net --- Per feedback made test more like a unit test: TEST PROGRAM: character(len=:),allocatable :: m(:) !!NOTE: WORKS WITH len=10 instead of len=: logical :: passed m = [ character(len

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

2020-06-28 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95947 --- Comment #1 from urbanjost at comcast dot net --- Created attachment 48796 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48796=edit test using PACK(3f) intrinsic with allocatable variables PACK() intrinsic is returning all bla

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

2020-06-28 Thread urbanjost at comcast dot net
Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: ---

[Bug fortran/92785] expressions passed as real arguments to a dummy polymorphic argument fail with indexing error

2020-02-28 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92785 --- Comment #3 from urbanjost at comcast dot net --- Great! Looking forward to using polymorphic variables in more and more applications and this problem had put a hold on that. > On February 28, 2020 at 6:58 AM "pault at gcc dot

[Bug fortran/93635] New: Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group

2020-02-08 Thread urbanjost at comcast dot net
Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- User programming error produces an ICE instead

[Bug fortran/93234] INQUIRE on pre-assigned files of ROUND and SIGN properties fails

2020-01-18 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93234 --- Comment #5 from urbanjost at comcast dot net --- Thanks! If it can be easily backported that would be even better from my perspective.

[Bug fortran/93234] INQUIRE on pre-assigned files of ROUND and SIGN properties fails

2020-01-12 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93234 --- Comment #2 from urbanjost at comcast dot net --- Created attachment 47641 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47641=edit NAMELIST dumper of all INQUIRE parameters I did not see anything else undefined. I had to chop it d

[Bug fortran/93234] New: INQUIRE on pre-assigned files of ROUND and SIGN properties fails

2020-01-11 Thread urbanjost at comcast dot net
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Cannot call INQUIRE() on pre-assigned files for properties ROUND and SIGN fails with an internal error. The simplest case

[Bug fortran/92785] New: expressions passed as real arguments to a dummy polymorphic argument fail with indexing error

2019-12-03 Thread urbanjost at comcast dot net
Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- I thought this was a duplicate of Bug 84074 at first. I could not find a way to tell when a fix

[Bug fortran/92114] equivalence in module causes ICE

2019-10-27 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92114 --- Comment #3 from urbanjost at comcast dot net --- I could not get the code to compile at all with 7.4.0 trying a variety of compiler switches with 7.4.0. This was in a Cygwin environment. I reinstalled the Cygwin environment and still got

[Bug fortran/92114] New: equivalence in module causes ICE

2019-10-15 Thread urbanjost at comcast dot net
Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- module minimal implicit none logical,private :: help,h,version,v equivalence (help,h),(version,v) end module minimal GNU Fortran (GCC) 7.4.0 gfortran bug.f90 f951: internal

[Bug fortran/92006] storage_size() returns incorrect value on unlimited polymorphic variable (CLASS(*)) when passed a CHARACTER variable

2019-10-07 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92006 --- Comment #3 from urbanjost at comcast dot net --- (In reply to kargl from comment #2) > Depends on, if not a duplicate, of 84006 84006 is showing an ICE when calling STORAGE_SIZE() with an unallocated variable, which I believe is invalid c

[Bug fortran/92006] storage_size() returns incorrect value on unlimited polymorphic variable (CLASS(*)) when passed a CHARACTER variable

2019-10-06 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92006 --- Comment #1 from urbanjost at comcast dot net --- I expect the following call to storage_size() to return the value 80 whether called from within a select or not. I did not see the same issue with any other type, including a type

[Bug fortran/92006] New: storage_size() returns incorrect value on unlimited polymorphic variable (CLASS(*)) when passed a CHARACTER variable

2019-10-06 Thread urbanjost at comcast dot net
: 7.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: ---

[Bug fortran/91686] New: ICE in gimplify:2554

2019-09-06 Thread urbanjost at comcast dot net
: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- program shuf implicit none character(len=:),allocatable :: pageout(:) integer :: i pageout=[character(len=20) :: 'a','bbb','c'] pageout=pageout

[Bug fortran/91544] New: When initializing allocatable character array get "Error: size of variable 'A.0' is too large"

2019-08-25 Thread urbanjost at comcast dot net
NCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- If use a non-constant integer as the length for an allocatable character variable

[Bug fortran/91039] LHS size to small to hold RHS but no error

2019-06-30 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91039 --- Comment #2 from urbanjost at comcast dot net --- After posting this for comment on the Fortran newsgroup I realize this is not technically a bug, but I would like it to remain as an enhancement request that this type of bug be reported when

[Bug fortran/91039] LHS size to small to hold RHS but no error

2019-06-30 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91039 --- Comment #1 from urbanjost at comcast dot net --- implicit none integer :: fx1(10)=1 integer :: fx2(20)=2 integer,allocatable :: a(:) a=-fx1 ! I would expect errors like "different shape for array assignment" where indicated? a

[Bug fortran/91039] New: LHS size to small to hold RHS but no error

2019-06-30 Thread urbanjost at comcast dot net
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: ---

[Bug fortran/90350] New: ubound ICE on assumed size array even though explicit bound is specified

2019-05-04 Thread urbanjost at comcast dot net
: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Created attachment 46291 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46291=edit call UBOUND(3f) with an assu

[Bug fortran/90344] New: small code that compiles and runs in 7.3.0 but not 7.4.1

2019-05-04 Thread urbanjost at comcast dot net
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Created attachment 46288 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46288=edit minimal test case that still causes segfa

[Bug fortran/89821] New: Get a SIGFPE on a simple test of a kind=real128 variable with -ffpe-trap=invalid switch

2019-03-25 Thread urbanjost at comcast dot net
Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Created attachment 46019 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46019=edit test prog

[Bug fortran/89782] New: Can do an internal READ of a character array when it is a parameter, but not a scalar character parameter

2019-03-20 Thread urbanjost at comcast dot net
: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Inconsistently, a scalar parameter CHARACTER variable fails with an internal READ

[Bug fortran/89783] New: Can do an internal READ of a character array when it is a parameter, but not a scalar character parameter

2019-03-20 Thread urbanjost at comcast dot net
: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Inconsistently, a scalar parameter CHARACTER variable fails with an internal READ

[Bug fortran/89344] uncaught programmer error: polymorphic variable is INTENT(IN) but assigned to without error

2019-02-18 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89344 --- Comment #5 from urbanjost at comcast dot net --- That was fast. Thanks!

[Bug fortran/89344] uncaught programmer error: polymorphic variable is INTENT(IN) but assigned to without error

2019-02-13 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89344 urbanjost at comcast dot net changed: What|Removed |Added Keywords||diagnostic

[Bug fortran/89344] New: intent

2019-02-13 Thread urbanjost at comcast dot net
at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: ---

[Bug fortran/83246] internal compiler error or loader problem might be related to a PARAMETER statement being in a BLOCK

2019-02-03 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83246 --- Comment #7 from urbanjost at comcast dot net --- Thanks!

[Bug c/86667] [7/8/9 Regression] can no longer traverse environment table

2018-07-26 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86667 --- Comment #7 from urbanjost at comcast dot net --- Did not mean to get a debug session for the code. The code had been working for several years and "broke" when I updated gfortran (and incidently, gcc). Thanks to everyone for lookin

[Bug fortran/86667] can no longer traverse environment table

2018-07-24 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86667 --- Comment #1 from urbanjost at comcast dot net --- Created attachment 44434 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44434=edit C code for interfacing to Fortran for printing environment table

[Bug fortran/86667] New: can no longer traverse environment table

2018-07-24 Thread urbanjost at comcast dot net
Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Created attachment 44433 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44433=edit fortran module and example program that used to print environment table Program co

[Bug fortran/86666] New: Can no longer traverse and read process environment table

2018-07-24 Thread urbanjost at comcast dot net
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: ---

[Bug fortran/66694] Failure in function returning an allocated CHARACTER array

2018-05-20 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66694 --- Comment #9 from urbanjost at comcast dot net --- Thanks! -Original Message- From: pault at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] Sent: Sunday, May 20, 2018 6:00 AM To: urbanj...@comcast.net Subject: [Bug fortran/66694

[Bug fortran/85581] New: implied DO not initializing array as expected

2018-04-30 Thread urbanjost at comcast dot net
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- I expect the two functions to be equivalent, but returnarrB acts like (char(64+isize),I=1,isize) instead of (char(64+i),I=1,isize) was specified??? program uuidgen

[Bug fortran/85566] New: LEN() intrinsic returns zero when given zero-sized array

2018-04-28 Thread urbanjost at comcast dot net
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- The following code returns "10,0" instead of "10,20" program test_len character(len=:), allocatabl

[Bug fortran/85565] New: LEN() intrinsic returns zero when given zero-sized array

2018-04-28 Thread urbanjost at comcast dot net
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- The following code returns "10,0" instead of "10,20" program test_len character(len=:), allocatabl

[Bug fortran/83560] list-directed formatting of INTEGER is missing plus on output when output open with SIGN='PLUS'

2017-12-24 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83560 --- Comment #6 from urbanjost at comcast dot net --- Thanks! As always, I am astonished at what has been accomplished. Fortran's viability itself depends so much on the availability of an open compiler.

[Bug fortran/83560] list-directed formatting of INTEGER is missing plus on output when output open with SIGN='PLUS'

2017-12-23 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83560 --- Comment #4 from urbanjost at comcast dot net --- Yes - just to confirm, I only found a problem with the missing plus with INTEGER values printed without an explicit format. Everything I tried with floating-point values (REAL and COMPLEX

[Bug fortran/83560] list-directed formatting of INTEGER is missing plus on output when output open with SIGN='PLUS'

2017-12-22 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83560 --- Comment #2 from urbanjost at comcast dot net --- Created attachment 42958 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42958=edit NAMELIST integers exhibit same problem PS: An INTEGER in a NAMELIST shows the same issue (miss

[Bug fortran/83561] New: list-directed output of an integer missing plus (+) sign when output open with SIGN="PLUS"

2017-12-22 Thread urbanjost at comcast dot net
NCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- List-directed print of an integer is missing a leading plus-sign when output file is open with

[Bug fortran/83560] New: list-directed formatting of INTEGER is missing plus on output when output open with SIGN='PLUS'

2017-12-22 Thread urbanjost at comcast dot net
Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- List-directed print of an integer is missing a leading plus-sign when output file is open with SIGN

[Bug fortran/83522] New: gfortran is sometimes confused between what is an element range and what is a character range

2017-12-20 Thread urbanjost at comcast dot net
Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- In the attachment: If I try to print any range of elements of the array other than all of them

[Bug fortran/83282] New: missing comma in format changes output

2017-12-04 Thread urbanjost at comcast dot net
Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- I (accidently) used a GNU/gfortran extension, leaving a comma out of a format. The output changed unexpectedly. The description of the extension seems to indicate

[Bug fortran/83224] creating character array from elements shorter than declared does not pad with whitespace properly and aborts

2017-12-01 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83224 --- Comment #10 from urbanjost at comcast dot net --- Impressively quick resolution. Thanks again!

[Bug fortran/83246] internal compiler error or loader problem might be related to a PARAMETER statement being in a BLOCK

2017-12-01 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83246 --- Comment #3 from urbanjost at comcast dot net --- Created attachment 42772 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42772=edit shorter case for internal compiler error

[Bug fortran/83246] internal compiler error or loader problem might be related to a PARAMETER statement being in a BLOCK

2017-12-01 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83246 --- Comment #2 from urbanjost at comcast dot net --- Created attachment 42771 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42771=edit shorter case for just getting loader error

[Bug fortran/83246] New: internal compiler error or loader problem might be related to a PARAMETER statement being in a BLOCK

2017-12-01 Thread urbanjost at comcast dot net
: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Created attachment 42769 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42769=edit cre

[Bug fortran/83224] creating character array from elements shorter than declared does not pad with whitespace properly and aborts

2017-11-30 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83224 --- Comment #2 from urbanjost at comcast dot net --- Thanks for checking on this so quickly. I did not reduce my example any further than I did because it would just print without padding with blanks the way I expected and not abort if I made

[Bug fortran/83224] New: creating character array from elements shorter than declared does not pad with whitespace properly and aborts

2017-11-29 Thread urbanjost at comcast dot net
Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- I expect this program to produce at the end

[Bug fortran/83057] OPEN(3f) without a filename and without STATUS='SCRATCH' does not produce a warning as being an extension on unassigned files

2017-11-20 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83057 --- Comment #2 from urbanjost at comcast dot net --- A long-standing convention when referencing procedures anprd commands, especially on Unix platforms is to suffix them with (category[group]) to distinguish them from English words

[Bug fortran/83057] New: OPEN(3f) without a filename and without STATUS='SCRATCH' does not produce a warning as being an extension on unassigned files

2017-11-19 Thread urbanjost at comcast dot net
Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- The standard states if a unconnected file

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

2017-10-08 Thread urbanjost at comcast dot net
Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Created attachment 42326 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42326=edit sam

[Bug libfortran/82233] [6/7/8 Regression] execute_command_line causes program to stop when command fails (or does not exist)

2017-09-17 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233 --- Comment #3 from urbanjost at comcast dot net --- Created attachment 42193 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42193=edit specifically even if cmdstat option present, must have cmdmsg or get failure, and man(1) page ne

[Bug fortran/82233] New: execute_command_line causes program to stop when command fails (or does not exist)

2017-09-17 Thread urbanjost at comcast dot net
Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Created attachment 42191 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42191=edit samp

[Bug fortran/82232] New: execute_command_line causes program to stop when command fails (or does not exist)

2017-09-17 Thread urbanjost at comcast dot net
Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: ---

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

2017-08-15 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 --- Comment #34 from urbanjost at comcast dot net --- It still occurs with Cygwin 2.8.2, which comes with gfortran 5.4.0, which is the latest version of CygWin, if that is of any help. -Original Message- From: dominiq at lps dot ens.fr

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

2017-08-03 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 --- Comment #31 from urbanjost at comcast dot net --- It may be of interest that the original application where this was encountered was changed to use modules, which I have had no similar problem with on Cygwin; but that the bug1.sh attachment

[Bug fortran/77506] New: stamdard for f2008 does not allow CHARACTER(LEN=*) in array constructor

2016-09-06 Thread urbanjost at comcast dot net
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- I posted to fortran.comp.org a question on whether LEN=* was allowed in an array constructor. The concensus

[Bug fortran/77505] New: Negative character length not treated as LEN=0

2016-09-06 Thread urbanjost at comcast dot net
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- From section 4.4.5.2-5 of the f2008 standard, I think negative character lengths should be treated as LEN=0. In the following sample, if I enter a negative value the code

[Bug fortran/77504] "is used uninitialized" with allocatable string and array constructors

2016-09-06 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504 urbanjost at comcast dot net changed: What|Removed |Added CC||urbanjost at comcast dot

[Bug fortran/77391] gfortran allows CHARACTER(LEN=:),PARAMETER:: STRING='constant' buts does not report it as an extension

2016-09-05 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77391 --- Comment #8 from urbanjost at comcast dot net --- Thanks. The asterick in this case and when used to initialize allocatable character variables does not fit my old rule of thumb that "an asterick means the variable is allocated and has a

[Bug fortran/77391] New: gfortran allows CHARACTER(LEN=:),PARAMETER:: STRING='constant' buts does not report it as an extension

2016-08-26 Thread urbanjost at comcast dot net
Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Created attachment 39501 --> https://gcc.gnu.org/bugzi

[Bug fortran/76490] when use -O2 -fcheck-founds compiler appears to hang and consumes all memory

2016-08-13 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76490 --- Comment #1 from urbanjost at comcast dot net --- Created attachment 39433 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39433=edit Smallest version of problem I could generate to reproduce problem

[Bug fortran/76490] New: when use -O2 -fcheck-founds compiler appears to hang and consumes all memory

2016-08-13 Thread urbanjost at comcast dot net
: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Routine that has compiled for years with gfortran 4.9.6 and older versions now hangs compiler when -O2 -fbound-checks

[Bug fortran/76488] New: when use -O2 -fcheck-founds compiler appears to hang and consumes all memory

2016-08-13 Thread urbanjost at comcast dot net
: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: ---

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

2015-09-14 Thread urbanjost at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 --- Comment #28 from urbanjost at comcast dot net --- This is still a problem with Cygwin 2.2.1 and gfortran 4.9.3 $ cygcheck --version cygcheck (cygwin) 2.2.1 System Checker for Cygwie $ gfortran --version GNU Fortran (GCC) 4.9.3 $ bash

[Bug fortran/67388] New: cannot compile function with SAVE in it with gfortran option -finit-real

2015-08-28 Thread urbanjost at comcast dot net
: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Created attachment 36264 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36264action=edit test code, test script

[Bug fortran/67367] New: Program crashes on READ(IOSTAT=IOS, ...) on directory OPEN()ed without error

2015-08-26 Thread urbanjost at comcast dot net
: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Created attachment 36257 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36257action=edit commands and their output

  1   2   >