https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99147
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99204
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99206
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99206
--- Comment #2 from anlauf at gcc dot gnu.org ---
As a sidenote:
print *, len (reshape (['a'], [0]))
end
This prints 0 for gcc-11, and the correct value 1 for 10.2.1.
Do we screw up things during simplification?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99206
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99206
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99206
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218
--- Comment #2 from anlauf at gcc dot gnu.org ---
Reduced testcase:
program play
implicit none
integer, parameter :: NCON = 1
integer, parameter :: NSTATE = 3
real,parameter :: ZERO = 0.0
real :: G(nCon,nState) = ZERO
real :: lamb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to fail||8.4.1
--- Comment #3 from anl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Summary|matmul on temporary array |[8/9/19/11 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Summary|[8/9/19/11 Regression] |[8/9/10/11 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99257
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93340
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #28 from anlauf at gcc dot gnu.org ---
Patch for accepts-invalid / ice-on-invalid-code (parameter + data) part:
https://gcc.gnu.org/pipermail/fortran/2021-March/055768.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99368
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99345
--- Comment #10 from anlauf at gcc dot gnu.org ---
Further reduced:
DO iq = 1, nq
CALL calc_upper_fan (iq)
ENDDO
CONTAINS
SUBROUTINE calc_upper_fan (iq)
INTEGER :: iq
INTEGER :: recl
INQUIRE(IOLENGTH=recl) iq
END
END
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99205
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-03-08
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99205
--- Comment #2 from anlauf at gcc dot gnu.org ---
This fixes the testcase and passes regtesting:
diff --git a/gcc/fortran/data.c b/gcc/fortran/data.c
index 25e97930169..71e2552025d 100644
--- a/gcc/fortran/data.c
+++ b/gcc/fortran/data.c
@@ -595,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99205
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99506
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> I don't know fortran enough for what 'parameter' means in this context:
>
>real(double), parameter:: latt(jmax) = [(latt100(i)/100.d0, j=1,jmax)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99112
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #2)
> For whatever reason, the chunk in gfc_conv_intrinsic_size doesn't quite work
> correctly because the wrong message is selected. Thus a bit more work is
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99112
--- Comment #4 from anlauf at gcc dot gnu.org ---
A simple one-liner on top of Paul's patch fixes it:
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 9cf3642f694..5e53d1162fa 100644
--- a/gcc/fortran/trans-intrins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99585
Bug ID: 99585
Summary: ICE with SIZE intrinsic on nested derived type
components
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99585
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99112
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99585
--- Comment #1 from anlauf at gcc dot gnu.org ---
Reduced example:
module m
type t
end type
type t2
type(t), allocatable :: my(:)
end type t2
contains
function h (x) result(z)
class(t2) :: x(:)
type(t) :: z(size(x(1)%my))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99585
--- Comment #2 from anlauf at gcc dot gnu.org ---
Actually the SIZE intrinsic might be a red herring, as the following variant
does also ICE:
module m
type t
end type
type t2
integer :: n
end type t2
contains
function h (x) result(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99138
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #14 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #13)
> Cool, thanks for the quick reaction, Paul. Maybe Harald can have a look at
> it as well :D
LGTM. It's by Paul. He simply needs to get the testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99138
--- Comment #7 from anlauf at gcc dot gnu.org ---
The patch in comment#6 generates an unexpected error:
pr99138.f90:11:2:
11 | module function f(x)
| 1
Error: Type mismatch in function result (CLASS(STAR)/CLASS(*)) between the
MODULE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99138
--- Comment #8 from anlauf at gcc dot gnu.org ---
The check in interface.c:gfc_check_result_characteristics has an asymmetry
coming from symbol.c:gfc_type_compatible that could be evaded by swapping
arguments:
diff --git a/gcc/fortran/interface.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #16 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #15)
> > LGTM. It's by Paul. He simply needs to get the testcase's dg-foo right...
> > ;-)
>
> Now I'm confused. So you consider the fix ok? Will it then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99609
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99205
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99688
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99709
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|VALUE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99369
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99740
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-03-23
Ever confirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #13 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96012
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99348
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99798
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99817
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99819
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |8.5
Summary|ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840
--- Comment #4 from anlauf at gcc dot gnu.org ---
For reasons I do not understand,
Breakpoint 1, gfc_simplify_matmul (matrix_a=0x292bbf0, matrix_b=0x292c550)
at ../../gcc-trunk/gcc/fortran/simplify.c:4777
4777 result_columns = mpz_ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840
--- Comment #5 from anlauf at gcc dot gnu.org ---
OK, now I see it. gfc_get_shape does not init the resulting shape.
The following simpler patch does the job:
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 388aca7c38c..c27b47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840
--- Comment #8 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2021-March/055897.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797
--- Comment #4 from anlauf at gcc dot gnu.org ---
The following patch regtests ok and fixes the testcase:
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 4db0a3ac76d..b4b7b437f86 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797
--- Comment #6 from anlauf at gcc dot gnu.org ---
Steve, can you give an example for the procedure pointer case you mentioned?
I played a bit, but the only valid code that I can think of did not produce
a reference to sqrt in such a way that it ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797
--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #7)
> which looks like a default initialization. Does sqrt need to be
> recorded into the module? If not, then your patch is probably ok.
My patch actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797
--- Comment #9 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2021-April/055935.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99255
--- Comment #2 from anlauf at gcc dot gnu.org ---
Replacing
class(t) :: x
by
class(t), allocatable :: x
avoids the ICE. Could be an error recovery issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100136
--- Comment #2 from anlauf at gcc dot gnu.org ---
We do not properly handle the VALUE attribute.
Reduced testcase:
program p
implicit none
class(*), allocatable :: d
call add_class (d)
contains
subroutine add_class (d)
class(*), val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100154
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100154
--- Comment #2 from anlauf at gcc dot gnu.org ---
Untested patch:
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 82db8e4e1b2..df4409840d5 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -5730,6 +5731,15 @@ gfc_check_f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97799
--- Comment #6 from anlauf at gcc dot gnu.org ---
I couldn't find any current 11-master, 10-, 9- and 8-branch version that
fails on x86_64-pc-linux-gnu, under valgrind, and with -m32 and -m64.
So it looks very likely that Dominique is right that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314
--- Comment #7 from anlauf at gcc dot gnu.org ---
The ICE in comment#0 vanishes when one replaces
integer,parameter::iarray(merge(2,3,.true.)) = 1
with
integer,parameter::iarray(merge(2,3,.true.)) = [ 1, 1 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85796
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48958
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48958
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P5
Status|SUSPEND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> Reverting the following snippet from my fix attempt for pr91651:
That snippet is necessary for the scalarizer during simplification.
The original ICE is comi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #4)
> Elemental actual arguments are some of those arrays involved.
> Obviously one should not remove some of them in the middle of code
> generation.
> It sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85796
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85796
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97977
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to fail||11.0
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300
--- Comment #6 from anlauf at gcc dot gnu.org ---
Currently the only generated STAT code is 5014 for LIBERROR_ALLOCATION.
This is ambiguous.
Shall we add another enum value to libgfortran_error_codes, such as
LIBERROR_VIRTUAL_MEMORY, LIBERROR_MEM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017
--- Comment #3 from anlauf at gcc dot gnu.org ---
Further reduced variant:
program p
implicit none
character(*), parameter :: exprs(1) = ['abc()']
print *, len (pack ( exprs , exprs(:)(:1) =='a'))
print *, len (pack (['abc()'],['abc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017
--- Comment #5 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2020-November/055367.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98023
--- Comment #3 from anlauf at gcc dot gnu.org ---
The patch in comment#1 does not work for me on x86_64-pc-linux-gnu.
In decl.c:
6242cleanup:
6243 if (saved_kind_expr)
6244gfc_free_expr (saved_kind_expr);
6245 if (type_para
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #2)
> > So the new compiler does compile-time simplification already at -O0,
> > while older versions maybe not.
>
> Is this expected?
Depends. I'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #8 from anlauf at gcc dot gnu.org ---
Created attachment 49687
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49687&action=edit
Untested patch (proof of concept)
Here's a possible patch that retries after short reads.
Not regte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #9 from anlau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #10)
> Seems like that, if nbyte <= MAX_CHUNK, we do not take account of the
> possibility of a short read.
Yes, that seems to be the better/right place.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #3 from anlauf at gcc dot gnu.org ---
The case
program p
print *, +[ real :: +(1) ]
end
is solved by e.g.
diff --git a/gcc/fortran/arith.c b/gcc/fortran/arith.c
index c4c1041afdf..b2fbeddeb49 100644
--- a/gcc/fortran/arith.c
+++ b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93337
--- Comment #12 from anlauf at gcc dot gnu.org ---
The valgrind invalid read is possibly an issue with error recovery when
handling
the assignment.
Modifying the testcase:
program p
type t
character(:), allocatable :: a
end type t
cla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98263
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95372
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95372
--- Comment #3 from anlauf at gcc dot gnu.org ---
Playing around with the above patches, I found that the following now gets
rejected instead of an ICE:
program p
type t
integer :: a = 1
end type t
type(t), parameter :: z(3) = t()
ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98284
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98284
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Assignee|u
301 - 400 of 1554 matches
Mail list logo
