[Bug fortran/51383] New: arrays of extended types interact break associations with arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51383 Bug #: 51383 Summary: arrays of extended types interact break associations with arrays Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: kaiserkar...@yahoo.com An ASSOCIATE block that associates a name with an array of derived types causes a compiler error. It is easily reproduced with the following short program: program extend type :: a integer :: i end type a type, extends (a) :: b integer :: j end type b type (a) :: x(2) type (b) :: y(2) associate (x1 => x, y1 => y) x1(1)%i = 1 ! Commenting out the following line will avoid the error y1(1)%i = 2 end associate end program extend In my version, I get the following error: ## start error message ## associate.f90:1.14: program extend 1 Internal Error at (1): find_array_spec(): Component not found ## end error message ## This example is trivial, of course (just use y instead of y1 and all is well), but if the association is something like associate (y1 => really_long%complicated(3)%variable(2)%array) it becomes more than a triviality As can be seen from the example above, this bug does not occur for "normal" derived types, only ones created with the EXTENDS key word.
[Bug fortran/107441] New: optional arguments are identified as "present" when missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107441 Bug ID: 107441 Summary: optional arguments are identified as "present" when missing Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kaiserkarl31 at yahoo dot com Target Milestone: --- If the first argument to a function is of type "character" (of any length, from what I can tell, including ":" and "*") and the second parameter is both passed by value and optional, the second argument will be identified as "present" even when absent. The following short program reproduces the problem with gfortran 12.2.1: program bugdemo implicit none character :: s integer :: t s = 'a' t = testoptional(s) print*, 'testoptional: ', t contains function testoptional(w, x) result(t) character, intent(in) :: w integer, intent(in), value, optional :: x integer :: t print*, 'present(x) is ', present(x) t = 0 end function testoptional end program bugdemo !! When compiled and run with gfortran 12.2.1, this gives the following output: present(x) is T testoptional:0 [clearly, the first line should have "F" instead of "T"]
[Bug fortran/107900] New: Select type with intrinsic type inside associate causes ICE / Segmenation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107900 Bug ID: 107900 Summary: Select type with intrinsic type inside associate causes ICE / Segmenation fault Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kaiserkarl31 at yahoo dot com Target Milestone: --- Using a polymorphic derived type element in a select type statement is not allowed, but placing it in an associate block causes an internal compiler error if one of the "type is" statements includes an intrinsic type. The following program is enough to reproduce it in GFortran 12.2.1: program test class(*), pointer :: ptr associate (c => ptr) select type (c) type is (integer) print *, 'integer' end select end associate end program test Note that the above program wouldn't run, as "ptr" isn't associated with anything, but it shouldn't generate an ICE either.
[Bug fortran/106108] New: gfortran gives warning about unitilialized variable for string with both allocatable length and size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106108 Bug ID: 106108 Summary: gfortran gives warning about unitilialized variable for string with both allocatable length and size Product: gcc Version: 11.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kaiserkarl31 at yahoo dot com Target Milestone: --- gfortran using "-Wuninitialized" spits out an erroneous warning message for the declaration of a string that has both allocatable length and allocatable dimension. Making it a fixed-length string works: gfortran handles the fixed-length string with allocatable dimension. The following program is a minimal working example: program test implicit none character (len=:), dimension(:), allocatable :: args allocate( character(len=6) :: args(2) ) args(1) = 'hello,' args(2) = 'world!' print '(2(A,1X))', args end program test The compiler seems to handle the above code just fine, but it should not warn the user. Instead, if compiled with "-Wall" or "-Wuninitialized", it says this: test.f90:3:55: 3 |character (len=:), dimension(:), allocatable :: args | ^ Warning: ‘.args’ is used uninitialized [-Wuninitialized] As I said before, making the length fixed seems to work: program test implicit none character (len=6), dimension(:), allocatable :: args allocate( args(2) ) args(1) = 'hello,' args(2) = 'world!' print '(2(A,1X))', args end program test This version produces no warnings.
