[Bug fortran/101762] ICE with "Every subscript of the target specification must be a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101762 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |10.4 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11- and 10-branch. Backporting further is probably not necessary. Closing. Thanks for the report!
[Bug fortran/104227] [9/10/11/12 Regression] ICE virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104227
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC||anlauf at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-01-25
--- Comment #1 from anlauf at gcc dot gnu.org ---
Obvious fix:
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 4fa05ee7e9b..d6c6767ae9e 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -6151,7 +6151,7 @@ gfc_calculate_transfer_sizes (gfc_expr *source, gfc_expr
*mold, gfc_expr *size,
* If SIZE is present, the result is an array of rank one and size SIZE.
*/
if (result_elt_size == 0 && *source_size > 0 && !size
- && mold->expr_type == EXPR_ARRAY)
+ && (mold->expr_type == EXPR_ARRAY || mold->rank))
{
gfc_error ("% argument of % intrinsic at %L is an "
"array and shall not have storage size 0 when % "
[Bug fortran/104227] [9/10/11/12 Regression] ICE virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104227 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Target Milestone|--- |9.5 Priority|P3 |P4 Status|NEW |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Taking.
[Bug fortran/84784] ICEs: verify_gimple failed with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84784
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 ---
Another reduced testcase:
! { dg-do run }
! { dg-options "-fdefault-integer-8" }
! { dg-require-effective-target fortran_integer_16 }
if (runtime_popcnt(0_16) /= 0) STOP 2
contains
integer function runtime_popcnt (i)
integer(kind=16), intent(in) :: i
runtime_popcnt = popcnt(i)
end function
end
[Bug fortran/84784] ICEs: verify_gimple failed with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84784
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> Another reduced testcase:
>
> ! { dg-do run }
> ! { dg-options "-fdefault-integer-8" }
> ! { dg-require-effective-target fortran_integer_16 }
>
> if (runtime_popcnt(0_16) /= 0) STOP 2
> contains
> integer function runtime_popcnt (i)
> integer(kind=16), intent(in) :: i
> runtime_popcnt = popcnt(i)
> end function
> end
Interestingly, this works for me with 11- and 10-branches, but fails with
12-mainline...
[Bug fortran/84784] ICEs: verify_gimple failed with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84784 --- Comment #4 from anlauf at gcc dot gnu.org --- OK, the following fixes the ICE: diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc index fccf0a9b229..d5564f659f8 100644 --- a/gcc/fortran/trans-intrinsic.cc +++ b/gcc/fortran/trans-intrinsic.cc @@ -7254,13 +7254,15 @@ gfc_conv_intrinsic_popcnt_poppar (gfc_se * se, gfc_expr *expr, int parity) arg2)); /* Combine the results. */ + tree builtin_type = integer_type_node; if (parity) - se->expr = fold_build2_loc (input_location, BIT_XOR_EXPR, result_type, + se->expr = fold_build2_loc (input_location, BIT_XOR_EXPR, builtin_type, call1, call2); else - se->expr = fold_build2_loc (input_location, PLUS_EXPR, result_type, + se->expr = fold_build2_loc (input_location, PLUS_EXPR, builtin_type, call1, call2); + se->expr = convert (result_type, se->expr); return; }
[Bug fortran/104212] ICE in transformational_result, at fortran/simplify.cc:466
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104212 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |11.3 --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed.
[Bug fortran/104227] [9/10/11 Regression] ICE virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104227 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/84784] ICEs: verify_gimple failed with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84784 --- Comment #5 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2022-January/057478.html This fixes gfortran.dg/team_change_1.f90 gfortran.dg/team_number_1.f90 gfortran.dg/popcnt_poppar_2.F90 (-m64, not supported with -m32) I was unable to reproduce gfortran.dg/coarray/sync_3.f90 (with -fcheck=all) gfortran.dg/goacc/nested-function-1.f90 Could somebody else have a look at these and give details? Especially which function or code triggers the error?
[Bug fortran/84787] ICEs: in decompose, at wide-int.h:933 with -default-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84787 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from anlauf at gcc dot gnu.org --- Likely fixed by the patch for pr84784 which also addresses this intrinsic. *** This bug has been marked as a duplicate of bug 84784 ***
[Bug fortran/84784] ICEs: verify_gimple failed with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84784 --- Comment #6 from anlauf at gcc dot gnu.org --- *** Bug 84787 has been marked as a duplicate of this bug. ***
[Bug fortran/32770] [Meta-bug] -fdefault-integer-8 issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770 Bug 32770 depends on bug 84787, which changed state. Bug 84787 Summary: ICEs: in decompose, at wide-int.h:933 with -default-integer-8 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84787 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/83700] [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 Bug 83700 depends on bug 84787, which changed state. Bug 84787 Summary: ICEs: in decompose, at wide-int.h:933 with -default-integer-8 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84787 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/84784] ICEs: verify_gimple failed with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84784 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #8 from anlauf at gcc dot gnu.org --- image_status(), team_number(), popcnt() and poppar() should be fixed. I could not reproduce the other issues except the message gcc/testsuite/gfortran.dg/coarray/sync_3.f90:58:17: 58 | sync images ([1]) | 1 Fatal Error: Sorry, only support for integer kind 4 implemented for image-set at (1) compilation terminated. This is not an ICE, so likely better tracked elsewhere.
[Bug fortran/104128] ICE in gfc_widechar_to_char, at fortran/scanner.c:199
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104128 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed for gcc-12. Closing. Thanks for the report!
[Bug fortran/101135] Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101135 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Last reconfirmed||2022-01-27 Status|UNCONFIRMED |NEW Priority|P3 |P4 Ever confirmed|0 |1 --- Comment #3 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug fortran/101135] Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101135 --- Comment #4 from anlauf at gcc dot gnu.org --- Created attachment 52311 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52311&action=edit Patch that regtests ok. The patch suggested by the reporter is rather close to this one. We need to special-case optional arguments of procedures with bind(c) attribute. I haven't understood the details yet, but excluding those prevents regressions in the c-binding testsuite, e.g. bind-c-contiguous-4.*. We need to fix the pattern for testcase gfortran.dg/missing_optional_dummy_6a.f90 which would have failed with -fsanitize=undefined without this patch.
[Bug fortran/101135] Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101135 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 #5 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-January/057496.html
[Bug fortran/83079] ICE in gfc_widechar_to_char, at fortran/scanner.c:198
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83079 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |10.4 Resolution|--- |FIXED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11- and 10-branch. Closing. Thanks for the report!
[Bug fortran/104127] [9 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104127 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[9/10/11/12 Regression] ICE |[9 Regression] ICE in |in get_array_charlen, at|get_array_charlen, at |fortran/trans-array.c:7244 |fortran/trans-array.c:7244 --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11- and 10-branch so far.
[Bug fortran/104127] [9 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104127 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from anlauf at gcc dot gnu.org --- Fixed on 9-branch for the reported testcase. The extended testcase committed on 10-branch and higher needed deactivating of two lines which seem to require additional fixes and likely failed before. Closing. Thanks for the report!
[Bug fortran/101135] Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101135 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #4) > Created attachment 52311 [details] > Patch that regtests ok. While playing some more with variations of the testcase, I figured that this patch is not complete. It does not fix cases where a call tree consists of procedures with and without the bind(c) attribute. So more work is needed.
[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-01-31 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P4 --- Comment #2 from anlauf at gcc dot gnu.org --- We could limit the size of the resulting array constructor, using e.g. flag_max_array_constructor.
[Bug fortran/104309] Elemental character function should not return array of character variables of different lengths.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104309 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P4 Last reconfirmed||2022-01-31 Version|fortran-dev |12.0 --- Comment #1 from anlauf at gcc dot gnu.org --- I don't think the wording of g95 is explaining what is wrong. Browsing F2018 I saw: C15103 In the specification-expr that specifies a type parameter value of the result of an elemental function, an object designator with a dummy argument of the function as the base object shall appear only as the subject of a specification inquiry (10.1.11), ... And 10.1.11 has: A specification inquiry is a reference to (1) an intrinsic inquiry function other than PRESENT, (2) a type parameter inquiry (9.4.5), (3) ... TRIM and LEN_TRIM are not intrinsic inquiry functions.
[Bug fortran/104331] [10/11/12 Regression] ICE in gfc_simplify_eoshift, at fortran/simplify.cc:2590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104331 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-02-01 CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Obvious fix, similar to other intrinsics: diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc index 8604162cfd5..6483f9c31e7 100644 --- a/gcc/fortran/simplify.cc +++ b/gcc/fortran/simplify.cc @@ -2572,6 +2572,9 @@ gfc_simplify_eoshift (gfc_expr *array, gfc_expr *shift, gfc_expr *boundary, if (arraysize == 0) goto final; + if (array->shape == NULL) +goto final; + arrayvec = XCNEWVEC (gfc_expr *, arraysize); array_ctor = gfc_constructor_first (array->value.constructor); for (i = 0; i < arraysize; i++)
[Bug fortran/104331] [10/11 Regression] ICE in gfc_simplify_eoshift, at fortran/simplify.cc:2590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104331 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 Target Milestone|--- |10.4 Summary|[10/11/12 Regression] ICE |[10/11 Regression] ICE in |in gfc_simplify_eoshift, at |gfc_simplify_eoshift, at |fortran/simplify.cc:2590|fortran/simplify.cc:2590 --- Comment #3 from anlauf at gcc dot gnu.org --- Taking.
[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> We could limit the size of the resulting array constructor, using e.g.
> flag_max_array_constructor.
Sample patch:
diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index 6483f9c31e7..15a2b36eed9 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -8152,6 +8152,15 @@ gfc_simplify_transfer (gfc_expr *source, gfc_expr *mold,
gfc_expr *size)
if (source->expr_type == EXPR_ARRAY && !gfc_array_size (source, &tmp))
gfc_internal_error ("Failure getting length of a constant array.");
+ if (size && mpz_cmp_si (size->value.integer, flag_max_array_constructor) >
0)
+{
+ gfc_error ("The number of elements in the array constructor "
+"at %L requires an increase of the allowed %d "
+"upper limit. See %<-fmax-array-constructor%> "
+"option", &size->where, flag_max_array_constructor);
+ return NULL;
+}
+
/* Create an empty new expression with the appropriate characteristics. */
result = gfc_get_constant_expr (mold->ts.type, mold->ts.kind,
&source->where);
[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #6)
> (In reply to anlauf from comment #2)
> > We could limit the size of the resulting array constructor, using e.g.
> > flag_max_array_constructor.
>
> Sample patch:
Well, thinking some more and rereading the standard text, I see I got it wrong.
A comment in gfc_calculate_transfer_sizes explains what it should be.
So the right thing is simply:
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index d6c6767ae9e..fc97bb1371e 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -6150,7 +6150,7 @@ gfc_calculate_transfer_sizes (gfc_expr *source, gfc_expr
*mold, gfc_expr *size,
* representation is not shorter than that of SOURCE.
* If SIZE is present, the result is an array of rank one and size SIZE.
*/
- if (result_elt_size == 0 && *source_size > 0 && !size
+ if (result_elt_size == 0 && *source_size > 0
&& (mold->expr_type == EXPR_ARRAY || mold->rank))
{
gfc_error ("% argument of % intrinsic at %L is an "
[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311 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 #8 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-February/057499.html
[Bug fortran/104331] [10/11 Regression] ICE in gfc_simplify_eoshift, at fortran/simplify.cc:2590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104331 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.
[Bug fortran/100196] [9/10/11/12 Regression] ICE in reduce_binary_ca, at fortran/arith.c:1364
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100196 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 --- I do not see the ICE for current 12/11/10 but get: pr100196-z1.f90:3:22: 3 | real, parameter :: b = 1 + [a] | 1 Error: Incompatible ranks 0 and 1 in assignment at (1) and pr100196-z5.f90:3:25: 3 | real, parameter :: b(1) = 1 + [a] | 1 Error: Different shape for array assignment at (1) on dimension 1 (1 and 0) The issue is still present on 9-branch, though.
[Bug fortran/91728] Accepts array with wrong shape in a structure constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91728 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING Priority|P3 |P4 Target Milestone|--- |10.4 --- Comment #2 from anlauf at gcc dot gnu.org --- Both testcases in comment#0 are now rejected on 10/11/12: pr91728-z1.f90:7:8: 7 | x = t([1.0]) |1 Error: The shape of component 'a' in the structure constructor at (1) differs from the shape of the declared component for dimension 1 (1/3) I assume this PR is a duplicate of another one that got fixed recently.
[Bug fortran/100196] [9/10/11/12 Regression] ICE in reduce_binary_ca, at fortran/arith.c:1364
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100196 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #18 from anlauf at gcc dot gnu.org --- Created attachment 52346 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52346&action=edit WIP patch This fixes at least some of the testcase given in this PR and regtests OK. May need more testing and fine-tuning.
[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 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 #19 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-February/057520.html
[Bug fortran/104382] Finalization of parent components not compliant with standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382 --- Comment #2 from anlauf at gcc dot gnu.org --- crayftn 11 & 12 output: destructor4(complicated) 2*2. destructor5 (simple2) 5 destructor5 (simple2) 6 destructor2(simple) 2*1 destructor4(complicated) 4., 5. destructor5 (simple2) -1 destructor5 (simple2) -2 destructor2(simple) 3, 4 final_count after assignment = 8 destructor4(complicated) 4., 5. destructor5 (simple2) -1 destructor5 (simple2) -2 destructor2(simple) 3, 4 final_count after deallocation = 12
[Bug fortran/93482] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93482 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|NEW |WAITING --- Comment #3 from anlauf at gcc dot gnu.org --- Seems to have been fixed on mainline, and backported to 11- and 10-branch. Likely a duplicate.
[Bug fortran/77693] ICE in rtl_for_decl_init, at dwarf2out.c:17378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77693 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 Status|NEW |ASSIGNED --- Comment #7 from anlauf at gcc dot gnu.org --- Patch at: https://gcc.gnu.org/pipermail/fortran/2022-February/057529.html
[Bug fortran/104211] ICE in find_array_section, at fortran/expr.cc:1720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104211 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 --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-February/057535.html
[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104573
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 ---
(In reply to kargl from comment #1)
> Only want to access the components of a derived type if we have an actual
> derived type.
I was wondering if we also need to allow BT_CLASS.
So something like the following might also work:
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 266e41e25b1..2fa1acdbd6d 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -1288,15 +1288,17 @@ resolve_structure_cons (gfc_expr *expr, int init)
}
}
- cons = gfc_constructor_first (expr->value.constructor);
-
/* A constructor may have references if it is the result of substituting a
parameter variable. In this case we just pull out the component we
want. */
if (expr->ref)
comp = expr->ref->u.c.sym->components;
- else
+ else if (expr->ts.u.derived)
comp = expr->ts.u.derived->components;
+ else
+return false;
+
+ cons = gfc_constructor_first (expr->value.constructor);
for (; comp && cons; comp = comp->next, cons = gfc_constructor_next (cons))
{
[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104573 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #3) > I'm not sure. I don't use CLASSes, so only know a bit > about them. If I check F18:7.5.6, I find > > C786 (R753) A final-subroutine-name shall be the name of a moduler >procedure with exactly one dummy argument. That argument shall >be nonoptional and shall be a noncoarray, nonpointer, nonallocatable, >*** nonpolymorphic *** >variable of the derived type being defined. All length type >parameters of the dummy argument shall be assumed. The dummy >argument shall not have the INTENT (OUT) or VALUE attribute. Steve, there's no finalization referred to in this PR. Can you please recheck?
[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104573 --- Comment #6 from anlauf at gcc dot gnu.org --- The patch in comment#2 regtests ok. I've been thinking a little to find cases where there should be a difference to the patch in comment#1, but did not succeed so far. At least not with minor variations of the original testcases.
[Bug fortran/104573] ICE in resolve_structure_cons, at fortran/resolve.cc:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104573 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 #7 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-February/057554.html
[Bug fortran/104211] ICE in find_array_section, at fortran/expr.cc:1720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104211 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.3 --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on mainline and applied to 11-branch. Closing. Thanks for the report!
[Bug fortran/104585] incorrect error for dummy arguments with both VALUE and DIMENSION attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104585 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from anlauf at gcc dot gnu.org --- Duplicate. *** This bug has been marked as a duplicate of bug 102369 ***
[Bug fortran/102369] VALUE attribute for arrays not allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102369 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||a.shahmoradi at gmail dot com --- Comment #3 from anlauf at gcc dot gnu.org --- *** Bug 104585 has been marked as a duplicate of this bug. ***
[Bug fortran/71196] f951: internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71196
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #9 from anlauf at gcc dot gnu.org ---
The following patch seems to fix some issues of this PR:
diff --git a/gcc/fortran/data.cc b/gcc/fortran/data.cc
index f7c91437439..e691c341c28 100644
--- a/gcc/fortran/data.cc
+++ b/gcc/fortran/data.cc
@@ -463,6 +463,10 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue,
mpz_t index,
break;
case REF_COMPONENT:
+ /* Find ultimate component in a chain. */
+ if (ref->next && ref->next->type == REF_COMPONENT)
+ continue;
+
if (init == NULL)
{
/* Setup the expression to hold the constructor. */
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |11.3 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #22 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11-branch. Closing. Thanks for the report!
[Bug fortran/77693] ICE in rtl_for_decl_init, at dwarf2out.c:17378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77693 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed for gcc-12. Closing. Thanks for the report!
[Bug fortran/106948] pure subroutine with pure procedure as dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106948 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-09-15 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Likely a problem due to use of submodules. A simplified, but otherwise equivalent version, such as below, works: module a implicit none interface new module procedure :: b end interface new contains subroutine b(x, f) integer, intent(inout) :: x interface pure function f(x) result(r) real, intent(in) :: x real :: r end function f end interface x = int(f(real(x)) * 0.1) end subroutine b end module a
[Bug fortran/106911] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.cc:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106911 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-15 CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. Potential fix for the ICE: diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc index bc178d54891..c7202ec0b9a 100644 --- a/gcc/fortran/simplify.cc +++ b/gcc/fortran/simplify.cc @@ -3955,6 +3955,9 @@ gfc_simplify_ishftc (gfc_expr *e, gfc_expr *s, gfc_expr *sz) return NULL; gfc_extract_int (sz, &ssize); + + if (ssize > isize || ssize <= 0) + return NULL; } else ssize = isize; However, this would change the issue to an accepts-invalid.
[Bug fortran/104314] ICE in deferred_op_assign, at fortran/resolve.cc:11794
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104314 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 mainline. Closing. Thanks for the report!
[Bug fortran/106857] [10/11/12/13 Regression] ICE in gfc_simplify_pack, at fortran/simplify.cc:6438 since r12-4278-g74ccca380cde5e79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106857
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 #3 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> Obvious fix for NULL pointer dereference:
>
> diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
> index bc178d54891..d5c4fe8443d 100644
> --- a/gcc/fortran/simplify.cc
> +++ b/gcc/fortran/simplify.cc
> @@ -6431,7 +6432,7 @@ gfc_simplify_pack (gfc_expr *array, gfc_expr *mask,
> gfc_expr *vector)
>/* Copy only those elements of ARRAY to RESULT whose
>MASK equals .TRUE.. */
>mask_ctor = gfc_constructor_first (mask->value.constructor);
> - while (mask_ctor)
> + while (mask_ctor && array_ctor)
> {
> if (mask_ctor->expr->value.logical)
> {
This regtests fine. Taking.
[Bug fortran/103287] [12 Regression] ICE in argument_rank_mismatch, at fortran/interface.c:2240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103287 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||jrfsousa at gcc dot gnu.org --- Comment #8 from anlauf at gcc dot gnu.org --- *** Bug 100024 has been marked as a duplicate of this bug. ***
[Bug fortran/100024] [10/11/12/13 Regression] ICE on subroutine missing explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100024 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- The basic issue seems to have been fixed by the patch for PR103287, and the present patch would collide with that one. Marking as fixed & duplicate. *** This bug has been marked as a duplicate of bug 103287 ***
[Bug fortran/100025] [10/11/12/13 Regression] ICE on subroutine missing explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100025 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||anlauf at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from anlauf at gcc dot gnu.org --- The basic issue seems to have been fixed by the patch for PR103287, and the present patch would collide with that one. Marking as fixed & duplicate. *** This bug has been marked as a duplicate of bug 103287 ***
[Bug fortran/103287] [12 Regression] ICE in argument_rank_mismatch, at fortran/interface.c:2240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103287 --- Comment #9 from anlauf at gcc dot gnu.org --- *** Bug 100025 has been marked as a duplicate of this bug. ***
[Bug fortran/100132] Optimization breaks pointer association
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100132
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 José Rui Faustino de Sousa from comment #1)
> Patch posted
>
> https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html
The patch is technically fine and regtests ok, but was unfortunately never
reviewed.
The basic fix can be slightly shortened to:
diff --git a/gcc/fortran/trans-types.cc b/gcc/fortran/trans-types.cc
index 0ea7c74a6f1..c062a5b29d7 100644
--- a/gcc/fortran/trans-types.cc
+++ b/gcc/fortran/trans-types.cc
@@ -3054,12 +3054,23 @@ create_fn_spec (gfc_symbol *sym, tree fntype)
for (f = gfc_sym_get_dummy_args (sym); f; f = f->next)
if (spec_len < sizeof (spec))
{
- if (!f->sym || f->sym->attr.pointer || f->sym->attr.target
+ bool is_class = false;
+ bool is_pointer = false;
+
+ if (f->sym)
+ {
+ is_class = f->sym->ts.type == BT_CLASS && CLASS_DATA (f->sym)
+ && f->sym->attr.class_ok;
+ is_pointer = is_class ? CLASS_DATA (f->sym)->attr.class_pointer
+ : f->sym->attr.pointer;
+ }
+
+ if (f->sym == NULL || is_pointer || f->sym->attr.target
|| f->sym->attr.external || f->sym->attr.cray_pointer
|| (f->sym->ts.type == BT_DERIVED
&& (f->sym->ts.u.derived->attr.proc_pointer_comp
|| f->sym->ts.u.derived->attr.pointer_comp))
- || (f->sym->ts.type == BT_CLASS
+ || (is_class
&& (CLASS_DATA (f->sym)->ts.u.derived->attr.proc_pointer_comp
|| CLASS_DATA (f->sym)->ts.u.derived->attr.pointer_comp))
|| (f->sym->ts.type == BT_INTEGER && f->sym->ts.is_c_interop))
I can take care of it for you.
[Bug fortran/100132] Optimization breaks pointer association
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100132 --- Comment #4 from anlauf at gcc dot gnu.org --- Pinged here: https://gcc.gnu.org/pipermail/fortran/2022-September/058212.html
[Bug fortran/82868] ICE in generate_coarray_sym_init, at fortran/trans-decl.c:5203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82868 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Keywords||ice-on-valid-code --- Comment #2 from anlauf at gcc dot gnu.org --- Potential fix: diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc index 908a4c6d42e..5d16d640322 100644 --- a/gcc/fortran/trans-decl.cc +++ b/gcc/fortran/trans-decl.cc @@ -5529,6 +5529,7 @@ generate_coarray_sym_init (gfc_symbol *sym) if (sym->attr.dummy || sym->attr.allocatable || !sym->attr.codimension || sym->attr.use_assoc || !sym->attr.referenced + || sym->attr.associate_var || sym->attr.select_type_temporary) return;
[Bug fortran/106987] [10/11/12/13 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-09-20 Status|UNCONFIRMED |NEW Keywords||ice-on-invalid-code --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. We are not really good at recovering from arithmetic errors.
[Bug fortran/106986] [10/11/12/13 Regression] ICE in simplify_findloc_nodim, at fortran/simplify.cc:5675
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106986 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-09-20 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Obvious NULL pointer dereference, fixed by: diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc index 140c17721a7..5883689066d 100644 --- a/gcc/fortran/simplify.cc +++ b/gcc/fortran/simplify.cc @@ -5895,6 +5899,7 @@ gfc_simplify_findloc (gfc_expr *array, gfc_expr *value, gfc_expr *dim, bool back_val = false; if (!is_constant_array_expr (array) + || array->shape == NULL || !gfc_is_constant_expr (dim)) return NULL;
[Bug fortran/106985] ICE in gfc_simplify_expr, at fortran/expr.cc:2290
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106985
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-09-20
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
NULL pointer dereference. Untested fix:
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index be94c18c836..bedf361c00a 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -2287,7 +2287,8 @@ gfc_simplify_expr (gfc_expr *p, int type)
initialization expression, or we want a subsection. */
if (p->symtree->n.sym->attr.flavor == FL_PARAMETER
&& (gfc_init_expr_flag || p->ref
- || p->symtree->n.sym->value->expr_type != EXPR_ARRAY))
+ || (p->symtree->n.sym->value
+ && p->symtree->n.sym->value->expr_type != EXPR_ARRAY)))
{
if (!simplify_parameter_variable (p, type))
return false;
[Bug fortran/106985] ICE in gfc_simplify_expr, at fortran/expr.cc:2290
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106985 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 |RESOLVED Resolution|--- |FIXED --- Comment #3 from anlauf at gcc dot gnu.org --- Fixed on mainline. Closing. Thanks for the report!
[Bug fortran/106986] [10/11/12/13 Regression] ICE in simplify_findloc_nodim, at fortran/simplify.cc:5675
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106986 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |10.5 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from anlauf at gcc dot gnu.org --- Taking.
[Bug fortran/82868] ICE in generate_coarray_sym_init, at fortran/trans-decl.c:5203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82868 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 #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-September/058231.html
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-09-21 --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. Comment#0 is fixed by e.g. diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc index d57059a375f..1f290050189 100644 --- a/gcc/fortran/arith.cc +++ b/gcc/fortran/arith.cc @@ -2238,6 +2238,9 @@ gfc_real2complex (gfc_expr *src, int kind) arith rc; bool did_warn = false; + if (src->ts.type != BT_REAL) +return NULL; + result = gfc_get_constant_expr (BT_COMPLEX, kind, &src->where); mpc_set_fr (result->value.complex, src->value.real, GFC_MPC_RND_MODE); but comment#1 has a different stack trace, as it hits an assert.
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 --- Comment #3 from anlauf at gcc dot gnu.org --- Created attachment 53601 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53601&action=edit Hackish patch This patch fixes all ICE in comment#0 and comment#1. However, it papers over the issue that we forget about earlier errors: while print *, [real :: -'1'] is diagnosed for the invalid unary "-", print *, 2 * [real :: -'1'] will throw a different error. So I'm not really happy with the hack.
[Bug fortran/100103] Automatic reallocation fails inside select rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100103 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Rebased version pinged here: https://gcc.gnu.org/pipermail/fortran/2022-September/058235.html
[Bug fortran/106857] [10/11/12/13 Regression] ICE in gfc_simplify_pack, at fortran/simplify.cc:6438 since r12-4278-g74ccca380cde5e79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106857 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/106945] [10/11/12/13 Regression] ICE: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106945 --- Comment #3 from anlauf at gcc dot gnu.org --- It is -fcheck=bounds that is required to trigger the failure. Replacing -ftrapv by -fsanitize=undefined produces the same error.
[Bug fortran/100245] ICE on automatic reallocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100245 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |10.5 --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Thanks for the patch!
[Bug fortran/102900] ICE via gfc_class_data_get with alloc_comp_class_4.f03 or proc_ptr_52.f90 using -fcheck=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102900 --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #5) > (In reply to anlauf from comment #4) > > The ICE is resolved by Jose's patch to PR100136, which was just accepted. Update: with current mainline (PR100136 now fixed), the runtime failure of alloc_comp_class_4.f03 with -fcheck=all is due to a missing allocate in function c_init2. Adding allocate (c_init2) resolves this. This testcase is thus incompatible with -fcheck=pointer. > ... but not for proc_ptr_52.f90 with -fcheck=pointer This one remains.
[Bug libfortran/107031] endfile truncates file at wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 anlauf at gcc dot gnu.org changed: What|Removed |Added Component|fortran |libfortran Ever confirmed|0 |1 Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-25 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. It appears that this issue exists since 2005.
[Bug libfortran/107031] endfile truncates file at wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #2) > gfortran's current behavior is correct. > > >12.3.4.4 File position after data transfer > >In all other cases, the file is positioned after the record just >read or written and that record becomes the preceding record. > >12.8.3 ENDFILE statement > >Execution of an ENDFILE statement for a file connected for sequential >access writes an endfile record as the next record of the file. > > After reading '5', the file is position at the record that contains '6'. > So, ENDIFLE writes the endfile record after the record with '6'. Hmm, interpretation of text? I read "as the next record", not "after the next record". gfortran differs here from Intel, NAG, Nvidia, AMD Flang, Crayftn.
[Bug fortran/100029] ICE on subroutine call with allocatable polymorphic assumed-rank argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100029 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 --- Rebased patch pinged here: https://gcc.gnu.org/pipermail/fortran/2022-September/058247.html
[Bug fortran/106986] [10/11/12/13 Regression] ICE in simplify_findloc_nodim, at fortran/simplify.cc:5675
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106986 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on all affected open branches. Closing. Thanks for the report!
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #4) > I think we need to expand the checking in array.cc > > /* Convert components of an array constructor to the type in ts. */ > > static match > walk_array_constructor (gfc_typespec *ts, gfc_constructor_base head) > > I haven't had time to look deeper, but this function should be comparing > the typespecs of REAL and -'1' or +'1'. That should fail. I suspect that > the EXPR_OP of type_expr is allowing the array constructor walk to succeed. You mean sth. like: diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc index bbdb5b392fc..78a15917cec 100644 --- a/gcc/fortran/array.cc +++ b/gcc/fortran/array.cc @@ -1213,7 +1213,7 @@ walk_array_constructor (gfc_typespec *ts, gfc_constructor_base head) return m; } else if (!gfc_convert_type_warn (e, ts, 1, 1, true) - && e->ts.type != BT_UNKNOWN) + && (e->ts.type != BT_UNKNOWN || e->expr_type == EXPR_OP)) return MATCH_ERROR; } return MATCH_YES; in addition to the fix from comment#2? This works and regtests ok.
[Bug fortran/107054] [10/11/12/13 Regression] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8461
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107054
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|--- |10.5
CC||anlauf at gcc dot gnu.org
Last reconfirmed||2022-09-27
Status|UNCONFIRMED |NEW
Priority|P3 |P4
--- Comment #2 from anlauf at gcc dot gnu.org ---
Confirmed.
We hit an assert that is fixed by:
diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index c0fbd0ed7c2..6ac92cf9db8 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -8458,9 +8458,16 @@ gfc_simplify_unpack (gfc_expr *vector, gfc_expr *mask,
gfc_expr *field)
{
if (mask_ctor->expr->value.logical)
{
- gcc_assert (vector_ctor);
- e = gfc_copy_expr (vector_ctor->expr);
- vector_ctor = gfc_constructor_next (vector_ctor);
+ if (vector_ctor)
+ {
+ e = gfc_copy_expr (vector_ctor->expr);
+ vector_ctor = gfc_constructor_next (vector_ctor);
+ }
+ else
+ {
+ gfc_free_expr (result);
+ return NULL;
+ }
}
else if (field->expr_type == EXPR_ARRAY)
e = gfc_copy_expr (field_ctor->expr);
[Bug fortran/107054] [10/11/12/13 Regression] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8461
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107054 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 #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-September/058250.html
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #6) > Yes, that would work! I was thinking of something more complex > such as looking at the types of the operand(s), but simplification > probably handles +1 and -1 correctly and punts on +'1' and -'1'. I played some more and found that we would regress on e.g. print *, [real :: 1, +real(2.0)] while print *, [real :: 1, real(2.0)] is fine. So we need a better solution...
[Bug libfortran/107068] Run-time error when reading logical arrays with a namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Component|fortran |libfortran Last reconfirmed||2022-09-28 --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. Renaming the second variable (e.g. flp -> xlp) works around the problem, as well as interchanging the lines in the namelist input. It appears that while scanning the namelist input we first see the T, then F, for which we try to determine if it means .false. or is part of a variable name, and then possibly screw up because we see a comma when referring to an element of rank-2 array flp. There is also no error when using a rank-1 array for flp and referring to flp(2) etc.
[Bug fortran/107074] ICE: Bad IO basetype (8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107074 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-09-28 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. (gdb) p ts->type $3 = BT_PROCEDURE We don't have an implementation for printing the address(?) of a procedure, which is what NVidia does. Intel does not like the code, but for different reasons. Looking at the standard, I only found: C1233 (R1217) An expression that is an output-item shall not have a value that is a procedure pointer. While a is not a procedure pointer, I don't see why such a procedure reference can be allowed.
[Bug fortran/107074] ICE: Bad IO basetype (8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107074 --- Comment #2 from anlauf at gcc dot gnu.org --- We also crash in the same place on: program p implicit none procedure(real), pointer :: a print *, merge(a, a, .true.) end
[Bug fortran/107075] ICE in get, at cgraph.h:461
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107075 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-09-28 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Small variation: program p implicit none integer, target :: a(3) ! save :: a a = [1, 2, 3] block integer, pointer :: z => a(2) z = 7 end block end Uncommenting the 'save' also avoids the ICE, as does adding -fno-automatic .
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 --- Comment #10 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #9) > This catches the parenthesis. ... but it is still not sufficient to handle ugly stuff like: print *, [real :: 1, +(+(.true.))] * 2
[Bug fortran/107075] ICE in get, at cgraph.h:461
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107075 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Mikael Morin from comment #3) > (In reply to Richard Biener from comment #2) > > > > But maybe 'z' shouldn't be of static storage duration ... > > No, I think it shouldn't. A should be static, and Z should not. Well, I think the declaration integer, pointer :: z => a(2) makes pointer z IMPLICIT_SAVE. At least I couldn't find anything in the standard that makes an exception for declarations in a BLOCK construct. This is confirmed by Intel and Cray and by replacing 'program p' by 'subroutine p'. And in line with gfortran... Error: Pointer initialization target at (1) must have the SAVE attribute
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 --- Comment #14 from anlauf at gcc dot gnu.org --- (In reply to Mikael Morin from comment #13) > If we pass this check, we proceed to reduce_binary, where if one (or both) > of the operands is an array, we do numerical evaluation for every element of > the array. > > With the guarding check above, it is safe, with the assumption that elements > of an array have the same type as the array itself. If that condition is > not true, well, it doesn't work obviously. > > I don't see right now where an additional check would fit well, but the fix > doesn't belong to walk_array_constructor in any case from my point of view. We could walk through the elements of each array passed to reduce_binary and check the types of the elements there, or do this check in a somewhat more clever way than in the patch attached to comment#3. This patch tried to perform checks in reduce_binary_ac, but I was not happy with that particular implementation. When looping over the elements, we currently have gfc_simplify_expr (c->expr, 0); if (c->expr->expr_type == EXPR_CONSTANT) rc = eval (c->expr, op2, &r); else rc = reduce_binary_ac (eval, c->expr, op2, &r); and do not handle the case that c->expr->ts.type == BT_UNKNOWN. Should we return sth. like rc = ARITH_INCOMMENSURATE, except that it is not array .op. array?
[Bug fortran/107054] [10/11/12/13 Regression] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8461
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107054 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on all affected branches. Closing. Thanks for the report!
[Bug fortran/82868] ICE in generate_coarray_sym_init, at fortran/trans-decl.c:5203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82868 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |10.5 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/83700] [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 Bug 83700 depends on bug 82868, which changed state. Bug 82868 Summary: ICE in generate_coarray_sym_init, at fortran/trans-decl.c:5203 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82868 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/102334] [12/13 Regression] ICE in trans_associate_var, at fortran/trans-stmt.c:1794 since r12-1482-g1de31913d20a467b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102334 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|NEW |WAITING --- Comment #4 from anlauf at gcc dot gnu.org --- Both testcases in comment#0 work for me with current mainline. Do we know what fixed it?
[Bug fortran/102312] [10/11 Regression] ICE in gfc_get_dtype_rank_type, at fortran/trans-types.c:1558 since r9-5424-g92f3a180aaf6f3cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102312 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Both testcases work for me on current mainline. Do we know what fixed it?
[Bug fortran/100103] Automatic reallocation fails inside select rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100103 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |12.3 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-13, and on 12-branch. Closing. Thanks for the patch!
[Bug fortran/100132] Optimization breaks pointer association
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100132 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |10.5 Resolution|--- |FIXED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the patch!
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #53601|0 |1 is obsolete|| --- Comment #16 from anlauf at gcc dot gnu.org --- Created attachment 53651 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53651&action=edit Revised patch This variant adds a check after the place Mikael pointed out, and which verifies that the types of all elements of an array ctor are the same. Testing so far indicates that it is robust enough for all cases discussed in this PR, although it mostly emits Error: Cannot convert UNKNOWN to ... for every expression involving a binary operator. Is this going into the right direction?
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 --- Comment #17 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #16) > Created attachment 53651 [details] > Revised patch Unfortunately this regresses on gfortran.dg/pr91552.f90, e.g. print *, 2 * [real :: 1, [2], 3]
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #53651|0 |1 is obsolete|| --- Comment #20 from anlauf at gcc dot gnu.org --- Created attachment 53659 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53659&action=edit Next try. (In reply to Mikael Morin from comment #18) > Well, a new return code seems better (ARITH_INVALID_TYPE ?). > I think it's better to move the check to the various gfc_arith_times, > gfc_arith_plus, gfc_arith_concat etc, because only those functions know what > type is appropriate and what is not. > Admittedly BT_UNKNOWN is probably never appropriate, and the check could be > done in reduce_binary_ac, but then it should be in reduce_binary_ca, > reduce_binary_aa and reduce_unary as well. > Then what's missing is a goto runtime in eval_intrinsic if evaluation > returns ARITH_INVALID_TYPE. > That's the first solution. Here's a patch that introduces ARITH_INVALID_TYPE and handles errors in reduce_unary, reduce_binary_ac, reduce_binary_ca, and reduce_binary_aa.
[Bug fortran/107074] ICE: Bad IO basetype (8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107074
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 ---
Potential fix:
diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc
index 9f86815388c..2f1a7be04aa 100644
--- a/gcc/fortran/trans-io.cc
+++ b/gcc/fortran/trans-io.cc
@@ -2529,6 +2529,17 @@ transfer_expr (gfc_se * se, gfc_typespec * ts, tree
addr_expr,
}
gcc_fallthrough ();
default:
+ if (ts->type == BT_PROCEDURE
+ && code->expr1
+ && code->expr1->symtree
+ && code->expr1->symtree->n.sym)
+ {
+ if (code->expr1->symtree->n.sym->attr.proc_pointer)
+ gfc_error ("Procedure pointer at %C cannot be an output item");
+ else
+ gfc_error ("Procedure at %C cannot be an output item");
+ return;
+ }
gfc_internal_error ("Bad IO basetype (%d)", ts->type);
}
