[Bug fortran/94446] Bogus "type mismatch" with TYPE(c_ptr) and sizeof()

[abensonca at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94446

Andrew Benson  changed:

   What|Removed |Added

 CC||abensonca at gmail dot com

--- Comment #2 from Andrew Benson  ---
After some more investigation this seems to be related to the following in
target-memory.c in function gfc_simplify_sizeof():

case BT_DERIVED:
case BT_CLASS:
case BT_VOID:
case BT_ASSUMED:
case BT_PROCEDURE:
  {
/* Determine type size without clobbering the typespec for ISO C
   binding types.  */
gfc_typespec ts;
HOST_WIDE_INT size;
ts = e->ts;
type = gfc_typenode_for_spec ();
size = int_size_in_bytes (type);
gcc_assert (size >= 0);
*siz = size;
  }
  return true;


The call to gfc_typenode_for_spec() seems to cause the problem. This eventually
leads to reaching the following point:

#0  gfc_typenode_for_spec(gfc_typespec*, int) () at
../../gcc-git/gcc/fortran/trans-types.c:1177
#1  0x00962502 in gfc_sym_type(gfc_symbol*) () at
../../gcc-git/gcc/fortran/trans-types.c:2247
#2  0x00960858 in gfc_get_function_type(gfc_symbol*,
gfc_actual_arglist*) () at ../../gcc-git/gcc/fortran/trans-types.c:3060
#3  0x009611ed in gfc_get_ppc_type (c=) at
../../gcc-git/gcc/fortran/trans-types.c:2430
#4  0x00961b50 in gfc_get_derived_type(gfc_symbol*, int) () at
../../gcc-git/gcc/fortran/trans-types.c:2712
#5  0x00961ae4 in gfc_get_derived_type(gfc_symbol*, int) () at
../../gcc-git/gcc/fortran/trans-types.c:2670
#6  0x00961ae4 in gfc_get_derived_type(gfc_symbol*, int) () at
../../gcc-git/gcc/fortran/trans-types.c:2670
#7  0x00961ae4 in gfc_get_derived_type(gfc_symbol*, int) () at
../../gcc-git/gcc/fortran/trans-types.c:2670
#8  0x00962115 in gfc_typenode_for_spec(gfc_typespec*, int) () at
../../gcc-git/gcc/fortran/trans-types.c:1166
#9  0x008bec61 in gfc_element_size(gfc_expr*, unsigned long*) () at
../../gcc-git/gcc/fortran/target-memory.c:130
#10 0x008bee33 in gfc_target_expr_size(gfc_expr*, unsigned long*) () at
../../gcc-git/gcc/fortran/target-memory.c:166
#11 0x008af4f3 in gfc_simplify_sizeof (x=0x29fd3c0) at
../../gcc-git/gcc/fortran/simplify.c:7492
#12 0x00829eea in do_simplify (specific=specific@entry=0x775bcc10,
e=e@entry=0x29fd5a0) at ../../gcc-git/gcc/fortran/intrinsic.c:4620
#13 0x008350bc in gfc_intrinsic_func_interface(gfc_expr*, int) () at
../../gcc-git/gcc/fortran/intrinsic.c:5013
#14 0x0088ec57 in resolve_unknown_f (expr=0x29fd5a0) at
../../gcc-git/gcc/fortran/resolve.c:2918

which is this code:

  /* If we're dealing with either C_PTR or C_FUNPTR, we modified the
 type and kind to fit a (void *) and the basetype returned was a
 ptr_type_node.  We need to pass up this new information to the 
 symbol that was declared of type C_PTR or C_FUNPTR.  */
  if (spec->u.derived->ts.f90_type == BT_VOID)
{
  spec->type = BT_INTEGER;
  spec->kind = gfc_index_integer_kind;
  spec->f90_type = BT_VOID;
  spec->is_c_interop = 1;  /* Mark as escaping later.  */
}

My guess is that this is exactly the "clobbering" that is trying to be avoided
in gfc_simplify_sizeof(). As far as I can understand this is occurring because
the variable "gsf" in the test case is an argument to a function, so its
typespec is being retrieved and modified here.

I don't have the understanding to know how to fix this though.

The "clobbering" fix was implemented (according to git blame) in this patch:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=48b155b991003487a50ac171ba5ca7c3409ad417

corresponding to PR50004.

[Bug fortran/83113] Bogus "duplicate allocatable attribute" error for submodule character function

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83113

--- Comment #9 from Andrew Benson  ---
Note that this patch doesn't check that the duplicate attributes are valid or
consistent with those declared in the module. For example both:

module mm
  implicit none
  interface
 module function c()
   integer, dimension(2)  :: c
 end function c
  end interface
end module mm

submodule (mm) oo
  implicit none
contains
  module function c()
integer, dimension(3)  :: c
  end function c
end submodule oo


and


module mm
  implicit none
  interface
 module function c()
   integer, dimension(2)  :: c
 end function c
  end interface
end module mm

submodule (mm) oo
  implicit none
contains
  module function c()
integer, dimension(:)  :: c
  end function c
end submodule oo



compile successfully, but should be rejected. Presumably we should add some
check that the attributes of the declaration in the submodule match those in
the module.

[Bug fortran/83113] Bogus "duplicate allocatable attribute" error for submodule character function

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83113

Andrew Benson  changed:

   What|Removed |Added

 CC||abensonca at gmail dot com

--- Comment #8 from Andrew Benson  ---
Created attachment 47757
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47757=edit
Proposed patch

This patch fixes the test cases in this PR (plus a similar case for a POINTER
attribute).

[Bug fortran/93501] [10 regression] gfortran.dg/pr93473.f90 ICEs starting with r10-6295

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93501

--- Comment #2 from Andrew Benson  ---
PR87103 is now resolved, which should also solve this problem.

[Bug fortran/93473] ICE on valid with long module + submodule names

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473

--- Comment #10 from Andrew Benson  ---
PR87103 is now resolved, which should also solve this problem.

[Bug fortran/91773] Buffer overflow for long module/submodule names

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91773
Bug 91773 depends on bug 87103, which changed state.

Bug 87103 Summary: [OOP] ICE in gfc_new_symbol() due to overlong symbol name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/87103] [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103

Andrew Benson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Andrew Benson  ---
Resolved by the above commit.

[Bug fortran/93501] [10 regression] gfortran.dg/pr93473.f90 ICEs starting with r10-6295

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93501

--- Comment #1 from Andrew Benson  ---
This should be fixed by the patch in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103#c7

[Bug fortran/87103] [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103

--- Comment #7 from Andrew Benson  ---
Created attachment 47735
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47735=edit
updated patch

[Bug fortran/90788] ICE on allocating derived type containing class(*) pointer initialized to null()

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90788

--- Comment #3 from Andrew Benson  ---
Ignore previous comment - wrong PR.

[Bug fortran/90788] ICE on allocating derived type containing class(*) pointer initialized to null()

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90788

--- Comment #2 from Andrew Benson  ---
Created attachment 47734
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47734=edit
updated patch

[Bug fortran/87103] [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103

--- Comment #6 from Andrew Benson  ---
The patch from https://gcc.gnu.org/ml/fortran/2018-09/msg00044.html still
applies cleanly to trunk (with some line offsets) and regression tests cleanly
as of today. I'll attached a new version of the patch based on a diff against
current trunk.

[Bug fortran/93486] ICE on valid with nested submodules and long submodule names

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93486

--- Comment #2 from Andrew Benson  ---
The problem is caused when loading (generic or operator) interfaces from a
module file. The module name can include the submodule name, so a size of
2*GFC_MAX_SYMBOL_LEN+2 is required to read this in.

The attached patch fixes this problem.

[Bug fortran/93486] ICE on valid with nested submodules and long submodule names

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93486

--- Comment #1 from Andrew Benson  ---
Created attachment 47725
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47725=edit
Proposed patch

[Bug fortran/93486] New: ICE on valid with nested submodules and long submodule names

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93486

Bug ID: 93486
   Summary: ICE on valid with nested submodules and long submodule
names
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following causes an ICE with revision
ad690d79cfbb905c5546c9333c5fd089d906505b:

module ivs
  interface l
 module procedure l_
  end interface l
contains
  function l_()
  end function l_
end module ivs

module aModeratleyLongModuleName
  use ivs
  interface
 module subroutine cmo()
 end subroutine cmo
  end interface
end module aModeratleyLongModuleName

submodule (aModeratleyLongModuleName)
aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill
contains
  module procedure cmo
  end procedure cmo
end submodule aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill

submodule
(aModeratleyLongModuleName:aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill)
sb
end submodule sb

submodule (aModeratleyLongModuleName:sb) sc
end submodule sc


$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/data001/abenson/Galacticus/Tools_Devel_Install/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-git/configure
--prefix=/home/abenson/Galacticus/Tools_Devel --enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200128 (experimental) (GCC) 


$ gfortran -c test.F90 -o test.o
f951: internal compiler error: Segmentation fault
0xe1bc9f crash_signal
../../gcc-git/gcc/toplev.c:328
0x7f98119c71ef ???
   
/data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x84b3f0 gfc_use_modules()
../../gcc-git/gcc/fortran/module.c:7315
0x85acc8 use_modules
../../gcc-git/gcc/fortran/parse.c:114
0x866daa parse_module
../../gcc-git/gcc/fortran/parse.c:6111
0x86733c gfc_parse_file()
../../gcc-git/gcc/fortran/parse.c:6428
0x8b780f gfc_be_parse_file
../../gcc-git/gcc/fortran/f95-lang.c:210
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.


The ICE goes away if the module and/or submodule names are made shorter.

[Bug fortran/93473] ICE on valid with long module + submodule names

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473

--- Comment #8 from Andrew Benson  ---
I think this is PR87103 causing this problem. There's a patch in that PR
(simply removing the check for the overlong symbol name also works as the
symbol name length is already checked elsewhere). The patch has not been
approved though as there's a better fix in the works -see
https://gcc.gnu.org/ml/fortran/2018-09/msg00016.html

[Bug fortran/93461] Bogus "symbol is already defined" with long subroutine names in submodule

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93461

Andrew Benson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Andrew Benson  ---
Fixed by
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commit;h=ad690d79cfbb905c5546c9333c5fd089d906505b

[Bug fortran/93473] ICE on valid with long module + submodule names

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473

Andrew Benson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Andrew Benson  ---
Fixed by
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commit;h=a83b5cc5828ee34471de415e8893242dd3b0a91b

[Bug fortran/93473] ICE on valid with long module + submodule names

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473

--- Comment #4 from Andrew Benson  ---
@Martin - yes, thanks for the reminder, I'll send the updated patch to the GCC
mailing list.

[Bug fortran/93461] Bogus "symbol is already defined" with long subroutine names in submodule

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93461

--- Comment #5 from Andrew Benson  ---
Yes, I think this would be an ABI change. Is there anything else I need to
include in a patch as a result of this?

[Bug fortran/93473] ICE on valid with long module + submodule names

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473

--- Comment #2 from Andrew Benson  ---
Problem occurs in set_syms_host_assoc() where the "parent1" and "parent2"
variables have a maximum length of GFC_MAX_SYMBOL_LEN+1. This is insufficient
when the parent names are a module+submodule name concatenated with a ".". The
patch above fixes this by increasing their length to 2*GFC_MAX_SYMBOL_LEN+2.

[Bug fortran/93473] ICE on valid with long module + submodule names

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473

--- Comment #1 from Andrew Benson  ---
Created attachment 47722
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47722=edit
Proposed patch

[Bug fortran/93473] New: ICE on valid with long module + submodule names

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473

Bug ID: 93473
   Summary: ICE on valid with long module + submodule names
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following code causes a bogus "symbol is already defined" error (using git
commit 472dc648ce3e7661762931d584d239611ddca964):

module aModestlyLongModuleName

  type :: aTypeWithASignificantlyLongNameButStillAllowedOK
  end type aTypeWithASignificantlyLongNameButStillAllowedOK

  interface
 module function aFunctionWithALongButStillAllowedName(parameters)
result(self)
   type(aTypeWithASignificantlyLongNameButStillAllowedOK) :: self
 end function aFunctionWithALongButStillAllowedName
  end interface

end module aModestlyLongModuleName

submodule (aModestlyLongModuleName)
aTypeWithASignificantlyLongNameButStillAllowedOK_

contains

  module procedure aFunctionWithALongButStillAllowedName
 class(*), pointer :: genericObject
  end procedure aFunctionWithALongButStillAllowedName

end submodule aTypeWithASignificantlyLongNameButStillAllowedOK_

submodule
(aModestlyLongModuleName:aTypeWithASignificantlyLongNameButStillAllowedOK_)
aSubmoduleWithASignificantlyLongButStillAllowedName__
end submodule aSubmoduleWithASignificantlyLongButStillAllowedName__



$ gfortran -v 
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/data001/abenson/Galacticus/Tools_Devel_Install/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-git/configure
--prefix=/home/abenson/Galacticus/Tools_Devel --enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200127 (experimental) (GCC) 


$ gfortran -c 1057.F90 -o test.o  -ffree-line-length-none
f951: internal compiler error: Segmentation fault
0xe1021f crash_signal
../../gcc-git/gcc/toplev.c:328
0x7fd1480c91ef ???
   
/data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x891106 do_traverse_symtree
../../gcc-git/gcc/fortran/symbol.c:4173
0x85739b parse_module
../../gcc-git/gcc/fortran/parse.c:6111
0x85782d gfc_parse_file()
../../gcc-git/gcc/fortran/parse.c:6427
0x8a7f2f gfc_be_parse_file
../../gcc-git/gcc/fortran/f95-lang.c:210
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.

[Bug fortran/93461] Bogus "symbol is already defined" with long subroutine names in submodule

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93461

--- Comment #2 from Andrew Benson  ---
The problem occurs because GFC_MAX_MANGLED_SYMBOL_LEN is set to 
GFC_MAX_SYMBOL_LEN*2+4, which is sufficient for a module name plus function
name 
(plus the additional "_"'s that get prepended), but insufficient if a submodule 
name is included. The name then gets truncated and can lead to two different 
functions having the same (truncated) symbol name.

The fix is to increase this length to GFC_MAX_SYMBOL_LEN*3+5 - which allows for 
the submodule name plus the "." added between module and submodule names.

Patch attached.

[Bug fortran/93461] Bogus "symbol is already defined" with long subroutine names in submodule

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93461

--- Comment #1 from Andrew Benson  ---
Created attachment 47721
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47721=edit
Patch for PR93461

[Bug fortran/93461] New: Bogus "symbol is already defined" with long subroutine names in submodule

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93461

Bug ID: 93461
   Summary: Bogus "symbol is already defined" with long subroutine
names in submodule
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following code causes a bogus "symbol is already defined" error (using git
commit 472dc648ce3e7661762931d584d239611ddca964):

module aModuleWithAnAllowedName

  interface
 module subroutine aShortName()
 end subroutine aShortName
  end interface

end module aModuleWithAnAllowedName

submodule (aModuleWithAnAllowedName)
aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName

contains

  subroutine aShortName()
call aSubroutineWithAVeryLongNameThatWillCauseAProblem()
call aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso()
  end subroutine aShortName

  subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem()
  end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblem

  subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso()
  end subroutine aSubroutineWithAVeryLongNameThatWillCauseAProblemAlso

end submodule aSubmoduleWithAVeryVeryVeryLongButEntirelyLegalName



$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/data001/abenson/Galacticus/Tools_Devel_Install/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-git/configure
--prefix=/home/abenson/Galacticus/Tools_Devel --enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200124 (experimental) (GCC) 


$ gfortran  -c symlength.F90 -o symlength.o -ffree-line-length-none -frecursive
 -pthread -Wall -fbacktrace -ffpe-trap=invalid,zero,overflow -fdump-core -O3
-ffinite-math-only -fno-math-errno -fopenmp -g
/tmp/cc8B4Hmp.s: Assembler messages:
/tmp/cc8B4Hmp.s:20: Error: symbol
`__amodulewithanallowedname.asubmodulewithaveryveryverylongbutentirelylegalname_MOD_asubroutinewithaverylongnamethatwillcauseaprobl'
is already defined

[Bug fortran/93427] New: Rejects valid with pointer result from recursive function

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93427

Bug ID: 93427
   Summary: Rejects valid with pointer result from recursive
function
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following code fails to compile (using git commit
472dc648ce3e7661762931d584d239611ddca964):

module a

type :: t
end type t

contains

recursive function b()
  class(t), pointer :: b
  type(t) :: c
  allocate(t :: b)
  select type (b)
  type is (t)
 b=c
  end select
end function b

end module a



$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran
 --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200124 (experimental) (GCC)


$ gfortran -c p.F90 -o p.o  
p.F90:12:15:

   12 |   select type (b)
  |   1
Error: Associating entity 'b' at (1) is a procedure name
p.F90:14:5:

   14 |  b=c
  | 1
Error: 'b' at (1) associated to vector-indexed target cannot be used in a
variable definition context (assignment)


The code compiles successfully using ifort 18.0.1. Removing the "recursive"
attribute, or specifying a "result()" variable makes the errors go away.

[Bug fortran/93422] Bogus POINTER attribute mismatch with submodule MODULE PROCEDURE

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93422

--- Comment #1 from Andrew Benson  ---
Using a "result()" for the return value of the function allows this to compile
successfully:

module t

  type :: a
   contains
 procedure :: p => ap
  end type a

  type, extends(a) :: b
   contains
 procedure :: p => bp
  end type b

  type :: c
  end type c

  type, extends(c) :: d
  end type d

  interface
 module function bp(s) result(ss)
   class(b), intent(inout) :: s
   class(d), pointer :: ss
 end function
  end interface

contains

  function ap(s) result(ss)
class(d), pointer :: ss
class(a), intent(inout) :: s
  end function ap

end module t

submodule (t) ts

contains

  function bp(s) result(ss)
class(d), pointer :: ss
class(b), intent(inout) :: s
  end function bp

end submodule ts

[Bug fortran/93424] ICE on valid with pointer result from submodule function

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93424

--- Comment #1 from Andrew Benson  ---
Correction: The above code is valid (not invalid as I stated in the
description) as far as I can tell.

[Bug fortran/93424] New: ICE on valid with pointer result from submodule function

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93424

Bug ID: 93424
   Summary: ICE on valid with pointer result from submodule
function
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following invalid code results in an ICE (using git commit
472dc648ce3e7661762931d584d239611ddca964):

module t

  type :: a
   contains
 procedure :: p => ap
  end type a

  type, extends(a) :: b
   contains
 procedure :: p => bp
  end type b

  type :: c
  end type c

  interface
 module function bp(s)
   class(b), intent(inout) :: s
   class(c), pointer :: bp
 end function
  end interface

contains

  function ap(s)
class(a), intent(inout) :: s
class(c), pointer :: ap
  end function ap

end module t

submodule (t) ts

contains

  function bp(s)
class(b), intent(inout) :: s
class(c), pointer :: bp
  end function bp

end submodule ts



$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200124 (experimental) (GCC) 



$ gfortran -c test3.mod.F90 -o test3.mod.o 
f951: internal compiler error: Segmentation fault
0xe1b2bf crash_signal
../../gcc-git/gcc/toplev.c:328
0x7fc2247331ef ???
   
/data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x80cc31 compare_rank
../../gcc-git/gcc/fortran/interface.c:776
0x80cc31 compare_rank
../../gcc-git/gcc/fortran/interface.c:766
0x80ef55 gfc_check_result_characteristics(gfc_symbol*, gfc_symbol*, char*, int)
../../gcc-git/gcc/fortran/interface.c:1556
0x814ae2 gfc_check_typebound_override(gfc_symtree*, gfc_symtree*)
../../gcc-git/gcc/fortran/interface.c:4799
0x86fd0d resolve_typebound_procedure
../../gcc-git/gcc/fortran/resolve.c:14002
0x8a0769 do_traverse_symtree
../../gcc-git/gcc/fortran/symbol.c:4178
0x8785bc resolve_typebound_procedures
../../gcc-git/gcc/fortran/resolve.c:14053
0x8785bc resolve_fl_derived
../../gcc-git/gcc/fortran/resolve.c:14829
0x8751a7 resolve_symbol
../../gcc-git/gcc/fortran/resolve.c:15199
0x8a0722 do_traverse_symtree
../../gcc-git/gcc/fortran/symbol.c:4172
0x882893 resolve_types
../../gcc-git/gcc/fortran/resolve.c:17123
0x8741fc gfc_resolve(gfc_namespace*)
../../gcc-git/gcc/fortran/resolve.c:17238
0x8741fc gfc_resolve(gfc_namespace*)
../../gcc-git/gcc/fortran/resolve.c:17219
0x8670b7 gfc_parse_file()
../../gcc-git/gcc/fortran/parse.c:6446
0x8b756f gfc_be_parse_file
../../gcc-git/gcc/fortran/f95-lang.c:210
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.

[Bug fortran/93423] New: ICE on invalid with argument list for module procedure

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93423

Bug ID: 93423
   Summary: ICE on invalid with argument list for module procedure
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following invalid code results in an ICE (using git commit
472dc648ce3e7661762931d584d239611ddca964):

module t

  type :: b
   contains
 procedure :: p => bp
  end type b

  interface
 module function bp(s)
   class(b), intent(inout) :: s
   integer, pointer :: bp
 end function
  end interface

end module t

submodule (t) ts

contains

  module procedure bp(s)
  end procedure bp

end submodule ts



$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200124 (experimental) (GCC) 


$ gfortran -c test2.mod.F90 -o test2.mod.o 
test2.mod.F90:21:19:

   21 |   module procedure bp(s)
  |   1
Error: MODULE PROCEDURE at (1) must be in a generic module interface
test2.mod.F90:22:5:

   22 |   end procedure bp
  | 1
Error: Expecting END SUBMODULE statement at (1)
*** glibc detected ***
/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951:
free(): invalid pointer: 0x03e2fa70 ***
=== Backtrace: =
/home/abenson/Galacticus/Tools/lib/libc.so.6(+0x71776)[0x7fe72592a776]
/home/abenson/Galacticus/Tools/lib/libc.so.6(cfree+0x6c)[0x7fe72592f49c]
/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x8a6b4e]
/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x8a6c59]
/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x8a6276]
/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x8a6630]
/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951(_Z17gfc_symbol_done_2v+0x54)[0x8a8314]
/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951(_Z10gfc_done_2v+0x9)[0x83e559]
/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x85a9a4]
/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951(_Z14gfc_parse_filev+0xa14)[0x8675d4]
/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x8b7570]
/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0xe1b484]
/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951(_ZN6toplev4mainEiPPc+0x7ad)[0xe1db0d]
/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951(main+0x2f)[0x183b47f]
/home/abenson/Galacticus/Tools/lib/libc.so.6(__libc_start_main+0xfd)[0x7fe7258d7d0d]
/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x7c5f21]
=== Memory map: 
0040-025c3000 r-xp  09:06 39587037  
/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951
027c3000-027d3000 rw-p 021c3000 09:06 39587037  
/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951
027d3000-0292d000 rw-p  00:00 0 
03d87000-03e4a000 rw-p  00:00 0  [heap]
3c4540-3c4542 r-xp  09:01 1703950   
/lib64/ld-2.12.so
3c4561f000-3c4562 r--p 0001f000 09:01 1703950   
/lib64/ld-2.12.so
3c4562-3c45621000 rw-p 0002 09:01 1703950   
/lib64/ld-2.12.so
3c45621000-3c45622000 rw-p  00:00 0 
7fe72000-7fe720021000 rw-p  00:00 0 
7fe720021000-7fe72400 ---p  00:00 0 
7fe725347000-7fe72535e000 r-xp  09:06 38928531  
/home/abenson/Galacticus/Tools/lib64/libgcc_s.so.1
7fe72535e000-7fe72555d000 ---p 00017000 09:06 38928531  
/home/abenson/Galacticus/Tools/lib64/libgcc_s.so.1
7fe72555d000-7fe72555e000 rw-p 00016000 09:06 38928531  
/home/abenson/Galacticus/Tools/lib64/libgcc_s.so.1
7fe72555e000-7fe7258b9000 rw-p  00:00 0 
7fe7258b9000-7fe725a18000 r-xp  09:06 36448328  
/home/abenson/Galacticus/Tools/lib/libc-2.12.1.so
7fe725a18000-7fe725c18000 ---p 0015f000 09:06 36448328  
/home/abenson/Galacticus/Tools/lib/libc-2.12.1.so
7fe725c18000-7fe725c1c000 r--p 0015f000 09:06 36448328  
/home/abenson/Galacticus/Tools/lib/libc-2.12.1.so
7fe725c1c000-7fe725c1d000 rw-p 00163000 09:06 36448328  
/home/abenson/Galacticus/Tools/lib/libc-2.1

[Bug fortran/93422] New: Bogus POINTER attribute mismatch with submodule MODULE PROCEDURE

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93422

Bug ID: 93422
   Summary: Bogus POINTER attribute mismatch with submodule MODULE
PROCEDURE
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following code results in a bogus error (using git commit
472dc648ce3e7661762931d584d239611ddca964) claiming a pointer attribute mismatch
between the function result as defined in the module and submodule:


module t

  type :: a
   contains
 procedure :: p => ap
  end type a

  type, extends(a) :: b
   contains
 procedure :: p => bp
  end type b

  type :: c
  end type c

  type, extends(c) :: d
  end type d

  interface
 module function bp(s)
   class(b), intent(inout) :: s
   class(d), pointer :: bp
 end function
  end interface

contains

  function ap(s)
class(a), intent(inout) :: s
class(d), pointer :: ap
  end function ap

end module t

submodule (t) ts

contains

  function bp(s)
class(d), pointer :: bp
class(b), intent(inout) :: s
  end function bp

end submodule ts




$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200124 (experimental) (GCC) 

$ gfortran -c test4.mod.F90 -o test4.mod.o 
test4.mod.F90:35:12:

   35 | submodule (t) ts
  |1
Error: Result mismatch for the overriding procedure 'p' at (1): POINTER
attribute mismatch in function result
test4.mod.F90:39:2:

   39 |   function bp(s)
  |  1
Error: POINTER attribute mismatch in function result between the MODULE
PROCEDURE declaration in MODULE 't' and the declaration at (1) in (SUB)MODULE
'ts'


The code compiles successfully if the "pointer" attribute is removed, or if the
function in the submodule is declared using the "module procedure" approach
instead of explicitly (re)defining its interface. It also compiles successfully
using ifort 18.0.1.

[Bug libfortran/92836] segfault with inquire()

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836

--- Comment #12 from Andrew Benson  ---
(In reply to Thomas Koenig from comment #11)
> (In reply to Andrew Benson from comment #10)
> > (In reply to Thomas Koenig from comment #8)
> > My reasoning for using INQUIRE to check the existence of the file
> > is that if it doesn't exist I want one thread to proceed to create the data
> > for the file (and actually that thread will then spawn another set of nested
> > OpenMP threads to do that work).
> 
> If you look at 12.5.6.1 in F2018, you will find
> 
> If the file to be connected to the unit is the same as the file to which the
> unit is connected, a new connection is not
> established and values for any changeable modes (12.5.2) specified come into
> effect for the established connection;
> the current file position is unaffected. Before any effect on changeable
> modes, a wait operation is performed for
> any pending asynchronous data transfer operations for the specified unit. If
> the POSITION= specifier appears
> in such an OPEN statement, the value specified shall not disagree with the
> current position of the file. If the
> STATUS= specifier is included in such an OPEN statement, it shall be
> specified with the value OLD. Other than
> ERR=, IOSTAT=, and IOMSG=, and the changeable modes, the values of all other
> specifiers in such an OPEN
> statement shall not differ from those in effect for the established
> connection.
> 
> ... so my example was actually not quite correct, because the
> STATUS was wrong.
> 
> However, in order to to do what you describe, maybe an explicit variable
> to hold the file number (or flag) may be better, like this, with
> access guarded by OMP CRITICAL:
> 
> integer :: file_num = -1
> 
> !$omp parallel
> 
> ...
> 
> !$omp critical
>   if (file_num < 0) then
> open (newunit = file_num, file="foo.dat")
> ! Do a lot of other stuff
>   end if
> !$omp end critical
> ! file_num contains something valid here

That seems like a good approach - thanks for the suggestion!

[Bug libfortran/92836] segfault with inquire()

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836

--- Comment #10 from Andrew Benson  ---
(In reply to Thomas Koenig from comment #8)
> > No. The inquire() is used only to see if the file exists already. If it
> > does, the code branches to read the file, if it does not, the code branches
> > to generate the data for the file and then write it.
> 
> You have to watch out here.
> 
> If you are
> 
> a) using INQUIRE to check if the file exists
> 
> b) using OPEN if it does not
> 
> in a thread, this is classic race condition - separate threads
> may INQUIRE and then try to open, in parallel. This is not atomic,
> and is a classic race condition.
> 
> You should always put such a sequence into OMP CRITICAL.  This has
> the nice side effect that you will also avoid this bug (which should
> be fixed regardless).

It's actually doing a sequence like this:

1) INQUIRE to test for the existence of the file; assuming it does not exist
then:
2) Synchronize access to the file using an OMP CRITICAL section, and a file
lock (the file lock being necessary as this is running with MPI so there are
multiple processes than can be attempting to access the file);
3) INQUIRE again to test the existence of the file (since it's possible that it
just happened to have been created by another thread)
4) Generate data to be written to the file;
5) Open, write, and close the file.
6) Exit the OPENMP CRITICAL section and release the file lock.

This clearly allows multiple threads to INQUIRE in parallel, but I don't think
it allows any race condition on the OPEN. If I'm wrong about that though then I
should fix my code!

> Also, why do you use inquire at all? AFAIK, it is not an error
> to OPEN a file more than one if you don't change anything, so
> a simple
> 
>   open (10,file="foo.dat",status="unknown")
> 
> should, in principle, work even with OpenMP; if it doesn't, this is
> another bug that needs fixing.

I haven't tried this. Are you suggesting this as an alternative to using
INQUIRE? My reasoning for using INQUIRE to check the existence of the file is
that if it doesn't exist I want one thread to proceed to create the data for
the file (and actually that thread will then spawn another set of nested OpenMP
threads to do that work).

[Bug libfortran/92836] segfault with inquire()

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836

--- Comment #2 from Andrew Benson  ---
Answers to questions raised by Jerry at:

https://gcc.gnu.org/ml/fortran/2019-12/msg00059.html

> 1) Are you opening a unique file (by file name) in each thread?

No. The code is operating on many files, but in the specific case that causes
the problem it's a file which is shared by all threads. Specifically, it's a
file which is generated by the code if the file does not already exist (it
stores solutions to a time-consuming calculation), or is read by the code if it
does exist. All threads write/read the same file.

> 2) Are you trying to synchronize these threads using the inquire?

No. The inquire() is used only to see if the file exists already. If it does,
the code branches to read the file, if it does not, the code branches to
generate the data for the file and then write it.

Synchronization of the file accesses are being handled using file locks, i.e. I
use ISO_C_Binding to allow me to call fcntl(). Since the Linux kernel on the
machine I'm using is too old to support OFD locks I'm using POSIX locks plus
OpenMP locks (since POSIX locks are per processes so I have to separately
synchronize the OpenMP threads).

> 3) or, trying to ensure a unique filename for each file or avoid the same
> file in two or more threads?

No. The problem always seems to occur when a thread inquires() on one
particular file, and the file name is the same across all threads.

There are other places in my code where inquire() is being used on other file
names. But in all cases the filename is the same for all threads.

[Bug libfortran/92836] segfault with inquire()

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836

--- Comment #1 from Andrew Benson  ---
Running with -fsanitize=thread (suggested by Tobias) gives:

==
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=9982)
  Cycle in lock order graph: M26 (0x7f02bb31c340) => M84 (0x7b58002efee0) => 
M26

  Mutex M84 acquired here while holding mutex M26 in thread T63:
#0 pthread_mutex_lock ../../../../gcc-trunk/libsanitizer/sanitizer_common/
sanitizer_common_interceptors.inc:4148 (libtsan.so.0+0x5095a)
#1 __gthread_mutex_lock ../libgcc/gthr-default.h:749 (libgfortran.so.
5+0x1e25c9)
#2 insert_unit ../../../gcc-trunk/libgfortran/io/unit.c:244 
(libgfortran.so.5+0x1e25c9)
#3 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:123 (libgomp.so.
1+0x198a5)

  Mutex M26 previously acquired by the same thread here:
#0 pthread_mutex_lock ../../../../gcc-trunk/libsanitizer/sanitizer_common/
sanitizer_common_interceptors.inc:4148 (libtsan.so.0+0x5095a)
#1 __gthread_mutex_lock ../libgcc/gthr-default.h:749 (libgfortran.so.
5+0x1e265c)
#2 get_gfc_unit ../../../gcc-trunk/libgfortran/io/unit.c:332 
(libgfortran.so.5+0x1e265c)
#3 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:123 (libgomp.so.
1+0x198a5)

  Mutex M26 acquired here while holding mutex M84 in thread T63:
#0 pthread_mutex_lock ../../../../gcc-trunk/libsanitizer/sanitizer_common/
sanitizer_common_interceptors.inc:4148 (libtsan.so.0+0x5095a)
#1 __gthread_mutex_lock ../libgcc/gthr-default.h:749 (libgfortran.so.
5+0x1e336b)
#2 close_unit_1 ../../../gcc-trunk/libgfortran/io/unit.c:735 
(libgfortran.so.5+0x1e336b)
#3 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:123 (libgomp.so.
1+0x198a5)

  Mutex M84 previously acquired by the same thread here:
#0 pthread_mutex_trylock ../../../../gcc-trunk/libsanitizer/tsan/
tsan_interceptors_posix.cpp:1246 (libtsan.so.0+0x4340a)
#1 __gthread_mutex_trylock ../libgcc/gthr-default.h:758 (libgfortran.so.
5+0x1e26f1)
#2 get_gfc_unit ../../../gcc-trunk/libgfortran/io/unit.c:380 
(libgfortran.so.5+0x1e26f1)
#3 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:123 (libgomp.so.
1+0x198a5)

  Thread T63 (tid=10047, running) created by main thread at:
#0 pthread_create ../../../../gcc-trunk/libsanitizer/tsan/
tsan_interceptors_posix.cpp:962 (libtsan.so.0+0x5bb22)
#1 gomp_team_start ../../../gcc-trunk/libgomp/team.c:839 (libgomp.so.
1+0x19eba)
#2 main  (a.out+0x400ef9)

SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) ../libgcc/
gthr-default.h:749 in __gthread_mutex_lock
==

[Bug libfortran/92836] New: segfault with inquire()

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836

Bug ID: 92836
   Summary: segfault with inquire()
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

I'm attempting to track down a segfault that seems to be associated with the 
inquire() statement. Unfortunately it only happens when running a massively 
parallel code, using both MPI and OpenMP parallelism, and I have as yet been 
unable to make a simple test case that reproduces the bug. I also haven't 
convinced myself 100% that the problem is really in the libgfortran code for 
inquire() and not in my own code, but since it seems that inquire() should be 
thread safe it seems that the problem at least could be in libgfortran.

So, I'm hoping that someone on the mailing list has suggestions for how to 
track this down as I've exhausted everything I can think of!

The segfault is triggered by:

inquire(file=fileName,exist=exists)

This works as expected most of the time, but occasionally (typically after 
thousands of calls in a code running with 128 MPI processes and 4 OpenMP 
threads each) it will segfault. The gdb trace for the failed thread is:

(gdb) where
#0  galacticus_error::galacticus_signal_handler_sigsegv () at ./work/buildMPI/
galacticus.error.p.F90:328
#1  
#2  find_file0 (u=, st=st@entry=0x7ffed9b88ad0) at ../../../gcc-
trunk/libgfortran/io/unix.c:1725
#3  0x7f33ac1b7460 in find_file0 (u=, 
st=st@entry=0x7ffed9b88ad0) at ../../../gcc-trunk/libgfortran/io/unix.c:1741
#4  0x7f33ac1b7460 in find_file0 (u=, 
st=st@entry=0x7ffed9b88ad0) at ../../../gcc-trunk/libgfortran/io/unix.c:1741
#5  0x7f33ac1b7460 in find_file0 (u=, 
st=st@entry=0x7ffed9b88ad0) at ../../../gcc-trunk/libgfortran/io/unix.c:1741
#6  0x7f33ac1b7460 in find_file0 (u=, 
st=st@entry=0x7ffed9b88ad0) at ../../../gcc-trunk/libgfortran/io/unix.c:1741
#7  0x7f33ac1b7460 in find_file0 (u=, 
st=st@entry=0x7ffed9b88ad0) at ../../../gcc-trunk/libgfortran/io/unix.c:1741
#8  0x7f33ac1b8bbb in _gfortrani_find_file (file=, 
file_len=) at ../../../gcc-trunk/libgfortran/io/unix.c:1779
#9  0x7f33ac1a601d in _gfortran_st_inquire (iqp=0x7ffed9b88bf0) at 
../../../gcc-trunk/libgfortran/io/inquire.c:803

and the relevant line in unix.c is:

1725  if (st[0].st_dev == s->st_dev && st[0].st_ino == s->st_ino)

If I examine the variables used in this line I find:

(gdb) print st[0]
$2 = {st_dev = 24, st_ino = 12194159, st_nlink = 1, st_mode = 33188, st_uid = 
509, st_gid = 100, __pad0 = 0, st_rdev = 0, st_size = 104168, st_blksize = 
1048576, st_blocks = 208, 
  st_atim = {tv_sec = 1575236480, tv_nsec = 343597308}, st_mtim = {tv_sec = 
1575236486, tv_nsec = 774663718}, st_ctim = {tv_sec = 1575236486, tv_nsec = 
774663718}, __unused = {0, 0, 
0}}
(gdb) print *s
Cannot access memory at address 0x7f33818d7eb0

which suggests that "s" is somehow corrupted. I don't see how this can happen 
though as the "unit_lock" lock is used by find_file() which should prevent any 
modification to the tree of units. 

One other OpenMP thread was waiting for unit_lock:

#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/
lowlevellock.S:136
#1  0x7f33ab4a354f in _L_lock_1028 () from /home/abenson/Galacticus/Tools/
lib/libpthread.so.0
#2  0x7f33ab4a336b in __pthread_mutex_lock (mutex=0x7f33ac40b340 
<_gfortrani_unit_lock>) at pthread_mutex_lock.c:61
#3  0x7f33ac1b6f3c in __gthread_mutex_lock (__mutex=0x7f33ac40b340 
<_gfortrani_unit_lock>) at ../libgcc/gthr-default.h:749
#4  _gfortrani_newunit_alloc () at ../../../gcc-trunk/libgfortran/io/unit.c:
906
#5  0x7f33ac1b706b in _gfortrani_get_unit (dtp=dtp@entry=0x7f33a1785800, 
do_create=do_create@entry=1) at ../../../gcc-trunk/libgfortran/io/unit.c:555
#6  0x7f33ac1b4ebd in data_transfer_init (dtp=dtp@entry=0x7f33a1785800, 
read_flag=read_flag@entry=0) at ../../../gcc-trunk/libgfortran/io/transfer.c:
2851
#7  0x7f33ac1b5924 in _gfortran_st_write (dtp=dtp@entry=0x7f33a1785800) at 
../../../gcc-trunk/libgfortran/io/transfer.c:4392

and was doing other writes to an internal file unit just prior to this.

[Bug fortran/92701] New: ICE assigning to assumed rank derived type component

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92701

Bug ID: 92701
   Summary: ICE assigning to assumed rank derived type component
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following code causes an ICE with gfortran 10.0 (r278783):

module a

  type :: r
  end type r

  type, extends(r) :: rr
 double precision:: d
  end type rr 

contains

  subroutine abd(p)
implicit none
class(r), intent(inout), dimension(..) :: p
double precision, dimension(:), allocatable :: d
select rank (p)
rank (1)
   select type (p)
   type is (rr)
  allocate(d(size(p,dim=1)))
  d=0.0d0
  p%d=d
   end select
end select
return
  end subroutine abd

end module a

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib : (reconfigured)
../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--disable-multilib --enable-languages=c,c++,fortran,lto --no-create
--no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20191127 (experimental) (GCC) 


$ gfortran -c bug.F90 -o bug.o
f951: internal compiler error: Segmentation fault
0xdd4adf crash_signal
../../gcc-trunk/gcc/toplev.c:328
0x7fa79dd101ef ???
   
/data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7d41a1 gfc_check_vardef_context(gfc_expr*, bool, bool, bool, char const*)
../../gcc-trunk/gcc/fortran/expr.c:6237
0x84cff7 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:11768
0x8508b7 resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:17180
0x83c2ce gfc_resolve(gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:17215
0x83c2ce gfc_resolve(gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:17194
0x84cc58 resolve_block_construct
../../gcc-trunk/gcc/fortran/resolve.c:10549
0x84cc58 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:11899
0x84ef43 gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:10691
0x84fa0b resolve_select_type
../../gcc-trunk/gcc/fortran/resolve.c:9544
0x84cbe1 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:11891
0x84ef43 gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:10691
0x84c3b8 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:11654
0x8508b7 resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:17180
0x8507ee resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:17163
0x83c2ce gfc_resolve(gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:17215
0x83c2ce gfc_resolve(gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:17194
0x82f078 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:6443
0x87f30f gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:210
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.



The ICE seems to be triggered by the "p%d=d" assignment.

[Bug fortran/90788] New: ICE on allocating derived type containing class(*) pointer initialized to null()

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90788

Bug ID: 90788
   Summary: ICE on allocating derived type containing class(*)
pointer initialized to null()
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following gives an ICE with trunk:

module vdc
  type:: vdcp
 class(*), pointer :: po => null()
  end type vdcp
end module vdc

module oa
contains
  subroutine i1()
use :: vdc, only : vdcp
type(vdcp), pointer :: a, b
allocate(a)
  end subroutine i1
  subroutine i2()
use :: vdc, only : vdcp
type(vdcp), pointer :: a
allocate(a)
  end subroutine i2
end module oa


$ gfortran -c  tmp.F90 -o tmp.o
tmp.F90:12:0:

   12 | allocate(a)
  | 
internal compiler error: Segmentation fault
0xde688f crash_signal
../../gcc-trunk/gcc/toplev.c:326
0x7fedc334d1ef ???
   
/data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x904f94 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc-trunk/gcc/tree.h:3307
0x904f94 gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool)
../../gcc-trunk/gcc/fortran/trans-expr.c:8360
0x904702 gfc_trans_subcomponent_assign
../../gcc-trunk/gcc/fortran/trans-expr.c:8205
0x904fe0 gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool)
../../gcc-trunk/gcc/fortran/trans-expr.c:8370
0x905e76 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc-trunk/gcc/fortran/trans-expr.c:8437
0x907b25 gfc_trans_assignment_1
../../gcc-trunk/gcc/fortran/trans-expr.c:10779
0x9453f8 gfc_trans_allocate(gfc_code*)
../../gcc-trunk/gcc/fortran/trans-stmt.c:6663
0x8c34d7 trans_code
../../gcc-trunk/gcc/fortran/trans.c:1995
0x8efebb gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.c:6705
0x8c76c1 gfc_generate_module_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans.c:2221
0x8773ad translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.c:6121
0x8773ad gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:6367
0x8c05ef 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.


$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 10.0.0 20190608 (experimental) (GCC) 



The ICE only occurs if there are two subroutines each with an "allocate(a)"
statement - one such subroutine on its own does not trigger the ICE. 

The ICE also goes away if the class(*) pointer is not initialized to null().

[Bug fortran/90786] New: ICE on procedure pointer assignment to function with class pointer result

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786

Bug ID: 90786
   Summary: ICE on procedure pointer assignment to function with
class pointer result
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following causes an ICE on trunk:

module f
procedure(c), pointer :: c_ 

 type :: s 
 end type s 

contains 

 function c() 
   implicit none 
   class(s), pointer ::  c 
   c => null() 
   return 
 end function c 

 subroutine fs() 
   implicit none 
   c_ => c 
   return 
 end subroutine fs 

end module f



$ gfortran -c tmp.F90 -o tmp.o 
tmp.F90:18:0: 

  18 | c_ => c 
 |  
internal compiler error: tree check: expected record_type or union_type or
qual_union_type, have function_type in gfc_class_data_get, at
fortran/trans-expr.c:191 
0x71c0f0 tree_check_failed(tree_node const*, char const*, int, char const*,
...) 
   ../../gcc-trunk/gcc/tree.c:9900 
0x5d791d tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code) 
   ../../gcc-trunk/gcc/tree.h:3220
0x5d791d gfc_class_data_get(tree_node*)
../../gcc-trunk/gcc/fortran/trans-expr.c:191
0x8feec1 gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.c:8898
0x8b70d2 trans_code
../../gcc-trunk/gcc/fortran/trans.c:1833
0x8e393b gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.c:6655
0x8bb4a1 gfc_generate_module_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans.c:2219
0x86b095 translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.c:6121
0x86b095 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:6337
0x8b43ef 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.


$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 10.0.0 20190501 (experimental) (GCC) 



Possibly related to PR86242?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86242

[Bug fortran/87103] [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103

--- Comment #2 from Andrew Benson  ---
Thanks Janus. That does solve the problem, and regtests cleanly, with this
patch:




Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h  (revision 264085)
+++ gcc/fortran/gfortran.h  (working copy)
@@ -54,7 +54,9 @@ not after.

 /* Major control parameters.  */

-#define GFC_MAX_SYMBOL_LEN 63   /* Must be at least 63 for F2003.  */
+/* Must be at least 63 for F2003, +1 for null terminator,
+ +12 for prefix "__tmp_class_".  */
+#define GFC_MAX_SYMBOL_LEN 76
 #define GFC_LETTERS 26 /* Number of letters in the alphabet.  */

 #define MAX_SUBRECORD_LENGTH 2147483639   /* 2**31-9 */

[Bug fortran/87103] New: ICE in gfc_new_symbol() due to overlong symbol name

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103

Bug ID: 87103
   Summary: ICE in gfc_new_symbol() due to overlong symbol name
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following code causes an ICE with gfortan 9.0.0 (r263855):

module a
  type :: nameThatIsVeryLongButNotTooLongThatItShouldBeInvalid
  end type nameThatIsVeryLongButNotTooLongThatItShouldBeInvalid
contains
  subroutine b(self)
class(nameThatIsVeryLongButNotTooLongThatItShouldBeInvalid), intent(in) ::
self
select type (self)
class is (nameThatIsVeryLongButNotTooLongThatItShouldBeInvalid)
end select
  end subroutine b
end module a

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib : (reconfigured)
../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib : (reconfigured)
../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--disable-multilib --enable-languages=c,c++,fortran,lto --no-create
--no-recursion : (reconfigured) ../gcc-trunk/configure
--prefix=/home/abenson/Galacticus/Tools --disable-multilib
--enable-languages=c,c++,fortran,lto --no-create --no-recursion :
(reconfigured) ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--disable-multilib --enable-languages=c,c++,fortran,lto --no-create
--no-recursion
Thread model: posix
gcc version 9.0.0 20180825 (experimental) (GCC) 


$ gfortran -c tmp1.F90 -o tmp1.o
f951: internal compiler error: new_symbol(): Symbol name too long
0x7b9711 gfc_internal_error(char const*, ...)
../../gcc-trunk/gcc/fortran/error.c:1362
0x84a838 gfc_new_symbol(char const*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/symbol.c:3132
0x84ab97 gfc_get_sym_tree(char const*, gfc_namespace*, gfc_symtree**, bool)
../../gcc-trunk/gcc/fortran/symbol.c:3373
0x7e565d select_type_set_tmp
../../gcc-trunk/gcc/fortran/match.c:6114
0x7ee260 gfc_match_class_is()
../../gcc-trunk/gcc/fortran/match.c:6470
0x808c79 match_word
../../gcc-trunk/gcc/fortran/parse.c:65
0x80a4f1 decode_statement
../../gcc-trunk/gcc/fortran/parse.c:462
0x80d04c next_free
../../gcc-trunk/gcc/fortran/parse.c:1234
0x80d04c next_statement
../../gcc-trunk/gcc/fortran/parse.c:1466
0x810861 parse_select_type_block
../../gcc-trunk/gcc/fortran/parse.c:4236
0x810861 parse_executable
../../gcc-trunk/gcc/fortran/parse.c:5330
0x8118e6 parse_progunit
../../gcc-trunk/gcc/fortran/parse.c:5697
0x811bfc parse_contained
../../gcc-trunk/gcc/fortran/parse.c:5574
0x812a4c parse_module
../../gcc-trunk/gcc/fortran/parse.c:5944
0x812f75 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:6247
0x859d3f 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.


The problem seems to be that gfc_new_symbol() is passed a name
'__tmp_class_namethatisverylongbutnottoolongthatitshouldbeinvalid' in this case
which exceeds GFC_MAX_SYMBOL_LEN=64. My understanding is that the code is valid
since the symbol name itself,
'namethatisverylongbutnottoolongthatitshouldbeinvalid', is less than 64
characters. 

I'm not sure what the correct fix for this is - should the name length limit in
gfc_new_symbol() just be increased by enough to allow the '__tmp_class_'
prefix?

[Bug fortran/85138] [8 regression] ICE with generic function

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138

--- Comment #4 from Andrew Benson  ---
A related but possibly different ICE:


module fox_m_fsys_format
  interface len
module procedure str_real_dp_len, str_real_dp_fmt_len
  end interface
contains
  pure function str_real_dp_fmt_len(x, fmt) result(n)
real, intent(in) :: x
character(len=*), intent(in) :: fmt
if (.not.checkFmt(fmt)) then
endif
  end function str_real_dp_fmt_len
  pure function str_real_dp_len(x) result(n)
real, intent(in) :: x
  end function str_real_dp_len
  pure function str_real_dp_array_len(xa) result(n)
real, dimension(:), intent(in) :: xa
  end function str_real_dp_array_len
  pure function str_real_dp_array_fmt_len(xa, fmt) result(n)
real, dimension(:), intent(in) :: xa
character(len=*), intent(in) :: fmt
  end function str_real_dp_array_fmt_len
  pure function str_real_dp_fmt(x, fmt) result(s)
real, intent(in) :: x
character(len=*), intent(in) :: fmt
character(len=len(x, fmt)) :: s
  end function str_real_dp_fmt
  pure function checkFmt(fmt) result(good)
character(len=*), intent(in) :: fmt
logical :: good
  end function checkFmt
end module fox_m_fsys_format


$ gfortran -c  tmp6.F90

 if (.not.checkFmt(fmt)) then

internal compiler error: Segmentation fault
0xd2f4cf crash_signal
../../gcc-trunk/gcc/toplev.c:325
0x7f434bb321ef ???
   
/data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x881660 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc-trunk/gcc/fortran/trans-expr.c:4890
0x886eaa gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.c:7922
0x889cc7 gfc_conv_expr_val(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.c:7975
0x889d61 gfc_conv_unary_op
../../gcc-trunk/gcc/fortran/trans-expr.c:2799
0x887060 gfc_conv_expr_op
../../gcc-trunk/gcc/fortran/trans-expr.c:3317
0x887060 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.c:7918
0x889cc7 gfc_conv_expr_val(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.c:7975
0x8c00d7 gfc_trans_if_1
../../gcc-trunk/gcc/fortran/trans-stmt.c:1427
0x8c8dba gfc_trans_if(gfc_code*)
../../gcc-trunk/gcc/fortran/trans-stmt.c:1464
0x84ca37 trans_code
../../gcc-trunk/gcc/fortran/trans.c:1916
0x878a2d gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.c:6507
0x850cc1 gfc_generate_module_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans.c:
0x80333b translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.c:6108
0x80333b gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:6324
0x849b8f 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  for instructions.

[Bug fortran/85138] New: ICE with generic function

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85138

Bug ID: 85138
   Summary: ICE with generic function
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following (reduced from a much larger module) causes an ICE with gfortran
8.0.1 r258983:

module fox_m_fsys_format
  interface len
 module procedure str_real_sp_len, str_real_sp_fmt_len
  end interface
contains
  pure function str_real_sp_fmt_len(x, fmt) result(n)
real, intent(in) :: x
character(len=*), intent(in) :: fmt
if (.not.checkFmt(fmt)) then
endif
  end function str_real_sp_fmt_len
  pure function str_real_sp_len(x) result(n)
real, intent(in) :: x
n = len(x, "")
  end function str_real_sp_len
  function str_real_dp_matrix(xa) result(s)
real, intent(in) :: xa
character(len=len(xa)) :: s
  end function str_real_dp_matrix
end module fox_m_fsys_format

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fort
an --disable-multilib
Thread model: posix
gcc version 8.0.1 20180330 (experimental) (GCC)

$ gfortran -c tmp3.F90
tmp3.F90:9:0:

 if (.not.checkFmt(fmt)) then

internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1157
0x5ee3b2 gfc_typenode_for_spec(gfc_typespec*, int)
../../gcc-trunk/gcc/fortran/trans-types.c:1157
0x889d77 gfc_conv_unary_op
../../gcc-trunk/gcc/fortran/trans-expr.c:2802
0x887060 gfc_conv_expr_op
../../gcc-trunk/gcc/fortran/trans-expr.c:3317
0x887060 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.c:7918
0x889cc7 gfc_conv_expr_val(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.c:7975
0x8c00d7 gfc_trans_if_1
../../gcc-trunk/gcc/fortran/trans-stmt.c:1427
0x8c8dba gfc_trans_if(gfc_code*)
../../gcc-trunk/gcc/fortran/trans-stmt.c:1464
0x84ca37 trans_code
../../gcc-trunk/gcc/fortran/trans.c:1916
0x878a2d gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.c:6507
0x850cc1 gfc_generate_module_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans.c:
0x80333b translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.c:6108
0x80333b gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:6324
0x849b8f 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.

[Bug fortran/84538] [8 Regression] Array of derived type elements incorrectly accessed in function

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84538

--- Comment #3 from Andrew Benson  ---
Hi Paul,

Thanks for the select type workaround suggestion - I'll do that for now.

[Bug fortran/84538] New: Array of derived type elements incorrectly accessed in function

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84538

Bug ID: 84538
   Summary: Array of derived type elements incorrectly accessed in
function
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following code results in incorrect behavior with gfortran 8.0.1 (r257956):

module bugMod
  public
  type :: t
 integer :: i
  end type t
  type, extends(t) :: te
 integer :: j
  end type te
contains
  subroutine check(n)
implicit none
class(t), intent(inout), dimension(:) :: n
write (0,*) "FROM MODULE  ",n%i
return
  end subroutine check
end module bugMod

program bug
  use bugMod
  class(t), allocatable, dimension(:) :: n
  allocate(te :: n(2))
  n(1:2)%i=[8,3]
  write (0,*) "FROM PROGRAM ",n%i
  call check(n)
end program bug

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/nfs/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/nfs/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 8.0.1 20180223 (experimental) (GCC) 

$ gfortran bug.F90
$ a.out 
 FROM PROGRAM8   3
 FROM MODULE 8   0

I would expect the output to be the same from the module subroutine as from the
main program.

[Bug fortran/84412] New: Erroneous "Inquire statement identifies an internal file" error

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84412

Bug ID: 84412
   Summary: Erroneous "Inquire statement identifies an internal
file" error
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

Using gfortran 8.0.1 (r257607) the following produces an erroneous error of
"Inquire statement identifies an internal file":

program bug
  implicit none
  integer  :: i
  character(len=1) :: s
  write (s,'(i1)') 0
  open(newUnit=i,file='bug.txt',status='unknown')
  inquire(unit=i)
end program bug

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 8.0.1 20180212 (experimental) (GCC) 

$ gfortran bug.F90

$ a.out 
At line 7 of file bug.F90
Fortran runtime error: Inquire statement identifies an internal file

Error termination. Backtrace:
#0  0x7fd470750d44 in inquire_via_unit
at ../../../gcc-trunk/libgfortran/io/inquire.c:47
#1  0x400969 in ???
#2  0x4009a0 in ???
#3  0x7fd46fb7ed0c in __libc_start_main
at /data001/abenson/Galacticus/Tools/glibc-2.12.1/csu/libc-start.c:226
#4  0x4006f8 in ???

If the WRITE statement is removed the error does not occur.

[Bug fortran/80440] New: Slow compile when USEing modules

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80440

Bug ID: 80440
   Summary: Slow compile when USEing modules
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

Compile times for code that makes extensive USEs of modules seems to be very 
slow in some cases. I've been doing some investigation of the cause of this 
with the hope that I can maybe figure out some way to speed things up.

For example, I have a smallish file - 700 lines of code, which takes around 3 
minutes to compile with a recent build of gfortran. Profiling f951 with 
valgrind I find that 63% of that time is spent in find_symtree_for_symbol(), 
which (if I understand correctly) is searching for a node in the symtree that 
already references some symbol being imported from a module. 

find_symtree_for_symbol() gets called directly 245,658 times in compiling this 
source file (and calls itself recursively almost 19 billion times!).

find_symtree_for_symbol() is just stepping through a binary branching tree 
looking for a reference to a given symbol, but (again, if I understood 
correctly), it can't use the usual bbt search approach because the tree is not 
ordered by the symbol name, so the search is O(n) rather than O(log n). 

If I ignore my ignorance of why the ordered tree isn't used here and go ahead
and search it using the symbol name (ignoring case which seems to differ
between the symbol name and the name of the symtree node) then I certainly get
a substantial speed-up (the file I mentioned now compiles in 40s), and nothing
seems to break. I ran the gfortan test suite which shows two FAILs:

gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/graphite/pr68279.f90   -
O  (internal compiler error)
gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/graphite/pr68279.f90   -
O  (test for excess errors)

but those show up when I run the test suite without any change to module.c 
anyway.

The patch I used is:

diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 6d3860e..f28a7b7 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -4286,22 +4286,25 @@ mio_symbol (gfc_symbol *sym)
 static gfc_symtree *
 find_symtree_for_symbol (gfc_symtree *st, gfc_symbol *sym)
 {
-  gfc_symtree *s = NULL;
-
-  if (st == NULL)
-return s;
-
-  s = find_symtree_for_symbol (st->right, sym);
-  if (s != NULL)
-return s;
-  s = find_symtree_for_symbol (st->left, sym);
-  if (s != NULL)
-return s;
+  int c;
+  
+  while (st != NULL)
+{
+  c = strcasecmp(sym->name, st->name);
+  if ( c == 0 )
+   {
+ if ( !check_unique_name (st->name))
+   {
+ return st;
+   } else {
+   return NULL;
+ }
+   }

-  if (st->n.sym == sym && !check_unique_name (st->name))
-return st;
+  st = (c < 0) ? st->left : st->right;
+}

-  return s;
+  return NULL;
 }

[Bug fortran/58175] [OOP] Incorrect warning message on scalar finalizer

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175

--- Comment #18 from Andrew Benson  ---
Thanks Janus. I can confirm that I see no more of these warnings now!

[Bug fortran/37336] [F03] Finish derived-type finalization

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
Bug 37336 depends on bug 58175, which changed state.

Bug 58175 Summary: [OOP] Incorrect warning message on scalar finalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

[Bug fortran/58175] [OOP] Incorrect warning message on scalar finalizer

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175

Andrew Benson  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #15 from Andrew Benson  ---
Hi Janus,

The patch fixes most cases but, when compiling my full code I found some cases
which still report the erroneous warning. These seem to be with cases where a
derived type extends another derived type. For example, with gfortran 7.0.0 (r
242964) the following occurs:

module ct
  type :: a
   contains
 final :: aD
  end type a
  type, extends(a) :: a1
   contains
  end type a1
contains
  subroutine aD(self)
type(a), intent(inout) :: self
  end subroutine aD
end module ct
program test
  use ct
end program test

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 7.0.0 20161129 (experimental) (GCC) 

$ gfortran -c bug.F90 -o bug.o -Wall
bug.F90:7:24:

   type, extends(a) :: a1
1
Warning: Only array FINAL procedures declared for derived type 'a1' defined at
(1), suggest also scalar one [-Wsurprising]
bug.F90:16:6:

   use ct
  1
Warning: Only array FINAL procedures declared for derived type 'a1' defined at
(1), suggest also scalar one [-Wsurprising]
bug.F90:11:20:

   subroutine aD(self)
1
Warning: Unused dummy argument 'self' at (1) [-Wunused-dummy-argument]

So, there's no warning about the finalizer for type "a", but for type "a1"
there's still a warning present.

[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387

--- Comment #5 from Andrew Benson  ---
I couldn't find anything in the OpenMP specifications which addresses this
issue - so presumably it's undefined behavior as far as OpenMP is concerned.
But it seems that internal file writes were intended to be thread safe in
gfortran - am I correct in understanding that? From what I can tell Intel
fortran also makes internal file writes thread safe, for what it's worth.

[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387

--- Comment #2 from Andrew Benson  ---
OK - thanks. I hadn't realized that the internal I/O operations weren't
threadsafe - I guess I've just been fortunate to avoid this with previous
versions of gfortran. I'll update my code to use critical sections as
necessary.

Thanks for the fast response!

[Bug fortran/78387] New: OpenMP segfault/stack size exceeded writing to internal file

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387

Bug ID: 78387
   Summary: OpenMP segfault/stack size exceeded writing to
internal file
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following code when run using OpenMP crashes with a "stack size exceeded"
error (and, sometimes, a segfault) under gfortran 7.0.0 (r242500). This happens
most times I run the code, but not every time. When compiled with gfortran
6.0.0 it runs successfully every time.

program p
  double precision :: b
  b=0.1d0
  !$omp parallel
  call s(b)
  !$omp end parallel
contains
  subroutine s(a)
implicit none
double precision, intent(in) :: a
character(len=10) :: f,c
write (f,'(a5,i1,a1)') "(e10.",2,")"
write (c,f) a
write (0,*) trim(c)
return
  end subroutine s
end program p

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 7.0.0 20161116 (experimental) (GCC) 

$ gfortran t.F90 -g -fopenmp
[abenson@mies v0.9.4]$ a.out 
   0.10E+00
   0.10E+00
   0.10E+00
   0.10E+00
At line 12 of file t.F90
Internal Error: stash_internal_unit(): Stack Size Exceeded

Error termination. Backtrace:
   0.10E+00
   0.10E+00
   0.10E+00
   0.10E+00
   0.10E+00
   0.10E+00
   0.10E+00
   0.10E+00
   0.10E+00
   0.10E+00
   0.10E+00
#0  0x400a7b in s
at /home/abenson/Galacticus/v0.9.4/t.F90:12
#1  0x400c53 in MAIN__._omp_fn.0
at /home/abenson/Galacticus/v0.9.4/t.F90:5
#2  0x7f786cbc955d in gomp_thread_start
at ../../../gcc-trunk/libgomp/team.c:119
#3  0x7f786bdbdc39 in start_thread
at
/data001/abenson/Galacticus/Tools/glibc-2.12.1/nptl/pthread_create.c:301
#4  0x7f786c4c361c in ???
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
#5  0x in ???

The frequency with which the code crashes increases as the number of OpenMP
threads is increased (running with 2 threads it almost always runs
successfully, with 4 threads it crashes on 1 run in 10-20, with 16 threads it
crashes almost every time).

The error is sometimes reported at line 12, sometimes at line 13 - but always
the same "stack size exceeded" error.

[Bug fortran/78356] [7 Regression] [OOP] segfault allocating polymorphic variable with polymorphic component with allocatable component

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78356

--- Comment #6 from Andrew Benson  ---
(In reply to janus from comment #3)
> (In reply to janus from comment #2)
> > I suspect it may be caused by Andre's r241885 ...
> 
> I may be wrong, though: It seems like reverting those changes does not solve
> the problem.
> 
> Another candidate: r241439.
> 
> 
> @Andrew: Are you aware of an earlier trunk build where this was still
> working? If yes, can you give a revision number?

I didn't record the previous revision number I used unfortunately, but it looks
like you were able to figure out the problem revision anyway,

[Bug fortran/78356] New: segfault allocating polymorphic variable with polymorphic component with allocatable component

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78356

Bug ID: 78356
   Summary: segfault allocating polymorphic variable with
polymorphic component with allocatable component
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following code causes a segfault at runtime using gfortran 7.0.0 (r242406),
but runs successfully when compiled with gfortran 6.0.0. Output and output from
valgrind are appended below.

module m
  implicit none
  type ac
  end type ac
  type, extends(ac) :: a
 integer, allocatable, dimension(:) :: b
  end type a
  type n
 class(ac), allocatable, dimension(:) :: acr
   contains
 procedure :: ncp => nncp
  end type n
contains
  subroutine nncp(self,tg)
implicit none
class(n), intent(in   ) :: self
class(n), intent(inout) :: tg
allocate(tg%acr(1),source=self%acr(1))
return
  end subroutine nncp
end module m
program p
  use m
  implicit none
  type(n) :: s,t
  allocate(a :: s%acr(1))
  call s%ncp(t)
end program

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 7.0.0 20161115 (experimental) (GCC) 

$ a.out 

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7ff186f0d1ef in ???
at
/data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
#1  0x7ff186f5a460 in ???
at ../sysdeps/x86_64/memcpy.S:161
#2  0x40167b in __copy_m_A
at /home/abenson/Galacticus/v0.9.4/c.F90:22
#3  0x400f59 in __m_MOD_nncp
at /home/abenson/Galacticus/v0.9.4/c.F90:18
#4  0x401593 in p
at /home/abenson/Galacticus/v0.9.4/c.F90:27
#5  0x4016c4 in main
at /home/abenson/Galacticus/v0.9.4/c.F90:23
Segmentation fault

$ valgrind a.out 
==1544== Memcheck, a memory error detector
==1544== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==1544== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==1544== Command: a.out
==1544== 
==1544== Argument 'size' of function malloc has a fishy (possibly negative)
value: -274793986988
==1544==at 0x4A05B60: malloc (vg_replace_malloc.c:299)
==1544==by 0x401647: __copy_m_A.3590 (c.F90:22)
==1544==by 0x400F59: __m_MOD_nncp (c.F90:18)
==1544==by 0x401593: MAIN__ (c.F90:27)
==1544==by 0x4016C4: main (c.F90:23)
==1544== 
==1544== Source and destination overlap in memcpy(0x0, 0x2,
18446743798915564628)
==1544==at 0x4A0A4D3: memcpy (vg_replace_strmem.c:1019)
==1544==by 0x40167B: __copy_m_A.3590 (c.F90:22)
==1544==by 0x400F59: __m_MOD_nncp (c.F90:18)
==1544==by 0x401593: MAIN__ (c.F90:27)
==1544==by 0x4016C4: main (c.F90:23)
==1544== 
==1544== Invalid read of size 2
==1544==at 0x4A0A6E8: memcpy (vg_replace_strmem.c:1019)
==1544==by 0x40167B: __copy_m_A.3590 (c.F90:22)
==1544==by 0x400F59: __m_MOD_nncp (c.F90:18)
==1544==by 0x401593: MAIN__ (c.F90:27)
==1544==by 0x4016C4: main (c.F90:23)
==1544==  Address 0x2 is not stack'd, malloc'd or (recently) free'd
==1544== 

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x56431ef in ???
at
/data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
#1  0x4a0a6e8 in _vgr20180ZZ_libcZdsoZa_memcpy
at ../shared/vg_replace_strmem.c:1019
#2  0x40167b in ???
#3  0x400f59 in ???
#4  0x401593 in ???
#5  0x4016c4 in ???
#6  0x562fd0c in __libc_start_main
at /data001/abenson/Galacticus/Tools/glibc-2.12.1/csu/libc-start.c:226
#7  0x400728 in ???
==1544== 
==1544== Process terminating with default action of signal 11 (SIGSEGV)
==1544==at 0x564313E: raise (raise.c:67)
==1544==by 0x56431EF: ??? (in
/home/abenson/Galacticus/Tools/lib/libc-2.12.1.so)
==1544==by 0x4A0A6E7: memcpy (vg_replace_strmem.c:1019)
==1544==by 0x40167B: __copy_m_A.3590 (c.F90:22)
==1544==by 0x400F59: __m_MOD_nncp (c.F90:18)
==1544==by 0x401593: MAIN__ (c.F90:27)
==1544==by 0x4016C4: main (c.F90:23)
==1544== 
==1544== HEAP SUMMARY:
==1544== in use at exit: 3,964 bytes in 17 blocks
==1544==   total heap usage: 21 allocs, 4 frees, 12,104 bytes allocated
==1544== 
==1544== LEAK SUMMARY:
==1544==definitely lost: 0 bytes in 0 blocks
==1544==indirectly lost: 0 bytes in 0 blocks
==1544==  possibly lost: 0 bytes in 0 blocks
==1544==still reachable: 3,964 bytes in 17 blocks
==1544== suppressed

[Bug fortran/78293] New: SIGABRT with function result used as argument

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78293

Bug ID: 78293
   Summary: SIGABRT with function result used as argument
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following code dies with a SIGABRT at run time in gfortran 7.0.0 
(r241975), and also in gfortran 6.2.1. As far as I can see it's valid code, 
but I wanted to get a second opinion on that before opening a PR.

-Andrew

--
module m
  implicit none

  type t
 integer, allocatable, dimension(:) :: r
  end type t

contains

  function tt(a,b)
implicit none
type(t), allocatable, dimension(:) :: tt
type(t), intent(in), dimension(:) :: a,b
allocate(tt(2))
allocate(tt(1)%r(1))
allocate(tt(2)%r(1))
return
  end function tt

  function ts()
implicit none
type(t), allocatable, dimension(:) :: ts
allocate(ts(1))
allocate(ts(1)%r(1))
return
  end function ts

end module m

program p
  use m
  implicit none
  type(t), dimension(2) :: c
  c=tt(ts(),ts())
end program p


$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.2.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC) 

$ gfortran t.F90
$ a.out
*** Error in `a.out': free(): invalid pointer: 0x02189f50 ***
=== Backtrace: =
/lib64/libc.so.6(+0x7570b)[0x2aceab27c70b]
/lib64/libc.so.6(+0x7deaa)[0x2aceab284eaa]
/lib64/libc.so.6(cfree+0x4c)[0x2aceab28840c]
a.out[0x4016ab]
a.out[0x40171c]
/lib64/libc.so.6(__libc_start_main+0xf1)[0x2aceab227731]
a.out[0x4007b9]
=== Memory map: 
0040-00402000 r-xp  fd:03 9574876/
home/abenson/Galacticus/v0.9.4/a.out
00601000-00602000 r--p 1000 fd:03 9574876/
home/abenson/Galacticus/v0.9.4/a.out
00602000-00603000 rw-p 2000 fd:03 9574876/
home/abenson/Galacticus/v0.9.4/a.out
02187000-021a8000 rw-p  00:00 0  
[heap]
2aceaa55-2aceaa574000 r-xp  fd:01 400265 /usr/
lib64/ld-2.23.so
2aceaa574000-2aceaa576000 rw-p  00:00 0 
2aceaa5c-2aceaa5c4000 rw-p  00:00 0 
2aceaa773000-2aceaa774000 r--p 00023000 fd:01 400265 /usr/
lib64/ld-2.23.so
2aceaa774000-2aceaa775000 rw-p 00024000 fd:01 400265 /usr/
lib64/ld-2.23.so
2aceaa775000-2aceaa776000 rw-p  00:00 0 
2aceaa776000-2aceaa8a4000 r-xp  fd:01 409988 /usr/
lib64/libgfortran.so.3.0.0
2aceaa8a4000-2ace4000 ---p 0012e000 fd:01 409988 /usr/
lib64/libgfortran.so.3.0.0
2ace4000-2ace5000 r--p 0012e000 fd:01 409988 /usr/
lib64/libgfortran.so.3.0.0
2ace5000-2ace6000 rw-p 0012f000 fd:01 409988 /usr/
lib64/libgfortran.so.3.0.0
2ace6000-2ace7000 rw-p  00:00 0 
2ace7000-2aceaabaf000 r-xp  fd:01 468489 /usr/
lib64/libm-2.23.so
2aceaabaf000-2aceaadae000 ---p 00108000 fd:01 468489 /usr/
lib64/libm-2.23.so
2aceaadae000-2aceaadaf000 r--p 00107000 fd:01 468489 /usr/
lib64/libm-2.23.so
2aceaadaf000-2aceaadb rw-p 00108000 fd:01 468489 /usr/
lib64/libm-2.23.so
2aceaadb-2aceaadc6000 r-xp  fd:01 394309 /usr/
lib64/libgcc_s-6.2.1-20160916.so.1
2aceaadc6000-2aceaafc5000 ---p 00016000 fd:01 394309 /usr/
lib64/libgcc_s-6.2.1-20160916.so.1
2aceaafc5000-2aceaafc6000 r--p 00015000 fd:01 394309 /usr/
lib64/libgcc_s-6.2.1-20160916.so.1
2aceaafc6000-2aceaafc7000 rw-p 00016000 fd:01 394309 /usr/
lib64/libgcc_s-6.2.1-20160916.so.1
2aceaafc7000-2aceab006000 r-xp  fd:01 409963 /usr/
lib64/libquadmath.so.0.0.0
2aceab006000-2aceab205000 ---p 0003f000 fd:01 409963 /usr/
lib64/libquadmath.so.0.0.0
2aceab205000-2aceab206000 r--p 0003e000 fd:01 409963 /usr/
lib64/libquadmath.so.0.0.0

[Bug fortran/77584] New: Unclassifiable statement error with procedure pointer using template named "structure_"

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77584

Bug ID: 77584
   Summary: Unclassifiable statement error with procedure pointer
using template named "structure_"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

In gfortran 7.0.0 (r240119) the following causes an error on compilation:

module bug
  abstract interface
 double precision function structure_()
 end function structure_
  end interface
contains
  double precision function a()
procedure(structure_), pointer :: b
  end function a
end module bug

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 7.0.0 20160913 (experimental) (GCC) 

$ gfortran -c tmp.F90 -o tmp.o
tmp.F90:8:4:

 procedure(structure_), pointer :: b
1
Error: Unclassifiable statement at (1)


The problem seems to occur only if the interface name begins with "structure",
so my guess is that this part of the name if being interpreted as a STRUCTURE
statement.

[Bug fortran/58175] [OOP] Incorrect warning message on scalar finalizer

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175

--- Comment #6 from Andrew Benson abensonca at gmail dot com ---
This problem still occurs in gcc 6.0.0. In a code which makes extensive use of
finalizors it results in many thousands of erroneous warning messages during
compile, which have to be filtered out to find the real warnings. Is there any
way I can help get the proposed patch committed (e.g. maybe testing it to
ensure it introduces no regressions)?

[Bug middle-end/66633] [5/6 regression] ICE on valid verify_gimple failed with OpenMP

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66633

--- Comment #13 from Andrew Benson abensonca at gmail dot com ---
(In reply to Eric Botcazou from comment #12)
 Fixed everywhere.

Thanks for the fix! Unfortunately, while this fixes some instances, it still
results in an ICE with optimization at -O1 or higher. 

Specifically:

Original test case: compiles OK with -O0; same ICE as before with -O1 or higher

Test case from comment #1: compiles OK with any optimization level.

[Bug fortran/66366] ICE on invalid with non-allocatable CLASS variable [OOP]

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66366

--- Comment #3 from Andrew Benson abensonca at gmail dot com ---
Note the name conflict between:

  type :: spsf

and

type(h5) :: spsf

in the previous comment. Changing the name of either to make them distinct
removes the ICE.

[Bug fortran/66633] New: ICE on valid verify_gimple failed with OpenMP

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66633

Bug ID: 66633
   Summary: ICE on valid verify_gimple failed with OpenMP
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following causes an ICE in gfortran 6.0.0 (r224761):

module spls
  type :: spc
   contains
 procedure :: l = spcL
  end type spc

contains
  function spl()
class(spc), pointer :: spc_
!$omp parallel
write (0,*) igrt(fli)
!$omp end parallel
  contains
double precision function fli()
  fli=spc_%l()
end function fli
  end function spl
  double precision function spcL(s)
implicit none
class(spc), intent(inout) :: s
return
  end function spcL
end module spls


$ gfortran -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-trunk/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/opt/gcc-trunk
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 6.0.0 20150622 (experimental) (GCC) 


 gfortran -c tmp.F90 -o tmp.o -fopenmp
tmp.F90:11:0:

 write (0,*) igrt(fli)
^
Error: invalid argument to gimple call
 error .fli
D.3429 = __builtin_adjust_trampoline ( error .fli);
tmp.F90:11:0: internal compiler error: verify_gimple failed
0xbaf19d verify_gimple_in_seq(gimple_statement_base*)
../../gcc-trunk/gcc/tree-cfg.c:4790
0xab14b0 execute_function_todo
../../gcc-trunk/gcc/passes.c:1987
0xab1c63 execute_todo
../../gcc-trunk/gcc/passes.c:2042
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.

[Bug fortran/66366] ICE on invalid with non-allocatable CLASS variable [OOP]

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66366

--- Comment #2 from Andrew Benson abensonca at gmail dot com ---
This reduced test case produces an ICE with similar backtrace, although it
doesn't share the problem of having a non-allocatable/pointer CLASS variable
(as far as I can tell):

module sps
  type :: spsf
  end type spsf
  type :: h5
   contains
 procedure :: c = hC
  end type h5
contains
  subroutine frf()
type(h5) :: spsf
call spsf%c()
  end subroutine frf
  subroutine hC(s)
class(h5), intent(inout) :: s
  end subroutine hC
end module sps

[Bug fortran/66633] ICE on valid verify_gimple failed with OpenMP

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66633

--- Comment #1 from Andrew Benson abensonca at gmail dot com ---
Further reduced test case:

module spls
contains
  function spl()
!$omp parallel
write (0,*) igrt(fli)
!$omp end parallel
  contains
double precision function fli()
end function fli
  end function spl
end module spls

[Bug fortran/66549] New: ICE on valid in OMP parallel region

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66549

Bug ID: 66549
   Summary: ICE on valid in OMP parallel region
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following causes an ICE with gfortran 6.0 (r224494):

module smfa
  type :: sgc
   contains
 procedure :: sla = sa
  end type sgc
  class(sgc), pointer :: sg_
  double precision, allocatable, dimension(:) :: vni 
contains
  double precision function sa(self,i)
class(sgc), intent(in   ) :: self
  end function sa
  subroutine cvn(sg_,vn)
class(sgc), intent(inout) :: sg_
double precision, intent(  out), dimension(:) :: vn
integer :: i
do i=1,2
   vn(i)= sg_%sla(i)
end do
  end subroutine cvn
  subroutine clwf()
!$omp parallel
call cvn(sg_,vni)
!$omp end parallel
  end subroutine clwf
end module smfa

$ gfortran -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-trunk/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/opt/gcc-trunk
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 6.0.0 20150615 (experimental) (GCC)

$ gfortran -c test2.F90 -O2 -fopenmp
test2.F90:12:0:

   subroutine cvn(sg_,vn)
^
internal compiler error: in create_component_ref_by_pieces_1, at
tree-ssa-pre.c:2585
0xcfb5bf create_component_ref_by_pieces_1
../../gcc-trunk/gcc/tree-ssa-pre.c:2585
0xcfb02f create_component_ref_by_pieces_1
../../gcc-trunk/gcc/tree-ssa-pre.c:2538
0xcfacb0 create_component_ref_by_pieces_1
../../gcc-trunk/gcc/tree-ssa-pre.c:2594
0xcfa40e create_component_ref_by_pieces
../../gcc-trunk/gcc/tree-ssa-pre.c:2735
0xcfa40e create_expression_by_pieces
../../gcc-trunk/gcc/tree-ssa-pre.c:2826
0xcfb875 insert_into_preds_of_block
../../gcc-trunk/gcc/tree-ssa-pre.c:3025
0xcff1de do_regular_insertion
../../gcc-trunk/gcc/tree-ssa-pre.c:3353
0xcff1de insert_aux
../../gcc-trunk/gcc/tree-ssa-pre.c:3563
0xcfe807 insert_aux
../../gcc-trunk/gcc/tree-ssa-pre.c:3573
0xcfe807 insert_aux
../../gcc-trunk/gcc/tree-ssa-pre.c:3573
0xcfe807 insert_aux
../../gcc-trunk/gcc/tree-ssa-pre.c:3573
0xd0126d insert
../../gcc-trunk/gcc/tree-ssa-pre.c:3596
0xd0126d execute
../../gcc-trunk/gcc/tree-ssa-pre.c:4864
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.

If compiled with -O1 instead of -O2 a different ICE occurs:

$ gfortran -c test2.F90 -O1 -fopenmp
test2.F90:16:0:

 do i=1,2
^
internal compiler error: in make_decl_rtl, at varasm.c:1320
0xe3f385 make_decl_rtl(tree_node*)
../../gcc-trunk/gcc/varasm.c:1316
0x854c93 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-trunk/gcc/expr.c:9489
0x861bbe expand_expr
../../gcc-trunk/gcc/expr.h:255
0x861bbe expand_assignment(tree_node*, tree_node*, bool)
../../gcc-trunk/gcc/expr.c:5130
0x755a95 expand_gimple_stmt_1
../../gcc-trunk/gcc/cfgexpand.c:3318
0x755a95 expand_gimple_stmt
../../gcc-trunk/gcc/cfgexpand.c:3414
0x757ebc expand_gimple_basic_block
../../gcc-trunk/gcc/cfgexpand.c:5426
0x75e846 execute
../../gcc-trunk/gcc/cfgexpand.c:6045
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.

If compiled without -fopenmp compilation is successful.

[Bug fortran/66366] New: ICE on invalid with non-allocatable CLASS variable [OOP]

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66366

Bug ID: 66366
   Summary: ICE on invalid with non-allocatable CLASS variable
[OOP]
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following invalid code causes an ICE with gfortran 6.0.0 223992:

module bug

  type :: t1d
   contains
 procedure :: interpolate = interp
  end type t1d

  type :: tff
 class(t1d) :: transfer
  end type tff

contains

  double precision function interp(self)
implicit none
class(t1d), intent(inout) :: self
return
  end function interp

  double precision function fvb(self)
implicit none
class(tff), intent(inout) :: self
fvb=self%transfer%interpolate()
return
  end function fvb

end module bug

$ gfortran -v  
  Using built-in specs.
COLLECT_GCC=/opt/gcc-trunk/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/opt/gcc-trunk
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 6.0.0 20150517 (experimental) (GCC) 


 gfortran -c bug.F90 -o bug.o
bug.F90:9:27:

  class(t1d) :: transfer
1
Error: Component ‘transfer’ with CLASS at (1) must be allocatable or pointer
f951: internal compiler error: in check_typebound_baseobject, at
fortran/resolve.c:5521
0x637465 check_typebound_baseobject
../../gcc-trunk/gcc/fortran/resolve.c:5521
0x63791e resolve_compcall
../../gcc-trunk/gcc/fortran/resolve.c:5812
0x63404e resolve_typebound_function
../../gcc-trunk/gcc/fortran/resolve.c:5954
0x63404e gfc_resolve_expr(gfc_expr*)
../../gcc-trunk/gcc/fortran/resolve.c:6265
0x63a8b6 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:10095
0x63d2d2 resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:15055
0x63d1d7 resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:15040
0x63d3b2 gfc_resolve(gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:15083
0x628cb6 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:5477
0x669445 gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:228
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.


The code is invalid as the CLASS variable in tff is neither allocatable nor a
pointer. The call to the interpolate function of the t1d class seems to be
necessary to trigger the ICE.

[Bug fortran/65889] New: ICE on invalid(?) with sizeof polymorphic variable [OOP]

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65889

Bug ID: 65889
   Summary: ICE on invalid(?) with sizeof polymorphic variable
[OOP]
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

The following testcase causes an ICE with gfortran 6.0 (r222432):

module m
  type n
  end type n
contains
  subroutine g(ns)
class(n), intent(out), allocatable, dimension(:) :: ns
write (0,*) sizeof(ns)
  end subroutine g
end module m

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/nfs/17/cond0061/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--prefix=/nfs/17/cond0061/Galacticus/Tools --enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
gcc version 6.0.0 20150424 (experimental) (GCC)

$ gfortran -c small.f90 -o small.o  
small.f90:7:0:

 write (0,*) sizeof(ns)
 1
internal compiler error: tree check: expected tree that contains ‘decl common’
structure, have ‘indirect_ref’ in gfc_conv_intrinsic_sizeof, at
fortran/trans-intrinsic.c:5928
0xdd8994 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc-trunk/gcc/tree.c:9471
0x706628 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc-trunk/gcc/tree.h:2960
0x706628 gfc_conv_intrinsic_sizeof
../../gcc-trunk/gcc/fortran/trans-intrinsic.c:5928
0x70e24f gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-intrinsic.c:8185
0x6ece32 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.c:7361
0x6f3685 gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.c:7496
0x7150c1 gfc_trans_transfer(gfc_code*)
../../gcc-trunk/gcc/fortran/trans-io.c:2394
0x6b18d7 trans_code
../../gcc-trunk/gcc/fortran/trans.c:1885
0x7121b0 build_dt
../../gcc-trunk/gcc/fortran/trans-io.c:1921
0x6b18f7 trans_code
../../gcc-trunk/gcc/fortran/trans.c:1857
0x6de1df gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.c:5896
0x6b6149 gfc_generate_module_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans.c:2053
0x66e3ad translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.c:5328
0x66e3ad gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:5538
0x6ae745 gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:228
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.

It's not clear to me if this is invalid code - see the discussion for PR57305
on how SIZEOF() should work on variables without a declared type. I checked
that the testcase for PR57305 still compiles successfully.

Wrapping the call to SIZEOF() inside a SELECT TYPE block removes the ICE. 

Replacing SIZEOF() with STORAGE_SIZE() (as suggested in PR57305) results in a
slightly different backtrace:

$ gfortran -c small.f90 -o small.o
small.f90:7:0:

 write (0,*) storage_size(ns)
 1
internal compiler error: Segmentation fault
0xb7572f crash_signal
../../gcc-trunk/gcc/toplev.c:383
0x70689e gfc_conv_intrinsic_storage_size
../../gcc-trunk/gcc/fortran/trans-intrinsic.c:6067
0x70e8b9 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-intrinsic.c:8189
0x6ece32 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.c:7361
0x6f3685 gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.c:7496
0x7150c1 gfc_trans_transfer(gfc_code*)
../../gcc-trunk/gcc/fortran/trans-io.c:2394
0x6b18d7 trans_code
../../gcc-trunk/gcc/fortran/trans.c:1885
0x7121b0 build_dt
../../gcc-trunk/gcc/fortran/trans-io.c:1921
0x6b18f7 trans_code
../../gcc-trunk/gcc/fortran/trans.c:1857
0x6de1df gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.c:5896
0x6b6149 gfc_generate_module_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans.c:2053
0x66e3ad translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.c:5328
0x66e3ad gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:5538
0x6ae745 gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:228
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.

[Bug fortran/61824] New: ICE using dble() and -march=native

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61824

Bug ID: 61824
   Summary: ICE using dble() and -march=native
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

The following causes an ICE with the latest gfortran if I compile with
-march=native:

module hs
contains
  subroutine extend()
implicit none
integer :: a
double precision :: t
t=dble(a)
  end subroutine extend
end module hs

$ gfortran -v
Usando especificaciones internas.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Objetivo: x86_64-unknown-linux-gnu
Configurado con: ../trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c++,c,fortran --disable-multilib
Modelo de hilos: posix
gcc versión 4.10.0 20140716 (experimental) (GCC) 

$ gfortran -c tmp3.F90 -o tmp3.o -march=native 
tmp3.F90: En la función ‘extend’:
tmp3.F90:11:0: error interno del compilador: en lra_update_insn_recog_data, en
lra.c:1219
   end subroutine extend
 ^
0x93323b lra_update_insn_recog_data(rtx_def*)
../../trunk/gcc/lra.c:1218
0x949b54 eliminate_regs_in_insn
../../trunk/gcc/lra-eliminations.c:1077
0x949b54 process_insn_for_elimination
../../trunk/gcc/lra-eliminations.c:1344
0x949b54 lra_eliminate(bool, bool)
../../trunk/gcc/lra-eliminations.c:1408
0x934eca lra(_IO_FILE*)
../../trunk/gcc/lra.c:2272
0x8f4806 do_reload
../../trunk/gcc/ira.c:5325
0x8f4806 execute
../../trunk/gcc/ira.c:5484
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.

For reference:

$ uname -a
Linux taurus 3.2.0-57-generic #87-Ubuntu SMP Tue Nov 12 21:35:10 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux

[Bug fortran/61824] ICE using dble() and -march=native

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61824

--- Comment #2 from Andrew Benson abensonca at gmail dot com ---
No problem. Here's the output:

$ gfortran -c tmp3.F90 -o tmp3.o -march=native -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 
COLLECT_GCC_OPTIONS='-c' '-o' 'tmp3.o' '-march=native' '-v'
 /usr/lib/gcc/x86_64-linux-gnu/4.6/f951 tmp3.F90 -cpp=/tmp/ccJLj4Nw.f90 -quiet
-v -imultilib . -imultiarch x86_64-linux-gnu tmp3.F90 -march=amdfam10 -mcx16
-msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mabm -mno-lwp -mno-fma
-mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -mno-sse4.2 -mno-sse4.1 --param
l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512
-mtune=amdfam10 -quiet -dumpbase tmp3.F90 -auxbase-strip tmp3.o -version
-fintrinsic-modules-path /usr/lib/gcc/x86_64-linux-gnu/4.6/finclude -o
/tmp/ccBjcPAR.s
GNU Fortran (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (x86_64-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version
3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../x86_64-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/4.6/finclude 
 /opt/intel/composer_xe_2013_sp1.1.106/mkl/include  
 /opt/intel/composer_xe_2013_sp1.1.106/tbb/include  
 /usr/lib/gcc/x86_64-linux-gnu/4.6/include  
 /usr/local/include 
 /usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed
 /usr/include/x86_64-linux-gnu  
 /usr/include   
End of search list. 
GNU Fortran (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (x86_64-linux-gnu) 
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version
3.1.0-p3, MPC version 0.9   
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072  
COLLECT_GCC_OPTIONS='-c' '-o' 'tmp3.o' '-march=native' '-v' 
 as --64 -o tmp3.o /tmp/ccBjcPAR.s  
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/
 
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/opt/intel/composer_xe_2013_sp1.1.106/compiler/lib/intel64/:/opt/intel/composer_xe_2013_sp1.1.106/ipp/../compiler/lib/intel64/:/opt/intel/composer_xe_2013_sp1.1.106/ipp/lib/intel64/:/opt/intel/composer_xe_2013_sp1.1.106/compiler/lib/intel64/:/opt/intel/composer_xe_2013_sp1.1.106/mkl/lib/intel64/:/opt/intel/composer_xe_2013_sp1.1.106/tbb/lib/intel64/gcc4.4/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../:/lib/:/usr/lib/
 
COLLECT_GCC_OPTIONS='-c' '-o' 'tmp3.o' '-march=native' '-v'

[Bug fortran/61824] ICE using dble() and -march=native

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61824

--- Comment #4 from Andrew Benson abensonca at gmail dot com ---
My mistake - forgot to switch back to the latest gfortran. Here's the correct
output:

$ gfortran -c tmp3.F90 -o tmp3.o -march=native -v
Usando especificaciones internas.
COLLECT_GCC=gfortran
Objetivo: x86_64-unknown-linux-gnu
Configurado con: ../trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c++,c,fortran --disable-multilib
Modelo de hilos: posix
gcc versión 4.10.0 20140716 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-o' 'tmp3.o' '-march=native' '-v'

/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/f951
tmp3.F90 -cpp=/tmp/ccHRIw0p.f90 -quiet -v -imultiarch x86_64-linux-gnu tmp3.F90
-march=amdfam10 -mmmx -m3dnow -msse -msse2 -msse3 -mno-ssse3 -msse4a -mcx16
-msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mpopcnt -mabm -mno-lwp
-mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2
-mno-sse4.2 -mno-sse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c
-mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt
-mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1
-mno-clflushopt -mno-xsavec -mno-xsaves --param l1-cache-size=64 --param
l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amdfam10 -quiet
-dumpbase tmp3.F90 -auxbase-strip tmp3.o -version -fintrinsic-modules-path
/home/abenson/Galacticus/Tools/lib/gcc/x86_64-unknown-linux-gnu/4.10.0/finclude
-o /tmp/ccWnK5zD.s
GNU Fortran (GCC) versión 4.10.0 20140716 (experimental)
(x86_64-unknown-linux-gnu)  
compilado por GNU C versión 4.10.0 20140716 (experimental), GMP versión
4.3.2, MPFR versión 2.4.2, MPC versión 0.8.1 
GGC heurísticas: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
se descarta el directorio inexistente /usr/local/include/x86_64-linux-gnu 
se descarta el directorio inexistente
/home/abenson/Galacticus/Tools/lib/gcc/x86_64-unknown-linux-gnu/4.10.0/../../../../x86_64-unknown-linux-gnu/include
la búsqueda de #include ... inicia aquí:  
la búsqueda de #include ... inicia aquí:  

/home/abenson/Galacticus/Tools/lib/gcc/x86_64-unknown-linux-gnu/4.10.0/finclude 
 /opt/intel/composer_xe_2013_sp1.1.106/mkl/include  
 /opt/intel/composer_xe_2013_sp1.1.106/tbb/include  
 /home/abenson/Galacticus/Tools/lib/gcc/x86_64-unknown-linux-gnu/4.10.0/include 
 /usr/local/include 
 /home/abenson/Galacticus/Tools/include 

/home/abenson/Galacticus/Tools/lib/gcc/x86_64-unknown-linux-gnu/4.10.0/include-fixed
 
 /usr/include/x86_64-linux-gnu  
 /usr/include   
Fin de la lista de búsqueda.
GNU Fortran (GCC) versión 4.10.0 20140716 (experimental)
(x86_64-unknown-linux-gnu)  
compilado por GNU C versión 4.10.0 20140716 (experimental), GMP versión
4.3.2, MPFR versión 2.4.2, MPC versión 0.8.1 
GGC heurísticas: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
tmp3.F90: En la función ‘extend’:
tmp3.F90:8:0: error interno del compilador: en lra_update_insn_recog_data, en
lra.c:1219
   end subroutine extend
 ^
0x93323b lra_update_insn_recog_data(rtx_def*)
../../trunk/gcc/lra.c:1218
0x949b54 eliminate_regs_in_insn
../../trunk/gcc/lra-eliminations.c:1077
0x949b54 process_insn_for_elimination
../../trunk/gcc/lra-eliminations.c:1344
0x949b54 lra_eliminate(bool, bool)
../../trunk/gcc/lra-eliminations.c:1408
0x934eca lra(_IO_FILE*)
../../trunk/gcc/lra.c:2272
0x8f4806 do_reload
../../trunk/gcc/ira.c:5325
0x8f4806 execute
../../trunk/gcc/ira.c:5484
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.

[Bug fortran/59765] New: ICE on valid with allocatable component and type extension

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59765

Bug ID: 59765
   Summary: ICE on valid with allocatable component and type
extension
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

The following causes an ICE with gfortran 4.9.0 r206484, but compiles
successfully with r205975:

module mtds
  type umd
 integer, dimension(:), allocatable :: c
  end type umd
  type mtd
 type(umd), dimension(1) :: u
  end type mtd
contains
  subroutine add(s)
class(mtd), intent(inout) :: s
  end subroutine add
end module mtds


$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/nfs/04/osu7985/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../trunk/configure --prefix=/nfs/04/osu7985/Galacticus/Tools
--enable-languages=c++,c,fortran --disable-multilib
Thread model: posix
gcc version 4.9.0 20140109 (experimental) (GCC) 

$ gfortran -c tmp1.F90 -o tmp1.o 
tmp1.F90: In function ‘__final_mtds_Mtd’:
tmp1.F90:10:0: internal compiler error: in gfc_conv_descriptor_data_get, at
fortran/trans-array.c:145
 class(mtd), intent(inout) :: s
 ^
0x65cd8d gfc_conv_descriptor_data_get(tree_node*)
../../trunk/gcc/fortran/trans-array.c:145
0x66454f gfc_array_deallocate(tree_node*, tree_node*, tree_node*, tree_node*,
tree_node*, gfc_expr*)
../../trunk/gcc/fortran/trans-array.c:5335
0x6bedfd gfc_trans_deallocate(gfc_code*)
../../trunk/gcc/fortran/trans-stmt.c:5421
0x658c27 trans_code
../../trunk/gcc/fortran/trans.c:1782
0x6bc344 gfc_trans_simple_do
../../trunk/gcc/fortran/trans-stmt.c:1427
0x6bc344 gfc_trans_do(gfc_code*, tree_node*)
../../trunk/gcc/fortran/trans-stmt.c:1590
0x658cea trans_code
../../trunk/gcc/fortran/trans.c:1732
0x6827be gfc_generate_function_code(gfc_namespace*)
../../trunk/gcc/fortran/trans-decl.c:5605
0x65a6c1 gfc_generate_module_code(gfc_namespace*)
../../trunk/gcc/fortran/trans.c:1956
0x61689d translate_all_program_units
../../trunk/gcc/fortran/parse.c:4523
0x61689d gfc_parse_file()
../../trunk/gcc/fortran/parse.c:4733
0x654815 gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:188
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.


The ICE goes away if I do any of the following:

* Change class(mtd) to type(mtd)

* Make the u component of mtd allocatable, or make it a scalar

* Make the c component of umd non-allocatable

[Bug fortran/54221] [4.8/4.9 Regression] Explicit private access specifier signals unexpected defined but not used [-Wunused-function] warning

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54221

--- Comment #11 from Andrew Benson abensonca at gmail dot com ---
(In reply to janus from comment #10)
 (In reply to Dominique d'Humieres from comment #9)
  I don't see the point to keep this PR open in addition of pr54224 (only one
  issue left AFAIU). Also I don't think this is any longer a regression.
 
 I agree that this PR can probably be closed.
 
 Except: What happened to the problem of comment 5, i.e. the linking problems
 with the FoX library? This is apparently the reason for the 'regression'
 tag. I see no follow-ups to this either here or in the mailing list thread.
 Has it been fixed? Or was it just false alarm?
 
 Andrew, can you give as a comment about what happened to the linking problem?

This was fixed in PR54884 if I remember correctly.

[Bug fortran/59502] New: ICE on invalid on pointer assignment to non-pointer CLASS

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59502

Bug ID: 59502
   Summary: ICE on invalid on pointer assignment to non-pointer
CLASS
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

The following causes an ICE with gfortran 4.9 (r205975):

module cp

  type :: d
  end type d

  type, public :: p
 class(d) :: pd
  end type p

contains

  function pc(pd)
implicit none
type(p) :: pc
class(d), intent(in), target :: pd
pc%pd = pd
return
  end function pc

end module cp

$ gfortran -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-trunk/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/opt/gcc-trunk
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.9.0 20131213 (experimental) (GCC) 

$ gfortran test.F90 -o test.o -c
f951: internal compiler error: Segmentation fault
0x9f251f crash_signal
../../gcc-trunk/gcc/toplev.c:336
0x5ae283 gfc_match_varspec(gfc_expr*, int, bool, bool)
../../gcc-trunk/gcc/fortran/primary.c:2044
0x5ae70d match_variable
../../gcc-trunk/gcc/fortran/primary.c:3304
0x58fe19 gfc_match(char const*, ...)
../../gcc-trunk/gcc/fortran/match.c:1116
0x590fdc gfc_match_assignment()
../../gcc-trunk/gcc/fortran/match.c:1293
0x5a5239 match_word
../../gcc-trunk/gcc/fortran/parse.c:65
0x5a61d1 match_word
../../gcc-trunk/gcc/fortran/parse.c:327
0x5a61d1 decode_statement
../../gcc-trunk/gcc/fortran/parse.c:327
0x5a7741 next_free
../../gcc-trunk/gcc/fortran/parse.c:784
0x5a7741 next_statement
../../gcc-trunk/gcc/fortran/parse.c:977
0x5a8103 parse_spec
../../gcc-trunk/gcc/fortran/parse.c:2768
0x5a9f78 parse_progunit
../../gcc-trunk/gcc/fortran/parse.c:4148
0x5aa2fc parse_contained
../../gcc-trunk/gcc/fortran/parse.c:4087
0x5ab50d parse_module
../../gcc-trunk/gcc/fortran/parse.c:4350
0x5ab50d gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:4652
0x5e8ff5 gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:188
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.

The code is invalid as pd should have either allocatable or pointer
attributes. If the pointer assignment pc%pd = pd is removed then compilation
correctly fails with:

$ gfortran test.F90 -o test.o -c
test.F90:7.19:

 class(d) :: pd
   1
Error: Component 'pd' with CLASS at (1) must be allocatable or pointer

[Bug fortran/58880] New: ICE on valid with FINAL function and type extension

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58880

Bug ID: 58880
   Summary: ICE on valid with FINAL function and type extension
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

The following causes an ICE using gfortran 4.9.0 (r204039):

module gn
  type sl
 integer, allocatable, dimension(:) :: lv
   contains
 final :: sld
  end type sl
  type :: nde
 type(sl) :: r
  end type nde
contains
  subroutine ndm(s)
type(nde), intent(inout) :: s
type(nde):: i
i=s
  end subroutine ndm
  subroutine sld(s)
implicit none
type(sl), intent(inout) :: s
return
  end subroutine sld
end module gn

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
--with-gmp=/home/abenson/Galacticus/Tools
Thread model: posix
gcc version 4.9.0 20131024 (experimental) (GCC) 

$ gfortran -c tmp1.F90 -o tmp1.o
tmp1.F90: In function 'ndm':
tmp1.F90:14:0: internal compiler error: in fold_convert_loc, at
fold-const.c:1970
 i=s
 ^
0x78774d fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc-trunk/gcc/fold-const.c:1969
0x59d0c8 gfc_conv_descriptor_data_set(stmtblock_t*, tree_node*, tree_node*)
../../gcc-trunk/gcc/fortran/trans-array.c:178
0x5c4be8 gfc_conv_scalar_to_descriptor(gfc_se*, tree_node*, symbol_attribute)
../../gcc-trunk/gcc/fortran/trans-expr.c:72
0x599421 gfc_add_comp_finalizer_call(stmtblock_t*, tree_node*, gfc_component*,
bool)
../../gcc-trunk/gcc/fortran/trans.c:1011
0x5a7689 structure_alloc_comps
../../gcc-trunk/gcc/fortran/trans-array.c:7609
0x5c863b gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool,
bool)
../../gcc-trunk/gcc/fortran/trans-expr.c:6946
0x5d35a2 gfc_trans_assignment_1
../../gcc-trunk/gcc/fortran/trans-expr.c:7990
0x598f11 trans_code
../../gcc-trunk/gcc/fortran/trans.c:1622
0x5c1b5e gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.c:5528
0x59a6e1 gfc_generate_module_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans.c:1955
0x5583df translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.c:4496
0x5583df gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:4706
0x594955 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.

Removing any of:

 integer, allocatable, dimension(:) :: lv
 final :: sld
 i=s

results in a successful compile.

[Bug fortran/58470] New: ICE on invalid with FINAL function and type extension

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58470

Bug ID: 58470
   Summary: ICE on invalid with FINAL function and type extension
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

The following causes an ICE with gfortran 4.9.0 (r202667):

module cf
  type  :: cfml
   contains
 final :: mld
  end type cfml
  type, extends(cfml) :: cfmde
  end type cfmde
contains
  subroutine mld(s)
class(cfml), intent(inout) :: s
  end subroutine mld
end module cf

$ gfortran -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-trunk/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/opt/gcc-trunk
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.9.0 20130917 (experimental) (GCC) 

$ gfortran -c bug.F90 -o bug.o
bug.F90: In function ‘__final_cf_Cfml’:
bug.F90:12:0: internal compiler error: Segmentation fault
 end module cf
 ^
0x99112f crash_signal
../../gcc-trunk/gcc/toplev.c:335
0x5f8e0c gfc_conv_derived_to_class(gfc_se*, gfc_expr*, gfc_typespec,
tree_node*, bool, bool)
../../gcc-trunk/gcc/fortran/trans-expr.c:424
0x5f1140 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vectree_node*, va_gc, vl_embed*)
../../gcc-trunk/gcc/fortran/trans-expr.c:4028
0x61cd04 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../gcc-trunk/gcc/fortran/trans-stmt.c:406
0x5bf010 trans_code
../../gcc-trunk/gcc/fortran/trans.c:1700
0x621a40 gfc_trans_integer_select
../../gcc-trunk/gcc/fortran/trans-stmt.c:1990
0x621a40 gfc_trans_select(gfc_code*)
../../gcc-trunk/gcc/fortran/trans-stmt.c:2484
0x5bed77 trans_code
../../gcc-trunk/gcc/fortran/trans.c:1743
0x5e7dae gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.c:5528
0x5c0781 gfc_generate_module_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans.c:1955
0x57eee7 translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.c:4496
0x57eee7 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:4706
0x5baab5 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.

The code is invalid because the finalization subroutine defines its argument as
CLASS rather than TYPE. Removing the cfmde type (or removing the ,
extends(cfml)) results in the correct error message:

$ gfortran -c bug.F90 -o bug.o
bug.F90:9.18:

  subroutine mld(s)
  1
Error: Argument of FINAL procedure at (1) must be of type 'cfml'

[Bug fortran/58471] New: ICE on invalid with missing type constructor and -Wall

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58471

Bug ID: 58471
   Summary: ICE on invalid with missing type constructor and -Wall
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

The following causes an ICE with gfortran 4.9.0 (r202667) when compiled with
-Wall:

module cf  
  type :: cfmde
  end type cfmde
  interface cfmde
 module procedure mdedc
  end interface cfmde
contains
  subroutine cfi()
implicit none
type(cfmde), pointer :: cfd
cfd=cfmde()
return
  end subroutine cfi
end module cf

$ gfortran -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-trunk/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/opt/gcc-trunk
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.9.0 20130917 (experimental) (GCC) 

$ gfortran -c bug1.F90 -o bug1.o -Wall
bug1.F90:5.22:

 module procedure mdedc
  1
Error: Procedure 'mdedc' in generic interface 'cfmde' at (1) is neither
function nor subroutine
f951: internal compiler error: Segmentation fault
0x99112f crash_signal
../../gcc-trunk/gcc/toplev.c:335
0x582892 gfc_expr_attr(gfc_expr*)
../../gcc-trunk/gcc/fortran/primary.c:2259
0x53a40c gfc_check_assign(gfc_expr*, gfc_expr*, int)
../../gcc-trunk/gcc/fortran/expr.c:3160
0x58f872 resolve_ordinary_assign
../../gcc-trunk/gcc/fortran/resolve.c:9200
0x58f872 resolve_code
../../gcc-trunk/gcc/fortran/resolve.c:9810
0x591b0e resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:14507
0x591a17 resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:14493
0x591bf2 gfc_resolve
../../gcc-trunk/gcc/fortran/resolve.c:14535
0x57efdf gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:4645
0x5baab5 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.

without -Wall the correct error message is generated:
$ gfortran -c bug1.F90 -o bug1.o 
bug1.F90:5.22:

 module procedure mdedc
  1
Error: Procedure 'mdedc' in generic interface 'cfmde' at (1) is neither
function nor subroutine
bug1.F90:11.8:

cfd=cfmde()
1
Error: Can't convert REAL(4) to TYPE(cfmde) at (1)

Adding a suitable mdedc procedure results in successful compilation.

[Bug fortran/58356] ICE with finalization and type extension

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58356

--- Comment #5 from Andrew Benson abensonca at gmail dot com ---
Thanks for fixing!

[Bug fortran/58355] New: ICE with TYPE, EXTENDS before parent TYPE defined

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58355

Bug ID: 58355
   Summary: ICE with TYPE, EXTENDS before parent TYPE defined
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

With gfortran 4.9.0 the following causes an ICE:

module ct
  public :: cfc, cfl, cfde
  type :: cfc
  end type cfc
  type, extends(cfl) :: cfde
  end type cfde
  type, extends(cfc) :: cfl
  end type cfl
end module ct


$ gfortran -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-trunk/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/opt/gcc-trunk
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.9.0 20130808 (experimental) (GCC) 

$ gfortran -c bug.F90 -o bug.o
f951: internal compiler error: Segmentation fault
0x97d66f crash_signal
../../gcc-trunk/gcc/toplev.c:335
0x52dec1 check_extended_derived_type
../../gcc-trunk/gcc/fortran/decl.c:7412
0x52dec1 gfc_match_derived_decl()
../../gcc-trunk/gcc/fortran/decl.c:7541
0x5770d9 match_word
../../gcc-trunk/gcc/fortran/parse.c:65
0x578561 decode_statement
../../gcc-trunk/gcc/fortran/parse.c:502
0x5796a4 next_free
../../gcc-trunk/gcc/fortran/parse.c:784
0x5796a4 next_statement
../../gcc-trunk/gcc/fortran/parse.c:977
0x579f34 parse_spec
../../gcc-trunk/gcc/fortran/parse.c:2741
0x57ccf8 parse_module
../../gcc-trunk/gcc/fortran/parse.c:4313
0x57ccf8 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:4625
0x5b8ce5 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.

The PUBLIC statement is required for the ICE to happen. switching the order of
the definitions of the cfde and cfl types results in a success compile.

I can't currently test this with the most recent revision of gfortran due to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58350

[Bug fortran/58356] New: ICE with finalization and type extension

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58356

Bug ID: 58356
   Summary: ICE with finalization and type extension
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

The following causes an ICE in gfortran 4.9.0:

module ct
  type :: cfl
   contains
 final :: cfld
  end type cfl
  type, extends(cfl) :: cfde
   contains
  end type cfde
contains
  subroutine cfld(self)
implicit none
type(cfl), intent(inout) :: self
return
  end subroutine cfld
end module ct

$ gfortran -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-trunk/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/opt/gcc-trunk
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.9.0 20130808 (experimental) (GCC) 

$ gfortran -c bug.F90 -o bug.o
f951: internal compiler error: Segmentation fault
0x97d66f crash_signal
../../gcc-trunk/gcc/toplev.c:335
0x51dd10 generate_finalization_wrapper
../../gcc-trunk/gcc/fortran/class.c:1950
0x51dd10 gfc_find_derived_vtab(gfc_symbol*)
../../gcc-trunk/gcc/fortran/class.c:2398
0x51fc87 gfc_is_finalizable(gfc_symbol*, gfc_expr**)
../../gcc-trunk/gcc/fortran/class.c:2464
0x5954a7 resolve_fl_derived0
../../gcc-trunk/gcc/fortran/resolve.c:12368
0x594fcf resolve_fl_derived0
../../gcc-trunk/gcc/fortran/resolve.c:11992
0x594fcf resolve_fl_derived0
../../gcc-trunk/gcc/fortran/resolve.c:11980
0x59683f resolve_fl_derived0
../../gcc-trunk/gcc/fortran/resolve.c:12402
0x59683f resolve_fl_derived
../../gcc-trunk/gcc/fortran/resolve.c:12425
0x591559 resolve_symbol
../../gcc-trunk/gcc/fortran/resolve.c:12695
0x5a8133 do_traverse_symtree
../../gcc-trunk/gcc/fortran/symbol.c:3571
0x594582 resolve_types
../../gcc-trunk/gcc/fortran/resolve.c:14400
0x590430 gfc_resolve
../../gcc-trunk/gcc/fortran/resolve.c:14497
0x57d0af gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:4645
0x5b8ce5 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.

I can't currently test this with the most recent revision of gfortran due to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58350

[Bug fortran/58171] [F03] Incorrect error message on invalid code when using type constructor

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58171

--- Comment #2 from Andrew Benson abensonca at gmail dot com ---
I see your point about it not being obvious what was intended in situations
like this. Something such as:

Error: There is no specific function for the generic 'cps' at (1)

would definitely be more helpful if it were possible to generate.

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58182

--- Comment #4 from Andrew Benson abensonca at gmail dot com ---
Btw, does it make sense to have a dummy procedure with 'BIND(C)' at all? I
have the feeling that this might be something which should be forbidden in
general ... (?)

Possibly not... This was reduced from the FGSL library source, so not my
own code. I could check in the original if the BIND(C) is actually needed.

[Bug fortran/58177] Incorrect warning message about unused PRIVATE module variable

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58177

--- Comment #2 from Andrew Benson abensonca at gmail dot com ---
You're absolutely correct -  my mistake!

[Bug fortran/58182] New: ICE with global binding name used as a FUNCTION

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58182

Bug ID: 58182
   Summary: ICE with global binding name used as a FUNCTION
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

The following leads to an ICE with gfortran 4.9.0 (r201758):

$ cat mod1.F90
module fg
  use, intrinsic :: iso_c_binding
contains
  function fffi(f)
interface
   function f() bind(c)
   end function f
end interface
  end function fffi
end module fg

$ cat mod2.F90
module f
  use fg
end module f

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
--with-gmp=/home/abenson/Galacticus/Tools
Thread model: posix
gcc version 4.9.0 20130815 (experimental) (GCC) 

$ gfortran -c mod1.F90 -o mod1.o
$ gfortran -c mod2.F90 -o mod2.o
f951: internal compiler error: Segmentation fault
0x95dcbf crash_signal
../../gcc-trunk/gcc/toplev.c:335
0x556f38 gfc_verify_binding_labels
../../gcc-trunk/gcc/fortran/resolve.c:10117
0x579e23 do_traverse_symtree
../../gcc-trunk/gcc/fortran/symbol.c:3571
0x565df3 resolve_types
../../gcc-trunk/gcc/fortran/resolve.c:14422
0x561a80 gfc_resolve
../../gcc-trunk/gcc/fortran/resolve.c:14489
0x563774 gfc_resolve
../../gcc-trunk/gcc/fortran/resolve.c:14482
0x563774 resolve_symbol
../../gcc-trunk/gcc/fortran/resolve.c:13257
0x579e23 do_traverse_symtree
../../gcc-trunk/gcc/fortran/symbol.c:3571
0x565bd2 resolve_types
../../gcc-trunk/gcc/fortran/resolve.c:14392
0x561a80 gfc_resolve
../../gcc-trunk/gcc/fortran/resolve.c:14489
0x54e6ef gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:4645
0x58a9f5 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.

The BIND(C) seems to be necessary for the ICE to happen.

Also, if I place both modules in the same file the ICE does not happen and a
suitable error message is reported:

$ cat mod1.F90 mod2.F90  mod12.F90
$ gfortran -c mod12.F90 -o mod12.o
mod12.F90:11.8:

module f
1
mod12.F90:6.7:

   function f() bind(c)
   2
Error: Global binding name 'f' at (1) is already being used as a FUNCTION at
(2)

[Bug fortran/58175] New: Incorrect warning message on scalar finalizor

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175

Bug ID: 58175
   Summary: Incorrect warning message on scalar finalizor
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

With gfortran 4.9.0 (r201776) the following causes an incorrect warning message
to be issued:

module ct
  type :: a
   contains
 final :: aD
  end type a
contains
  subroutine aD(self)
type(a), intent(inout) :: self
  end subroutine aD
end module ct
program test
  use ct
end program test

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
--with-gmp=/home/abenson/Galacticus/Tools
Thread model: posix
gcc version 4.9.0 20130815 (experimental) (GCC) 

$ gfortran -c bug1.F90 -o bug1.o -Wall
bug1.F90:12.6:

  use ct
  1
Warning: Only array FINAL procedures declared for derived type 'a' defined at
(1), suggest also scalar one
bug1.F90:7.20:

  subroutine aD(self)
1
Warning: Unused dummy argument 'self' at (1)

Only a scalar finalizor is present, but the warning suggests that an array but
no scalar finalizor is present.

The warning is only issued if the ct module is USEd.

Adding an array finalizor or making the scalar finalizor ELEMENTAL does not
change the warning message.

[Bug fortran/58177] New: Incorrect warning message about unused PRIVATE module variable

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58177

Bug ID: 58177
   Summary: Incorrect warning message about unused PRIVATE module
variable
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

With gfortran 4.9.0 (r201758) the following incorrectly reports than the
variable m in module b is unused:

module a
  logical :: m
end module a
module b
  logical, private :: m
contains
  subroutine bb()
use a
m=.true.
  end subroutine bb
end module b

$ gfortran -v   
Using built-in specs.   
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
 
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
--with-gmp=/home/abenson/Galacticus/Tools   
Thread model: posix 
gcc version 4.9.0 20130815 (experimental) (GCC) 
$ gfortran -c bug.F90 -o bug.o -Wall
bug.F90:5.23:   

  logical, private :: m 
   1
Warning: Unused PRIVATE module variable 'm' declared at (1)

The variable m in module b is used. The problem seems to be related to the
presence of a PUBLIC variable with the same name in another USEd module.
Changing the name of the variable in the USEd module makes the warning go away.
Renaming the imported variable with:

use a, only : mm = m

results in a correct warning:

Warning: Unused module variable 'm' which has been explicitly imported at (1)

and causes the Unused PRIVATE warning to go away.

[Bug fortran/58171] New: Incorrect error message on invalid code when using class constructor

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58171

Bug ID: 58171
   Summary: Incorrect error message on invalid code when using
class constructor
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

The following code leads to an incorrect error message from the compiler using
gfortran 4.9.0 (r201758):

module ct
  type :: cps
 private
 double precision :: aa ! Removing this line leads to a more meaningful
error message from the compiler.
   contains
  end type cps
  interface cps
 module procedure newCps
  end interface cps
contains
  function newCps(a,b)
implicit none
type(cps) :: newCps
double precision, intent(in) :: a,b
return
  end function newCps
end module ct
program bug
  use ct
  implicit none
  type(cps) :: c
  c=cps(0.27d0) !,0.13d0) ! Passing two arguments (as expected) results in
successful compile.
end program bug

$ gfortran -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-trunk/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/opt/gcc-trunk
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.9.0 20130808 (experimental) (GCC) 


$ gfortran bug.F90 -o bug.exe
bug.F90:22.4:

  c=cps(0.27d0) !,0.13d0) ! Passing two arguments (as expected) results in
successful compile.
1
Error: Component 'aa' at (1) is a PRIVATE component of 'cps'

The code is invalid - the class constructor requires two arguments - but the
error message doesn't reflect this. Passing two arguments to the constructor
results in a successful compile. 

If I remove the aa variable from the cps type then the error message is more
useful:

$ gfortran bug.F90 -o bug.exe
bug.F90:22.8:

  c=cps(0.27d0) !,0.13d0) ! Passing two arguments (as expected) results in
successful compile.
1
Error: Too many components in structure constructor at (1)!

but still incorrect - it should be Too few components in structure
constructor, not Too many.

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306

--- Comment #15 from Andrew Benson abensonca at gmail dot com ---
Thanks for fixing!

[Bug fortran/58023] New: ICE on invalid with missing NOPASS

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58023

Bug ID: 58023
   Summary: ICE on invalid with missing NOPASS
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

The following causes and ICE using gfortran 4.9.0 (r201320):

module m
  implicit none

  abstract interface
 double precision function mr()
 end function mr
  end interface

  type :: sfd
 procedure(mr), pointer :: mr1
 procedure(mr), pointer :: mr2
  end type sfd

contains

  subroutine go()
implicit none
type(sfd):: d

write (0,*) d%mr2()
return
  end subroutine go

end module m



$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
--with-gmp=/home/abenson/Galacticus/Tools
Thread model: posix
gcc version 4.9.0 20130729 (experimental) (GCC) 

$ gfortran -c bug.F90 -o bug.o
bug.F90:10.34:

 procedure(mr), pointer :: mr1
  1
Error: Procedure pointer component 'mr1' with PASS at (1) must have at least
one argument
f951: internal compiler error: in update_ppc_arglist, at fortran/resolve.c:5346
0x58332a update_ppc_arglist
../../gcc-trunk/gcc/fortran/resolve.c:5346
0x57f63c resolve_expr_ppc
../../gcc-trunk/gcc/fortran/resolve.c:6020
0x57f63c gfc_resolve_expr(gfc_expr*)
../../gcc-trunk/gcc/fortran/resolve.c:6119
0x5860bb resolve_code
../../gcc-trunk/gcc/fortran/resolve.c:9692
0x585e0b gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:9006
0x586099 resolve_code
../../gcc-trunk/gcc/fortran/resolve.c:9682
0x588c8e resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:14471
0x588b97 resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:14457
0x588d72 gfc_resolve
../../gcc-trunk/gcc/fortran/resolve.c:14499
0x5755bf gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:4645
0x5b1545 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.

The code is invalid because both procedure pointers in the sfd derived type
should have the NOPASS attribute (since the mr abstract interface declares no
arguments). 

The ICE only occurs if two (or more) procedure points are declared in this way,
AND the procedure pointer is accessed (via the write statement in this
example).

[Bug fortran/57306] New: ICE on valid with class pointer assignment

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306

Bug ID: 57306
   Summary: ICE on valid with class pointer assignment
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

The following causes an ICE with gfortran 4.9.0 r198983:

module t
  type :: c
  end type c
  type(c), target :: cd
  class(c), public, pointer :: cc = cd
end module t

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
--with-gmp=/home/abenson/Galacticus/Tools
Thread model: posix
gcc version 4.9.0 20130516 (experimental) (GCC) 

$ gfortran -c bug.F90 -o bug.o
bug.F90:7:0: internal compiler error: in gfc_conv_structure, at
fortran/trans-expr.c:6027
   class(c), public, pointer :: cc = cd
 ^
0x5be449 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc-trunk/gcc/fortran/trans-expr.c:6027
0x5be610 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc-trunk/gcc/fortran/trans-expr.c:5606
0x5a8cd6 gfc_get_symbol_decl(gfc_symbol*)
../../gcc-trunk/gcc/fortran/trans-decl.c:1500
0x5aeb02 gfc_create_module_variable
../../gcc-trunk/gcc/fortran/trans-decl.c:4144
0x572ed3 do_traverse_symtree
../../gcc-trunk/gcc/fortran/symbol.c:3571
0x5aef52 gfc_generate_module_vars(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.c:4543
0x588ec1 gfc_generate_module_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans.c:1738
0x547687 translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.c:4456
0x547687 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:4666
0x583a25 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.

[Bug fortran/56477] New: ICE on invalid with pointer assignment to function result

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56477



 Bug #: 56477

   Summary: ICE on invalid with pointer assignment to function

result

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: abenso...@gmail.com





The following causes an ICE with gfortran 4.8.0 r196316:



module s

contains

  function so()

implicit none

integer, target  :: so

integer, pointer :: sp

sp = so

return

  end function So

end module s



$ gfortran -v

Using built-in specs.

COLLECT_GCC=gfortran

COLLECT_LTO_WRAPPER=/home/abenson/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: ../gcc-trunk/configure --prefix=/home/abenson

--enable-languages=c,c++,fortran --disable-multilib --with-gmp=/home/abenson

Thread model: posix

gcc version 4.8.0 20130227 (experimental) (GCC) 



$ gfortran -c -o ICEtest.o ICEtest.F90 -Wall

f951: internal compiler error: Segmentation fault

0x92f79f crash_signal

../../gcc-trunk/gcc/toplev.c:332

0x4fdbf2 gfc_check_pointer_assign(gfc_expr*, gfc_expr*)

../../gcc-trunk/gcc/fortran/expr.c:3734

0xd6 resolve_code

../../gcc-trunk/gcc/fortran/resolve.c:10261

0x557c5e resolve_codes

../../gcc-trunk/gcc/fortran/resolve.c:14972

0x557b67 resolve_codes

../../gcc-trunk/gcc/fortran/resolve.c:14958

0x548aa2 gfc_resolve

../../gcc-trunk/gcc/fortran/resolve.c:15000

0x53d186 gfc_parse_file()

../../gcc-trunk/gcc/fortran/parse.c:4608

0x579415 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.





The -Wall is important - without the code compiles without complaint.



I tagged this as invalid(?) because I don't think that giving the function

return value the TARGET attribute makes sense, although I couldn't find

anything that clearly says it's not allowed.

[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261



--- Comment #8 from Andrew Benson abensonca at gmail dot com 2013-02-09 
16:50:54 UTC ---

On the test case in comment 2, ifort v11.1 reports:



 ifort -o bug.exe bug.F90 

bug.F90(23): error #6592: This symbol must be a defined parameter, an

enumerator, or an argument of an inquiry function that evaluates to a

compile-time constant.   [FF]

  procedure(  ), pointer   :: f = ff

---^

bug.F90(23): error #6973: This is not a valid initialization expression.   [FF]

  procedure(  ), pointer   :: f = ff

---^

compilation aborted for bug.F90 (code 1)



Same for the scalar case.



Interestingly, the workaround doesn't work under ifort - it seems not to like:



  procedure(ff), pointer :: f = ff



but instead needs:



  procedure(ff), pointer :: f

  f = ff



In fact, if I use:



  procedure(), pointer :: f

  f = ff



then it compiles without any warnings/errors but segfaults at runtime.



With:





  procedure(ff), pointer :: f

  f = ff



it compiles and runs as expected.

[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261



--- Comment #10 from Andrew Benson abensonca at gmail dot com 2013-02-09 
17:01:22 UTC ---

You're right - comment 1.

[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261



--- Comment #11 from Andrew Benson abensonca at gmail dot com 2013-02-09 
17:06:18 UTC ---

Thanks for figuring out the problem here. When I specify an interface for the

procedure pointer in the original code that I derived the test case from,

everything works OK.

[Bug fortran/56266] New: ICE on invalid in gfc_match_varspec

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56266



 Bug #: 56266

   Summary: ICE on invalid in gfc_match_varspec

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: abenso...@gmail.com





The following causes an ICE with trunk (and 4.6 and 4.7):



module t



  type nc

   contains

 procedure :: encM = em

  end type nc



contains



  double precision function em(self)

implicit none

class  (nc), intent(inout) :: c

em=0.0d0

return

  end function em



  double precision function cem(c)

implicit none

class  (nc), intent(inout) :: c



cem=c(i)%encM()

return

  end function cem



end program p



$ gfortran -v

Using built-in specs.

COLLECT_GCC=gfortran

COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-

linux-gnu/4.8.0/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: ../gcc-trunk/configure --

prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --

disable-multilib --with-gmp=/home/abenson/Galacticus/Tools

Thread model: posix

gcc version 4.8.0 20130208 (experimental) (GCC) 

$ gfortran -o bug.exe bug.F90

f951: internal compiler error: in gfc_match_varspec, at fortran/primary.c:1960

0x540478 gfc_match_varspec(gfc_expr*, int, bool, bool)

../../gcc-trunk/gcc/fortran/primary.c:1957

0x541a99 gfc_match_rvalue(gfc_expr**)

../../gcc-trunk/gcc/fortran/primary.c:3118

0x528d8e match_primary

../../gcc-trunk/gcc/fortran/matchexp.c:157

0x528d8e match_level_1

../../gcc-trunk/gcc/fortran/matchexp.c:211

0x528d8e match_mult_operand

../../gcc-trunk/gcc/fortran/matchexp.c:265

0x528fc8 match_add_operand

../../gcc-trunk/gcc/fortran/matchexp.c:354

0x5292e4 match_level_2

../../gcc-trunk/gcc/fortran/matchexp.c:478

0x529382 match_level_3

../../gcc-trunk/gcc/fortran/matchexp.c:549

0x529495 match_level_4

../../gcc-trunk/gcc/fortran/matchexp.c:597

0x529495 match_and_operand

../../gcc-trunk/gcc/fortran/matchexp.c:691

0x529652 match_or_operand

../../gcc-trunk/gcc/fortran/matchexp.c:720

0x529742 match_equiv_operand

../../gcc-trunk/gcc/fortran/matchexp.c:763

0x529834 match_level_5

../../gcc-trunk/gcc/fortran/matchexp.c:809

0x528be1 gfc_match_expr(gfc_expr**)

../../gcc-trunk/gcc/fortran/matchexp.c:868

0x522631 gfc_match(char const*, ...)

../../gcc-trunk/gcc/fortran/match.c:1103

0x523b19 gfc_match_assignment()

../../gcc-trunk/gcc/fortran/match.c:1301

0x537449 match_word

../../gcc-trunk/gcc/fortran/parse.c:65

0x537bdb match_word

../../gcc-trunk/gcc/fortran/parse.c:326

0x537bdb decode_statement

../../gcc-trunk/gcc/fortran/parse.c:326

0x539194 next_free

../../gcc-trunk/gcc/fortran/parse.c:777

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.



This is with gfortran 4.8.0 r195874



The code is invalid because of this line:



cem=c(i)%encM()



both because c is not an array, and i is not declared (and the function is 

IMPLICIT NONE)

[Bug fortran/56261] New: seg fault call procedure pointer on polymorphic array

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261



 Bug #: 56261

   Summary: seg fault call procedure pointer on polymorphic array

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: abenso...@gmail.com





The following test case causes a seg fault at run time using gfortran 4.8.0 

(r195874):



module t



  type, public :: nc

 character(len=3) :: n

  end type nc



  type, public :: tn

 class(nc), allocatable, dimension(:) :: c

   contains

 procedure :: mapProcPtr  =  doMapProcPtr

 procedure :: mapExternal =  doMapExternal

  end type tn



contains



  subroutine doMapProcPtr(self,func)

implicit none

class(tn), intent(inout) :: self   

procedure(  ), pointer   :: func

call func(self%c) !! This form causes segfault. 

!call ff(self%c)  !! This form works.   

return

  end subroutine doMapProcPtr



  subroutine doMapExternal(self,func)

implicit none

class(tn), intent(inout) :: self   

external :: func

call func(self%c)

return

  end subroutine doMapExternal



  subroutine ff(self)

implicit none

class(nc), intent(in), dimension(:) :: self



write (0,*) '  -- in ff size of self is ',size(self)

write (0,*) '  -- content of self(1)%n) is ',self(1)%n

return

  end subroutine ff



end module t



program p

  use t

  implicit none

  type (tn)  :: a

  procedure(  ), pointer :: f = ff



  allocate(a%c(10))

  a%c(1)%n='abc'

  write (0,*) 'in p size of a%c is ',size(a%c)

  write (0,*) directly call ff():

  call ff(a%c)

  ! write (0,*) call via a%mapExternal(f): !! Using this version, which 

passes the function to call as an  

  ! call a%mapExternal(f)!! EXTERNAL rather than as a 

procedure pointer also segfaults.  

  write (0,*) call via a%mapProcPtr(f):

  call a%mapProcPtr(f)



end program p





$ gfortran -v

Using built-in specs.

COLLECT_GCC=gfortran

COLLECT_LTO_WRAPPER=/home/abenson/libexec/gcc/x86_64-unknown-linux-

gnu/4.8.0/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: ../gcc-trunk/configure --prefix=/home/abenson --enable-

languages=c,c++,fortran --disable-multilib --with-gmp=/home/abenson

Thread model: posix

gcc version 4.8.0 20130208 (experimental) (GCC) 

$ gfortran -o bug.exe bug.F90

$ bug.exe 

 in p size of a%c is   10

 directly call ff():

   -- in ff size of self is   10

   -- content of self(1)%n) is abc

 call via a%mapProcPtr(f):

   -- in ff size of self is   131154



Program received signal SIGSEGV: Segmentation fault - invalid memory 

reference.



Backtrace for this error:

#0  0x2AE75E9FC387

#1  0x2AE75E9FC99E

#2  0x3D470302CF

#3  0x400BA4 in __t_MOD_ff

#4  0x400DB1 in __t_MOD_domapprocptr

#5  0x401106 in MAIN__ at bug.F90:0

Segmentation fault



The same problem happens if I use an EXTERNAL instead of a procedure pointer, 

but not if I call the subroutine directly.



If c in the tn type is a instead scalar then this works successfully.



Running this through valgrind I get:



$ valgrind bug.exe

==4488== Memcheck, a memory error detector

==4488== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.

==4488== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info

==4488== Command: bug.exe

==4488== 

 in p size of a%c is   10

 directly call ff():

   -- in ff size of self is   10

   -- content of self(1)%n) is abc

 call via a%mapProcPtr(f):

==4488== Invalid read of size 8

==4488==at 0x400ADA: __t_MOD_ff (in ./bug.exe)

==4488==by 0x400DB1: __t_MOD_domapprocptr (in ./bug.exe)

==4488==by 0x401106: MAIN__ (in ./bug.exe)

==4488==by 0x401162: main (in ./bug.exe)

==4488==  Address 0x5396368 is 10 bytes after a block of size 30 alloc'd

==4488==at 0x4A08328: malloc (vg_replace_malloc.c:263)

==4488==by 0x400E4E: MAIN__ (in ./bug.exe)

==4488==by 0x401162: main (in ./bug.exe)

==4488== 

==4488== Invalid read of size 8

==4488==at 0x400ADE: __t_MOD_ff (in ./bug.exe)

==4488==by 0x400DB1: __t_MOD_domapprocptr (in ./bug.exe)

==4488==by 0x401106: MAIN__ (in ./bug.exe)

==4488==by 0x401162: main (in ./bug.exe)

==4488==  Address 0x5396360 is 2 bytes after a block of size 30 alloc'd

==4488==at 0x4A08328: malloc (vg_replace_malloc.c:263)

==4488==by 0x400E4E: MAIN__ (in ./bug.exe)

==4488==by 0x401162: main (in ./bug.exe)

==4488== 

   -- in ff size of self is1

==4488== Invalid read of size 8

==4488==at 0x400B92: __t_MOD_ff (in ./bug.exe)

==4488==by 0x400DB1: __t_MOD_domapprocptr (in 

[Bug fortran/56261] seg fault call procedure pointer on polymorphic array

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261



--- Comment #1 from Andrew Benson abensonca at gmail dot com 2013-02-08 
23:19:11 UTC ---

Reduced test case:



module t



  type, public :: nc

 integer :: n

  end type nc



contains



  subroutine ff(self)

implicit none

class(nc), intent(in), dimension(:) :: self



write (0,*) '  -- content of self(1)%n) is ',self(1)%n

return

  end subroutine ff



end module t



program p

  use t

  implicit none

  class(nc), allocatable, dimension(:) :: c

  procedure(  ), pointer   :: f = ff



  allocate(c(10))

  call f(c)



end program p

[Bug fortran/55855] New: incorrect warning with type-bound procedure pointer

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55855

 Bug #: 55855
   Summary: incorrect warning with type-bound procedure pointer
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: abenso...@gmail.com


The following:

module eventMod
  type, public :: event
     private
    procedure(eventTask ), pointer, public :: task
 end type event
  abstract interface
     logical function eventTask(self)
       import event
       class(event), intent(in) :: self
     end function eventTask
  end interface
end module eventMod
program test
  use eventMod
  implicit none
  logical :: r
  type(event), pointer :: myEvent
  allocate(myEvent)
  r=myEvent%task()
end program test

causes the following warning when compiled (with gfortran 4.8.0):

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-
linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --
prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --
disable-multilib --with-gmp=/home/abenson/Galacticus/Tools
Thread model: posix
gcc version 4.8.0 20121219 (experimental) (GCC)

$ gfortran -o warn.exe warn.F90 -Wall
warn.F90:19.4:

  r=myEvent%task()
    1
Warning: POINTER valued function appears on right-hand side of assignment at
(1)

As far as I can tell, the code runs correctly despite this warning.

the warning is spurious as the task function returns a logical, not a
pointer.

[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884



--- Comment #7 from Andrew Benson abensonca at gmail dot com 2012-12-19 
17:31:47 UTC ---

The fix for this bug has been working for me, but I'm getting reports from

several colleagues (who are trying to install the FoX library so that they can

install my software) that compiling the FoX library fails with what seems to be

the same problem as reported here:



gfortran -g -O2   -o  wxml_example wxml_example.o $(../FoX-config --libs

--wxml)

/home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_wxml.a(m_wxml_core.o): In

function `__m_wxml_core_MOD_write_attributes':

m_wxml_core.F90:(.text+0x1a1): undefined reference to

`__m_common_attrs_MOD_get_value_by_index_len'

m_wxml_core.F90:(.text+0x232): undefined reference to

`__m_common_attrs_MOD_get_key_len'

m_wxml_core.F90:(.text+0x27d): undefined reference to

`__m_common_attrs_MOD_get_value_by_index_len'

m_wxml_core.F90:(.text+0x321): undefined reference to

`__m_common_attrs_MOD_get_key_len'

m_wxml_core.F90:(.text+0x3cc): undefined reference to

`__m_common_attrs_MOD_get_value_by_index_len'

m_wxml_core.F90:(.text+0x431): undefined reference to

`__m_common_attrs_MOD_get_value_by_index_len'

/home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_wxml.a(m_wxml_core.o): In

function `__m_wxml_core_MOD_xml_addattribute_ch':

m_wxml_core.F90:(.text+0x2818): undefined reference to

`__m_common_namespaces_MOD_getprefixindex'

m_wxml_core.F90:(.text+0x2d26): undefined reference to

`__m_common_namespaces_MOD_getprefixindex'

m_wxml_core.F90:(.text+0x3298): undefined reference to

`__m_common_namespaces_MOD_getprefixindex'

/home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_wxml.a(m_wxml_overloads.o):

In function `__m_wxml_overloads_MOD_pseudoattributematrixch':

m_wxml_overloads.F90:(.text+0xc2): undefined reference to

`__fox_m_fsys_format_MOD_str_string_matrix_len'

/home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_wxml.a(m_wxml_overloads.o):

In function `__m_wxml_overloads_MOD_pseudoattributearraych':

m_wxml_overloads.F90:(.text+0xea8): undefined reference to

`__fox_m_fsys_format_MOD_str_string_array_len'

/home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_wxml.a(m_wxml_overloads.o):

In function `__m_wxml_overloads_MOD_attributematrixch':

m_wxml_overloads.F90:(.text+0x2182): undefined reference to

`__fox_m_fsys_format_MOD_str_string_matrix_len'

/home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_wxml.a(m_wxml_overloads.o):

In function `__m_wxml_overloads_MOD_attributearraych':

m_wxml_overloads.F90:(.text+0x2feb): undefined reference to

`__fox_m_fsys_format_MOD_str_string_array_len'

/home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_wxml.a(m_wxml_overloads.o):

In function `__m_wxml_overloads_MOD_charactersmatrixch':

m_wxml_overloads.F90:(.text+0x438e): undefined reference to

`__fox_m_fsys_format_MOD_str_string_matrix_len'

/home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_wxml.a(m_wxml_overloads.o):

In function `__m_wxml_overloads_MOD_charactersarraych':

m_wxml_overloads.F90:(.text+0x4f78): undefined reference to

`__fox_m_fsys_format_MOD_str_string_array_len'

/home/jlgan/galacticus/soft/FoX-4.1.0/objs/lib/libFoX_common.a(m_common_namespaces.o):

In function `__m_common_namespaces_MOD_checknamespaces':

m_common_namespaces.F90:(.text+0x3928): undefined reference to

`__m_common_attrs_MOD_get_key_len'

m_common_namespaces.F90:(.text+0x39b9): undefined reference to

`__m_common_attrs_MOD_get_value_by_index_len'

m_common_namespaces.F90:(.text+0x3f7b): undefined reference to

`__m_common_attrs_MOD_get_key_len'

m_common_namespaces.F90:(.text+0x41a9): undefined reference to

`__m_common_attrs_MOD_get_key_len'

m_common_namespaces.F90:(.text+0x426f): undefined reference to

`__m_common_attrs_MOD_get_value_by_index_len'

collect2: error: ld returned 1 exit status

make[1]: *** [wxml_example] Error 1

make[1]: Leaving directory `/home/jlgan/galacticus/soft/FoX-4.1.0/examples'

make: *** [examples_build] Error 2





These problems have occurred when using the most recent checkout of gcc 4.8.0

(the last case I saw of this happening was yesterday). I've been unable to

reproduce the problem myself, even when using the same revision. 



Manually marking all of the functions that are listed as undefined reference

as PUBLIC solves the issue.



In any case, if anyone else is able to reproduce the problem I'd be very

interested to hear!

[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884



--- Comment #8 from Andrew Benson abensonca at gmail dot com 2012-12-19 
18:02:44 UTC ---

I spoke to soon! I just compiled r194618 of gcc and now I find the same

problem.

[Bug fortran/55172] New: ICE on invalid: gfc_variable_attr(): Bad array reference

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55172



 Bug #: 55172

   Summary: ICE on invalid: gfc_variable_attr(): Bad array

reference

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: abenso...@gmail.com





The following test case produces and ICE with gfortran 4.8 (r193051):



module gn

  type :: ncb

  end type ncb

  type, public :: tn

 class(ncb), allocatable, dimension(:) :: cb

  end type tn

contains

  integer function name(self)

implicit none

class (tn), intent(in) :: self

select type (component = self%cb(i))

end select

  end function name

end module gn



$ gfortran -v

Using built-in specs.

COLLECT_GCC=gfortran

COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-

linux-gnu/4.8.0/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: ../gcc-trunk/configure --

prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --

disable-multilib --with-gmp=/home/abenson/Galacticus/Tools

Thread model: posix

gcc version 4.8.0 20121031 (experimental) (GCC) 



$ gfortran -c bug4.F90 -o bug4.o

bug4.F90:14.13:



end module gn

 1   

Internal Error at (1):

gfc_variable_attr(): Bad array reference





The code is invalid because the name function contains implicit none but 

the variable i used in:



select type (component = self%cb(i))



is not explicitly defined. If I remove the implicit none or explicitly 

define i the ICE goes away.





(Reported by Janus at http://gcc.gnu.org/ml/fortran/2012-11/msg5.html):

With 4.7 the ICE also occurs, but only after the correct error message:



select type (component = self%cb(i))

   1

Error: Symbol 'i' at (1) has no IMPLICIT type