https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94446
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=83113
Andrew Benson changed:
What|Removed |Added
CC||abensonca at gmail dot com
--- Comment
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=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 #7 from Andrew Benson ---
Created attachment 47735
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47735&action=edit
updated patch
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=90788
--- Comment #2 from Andrew Benson ---
Created attachment 47734
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47734&action=edit
updated patch
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 b
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 at
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&action=edit
Proposed 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=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 h
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|---
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=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 concat
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&action=edit
Proposed 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=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 insuffici
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&action=edit
Patch for PR93461
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
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
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 results in a bogus error (using git commit
472dc648ce3e7661762931d584d239611ddca964) claiming a pointer attribute
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 fi
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 #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 #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)
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 MP
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 gives an ICE with trunk:
module vdc
type:: vdcp
class(*), pointer :: po => null()
end t
: 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
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
: 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=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
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
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
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=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
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=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=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 sect
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=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 solv
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
: 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175
--- Comment #6 from Andrew Benson ---
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 r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66633
--- Comment #13 from Andrew Benson ---
(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.
Specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66633
--- Comment #1 from Andrew Benson ---
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66366
--- Comment #3 from Andrew Benson ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66366
--- Comment #2 from Andrew Benson ---
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
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_
dou
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
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=61824
--- Comment #4 from Andrew Benson ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61824
--- Comment #2 from Andrew Benson ---
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-li
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54221
--- Comment #11 from Andrew Benson ---
(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 th
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
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58356
--- Comment #5 from Andrew Benson ---
Thanks for fixing!
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
: 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58182
--- Comment #4 from Andrew Benson ---
"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 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58171
--- Comment #2 from Andrew Benson ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58177
--- Comment #2 from Andrew Benson ---
You're absolutely correct - my mistake!
: 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
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
e
: 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
The following code leads to an incorrect error message from the compiler using
gfortran 4.9.0 (r201758):
module ct
type :: cps
private
double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306
--- Comment #15 from Andrew Benson ---
Thanks for fixing!
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
: 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
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
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
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261
--- Comment #11 from Andrew Benson 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261
--- Comment #10 from Andrew Benson 2013-02-09
17:01:22 UTC ---
You're right - comment 1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261
--- Comment #8 from Andrew Benson 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 argume
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261
--- Comment #1 from Andrew Benson 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), dimens
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: nor
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884
--- Comment #8 from Andrew Benson 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=54884
--- Comment #7 from Andrew Benson 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) th
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
1 - 100 of 103 matches
Mail list logo
