[Bug fortran/94246] [9/10 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #7 from anlauf at gcc dot gnu.org ---
I get an ICE even for the non-valgrind version on x86_64-pc-linux-gnu:

gcc/testsuite/gfortran.dg/bessel_5.f90:64:50:

   64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) ]))
&
  |  1
Error: Result of BESSEL_YN overflows its kind at (1)
gcc/testsuite/gfortran.dg/bessel_5.f90:64:26:

   64 | if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) ]))
&
  |  1
Error: Result of BESSEL_YN is -INF at (1)
f951: internal compiler error: Segmentation fault
0xd4aedf crash_signal
../../gcc-trunk/gcc/toplev.c:328
0x65ae4f reduce_binary_ac
../../gcc-trunk/gcc/fortran/arith.c:1325
0x65aee2 reduce_binary_ac
../../gcc-trunk/gcc/fortran/arith.c:1312
0x65b034 reduce_binary
../../gcc-trunk/gcc/fortran/arith.c:1438
0x65b35b eval_intrinsic
../../gcc-trunk/gcc/fortran/arith.c:1613
0x6965f8 simplify_intrinsic_op
../../gcc-trunk/gcc/fortran/expr.c:1219
0x6965f8 gfc_simplify_expr(gfc_expr*, int)
../../gcc-trunk/gcc/fortran/expr.c:2233
0x708c89 resolve_operator
../../gcc-trunk/gcc/fortran/resolve.c:4377
0x706177 gfc_resolve_expr(gfc_expr*)
../../gcc-trunk/gcc/fortran/resolve.c:7022
0x70993f gfc_resolve_expr(gfc_expr*)
../../gcc-trunk/gcc/fortran/resolve.c:2162
0x70993f resolve_actual_arglist
../../gcc-trunk/gcc/fortran/resolve.c:2081
0x70654e resolve_function
../../gcc-trunk/gcc/fortran/resolve.c:3183
0x70654e gfc_resolve_expr(gfc_expr*)
../../gcc-trunk/gcc/fortran/resolve.c:7029
0x70e7d1 gfc_resolve_expr(gfc_expr*)
../../gcc-trunk/gcc/fortran/resolve.c:6996
0x70e7d1 gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:10618
0x6fe518 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:11706
0x700d9d resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:17233
0x700e6e gfc_resolve(gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:17268
0x6ef01d resolve_all_program_units
../../gcc-trunk/gcc/fortran/parse.c:6245
0x6ef01d gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:6492

I agree with Richard that this should not happen.

[Bug fortran/94246] [9/10 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41

[anlauf at gcc dot gnu.org]

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Reduced testcase:

implicit none
integer :: i

if (any (BESSEL_YN(0, 10, 0.0) /= [ (BESSEL_YN(i, 0.0), i = 0, 10) ])) &
then
  STOP 6
end if

if (any (abs (BESSEL_YN(0, 10, 1.0) &
  - [ (BESSEL_YN(i, 1.0), i = 0, 10) ]) &
 > epsilon(0.0)*32)) then
  STOP 8
end if

end

[Bug fortran/57129] [8/9/10 Regression] Improve error message for conflicts between PROCEDURE and DERIVED.

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 CC||anlauf at gcc dot gnu.org
 Status|WAITING |RESOLVED
  Known to work||10.0, 8.3.1, 9.2.1

--- Comment #20 from anlauf at gcc dot gnu.org ---
I cannot reproduce on any active branch.  Please reopen if it reappears,
or open a new PR.

[Bug fortran/93364] [9/10 Regression] ICE in gfc_set_array_spec, at fortran/array.c:879

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
The following patch would avoid the ICE:

diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 57972bc9176..471523fb767 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -864,6 +864,10 @@ gfc_set_array_spec (gfc_symbol *sym, gfc_array_spec *as,
locus *error_loc)
   return false;
 }

+  /* Check F2018:C822.  */
+  if (sym->as->rank + sym->as->corank > GFC_MAX_DIMENSIONS)
+goto too_many;
+
   if (as->corank)
 {
   sym->as->cotype = as->cotype;

I have a gut feeling that this kind of check should trigger earlier,
but cannot find this place.

[Bug fortran/93364] [9/10 Regression] ICE in gfc_set_array_spec, at fortran/array.c:879

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed for gcc-10 and backported to 9-branch.

Thanks for the report.

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

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
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.

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

[anlauf at gcc dot gnu.org]

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> The testcase in comment#0 compiles for me with today's master.

Read: does not ICE; just gives an appropriate error message:

z1.f90:8:6:

8 |   function f(x)
  |  1
Error: Interface mismatch in global procedure 'f' at (1): POINTER attribute
mismatch in function result

[Bug fortran/92065] [8/9/10 Regression] internal compiler error: in expand_expr_real_1

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #5 from anlauf at gcc dot gnu.org ---
The testcase in comment#0 does not ICE if in function fun2 the
second dummy argument is declared as TYPE instead of CLASS, i.e.

type (bar), intent(in) :: a(this%n) ! no ICE

instead of

class(bar), intent(in) :: a(this%n)

Maybe this rings a bell with someone.

[Bug fortran/93834] [8/9/10 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #3 from anlauf at gcc dot gnu.org ---
AFAICT this is invalid code.

[Bug fortran/93340] [8/9/10 Regression] ICE in check_constant_initializer, at fortran/trans-decl.c:5450

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
AFAICS the code in comment#0 is non-standard:

% gfc-trunk foo.f90 -std=f2018
z1.f90:2:20:

2 |character c(2) /'a', 'b'(1:1)/
  |1
Error: GNU Extension: Old-style initialization at (1)
z1.f90:3:20:

3 |character d(2) /'a', 'bc'(1:1)/
  |1
Error: GNU Extension: Old-style initialization at (1)

[Bug fortran/93794] [8/9/10 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2497

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #2)
> Created attachment 47944 [details]
> Patch for the PR
> 
> The test below does the right thing and the code is as expected.
> 
> Paul
> 
> program p
>type t
>   character(:), pointer :: a
>end type
>type(t) :: z
>character(4), target :: c = 'abcd'
>z%a => c
>associate (y => z%a)
>   print *, y
>end associate
> end

Paul,

are you still working on this?

[Bug fortran/91862] [9/10 Regression] ICE in fold_convert_loc, at fold-const.c:2394

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Replacing

  character(3) :: a(3) = 'abc'

by

  character(3), parameter :: a(3) = 'abc' ! No ICE

also avoids the ICE.

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

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #7)
> And committed as r10-7081-g9de42a8e995451cb13dceb3970ae23ff88240bff
> [As far as I could see, it was not yet backported to GCC 9.]
Thus marking a 9 regression.

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

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #7 from anlauf at gcc dot gnu.org ---
(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?

[Bug fortran/94246] [9 Regression] valgrind error for ./gfortran.dg/bessel_5.f90 since r9-1566-g87c789f1c0b2df41

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||10.0
Summary|[9/10 Regression] valgrind  |[9 Regression] valgrind
   |error for   |error for
   |./gfortran.dg/bessel_5.f90  |./gfortran.dg/bessel_5.f90
   |since   |since
   |r9-1566-g87c789f1c0b2df41   |r9-1566-g87c789f1c0b2df41
  Known to fail|10.0|

--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #11)
> This issue was solved for GCC 10 = mainline by the following commit.
> 
> commit r10-7444-g7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65
Thus marking as 9 regression.

[Bug fortran/93366] ICE: Invalid expression in gfc_element_size

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> patch against last SVN revision.
Steve,

do you still care?

[Bug fortran/93366] ICE: Invalid expression in gfc_element_size

[anlauf at gcc dot gnu.org]

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Created attachment 48427
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48427&action=edit
Update and extension of Steve's patch

I've updated Steve's patch to reflect current master before creating the
10-release branch.

My additions handle a few accepts-invalid cases for
KIND, MERGE, SHAPE, SPREAD.

If there are no objections, I will submit with a testcase after the 10 release
for the 11 master.

[Bug fortran/93366] ICE: Invalid expression in gfc_element_size

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Patch posted at

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545091.html

[Bug fortran/93366] ICE: Invalid expression in gfc_element_size

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC 11.  Thanks for the report!

[Bug fortran/94943] [10 Regression] A module does not export allocatable attribute of herein arrays.

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from anlauf at gcc dot gnu.org ---
Next time please provide a testcase that works at least with another compiler.

First, I guess there's a typo: FNUM instead of FNAM

Second, FNAM is declared:

  CHARACTER(LEN=24),DIMENSION(NPA) :: FNAM

There's nothing allocatable here.

I'm closing this as invalid.

[Bug libfortran/94143] [9/10/11 Regression] Asynchronous execute_command_line() breaks following synchronous calls

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Funny.  I do not get failures when compiling with -fsanitize=thread.

With valgrind --tool=helgrind I get lots of "Possible data race" hints
that I'm not sure how to interpret.

[Bug fortran/93499] ICE in gfc_zero_size_array, at fortran/arith.c:1686

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Patch posted for review:

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545469.html

[Bug fortran/93499] ICE in gfc_zero_size_array, at fortran/arith.c:1686

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC 11.

Thanks for the report!

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
Even shorter and simpler (no linebreak needed):

  SUBROUTINE MNSTIN ()
* Adding a comma before or after the "/" avoids the ICE
 132  FORMAT ('A'/'B')
  END

Running this under gdb and setting a breakpoint in gfc_divide,
it appears to really divide characters:

(gdb) p op1->ts.type
$3 = BT_CHARACTER
(gdb) p op2->ts.type
$4 = BT_CHARACTER

What's going on here?

Most likely there's something latent in parsing FORMAT().

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
It gets actually really weird during parsing.

The following (invalid) code shows that the parser is still in an
early phase where it has not yet decided that it is a FORMAT statement,
but rather could be something else:

  format('x') = x
end

This gives:

1 |   format('x') = x
  |  1
Error: The function result on the lhs of the assignment at (1) must have the
pointer attribute.

while e.g. Intel detects:

foo.f90(1): error #6072: A dummy argument of a statement function must be a
scalar identifier.   ['x']
  format('x') = x
-^

The simplest solution is to defer error detection and recovery by restoring
the previous behavior when the basic type of operand 2 to gfc_divide is
non-numeric:

diff --git a/gcc/fortran/arith.c b/gcc/fortran/arith.c
index 1cd0867a941..dd72f44d377 100644
--- a/gcc/fortran/arith.c
+++ b/gcc/fortran/arith.c
@@ -1828,7 +1828,8 @@ gfc_divide (gfc_expr *op1, gfc_expr *op2)
rc = ARITH_DIV0;
  break;
default:
- gfc_internal_error ("gfc_divide(): Bad basic type");
+ /* basic type is non-numeric, handle this elsewhere.  */
+ break;
}
   if (rc == ARITH_DIV0)
{

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Should be fixed.  Please reopen if you find further issues.

Sorry for the breakage.

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[anlauf at gcc dot gnu.org]

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Bill Seurer from comment #11)
> /home/seurer/gcc/git/install/gcc-test/bin/gfortran -c -o
> module_ra_cam.fppized.o -I. -I./netcdf/include -I./inc -m64 -O0 -g3
> -mcpu=power8 -Wno-deprecated-declarations -fconvert=big-endian -std=legacy
> module_ra_cam.fppized.f90
> module_ra_cam.fppized.f90:6806:69:
> 
>  6806 |asort(nxs) =
> 1.0_r8-(floor(cld(i,k)/cldeps)*cldeps)
>   | 1
> Error: Division by zero at (1)
> 
> This error was also triggered by r11-205 but was not fixed by the patch.  It
> compiles cleanly with r11-204 and earlier.  I do not think (though cannot
> say for sure) that it really is a divide by zero.
> 
> This is part of 521.wrf_r in the spec2017 test suite

I don't have access to spec.

Can you provide enough context for a reproducer?

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from anlauf at gcc dot gnu.org ---
A possible workaround is to partly revert the offending commit and handle
problematic cases individually.  The original commit intended to handle
two different ICEs with a common invalid code.

Bill, can you try the following patch?  (Note that this needs two adjustments
in the testsuite, but otherwise regtests for me.   I'm not 100%sure if the
PDT part is correct.)

diff --git a/gcc/fortran/arith.c b/gcc/fortran/arith.c
index dd72f44d377..dd7f5f43930 100644
--- a/gcc/fortran/arith.c
+++ b/gcc/fortran/arith.c
@@ -1806,7 +1806,7 @@ gfc_multiply (gfc_expr *op1, gfc_expr *op2)
 gfc_expr *
 gfc_divide (gfc_expr *op1, gfc_expr *op2)
 {
-  if (op2 && op2->expr_type == EXPR_CONSTANT)
+  if (0 && op2 && op2->expr_type == EXPR_CONSTANT)
 {
   arith rc = ARITH_OK;
   switch (op2->ts.type)
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index d650407da41..6866f460224 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -2602,6 +2602,14 @@ variable_decl (int elem)
  gfc_free_expr (e);
}

+ if (not_constant && e->ts.type != BT_INTEGER)
+   {
+ gfc_error ("Explicit array shape at %C must be constant of "
+"INTEGER type and not %s type",
+gfc_basic_typename (e->ts.type));
+ m = MATCH_ERROR;
+ goto cleanup;
+   }
  if (not_constant)
{
  gfc_error ("Explicit shaped array with nonconstant bounds at
%C");
@@ -3736,8 +3744,9 @@ gfc_get_pdt_instance (gfc_actual_arglist *param_list,
gfc_symbol **sym,
   if (kind_expr)
{
  /* Try simplification even for LEN expressions.  */
+ bool ok;
  gfc_resolve_expr (kind_expr);
- gfc_simplify_expr (kind_expr, 1);
+ ok = gfc_simplify_expr (kind_expr, 1);
  /* Variable expressions seem to default to BT_PROCEDURE.
 TODO find out why this is and fix it.  */
  if (kind_expr->ts.type != BT_INTEGER
@@ -3748,6 +3757,12 @@ gfc_get_pdt_instance (gfc_actual_arglist *param_list,
gfc_symbol **sym,
 gfc_basic_typename (kind_expr->ts.type));
  goto error_return;
}
+ if (kind_expr->ts.type == BT_INTEGER && !ok)
+   {
+ gfc_error ("The parameter expression at %C does not "
+"simplify to an INTEGER constant");
+ goto error_return;
+   }

  tail->expr = gfc_copy_expr (kind_expr);
}

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[anlauf at gcc dot gnu.org]

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

--- Comment #20 from anlauf at gcc dot gnu.org ---
(In reply to Bill Seurer from comment #19)
> There's some stuff above this in the module but this is the part that shows
> the error and I think it contains all the declarations.
> 
> subroutine Z()
>real(r8) :: cld(99,99)
>real(r8) cldeps
>parameter (cldeps = 0.0_r8)
>real(r8) asort(99)
>if (cldeps > 0) then
>   asort(1) = 1.0_r8-(floor(cld(1,7)/cldeps)*cldeps)
>endif
>return
> end subroutine Z
> 
>15 |   asort(1) = 1.0_r8-(floor(cld(1,7)/cldeps)*cldeps)
>   |  1
> Error: Division by zero at (1)

Thanks for the small example.

The parameter statement makes cldeps to a constant that is zero when that
line is processed.  Arguably that is borderline code.

I see two ways around:

1) either replace the parameter statement for cldeps by an initialization:

  data cldeps / 0.0_r8 /

2) or add -fno-range-check to the command line.

I could adjust the error message so that you get an approprate hint
how to switch off that error.

What do you think?

[Bug fortran/95138] ICE on transfer to unlimited polymorphic

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-5-14
 CC||anlauf at gcc dot gnu.org
   Keywords||ice-on-valid-code,
   ||wrong-code
   Priority|P3  |P4

--- Comment #1 from anlauf at gcc dot gnu.org ---
A small subset of the reproducer shows that invalid code is generated:

program transfer_p
  implicit none
  integer, parameter :: n = 3
  class(*), allocatable :: o(:)
  integer   :: v(n)
  integer   :: i

  v = [(i, i=1,n)]
  allocate(o, source=v)
  print *, "size (o) =", size (o)
  print *, transfer(o, v)
end

This compiles and gives:

 size (o) =   3
   1   2   3   0   0   0

while compiling with -fdefault-integer-8 gives the correct answer:

 size (o) =3
123

A look at the dump appears to give some hint where to look further.

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[anlauf at gcc dot gnu.org]

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

--- Comment #28 from anlauf at gcc dot gnu.org ---
A patch based on comment#15 has been posted for review:

https://gcc.gnu.org/pipermail/fortran/2020-May/054321.html

[Bug fortran/95138] ICE on transfer to unlimited polymorphic

[anlauf at gcc dot gnu.org]

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Another datapoint: inserting

  select type (o)
  type is (integer)
 print *, transfer(o, v)
  end select

prints the right thing:

   1   2   3

Also note the possibly related PR84006, where one gets an ICE on

 print *, "storage_size (o) =", storage_size (o) ! ICE

unless one places this inside a select type.

[Bug fortran/95191] Hang in WAIT with a bad ID= value if threading specified

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Priority|P3  |P4
 CC||anlauf at gcc dot gnu.org
   Last reconfirmed||2020-05-18
 Status|UNCONFIRMED |NEW

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

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[anlauf at gcc dot gnu.org]

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

Bug 95053 Summary: [11 regression] ICE in f951: gfc_divide()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #30 from anlauf at gcc dot gnu.org ---
Should be fixed now.

Sorry for the breakage.

[Bug fortran/94361] Memory leak in nested types with final

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||10.1.1, 11.0, 7.4.1, 8.2.1,
   ||8.3.1, 9.3.1
Summary|Regression: Memory leak in  |Memory leak in nested types
   |nested types with final |with final
   Last reconfirmed||2020-05-18
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed regarding the memory leak.

Cannot confirm as regression.  My 8.2.1 (OpenSuse) leaks the same as other
versions according to valgrind.

Regression marker therefore removed.

[Bug fortran/94361] Memory leak in nested types with final

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P4

[Bug fortran/94361] [8/9/10/11 Regression] Memory leak in nested types with final

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||6.5.0, 7.2.0, 7.4.0, 8.1.0
   Target Milestone|--- |8.5
Summary|Memory leak in nested types |[8/9/10/11 Regression]
   |with final  |Memory leak in nested types
   ||with final
  Known to fail||9.2.0

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Antony Lewis from comment #3)
> On Windows 8.1.0 does not leak, and on NERSC 8.3.0 20190222 (Cray Inc.) also
> does not (but 9.2.0 does)... so not exactly sure what this means about when
> it was introduced.

So adding to known-to-work/fail.

I found a Debian machine with 7.2.0 and compared the dump tree with that of
7.4.1.  There is clearly a chunk of code related to finalization present in
7.2.0, but it is missing in 7.4.1:

  if (&ptr2->t != 0B)
{
  {
integer(kind=4) stat.5;

if ((real(kind=4)[0:] * restrict) ptr2->t.dat.data == 0B)
  {
stat.5 = 1;
  }
else
  {
__builtin_free (ptr2->t.dat.data);
(real(kind=4)[0:] * restrict) ptr2->t.dat.data = 0B;
stat.5 = 0;
  }
if (stat.5 != 0) goto L.9;
L.9:;
ignore = stat.5;
  }
}
  L.8:;
  {
struct array0_typewithfinal desc.6;

desc.6.dtype = 40;
desc.6.data = (void * restrict) &ptr2->t.x;
__final_debug_Typewithfinal (&desc.6);
  }

Looking at the changes to the 7 series leading to 7.4.1 might indicate the
which commit (or backport) caused this.

Marking as (7)/8/9/10/11 regression.

[Bug fortran/95195] gfortran poorly handles a program error of writing a namelist to an unformatted file.

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
   Last reconfirmed||2020-05-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Seems to be present in all versions.

Confirmed.

[Bug libfortran/95195] gfortran poorly handles a program error of writing a namelist to an unformatted file.

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Component|fortran |libfortran
   Priority|P3  |P4

--- Comment #2 from anlauf at gcc dot gnu.org ---
The following patch generates a runtime error for namelist read:

diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 77d61421a0f..28744d21143 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -3549,6 +3549,14 @@ namelist_read (st_parameter_dt *dtp)
  name.  */
   namelist_info *prev_nl = NULL;

+  if (dtp->u.p.current_unit->flags.form == FORM_UNFORMATTED)
+{
+  generate_error (&dtp->common, LIBERROR_OPTION_CONFLICT,
+ "Namelist formatting not allowed for unit connected "
+ "with FORM='UNFORMATTED'");
+  return;
+}
+
   dtp->u.p.input_complete = 0;
   dtp->u.p.expanded_read = 0;

This generates:

At line 10 of file pr95195.f90 (unit = 10, file = 'test.dat')
Fortran runtime error: Namelist formatting not allowed for unit connected with
FORM='UNFORMATTED'

Error termination. Backtrace:
#0  0x7f80d510f1a7 in finalize_transfer
at ../../../gcc-trunk/libgfortran/io/transfer.c:4128
#1  0x400b3b in test
at /home/anlauf/gcc-bugs/pr95195.f90:10
#2  0x400b9c in main
at /home/anlauf/gcc-bugs/pr95195.f90:12


Regtests cleanly for me.

Similar checks can be added for namelist write, list-directed formatting,
and non-advancing data transfers.  (F2018: 12.3.3.3)

Does this look better?

[Bug fortran/95106] Bogus warning from module with long name and an equivalence

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
   Last reconfirmed||2020-05-21
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||wrong-code
   Priority|P3  |P4

--- Comment #1 from anlauf at gcc dot gnu.org ---
The warning is not only bogus, but indicates that something goes wrong.

Doing an "nm" on the resulting object files, it seems one equivalence is
missing for names of length 60+.

For z1_59.o:

0020 C
m2345678901234567890123456789012345678901234567890123456789.eq.0_
0018 C
m2345678901234567890123456789012345678901234567890123456789.eq.1_

For z1_60.o:

0020 C
m23456789012345678901234567890123456789012345678901234567890.eq._

It seems it cannot disambiguate the two equivalences any more,
and treat them as a single common.

[Bug fortran/95106] Bogus warning from module with long name and an equivalence

[anlauf at gcc dot gnu.org]

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Something like

diff --git a/gcc/fortran/trans-common.c b/gcc/fortran/trans-common.c
index bf163bc4f52..06313873002 100644
--- a/gcc/fortran/trans-common.c
+++ b/gcc/fortran/trans-common.c
@@ -242,8 +242,8 @@ static tree
 gfc_sym_mangled_common_id (gfc_common_head *com)
 {
   int has_underscore;
-  char mangled_name[GFC_MAX_MANGLED_SYMBOL_LEN + 1];
-  char name[GFC_MAX_SYMBOL_LEN + 1];
+  char mangled_name[GFC_MAX_MANGLED_SYMBOL_LEN + 10];
+  char name[GFC_MAX_SYMBOL_LEN + 10];

   /* Get the name out of the common block pointer.  */
   strcpy (name, com->name);

prevents the truncation of the mangled name, including the .eq.0123_ part.

[Bug fortran/95106] Bogus warning from module with long name and an equivalence

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #3 from anlauf at gcc dot gnu.org ---
Patch submitted for review:

https://gcc.gnu.org/pipermail/fortran/2020-May/054373.html

[Bug fortran/94361] [8/9/10/11 Regression] Memory leak in nested types with final

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #5 from anlauf at gcc dot gnu.org ---
Reverting the commit

commit b81f7b83631be7dedcdcf44eed6dd575ada3ac23
Author: Thomas Koenig 
Date:   Sat Apr 6 22:10:28 2019 +

re PR fortran/87352 (Large stack usage with new gfortran)

2019-04-06  Thomas Koenig  

PR fortran/87352
* gfortran.h (gfc_component): Add finalized field.
* class.c (finalize_component): If the component is already
finalized, return early.  Set component->finalized on exit.

2019-04-06  Thomas Koenig  

PR fortran/87352
* gfortran.dg/finalize_28.f90: Adjust count of __builtin_free.
* gfortran.dg/finalize_33.f90: Likewise.
* gfortran.dg/finalize_34.f90: New test.

From-SVN: r270184

fixes the memory leak.

CCing Thomas.

[Bug fortran/95106] Bogus warning from module with long name and an equivalence

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Should be fixed, closing.

The test case assumes name mangling for equivalences as on Linux/x86.
If some platform has different conventions, I can add an appropriate
restriction.

Thanks for the report!

[Bug libfortran/95195] gfortran poorly handles a program error of writing a namelist to an unformatted file.

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #3 from anlauf at gcc dot gnu.org ---
Slightly adjusted patch, posted for review:

https://gcc.gnu.org/pipermail/fortran/2020-May/054380.html

[Bug fortran/95323] ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-05-25
 Status|UNCONFIRMED |WAITING

--- Comment #1 from anlauf at gcc dot gnu.org ---
local.f90:3: Error: Can't open included file 'SIZES'

Please include everything needed to reproduce.

Are you sure this is a fortran bug, rather than tree-optimization?

[Bug fortran/95089] [Coarray] ICE in gfc_get_derived_type, at fortran/trans-types.c:2843

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-05-25
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|ICE in  |[Coarray] ICE in
   |gfc_get_derived_type, at|gfc_get_derived_type, at
   |fortran/trans-types.c:2843  |fortran/trans-types.c:2843
 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
All versions from 7 to 11 (master) ICE.

Confirmed.

[Bug fortran/95089] [Coarray] ICE in gfc_get_derived_type, at fortran/trans-types.c:2843

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Obvious fix:

diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index b7712dc74d1..99844812505 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2836,9 +2836,10 @@ copy_derived_types:
  && (c->attr.allocatable || c->attr.pointer)
  && !derived->attr.is_class)
{
- char caf_name[GFC_MAX_SYMBOL_LEN];
+ /* Provide sufficient space to hold "_caf_symbol".  */
+ char caf_name[GFC_MAX_SYMBOL_LEN + 6];
  gfc_component *token;
- snprintf (caf_name, GFC_MAX_SYMBOL_LEN, "_caf_%s", c->name);
+ snprintf (caf_name, sizeof (caf_name), "_caf_%s", c->name);
  token = gfc_find_component (derived, caf_name, true, true, NULL);
  gcc_assert (token);
  c->caf_token = token->backend_decl;

[Bug fortran/95089] [Coarray] ICE in gfc_get_derived_type, at fortran/trans-types.c:2843

[anlauf at gcc dot gnu.org]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Patch submmitted for review:

https://gcc.gnu.org/pipermail/fortran/2020-May/054385.html

[Bug tree-optimization/95323] ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
  Component|fortran |tree-optimization
 Status|WAITING |NEW

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to David Binderman from comment #3)
> (In reply to anlauf from comment #1)
> > local.f90:3: Error: Can't open included file 'SIZES'
> > 
> > Please include everything needed to reproduce.
> 
> Done.
> 
> > Are you sure this is a fortran bug, rather than tree-optimization?
> 
> Not using -O2 makes the code compile, so something in the optimiser
> is going wrong, triggered by Fortran source code.

OK, using -O0, -Og, or -Os makes the code compile, -O1, -O2 or higher ICEs.

This looks fishy.

I'd prefer someone with better middle-end knowledge to look at it.

[Bug fortran/95089] [Coarray] ICE in gfc_get_derived_type, at fortran/trans-types.c:2843

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed on master for gcc-11.

Thanks for the report!

[Bug libfortran/95195] gfortran poorly handles a program error of writing a namelist to an unformatted file.

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed on master for gcc-11.

Thanks for the report!

[Bug libfortran/95104] [9/10/11 Regression] Segfault on a legal WAIT statement

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
Summary|Segfault on a legal WAIT|[9/10/11 Regression]
   |statement   |Segfault on a legal WAIT
   ||statement
   Target Milestone|--- |9.4
  Component|fortran |libfortran

--- Comment #5 from anlauf at gcc dot gnu.org ---
So a 9/10/11 regression.

[Bug libfortran/95104] [9/10/11 Regression] Segfault on a legal WAIT statement

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #6 from anlauf at gcc dot gnu.org ---
Steve, do you want me to commit it for you, including backports?

Testcase:

! { dg-do run }
! PR libfortran/95104 - Segfault on a legal WAIT statement

program test
  wait (10, iostat=ios)
  if (ios /= 0) stop 1
  close (10)
end program test

[Bug fortran/95090] ICE: identifier overflow: 129

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-05-26
 CC||anlauf at gcc dot gnu.org
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Priority|P3  |P4

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

The fix is to provide a sufficiently large buffer:

diff --git a/gcc/fortran/iresolve.c b/gcc/fortran/iresolve.c
index 7ecb6595f59..df4f2265c58 100644
--- a/gcc/fortran/iresolve.c
+++ b/gcc/fortran/iresolve.c
@@ -47,7 +47,8 @@ along with GCC; see the file COPYING3.  If not see
 const char *
 gfc_get_string (const char *format, ...)
 {
-  char temp_name[128];
+  /* Provide sufficient space to hold "_F.caf_token__symbol_MOD_symbol".  */
+  char temp_name[14 + GFC_MAX_SYMBOL_LEN + 5 + GFC_MAX_SYMBOL_LEN + 1];
   const char *str;
   va_list ap;
   tree ident;

[Bug libfortran/95104] [9/10 Regression] Segfault on a legal WAIT statement

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[9/10/11 Regression]|[9/10 Regression] Segfault
   |Segfault on a legal WAIT|on a legal WAIT statement
   |statement   |
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #9 from anlauf at gcc dot gnu.org ---
Fixed on master for gcc-11.

Backports pending.

[Bug libfortran/95104] [9/10 Regression] Segfault on a legal WAIT statement

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
Fixed on master for gcc-11, and backported to 10- and 9-branches.

Thanks for the report!

[Bug fortran/95090] ICE: identifier overflow: 129

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Fixed on master for gcc-11.

Thanks for the report!

[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942

[anlauf at gcc dot gnu.org]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Patch:

diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index d73898473df..67105cc9ab1 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -1998,6 +1998,28 @@ is_inquiry_ref (const char *name, gfc_ref **ref)
   else
 return false;

+  switch (type)
+{
+case INQUIRY_RE:
+case INQUIRY_IM:
+  if (!gfc_notify_std (GFC_STD_F2008, "RE or IM part_ref at %C"))
+   return false;
+  break;
+
+case INQUIRY_KIND:
+  if (!gfc_notify_std (GFC_STD_F2003, "KIND part_ref at %C"))
+   return false;
+  break;
+
+case INQUIRY_LEN:
+  if (!gfc_notify_std (GFC_STD_F2003, "LEN part_ref at %C"))
+   return false;
+  break;
+
+default:
+  gcc_unreachable ();
+}
+
   if (ref)
 {
   *ref = gfc_get_ref ();

[Bug fortran/95090] ICE: identifier overflow: 129

[anlauf at gcc dot gnu.org]

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Manfred Schwarb from comment #5)
> gdb shows:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xf7aa5162 in __strlen_sse2_bsf () from /lib/libc.so.6
> #0  0xf7aa5162 in __strlen_sse2_bsf () from /lib/libc.so.6
> #1  0x083e6def in get_unique_hashed_string(char*, gfc_symbol*) ()

Can you please try the following patch for me?

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 9aa3eb7282c..065cd691a73 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -501,7 +501,8 @@ get_unique_type_string (char *string, gfc_symbol *derived)
 static void
 get_unique_hashed_string (char *string, gfc_symbol *derived)
 {
-  char tmp[2*GFC_MAX_SYMBOL_LEN+2];
+  /* Provide sufficient space to hold "symbol_Pdtsymbol".  */
+  char tmp[2*GFC_MAX_SYMBOL_LEN+5];
   get_unique_type_string (&tmp[0], derived);
   /* If string is too long, use hash value in hex representation (allow for
  extra decoration, cf. gfc_build_class_symbol & gfc_find_derived_vtab).

Thanks.

[Bug fortran/95090] ICE: identifier overflow: 129

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Reopening.

[Bug libfortran/95104] [9/10 Regression] Segfault on a legal WAIT statement

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #17 from anlauf at gcc dot gnu.org ---
Should be fixed now.

Thanks, Rainer, for precisely pointing at the latent issue.

[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||anlauf at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #6 from anlauf at gcc dot gnu.org ---
Taking.

Fixed on master for gcc-11.

[Bug fortran/95090] ICE: identifier overflow: 129

[anlauf at gcc dot gnu.org]

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Manfred Schwarb from comment #10)
> Is there a way to get useful backtraces? "--enable-checking=yes,extra"
> seems not to be enough...

Maybe some "fortify" option or a "sanitized" version of the compiler?

I tried valgrind, but failed.

Then I decided to do it the hard way running the example under gdb,
and found a third function which needs adjustment.

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 9aa3eb7282c..db395624a16 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -479,11 +479,12 @@ gfc_class_initializer (gfc_typespec *ts, gfc_expr
*init_expr)
 static void
 get_unique_type_string (char *string, gfc_symbol *derived)
 {
-  char dt_name[GFC_MAX_SYMBOL_LEN+1];
+  /* Provide sufficient space to hold "Pdtsymbol".  */
+  char dt_name[GFC_MAX_SYMBOL_LEN+4];
   if (derived->attr.unlimited_polymorphic)
 strcpy (dt_name, "STAR");
   else
-strcpy (dt_name, gfc_dt_upper_string (derived->name));
+strncpy (dt_name, gfc_dt_upper_string (derived->name), sizeof (dt_name));
   if (derived->attr.unlimited_polymorphic)
 sprintf (string, "_%s", dt_name);
   else if (derived->module)
@@ -501,7 +502,8 @@ get_unique_type_string (char *string, gfc_symbol *derived)
 static void
 get_unique_hashed_string (char *string, gfc_symbol *derived)
 {
-  char tmp[2*GFC_MAX_SYMBOL_LEN+2];
+  /* Provide sufficient space to hold "symbol_Pdtsymbol".  */
+  char tmp[2*GFC_MAX_SYMBOL_LEN+5];
   get_unique_type_string (&tmp[0], derived);
   /* If string is too long, use hash value in hex representation (allow for
  extra decoration, cf. gfc_build_class_symbol & gfc_find_derived_vtab).
@@ -523,7 +525,8 @@ unsigned int
 gfc_hash_value (gfc_symbol *sym)
 {
   unsigned int hash = 0;
-  char c[2*(GFC_MAX_SYMBOL_LEN+1)];
+  /* Provide sufficient space to hold "symbol_Pdtsymbol".  */
+  char c[2*GFC_MAX_SYMBOL_LEN+5];
   int i, len;

   get_unique_type_string (&c[0], sym);


I have added one protection using strncpy to avoid a buffer overflow.
One could "protect" the temporary buffers by setting the last byte to \0
and add an assert later to detect an overrun.

I'll regtest the above and commit as "obvious" later.

Thanks, Manfred, for providing pointers.

[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942

[anlauf at gcc dot gnu.org]

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to Christophe Lyon from comment #7)
> This causes regressions on arm and aarch64:

Followup fix to cure this:

https://gcc.gnu.org/pipermail/fortran/2020-May/054420.html

Sorry for that.

[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942

[anlauf at gcc dot gnu.org]

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Master should be fixed now.

[Bug libfortran/95418] Static assert going off on MinGW

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-05-30

--- Comment #1 from anlauf at gcc dot gnu.org ---
(In reply to Markus Böck from comment #0)
> Since commit "i386: Use generic division to generate INEXACT exception"
> (d3a1459cd4f2d4997fb53e34ddef72e91a7855c1) libgfortran is not able to be
> compiled with the target x86_64-w64-mingw32. This is due to a _Static_assert
> going off in fpu-target.h. The exact error message is:
> 
> In file included from ../../../libgfortran/runtime/fpu.c:29:
> ./fpu-target.h:91:1: error: static assertion failed:
> "GFC_FPE_STATE_BUFFER_SIZE is too small"
>91 | _Static_assert (sizeof(struct fenv) <= (size_t)
> GFC_FPE_STATE_BUFFER_SIZE,
>   | ^~
> 
> Reverting the above commit makes compilation succeed.

Can you print sizeof(struct fenv)?

On Linux, this is 32, the same as defined in gcc/fortran/libgfortran.h

[Bug fortran/95503] ICE in gfc_is_simply_contiguous, at fortran/expr.c:5844

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||7.4.1, 8.3.1
   Last reconfirmed||2020-06-03
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||anlauf at gcc dot gnu.org
  Known to fail||10.1.1, 11.0, 9.3.1

--- Comment #1 from anlauf at gcc dot gnu.org ---
The following patch fixes the ICE:

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index a9fa03ad153..8daa7bb8d06 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4346,7 +4346,9 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr
*rvalue,
  contiguous.  Be lenient in the definition of what counts as
  contiguous.  */

-  if (lhs_attr.contiguous && !gfc_is_simply_contiguous (rvalue, false, true))
+  if (lhs_attr.contiguous
+  && lhs_attr.dimension > 0
+  && !gfc_is_simply_contiguous (rvalue, false, true))
 gfc_warning (OPT_Wextra, "Assignment to contiguous pointer from "
 "non-contiguous target at %L", &rvalue->where);


Not regtested though.

In some sense a 9/10/11 regression, although %re etc. did not exist
in 8 and older.

[Bug fortran/95504] [PDT] ICE in transfer_array_component, at fortran/trans-io.c:2167

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

Summary|ICE in  |[PDT] ICE in
   |transfer_array_component,   |transfer_array_component,
   |at fortran/trans-io.c:2167  |at fortran/trans-io.c:2167
   Last reconfirmed||2020-06-03
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from anlauf at gcc dot gnu.org ---
Confirmed.

Adding "PDT" to subject line.

[Bug fortran/95530] [11 regression] ICE in gfortran.dg/equiv_11.f90 after r11-594

[anlauf at gcc dot gnu.org]

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Are you able to produce a traceback?

valgrind unfortunately does not provide any hints.

[Bug fortran/95537] [11 regression] gfortran.dg/pr95090.f90 since r11-670

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
It might be related.  This testcase and the one in PR95530 exercise
code paths with possibly latent bugs.

Nevertheless, are you able to produce a traceback?

valgrind on x86_64 unfortunately does not provide any useful hints.

[Bug fortran/95503] [9/10/11 Regression] ICE in gfc_is_simply_contiguous, at fortran/expr.c:5844

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Patch posted for review:

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

[Bug fortran/95500] Segfault compiling extra interface on intrinsic

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Will commit Steve's fix as obvious, with a testcase.

[Bug fortran/95530] [11 regression] ICE in gfortran.dg/equiv_11.f90 after r11-594

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-04

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Bill Seurer from comment #4)
> Note that I did this run on a power 9 LE system.

Well, that is already helpful.

Can you please try the following patch?

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 5af44847f9b..0ef7b1b0eff 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -1677,7 +1677,8 @@ typedef struct gfc_common_head
   char use_assoc, saved, threadprivate;
   unsigned char omp_declare_target : 1;
   unsigned char omp_declare_target_link : 1;
-  char name[GFC_MAX_SYMBOL_LEN + 1];
+  /* Provide sufficient space to hold "symbol.eq.1234567890".  */
+  char name[GFC_MAX_SYMBOL_LEN + 1 + 14];
   struct gfc_symbol *head;
   const char* binding_label;
   int is_bind_c;

[Bug fortran/95537] [11 regression] gfortran.dg/pr95090.f90 since r11-670

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Priority|P3  |P4
   Last reconfirmed||2020-06-04

--- Comment #4 from anlauf at gcc dot gnu.org ---
Thanks for the backtrace.

Can you please try the following patch?

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 3ad5559c3ec..1c1626d3fa4 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -4094,7 +4094,8 @@ match_byte_typespec (gfc_typespec *ts)
 match
 gfc_match_decl_type_spec (gfc_typespec *ts, int implicit_flag)
 {
-  char name[GFC_MAX_SYMBOL_LEN + 1];
+  /* Provide sufficient space to hold "pdtsymbol".  */
+  char name[GFC_MAX_SYMBOL_LEN + 1 + 3];
   gfc_symbol *sym, *dt_sym;
   match m;
   char c;
@@ -4284,7 +4285,11 @@ gfc_match_decl_type_spec (gfc_typespec *ts, int
implicit_flag)
return m;
  gcc_assert (!sym->attr.pdt_template && sym->attr.pdt_type);
  ts->u.derived = sym;
- strcpy (name, gfc_dt_lower_string (sym->name));
+ const char* lower = gfc_dt_lower_string (sym->name);
+ size_t len = strnlen (lower, sizeof (name));
+ gcc_assert (len < sizeof (name));
+ memcpy (name, lower, len);
+ name[len] = '\0';
}

   if (sym && sym->attr.flavor == FL_STRUCT)

[Bug fortran/95530] [11 regression] ICE in gfortran.dg/equiv_11.f90 after r11-594

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #6 from anlauf at gcc dot gnu.org ---
In addition to the patch in comment#5, we can "harden" the strcpy:

diff --git a/gcc/fortran/trans-common.c b/gcc/fortran/trans-common.c
index 3775a8bea74..1acc336eacf 100644
--- a/gcc/fortran/trans-common.c
+++ b/gcc/fortran/trans-common.c
@@ -1314,7 +1314,11 @@ finish_equivalences (gfc_namespace *ns)
  c->where = ns->proc_name->declared_at;
else if (ns->is_block_data)
  c->where = ns->sym_root->n.sym->declared_at;
-   strcpy (c->name, z->module);
+
+   size_t len = strlen (z->module);
+   gcc_assert (len < sizeof (c->name));
+   memcpy (c->name, z->module, len);
+   c->name[len] = '\0';
  }
else
  c = NULL;

[Bug fortran/95537] [11 regression] gfortran.dg/pr95090.f90 since r11-670

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Bill Seurer from comment #5)
> Still fails:
> 
> make -k check-gcc-fortran RUNTESTFLAGS=dg.exp=gfortran.dg/pr95090.f90
> 
> FAIL: gfortran.dg/pr95090.f90   -O  (internal compiler error)
> FAIL: gfortran.dg/pr95090.f90   -O  (test for excess errors)

It turns out that this PR and PR95530 are unrelated issues regarding
buffer overflow in different places.

Can you add the patch in this PR, comment#4, and in PR95530 comment#6?

I've "regtested" on x86_64-pc-linux-gnu, but this might miss further
buffer overflows elsewhere.

[Bug fortran/95530] [11 regression] ICE in gfortran.dg/equiv_11.f90 after r11-594

[anlauf at gcc dot gnu.org]

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Created attachment 48679
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48679&action=edit
Joint patch to fix the fallout reported in pr95530 and pr95537

Here's a clean patch that should fix the issues.

[Bug fortran/95530] [11 regression] ICE in gfortran.dg/equiv_11.f90 after r11-594

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #11 from anlauf at gcc dot gnu.org ---
Patch submitted for review:

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

[Bug fortran/95500] Segfault compiling extra interface on intrinsic

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC-11, and backported to 10-branch and 9-branch.
Closing.

Thanks for the report!

[Bug fortran/95530] [11 regression] ICE in gfortran.dg/equiv_11.f90 after r11-594

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC-11, and backported to 10-branch and 9-branch.

Thanks for the report and assistance in pinpointing the origin of the problem!

[Bug fortran/95537] [11 regression] gfortran.dg/pr95090.f90 since r11-670

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC-11, and backported to 10-branch and 9-branch.

Thanks for the report and assistance in pinpointing the origin of the problem!

[Bug fortran/95090] ICE: identifier overflow: 129

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #17 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC-11 and 10-branch.

A backport to 9-branch would need some manual work.  As this is not a
regression, not done.

Thanks for the report!

[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC-11, and backported to 10-branch and 9-branch.

Thanks for the report!

[Bug fortran/95512] gcc/fortran/trans-decl.c:1066: array sanity check after use

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-06-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from anlauf at gcc dot gnu.org ---
This looks like a false positive: dim is the index of the enclosing for loop.

It is also funny that it warns about this statement and not the if preceeding
this one.

[Bug fortran/95374] ICE: gfc_array_size failed

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |accepts-invalid,
   ||ice-on-invalid-code
   Priority|P3  |P4
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-05
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Example z2.f90 is actually invalid code that is not rejected,
since the rhs takes element a(0) which is out-of-bounds, has size 1,
whereas the lhs has size 0.

For the same reason, z1.f90 is invalid code since it accesses a(0).

[Bug fortran/95512] gcc/fortran/trans-decl.c:1066: array sanity check after use

[anlauf at gcc dot gnu.org]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
I didn't write the code, but for more context:

trans.h has:

#define GFC_TYPE_ARRAY_LBOUND(node, dim) \
  (TYPE_LANG_SPECIFIC(node)->lbound[dim])
#define GFC_TYPE_ARRAY_UBOUND(node, dim) \
  (TYPE_LANG_SPECIFIC(node)->ubound[dim])

The loop in trans-decl.c:

  for (dim = GFC_TYPE_ARRAY_RANK (type);
   dim < GFC_TYPE_ARRAY_RANK (type) + GFC_TYPE_ARRAY_CORANK (type); dim++)
{
  if (GFC_TYPE_ARRAY_LBOUND (type, dim) == NULL_TREE)
{
  GFC_TYPE_ARRAY_LBOUND (type, dim) = create_index_var ("lbound",
nest);
  TREE_NO_WARNING (GFC_TYPE_ARRAY_LBOUND (type, dim)) = 1;
}
  /* Don't try to use the unknown ubound for the last coarray dimension. 
*/
  if (GFC_TYPE_ARRAY_UBOUND (type, dim) == NULL_TREE
  && dim < GFC_TYPE_ARRAY_RANK (type) + GFC_TYPE_ARRAY_CORANK (type) -
1)
{
  GFC_TYPE_ARRAY_UBOUND (type, dim) = create_index_var ("ubound",
nest);
  TREE_NO_WARNING (GFC_TYPE_ARRAY_UBOUND (type, dim)) = 1;
}
}

So the relevant check is in the loop header, and the current check is there
for the last index.

Maybe it is bad style, but I still consider it a false positive.
cppcheck's view is probably too narrow to understand the range of dim.

[Bug fortran/95091] ICE in gfc_hash_value, at fortran/class.c:538

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
Created attachment 48695
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48695&action=edit
Patch to adjust buffer sizes

Obvious fix for buffer overflows.

Will submit soon.

[Bug fortran/95091] ICE in gfc_hash_value, at fortran/class.c:538

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
   Priority|P3  |P4
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-06-06

--- Comment #2 from anlauf at gcc dot gnu.org ---
Slightly improved patch posted for review:

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

[Bug fortran/95088] ICE in gfc_build_class_symbol, at fortran/class.c:653

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-06-07
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Priority|P3  |P4
 Ever confirmed|0   |1
 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
I have a patch that is regtesting.

[Bug fortran/95088] ICE in gfc_build_class_symbol, at fortran/class.c:653

[anlauf at gcc dot gnu.org]

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Patch submitted for review:

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

[Bug fortran/95544] ICE in gfc_can_put_var_on_stack, at fortran/trans-decl.c:494

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #5 from anlauf at gcc dot gnu.org ---
Created attachment 48708
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48708&action=edit
Cleaned up patch

Hi Steve,

since there is already a function invalid_null_arg(), it can be reused.

If you do not object, I'll package it for you.

Regarding comment#4, please create a separate PR.

[Bug fortran/95544] ICE in gfc_can_put_var_on_stack, at fortran/trans-decl.c:494

[anlauf at gcc dot gnu.org]

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Submitted for review here:

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

[Bug fortran/95091] ICE in gfc_hash_value, at fortran/class.c:538

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC-11, and backported to 10-branch and 9-branch.

Thanks for the report!

[Bug fortran/95611] ICE in access_attr_decl, at fortran/decl.c:9075

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
I'll commit that as obvious.

[Bug fortran/95611] ICE in access_attr_decl, at fortran/decl.c:9075

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC-11, 10-branch and 9-branch.

Thanks for the report!

[Bug fortran/91640] [9 Regression] ICE: gimplification failed (contiguous expr)

[anlauf at gcc dot gnu.org]

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Tobias,

are you still planning a backport to 9-branch?

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #14 from anlauf at gcc dot gnu.org ---
Why don't we simply set IEEE_SUPPORT_DATATYPE (1._10) to .false.?

use, intrinsic :: ieee_arithmetic
print *, ieee_support_datatype (1._10)
end

We currently print 'T'.

[Bug fortran/95503] [9/10/11 Regression] ICE in gfc_is_simply_contiguous, at fortran/expr.c:5844

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC-11, and on 10-branch and 9-branch.  Closing.

Thanks for the report!