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
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.
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667
--- Comment #7 from Andrew Benson abensonca at gmail dot com 2012-09-22
16:59:26 UTC ---
(In reply to comment #3)
(In reply to comment #2)
While it would be nontrivial to fully enforce these constraints by a runtime
check, I think
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667
--- Comment #8 from Andrew Benson abensonca at gmail dot com 2012-09-22
17:02:06 UTC ---
Thanks for clarifying this. It does look like this is invalid according to the
standard. I'll think of another way to do what I was trying to do.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667
--- Comment #11 from Andrew Benson abensonca at gmail dot com 2012-09-22
19:39:17 UTC ---
(In reply to comment #10)
(In reply to comment #9)
From Fortran 2008 15.2.3.6 and 15.2.3.3:
CPTR shall be a scalar of type C PTR. It is an INTENT
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
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:
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
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
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.
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
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
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:
: 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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #15 from Andrew Benson abensonca at gmail dot com ---
Thanks for fixing!
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
: 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
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
: 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
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!
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
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
: 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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58356
--- Comment #5 from Andrew Benson abensonca at gmail dot com ---
Thanks for fixing!
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
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
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
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
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
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
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
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
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.
: 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
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
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
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
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
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
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
NCONFIRMED
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
: 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
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
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 gfor
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
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
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
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!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175
Andrew Benson changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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
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
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.
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
ty: 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
: 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
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
===
---
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)
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
: 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
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 t
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
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
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
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
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
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
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" err
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90788
--- Comment #3 from Andrew Benson ---
Ignore previous comment - wrong PR.
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
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
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
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
: 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 aModestlyLongModuleNa
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
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
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
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_
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.
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103
Andrew Benson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83113
Andrew Benson changed:
What|Removed |Added
CC||abensonca at gmail dot com
--- Comment
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()
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
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.
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
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
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
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
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.
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93461
Andrew Benson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93473
Andrew Benson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
1 - 100 of 103 matches
Mail list logo
