[Bug fortran/38282] New: Add the remaining HPF bit intrinsics
In 4.4, the LEADZ and TRAILZ intrinsics were added. LEADZ is one of the HPF intrinsics. However the other HPF bit intrinsics, POPCNT and POPPAR, were not included. POPCNT and POPPAR are present in many other compilers, and have usually been implemented along with LEADZ. This is because historically, POPCNT, POPPAR, and LEADZ were present in the Cray compilers to allow access to hardware instructions. So it is a little strange to see LEADZ without the others. Both POPCNT and POPPAR are also present in the F2008 draft. -- Summary: Add the remaining HPF bit intrinsics Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: w6ws at earthlink dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282
[Bug fortran/38282] Add the remaining HPF bit intrinsics
--- Comment #2 from w6ws at earthlink dot net 2008-11-27 19:32 --- Tobias, Steven, If you would like to usurp this request and use it to implement the complete set of F2008 bit intrinsics, please feel free to do so. For completeness, one other HPF bit intrinsic is ILEN - which counts the number of bits needed to represent an integer. This is not in the F2008 draft, but is occasionally useful. A few comments on the draft F2008 intrinsics: DSHIFTL/DSHIFTR - Cray-1 intrinsics. Occasionally handy. Represented the hardware vector "snake" instruction. SHIFTA - Lots of systems have this instruction in hardware, but not the Cray-1. So it went into the Cray compilers somewhat later. SHIFTL/SHIFTR - Cray-1 intrinsics. Better than ISHFT because the compiler always knows which shift instruction to generate. MASKL/MASKR - Shades of the MASK intrinsic on 60-bit CDC systems, which represented a hardware instruction. MERGE_BITS - On the Cray-1, it was called CSMG. Hardware instruction. One final instrinsic: IBCHNG. This was part of the old "Industrial Real-Time Fortran" Standard. IBCHNG allows the caller to 'flip' a specific bit to its complement. The IRTF bit intrinsics were the basis for the Milspec-1753 bit intrinsics, and then F90. But somehow IBCHNG got lost along the way. Nonetheless, a number of compilers (ifort, cray, sun, sgi, probably ibm, etc) also implement IBCHNG. (We could talk about the IRTF ISHL (logical shift), ISHA (arithmetic shift), and ISHC (circular shift) which are also implemented in some compilers. But since the F90 ISHFT and ISHFTC, and F2008 SHIFTA cover these cases in a Standard-conforming way, I would not recommend implementing them in gfortran.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282
[Bug fortran/36947] Attributes not fully checked comparing actual vs dummy procedure
--- Comment #8 from w6ws at earthlink dot net 2009-05-18 15:36 --- Subject: Re: Attributes not fully checked comparing actual vs dummy procedure Janus, janus at gcc dot gnu dot org wrote: > --- Comment #7 from janus at gcc dot gnu dot org 2009-05-18 09:36 --- > The commit in comment #6 implements the checking for intents. > > ToDo: > > * check for OPTIONAL > * better error messages > * recursive check (see comment #2) I was going to comment that OPTIONAL should be checked too, but you beat me to it. We have been having problems with both OPTIONAL and INTENT not being checked by various compilers. NAG, of course, does a better job than most in this area. It is good to see gfortran learn about this checking too. Thank you for your hard work on this! Walter -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36947
[Bug fortran/37712] New: Parent component name getting confused with structure constructor
The following test module creates two derived type, with the second extending
the first. Type-bound procedures for initialization are defined by both.
However when the init routine for the extended derived type attempts to call
the init routine in the parent type, via the parent component name, the
compiler gets confused. It thinks the parent component name is a structure
constructor and gives a fatal error:
module oo_mod
implicit none
type base_t
character(16) :: name
contains
procedure :: init=>base_init
end type
type x_t
integer :: value
contains
procedure :: init=>x_init
end type
contains
subroutine base_init (this, text)
type(base_t) :: this
character(*) :: text
this%name = text
end subroutine
subroutine x_init (this, text, value)
type(x_t) :: this
character(*) :: text
integer :: value
call base_t%init (text)
! or...
call base_init (base_t, text)
this%value = value
end subroutine
end module
[EMAIL PROTECTED]:/home/wws/fortran/oop> gfortran --version
GNU Fortran (GCC) 4.4.0 20081001 (experimental) [trunk revision 140806]
Copyright (C) 2008 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
[EMAIL PROTECTED]:/home/wws/fortran/oop> gfortran -c parent.f90
parent.f90:31.15:
call base_t%init (text)
1
Error: Syntax error in CALL statement at (1)
parent.f90:33.26:
call base_init (base_t, text)
1
Error: Syntax error in structure constructor at (1)
parent.f90:7.13:
procedure :: init=>base_init
1
Warning: Polymorphic entities are not yet implemented, non-polymorphic
passed-ob
ject dummy argument of 'base_init' at (1) accepted
parent.f90:13.13:
procedure :: init=>x_init
1
Warning: Polymorphic entities are not yet implemented, non-polymorphic
passed-ob
ject dummy argument of 'x_init' at (1) accepted
[EMAIL PROTECTED]:/home/wws/fortran/oop>
--
Summary: Parent component name getting confused with structure
constructor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37712
[Bug fortran/37712] Parent component name getting confused with structure constructor
--- Comment #3 from w6ws at earthlink dot net 2008-10-02 13:06 --- Subject: Re: Parent component name getting confused with structure constructor Yes, my example is messed up. My excuse is that it was late and I was tired. Next time I will verify against NAG first. Please close this ticket. Walter -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37712
[Bug fortran/37712] Parent component name getting confused with structure constructor
--- Comment #4 from w6ws at earthlink dot net 2008-10-02 17:18 --- I am closing this report. -- w6ws at earthlink dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37712
[Bug fortran/35037] New: VOLATILE attribute not being honored with common block variable
The following code demonstrates that when optimization is turned on, the memory reference is being moved out of the loop. Thus, the volatile attribute is not being honored. As a workaround (and perhaps better solution), the user could use a module instead of a common block. Gfortran works ok in the case of module variables. The below example is from x86 cygwin. But the same thing happens with x86_64 Linux on the current trunk. $ cat vol.f subroutine wait4it () implicit none logical event volatile event common /xyzzy/ event do if (event) exit end do end subroutine $ gfortran -O -S vol.f $ cat vol.s .file "vol.f" .text .globl _wait4it_ .def_wait4it_; .scl2; .type 32; .endef _wait4it_: pushl %ebp movl%esp, %ebp cmpl$0, _xyzzy_ jne L4 L5: jmp L5 L4: popl%ebp ret .comm _xyzzy_, 16 # 4 $ $ gfortran --version GNU Fortran (GCC) 4.3.0 20071222 (experimental) [trunk revision 127783] Copyright (C) 2007 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $ -- Summary: VOLATILE attribute not being honored with common block variable Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: w6ws at earthlink dot net GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35037
[Bug fortran/35037] VOLATILE attribute not being honored with common block variable
--- Comment #1 from w6ws at earthlink dot net 2008-01-31 03:09 --- Adding myself to the cc list. -- w6ws at earthlink dot net changed: What|Removed |Added CC||w6ws at earthlink dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35037
[Bug fortran/35037] VOLATILE attribute not being honored with common block variable
--- Comment #7 from w6ws at earthlink dot net 2008-02-05 01:25 --- Subject: Re: VOLATILE attribute not being honored with common block variable Gosh - one learns something everyday. The bit with EQUIVALENCE is an interesting twist! It seems that F2003 would allow maximum flexibility. One of my complaints about VOLATILE has been that it is too 'strong'. The attribute lasts over the entire scope of the variable - whereas one might only need to ensure coherency with an external process at a specific point in the routine. (E.g., the spin loop in the example.) With the F2003 definition, one can use the name with the volatile attribute at that point, yet use its alias for maximum optimization at other places. So I actually like the F2003 definition and would prefer that the non-VOLATILEd name did not get the attribute. Walter -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35037
[Bug fortran/35395] New: Invalid-accepted - public entity with private type should be diagnosed
The following test case should be diagnosed as an error. This is because the type definition (e.g, X_t) is private, but the entity defined with it (abc) is public. module xyzzy implicit none private type X_t real :: y real :: z end type private :: X_t type(X_t), parameter, public :: abc = X_t (12.34, 56.78) end module This was observed with several versions of gfortran, including the 4.1.0 IA64 release, the 4.3.0 20081222 snapshot for x86 windows, and the 4.4.0 20080219 snapshot for x86_64 linux. Both ifort 10.1 and SGI IRIX f90 correctly reject the code. Interestingly, Salford 5.10 (wrongly) accepts it. -- Summary: Invalid-accepted - public entity with private type should be diagnosed Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: w6ws at earthlink dot net GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35395
[Bug fortran/35395] Invalid-accepted - public entity with private type should be diagnosed
--- Comment #1 from w6ws at earthlink dot net 2008-02-27 18:30 --- Add keywords -- w6ws at earthlink dot net changed: What|Removed |Added Keywords||accepts-invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35395
[Bug fortran/35395] Invalid-accepted - public entity with private type should be diagnosed
--- Comment #4 from w6ws at earthlink dot net 2008-03-24 17:47 --- Subject: Re: Invalid-accepted - public entity with private type should be diagnosed pault at gcc dot gnu dot org wrote: > > This is permitted in F2003 so you have to apply the F95 standard to extract > the > message out of gfortran: OK, I have researched this further, and concur with your response. In fact, MR&C 95/2003 discusses this in section 18.14. (I finally bought a copy last week...) So you may close the PR. However it would also be nice if at least the following web pages were updated to show that the feature is now supported: http://gcc.gnu.org/wiki/GFortran#news http://gcc.gnu.org/wiki/Fortran2003 http://gcc.gnu.org/wiki/Fortran2003Status Thank you, Walter -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35395
[Bug fortran/39505] New: Consider a 'no arg check' directive
A few compilers support a 'no arg check' compiler directive which tells the
compiler to ignore type/kind/rank checking on specified arguments. This is
useful when routines have 'generic' arguments which are simply passed on to
other routines. Two compilers which support this feature are ifort, with the
'!dec$ attributes no_arg_check' directive, and MIPSpro f90, with the '!dir$
ignore_tkr' directive.
For example, in the Message Passing Interface (MPI), the send and receive
buffer arguments are typically 'choice' arguments which can have any type.
This makes it difficult to write interface blocks to help validate the
remaining arguments (and allow keyword=value usage for better self-documenting
code.) Using the Intel compiler directive, an interface block could be written
as follows:
interface
subroutine mpi_send (BUF, COUNT, DATATYPE, DEST, TAG, COMM, IERROR)
implicit none
integer :: BUF(*)
!dec$ attributes no_arg_check::buf
integer, intent(in) :: COUNT, DATATYPE, DEST, TAG, COMM
integer, intent(out) :: IERROR
end subroutine
end interface
The alternative to this is to do as OpenMPI does and generate dozens of
specific 'glue' routines, and tie them together under a generic name.
(Tedious, less so by using a preprocessor.) Or to not have explicit interfaces
at all, at least for routines with 'choice' arguments, and get no argument
checking at all. (In most cases, the current status quo.)
--
Summary: Consider a 'no arg check' directive
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39505
[Bug fortran/39505] Consider a 'no arg check' directive
--- Comment #3 from w6ws at earthlink dot net 2009-03-20 02:13 --- Subject: Re: Consider a 'no arg check' directive Gents, I was unaware of Bills TR proposal for a TYPE(*). This is good news, and would totally solve the problem. BTW, the no_arg_check directive actually works pretty well in practice. But I agree that if a TR to address the problem is within sight, gfortran should wait for that. Walter -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39505
[Bug fortran/39988] New: F2008: Default initialization, structure constructors, and allocatable components
Consider the following test case:
program defallocatable
implicit none
! Demonstrate structure constructors with default initialization
! and allocatable arrays. (Unspecified in F2003, initialized to
! unallocated in F2008.)
type mytype_t
integer, allocatable :: data(:)
end type
type(mytype_t) :: my_object
my_object = mytype_t ()
print *, 'allocated =', allocated (my_object%data)
end program
When compiling with gfortran, we get:
$ gfortran defallocatable.f90
defallocatable.f90:14.25:
my_object = mytype_t ()
1
Error: No initializer for component 'data' given in the structure constructor
at (1)!
$
This may be a valid error in F2003. In F2003 section 4.5.9 paragraph 3, it
states that "If a component with default initialization has no corresponding
component-data-source, then the default initialization is applied to that
component." But when a component is allocatable, it is not legal to specify
a component-data-source. This creates a difference in how default
initialization
works with structure constructors, and other places where default
initialization
must take place.
In F2008 the above paragraph, this time in section 4.5.10 paragraph 3, adds:
"If an allocatable component has no corresponding component-data-source,
then that component has an allocation status of unallocated." This closes
the hole and makes default initialization of allocatable components in
structure constructors work like it does everywhere else.
So this enhancement request is to consider gfortran allow the code to compile
under the F2008 semantics (which are seemingly undefined in F2003.)
FWIW, g95 and ifort have the same problem.
--
Summary: F2008: Default initialization, structure constructors,
and allocatable components
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39988
[Bug fortran/57639] New: ICE with polymorphism (and illegal code)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57639 Bug ID: 57639 Summary: ICE with polymorphism (and illegal code) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: w6ws at earthlink dot net Bug encountered with a snapshot of todays (June 17, 2013) trunk. The example compiles ok with 'allocatable' attribute specified (and the related allocate statement used) for variables t1 and t2. However if the allocatable attribute is omitted, (and allocate statement removed), gfortran gives a correct error message and then ICEs. module class_mod implicit none contains function compare (a, b) class(*), intent(in), allocatable :: a, b logical :: compare compare = SAME_TYPE_AS (a, b) end function end module program unlimited_test use class_mod implicit none type wws integer :: a, b end type ! When t1 and t2 are given the 'allocatable' attribute, ! and the allocate statement is used, this example compiles ! and runs correctly. However if the 'allocatable' attribute ! and the allocate statement are removed, the compiler issues ! the correct error message and then ICEs. class(*) :: t1, t2 ! allocate (wws::t1, t2) print *, 'main: compare = ', compare (t1, t2) end program wws@w6ws-4:~/fortran/f2008$ gfortran --version GNU Fortran (GCC) 4.9.0 20130617 (experimental) Copyright (C) 2013 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING wws@w6ws-4:~/fortran/f2008$ gfortran -c unlimited_test.f90 unlimited_test.f90:29.16: class(*) :: t1, t2 1 Error: CLASS variable 't1' at (1) must be dummy, allocatable or pointer unlimited_test.f90:29.20: class(*) :: t1, t2 1 Error: CLASS variable 't2' at (1) must be dummy, allocatable or pointer f951: internal compiler error: Segmentation fault 0x96fcaf crash_signal ../../gcc-trunk/gcc/toplev.c:333 0x53a009 compare_parameter ../../gcc-trunk/gcc/fortran/interface.c:1982 0x53a009 compare_actual_formal ../../gcc-trunk/gcc/fortran/interface.c:2567 0x53ad33 gfc_procedure_use(gfc_symbol*, gfc_actual_arglist**, locus*) ../../gcc-trunk/gcc/fortran/interface.c:3269 0x585fe0 resolve_specific_f0 ../../gcc-trunk/gcc/fortran/resolve.c:2612 0x585fe0 resolve_specific_f ../../gcc-trunk/gcc/fortran/resolve.c:2637 0x585fe0 resolve_function ../../gcc-trunk/gcc/fortran/resolve.c:2905 0x585fe0 gfc_resolve_expr(gfc_expr*) ../../gcc-trunk/gcc/fortran/resolve.c:6083 0x58bd2b resolve_code ../../gcc-trunk/gcc/fortran/resolve.c:9685 0x58ba7b gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:8998 0x58bd09 resolve_code ../../gcc-trunk/gcc/fortran/resolve.c:9675 0x58e8be resolve_codes ../../gcc-trunk/gcc/fortran/resolve.c:14464 0x57fe82 gfc_resolve ../../gcc-trunk/gcc/fortran/resolve.c:14492 0x5749aa resolve_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:4442 0x5749aa gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:4691 0x5b0a45 gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:189 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. wws@w6ws-4:~/fortran/f2008$
[Bug fortran/51976] [F2003] Support deferred-length character components of derived types (allocatable string length)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976
Walter Spector changed:
What|Removed |Added
CC||w6ws at earthlink dot net
--- Comment #12 from Walter Spector ---
Adding myself (Walter Spector) to the cc list. My contribution is a simple
little test case that works with current versions of Intel (with -assume
realloc_lhs option) and NAG. As of todays gfortran snapshot (20130828), I get
a lot of 'Deferred-length character component 'city' at (1) is not yet
supported' errors.
program city_names
implicit none
type city_entry_t
character(:), allocatable :: city
character(:), allocatable :: state
end type
type(city_entry_t), allocatable :: cities(:)
integer :: i
cities = (/ &
city_entry_t ("San Francisco", "California"), &
city_entry_t ("Portland", "Oregon"), &
city_entry_t ("Seattle", "Washington"), &
city_entry_t ("Salt Lake City", "Utah"), &
city_entry_t ("Reno", "Nevada"), &
city_entry_t ("Tucson", "Arizona"), &
city_entry_t ("Denver", "Colorado"), &
city_entry_t ("Kansas City","Kansas"), &
city_entry_t ("Tulsa", "Oklahoma"), &
city_entry_t ("Houston", "Texas") &
/)
print '(5a)', (">",cities(i)%city, ", ", cities(i)%state,"<", i=1,size
(cities))
end program
[Bug fortran/48820] TR 29113: Implement parts needed for MPI 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48820 --- Comment #6 from Walter Spector 2012-02-29 15:58:10 UTC --- Tobias, If you are interested, I tried the patch you posted on the email list to a freshly checked out trunk. After building the compiler, I tried the following small test case: module mpi_interface implicit none interface mpi_send subroutine MPI_Send (buf, count, datatype, dest, tag, comm, ierr) type(*), intent(in) :: buf(:) integer, intent(in) :: count integer, intent(in) :: datatype integer, intent(in) :: dest integer, intent(in) :: tag integer, intent(in) :: comm integer, intent(out):: ierr end subroutine end interface end module The compiler gave the following error: mpi_interface.F90:16.10: end module 1 Internal Error at (1): gfc_code2string(): Bad code If I change the 'buf(:)' to 'buf(*)' I get the same error. Hope this helps, Walter
[Bug fortran/52564] New: Accepts invalid: Missing I/O list after comma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52564 Bug #: 52564 Summary: Accepts invalid: Missing I/O list after comma Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: w...@earthlink.net In the following test case, gfortran does not diagnose the missing I/O list after the comma in the print statement: program printbug print *, 'hello world' ! the following line should not compile: print *, end program Other compilers do diagnose it. First noticed on 4.6.1, but is also a problem with 4.8 snapshot.
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 --- Comment #8 from Walter Spector 2012-03-15 17:24:59 UTC --- Should this bug report number be added to the F2003 meta bug? (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585)
[Bug fortran/48820] TR 29113: Implement parts needed for MPI 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48820 Walter Spector changed: What|Removed |Added CC||w6ws at earthlink dot net --- Comment #4 from Walter Spector 2011-12-13 20:04:48 UTC --- Added myself to the cc list. (Interested in the assumed rank and assumed type portions.)
[Bug fortran/51589] New: Modification of loop index variable by intent(out) or intent(inout) procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51589 Bug #: 51589 Summary: Modification of loop index variable by intent(out) or intent(inout) procedures Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: w...@earthlink.net In the following snippet of code, the loop index variable is passed to procedures via either intent(out) or intent(inout) dummy arguments. In the first of these cases, intent(out), gfortran should give a "Variable 'i' at (1) cannot be redefined inside loop" error but does not. Even with --pedantic. It is arguable whether the second should give the same error, or just a warning. Note that Intel 12.1 gives warnings for both usages. The resulting code only runs for one iteration. With gfortran, it ends up in an infinite loop. wws@w6ws-4:~/fortran/intents$ cat intents.f90 program intents implicit none integer :: i do, i=1,10 call sub1 (i) print *, i call sub2 (i) print *, i end do contains subroutine sub1 (idx) integer, intent(inout) :: idx idx = 42 end subroutine subroutine sub2 (idx) integer, intent(out) :: idx idx = 11 end subroutine end program wws@w6ws-4:~/fortran/intents$ gfortran --pedantic intents.f90 wws@w6ws-4:~/fortran/intents$ gfortran --version GNU Fortran (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING wws@w6ws-4:~/fortran/intents$
[Bug fortran/51589] Modification of loop index variable by intent(out) or intent(inout) procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51589 --- Comment #1 from Walter Spector 2011-12-16 21:32:55 UTC --- Sorry - my description is backwards from the test case. The first is intent(inout), and should probably give a warning. The second is intent(out) and should give an error.
[Bug fortran/51589] Modification of loop index variable by intent(out) or intent(inout) procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51589 --- Comment #2 from Walter Spector 2011-12-16 22:37:44 UTC --- No error messages from Absoft (v9), g95, or PGI (v11.10). All print the revised version of i, but only perform 10 iterations. NAG (5.2 edit 721) considers the intent(out) to be an error. No warning for the intent(inout).
[Bug fortran/51589] Modification of loop index variable by intent(out) or intent(inout) procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51589 --- Comment #5 from Walter Spector 2011-12-17 19:04:12 UTC --- It seems like intent information should be available when the procedures are USE associated, as opposed to the internal procedures. However gfortran does not diagnose that case either. Here is an expanded test case: module intent_mod implicit none contains subroutine submod1 (idx) integer, intent(inout) :: idx idx = 42 end subroutine subroutine submod2 (idx) integer, intent(out) :: idx idx = 11 end subroutine end module program intents use intent_mod implicit none integer :: i do, i=1,10 call sub1 (i) print *, i call sub2 (i) print *, i call submod1 (i) print *, i call submod2 (i) print *, i end do contains subroutine sub1 (idx) integer, intent(inout) :: idx idx = 42 end subroutine subroutine sub2 (idx) integer, intent(out) :: idx idx = 11 end subroutine end program
[Bug fortran/85541] New: ICE with parameterized derived type (PDT) and allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85541 Bug ID: 85541 Summary: ICE with parameterized derived type (PDT) and allocate Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: w6ws at earthlink dot net Target Milestone: --- The following test case causes an ICE when the allocate statement is present. This was first noticed with an older development snapshot. However I updated my compiler to a snapshot of todays trunk and still shows the problem. wws@w6ws-4:/rootsda5/home/wws/fortran/pdt$ cat charptr.f90 module char_kinds implicit none type charptr(clen) integer, len :: clen character(clen), pointer :: cptr(:) => null() end type end module program charptr_test use char_kinds implicit none type (charptr(clen=:)), allocatable :: mychars allocate (mychars) ! ICEes with this, compiles without it end program wws@w6ws-4:/rootsda5/home/wws/fortran/pdt$ /usr/local/gcc-trunk/bin/gfortran --version GNU Fortran (GCC) 9.0.0 20180426 (experimental) Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. wws@w6ws-4:/rootsda5/home/wws/fortran/pdt$ /usr/local/gcc-trunk/bin/gfortran -c charptr.f90 charptr.f90:17:0: allocate (mychars) internal compiler error: Segmentation fault 0xce260f crash_signal ../../gcc-trunk/gcc/toplev.c:325 0x693b2c insert_parameter_exprs ../../gcc-trunk/gcc/fortran/decl.c:3337 0x6b1390 gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*, gfc_symbol*, int*), int) ../../gcc-trunk/gcc/fortran/expr.c:4731 0x76e145 structure_alloc_comps ../../gcc-trunk/gcc/fortran/trans-array.c:9054 0x772850 gfc_allocate_pdt_comp(gfc_symbol*, tree_node*, int, gfc_actual_arglist*) ../../gcc-trunk/gcc/fortran/trans-array.c:9391 0x7ea98a gfc_trans_allocate(gfc_code*) ../../gcc-trunk/gcc/fortran/trans-stmt.c:6604 0x7542b7 trans_code ../../gcc-trunk/gcc/fortran/trans.c:1996 0x788f45 gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.c:6507 0x7081d0 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:6121 0x7081d0 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:6324 0x75107f gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:204 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. wws@w6ws-4:/rootsda5/home/wws/fortran/pdt$
[Bug fortran/85547] New: Run-time error: character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85547 Bug ID: 85547 Summary: Run-time error: character array constructor Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: w6ws at earthlink dot net Target Milestone: --- The following compiles with gfortran (v4.8.4, 5.4, and a snapshot of todays 9.0), but abends at run-time. Note there are actually two problems shown here: First, the passed in string size is bad. It should be '16', not the length of the first element. Second, the deallocations after the call fail - which cause the abend. This test case runs fine with NAG and PGI. (I've not tried Intel yet, but I can if needed.) wws@w6ws-4:/tmp$ cat testch.f90 program testch implicit none character(10) :: path path = 'xyz/' call print_strings ((/ character(16) :: & trim(path) // "one", & trim(path) // "three", & trim(path) // "five", & trim(path) // "eight", & trim(path) // "forty two" /) ) contains subroutine print_strings (s) character(*), intent(in) :: s(:) integer :: i do, i=1, size(s) print *, i, '>', s(i), '<' end do end subroutine end program wws@w6ws-4:/tmp$ /usr/local/gcc-trunk/bin/gfortran --version GNU Fortran (GCC) 9.0.0 20180426 (experimental) Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. wws@w6ws-4:/tmp$ /usr/local/gcc-trunk/bin/gfortran -g testch.f90 Running under gdb: wws@w6ws-4:/tmp$ gdb a.out GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from a.out...done. (gdb) run Starting program: /tmp/a.out 1 >xyz/one< 2 >xyz/thr< 3 >xyz/fiv< 4 >xyz/eig< 5 >xyz/for< *** Error in `/tmp/a.out': free(): invalid next size (fast): 0x00605640 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x76eb87e5] /lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x76ec137a] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x76ec553c] /tmp/a.out[0x4012d9] /tmp/a.out[0x40131e] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x76e61830] /tmp/a.out[0x4008b9] === Memory map: 0040-00402000 r-xp 08:0a 40632824 /tmp/a.out 00601000-00602000 rw-p 1000 08:0a 40632824 /tmp/a.out 00602000-00623000 rw-p 00:00 0 [heap] 7000-70021000 rw-p 00:00 0 70021000-7400 ---p 00:00 0 76e41000-77001000 r-xp 08:0a 20190243 /lib/x86_64-linux-gnu/libc-2.23.so 77001000-77201000 ---p 001c 08:0a 20190243 /lib/x86_64-linux-gnu/libc-2.23.so 77201000-77205000 r--p 001c 08:0a 20190243 /lib/x86_64-linux-gnu/libc-2.23.so 77205000-77207000 rw-p 001c4000 08:0a 20190243 /lib/x86_64-linux-gnu/libc-2.23.so 77207000-7720b000 rw-p 00:00 0 7720b000-7724a000 r-xp 08:0a 48497154 /usr/local/gcc-trunk/lib64/libquadmath.so.0.0.0 7724a000-77449000 ---p 0003f000 08:0a 48497154 /usr/local/gcc-trunk/lib64/libquadmath.so.0.0.0 77449000-7744a000 rw-p 0003e000 08:0a 48497154 /usr/local/gcc-trunk/lib64/libquadmath.so.0.0.0 7744a000-77461000 r-xp 08:0a 48497146 /usr/local/gcc-trunk/lib64/libgcc_s.so.1 77461000-7766 ---p 00017000 08:0a 48497146 /usr/local/gcc-trunk/lib64/libgcc_s.so.1 7766-77661000 rw-p 00016000 08:0a 48497146 /usr/local/gcc-trunk/lib64/libgcc_s.so.1 77661000-77769000 r-xp 08:0a 20185261
[Bug fortran/85547] Run-time error: character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85547 --- Comment #1 from Walter Spector --- Slightly different test case - using allocatable string length instead of the trims. However the same problems are evident: program testch implicit none character(:), allocatable :: path path = 'xyz/' call print_strings ((/ character(16) :: & path // "one", & path // "three", & path // "five", & path // "eight", & path // "forty two" /) ) contains subroutine print_strings (s) character(*), intent(in) :: s(:) integer :: i do, i=1, size(s) print *, i, '>', s(i), '<' end do end subroutine end program wws@w6ws-4:/tmp$ /usr/local/gcc-trunk/bin/gfortran -g testch.f90 wws@w6ws-4:/tmp$ a.out 1 >xyz/one< 2 >xyz/thr< 3 >xyz/fiv< 4 >xyz/eig< 5 >xyz/for< *** Error in `a.out': free(): invalid next size (fast): 0x0217b640 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fac7b49c7e5] /lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7fac7b4a537a] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fac7b4a953c] a.out[0x401280] a.out[0x4012c5] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fac7b445830] a.out[0x400949] === Memory map: 0040-00402000 r-xp 08:0a 40632824 /tmp/a.out 00601000-00602000 rw-p 1000 08:0a 40632824 /tmp/a.out 02178000-02199000 rw-p 00:00 0 [heap] 7fac7400-7fac74021000 rw-p 00:00 0 7fac74021000-7fac7800 ---p 00:00 0 7fac7b425000-7fac7b5e5000 r-xp 08:0a 20190243 /lib/x86_64-linux-gnu/libc-2.23.so 7fac7b5e5000-7fac7b7e5000 ---p 001c 08:0a 20190243 /lib/x86_64-linux-gnu/libc-2.23.so 7fac7b7e5000-7fac7b7e9000 r--p 001c 08:0a 20190243 /lib/x86_64-linux-gnu/libc-2.23.so 7fac7b7e9000-7fac7b7eb000 rw-p 001c4000 08:0a 20190243 /lib/x86_64-linux-gnu/libc-2.23.so 7fac7b7eb000-7fac7b7ef000 rw-p 00:00 0 7fac7b7ef000-7fac7b82e000 r-xp 08:0a 48497154 /usr/local/gcc-trunk/lib64/libquadmath.so.0.0.0 7fac7b82e000-7fac7ba2d000 ---p 0003f000 08:0a 48497154 /usr/local/gcc-trunk/lib64/libquadmath.so.0.0.0 7fac7ba2d000-7fac7ba2e000 rw-p 0003e000 08:0a 48497154 /usr/local/gcc-trunk/lib64/libquadmath.so.0.0.0 7fac7ba2e000-7fac7ba45000 r-xp 08:0a 48497146 /usr/local/gcc-trunk/lib64/libgcc_s.so.1 7fac7ba45000-7fac7bc44000 ---p 00017000 08:0a 48497146 /usr/local/gcc-trunk/lib64/libgcc_s.so.1 7fac7bc44000-7fac7bc45000 rw-p 00016000 08:0a 48497146 /usr/local/gcc-trunk/lib64/libgcc_s.so.1 7fac7bc45000-7fac7bd4d000 r-xp 08:0a 20185261 /lib/x86_64-linux-gnu/libm-2.23.so 7fac7bd4d000-7fac7bf4c000 ---p 00108000 08:0a 20185261 /lib/x86_64-linux-gnu/libm-2.23.so 7fac7bf4c000-7fac7bf4d000 r--p 00107000 08:0a 20185261 /lib/x86_64-linux-gnu/libm-2.23.so 7fac7bf4d000-7fac7bf4e000 rw-p 00108000 08:0a 20185261 /lib/x86_64-linux-gnu/libm-2.23.so 7fac7bf4e000-7fac7c1b8000 r-xp 08:0a 48497159 /usr/local/gcc-trunk/lib64/libgfortran.so.5.0.0 7fac7c1b8000-7fac7c3b8000 ---p 0026a000 08:0a 48497159 /usr/local/gcc-trunk/lib64/libgfortran.so.5.0.0 7fac7c3b8000-7fac7c3ba000 rw-p 0026a000 08:0a 48497159 /usr/local/gcc-trunk/lib64/libgfortran.so.5.0.0 7fac7c3ba000-7fac7c3bb000 rw-p 00:00 0 7fac7c3bb000-7fac7c3e1000 r-xp 08:0a 20190239 /lib/x86_64-linux-gnu/ld-2.23.so 7fac7c5b9000-7fac7c5bd000 rw-p 00:00 0 7fac7c5de000-7fac7c5e rw-p 00:00 0 7fac7c5e-7fac7c5e1000 r--p 00025000 08:0a 20190239 /lib/x86_64-linux-gnu/ld-2.23.so 7fac7c5e1000-7fac7c5e2000 rw-p 00026000 08:0a 20190239 /lib/x86_64-linux-gnu/ld-2.23.so 7fac7c5e2000-7fac7c5e3000 rw-p 00:00 0 7ffd9dc1f000-7ffd9dc4 rw-p 00:00 0 [stack] 7ffd9dd24000-7ffd9dd27000 r--p 00:00 0 [vvar] 7ffd9dd27000-7ffd9dd29000 r-xp 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x7fac7b45a4af in ??? #1 0x7fac7b45a428 in ??? #2 0x7fac7b45c029 in ??? #3 0x7fac7b49c7e9 in ??? #4 0x7fac7b4a5379 in ??? #5 0x7fac7b4a953b in ??? #6 0x40127f in testch at /tmp/testch.f90:11 #7 0x4012c4 in main at /tmp/testch.f90:11 Aborted (core dumped) wws@w6ws-4:/tmp$
[Bug fortran/85547] Run-time error: character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85547 --- Comment #2 from Walter Spector --- Third variant. This one messes up NAG and PGI too: wws@w6ws-4:/tmp$ cat testch3.f90 program testch implicit none character(:), allocatable :: path(:) path = 'xyz/' path = (/ character(16) :: & path // "one", & path // "three", & path // "five", & path // "eight", & path // "forty two" /) call print_strings (path) contains subroutine print_strings (s) character(*), intent(in) :: s(:) integer :: i print *, 'character string length:', len (s) print *, 'array size =', size (s) do, i=1, size(s) print *, i, '>', s(i), '<' end do end subroutine end program wws@w6ws-4:/tmp$ /usr/local/gcc-trunk/bin/gfortran -g testch3.f90 wws@w6ws-4:/tmp$ a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7fe073c854af in ??? #1 0x400ea3 in testch at /tmp/testch3.f90:5 #2 0x401b66 in main at /tmp/testch3.f90:12 Segmentation fault (core dumped) wws@w6ws-4:/tmp$
[Bug fortran/85547] Run-time error: character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85547 --- Comment #5 from Walter Spector --- Turns out my third case, in comment #2, is incorrect. To correct it, line 5 should read: path = (/ 'xyz/' /) With this correction, my current trunk snapshot works ok. (Doesn't apply to the first two examples though.)
[Bug fortran/85603] New: ICE with character array substring assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85603 Bug ID: 85603 Summary: ICE with character array substring assignment Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: w6ws at earthlink dot net Target Milestone: --- The following test case causes an ICE. First noticed with v5.4, but also happens with v4.8 and a 4/26/2018 snapshot of v9.0.0. Intel and NAG compile and run this. PGI v17.10 also gets an ICE...: program strlen_bug implicit none character(:), allocatable :: strings(:) integer :: maxlen strings = [ character(32) :: & 'short', & 'somewhat longer' ] maxlen = maxval (len_trim (strings)) print *, 'max length =', maxlen ! causes ICE ! strings = strings(:)(:maxlen) print *, strings end program wws@w6ws-4:/rootsda5/home/wws/fortran/array_cons$ /usr/local/gcc-trunk/bin/gfortran --version GNU Fortran (GCC) 9.0.0 20180426 (experimental) Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. wws@w6ws-4:/rootsda5/home/wws/fortran/array_cons$ /usr/local/gcc-trunk/bin/gfortran strlen_bug.f90 strlen_bug.f90:13:0: strings = strings(:)(:maxlen) internal compiler error: Segmentation fault 0xce260f crash_signal ../../gcc-trunk/gcc/toplev.c:325 0x7722a7 gfc_alloc_allocatable_for_assignment(gfc_loopinfo*, gfc_expr*, gfc_expr*) ../../gcc-trunk/gcc/fortran/trans-array.c:9915 0x7a3c24 gfc_trans_assignment_1 ../../gcc-trunk/gcc/fortran/trans-expr.c:10329 0x754537 trans_code ../../gcc-trunk/gcc/fortran/trans.c:1828 0x7e7b2f gfc_trans_block_construct(gfc_code*) ../../gcc-trunk/gcc/fortran/trans-stmt.c:2058 0x754327 trans_code ../../gcc-trunk/gcc/fortran/trans.c:1924 0x788f45 gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.c:6507 0x7081d0 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:6121 0x7081d0 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:6324 0x75107f gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:204 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. wws@w6ws-4:/rootsda5/home/wws/fortran/array_cons$
[Bug c++/83779] New: Trivial bounds error not detected with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83779
Bug ID: 83779
Summary: Trivial bounds error not detected with -fbounds-check
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: w6ws at earthlink dot net
Target Milestone: ---
Does -fbounds-check do anything useful with C/C++ code? The following trivial
code does not trigger any error at run time. (Note: I added the static
attribute because otherwise this simple example does trigger a stack smash
detected message after the program completes.):
wws@w6ws-4:/tmp$ cat bck.c
#include
int main () {
static int array1[20];
for (int i=0; i<25; i++)
array1[i] = i;
printf ("done!\n");
}
wws@w6ws-4:/tmp$ g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
wws@w6ws-4:/tmp$ g++ -g -fbounds-check bck.c
wws@w6ws-4:/tmp$ a.out
done!
wws@w6ws-4:/tmp$ gcc -g -fbounds-check bck.c
wws@w6ws-4:/tmp$ a.out
done!
wws@w6ws-4:/tmp$
[Bug c++/83779] Trivial bounds error not detected with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83779 --- Comment #2 from Walter Spector --- Ah. Thank you.
[Bug c++/83779] Trivial bounds error not detected with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83779 --- Comment #5 from Walter Spector --- Thanks for mentioning that, Martin. A couple of us in the project I work on were reviewing the options we specify in our debug builds to try to smoke out problems. We already use options like -Wall, -Wextra and such for both g++ and gfortran. We also use -fbounds-check with gfortran. Just wondering if -fbounds-check would help find things on the c++ side. But seems it doesn't - as documented.
[Bug fortran/71723] [7/8 Regression] [F08] ICE on invalid pointer initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723 --- Comment #17 from Walter Spector --- Thank you Thomas!
[Bug fortran/85603] ICE with character array substring assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85603 --- Comment #4 from Walter Spector --- Hi Paul, I built an updated compiler that includes your fix. The ICE is gone - thanks! However the assignment is still not correctly compiled. The example should be reallocating the character string length of the array to 15. Unfortunately it remains at 32. Slightly longer example: program strlen_bug implicit none character(:), allocatable :: strings(:) integer :: maxlen strings = [ character(32) :: & 'short', & 'somewhat longer' ] maxlen = maxval (len_trim (strings)) print *, 'max length =', maxlen ! Used to cause an ICE strings = strings(:)(:maxlen) ! Should realloc print *, strings print *, 'string length =', len (strings) end program wws@w6ws-4:/rootsda5/home/wws/fortran/gfortran$ /usr/local/gcc-9/bin/gfortran -frealloc-lhs strlen_bug.f90 wws@w6ws-4:/rootsda5/home/wws/fortran/gfortran$ a.out max length = 15 short somewhat longer string length = 32 wws@w6ws-4:/rootsda5/home/wws/fortran/gfortran$ /usr/local/gcc-9/bin/gfortran --version GNU Fortran (GCC) 9.0.0 20180922 (experimental) Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. wws@w6ws-4:/rootsda5/home/wws/fortran/gfortran$ Note that I tried explicitly adding the -frealloc-lhs option, but it didn't make a difference either way.
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 Walter Spector changed: What|Removed |Added CC||w6ws at earthlink dot net --- Comment #5 from Walter Spector 2013-01-04 02:54:05 UTC --- Adding myself to the CC list. Walter Spector
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #6 from Walter Spector 2013-01-04 14:33:15 UTC --- Another manifestation of this problem is with type extension. Here is another small example which fails. (Tested on v4.6.3 and also a 1/4/2013 snapshot of the 4.8 trunk.): program test_type_extension type t1_t real :: x end type t1_t type, extends(t1_t) :: t1e_t character(8) :: string end type t1e_t type(t1e_t) :: t1e integer :: answer namelist /test_NML/ t1e, answer open(unit=1,file='test1.inp') read(1,NML=test_NML) write(*,*) t1e%x, t1e%string, answer end program test_type_extension File test1.inp contains: &test_NML t1e%x = 2.,t1e%string='gfortran',answer=42 / wws@w6ws-4:~/fortran/xxx$ gfortran --version GNU Fortran (GCC) 4.8.0 20130104 (experimental) Copyright (C) 2013 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING wws@w6ws-4:~/fortran/xxx$ gfortran namelist.f90 wws@w6ws-4:~/fortran/xxx$ a.out At line 17 of file namelist.f90 (unit = 1, file = 'test1.inp') Fortran runtime error: Cannot match namelist object name %x Backtrace for this error: + in the main program from file namelist.f90 + /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7ffe80c5376d] wws@w6ws-4:~/fortran/xxx$ The NAG Fortran compiler has no problems with this test case. (Intel and PGI are not so lucky. :) )
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #8 from Walter Spector 2013-01-04 17:22:31 UTC --- Good point. The key is: > T1E%T1_T%X= 2., If the full expanded version is used, in other words %T1_T is specified, the example works. (On Intel too.)
[Bug fortran/70149] New: Character pointer initialization causes ICE. (F2008)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 Bug ID: 70149 Summary: Character pointer initialization causes ICE. (F2008) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: w6ws at earthlink dot net Target Milestone: --- The following causes an ICE on both 5.8.4 and the 20160309 6.0 trunk: module myptr_mod implicit none integer, target, save :: int_data = 42 character(16), target, save :: char_data = 'forty two' integer, pointer :: number => int_data ! The following works: ! character(16), pointer :: number_string => char_data ! The following causes a compiler ICE: character(:), pointer :: number_string => char_data end module wws@w6ws-4:/tmp$ gfortran --version GNU Fortran (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4 Copyright (C) 2013 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING wws@w6ws-4:/tmp$ gfortran -c ptr_init_ice.f90 f951: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1449 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. wws@w6ws-4:/tmp$ and wws@w6ws-4:/tmp$ /usr/local/bin/gfortran_trunk --version GNU Fortran (GCC) 6.0.0 20160309 (experimental) Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. wws@w6ws-4:/tmp$ /usr/local/bin/gfortran_trunk -c ptr_init_ice.f90 f951: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1636 0x691703 gfc_get_symbol_decl(gfc_symbol*) ../../gcc-trunk/gcc/fortran/trans-decl.c:1636 0x696fa9 gfc_create_module_variable ../../gcc-trunk/gcc/fortran/trans-decl.c:4648 0x650323 do_traverse_symtree ../../gcc-trunk/gcc/fortran/symbol.c:3817 0x694772 gfc_generate_module_vars(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.c:5091 0x66a72b gfc_generate_module_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans.c:2032 0x621b35 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:5600 0x621b35 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:5819 0x663032 gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:201 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. wws@w6ws-4:/tmp$
[Bug fortran/70149] Character pointer initialization causes ICE. (F2008)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 --- Comment #1 from Walter Spector --- Typo: 5.8.4 -> 4.8.4
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 --- Comment #25 from Walter Spector --- Thank you Dominique! Walter
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640 --- Comment #38 from Walter Spector --- Paul, THANK YOU!
[Bug fortran/56471] Program crashes when allocating a derived type with an allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56471 Walter Spector changed: What|Removed |Added CC||w6ws at earthlink dot net --- Comment #3 from Walter Spector --- Adding myself to the ticket. Here is another simple example using the trunk as of today: wws@w6ws-4:/tmp$ cat allscal.f90 program allscal implicit none type mytype_t character(32), allocatable :: typescalar end type type (mytype_t), allocatable :: myobj allocate (myobj) allocate (myobj%typescalar) myobj%typescalar = 'hello world' print *, myobj%typescalar deallocate (myobj%typescalar) deallocate (myobj) end program wws@w6ws-4:/tmp$ /usr/local/gcc-trunk/bin/gfortran -g allscal.f90 wws@w6ws-4:/tmp$ echo $LD_LIBRARY_PATH /usr/local/gcc-trunk/lib64 wws@w6ws-4:/tmp$ a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f3e526c44af in ??? #1 0x4008c5 in allscal at /tmp/allscal.f90:10 #2 0x400b19 in main at /tmp/allscal.f90:17 Segmentation fault (core dumped) wws@w6ws-4:/tmp$ /usr/local/gcc-trunk/bin/gfortran --version GNU Fortran (GCC) 8.0.0 20170920 (experimental) Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. wws@w6ws-4:
[Bug fortran/79087] New: CPATH environment variable not recognised.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79087 Bug ID: 79087 Summary: CPATH environment variable not recognised. Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: w6ws at earthlink dot net Target Milestone: --- The ENVIRONMENT portion of the gfortran man page states: The gfortran compiler currently does not make use of any environment variables to control its operation above and beyond those that affect the operation of gcc. Then referring to the ENVIRONMENT portion of the gcc man page, under CPATH, it states: CPATH specifies a list of directories to be searched as if specified with -I, but after any paths given with -I options on the command line. This environment variable is used regardless of which language is being preprocessed. Unfortunately gfortran does not seem to recognize CPATH: wws@w6ws-4:~$ cd /tmp wws@w6ws-4:/tmp$ mkdir include wws@w6ws-4:/tmp$ cat > include/inc.inc integer, parameter :: answer = 42 wws@w6ws-4:/tmp$ export CPATH=/tmp/include wws@w6ws-4:/tmp$ cat > junk.f90 program junk include "inc.inc" print *, answer end program wws@w6ws-4:/tmp$ gfortran junk.f90 junk.f90:2: Error: Can't open included file 'inc.inc' wws@w6ws-4:/tmp$ gfortran -I$CPATH junk.f90 wws@w6ws-4:/tmp$ a.out 42 wws@w6ws-4:/tmp$ /tmp$ gfortran --version GNU Fortran (GCC) 7.0.0 20160831 (experimental) Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. wws@w6ws-4:/tmp$ Intel Fortran does support this. It is handy when used in conjunction with the "module" package that is often used at sites to select various software packages. This ticket might be a duplicate of PR 65998, but that ticket seems more pre-processor (cpp) and architecture oriented.
[Bug fortran/82367] New: ICE with deferred length string allocate on non-deferred length argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82367 Bug ID: 82367 Summary: ICE with deferred length string allocate on non-deferred length argument Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: w6ws at earthlink dot net Target Milestone: --- Incorrect code caused a ICE: wws@w6ws-4:/tmp$ cat cls.f90 module cls_allocmod implicit none contains subroutine cls_alloc (n, str) integer, intent(in) :: n character(*), allocatable, intent(out) :: str ! Note: Star ^ should have been a colon (:) allocate (character(n)::str) end subroutine end module program cls use cls_allocmod implicit none character(:), allocatable :: string call cls_alloc (42, string) print *, 'string len =', len(string) end program wws@w6ws-4:/tmp$ Gfortran 5.4 produces an ICE. So do older versions (e.g., 4.8 on one of my other machines.): wws@w6ws-4:/tmp$ gfortran --version GNU Fortran (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 Copyright (C) 2015 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING wws@w6ws-4:/tmp$ gfortran cls.f90 f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. wws@w6ws-4:/tmp$ The trunk as of a couple of days ago also produces an ICE - this time with a compiler traceback: wws@w6ws-4:/tmp$ /usr/local/gcc-trunk/bin/gfortran --version GNU Fortran (GCC) 8.0.0 20170927 (experimental) Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. wws@w6ws-4:/tmp$ /usr/local/gcc-trunk/bin/gfortran cls.f90 f951: internal compiler error: Segmentation fault 0xc906cf crash_signal ../../gcc-trunk/gcc/toplev.c:326 0x727af8 gfc_dep_compare_expr(gfc_expr*, gfc_expr*) ../../gcc-trunk/gcc/fortran/dependency.c:321 0x6fe687 resolve_allocate_expr ../../gcc-trunk/gcc/fortran/resolve.c:7391 0x6fe687 resolve_allocate_deallocate ../../gcc-trunk/gcc/fortran/resolve.c:7782 0x70067a gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:11212 0x701c02 resolve_codes ../../gcc-trunk/gcc/fortran/resolve.c:16236 0x701b07 resolve_codes ../../gcc-trunk/gcc/fortran/resolve.c:16221 0x701d06 gfc_resolve(gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.c:16271 0x6eb54c gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:6217 0x7313af gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:204 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. wws@w6ws-4:/tmp$
[Bug fortran/82367] ICE with deferred length string allocate on non-deferred length argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82367 --- Comment #1 from Walter Spector --- PGI and NAG both catch this error. I can try Intel if needed.
[Bug fortran/71723] [5/6/7 Regression] [F08] ICE on invalid pointer initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723 --- Comment #4 from Walter Spector --- As you are surmising, there are actually two problems in the example. First, 'data' needs the 'target' attribute in order to be pointed to. Second, 'data' must either have the 'target' or a 'pointer' attribute, but not both. Walter
[Bug fortran/71723] [5/6/7 Regression] [F08] ICE on invalid pointer initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723 --- Comment #6 from Walter Spector --- Hi Janus, Your test case in Comment #5 is fine - because it is not attempting to initialize the pointer at compile time. Initializing a pointer at compile time is a F2008 feature. I was testing this F2008 feature when I encountered the ICE which prompted this bug report. If I feed my original test case into ifort (v17), I get: /tmp/wws> ifort ptr2.f90 ptr2.f90(10): error #8813: The target must have the TARGET attribute. [DATA] integer, pointer :: idata => data%i ---^ compilation aborted for ptr2.f90 (code 1) /tmp/wws>
[Bug fortran/71723] [5/6/7 Regression] [F08] ICE on invalid pointer initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723 --- Comment #8 from Walter Spector --- Hi Janus, The ifort compiler has no problem with your example in Comment #5. That example should be Standard Fortran 90. The newer F2008 data pointer initialization stuff is largely in §4.5.4.6, paragraph 2: "A pointer variable or component is data-pointer-initialization compatible with a target if the pointer is type compatible with the target, they have the same rank, all nondeferred type parameters of the pointer have the same values as the corresponding type parameters of the target, and the target is contiguous if the pointer has the CONTIGUOUS attribute." Note the repeated use of the word "target". :)
[Bug fortran/60751] New: Extra comma in WRITE statement not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 Bug ID: 60751 Summary: Extra comma in WRITE statement not diagnosed Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: w6ws at earthlink dot net
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 --- Comment #1 from Walter Spector --- Simple test case: program extracomma implicit none write (*,*), 1, 2, 3 end program This compiles without error. I notice that if I compile with -std=f95, it does diagnose this as a GNU Extension. My thoughts are that a warning message should be issued, rather than quietly accepting the extension by default.
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 --- Comment #3 from Walter Spector --- I didn't complain to Intel, but I can... However the compilers that did catch it by default were NAG, lahey, and Absoft. Walter
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 --- Comment #5 from Walter Spector --- > It seems quite trivial to fix, but does it really worth the work? Well, we had an instance where this accidentally slipped into our code. Later on, our nightly regression runs crashed with several non-gfortran (and non-Intel) compilers. The extension itself is pretty gratuitous. It adds nothing to the language, yet can quietly promote incompatibilities. Since g95 also accepts it, I am assuming it came into the compiler before the split.
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 --- Comment #6 from Walter Spector --- Adding that both READ and WRITE have this issue. Interestingly, the iolength version of INQUIRE does not: inquire (iolength=i), i 1 Error: Expected expression in INQUIRE statement at (1)
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 --- Comment #9 from Walter Spector --- Harald and Steve: I am quite aware of the std= options, thanks. My main point is that the default situation violates the Principle of Least Astonishment. I don't have a problem with gfortran offering such an extension (though I think providing it in the first place was a waste of time). But since it offers no desireable new capability, and allows gratuitous incompatibility with other compilers, it would at least be worth a warning. The ideal would be to only allow it under a -f option - but don't do that on my account. In fact the gfortran man page for the -std= argument states: "...The default value for std is gnu, which specifies a superset of the Fortran 95 standard that includes all of the extensions supported by GNU Fortran, although warnings will be given for obsolete extensions not recommended for use in new code..." I would opine that this extension is obsolete and not recommeded for use in new code. Therefore a warning should be given.
[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383 Walter Spector changed: What|Removed |Added CC||w6ws at earthlink dot net --- Comment #12 from Walter Spector --- Adding myself to the CC list, sympathizing with comment #5. Just IEEE_ARITHMETIC intrinsic functions for basic setting (e.g., IEEE_VALUE) and testing (e.g., IEEE_IS_NAN) with the default rounding mode, roughly equivalent to what g95 supports, would be very useful. I don't need fancy rounding modes.
[Bug fortran/43832] New: OPEN statement not diagnosing missing unit number
An OPEN statement needs to either have a unit number in the first item in the list, or have a UNIT= (or NEWUNIT= in F2008) keyword somewhere else. Here is an example where the unit number is not specified, yet gfortran does not issue an error: subroutine openit implicit none open (file='x') end subroutine This was tested with version 4.4.1 on Ubuntu linux. -- Summary: OPEN statement not diagnosing missing unit number Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: w6ws at earthlink dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43832
[Bug fortran/43832] OPEN statement not diagnosing missing unit number
--- Comment #1 from w6ws at earthlink dot net 2010-04-21 14:05 --- An additional test: with just an OPEN statement with no list, gfortran issues: In file miniopen.f90:4 open () 1 Error: Syntax error in OPEN statement at (1) While the message is technically correct, it would be more helpful if it mentioned the missing unit number. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43832
[Bug fortran/59796] New: Deallocate aborts even with STAT=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59796 Bug ID: 59796 Summary: Deallocate aborts even with STAT= Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: w6ws at earthlink dot net Yes, this is probably a duplicate of the now-closed bug 44504. The following code returns a stat of 0 from g95, PGI (v13.8), and NAG (v5.3.1). However Intel and gfortran abend - which is not very friendly. Who is right? program double_dealloc implicit none integer, pointer :: ip1(:), ip2(:) integer :: memstat allocate (ip1(42)) ip2 => ip1 deallocate (ip1) deallocate (ip2, stat=memstat) print *, 'memstat =', memstat end program The Fortran 2008 Standard, in section 6.7.4 pertaining to the STAT= specifier, starts off somewhat vague with respect to STAT= when there is an error. In paragraph 2 it only states that upon success, a value of 0 is set. However in paragraph 3, which pertains to co-array allocation, it does explicitly state that "... If any other error condition occurs during execution of the ALLOCATE or DEALLOCATE statement, the stat-variable becomes de ned with a processor-dependent positive integer value di fferent from STAT STOPPED IMAGE. In either case, each allocate-object has a processor-dependent status..." Also in the following Note 6.25, it states "The status of objects that were not successfully allocated or deallocated can be individually checked with the intrinsic functions ALLOCATED or ASSOCIATED." >From these last two sets of statements, it seems clear that the intent of the Standard is that no deallocation should cause an abend when stat= is present.
[Bug fortran/59796] Deallocate aborts even with STAT=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59796 --- Comment #1 from Walter Spector --- Forgot to mention: The test case was tested with gfortran 4.7.3 and 4.8.2.
[Bug fortran/59796] Deallocate aborts even with STAT=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59796 --- Comment #3 from Walter Spector --- My initial reaction is that yes, 6.7.3.3 in F08 states what you quoted. And I agree that it is a programming error to pass a dangling pointer into deallocate. But that does not preclude gfortran from returning some sort of error back to the user when stat= is present. In fact, 6.7.4 seems to *require* it - at least in the case of co-arrays. (... "If any other error condition occurs...") So I don't see a conflict in the Standard.
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 --- Comment #14 from Walter Spector --- Hi Dominique, I am sorry I didn't see or respond to your comment from last year. Thank you for the ping. Yes, it would be fine with me to recategorize the error as GFC_STD_LEGACY. Walter
[Bug fortran/34402] Diagnose illegal initialization of derived type containing allocatable component
--- Comment #3 from w6ws at earthlink dot net 2009-12-08 21:34 --- (In reply to comment #2) > I don't get it. "Fortran 95/2003 explained" by Metcalf has exactly this in the > example (figure 12.3, p243) for allocatable components... So, where's the > actual problem? The example on p243 correctly shows the use of a structure constructor in an assignment statement. This bug report is different in that it concerns a structure constructor in the initializer portion of a TYPE statement (where the derived type contains an ALLOCATABLE.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34402
[Bug fortran/34402] Diagnose illegal initialization of derived type containing allocatable component
--- Comment #5 from w6ws at earthlink dot net 2009-12-09 00:27 --- (In reply to comment #4) > ... it dawns on me that the crucial point is, that variables with > initializer get the SAVE attribute which doesn't go well with the ALLOCATABLE > components. Correct? I am not sure why they put the restriction in. But note that one *can* use null() in a structure constructor for the allocatable component. So the following is legal: type xyzzy integer, allocatable :: x(:) real :: y end type type(xyzzy) :: plugh = xyzzy (null (), 123.456) See 7.1.7(3) in F2003 (and 7.1.12(3) in the F2008 draft.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34402
[Bug fortran/48048] New: [F2003] Remove constraint on namelist group objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48048 Summary: [F2003] Remove constraint on namelist group objects Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: w...@earthlink.net Fortran-90/95 had a major constraint on namelist group objects which prevented the use of non-fixed-length objects. In F2003, this constraint was removed. Compare section 5.4 in F95 with section 5.4 in F2003. This is not a critical need for me at this point in time. But I wanted to see it in the bugzilla for completeness.
[Bug fortran/48048] [F2003] Remove constraint on namelist group objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48048 --- Comment #2 from Walter Spector 2011-03-09 20:25:18 UTC --- >--- Comment #1 from Tobias Burnus 2011-03-09 >18:50:28 UTC --- >Report comes too late - it's fixed since 2011-01-26 :-) > >Cf. PR 47339 and PR 43062. > >I case something is not working, please reopen. >For nightly or regular builds, see http://gcc.gnu.org/wiki/GFortranBinaries Gosh - my copy of the trunk is all of 1.5 months old - just prior to your mods. Thank you! Walter
[Bug fortran/48048] [F2003] Remove constraint on namelist group objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48048 --- Comment #3 from Walter Spector 2011-03-09 23:17:20 UTC --- I updated my copy of the trunk, and rebuilt 4.6. Non-derived type allocatable/pointer variables seem to be ok. However allocatable/pointer derived type components are not supported. This appears to be because DTIO is then required and gfortran does not support it yet. testnml.f90:55.19: namelist /mygroup/ iarray, a, da 1 Error: NAMELIST object 'da' in namelist 'mygroup' at (1) has ALLOCATABLE or POINTER components and thus requires a defined input/output procedure testnml.f90:66.13: print *, da 1 Error: Data transfer element at (1) cannot have POINTER components Off topic, but note that the error message for the 'print' statement in my little test program could be more helpful. It could give a message similar to the one provided at the namelist statement.
[Bug fortran/38282] Bit intrinsics: ILEN and IBCHNG
--- Comment #15 from w6ws at earthlink dot net 2010-09-08 21:32 ---
Subject: Re: Bit intrinsics: ILEN and IBCHNG
FX wrote:
>--- Comment #14 from fxcoudert at gcc dot gnu dot org 2010-09-08 19:52
>---
>Possible remaining are only old extensions, not sure they're useful: ILEN and
>IBCHNG.
>
>Closing?
It is easy to write ones own IBCHNG. So at this point, especially given
its rarity in actual codes, it is probably not worth implementing.
ILEN is pretty easy to write too. If there is ever a move to implement
more of HPFs intrinsics, you could add it then. (Speaking of which, I
think some kind of intrinsic sorting/grading routines, like maybe
simplified 1-D versions of HPFs SORT_{UP,DOWN} and GRADE_{UP,DOWN}
functions would be incredibly useful to a lot of programmers. But that
is something which should be covered under a different ticket.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282
[Bug fortran/46405] New: Preprocessor generated code can exceed 132 characters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405 Summary: Preprocessor generated code can exceed 132 characters Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: w...@earthlink.net A silly, but nonetheless interesting, problem - it is easy to exceed the 132 character line limit when using preprocessing. The specific case that is causing me problems is error handling code where one would like to use the predefined __FILE__ macro (along with __LINE__) to record the area of code reporting a problem. The code might reside in a deeply nested directory path, and absolute file names are used by the make files. Some musings: 1.) The built-in preprocessor is supposedly Fortran-aware. E.g., it knows about things like // being character concatenation, and not a C/C++ inline comment. 2.) By the Principle of Least Astonishment, a user might expect that as long as the source code presented to the compilation system (e.g., preprocessor + compiler proper) conforms to the 132 character limit, things should be ok. A user sees __FILE__ as being only 8 characters, yet invisibly, the compiler sees it very differently and refuses to compile his code. 3.) This is a problem with macros in general, and not just __FILE__. 4.) This is a problem with a lot of other Fortran compilers - not just gfortran. 5.) Yes, one can use the -ffree-line-length-none option. Disadvantage is that it will not detect other problems in lines that are not affected by preprocessing. So it seems to me that one solution would be for the preprocessor to enforce the 132 character limit (modulo the -ffree-line-length option). But when the preprocessed code is presented to the compiler, the overcompiler should specify -ffree-line-length-none.
[Bug fortran/33888] New: ICE - CHARACTER expression using an ELEMENTAL FUNCTION as actual arg
The following causes an ICE: $ cat ftn95bug.f90 program ftn95bug implicit none character(8) :: indata(4) = (/ & '12344321', '98766789', 'abcdefgh', 'ABCDEFGH' & /) call process (myfunc (indata)) ! <- This causes a gfortran ICE ! contains elemental function myfunc (s) character(*), intent(in) :: s character(len (s)) :: myfunc myfunc = s end function subroutine process (strings) character(*), intent(in) :: strings(:) print *, strings end subroutine end program [EMAIL PROTECTED] /cygdrive/d/usr/wws/fortran/utils $ gfortran --version GNU Fortran (GCC) 4.3.0 20071005 (experimental) [trunk revision 127783] Copyright (C) 2007 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING [EMAIL PROTECTED] /cygdrive/d/usr/wws/fortran/utils $ gfortran ftn95bug.f90 ftn95bug.f90:8: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED] /cygdrive/d/usr/wws/fortran/utils $ -- Summary: ICE - CHARACTER expression using an ELEMENTAL FUNCTION as actual arg Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: w6ws at earthlink dot net GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33888
[Bug fortran/34136] [g77 regression] Add entry point and symbol for linker
--- Comment #1 from w6ws at earthlink dot net 2007-11-17 15:34 --- First, the problem is described, and a full test case available, at: http://www.ncl.ucar.edu/Download/build_from_src.shtml#CompilersNeeded Second, I am not sure if part b (changing the name from BSS to TEXT) is strictly needed. On my cygwin system, if I compile the block data with gfortran (getting the BSS version), and the remainder of the test case with g77, everything works fine. However I can well imagine that linkers on other architectures may work differently. -- w6ws at earthlink dot net changed: What|Removed |Added CC||w6ws at earthlink dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34136
[Bug fortran/34402] New: Diagnose illegal initialization of derived type containing allocatable component
The initialization in following test case should be diagnosed as an error: $ cat nocomp7.f90 module nocomp7 implicit none type bad_t real, allocatable :: x(:) end type ! The following is illegal! type (bad_t) :: bad = bad_t ( (/ 1., 3., 5., 7., 9. /) ) end module $ $ gfortran --version GNU Fortran (GCC) 4.3.0 20071005 (experimental) [trunk revision 127783] Copyright (C) 2007 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $ $ gfortran --pedantic -c nocomp7.f90 $ -- Summary: Diagnose illegal initialization of derived type containing allocatable component Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: w6ws at earthlink dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34402
[Bug fortran/34476] Parameters: Bogus out of bounds error in array constructor
--- Comment #2 from w6ws at earthlink dot net 2007-12-17 15:33 ---
Here is an additional variant of this bug:
program init_bug
implicit none
integer :: i
character(11), parameter :: string="hello world"
! This compiles:
character, parameter :: up_string(len (string)) = &
(/ (string(i:i), i=1, len (string)) /)
integer, parameter :: bytes(len (string)) = &
(/ (iachar (string(i:i)), i=1, len (string)) /)
integer, parameter :: up_bytes(len (string)) = &
(/ (iachar (up_string(i)), i=1, size (up_string)) /)
print *, string
print *, up_string
print *, bytes
print *, up_bytes
end program
Besides the out-of-bounds error, it also gives a 'cannot appear in the
expression error':
(/ (iachar (up_string(i)), i=1, size (up_string)) /)
1
Error: index in dimension 1 is out of bounds at (1)
abuse_init4.f90:12.25:
(/ (iachar (string(i:i)), i=1, len (string)) /)
1
Error: Variable 'i' cannot appear in the expression at (1)
abuse_init4.f90:21.19:
print *, up_bytes
1
Error: Symbol 'up_bytes' at (1) has no IMPLICIT type
--
w6ws at earthlink dot net changed:
What|Removed |Added
----
CC| |w6ws at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34476
[Bug fortran/36058] New: Not allowing pointers to derived types in COMMON
Gfortran is not allowing pointers to certain derived types to reside in COMMON.
While there are constraints for derived type objects themselves (ref section
5.5.2 of F2003), there do not appear to be constraints on pointers to them. So
it seems that gfortran is not considering 'pointeredness' when applying the
constraint checks in 5.5.2.
$ cat commonptr.f90
subroutine commonptr ()
implicit none
type wws_t
integer :: x = 1, y = 2, z = 3
end type
type (wws_t), pointer :: my_wwsptr
common /block/ my_wwsptr
allocate (my_wwsptr)
my_wwsptr = wws_t (3, 4, 5)
end subroutine
$
$ gfortran --version
GNU Fortran (GCC) 4.3.0 20071222 (experimental) [trunk revision 127783]
Copyright (C) 2007 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
$ gfortran -c commonptr.f90
commonptr.f90:8.36:
type (wws_t), pointer :: my_wwsptr
1
Error: Derived type variable 'my_wwsptr' in COMMON at (1) has neither the
SEQUENCE nor the BIND(C) attribute
commonptr.f90:8.36:
type (wws_t), pointer :: my_wwsptr
1
Error: Derived type variable 'my_wwsptr' in COMMON at (1) may not have default
initializer
$
--
Summary: Not allowing pointers to derived types in COMMON
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36058
[Bug fortran/36058] Not allowing pointers to derived types in COMMON
--- Comment #2 from w6ws at earthlink dot net 2008-04-27 13:24 ---
Subject: Re: Not allowing pointers to derived types in
COMMON
burnus at gcc dot gnu dot org wrote:
> --- Comment #1 from burnus at gcc dot gnu dot org 2008-04-27 08:01
> ---
> gfortran's rejection is in line with g95, NAG f95, ifort, openf95, sunf95 and
> ifort.
On the other side are PGI and Salford/Silverfrost - who allow the pointer
to reside in the COMMON block.
> Additionally, I think the following also applies to pointers. ("my_wwsptr" is
> of a derived type [albeit with pointer attribute].)
>
> "C589 (R558) If a common-block-object is of a derived type, it shall be a
> sequence type (4.5.1) or a type with the BIND attribute and it shall have no
> default initialization."
I am only concerned with the POINTER case. I am not placing a
derived type object in the COMMON block. I am only storing a
pointer to it.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36058
[Bug fortran/36721] New: Compiler aborts with no message when libgmp and/or libmpfr are missing
When gfortran is installed into a system where libgmp and/or libmpfr are missing, it aborts with no error message. It does, however, return an exit code of 1 - which is good. So at least make, or a script, can detect that something bad happened. Both in the case of linux and cygwin, libgmp and libmpfr are often not installed by default. When this is the case, gfortran should issue a reasonable error message prior to aborting. This would eliminate any confusion as to why gfortran failed to compile the users code. -- Summary: Compiler aborts with no message when libgmp and/or libmpfr are missing Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: w6ws at earthlink dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36721
[Bug fortran/36721] Compiler aborts with no message when libgmp and/or libmpfr are missing
--- Comment #1 from w6ws at earthlink dot net 2008-07-03 17:41 --- Add keyword. -- w6ws at earthlink dot net changed: What|Removed |Added CC||w6ws at earthlink dot net Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36721
[Bug fortran/36721] Compiler aborts with no message when libgmp and/or libmpfr are missing
--- Comment #3 from w6ws at earthlink dot net 2008-07-03 17:57 --- Subject: Re: Compiler aborts with no message when libgmp and/or libmpfr are missing pinskia at gcc dot gnu dot org wrote: > --- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-03 17:46 > --- > This is an OS issue really. Or maybe a distribution of GCC issue which is not > a bug which the FSF should worry about. That is the binary distributers did > not distribute GMP/MPFR with GCC or did not compiler GMP/MPFR as being static. In this case, Tobias is the 'binary distributor'... (And I really appreciate his efforts!) > I think we can declare this as invalid based on that fact and the fact we > don't > support binary distributions. Not user-friendly. I can offer two suggestions: 1.) If shared libs are being used, try doing a dlopen on the library to make sure it is available. If it is not available, an error message can be printed before aborting. 2.) A signal handler can be written to catch the jump into nowhere. Again, an error message can be printed. Walter -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36721
[Bug fortran/36721] Compiler aborts with no message when libgmp and/or libmpfr are missing
--- Comment #6 from w6ws at earthlink dot net 2008-07-03 18:48 --- Subject: Re: Compiler aborts with no message when libgmp and/or libmpfr are missing jvdelisle at gcc dot gnu dot org wrote: > This issue comes up on Cygwin a lot as well... Yes - it happened to me yesterday - hence the impetus for my report... > In the Cygwin case, I do that build, so as FX begged in another email, perhaps > I will statically link in those libraries. I really appreciate your efforts too! > ... They do help us get users to try it and report > bugs. That is highly valued. Well, I regularly compile about 250k lines of F90 and C++ code. Since gfortran 4.3 came out, it has been working pretty well. Since you do the cygwin builds, you might be interested that there is another problem with it at link time. When I use g++ to link programs, the 3.4.4 libstdc++ wants to use the 3.4.4 libgcc for externals such as "___w32_sharedptr_terminate" (and friends). However my build scripts set up the library paths such that the libgcc.a that is supplied with gfortran is used instead. The new libgcc does not have the required externals, so I get unsatisfieds. I have to rename the newer libgcc to fake out the linker, and then all is well. Walter -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36721
[Bug fortran/36721] Compiler aborts with no message when libgmp and/or libmpfr are missing
--- Comment #8 from w6ws at earthlink dot net 2008-07-03 20:37 --- Subject: Re: Compiler aborts with no message when libgmp and/or libmpfr are missing burnus at gcc dot gnu dot org wrote: > ... > Is this really an issue with my (newer) 4.4 builds? (4.3 and 4.2 are still > dynamically linked.) I am using your 4.3.1 build on linux. So yes, it does still have the problem. On cygwin, I am using a 4.4 snapshot from last may. > -- One problem with my builds is that my libc (glibc 2.8) > is too new for some systems - I really need to get some virtual machine (Xen, > Virtual Box 1.7,...) running with an older Linux. Funny thing is that I have no problems running on SUSE 9 - which came with gcc 3.something and g77. But on SUSE 10, which came with 4.1.2, I have problems trying to use gfortran 4.3 with our code base. Has to do with the order the libraries get linked in (default locations vs the location where the gfortran libs live.) Walter -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36721
[Bug fortran/36947] New: accepts-invalid
The following test case demonstrates a problem with gfortran, and several
other, compilers that are not properly checking intents. This happens when
using an interface block to define a dummy argument for passing subprograms.
The interface of the actual routine being passed is not fully compared to the
dummy argument definition, the code compiles without warning, and bad results
occur at runtime.
NAG is one of a very few compilers that detect the error at run time.
module testsub
contains
subroutine test(sub)
interface
subroutine sub(x)
integer, intent(in), optional:: x
end subroutine
end interface
print *, "In test(), about to call sub()"
call sub()
end subroutine
end module
module sub
contains
subroutine subActual(x)
! actual subroutine's argment is different in intent and optional
integer, intent(inout):: x
print *, "In subActual():", x
end subroutine
end module
program interfaceCheck
use testsub
use sub
integer :: a
call test(subActual)
end program
--
Summary: accepts-invalid
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
GCC build triplet: Attributes not fully checked comparing actual vs dummy
procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36947
[Bug fortran/36947] Attributes not fully checked comparing actual vs dummy procedure
--- Comment #1 from w6ws at earthlink dot net 2008-07-27 04:22 --- Fixed summary and keyword fields -- w6ws at earthlink dot net changed: What|Removed |Added GCC build triplet|Attributes not fully checked| |comparing actual vs dummy | |procedure | Keywords||accepts-invalid Summary|accepts-invalid |Attributes not fully checked ||comparing actual vs dummy ||procedure http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36947
[Bug fortran/36947] Attributes not fully checked comparing actual vs dummy procedure
--- Comment #3 from w6ws at earthlink dot net 2008-07-27 13:52 --- Subject: Re: Attributes not fully checked comparing actual vs dummy procedure burnus at gcc dot gnu dot org wrote: > If actual-argument procedure itself takes procedures as argument, one can > check > recursively, which will be more work; I think for such kind of nesting no > checking is done currently. Good point. > (I thought that there was a PR already, but I cannot find it - maybe it does > not exist.) There are several 'accept-invalid' PRs that seem to deal with similar issues, but I did not see any that specifically addressed this one. BTW, I meant to say that the NAG compiler finds the problem at *compile* time. So run-time never happens. Almost every other compiler I have tried ignores the problem, and a SEGV usually occurs at run-time. Thank you for looking into this! W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36947
[Bug fortran/71723] New: ICE with attempted pointer initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723 Bug ID: 71723 Summary: ICE with attempted pointer initialization Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: w6ws at earthlink dot net Target Milestone: --- The following test case demonstrates an ICE when compiling a program attempting to use the F2008 pointer initialization feature. The example is not legal. Nonetheless, the compiler should not ICE. module data_mod implicit none type data_t integer :: i end type type(data_t), pointer :: data ! Causes a gfortran ICE integer, pointer :: idata => data%i end module The ICE occurs with both gfortran 4.8 and a snapshot of the 7.0 trunk from April 29, 2016. Here is the trunk snapshot details: f951: internal compiler error: output_operand: invalid expression as operand 0x8b4de3 output_operand_lossage(char const*, ...) ../../gcc-trunk/gcc/final.c:3409 0x8b573d output_addr_const(_IO_FILE*, rtx_def*) ../../gcc-trunk/gcc/final.c:3998 0xe9a10e assemble_integer_with_op(char const*, rtx_def*) ../../gcc-trunk/gcc/varasm.c:2668 0xe9a18d default_assemble_integer(rtx_def*, unsigned int, int) ../../gcc-trunk/gcc/varasm.c:2684 0xe9a1fd assemble_integer(rtx_def*, unsigned int, unsigned int, int) ../../gcc-trunk/gcc/varasm.c:2700 0xea0db4 output_constant ../../gcc-trunk/gcc/varasm.c:4749 0xea17af assemble_variable_contents ../../gcc-trunk/gcc/varasm.c:2062 0xeab69d assemble_variable(tree_node*, int, int, int) ../../gcc-trunk/gcc/varasm.c:2238 0xeb0f39 varpool_node::assemble_decl() ../../gcc-trunk/gcc/varpool.c:589 0x7cebed output_in_order ../../gcc-trunk/gcc/cgraphunit.c:2231 0x7ceee3 symbol_table::compile() ../../gcc-trunk/gcc/cgraphunit.c:2468 0x7d1779 symbol_table::finalize_compilation_unit() ../../gcc-trunk/gcc/cgraphunit.c:2564 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. $ /usr/local/gcc-trunk/bin/gfortran --version GNU Fortran (GCC) 7.0.0 20160429 (experimental) Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $
[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298 Walter Spector changed: What|Removed |Added CC||w6ws at earthlink dot net --- Comment #16 from Walter Spector --- Adding myself to the cc list. Jerry - Your example in Comment 14 needs a little touching up to be legal. The read methods need to have the dtv argument as intent (in out). Also the unformatted methods do not have iotype or vlist dummy args. Walter
[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298 --- Comment #18 from Walter Spector --- Awesome! I have noticed one bug so far. The compiler is missing a check to see if the arguments in the I/O procedures have the 'optional' attribute. It is allowing the attribute - even though it is illegal. E.g. the following should be flagged as erroneous: SUBROUTINE pwf (dtv,unit,iotype,vlist,iostat,iomsg) ! argument definitions CLASS(person), INTENT(IN) :: dtv INTEGER, INTENT(IN), OPTIONAL :: unit CHARACTER (LEN=*), INTENT(IN), OPTIONAL :: iotype INTEGER, INTENT(IN), OPTIONAL :: vlist(:) INTEGER, INTENT(OUT), OPTIONAL :: iostat CHARACTER (LEN=*), INTENT(INOUT), OPTIONAL :: iomsg ... Walter
[Bug fortran/77504] [11/12/13/14 Regression] "is used uninitialized" with allocatable string and array constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504 Walter Spector changed: What|Removed |Added CC||w6ws at earthlink dot net --- Comment #31 from Walter Spector --- Super simple test case: wws@w6ws-4:~/computer/fortran/tests$ /usr/local/bin/gfortran --version GNU Fortran (GCC) 14.0.1 20240115 (experimental) Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. wws@w6ws-4:~/computer/fortran/tests$ cat a.f90 program catenate_test implicit none integer, allocatable :: a(:) a = (/ 1, 3, 5 /) print *, 'size(a) =', size (a) print *, 'a =', a end program wws@w6ws-4:~/computer/fortran/tests$ /usr/local/bin/gfortran -o a a.f90 wws@w6ws-4:~/computer/fortran/tests$ /usr/local/bin/gfortran -Wall -o a a.f90 a.f90:6:19: 6 | a = (/ 1, 3, 5 /) | ^ Warning: ‘a.offset’ is used uninitialized [-Wuninitialized] a.f90:4:30: 4 | integer, allocatable :: a(:) | ^ note: ‘a’ declared here a.f90:6:19: 6 | a = (/ 1, 3, 5 /) | ^ Warning: ‘a.dim[0].lbound’ is used uninitialized [-Wuninitialized] a.f90:4:30: 4 | integer, allocatable :: a(:) | ^ note: ‘a’ declared here a.f90:6:19: 6 | a = (/ 1, 3, 5 /) | ^ Warning: ‘a.dim[0].ubound’ is used uninitialized [-Wuninitialized] a.f90:4:30: 4 | integer, allocatable :: a(:) | ^ note: ‘a’ declared here a.f90:6:19: 6 | a = (/ 1, 3, 5 /) | ^ Warning: ‘a.dim[0].lbound’ may be used uninitialized [-Wmaybe-uninitialized] a.f90:4:30: 4 | integer, allocatable :: a(:) | ^ note: ‘a’ declared here a.f90:6:19: 6 | a = (/ 1, 3, 5 /) | ^ Warning: ‘a.dim[0].ubound’ may be used uninitialized [-Wmaybe-uninitialized] a.f90:4:30: 4 | integer, allocatable :: a(:) | ^ note: ‘a’ declared here wws@w6ws-4:~/computer/fortran/tests$ ./a size(a) = 3 a = 1 3 5 wws@w6ws-4:~/computer/fortran/tests$
[Bug fortran/114611] New: H edit descriptor should flag as error with -std-f95 (or higher)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114611 Bug ID: 114611 Summary: H edit descriptor should flag as error with -std-f95 (or higher) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: w6ws at earthlink dot net Target Milestone: --- When an H edit descriptor is used in a format, only a warning is given when -std=f95 (or higher) is specified. It should be an error, as are other ancient features that were deleted in F95 such as PAUSE and ASSIGN/assigned GO TO. Note in the following example that PAUSE gives an error, whereas use of the H edit descriptor is only a warning: wws@w6ws-4:/tmp/wws$ cat fmt1.f90 program fmt1 implicit none pause 13 print 100 100 format (1H ,"Hello World") end program wws@w6ws-4:/tmp/wws$ gfortran -std=f95 fmt1.f90 fmt1.f90:4:10: 4 | pause 13 | 1 Error: Deleted feature: PAUSE statement at (1) fmt1.f90:7:17: 7 | 100 format (1H ,"Hello World") | 1 Warning: The H format specifier at (1) is a Fortran 95 deleted feature wws@w6ws-4:/tmp/wws$ wws@w6ws-4:/tmp/wws$ gfortran --version GNU Fortran (GCC) 14.0.1 20240115 (experimental) Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. wws@w6ws-4:/tmp/wws$
[Bug fortran/57360] Implement a warning for implied save
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57360 --- Comment #5 from Walter Spector --- IMHO this should be a "surprising" warning when -Wsurprising is specified. The message should suggest adding an explicit SAVE attribute to make the code clear.
[Bug fortran/57360] Implement a warning for implied save
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57360
--- Comment #8 from Walter Spector ---
Hi,
It is a good point. The message is helpful when issued within a procedure.
At module scope, it doesn't mean much since everything at that level is SAVE
anyway. This is similar to what happens in C:
int x = 3; // statically allocated
void fn () {
int i=3; // stack allocated
}
Walter
-Original Message-
From: kargl at gcc dot gnu.org
Sent: Jan 21, 2024 9:43 AM
To:
Subject: [Bug fortran/57360] Implement a warning for implied save
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57360
--- Comment #7 from kargl at gcc dot gnu.org ---
Upon some additional thinking, I wonder how useful this will be compared
to the possible volume of warning messages from modern Fortran. Consider
this code:
module foo
integer :: j = 2
type a
integer :: k = 3
end type
type(a) :: b = a(4)
integer, target :: n
integer, pointer :: m => n
end module foo
subroutine t()
integer :: i=1
write(6,*) i
i=i+1
end subroutine t
call t()
call t()
end
with the patch at the end of this email, I see
% gfcx -c -Wsurprising -Wall a.f90
a.f90:2:14:
2 | integer :: j = 2
| 1
Warning: Entity at (1) has an implicit SAVE attribute [-Wsurprising]
a.f90:6:14:
6 | type(a) :: b = a(4)
| 1
Warning: Entity at (1) has an implicit SAVE attribute [-Wsurprising]
a.f90:7:22:
7 | integer, target :: n
| 1
Warning: Entity at (1) has an implicit SAVE attribute [-Wsurprising]
a.f90:8:23:
8 | integer, pointer :: m => n
| 1
Warning: Entity at (1) has an implicit SAVE attribute [-Wsurprising]
a.f90:12:13:
12 | integer :: i=1
| 1
Warning: ‘i’ at (1) has an implicit SAVE attribute [-Wsurprising]
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 503ecb8d9b5..d6ef37e51f2 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2278,7 +2278,12 @@ add_init_expr_to_sym (const char *name, gfc_expr
**initp, locus *var_locus)
sym->value = init;
if (sym->attr.save == SAVE_NONE)
- sym->attr.save = SAVE_IMPLICIT;
+ {
+ sym->attr.save = SAVE_IMPLICIT;
+ if (warn_surprising)
+ gfc_warning (OPT_Wsurprising, "%qs at %L has an implicit SAVE "
+ "attribute", sym->name, &sym->declared_at);
+ }
*initp = NULL;
}
@@ -5868,7 +5873,12 @@ match_attr_spec (void)
|| gfc_current_state () == COMP_SUBMODULE)
&& !current_attr.save
&& (gfc_option.allow_std & GFC_STD_F2008) != 0)
- current_attr.save = SAVE_IMPLICIT;
+ {
+ current_attr.save = SAVE_IMPLICIT;
+ if (warn_surprising)
+ gfc_warning (OPT_Wsurprising, "Entity at %C has an implicit SAVE "
+ "attribute");
+ }
colon_seen = 1;
return MATCH_YES;
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug fortran/57360] Implement a warning for implied save
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57360 --- Comment #9 from Walter Spector --- It appears that Lfortran issues a message for this case. See: https://github.com/j3-fortran/fortran_proposals/issues/83#issuecomment-1906266587
[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 --- Comment #2 from Walter Spector --- Having suffered through porting Fortran programs from one compiler to another, and one system to another, uncountable times over the past 50 years, I am one who doesn't like "legacy" extensions to be enabled by default. They are traps just waiting to be sprung. So in the rare case where I want specific extensions, I like options to explicitly turn them on. It seems that if I compile with -std=legacy, the compiler somehow indicates to the run-time library to allow the missing commas extension: $ gfortran -std=legacy -g badfmt.f90 $ ./a.out hi3 hi3 hi3 hi3 hi3 $ With this in mind, I would suggest issuing a diagnostic at compile time whenever possible - unless -std=legacy is specified. In the case of run-time formats, without -std=legacy there isn't a way to check at compile time. So perhaps the run-time error message could indicate that it would work if the code were compiled with -std=legacy.
[Bug fortran/119856] New: Missing commas in I/O formats not diagnosed by default at compile time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856
Bug ID: 119856
Summary: Missing commas in I/O formats not diagnosed by default
at compile time.
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: w6ws at earthlink dot net
Target Milestone: ---
Based on a posting in the Fortran discourse forum, I tried a few test cases
with missing comma in I/O formats. With the fix mentioned in PR 88052, my test
cases show diagnostics and the tests abend at run-time. However it would be
even better if these were caught at compile time.
Gfortran already has code for compile-time checking. But it isn't enabled by
default. It should be enabled by default to match the I/O library.
Tested with todays trunk:
$ gfortran --version
GNU Fortran (GCC) 16.0.0 20250417 (experimental)
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$$ cat badfmt.f90
program badfmt
implicit none
integer :: ierr
character(*), parameter :: badfmt_p = '(a i0)'
character(8) :: badfmt_s = '(a i0)'
interface
function add_parens (s)
character(*), intent(in) :: s
character(len (s) + 2) :: add_parens
end function
end interface
! Test with character string in the I/O statement
write (*,"(ai0)", iostat=ierr) "hi", 3
if (ierr /= 0) print*,"could not write"
! Test checking FORMAT statements
write (*,100, iostat=ierr) "hi", 3
100 format (a i0)
! Test using a parameterized string
write (*,badfmt_p) "hi", 3
! Test using a regular character string (which might need to be diagnosed at
run-time,
! but in theory could be diagnosed at compile time.)
write (*,badfmt_s) "hi", 3
! Test using a regular character string (which will need to be diagnosed at
run-time)
write (*, add_parens (badfmt_s)) "hi", 3
end program
function add_parens (s)
character(*), intent(in) :: s
character(len (s) + 2) :: add_parens
add_parens = '(' // s // ')'
end function
$ gfortran -g badfmt.f90 # NOT diagnosed at compile time!
$ ./a.out
could not write
hi
At line 28 of file badfmt.f90 (unit = 6, file = 'stdout')
Fortran runtime error: Missing comma between descriptors
(a i0)
^
Error termination. Backtrace:
#0 0x7f4e7f7d588a in parse_format_list
at ../../../gcc-trunk/libgfortran/io/format.c:1240
#1 0x7f4e7f7e89a7 in data_transfer_init
at ../../../gcc-trunk/libgfortran/io/transfer.c:3298
#2 0x401599 in badfmt
at /home/wws/computer/fortran/tests/badfmt.f90:28
#3 0x4016bb in main
at /home/wws/computer/fortran/tests/badfmt.f90:33
$
$
$ gfortran -std=f95 -g badfmt.f90
badfmt.f90:16:13:
16 | write (*,"(ai0)", iostat=ierr) "hi", 3
| 1
Error: GNU Extension: Missing comma at (1)
badfmt.f90:21:15:
21 | 100 format (a i0)
| 1
Error: GNU Extension: Missing comma at (1)
badfmt.f90:24:14:
24 | write (*,badfmt_p) "hi", 3
| 1
Error: GNU Extension: Missing comma at (1)
badfmt.f90:20:36:
20 | write (*,100, iostat=ierr) "hi", 3
|1
Error: FORMAT label 100 at (1) not defined
$
[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 --- Comment #10 from Walter Spector --- My bad. Didn't have LD_LIBRARY_PATH set right... $ ls -l $LD_LIBRARY_PATH/*gf* -rw-r--r-- 1 root root 21336066 May 29 07:59 /usr/local/lib64/libgfortran.a -rwxr-xr-x 1 root root 977 May 29 07:59 /usr/local/lib64/libgfortran.la lrwxrwxrwx 1 root root 20 May 29 07:59 /usr/local/lib64/libgfortran.so -> libgfortran.so.5.0.0 lrwxrwxrwx 1 root root 20 May 29 07:59 /usr/local/lib64/libgfortran.so.5 -> libgfortran.so.5.0.0 -rwxr-xr-x 1 root root 11500400 May 29 07:59 /usr/local/lib64/libgfortran.so.5.0.0 -rw-r--r-- 1 root root 278 May 29 07:59 /usr/local/lib64/libgfortran.spec $ So now I get an error code from iostat - which is good. But it is interesting that the second write statement doesn't abend. It prints the string 'value =', and a '+' sign. Then the program completes normally. (Exit code 0.) As if the iostat= didn't reset something inside some internal I/O data structure. So when the print, and then the second write came along, it doesn't provide the error. $ gfortran -std=f95 badfmt2.f90 $ ./a.out ioerr =5006 value = + $ If I remove the iostat= from the first write, as you did, I get an immediate abend: $ ./a.out At line 7 of file badfmt2.f90 (unit = 6, file = 'stdout') Fortran runtime error: Missing comma between descriptors (AI5) ^ Error termination. Backtrace: #0 0x7f26028390fa in parse_format_list at ../../../gcc-trunk/libgfortran/io/format.c:1240 #1 0x7f260284c427 in data_transfer_init at ../../../gcc-trunk/libgfortran/io/transfer.c:3298 #2 0x4011ce in ??? #3 0x40134e in ??? #4 0x7f26021ff082 in __libc_start_main at ../csu/libc-start.c:308 #5 0x4010bd in ??? #6 0x in ??? $
[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 --- Comment #7 from Walter Spector --- Confirmed that the compiler now diagnoses the missing commas. Thanks! As noted in Comment 1, there is no message at run-time for run-time formats: $ cat badfmt2.f90 program badfmt implicit none character(10):: fmt = "(AI5)" ! Not parameter, so not examined at compile time integer :: ioerr write (*, fmt, iostat=ioerr) 'value =', 42 print *, 'ioerr =', ioerr write (*, fmt) 'value =', 43 end program badfmt $ $ gfortran badfmt2.f90 $ ./a.out value = 42 ioerr = 0 value = 43 $ $ gfortran --std=f95 badfmt2.f90 $ ./a.out value = 42 ioerr = 0 value = 43 $ $ gfortran --version GNU Fortran (GCC) 16.0.0 20250529 (experimental) Copyright (C) 2025 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $
[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 --- Comment #12 from Walter Spector --- > Definately not right. > > This is some different Issue. If it would help, I'd be happy to submit another PR.
[Bug fortran/114611] H edit descriptor should flag as error with -std-f95 (or higher)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114611 --- Comment #2 from Walter Spector --- Revisiting this, I still think that by the definition of the default -std=gnu, the compiler should give a warning by default, and give an error when -std=f95 (or higher) is specified. Currently no warning is issued by default, and only a warning is issued with -std=f95: $ cat pf.f program pf implicit none character(*), parameter :: hwc = '(12hhello World!)' print 100 100 format (12hHello world!) write (*, hwc) end $ gfortran pf.f $ ./a.out Hello world! hello World! $ $ rm a.out $ gfortran -std=f95 pf.f pf.f:7:21: 7 | 100 format (12hHello world!) | 1 Warning: The H format specifier at (1) is a Fortran 95 deleted feature pf.f:9:19: 9 | write (*, hwc) | 1 Warning: The H format specifier at (1) is a Fortran 95 deleted feature $ ./a.out Hello world! hello World! $ $ gfortran --version GNU Fortran (GCC) 16.0.0 20250529 (experimental) Copyright (C) 2025 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $
