[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301

[markeggleston at gcc dot gnu.org via Gcc-bugs]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #12 from markeggleston at gcc dot gnu.org ---
Committed to master.

[Bug fortran/96099] ICE in gfc_validate_kind, at fortran/trans-types.c:773

[markeggleston at gcc dot gnu.org via Gcc-bugs]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from markeggleston at gcc dot gnu.org ---
Committed to master.

[Bug fortran/50550] does not recognize pointer variable at initialization (r178939)

[markeggleston at gcc dot gnu.org via Gcc-bugs]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #8 from markeggleston at gcc dot gnu.org ---
@@ -2858,7 +2858,8 @@ variable_decl (int elem)
 {
   if (gfc_match (" =>") == MATCH_YES)
{
- if (!current_attr.pointer)
+ gfc_find_symbol (name, gfc_current_ns, 1, );
+ if (!(current_attr.pointer || (sym && sym->attr.pointer)))
{
  gfc_error ("Initialization at %C isn't for a pointer variable");
  m = MATCH_ERROR;

The contents of current_attr only applies to the line currently being parsed so
will not have the pointer attribute.  In the case where the pointer attribute
has already been declared a matching symbol should exist that has that
attribute set.

However, if the pointer attribute is declared after the initialisation it is
not known when initialisation line is parsed.  The parsing of pointer occurs
after the initialisation parsing is complete.

For this to be fixed where the attribute is declared after initialisation error
detection would have to be deferred until after parsing has been completed.

The above change does not result in any unexpected test case failures when
running make with check-fortran.

I'm no longer working on this PR as I do not know how to proceed.

[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301

[markeggleston at gcc dot gnu.org via Gcc-bugs]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from markeggleston at gcc dot gnu.org ---
See 97224

[Bug fortran/97224] [8/9/10/11 Regression] SPECCPU 2006 Gamess fails to build after g:e5a76af3a2f3324efc60b4b2778ffb29d5c377bc

[markeggleston at gcc dot gnu.org via Gcc-bugs]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #2 from markeggleston at gcc dot gnu.org ---
Reopened 95614

[Bug fortran/82721] [8/9/10/11 Regression] Error message with corrupted text, sometimes ICE

[markeggleston at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from markeggleston at gcc dot gnu.org ---
No progress. I have no idea how to fix this and will no longer work on it.

[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301

[markeggleston at gcc dot gnu.org via Gcc-bugs]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED

--- Comment #9 from markeggleston at gcc dot gnu.org ---
Committed to master and backported.

[Bug fortran/82721] [8/9/10/11 Regression] Error message with corrupted text, sometimes ICE

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #10 from markeggleston at gcc dot gnu.org ---
Using the bare minimum:

integer :: b
character(len(c)) :: b
end

I consistently get:

2 | character(len(c)) :: b
  |  1
Error: Symbol ‘b’ at (1) already has basic type of INTEGER
pr82721temp.f90:2:14:

2 | character(len(c)) :: b
  |  1
Error: Statement function ‘’ at (1) is not allowed as an actual argument

The second error pops out when the following code in resolve_types (resolve.c)
is executed:

  for (cl = ns->cl_list; cl; cl = cl->next)
resolve_charlen (cl);

The list of character lengths is corrupt, the first item points to an
expression of type EXPR_FUNCTION however its symtree has the name "end" instead
of "len" it had when it was first added to the character lengths list.

When reject_statement is called for "character(len(c)) :: b" the symtree
structure for "len" is deleted, unfortunately the reference to the deleted
symtree structure remains untouched in the expression representing the
character length.

Later a symtree is created for "end" which matches the symtree referenced by
the character length expression thus the name is changed to "end" and the
symtree points to symbol.

As an experiment using a nasty dirty hack I prevent the symtree being deleted
if it was referenced by the expression pointed to by the length field of the
charlen structure. It had not affect on the reported errors.

I have since discovered that the expression that is the first argument of the
"len" function also has a symtree that is deleted which the reference remains
as is.

Note: the comment preceding reject_statement says:

/* Undo anything tentative that has been built for the current statement,
   except if a gfc_charlen structure has been added to current namespace's
   list of gfc_charlen structure.  */

Clearly this is not the case as items referenced indirectly from the
gfc_charlen structure are deleted without references being touched.

Further investigation is in progress.

[Bug fortran/53298] ICE in gfc_conv_scalarized_array_ref for ARRAY + substring

[markeggleston at gcc dot gnu.org]

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

--- Comment #14 from markeggleston at gcc dot gnu.org ---
The test case in comment 7 proved trickier to track down.

The ICE occurs in this code:

  /* Components can correspond to fields of different containing
 types, as components are created without context, whereas
 a concrete use of a component has the type of decl as context.
 So, if the type doesn't match, we search the corresponding
 FIELD_DECL in the parent type.  To not waste too much time
 we cache this result in norestrict_decl.
 On the other hand, if the context is a UNION or a MAP (a
 RECORD_TYPE within a UNION_TYPE) always use the given FIELD_DECL.  */

  if (context != TREE_TYPE (decl)
  && !(   TREE_CODE (TREE_TYPE (field)) == UNION_TYPE /* Field is union */
  || TREE_CODE (context) == UNION_TYPE)) /* Field is map */
{
  tree f2 = c->norestrict_decl;
  if (!f2 || DECL_FIELD_CONTEXT (f2) != TREE_TYPE (decl))
==> for (f2 = TYPE_FIELDS (TREE_TYPE (decl)); f2; f2 = DECL_CHAIN (f2))
  if (TREE_CODE (f2) == FIELD_DECL
  && DECL_NAME (f2) == DECL_NAME (field))
break;
  gcc_assert (f2);
  c->norestrict_decl = f2;
  field = f2;
}


The ICE occurs at the line marked with ==>, the assignment f2 = TYPE_FIELDS
(TREE_TYPE (decl)) hides a call to a routine that returns a null pointer which
is then used causing the ICE.

I speculated that the code dealing with f2 should not have been executed. I
noted that in the comments "On the other hand, if the context is a UNION or a
MAP (a RECORD_TYPE within a UNION_TYPE) always use the given FIELD_DECL."  This
does not match the code that follows.

The following change:

trans-expr.c

@@ -2474,8 +2474,8 @@ gfc_conv_component_ref (gfc_se * se, gfc_ref * ref)
  RECORD_TYPE within a UNION_TYPE) always use the given FIELD_DECL.  */

   if (context != TREE_TYPE (decl)
-  && !(   TREE_CODE (TREE_TYPE (field)) == UNION_TYPE /* Field is union */
-   || TREE_CODE (context) == UNION_TYPE)) /* Field is map */
+  && (   TREE_CODE (context) == UNION_TYPE /* Field is union */
+  || TREE_CODE (context) == MAP_TYPE)) /* Field is map */
 {
   tree f2 = c->norestrict_decl;
   if (!f2 || DECL_FIELD_CONTEXT (f2) != TREE_TYPE (decl))

matches the comment and also fixes the ICE for the test case in comment 7.

make -j 8 check-fortran was looking good until test case failures were reported
for:

gfortran.dg/finalize_35.f90
gfortran.dg/finalize_36.f90

[Bug fortran/53298] ICE in gfc_conv_scalarized_array_ref for ARRAY + substring

[markeggleston at gcc dot gnu.org]

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

--- Comment #13 from markeggleston at gcc dot gnu.org ---
The test case in comment 0 is fixed by:

trans-array.c

@ -3638,8 +3638,11 @@ gfc_conv_array_ref (gfc_se * se, gfc_array_ref * ar,
gfc_expr *expr,
   /* Handle scalarized references separately.  */
   if (ar->type != AR_ELEMENT)
 {
-  gfc_conv_scalarized_array_ref (se, ar);
-  gfc_advance_se_ss_chain (se);
+  if (se->ss)
+   {
+ gfc_conv_scalarized_array_ref (se, ar);
+ gfc_advance_se_ss_chain (se);
+   }
   return;
 }

make -j 8 check-fortran does not produce any additional test case failures on
x86_64.

The test case in comment 7 still produces the same ICE.

[Bug fortran/95398] ICE on invalid code

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #5 from markeggleston at gcc dot gnu.org ---
Committed to master and backported to gcc-10.

[Bug fortran/95882] [9/10/11 Regression] ICE in gfc_get_derived_type, at fortran/trans-types.c:2729

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED

--- Comment #6 from markeggleston at gcc dot gnu.org ---
committed and backported.

[Bug fortran/96486] get_environment_variable crashes for environment variables that are empty strings

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #32 from markeggleston at gcc dot gnu.org ---
Committed to master and backported to gcc-10 and gcc-9.

For F2018 conformance see PR96583.

[Bug fortran/96436] -std=f2003 -pedantic rejects valid f0.d edit descriptor

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from markeggleston at gcc dot gnu.org ---
Committed to master.

[Bug fortran/96585] New: Fortran 2018 changes to get_command_argument

[markeggleston at gcc dot gnu.org]

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

Bug ID: 96585
   Summary: Fortran 2018 changes to get_command_argument
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markeggleston at gcc dot gnu.org
Blocks: 85836
  Target Milestone: ---

Fortran 2003 and 2008:

NUMBER Shall be a scalar of type INTEGER and of default kind, NUMBER ≥ 0
VALUE(Optional) Shall be a scalar of type CHARACTER and of default kind.
LENGTH(Optional) Shall be a scalar of type INTEGER and of default kind.
STATUS(Optional) Shall be a scalar of type INTEGER and of default kind.

Optional arguments are intent(out)

Fortran 2018:

NUMBER Shall be a scalar of type INTEGER and of default kind, NUMBER ≥ 0
VALUE(Optional) Shall be a scalar of type CHARACTER and of default kind.
LENGTH(Optional) shall be a scalar of type integer with a decimal exponent
range of at least four
STATUS(Optional) shall be a scalar of type integer with a decimal exponent
range of at least four
ERRMSG (optional) shall be a default character scalar. It is assigned a
processor-dependent explanatory message if the optional argument STATUS is, or
would be if
present, assigned a positive value. Otherwise, it is unchanged.

Optional arguments are intent(out) except ERRMSG which is intent(inout)

---

Arguments LENGTH and STATUS should only be accepted with types other than
default kind if -std-f2018 or-std-gnu, integer(1) should be treated the same
way it is treated for -std=f2003 and -std=f2008.  Use of ERRMSG should only be
allowed with -std=f2018 and -std=gnu.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836
[Bug 85836] [meta-bug] Fortran 2018 support

[Bug fortran/96584] New: f2018 changes to get_command

[markeggleston at gcc dot gnu.org]

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

Bug ID: 96584
   Summary: f2018 changes to get_command
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markeggleston at gcc dot gnu.org
Blocks: 85836
  Target Milestone: ---

Fortran 2003 and Fortran 2008:

COMMAND(Optional) shall be of type CHARACTER and of default kind.
LENGTH (Optional) Shall be of type INTEGER and of default kind.
STATUS(Optional) Shall be of type INTEGER and of default kind.

all are intent(out)

Fortran 2018:

COMMAND(Optional) shall be of type CHARACTER and of default kind.
LENGTH (Optional) shall be scalar of type integer with a decimal exponent range
of at least four
STATUS(Optional) shall be scalar of type integer with a decimal exponent range
of at least four
ERRMSG (optional) shall be a default character scalar.  It is assigned a
processor-dependent explanatory message if the command retrieval fails.
Otherwise, it is unchanged.

all are intent(out) except ERRMSG which is intent(inout)

ERRMSG is new an is not currently supported.
---

-std=f2003 and -std=f2008

gfortran 11.0 currently correctly rejects arguments command and length with
types other than default integer

-std=f2018

gfortran 11.0 currently correctly rejects arguments command and length with
types other than default integer


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836
[Bug 85836] [meta-bug] Fortran 2018 support

[Bug fortran/96583] New: F2018 changes to get_environment_variable

[markeggleston at gcc dot gnu.org]

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

Bug ID: 96583
   Summary: F2018 changes to get_environment_variable
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markeggleston at gcc dot gnu.org
Blocks: 85836
  Target Milestone: ---

Fortran 2003 and Fortran 2008:

Arguments LENGTH and STATUS shall be default integer scalars.

Fortran 2018:

Arguments LENGTH and STATUS shall be a scalars of type integer with a decimal
exponent range of at least four.

New argument:

ERRMSG (optional) shall be a default character scalar. It is an INTENT (INOUT)
argument. It is assigned a processor-dependent explanatory message if the
optional argument STATUS is, or would be if present, assigned a positive value.
Otherwise, it is unchanged. Not currently supported by gfortran 11.

---

For -std=f2003 and -std=f2008 LENGTH and STATUS arguments should be rejected if
they are not default integer scalars, gfortran 11 produces "type mismatch in
argument" error messages.

For -std=f2018 and -std=gnu LENGTH and STATUS arguments should only be rejected
if the is integer(1).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836
[Bug 85836] [meta-bug] Fortran 2018 support

[Bug fortran/96580] New: F2018 changes to date_and_time intrinsics

[markeggleston at gcc dot gnu.org]

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

Bug ID: 96580
   Summary: F2018 changes to date_and_time intrinsics
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markeggleston at gcc dot gnu.org
Blocks: 85836
  Target Milestone: ---

Prior to Fortran 2018:

VALUES (optional) shall be a rank-one default integer array. It is an INTENT
(OUT) argument. Its size shall be at least 8.

Fortran 2018:

VALUES (optional) shall be a rank-one array of type integer with a decimal
exponent range of at least four. It is an INTENT (OUT) argument. Its size shall
be at least 8.

For -std=f2008 and earlier arrays of integer type of other than default kind
should be rejected as the value argument. Currently 11.0 compiles with integers
of kind other than default including integer(1).

For -std=f2018 and -std=gnu arrays of integer type with kinds 2 and greater are
allowed, integer(1) is rejected.

Currently there are issues with gfortran manual documentation:

- minimum sizes are specified for the character arguments date, time and zones,
the standards do not specify a minimum size and gfortran allows smaller sizes.
- the VALUES argument is described as (Optional) The type shall be INTEGER(8),
which implies a scalar integer of kind 8.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836
[Bug 85836] [meta-bug] Fortran 2018 support

[Bug fortran/96569] New: F2018 add EX edit descriptor support

[markeggleston at gcc dot gnu.org]

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

Bug ID: 96569
   Summary: F2018 add EX edit descriptor support
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markeggleston at gcc dot gnu.org
Blocks: 85836
  Target Milestone: ---

New descriptor introduced with Fortran 2018. 

The EX edit descriptor produces an output field in the form of a
hexadecimal-significand number.

Examples:

Internal value  Edit descriptor  Possible output with sign suppress in effect
1.375EX0.10X1.6P+0
−15.625  EX14.4E3 -0X1.F400P+003
1048580.0EX0.00X1.4P+20
2.375EX0.1 0X2.6P+0

See the standard for full details.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836
[Bug 85836] [meta-bug] Fortran 2018 support

[Bug fortran/96436] -std=f2003 -pedantic rejects valid f0.d edit descriptor

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |markeggleston at gcc 
dot gnu.org
 CC||markeggleston at gcc dot 
gnu.org

--- Comment #2 from markeggleston at gcc dot gnu.org ---
Not so simple.

Zero width format descriptors are valid:

f - Fortran 95 and later
g - Fortran 2008 and later
d, e, en, es and ex - Fortran 2018

Note: ex is not yet implemented.

There are also related compile time errors:

5 | print "(d0.2)", 3.
  | 1
Error: Fortran 2018: positive width required at (1)

and corresponding runtime errors:

Fortran runtime error: Positive width required in format
(d0.2)
  ^

I currently have:

--- libgfortran/io/format.c ---
index 3be861fb19c..0959b3d8f84 100644
@@ -617,6 +617,7 @@ parse_format_list (st_parameter_dt *dtp, bool *seen_dd)
   int repeat;
   format_data *fmt = dtp->u.p.fmt;
   bool seen_data_desc = false;
+  int standard;

   head = tail = NULL;

@@ -929,7 +930,14 @@ parse_format_list (st_parameter_dt *dtp, bool *seen_dd)
   /* Processing for zero width formats.  */
   if (u == FMT_ZERO)
{
- if (notification_std (GFC_STD_F2008) == NOTIFICATION_ERROR
+  if (t == FMT_F)
+   standard = GFC_STD_F95;
+ else if (t == FMT_G)
+   standard = GFC_STD_F2008;
+ else
+   standard = GFC_STD_F2018;
+
+ if (notification_std (standard) == NOTIFICATION_ERROR
  || dtp->u.p.mode == READING)
{
  fmt->error = zero_width;

I'm currently working on the test cases, "(d0.2)" indicates there are
additional changes required. I'm now checking e, en and es descriptors.

[Bug fortran/96486] get_environment_variable fails for zero-length values

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #12 from markeggleston at gcc dot gnu.org ---
(In reply to kargl from comment #6)
> I do note there are other problems with get_environment_variable.

It looks to me that this intrinsic supports the Fortran 2003 standard. Changes
were introduced with the Fortran 2018 and support has not yet been implemented.

> 
> 1) Neither length nor status can be integer(1).  gfortran should issue
>an error.

Fortran 2003 has default kind for these arguments.

> 
> 2) Fortran 2018 has added an optional errmsg argument.  This is not
>supported.
> 
> 3) gfortran is issuing errors that don't make sence (to me).
> 
> program foo
>integer( 1) i01
>integer( 2) i02
>integer( 4) i04
>integer( 8) i08
> #ifdef __GFC_INT_16__
>integer(16) i16
> #endif
>character(len=20) name
> 
>print '(A,I0)', 'range(i01) = ', range(i01)
>print '(A,I0)', 'range(i02) = ', range(i02)
>print '(A,I0)', 'range(i04) = ', range(i04)
>print '(A,I0)', 'range(i08) = ', range(i08)
> #ifdef __GFC_INT_16__
>print '(A,I0)', 'range(i16) = ', range(i16)
> #endif
> 
>name = ''
>! Although valid Fortran, this should probably raise a warning.
>call get_environment_variable(name);
> 
>name = 'FOO'
>call get_environment_variable(name,length=i01);  ! Should be an error
>call get_environment_variable(name,length=i02);  ! Should be ok
>call get_environment_variable(name,length=i04);  ! Should be ok
>call get_environment_variable(name,length=i08);  ! Should be ok
> #ifdef __GFC_INT_16__
>call get_environment_variable(name,length=i16);  ! Should be ok
> #endif
> 
> end program foo
> 
> mobile:kargl[256] gfcx -o z a.F90 && ./z
> a.F90:29:45:
> 
>29 |call get_environment_variable(name,length=i01);  ! Should be an
> error
>   | 1
> Error: In call to 'get_environment_variable' at (1), type mismatch in
> argument length'; pass 'INTEGER(1)' to 'INTEGER(4)'
> a.F90:30:45:
> 
>30 |call get_environment_variable(name,length=i02);
>   | 1
> Error: In call to 'get_environment_variable' at (1), type mismatch in
> argument length'; pass 'INTEGER(2)' to 'INTEGER(4)'
> a.F90:32:45:
> 
>32 |call get_environment_variable(name,length=i08);
>   | 1
> Error: In call to 'get_environment_variable' at (1), type mismatch in
> argument length'; pass 'INTEGER(8)' to 'INTEGER(4)'

The mismatch errors are consistent with Fortran 2003 support.

I think these issues should be in a separate PR for Fortran 2018 support.

[Bug fortran/53298] ICE in gfc_conv_scalarized_array_ref for ARRAY + substring

[markeggleston at gcc dot gnu.org]

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

--- Comment #12 from markeggleston at gcc dot gnu.org ---
Fixed the ICE in comment 5.  I completely missed the "a different ICE"...

More investigation required.

[Bug fortran/96319] Don't warn for LOGICAL kind conversion with -Wconversion

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from markeggleston at gcc dot gnu.org ---
Committed to master. The problem also occurs with gcc-10 but not gcc-9 or 8 so
it has been backported to gcc-10.

[Bug fortran/53298] ICE in gfc_conv_scalarized_array_ref for ARRAY + substring

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from markeggleston at gcc dot gnu.org ---
Committed to master.

[Bug fortran/45424] [F08] Add IS_CONTIGUOUS intrinsic

[markeggleston at gcc dot gnu.org]

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

Bug 53298 Summary: ICE in gfc_conv_scalarized_array_ref for ARRAY + substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53298

   What|Removed |Added

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

[Bug fortran/56818] [meta-bug] fortran-dev bugs

[markeggleston at gcc dot gnu.org]

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

Bug 53298 Summary: ICE in gfc_conv_scalarized_array_ref for ARRAY + substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53298

   What|Removed |Added

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

[Bug fortran/95612] [9/10/11 Regression] ICE in gfc_check_pointer_assign, at fortran/expr.c:4274

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||markeggleston at gcc dot 
gnu.org
 Status|NEW |RESOLVED

--- Comment #6 from markeggleston at gcc dot gnu.org ---
Committed to master and backported to gcc 10 & 9.

[Bug fortran/96038] Confirming implicitly type parameter causes an invalid error

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 CC||markeggleston at gcc dot 
gnu.org

--- Comment #2 from markeggleston at gcc dot gnu.org ---
committed to master

[Bug fortran/95981] ICE in gfc_find_array_ref(): No ref found

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from markeggleston at gcc dot gnu.org ---
committed to master

[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from markeggleston at gcc dot gnu.org ---
Committed to master.

[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #13 from markeggleston at gcc dot gnu.org ---
Regarding patch in comment 7 and test case in comment 11.

It seems to me that it is only necessary to to check for the dummy attribute:

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 223de91..730d11105bd 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -12918,8 +12918,7 @@ resolve_fl_variable (gfc_symbol *sym, int mp_flag)
   else if (sym->attr.external)
gfc_error ("External %qs at %L cannot have an initializer",
   sym->name, >declared_at);
-  else if (sym->attr.dummy
-   && !(sym->ts.type == BT_DERIVED && sym->attr.intent == INTENT_OUT))
+  else if (sym->attr.dummy)
gfc_error ("Dummy %qs at %L cannot have an initializer",
   sym->name, >declared_at);
   else if (sym->attr.intrinsic)


For the test case from comment 1:

pr45337_1.f90:3:20:

3 | subroutine lengthX(x, i)
  |1
Error: Dummy 'x' at (1) cannot have an initializer
pr45337_1.f90:14:7:

   14 |   use ptrmod
  |   1
Fatal Error: Cannot open module file 'ptrmod.mod' for reading at (1): No such
file or directory
compilation terminated.


and for the test case from comment 11:

pr45337_2.f90:7:16:

7 |   subroutine x(a, b, c)
  |1
Error: Dummy 'a' at (1) cannot have an initializer
pr45337_2.f90:7:19:

7 |   subroutine x(a, b, c)
  |   1
Error: Dummy 'b' at (1) cannot have an initializer


Regarding comments 8, 9 and 10.  I think the the error messages are sufficient
as is.

No additional test failures encountered when running make check-fortran.

[Bug fortran/52279] Fortran translation issues

[markeggleston at gcc dot gnu.org]

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

--- Comment #5 from markeggleston at gcc dot gnu.org ---
(In reply to markeggleston from comment #4)
> Regarding comment 2.
> 
> Using -fallow-invalid-boz results in an ICE. I'll create a new PR.

Not true, tried it on the wrong file and jumped to the wrong conclusion.

[Bug fortran/52279] Fortran translation issues

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #4 from markeggleston at gcc dot gnu.org ---
Regarding comment 2.

Using -fallow-invalid-boz results in an ICE. I'll create a new PR.

[Bug fortran/95584] ICE in generic_correspondence, at fortran/interface.c:1260

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #3 from markeggleston at gcc dot gnu.org ---
committed to master, although the problem exists with gcc-10, 9 and 8 it isn't
being backported. (https://gcc.gnu.org/pipermail/fortran/2020-June/054659.html)

[Bug fortran/95446] False positive for optional arguments of elemental procedure

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from markeggleston at gcc dot gnu.org ---
committed to master.

[Bug fortran/95829] Bogus error with additional blanks in type(*)

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED

--- Comment #6 from markeggleston at gcc dot gnu.org ---
Committed to master and backported.

[Bug fortran/95586] ICE in gfc_validate_kind, at fortran/trans-types.c:773

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from markeggleston at gcc dot gnu.org ---
Committed to master.

[Bug fortran/95708] [9/10/11 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13002

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #3 from markeggleston at gcc dot gnu.org ---
Committed to master.

[Bug fortran/95585] ICE in gfc_check_reshape, at fortran/check.c:4751

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org

--- Comment #3 from markeggleston at gcc dot gnu.org ---
Committed to master.

[Bug fortran/42693] Missing gcc-internal-format on messages from gfc_arith_error

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from markeggleston at gcc dot gnu.org ---
Committed to master.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[markeggleston at gcc dot gnu.org]

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

Bug 42693 Summary: Missing gcc-internal-format on messages from gfc_arith_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42693

   What|Removed |Added

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

[Bug fortran/52274] [Meta-bug] Fortran translation related issues: Typos and more

[markeggleston at gcc dot gnu.org]

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

Bug 42693 Summary: Missing gcc-internal-format on messages from gfc_arith_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42693

   What|Removed |Added

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

[Bug fortran/93026] gfortran.dg/goacc/finalize-1.f – FAILs since r279626

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
 CC||markeggleston at gcc dot 
gnu.org

--- Comment #3 from markeggleston at gcc dot gnu.org ---
Fixed by the fix for PR94090.

New test case committed to master and backported to gcc-10.

[Bug fortran/92993] [8/9 Regression] ICE in maybe_canonicalize_comparison_1, at fold-const.c:8845

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #9 from markeggleston at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #6)
> (In reply to anlauf from comment #4)
> > The testcase in comment#0 compiles for me with today's master.
> > Has this been fixed accidentally?  Maybe someone can bisect
> > so that one can identify the commit that might be backported
> > to fix the regression.
> 
> This probably was
> 
> https://gcc.gnu.org/g:2298af0800b292f028298c1eaec42fd3033c4b9b
> 
> the fix for PR94090.
> 
> I think this is something that could be backported.

I tried this see:

https://gcc.gnu.org/pipermail/fortran/2020-June/054462.html

It won't be backported to gcc-9 and gcc-8 see:

https://gcc.gnu.org/pipermail/fortran/2020-June/054469.html

[Bug fortran/93814] [9/10/11 Regression] ICE in build_entry_thunks, at fortran/trans-decl.c:2898

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #5 from markeggleston at gcc dot gnu.org ---
I tried out the patch provided by Steve Kargl in comment 3.  It appeared to me
to be OK so I added a test case sent a patch upstream with "OK to commit?".

The patch was not accepted see:
https://gcc.gnu.org/pipermail/fortran/2020-March/054157.html

[Bug fortran/42693] Missing gcc-internal-format on messages from gfc_arith_error

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #4 from markeggleston at gcc dot gnu.org ---
I note from the current code all the strings in gfc_arith_error are enclosed in
_(). Does this mean that this is fixed?

I don't know how to test for message translation so can not confirm.

[Bug fortran/94397] [9/10/11 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #13 from markeggleston at gcc dot gnu.org ---
committed to master and backported

[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org

--- Comment #22 from markeggleston at gcc dot gnu.org ---
committed to master and backported

[Bug fortran/32834] [Meta-bug] 'Fortran 95'-only failures

[markeggleston at gcc dot gnu.org]

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

Bug 50392 Summary: SIGSEGV in gfc_trans_label_assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392

   What|Removed |Added

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

[Bug fortran/20585] [meta-bug] Fortran 2003 support

[markeggleston at gcc dot gnu.org]

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

Bug 39695 Summary: [F03] ProcPtr function results: wrong name in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695

   What|Removed |Added

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

[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from markeggleston at gcc dot gnu.org ---
Committed to master and backported.

[Bug fortran/93497] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7594

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED

--- Comment #9 from markeggleston at gcc dot gnu.org ---
Committed to master and backported to gcc-10 and gcc-9.

[Bug fortran/59107] [8/9/10/11 Regression] Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising.

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #23 from markeggleston at gcc dot gnu.org ---
Commits to master and backported to gcc-10, gcc-9 and gcc-8.

[Bug fortran/92736] [9/10/11 Regression] Error when using a variable from a module in a submodule and its parent module.

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #8 from markeggleston at gcc dot gnu.org ---
This was fixed by Tobias:

https://gcc.gnu.org/g:36c3edb1e39c74e2705efac738a389b5597d9d88

As PR fortran/92736 was not used in the body of the commit message (or
ChangeLog files) this PR was not automatically updated with the commit info.

I'm not precisely sure of the mechanism used to automatically add the commit
info to a PR but preceding change log entries with PR / (both in
the commit message and the ChangeLog files) has worked for me. When I've
omitted PR / it has not worked.

Just needs backporting to gcc-9.

[Bug fortran/93833] [8/9/10/11 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #8 from markeggleston at gcc dot gnu.org ---
As noted by Tobias:

  Patch was submitted
at https://gcc.gnu.org/pipermail/fortran/2020-March/054072.html
  but the new mailing had stripped off the 'text/x-patch' MIME type back then.

Is the patch going to be resubmitted?

[Bug fortran/94397] [9/10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[markeggleston at gcc dot gnu.org]

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

--- Comment #8 from markeggleston at gcc dot gnu.org ---
(In reply to anlauf from comment #7)
> (In reply to markeggleston from comment #6)
> > Thanks Steve.  Should've tried your patch earlier, it is much simpler than
> > mine and I've verified that it works. There was a nagging feeling that my
> > solution was incomplete. I'm happy to add test cases to your patch and send
> > it upstream for approval.
> Any progress?

Unfortunately I was diverted on to working on something else and when I got
back to it I found that two test case failures occurred: pr93484_1.f90 and
pr93484_2.f90 both failing with ICE.  These did not occur when I last checked
the patch.

Thanks for the nudge, I intend to fully investigate today.

[Bug fortran/93498] [9/10 Regression] ICE in gfc_resolve_findloc, at fortran/iresolve.c:1844 since r9-3688-g01ce9e31a02c8039

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||markeggleston at gcc dot 
gnu.org
 Status|NEW |RESOLVED

--- Comment #9 from markeggleston at gcc dot gnu.org ---
Committed to master and backported:

r10-7508-g2c54eab5a302c6da015bb39b1a81f6799e45a650
r9-8441-gb6e546912555c9b9b27bdce516e98546f4cd3d25

[Bug fortran/94030] [8/9/10 Regression] ICE equivalence of an integer and an element of an array of size n

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from markeggleston at gcc dot gnu.org ---
Commits for master and backports:

r10-7507-gbf1f6d8819ade074271df718f01fd3a5a9dc1b82
r9-8440-g514bd32c5273b1b6c3438016faf96ffdd45639ca
r8-10157-g26191cec3421a157f4bafa7760cfd1bc4f90f0e5

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from markeggleston at gcc dot gnu.org ---
r10-7495-g0c9a8a8c1030d072d598880c07f4d6a8d9e7deed committed to master

[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90

[markeggleston at gcc dot gnu.org]

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

--- Comment #12 from markeggleston at gcc dot gnu.org ---
Created attachment 48155
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48155=edit
Proposed fix

Sorry for the duplicate (PR94430) I missed this PR.

The cause of the errors messages is due to most of the code in expr.c
introduced by PR93600 being deleted.

I restored the code, the error went away, however, bessel_5_redux.f90 resulted
in an ICE.

When this bit of PR94246 is put back:

@@ -2314,9 +2296,8 @@ scalarize_intrinsic_call (gfc_expr *e, bool init_flag)
   gfc_constructor_base ctor;
   gfc_constructor *args[5] = {};  /* Avoid uninitialized warnings.  */
   gfc_constructor *ci, *new_ctor;
-  gfc_expr *expr, *old;
+  gfc_expr *expr, *old, *p;
   int n, i, rank[5], array_arg;
-  int errors = 0;

   if (e == NULL)
 return false;
@@ -2384,8 +2365,6 @@ scalarize_intrinsic_call (gfc_expr *e, bool init_flag)
   n++;
 }

-  gfc_get_errors (NULL, );
-
   /* Using the array argument as the master, step through the array
  calling the function for each element and advancing the array
  constructors together.  */
@@ -2419,8 +2398,12 @@ scalarize_intrinsic_call (gfc_expr *e, bool init_flag)
   /* Simplify the function calls.  If the simplification fails, the
 error will be flagged up down-stream or the library will deal
 with it.  */
-  if (errors == 0)
-   gfc_simplify_expr (new_ctor->expr, 0);
+  p = gfc_copy_expr (new_ctor->expr);
+
+  if (!gfc_simplify_expr (p, init_flag))
+   gfc_free_expr (p);
+  else
+   gfc_replace_expr (new_ctor->expr, p);

   for (i = 0; i < n; i++)
if (args[i])

bessel_5_redux.f90.

I think

  if (errors == 0)
gfc_simplify_expr (new_ctor->expr, 0);

caused the ICE.

I'm preparing the patch for upstream, its commit message needs updating not
that I have a PR number.

[Bug fortran/94430] New: [10 Regression] Test case failures

[markeggleston at gcc dot gnu.org]

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

Bug ID: 94430
   Summary: [10 Regression] Test case failures
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markeggleston at gcc dot gnu.org
  Target Milestone: ---

Test failures:

FAIL: gfortran.dg/pr93365.f90   -O0  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/pr93365.f90   -O1  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/pr93365.f90   -O2  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/pr93365.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal
compiler error)
FAIL: gfortran.dg/pr93365.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for
excess errors)
FAIL: gfortran.dg/pr93365.f90   -O3 -g  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/pr93365.f90   -Os  (internal compiler error)
FAIL: gfortran.dg/pr93365.f90   -Os  (test for excess errors)
FAIL: gfortran.dg/pr93600_1.f90   -O  (internal compiler error)
FAIL: gfortran.dg/pr93600_1.f90   -O   (test for errors, line 6)
FAIL: gfortran.dg/pr93600_1.f90   -O   (test for errors, line 7)
FAIL: gfortran.dg/pr93600_1.f90   -O  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -O0  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -O1  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -O2  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (internal
compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for
excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -O3 -g  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/pr93600_2.f90   -Os  (internal compiler error)
FAIL: gfortran.dg/pr93600_2.f90   -Os  (test for excess errors)

These started with
https://gcc.gnu.org/g:7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65

[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[markeggleston at gcc dot gnu.org]

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

--- Comment #6 from markeggleston at gcc dot gnu.org ---
(In reply to kargl from comment #5)
> (In reply to markeggleston from comment #4)
> > The compilation error reported is due this change in PR93484:
> > 
> > --- a/gcc/fortran/match.c
> > +++ b/gcc/fortran/match.c
> > @@ -,9 +,9 @@ gfc_match_type_spec (gfc_typespec *ts)
> >  
> >  found:
> >  
> > -  m = gfc_match_init_expr ();
> > +  m = gfc_match_expr ();
> > 
> > Changing it back causes test cases ISO_Fortran_binding_11.f90 and
> > pr78033.f90 to fail.
> > 
> > If "kind=" is found gfc_match_init_expr () should be used and when it is
> > not gfc_match_expr ().
> > 
> > I'm checking a suitable test case and will have a patch ready soon.
> 
> The patch in comment #3 likely is the correct patch.  When in the
> specification part of a scoping unit, the above change is needed to
> distinguish REAL(kind(1.)) from REAL(1.1, kind(1.)).  In the former,
> we have a type and kind(1.) must be an initialization expression
> (see comment 3 or 4 lines down).  In the latter case, we have the
> intrinsic subprogram, and simply return MATCH_NO or MATCH_ERROR.
> 
> -- 
> steve

Thanks Steve.  Should've tried your patch earlier, it is much simpler than mine
and I've verified that it works. There was a nagging feeling that my solution
was incomplete. I'm happy to add test cases to your patch and send it upstream
for approval.

[Bug fortran/94397] [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error since r10-7369-gc38daa7976886a59

[markeggleston at gcc dot gnu.org]

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

--- Comment #4 from markeggleston at gcc dot gnu.org ---
The compilation error reported is due this change in PR93484:

--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -,9 +,9 @@ gfc_match_type_spec (gfc_typespec *ts)

 found:

-  m = gfc_match_init_expr ();
+  m = gfc_match_expr ();

Changing it back causes test cases ISO_Fortran_binding_11.f90 and pr78033.f90
to fail.

If "kind=" is found gfc_match_init_expr () should be used and when it is not
gfc_match_expr ().

I'm checking a suitable test case and will have a patch ready soon.

[Bug fortran/94030] [8/9/10 Regression] ICE equivalence of an integer and an element of an array of size n

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #3 from markeggleston at gcc dot gnu.org ---
A patch from Steve Kargl was sent to the fortran mailing list, (see
https://gcc.gnu.org/pipermail/fortran/2020-March/054130.html) without reference
to any PR.

It appeared to be related to this PR. I have verified the patch and also
checked it with the test case in the original report.

The result is:

5 |   equivalence (i, arr(1))
  | 1
Error: Array 'arr' at (1) with non-constant bounds cannot be an EQUIVALENCE
object

The above is much better than an ICE. Thanks Steve.

I will add test cases to the patch and will send it upstream for approval for
master and backports to gcc-8 and gcc-9.

[Bug fortran/93365] KIND inquiry and zero-sized array generates wrong code

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org
 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from markeggleston at gcc dot gnu.org ---
Fixed as a side affect of fixing PR93600.

[Bug fortran/93484] [8/9/10 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1120 since r7-4028-g87c9fca50cbe7ca9

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from markeggleston at gcc dot gnu.org ---
committed to master and backported to gcc-9 and gcc-8

[Bug fortran/93600] [10 Regression] ICE in gfc_match_assignment, at fortran/match.c:1366/1340

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from markeggleston at gcc dot gnu.org ---
commit https://gcc.gnu.org/g:b0d84ecc55f3ea86764b119040c5ffde36cd0524

[Bug fortran/93792] [10 Regression] ICE in gfc_code2string, at fortran/misc.c:281

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED

--- Comment #4 from markeggleston at gcc dot gnu.org ---
Committed as obvious https://gcc.gnu.org/g:a2ec7c4aafbc

[Bug fortran/93832] [8/9/10 Regression] ICE in gfc_convert_to_structure_constructor, at fortran/primary.c:3100

[markeggleston at gcc dot gnu.org]

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

--- Comment #5 from markeggleston at gcc dot gnu.org ---
Created attachment 47968
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47968=edit
Incomplete patch

Please find att an incomplete patch.

program p
  type t
character :: a
integer :: b
integer :: c(t(1, 2, 3))
  end type
end

results in:

5 | integer :: c(t(1, 2, 3))
  | 1
Error: Expression at (1) must be of INTEGER type, found DERIVED
pr93832_2.f03:7:19:

5 | integer :: c(t(1, 2, 3))
  |   1
Error: Cannot convert INTEGER(4) to CHARACTER(1) at (1)

instead of an ICE

However the following:

program p
  type t
character :: a
integer :: b
integer :: c(t())
  end type
end

results in

5 | integer :: c(t())
  |  1
Error: No initializer for component 'a' given in the structure constructor at
(1)

I had hoped to report "Error: Expression at (1) must be of INTEGER type, found
DERIVED", the closest I managed was "Error: Expression at (1) must be of
INTEGER type, found UNKNOWN". Unfortunately that also resulted in duplicate and
spurious error messages.

As it stands the patch has the following side affect when running check-fortran

FAIL: gfortran.dg/typebound_call_25.f90   -O  (internal compiler error)
FAIL: gfortran.dg/typebound_call_25.f90   -O   (test for errors, line 32)
FAIL: gfortran.dg/typebound_call_25.f90   -O   (test for errors, line 33)
FAIL: gfortran.dg/typebound_call_25.f90   -O  (test for excess errors)
FAIL: gfortran.dg/typebound_proc_31.f90   -O  (internal compiler error)
FAIL: gfortran.dg/typebound_proc_31.f90   -O  (test for excess errors)
FAIL: gfortran.dg/typebound_proc_32.f90   -O  (internal compiler error)
FAIL: gfortran.dg/typebound_proc_32.f90   -O  (test for excess errors)


typebound_proc_31.f90:

! { dg-do compile }
!
! PR 59450: [OOP] ICE for type-bound-procedure expression in module procedure
interface
!
! Contributed by 

module classes

  implicit none

  type :: base_class
   contains
 procedure, nopass :: get_num
  end type

contains

  pure integer function get_num()
  end function

  function get_array( this ) result(array)
class(base_class), intent(in) :: this
integer, dimension( this%get_num() ) :: array
  end function

end module

produces this ICE:
f951: internal compiler error: check_restricted(): Unknown expression type
0x6c6ede gfc_report_diagnostic
../../gcc/gcc/fortran/error.c:782
0x6c85ca gfc_internal_error(char const*, ...)
../../gcc/gcc/fortran/error.c:1402
0x6cb6db check_restricted
../../gcc/gcc/fortran/expr.c:3428
0x6964b4 resolve_array_bound
../../gcc/gcc/fortran/array.c:378
0x697180 gfc_resolve_array_spec(gfc_array_spec*, int)
../../gcc/gcc/fortran/array.c:424
0x7406fe resolve_symbol
../../gcc/gcc/fortran/resolve.c:15832
0x7400c1 resolve_symbol
../../gcc/gcc/fortran/resolve.c:15247
0x75c6ab do_traverse_symtree
../../gcc/gcc/fortran/symbol.c:4147
0x742ccc resolve_types
../../gcc/gcc/fortran/resolve.c:17121
0x73e4dc gfc_resolve(gfc_namespace*)
../../gcc/gcc/fortran/resolve.c:17236
0x726aa4 gfc_parse_file()
../../gcc/gcc/fortran/parse.c:6447
0x77206f gfc_be_parse_file
../../gcc/gcc/fortran/f95-lang.c:210
Please submit a full bug report,

patch applied to master at f1a681a174cdfb82e62c246d6f4add9a25fc2e43

At this point I'm stuck and I currently don't have the knowledge to fix this.

[Bug fortran/94030] New: ICE equivalence of an integer and an element of an array of size n

[markeggleston at gcc dot gnu.org]

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

Bug ID: 94030
   Summary: ICE equivalence of an integer and an element of an
array of size n
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markeggleston at gcc dot gnu.org
  Target Milestone: ---

subroutine f(n)
  integer :: n
  integer :: arr(n)
  integer :: i
  equivalence (i, arr(1))
end

Using 9.2 release:

f951: internal compiler error: get_mpz(): Not an integer constant
0x657561 gfc_internal_error(char const*, ...)
../../gcc/gcc/fortran/error.c:1363
0x717f1b get_mpz
../../gcc/gcc/fortran/trans-common.c:782
0x717f1b element_number
../../gcc/gcc/fortran/trans-common.c:813
0x717f1b calculate_offset
../../gcc/gcc/fortran/trans-common.c:871
0x7180fa new_condition
../../gcc/gcc/fortran/trans-common.c:905
0x7180fa add_condition
../../gcc/gcc/fortran/trans-common.c:946
0x7180fa find_equivalence
../../gcc/gcc/fortran/trans-common.c:989
0x7180fa add_equivalences
../../gcc/gcc/fortran/trans-common.c:1022
0x719887 finish_equivalences
../../gcc/gcc/fortran/trans-common.c:1229
0x719887 gfc_trans_common(gfc_namespace*)
../../gcc/gcc/fortran/trans-common.c:1297
0x7242af gfc_generate_function_code(gfc_namespace*)
../../gcc/gcc/fortran/trans-decl.c:6670
0x6b24b0 translate_all_program_units
../../gcc/gcc/fortran/parse.c:6134
0x6b24b0 gfc_parse_file()
../../gcc/gcc/fortran/parse.c:6367
0x6fbe3f gfc_be_parse_file
../../gcc/gcc/fortran/f95-lang.c:204
Please submit a full bug report,

Version info for compiler:
Using built-in specs.
COLLECT_GCC=/home/markeggleston/t3/install-gcc/release-9.2/bin/gfortran
COLLECT_LTO_WRAPPER=/home/markeggleston/t3/install-gcc/release-9.2/bin/../libexec/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/release-9.2
--enable-languages=fortran --disable-nls --disable-bootstrap
Thread model: posix
gcc version 9.2.0 (GCC) 

Also occurs with builds of 8.1, 8.2, 8.3, 9.1 and the Debian built compiler GNU
Fortran (Debian 6.3.0-18+deb9u1) 6.3.0 20170516

[Bug fortran/93832] [8/9/10 Regression] ICE in gfc_convert_to_structure_constructor, at fortran/primary.c:3100

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #3 from markeggleston at gcc dot gnu.org ---
Using the patch comment 2 and the example program:

program p
   type t
  character :: a
  integer :: b
  integer :: c(t(1))
   end type
   type(t) :: z = t('a', 2, [3])
end

5 |   integer :: c(t(1))
  |1
Error: No initializer for component 'b' given in the structure constructor at
(1)

Adding a second initializer:

program p
   type t
  character :: a
  integer :: b
  integer :: c(t(1, "rubbish"))
   end type
   type(t) :: z = t('a', 2, [3])
end

5 |   integer :: c(t(1))
  |1
Error: No initializer for component 'c' given in the structure constructor at
(1)

There is no reporting of incompatible types i.e, integer(4) to character(1) and
character(7) to integer(4).

Finally if all initializers are given:

program p
   type t
  character :: a
  integer :: b
  integer :: c(t(1, "rubbish", 7.5))
   end type
   type(t) :: z = t('a', 2, [3])
end

The result is an ICE without a call stack:

gfortran: internal compiler error: Segmentation fault signal terminated program
f951
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

The declaration of component c of the derived type t is intended to be an
array, if it is then I would expect the use of derived type to be illegal.

An error is given if a different derived type is used:

program p
   type t2
   end type
   type t
  character :: a
  integer :: b
  integer :: c(t2())
   end type
   type(t) :: z = t('a', 2, [3])
end


7 |   integer :: c(t2())
  |   1
Error: Expression at (1) must be of INTEGER type, found DERIVED

This is the error or something like it that should be reported when the derived
type t is used as the array spec.

Where the type t constructor is used in the declaration of type t I'm having
difficulty in stopping it from constructing a structure and consequently
resulting in an ICE.

[Bug fortran/93835] [9/10 Regression] ICE in simplify_findloc_nodim, at fortran/simplify.c:5513

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from markeggleston at gcc dot gnu.org ---
committed

[Bug fortran/93604] [10 Regression] ICE in gfc_conv_constant_to_tree, at fortran/trans-const.c:372

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED

--- Comment #3 from markeggleston at gcc dot gnu.org ---
Committed to master.

[Bug fortran/93835] [9/10 Regression] ICE in simplify_findloc_nodim, at fortran/simplify.c:5513

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #4 from markeggleston at gcc dot gnu.org ---
After applying the patch in comment 2 the ICE no longer occurs, however, it
reveals an error when using the shape intrinsic with the findloc intrinsic.

program test
  print *, findloc(shape([1, 2, 3, 4]), 4)
end program

produces:

   0

i.e. 4 is not found in the array returned by shape.

shape does indeed return [ 4 ] but the expression representing the array does
not have a shape defined. This is why it is necessary to check for the
existence of shape in the original patch.

Adding a shape to the result expression addressed the issue and also means that
the original is not required:

diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 613fdafd1a6..59afb239af5 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -7228,6 +7228,8 @@ gfc_simplify_shape (gfc_expr *source, gfc_expr *kind)
 return NULL;

   result = gfc_get_array_expr (BT_INTEGER, k, >where);
+  result->shape = gfc_get_shape (1);
+  mpz_init (result->shape[0]);

   if (source->rank == 0)
 return result;
@@ -7284,6 +7286,8 @@ gfc_simplify_shape (gfc_expr *source, gfc_expr *kind)
   if (t)
 gfc_clear_shape (shape, source->rank);

+  mpz_set_si (result->shape[0], source->rank);
+  
   return result;
 }

There is some tidying up to do as pr77351.f90 now produces one error instead of
two:

4 |print *, any(shape(z) /= [4,1])  ! { dg-error "shape for elemental
binary" }
  |1  2
Error: Shapes for operands at (1) and (2) are not conformable

verses:

4 |print *, any(shape(z) /= [4,1])  ! { dg-error "shape for elemental
binary" }
  |1
Error: Different shape for elemental binary operation at (1) on dimension 1 (1
and 2)
pr77351.f90:4:16:

4 |print *, any(shape(z) /= [4,1])  ! { dg-error "shape for elemental
binary" }
  |1
Error: Array operands are incommensurate at (1)

Final patch in preparation.

[Bug fortran/93827] fails to initialize logical variable

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |INVALID

--- Comment #1 from markeggleston at gcc dot gnu.org ---
Unlike C the initialisation of a local variable at declaration only occurs once
on the first entry to the subroutine.

See http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html see the section on locally
initialised variables.

[Bug fortran/93714] [8/9/10 Regression] ICE in gfc_check_same_strlen, at fortran/check.c:1253

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from markeggleston at gcc dot gnu.org ---
Committed to master and backported to gcc 8 and gcc 9 branches.

[Bug fortran/93814] [9/10 Regression] ICE in build_entry_thunks, at fortran/trans-decl.c:2898

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-19
 CC||markeggleston at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from markeggleston at gcc dot gnu.org ---
Confirmed.

[Bug fortran/93601] [10 Regression] ICE: Invalid expression in gfc_element_size

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED

--- Comment #3 from markeggleston at gcc dot gnu.org ---
Committed.

[Bug fortran/93603] [10 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1201

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |FIXED

--- Comment #3 from markeggleston at gcc dot gnu.org ---
Committed.

[Bug fortran/93580] [9/10 Regression] ICE in gfc_validate_kind(): Got bad kind

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from markeggleston at gcc dot gnu.org ---
Committed for master and gcc 9 branch.

[Bug fortran/93579] [9/10 Regression] ICE in gfc_conv_substring_expr, at fortran/trans-expr.c:8587

[markeggleston at gcc dot gnu.org]

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

Bug 93580 Summary: [9/10 Regression] ICE in gfc_validate_kind(): Got bad kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93580

   What|Removed |Added

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

[Bug fortran/93714] [8/9/10 Regression] ICE in gfc_check_same_strlen, at fortran/check.c:1253

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #2 from markeggleston at gcc dot gnu.org ---
Patch in comment 1 produces:

z1.f90 -> pr93714_1.f90

pr93714_1.f90:3:4:

3 |character, pointer :: b => a
  |1
Error: Unclassifiable statement at (1)
pr93714_1.f90:2:13:

2 |character((1.)) :: a
  | 1
Error: Expression at (1) must be of INTEGER type, found REAL

z2.f90 -> pr93714_1.f90

pr93714_2.f90:3:4:

3 |character(:), pointer :: b => a
  |1
Error: Unclassifiable statement at (1)
pr93714_2.f90:2:13:

2 |character((9.)), target :: a
  | 1
Error: Expression at (1) must be of INTEGER type, found REAL

Can do better than "Unclassifiable statement".

Moving the check for lvalue being a character to after the handling of pointer
and target attributes:

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index a9698c3e3d2..79e00b4112a 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4222,13 +4222,6 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr
*rvalue,
   if (rvalue->expr_type == EXPR_NULL)
 return true;

-  if (lvalue->ts.type == BT_CHARACTER)
-{
-  bool t = gfc_check_same_strlen (lvalue, rvalue, "pointer assignment");
-  if (!t)
-   return false;
-}
-
   if (rvalue->expr_type == EXPR_VARIABLE && is_subref_array (rvalue))
 lvalue->symtree->n.sym->attr.subref_array_pointer = 1;

@@ -4284,6 +4277,13 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr
*rvalue,
}
 }

+  if (lvalue->ts.type == BT_CHARACTER)
+{
+  bool t = gfc_check_same_strlen (lvalue, rvalue, "pointer assignment");
+  if (!t)
+   return false;
+}
+
   if (is_pure && gfc_impure_variable (rvalue->symtree->n.sym))
 {
   gfc_error ("Bad target in pointer assignment in PURE "

and omitting Steve Kargl's patch results in:

pr93714_1.f90:3:31:

3 |character, pointer :: b => a
  |   1
Error: Pointer assignment target in initialization expression does not have the
TARGET attribute at (1)
pr93714_1.f90:2:13:

2 |character((1.)) :: a
  | 1
Error: Expression at (1) must be of INTEGER type, found REAL

and

pr93714_2.f90:3:34:

3 |character(:), pointer :: b => a
  |  1
Error: Pointer assignment target in initialization expression does not have the
TARGET attribute at (1)
pr93714_2.f90:2:13:

2 |character((9.)) :: a
  | 1
Error: Expression at (1) must be of INTEGER type, found REAL

Running make with check-fortran resulted in char_pointer_assign_6.f90 failing:

char_pointer_assign_6.f90:8:2:

8 |   p1 => s1(2:3) ! { dg-error "Unequal character lengths \\(20/2\\)" }
  |  1
Error: Unequal character lengths (20/2) in pointer assignment at (1)
char_pointer_assign_6.f90:9:8:

9 |   p1 => c(1:) ! { dg-error "Unequal character lengths \\(20/4\\)" }
  |1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
char_pointer_assign_6.f90:10:8:

   10 |   p1 => c(:4) ! { dg-error "Unequal character lengths \\(20/4\\)" }
  |1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)

The variable c does not have the target attribute so the unequal character
lengths messages should not have occurred.

I'm now modifying char_pointer_assign_6.f90 and adding test cases so I can send
a patch upstream for approval.

[Bug fortran/93715] [9/10 Regression] ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:6320

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-13
 CC||markeggleston at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from markeggleston at gcc dot gnu.org ---
Confirmed using compiler built at commit
https://gcc.gnu.org/g:8ea884b85e338d09b14e6a54043c53ae0c1b1fe9

ICE also occurs for 9.1 and 9.2 releases.

[Bug fortran/93685] [9/10 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-12
 CC||markeggleston at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from markeggleston at gcc dot gnu.org ---
Introduced with https://gcc.gnu.org/g:b6e841a699fe43ddf632dd79e0002dd51c8bf864
"decl.c (match_data_constant): Fortran 2018 allows pointer initialization in a
data statement."

Changing the example code to:

program p
   type t
  integer :: a
   end type
   type(t) :: x
   integer, target :: c = 10
   data x%a /c/
end program

results in:

7 |data x%a /c/
  |  1
Error: non-constant initialization expression at (1)

I think the error message is inadequate, it ought to state that 'a' does not
have the pointer attribute or something along those lines.

The ICE only appears to occur if the types of a and x are both CHARACTER.

This is a feature of Fortran 2018, however with the pointer attribute added to
a the code compiles irrespective of the -std option.

I think the issues of error messages and -std can be postponed until the next
release.

[Bug fortran/92196] Regression: -fno-automatic affects local variables in subroutines/function declared with recursive keyword

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from markeggleston at gcc dot gnu.org ---
This bug was reported again as pr93263 and fixed.

*** This bug has been marked as a duplicate of bug 93263 ***

[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mark.eggleston at codethink 
dot co
   ||m

--- Comment #20 from markeggleston at gcc dot gnu.org ---
*** Bug 92196 has been marked as a duplicate of this bug. ***

[Bug fortran/93578] [10 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:1949

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from markeggleston at gcc dot gnu.org ---
Built with bootstrap, master at https://gcc.gnu.org/g:c940105cc17

Get the same output as gfortran-10-20200105 in the original report.

[Bug fortran/93581] [9/10 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #4 from markeggleston at gcc dot gnu.org ---
Implementation of "Type parameter inquiry (str%len, a%kind) and Complex parts
(z%re, z%im)" was introduced in PR fortran/40196.

An subsequent ICE was fixed in PR fortran/92753.

Looking at trans-array.c:6951 it is clear that INQUIRY_REF is not handled.

Implementation of this feature is incomplete, unfortunately I do not have the
knowledge to add the missing code.

Related PRs.

PR fortran/93600 ICE in gfc_match_assignment, at fortran/match.c:1366/1340
PR fortran/93580 ICE in gfc_validate_kind(): Got bad kind
PR fortran/93579 ICE in gfc_conv_substring_expr, at fortran/trans-expr.c:8587

I've added Paul Thomas to the cc list as he committed the original
implementation.

[Bug fortran/93581] [9/10 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-05
 Ever confirmed|0   |1

--- Comment #3 from markeggleston at gcc dot gnu.org ---
Confirmed on master at
https://gcc.gnu.org/g:a2155f7dd3d8d031607036d40b0fa32f0cb8da52

[Bug fortran/93580] [9/10 Regression] ICE in gfc_validate_kind(): Got bad kind

[markeggleston at gcc dot gnu.org]

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

--- Comment #4 from markeggleston at gcc dot gnu.org ---
Created attachment 47785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47785=edit
Modified patch to handle %len in addition to %re and %im

Modified Steve Kargl's patch to handle %len in addition to %re and %im. Test
case included.

[Bug fortran/93581] [9/10 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951

[markeggleston at gcc dot gnu.org]

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

--- Comment #2 from markeggleston at gcc dot gnu.org ---
(In reply to markeggleston from comment #1)
> Created attachment 47784 [details]
> Modified patch to handle %len in addition to %re and %im
> 
> Modified Steve Kargl's patch to handle %len in addition to %re and %im. Test
> case included.

Wrong PR apologies.

[Bug fortran/93581] [9/10 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #1 from markeggleston at gcc dot gnu.org ---
Created attachment 47784
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47784=edit
Modified patch to handle %len in addition to %re and %im

Modified Steve Kargl's patch to handle %len in addition to %re and %im. Test
case included.

[Bug fortran/93580] [9/10 Regression] ICE in gfc_validate_kind(): Got bad kind

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #3 from markeggleston at gcc dot gnu.org ---
Regarding initial report

program p
   integer, parameter :: n = 4
   complex(n%len) :: x
   x = 2.0
end

produces an identical ICE.

Regarding comment 1:

program p
   integer, parameter :: n = 4
   character(kind=n%len) :: x
   x = 'a'
   print *, x
end

use of %len is also accepted and the output is the same.

The invalid use of %len should also be handled.

[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from markeggleston at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #10)
> On Fri, Jan 31, 2020 at 08:41:29AM +0000, markeggleston at gcc dot gnu.org
> wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93365
> > 
> > markeggleston at gcc dot gnu.org changed:
> > 
> >What|Removed |Added
> > ----
> >    Assignee|markeggleston at gcc dot gnu.org   |unassigned at gcc 
> > dot gnu.org
> > 
> > --- Comment #9 from markeggleston at gcc dot gnu.org ---
> > Since I'm no longer investigating this I've removed myself from assignment.
> > 
> > This problem does not occur when the compiler is built with bootstrap but 
> > does
> > when built with gcc 6.3.
> > 
> > What should be done about its status?
> > 
> > I think it should be closed. Any suggestions/opinions?
> > 
> 
> What do you mean by "this problem"?  The original bug in
> z1.f90 from comment #1 has been fixed?

The problem of getting an ICE if I build using gcc 6.3.0. Since the original
problem is fixed. I'm changing the status to RESOLVED/FIXED.

[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|markeggleston at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #9 from markeggleston at gcc dot gnu.org ---
Since I'm no longer investigating this I've removed myself from assignment.

This problem does not occur when the compiler is built with bootstrap but does
when built with gcc 6.3.

What should be done about its status?

I think it should be closed. Any suggestions/opinions?

[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426

[markeggleston at gcc dot gnu.org]

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

--- Comment #8 from markeggleston at gcc dot gnu.org ---
(In reply to markeggleston from comment #7)
> (In reply to Steve Kargl from comment #6)
> > On Fri, Jan 24, 2020 at 12:36:45PM +, markeggleston at gcc dot gnu.org
> > wrote:
> > > gfc_simplify_expr calls simplify_parameter_variable which for zero size
> > > arrays it creates a new gfc_expr structure with the expr_type set to 
> > > EXPR_ARRAY
> > > and replaces primary. When primary is replaced its chain of ref 
> > > structures is
> > > deleted so tmp->u.i is invalid causing the ICE the following lines are 
> > > never
> > > reached:
> > 
> > The lines are reached in my debugging sessions. :-)
> > I bootstrap with --enable-checking, which might 
> > prevent the ICE issue.
> 
> Tried that to no effect, however, I found that the version of the compiler
> used to compile gfortran does affect the outcome:
> 
> bootstrap no ICE
> gcc-8.2.0 no ICE

checking the environment again: gcc 8.2.1, g++ 4.8.5

> gcc-6.3.0 ICE
> 
> I haven't tried an other compilers.
> 
> > 
> > > > then enters the switch statement and get to lines 2384-2385
> > > > 
> > > >primary->ts.type = BT_INTEGER;
> > > >primary->ts.kind = gfc_default_integer_kind;
> > > > 
> > > > This just resets a part of primary, but it does not fix up
> > > > it up correctly.  Likely, need to check for zero size
> > > > arrays do extra work.
> > > 
> > > I have modified gfc_simplify_expr:
> > 
> > I'm beginning to think that calling gfc_simplify_expr may
> > not be correct, here.  But, don't have time to investigate
> > more.

[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426

[markeggleston at gcc dot gnu.org]

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

--- Comment #7 from markeggleston at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #6)
> On Fri, Jan 24, 2020 at 12:36:45PM +0000, markeggleston at gcc dot gnu.org
> wrote:
> > gfc_simplify_expr calls simplify_parameter_variable which for zero size
> > arrays it creates a new gfc_expr structure with the expr_type set to 
> > EXPR_ARRAY
> > and replaces primary. When primary is replaced its chain of ref structures 
> > is
> > deleted so tmp->u.i is invalid causing the ICE the following lines are never
> > reached:
> 
> The lines are reached in my debugging sessions. :-)
> I bootstrap with --enable-checking, which might 
> prevent the ICE issue.

Tried that to no effect, however, I found that the version of the compiler used
to compile gfortran does affect the outcome:

bootstrap no ICE
gcc-8.2.0 no ICE
gcc-6.3.0 ICE

I haven't tried an other compilers.

> 
> > > then enters the switch statement and get to lines 2384-2385
> > > 
> > >primary->ts.type = BT_INTEGER;
> > >primary->ts.kind = gfc_default_integer_kind;
> > > 
> > > This just resets a part of primary, but it does not fix up
> > > it up correctly.  Likely, need to check for zero size
> > > arrays do extra work.
> > 
> > I have modified gfc_simplify_expr:
> 
> I'm beginning to think that calling gfc_simplify_expr may
> not be correct, here.  But, don't have time to investigate
> more.

[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |markeggleston at gcc 
dot gnu.org

--- Comment #5 from markeggleston at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #4)
> On Thu, Jan 23, 2020 at 03:37:04PM +0000, markeggleston at gcc dot gnu.org
> wrote:
> > 
> > If the parameter attribute is removed or a non zero sized array is used, the
> > ICE does not occur.
> > 
> > The ICE occurs in gfc_match_varspec (primary.c) a temporary gfc_ref 
> > structure
> > has been created and has the type REF_INQUIRY. If the primary expression has
> > been passed in is EXPR_CONSTANT the check is done. When the ICE occurs the 
> > type
> > is EXPR_STRUCTURE, so the value of the REF_INQUIRY taken from u.i is used 
> > for
> > the inquiry type instead of being 2 (INQUIRY_KIND) it is random 
> > e.g.73176720.
> > 
> 
> Not quite, right.  If you have
> 
>complex, parameter :: a(1) = 0
>integer b
>data b/a%kind%
> 
> then at line 2337 in primary.c
> 
>gfc_simplify_expr (primary, 0);
> 
> collapses primary to an EXPR_CONSTANT, and then things seem to work.
> 
> If you have
> 
>complex, parameter :: a(0) = 0
>integer b
>data b/a%kind%
> 
> then "gfc_simplify_expr (primary, 0)" does not collapse primary
> to EXPR_CONSTANT as it seems gfc_simplify_expr does not handle
> zero size arrays (as there is nothing to simplify!).  gfortran

gfc_simplify_expr calls simplify_parameter_variable which for zero size
arrays it creates a new gfc_expr structure with the expr_type set to EXPR_ARRAY
and replaces primary. When primary is replaced its chain of ref structures is
deleted so tmp->u.i is invalid causing the ICE the following lines are never
reached:

> then enters the switch statement and get to lines 2384-2385
> 
>primary->ts.type = BT_INTEGER;
>primary->ts.kind = gfc_default_integer_kind;
> 
> This just resets a part of primary, but it does not fix up
> it up correctly.  Likely, need to check for zero size
> arrays do extra work.

I have modified gfc_simplify_expr:

--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -2069,8 +2069,13 @@ simplify_parameter_variable (gfc_expr *p, int type)
   e->value.constructor = NULL;
   e->shape = gfc_copy_shape (p->shape, p->rank);
   e->where = p->where;
-  gfc_replace_expr (p, e);
-  return true;
+  e->ref = gfc_copy_ref (p->ref);
+  t = gfc_simplify_expr (e, type);
+  if (t && !e->ref)
+   gfc_replace_expr (p, e);
+  else
+   gfc_free_expr (e);
+  return t;
 }

   e = gfc_copy_expr (p->symtree->n.sym->value);

This results in primary being reduced to a EXPR_CONSTANT just like it is for
non-zero length arrays.

I've checked the 8 and 9 branches, 8 does not support this syntax and 9.2
behaves differently:

program p
   real, parameter :: a(0) = 0.5
   write(*,*) a%kind
end

compiles but the output is:
  0.5

and 

program p
   real, parameter :: a(1) = 0.5
   write(*,*) a%kind
end

fails to compile with an ICE. I'll investigate these further and ad either 1 or
2 new PRs.

I'm now getting failures for several test cases in gfortran.dg, more work to
do...

[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426

[markeggleston at gcc dot gnu.org]

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

--- Comment #3 from markeggleston at gcc dot gnu.org ---
(In reply to markeggleston from comment #2)
> f951: internal compiler error: in gfc_match_varspec, at
> fortran/primary.c:2389
> 0x727097 gfc_match_varspec(gfc_expr*, int, bool, bool)
>   ../../gcc/gcc/fortran/primary.c:2389
> 0x728b35 gfc_match_rvalue(gfc_expr**)
>   ../../gcc/gcc/fortran/primary.c:3496
> 0x6ae0f4 match_data_constant
>   ../../gcc/gcc/fortran/decl.c:398
> 0x6ae356 top_val_list
>   ../../gcc/gcc/fortran/decl.c:499
> 0x6ae691 gfc_match_data()
>   ../../gcc/gcc/fortran/decl.c:712
> 0x7177b9 match_word_omp_simd
>   ../../gcc/gcc/fortran/parse.c:93
> 0x71cbc6 match_word
>   ../../gcc/gcc/fortran/parse.c:469
> 0x71cbc6 decode_statement
>   ../../gcc/gcc/fortran/parse.c:469
> 0x71d6d4 next_free
>   ../../gcc/gcc/fortran/parse.c:1279
> 0x71d6d4 next_statement
>   ../../gcc/gcc/fortran/parse.c:1511
> 0x71efcc parse_spec
>   ../../gcc/gcc/fortran/parse.c:3922
> 0x721728 parse_progunit
>   ../../gcc/gcc/fortran/parse.c:5851
> 0x722d54 gfc_parse_file()
>   ../../gcc/gcc/fortran/parse.c:6391
> 0x76e80f gfc_be_parse_file
>   ../../gcc/gcc/fortran/f95-lang.c:210
> 
> on master https://gcc.gnu.org/g:7491c17fe01d8cf116f645532d46120029b26408
> 
> This occurs for:
> 
> program p
>   real, parameter :: a(0) = 0.5
>   write(\*,\*) a%kind
> end
> 
> If the parameter attribute is removed or a non zero sized array is used, the
> ICE does not occur.
> 
> The ICE occurs in gfc_match_varspec (primary.c) a temporary gfc_ref
> structure has been created and has the type REF_INQUIRY. If the primary
> expression has been passed in is EXPR_CONSTANT the check is done. When the
> ICE occurs the type
> is EXPR_STRUCTURE, so the value of the REF_INQUIRY taken from u.i is used

my mistake EXPR_ARRAY not EXPR_STRUCTURE

> for the inquiry type instead of being 2 (INQUIRY_KIND) it is random
> e.g.73176720.

[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #2 from markeggleston at gcc dot gnu.org ---
f951: internal compiler error: in gfc_match_varspec, at fortran/primary.c:2389
0x727097 gfc_match_varspec(gfc_expr*, int, bool, bool)
../../gcc/gcc/fortran/primary.c:2389
0x728b35 gfc_match_rvalue(gfc_expr**)
../../gcc/gcc/fortran/primary.c:3496
0x6ae0f4 match_data_constant
../../gcc/gcc/fortran/decl.c:398
0x6ae356 top_val_list
../../gcc/gcc/fortran/decl.c:499
0x6ae691 gfc_match_data()
../../gcc/gcc/fortran/decl.c:712
0x7177b9 match_word_omp_simd
../../gcc/gcc/fortran/parse.c:93
0x71cbc6 match_word
../../gcc/gcc/fortran/parse.c:469
0x71cbc6 decode_statement
../../gcc/gcc/fortran/parse.c:469
0x71d6d4 next_free
../../gcc/gcc/fortran/parse.c:1279
0x71d6d4 next_statement
../../gcc/gcc/fortran/parse.c:1511
0x71efcc parse_spec
../../gcc/gcc/fortran/parse.c:3922
0x721728 parse_progunit
../../gcc/gcc/fortran/parse.c:5851
0x722d54 gfc_parse_file()
../../gcc/gcc/fortran/parse.c:6391
0x76e80f gfc_be_parse_file
../../gcc/gcc/fortran/f95-lang.c:210

on master https://gcc.gnu.org/g:7491c17fe01d8cf116f645532d46120029b26408

This occurs for:

program p
  real, parameter :: a(0) = 0.5
  write(\*,\*) a%kind
end

If the parameter attribute is removed or a non zero sized array is used, the
ICE does not occur.

The ICE occurs in gfc_match_varspec (primary.c) a temporary gfc_ref structure
has been created and has the type REF_INQUIRY. If the primary expression has
been passed in is EXPR_CONSTANT the check is done. When the ICE occurs the type
is EXPR_STRUCTURE, so the value of the REF_INQUIRY taken from u.i is used for
the inquiry type instead of being 2 (INQUIRY_KIND) it is random e.g.73176720.