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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031
urbanjost at comcast dot net changed:
What|Removed |Added
CC||urbanjost at comcast dot
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109226
urbanjost at comcast dot net changed:
What|Removed |Added
Resolution|--- |DUPLICATE
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. ***
: 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
: 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
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
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
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
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
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
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"
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
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
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&
: 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
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 of the
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.
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
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: urbanjost at comcast dot net
Target Milestone: ---
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&action=edit
single file source appears to be required to reproduce the
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 gfortra
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, at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507
--- Comment #4 from urbanjost at comcast dot net ---
Thanks! nice to have this fixed!
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
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&action=edit
exa
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
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
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
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.
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&action=edit
call date_and_time and p
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
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&action=edit
test using PACK(3f) intrinsic with allocatable variables
PACK() intrinsic is return
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: urbanjost at comcast dot net
Target Milestone: ---
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
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 of the
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.
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&action=edit
NAMELIST dumper of all INQUIRE parameters
I did not see anything else undefined. I had
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 is
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 is
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 the
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
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
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 such as
: 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: ---
: 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','
Status: UNCONFIRMED
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
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
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
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: urbanjost at comcast dot net
Target Milestone: ---
: 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&action=edit
call UBOUND(3f)
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&action=edit
minimal test case that still
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&action=edit
test
: 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,
but a
: 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,
but a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89344
--- Comment #5 from urbanjost at comcast dot net ---
That was fast. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89344
urbanjost at comcast dot net changed:
What|Removed |Added
Keywords||diagnostic
gcc dot gnu.org
Reporter: urbanjost at comcast dot net
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83246
--- Comment #7 from urbanjost at comcast dot net ---
Thanks!
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
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&action=edit
C code for interfacing to Fortran for printing environment table
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&action=edit
fortran module and example program that used to print environmen
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: urbanjost at comcast dot net
Target Milestone: ---
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
: 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
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
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
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.
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
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&action=edit
NAMELIST integers exhibit same problem
PS:
An INTEGER in a NAMELIST shows the sam
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
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
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
and
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 that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83224
--- Comment #10 from urbanjost at comcast dot net ---
Impressively quick resolution.
Thanks again!
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&action=edit
shorter case for internal compiler error
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&action=edit
shorter case for just getting loader error
: 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&acti
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 it
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
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 and to
oduct: gcc
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 unconnect
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&acti
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&action=edit
specifically even if cmdstat option present, must have cmdmsg or get failure,
and man(
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&action=edit
sam
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: urbanjost at comcast dot net
Target Milestone: ---
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
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
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 as that it is
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504
urbanjost at comcast dot net changed:
What|Removed |Added
CC||urbanjost at comcast dot
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
ion: 5.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: ---
Created attachment 39501
--> https://gcc.gnu
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&action=edit
Smallest version of problem I could generate to reproduce problem
: 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
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: urbanjost at comcast dot net
Target Milestone: ---
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
: 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=36264&action=edit
test code, test scr
: 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=36257&action=edit
commands an
1 - 100 of 116 matches
Mail list logo
