[Bug fortran/101327] ICE in find_array_element, at fortran/expr.c:1355
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101327 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #3) > I no longer have the ability to commit changes, > so I won't being submitting patches to fortran@ > and gcc-patches@ for review. I'll simply add > patches to bug reports and move on. You rarely say whether the patch regtests fine. Would be a nice-to-have. > My current method of development: > > 1) git clone humble into gccx/ > 2) Develop a patch and test patch. > 3) git diff HEAD > prXXX.diff > 4) Place diff into PR. > 5) Repeat 2)-4) until gccx/ tree gets messed up > 6) rm -rf gccx/ and goto 1) Probably not the most common nor most efficient workflow when using git... Anyway, the current patch is obvious enough. I could commit it for you.
[Bug fortran/99819] [9 Regression] ICE in gfc_defer_symbol_init, at fortran/trans-decl.c:841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99819 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[9/10 Regression] ICE in|[9 Regression] ICE in |gfc_defer_symbol_init, at |gfc_defer_symbol_init, at |fortran/trans-decl.c:841|fortran/trans-decl.c:841 --- Comment #9 from anlauf at gcc dot gnu.org --- Cherry-picked to 10-branch after verifying that it regtests fine.
[Bug fortran/87737] ICE tree check: expected ssa_name, have addr_expr in remap_gimple_op_r, at tree-inline.c:923
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87737 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 mainline for gcc-12, and backported to 11-branch. Closing. Thanks for the report!
[Bug fortran/101349] ICE in gfc_get_descriptor_field, at fortran/trans-array.c:140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101349 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from anlauf at gcc dot gnu.org --- Committed as obvious. Fixed.
[Bug fortran/102113] parsing error in assigned goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102113 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.
[Bug fortran/101327] ICE in find_array_element, at fortran/expr.c:1355
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101327 --- Comment #5 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2021-August/056455.html
[Bug fortran/56985] gcc/fortran/resolve.c:920: "'%s' in cannot appear in COMMON ..."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56985 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 --- Submitted: https://gcc.gnu.org/pipermail/fortran/2021-August/056457.html
[Bug fortran/56985] gcc/fortran/resolve.c:920: "'%s' in cannot appear in COMMON ..."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56985 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 for gcc-12.
[Bug fortran/83865] ICE in wide_int_to_tree_1, at tree.c:1567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83865 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 --- As found in comment#0, it appears to be the array constructor for length 0 which is mishandled. allocate (z, source=[ character(1) :: 'a']) ! works allocate (z, source=[ character(0) :: 'a']) ! ICEs
[Bug fortran/93834] [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93834 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|anlauf at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #7 from anlauf at gcc dot gnu.org --- Patch withdrawn after review.
[Bug fortran/102180] New: Improve checking of assume size array spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102180
Bug ID: 102180
Summary: Improve checking of assume size array spec
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gcc dot gnu.org
Target Milestone: ---
F2018 has:
8.5.8.5 Assumed-size array
R821 assumed-implied-spec is [ lower-bound : ] *
We currently give a misleading error message for:
subroutine s(x)
real :: x(0:*) ! legal
end
subroutine t(x)
real :: x(:*) ! illegal
end
uuu.f90:6:14:
6 | real :: x(:*) ! illegal
| 1
Error: Expected another dimension in array declaration at (1)
A possibly better error message could be:
uuu.f90:6:15:
6 | real :: x(:*) ! illegal
| 1
Error: A lower bound must precede colon in assumed size array specification at
(1)
which is obtained by the patch:
diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index b858bada18a..56d26455972 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -481,6 +481,13 @@ match_array_element_spec (gfc_array_spec *as)
return AS_ASSUMED_SIZE;
}
+ if (gfc_match (" : * ") == MATCH_YES)
+{
+ gfc_error ("A lower bound must precede colon in "
+"assumed size array specification at %C");
+ return AS_UNKNOWN;
+}
+
if (gfc_match_char (':') == MATCH_YES)
return AS_DEFERRED;
This might be important for some other PRs, as this affects the return value
of match_array_element_spec. This is also potentially relevant for illegal
coarray specs, such as
integer :: a[1:,:*]
where match_array_element_spec currently returns AS_DEFERRED for a badly
specified dimension.
[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #17 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and backported to 11-branch. Closing. Thanks for the report!
[Bug fortran/93794] [9 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93794 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/93924] [OOP] ICE with procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from anlauf at gcc dot gnu.org --- Should be fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/93925] Invalid memory reference upon call of a routine taking a procedure pointer as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from anlauf at gcc dot gnu.org --- Should be fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/20585] [meta-bug] Fortran 2003 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 Bug 20585 depends on bug 93925, which changed state. Bug 93925 Summary: Invalid memory reference upon call of a routine taking a procedure pointer as argument https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/99125] [9 Regression] ICE: gimplification failed (gimplify.c:15068)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99125 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from anlauf at gcc dot gnu.org --- Should be fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/99819] [9 Regression] ICE in gfc_defer_symbol_init, at fortran/trans-decl.c:841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99819 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from anlauf at gcc dot gnu.org --- Pushed fix by Paul to all open branches. Closing. Thanks for the report!
[Bug fortran/46991] [OOP] polymorphic assumed-size actual arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46991 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Pushed the fix by Paul to remaining open branches, but missed that the PR number was off due to a typo. Closing. Thanks for the report!
[Bug fortran/92065] [9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #32 from anlauf at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #29) > r12-570-ga2c593009fef1564dbef2237ee71e9fd08f5361e fixed it. This fix has been backported to all open branches. I verified that the ICE is now gone for the testcae in comment#0. Closing this PR. Please reopen if there is something that has been missed.
[Bug libfortran/102111] Segfault with associate to derived type with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102111 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-09-06 Keywords||wrong-code --- Comment #3 from anlauf at gcc dot gnu.org --- I get a memory corruption on x86_64-pc-linux-gnu when adding a print as in comment#1. valgrind complains about: Invalid free() / delete / delete[] / realloc() So I guess it is not (fully) fixed yet.
[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314
--- Comment #8 from anlauf at gcc dot gnu.org ---
I am testing the following patch which fixes comment#0:
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 2e49a673e15..f2e8896b562 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -2169,6 +2169,24 @@ add_init_expr_to_sym (const char *name, gfc_expr
**initp, locus *var_locus)
sym->as->type = AS_EXPLICIT;
}
+ /* Ensure that explicit bounds are simplified. */
+ if (sym->attr.flavor == FL_PARAMETER && sym->attr.dimension
+ && sym->as->type == AS_EXPLICIT)
+ {
+ for (int dim = 0; dim < sym->as->rank; ++dim)
+ {
+ gfc_expr *e;
+
+ e = sym->as->lower[dim];
+ if (e->expr_type != EXPR_CONSTANT)
+ gfc_reduce_init_expr (e);
+
+ e = sym->as->upper[dim];
+ if (e->expr_type != EXPR_CONSTANT)
+ gfc_reduce_init_expr (e);
+ }
+ }
+
/* Need to check if the expression we initialized this
to was one of the iso_c_binding named constants. If so,
and we're a parameter (constant), let it be iso_c.
[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314 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 #9 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-September/056492.html
[Bug fortran/102240] [PDT] derived type parameter does not shadow variable name in enclosing scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102240 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-09-08 Ever confirmed|0 |1 Summary|[F03] derived type |[PDT] derived type |parameter does not shadow |parameter does not shadow |variable name in enclosing |variable name in enclosing |scope |scope Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug fortran/92805] gfortran: blanks within literal constants should not be allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92805
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 ---
(In reply to Steve Kargl from comment #4)
> Tested.
I tried to resurrect your patch, but it partly misses on the following:
integer, parameter :: ck = kind ("a") ! default character kind
print *, ck_"a"
print *, ck _"a"
print *, ck_ "a"
print *, 1_"a"
print *, 1 _"a"
print *, 1_ "a"
end
pr92805.f90:3:19:
3 | print *, ck _"a"
| 1
Error: Syntax error in PRINT statement at (1)
pr92805.f90:4:20:
4 | print *, ck_ "a"
|1
Error: Syntax error in PRINT statement at (1)
For some reason we detect only some of the syntax violations.
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #28 from anlauf at gcc dot gnu.org --- (In reply to Toon Moene from comment #27) > Yes, I am now convince this works (64 leads to stop 1, but 63 works). So has this been definitely fixed, and can we close it?
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 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 --- (In reply to Steve Kargl from comment #7) > This regresses okay. Still does. Shall I submit it for review, commit for you, or let it bit-rot?
[Bug fortran/97589] Segementation fault when allocating coarrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED CC||anlauf at gcc dot gnu.org Status|WAITING |RESOLVED --- Comment #30 from anlauf at gcc dot gnu.org --- Thanks for the confirmation! Closing.
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 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 Keywords||wrong-code --- Comment #12 from anlauf at gcc dot gnu.org --- Here's the mail to the ML: https://gcc.gnu.org/pipermail/fortran/2021-September/056494.html Unless there is fallout, I'll see if this can be backported to open branches.
[Bug fortran/53699] Missing "restrict" qualifier for OPTIONAL dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53699 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from anlauf at gcc dot gnu.org --- PR100988 has a draft patch for the same issue. *** This bug has been marked as a duplicate of bug 100988 ***
[Bug fortran/100988] Missed optimization: RESTRICT missing for optional arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100988 --- Comment #1 from anlauf at gcc dot gnu.org --- *** Bug 53699 has been marked as a duplicate of this bug. ***
[Bug fortran/100988] Missed optimization: RESTRICT missing for optional arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100988 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-09-09 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug fortran/100110] Parameterized Derived Types, problems with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100110 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from anlauf at gcc dot gnu.org --- Backported Paul's fix to remaining open branches. Closing. Thanks to everybody!
[Bug fortran/98472] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:7352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98472 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED CC||anlauf at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- Backported to remaining open branches after verifying that it works. Closing. Thanks to everybody involved!
[Bug fortran/93701] ICE on associate of wrongly accessed array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93701 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED CC||anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Backported to remaining open branches after verifying that the fix works. Closing. Thanks to all!
[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477 Bug 87477 depends on bug 93701, which changed state. Bug 93701 Summary: ICE on associate of wrongly accessed array https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93701 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/97723] type bound ASSIGNMENT(=) within select rank block wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||anlauf at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Backported Paul's fix to 10-branch after verifying that it does the job. The backport to 9-branch would require more work, thus not done. Closing.
[Bug fortran/97694] ICE with optional assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED CC||anlauf at gcc dot gnu.org --- Comment #10 from anlauf at gcc dot gnu.org --- Backported Paul's fix to 10-branch after verifying that it does the job. The backport to 9-branch would require more work, thus not done. Closing.
[Bug fortran/98565] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98565 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED CC||anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Backported Paul's fix to remaining open branches after verifying that it does the job. Closing. Thanks to all!
[Bug fortran/97612] [F08] Structure constructor of type with nested allocatable array components fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97612 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED CC||anlauf at gcc dot gnu.org Status|ASSIGNED|RESOLVED --- Comment #8 from anlauf at gcc dot gnu.org --- Backported to remaining open branches after verifying that it works. Closing. Thanks to all!
[Bug fortran/85130] Substrings out of range are not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85130 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- F2018 has the following changed text in 9.4.1 Substrings: ... If the starting point is greater than the ending point, the substring has length zero; otherwise, both the starting point and the ending point shall be within the range 1, 2, ..., n. ... Thus the following code would be legal: character(5), parameter :: c0(1) = [ "12345" ] print *, c0(1)(-5:-8) end and print an empty string, while it currently prints junk. It does the right thing with current trunk when parameter is removed, though.
[Bug fortran/85130] Substrings out of range are not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85130 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 --- We should handle the substring bounds as signed instead of unsigned. This is obviously fixed by: diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c index dfecc3012e1..604e63e6164 100644 --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -1724,8 +1724,8 @@ find_substring_ref (gfc_expr *p, gfc_expr **newp) *newp = gfc_copy_expr (p); free ((*newp)->value.character.string); - end = (gfc_charlen_t) mpz_get_ui (p->ref->u.ss.end->value.integer); - start = (gfc_charlen_t) mpz_get_ui (p->ref->u.ss.start->value.integer); + end = (gfc_charlen_t) mpz_get_si (p->ref->u.ss.end->value.integer); + start = (gfc_charlen_t) mpz_get_si (p->ref->u.ss.start->value.integer); if (end >= start) length = end - start + 1; else and regtests cleanly. :-) @Thomas: although the wording is slightly different between F2003 and F2018, it always results in length zero if the starting point exceeds the ending point. Would you agree in reverting your commit r258976 after applying the above?
[Bug fortran/67972] Substrings of arrays of unicode strings are of type DEFAULT rather than ISO_10646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67972 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||11.2.1, 12.0 Known to fail||10.3.1 Status|NEW |WAITING --- Comment #2 from anlauf at gcc dot gnu.org --- This appears to have been fixed at some point. 12-trunk and 11-branch work for me as of today, while 10-branch still shows the corruption.
[Bug fortran/85130] Substrings out of range are not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85130 --- Comment #6 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2021-September/056500.html
[Bug fortran/65454] Extending both forms of relational operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65454 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid CC||anlauf at gcc dot gnu.org Last reconfirmed|2015-03-20 00:00:00 |2021-9-12 Status|WAITING |NEW --- Comment #5 from anlauf at gcc dot gnu.org --- F2018 clearly states: 10.1.5.5.1 Interpretation of relational intrinsic operations The operators <, <=, >, >=, ==, and /= always have the same interpretations as the operators .LT., .LE., .GT., .GE., .EQ., and .NE., respectively. We need to handle this. (The current gfortran code seems to be able to distinguish between "old-style" and "new-style" and may fail to handle source code such as in this PR.)
[Bug fortran/102311] [11/12 Regression] ICE in gfc_enforce_clean_symbol_state, at fortran/symbol.c:4278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-09-13
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
(gdb) l symbol.c:4278
4273
4274void
4275gfc_enforce_clean_symbol_state(void)
4276{
4277 enforce_single_undo_checkpoint ();
4278 gcc_assert (latest_undo_chgset->syms.is_empty ());
4279}
For some reason we fail to clean up when the function is contained in a module.
[Bug fortran/102311] [11/12 Regression] ICE in gfc_enforce_clean_symbol_state, at fortran/symbol.c:4278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311
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 ---
Potential fix:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 8e5ed1c032c..30b96b2f597 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -811,7 +811,7 @@ resolve_entries (gfc_namespace *ns)
gfc_error ("Function %s at %L has entry %s with mismatched "
"characteristics", ns->entries->sym->name,
&ns->entries->sym->declared_at, el->sym->name);
- return;
+ goto cleanup;
}
else if (ts->type == BT_CHARACTER && ts->u.cl && fts->u.cl
&& (((ts->u.cl->length && !fts->u.cl->length)
@@ -917,6 +917,8 @@ resolve_entries (gfc_namespace *ns)
}
}
}
+
+cleanup:
proc->attr.access = ACCESS_PRIVATE;
proc->attr.entry_master = 1;
[Bug fortran/102287] optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102287 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-09-13 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug fortran/102287] optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102287
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 ---
We need to wrap the deallocation of INTENT(out) allocatable components into
a test for presence, like:
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 18d665192f0..076cffdd77f 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6548,6 +6548,19 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
// deallocate the components first
tmp = gfc_deallocate_alloc_comp (fsym->ts.u.derived,
parmse.expr, e->rank);
+ /* But check whether dummy argument is optional. */
+ if (tmp != NULL_TREE
+ && fsym->attr.optional
+ && e->expr_type == EXPR_VARIABLE
+ && e->symtree->n.sym->attr.optional)
+ {
+ tree present, notpres;
+ present = gfc_conv_expr_present (e->symtree->n.sym);
+ notpres = build_empty_stmt (input_location);
+ tmp = fold_build3_loc (input_location, COND_EXPR,
+ void_type_node,
+ present, tmp, notpres);
+ }
if (tmp != NULL_TREE)
gfc_add_expr_to_block (&se->pre, tmp);
}
[Bug fortran/102311] [11/12 Regression] ICE in gfc_enforce_clean_symbol_state, at fortran/symbol.c:4278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311 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 Keywords||error-recovery
[Bug fortran/102311] [11/12 Regression] ICE in gfc_enforce_clean_symbol_state, at fortran/symbol.c:4278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311 --- Comment #5 from anlauf at gcc dot gnu.org --- For the sake of completeness: considered as "obvious" https://gcc.gnu.org/pipermail/fortran/2021-September/056521.html
[Bug fortran/102287] optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102287 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 cleaned up and submitted: https://gcc.gnu.org/pipermail/fortran/2021-September/056522.html
[Bug fortran/102333] [9/10/11/12 Regression] ICE in gfc_generate_function_code, at fortran/trans-decl.c:6941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102333 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||accepts-invalid, ||ice-on-valid-code Last reconfirmed||2021-09-14 CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- The result clause is not needed. We even ICE on: function f(x) class(*), pointer :: f contains function g() procedure(f), pointer :: g end end or function f(x) class(*), allocatable :: f contains function g() procedure(f), pointer :: g end end Note however that the code in comment#1 is invalid and should be rejected.
[Bug fortran/102331] ICE in attr_decl1, at fortran/decl.c:8691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102331 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #2) > The following patch fixes the problem. It has not been regression tested. This restores the error, but for CLASS I now get: pr102331.f90:2:3: 2 | allocatable :: f | 1 Error: Unclassifiable statement at (1) pr102331.f90:1:0: 1 | class(t) function f() | Error: The type for function 'f' at (1) is not accessible while the error message for line 2 does not show up for TYPE. Maybe there are a few more places that need fixing. (Not only the obvious one after the second hunk for parse.c).
[Bug fortran/102315] ICE tree check: expected integer_cst, have save_expr in gfc_trans_array_constructor_value, at fortran/trans-array.c:2056
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102315 --- Comment #2 from anlauf at gcc dot gnu.org --- Looks familiar, and I am pretty sure there's a duplicate. Removing one set of [] makes the code compile: y = [character(8) :: 'a'//trim(x), 'b', 'c', 'd', 'e'] is obviously "fine".
[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 Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-16 Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. F2018: 8.5.18 VALUE attribute C863 An entity with the VALUE attribute shall be a dummy data object. It shall not be an assumed-size array, a coarray, or a variable with a coarray ultimate component. Thus assumed-shape is allowed. We need to adjust the checks.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 --- Comment #2 from anlauf at gcc dot gnu.org --- What is your stack size? Does it help if you declare a SAVEd?
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #6)
> Seems it changed with r12-3129-gf95946afd160e2a1f4beac4ee5e6d5633307f39a
Looking at the tree dump, it appears that there is a latent issue.
void MAIN__ ()
{
real(kind=4) a[16776325];
However, that standard says:
F2018 8.5.16 SAVE attribute
(4) A variable, common block, or procedure pointer declared in the scoping unit
of a main program, [...] implicitly has the SAVE attribute
My interpretations of the issue is that we miss to set the SAVE_IMPLICIT,
which is confirmed by running under the debugger, which shows that a
has SAVE_NONE.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 --- Comment #8 from anlauf at gcc dot gnu.org --- Potential fix for comment#0: diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c index bed61e2325d..54309646aad 100644 --- a/gcc/fortran/trans-decl.c +++ b/gcc/fortran/trans-decl.c @@ -709,6 +709,11 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym) } } + /* Implicit SAVE (F2018, 8.5.16 SAVE attribute, clause 4). */ + if (sym->ns->proc_name && sym->ns->proc_name->attr.is_main_program + && sym->attr.save == SAVE_NONE) +sym->attr.save = SAVE_IMPLICIT; + /* Derived types are a bit peculiar because of the possibility of a default initializer; this must be applied each time the variable comes into scope it therefore need not be static. These variables Works for me, but not regtested yet. Does that help? Of course that handles only part of that clause, and we need extended testcases.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 --- Comment #9 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #8) > Potential fix for comment#0: I'm getting many regressions for this change. Investigating.
[Bug fortran/102366] [10/11/12 Regression] large arrays no longer become static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #10)
> The problem is gone if I revert r12-3129.
But then it regresses on pr98411. See for yourself compiling with -Wall.
Something like
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index bed61e2325d..b022d818e82 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -743,7 +743,6 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
/* Keep variables larger than max-stack-var-size off stack. */
if (!(sym->ns->proc_name && sym->ns->proc_name->attr.recursive)
- && !(sym->ns->proc_name && sym->ns->proc_name->attr.is_main_program)
&& !sym->attr.automatic
&& sym->attr.save != SAVE_EXPLICIT
&& sym->attr.save != SAVE_IMPLICIT
@@ -757,7 +756,9 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
|| sym->attr.allocatable)
&& !DECL_ARTIFICIAL (decl))
{
- if (flag_max_stack_var_size > 0)
+ if (flag_max_stack_var_size > 0
+ && !(sym->ns->proc_name &&
+ sym->ns->proc_name->attr.is_main_program))
gfc_warning (OPT_Wsurprising,
"Array %qs at %L is larger than limit set by "
"%<-fmax-stack-var-size=%>, moved from stack to static "
disables the warning for arrays in the main.
[Bug fortran/102366] [10/11/12 Regression] large arrays no longer become static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 --- Comment #13 from anlauf at gcc dot gnu.org --- In decl.c:match_attr_spec we have: 5818 /* Since Fortran 2008 module variables implicitly have the SAVE attribute. */ 5819 if ((gfc_current_state () == COMP_MODULE 5820 || gfc_current_state () == COMP_SUBMODULE) 5821 && !current_attr.save 5822 && (gfc_option.allow_std & GFC_STD_F2008) != 0) 5823current_attr.save = SAVE_IMPLICIT; I tried to extend that to the case of COMP_PROGRAM, but: (gdb) p gfc_state_stack->state $162 = COMP_NONE But when I add program test at the beginning of the file, I find (gdb) p gfc_state_stack->state $164 = COMP_PROGRAM So this may be too early to handle arrays in the main. Given Jakub's comment, I'll fix that and regtest.
[Bug fortran/102390] New: IMPLICIT SAVE not properly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102390 Bug ID: 102390 Summary: IMPLICIT SAVE not properly implemented Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- While working on pr102366, it became clear that we do not properly handle some situations where the Fortran standard requires variables to be IMPLICIT SAVE. F2018 8.5.16 SAVE attribute (4) A variable, common block, or procedure pointer declared in the scoping unit of a main program, module, or submodule implicitly has the SAVE attribute, which may be confirmed by explicit specification. If a common block has the SAVE attribute in any other kind of scoping unit, it shall have the SAVE attribute in every scoping unit that is not of a main program, module, or submodule. There is code in decl.c:match_attr_spec that attempts to handle this for modules and submodules. However, the program real(kind=4) :: a(10) a=1.0 end fails to place array a in static memory (for default values of option -fmax-stack-var-size). As long as there is no program statement, we do not have the proper context to set IMPLICIT_SAVE. But even with a program statement the current gfortran will place a in static memory unless one sets e.g. -fmax-stack-var-size=1 . For standard conforming code and -std=f2018 (or earlier) this needs fixing.
[Bug fortran/102366] [10/11/12 Regression] large arrays no longer become static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 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 #15 from anlauf at gcc dot gnu.org --- Committed as per Jakub's LGTM and announced here: https://gcc.gnu.org/pipermail/fortran/2021-September/056540.html
[Bug libfortran/102370] Runtime failure with allocatable component of allocatable parent and MOVE_ALLOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102370 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-09-17 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Are you sure the code is valid? Even Intel crashes when it reaches the print. Adding print *, allocated (temp) before print *, temp%val print for both: F So the final print looks invalid.
[Bug fortran/102311] [11/12 Regression] ICE in gfc_enforce_clean_symbol_state, at fortran/symbol.c:4278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102311 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Should be fixed on affected branches. Closing. Thanks for the report!
[Bug fortran/102366] [10/11/12 Regression] large arrays no longer become static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #18 from anlauf at gcc dot gnu.org --- Fixed on all affected branches. Closing. Thanks for the report!
[Bug fortran/102287] optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102287 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/85130] Substrings out of range are not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85130 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |9.5 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing.
[Bug fortran/78219] [F08] specifying the kind of a FORALL index in the header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78219 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 --- (In reply to kargl from comment #7) > diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c The patch unfortunately seems incomplete. It fails when using IMPLICIT NONE or -fimplicit-none with: pr78219.f90:3:30: 3 | forall (integer(kind=4) :: i = 1:10) | 1 Error: Symbol 'i' at (1) has no IMPLICIT type and similarly for pr102371.
[Bug fortran/102371] Error for type spec in FORALL statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102371 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- It is indeed a duplicate of pr78219. Unfortunately the patch provided there fails on the present testcase with: pr102371.f90:7:27: 7 | forall(integer(long) :: i=1:very_large, j=1:2) | 1 Error: Symbol 'i' at (1) has no IMPLICIT type pr102371.f90:7:43: 7 | forall(integer(long) :: i=1:very_large, j=1:2) | 1 Error: Symbol 'j' at (1) has no IMPLICIT type pr102371.f90:7:44: 7 | forall(integer(long) :: i=1:very_large, j=1:2) |1 Error: Cannot convert INTEGER(4) to UNKNOWN at (1) pr102371.f90:7:46: 7 | forall(integer(long) :: i=1:very_large, j=1:2) | 1 Error: Cannot convert INTEGER(4) to UNKNOWN at (1) pr102371.f90:7:47: 7 | forall(integer(long) :: i=1:very_large, j=1:2) | 1 Error: Cannot convert INTEGER(4) to UNKNOWN at (1) *** This bug has been marked as a duplicate of bug 78219 ***
[Bug fortran/78219] [F08] specifying the kind of a FORALL index in the header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78219 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||longb at cray dot com --- Comment #10 from anlauf at gcc dot gnu.org --- *** Bug 102371 has been marked as a duplicate of this bug. ***
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Last reconfirmed||2021-09-22 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from anlauf at gcc dot gnu.org --- I think the problem is we consider command_argument_count() as a pure function, so that gfc_is_constant_expr returns true. As a consequence, is_non_constant_shape_array thinks that 'a' has constant shape, thus erroneously allowing the initialization. We need a better concept of "constant"...
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #3) > Well, it is a pure function. Fortran 2018, page 327, > > All standard intrinsic functions are pure. Of course you are correct. I wanted to express that in this context one cannot interpret PURE == (compile time) constant.
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 --- Comment #6 from anlauf at gcc dot gnu.org --- Created attachment 51497 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51497&action=edit Patch Thanks for the research, Steve. The attached patch fixes the PR by excluding the listed functions.
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #51497|0 |1 is obsolete|| --- Comment #7 from anlauf at gcc dot gnu.org --- Created attachment 51498 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51498&action=edit Revised patch including testcase This regtests ok and has the right logic.
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 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 #9 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #8) > I think TRANSFER needs to be handled differently. > > From the same section of the Fortran standard, TRANSFER is > rejected if the following does not apply. > >(8) a reference to the intrinsic function TRANSFER where each >argument is a constant expression and each ultimate pointer >component of the SOURCE argument is disassociated, yeah, I did that for the final patch. Will submit soon. > So, one should be able to do something like > >integer,parameter :: n = 4 >integer,parameter :: x(transfer(n, n)) = 1 >print *, x >end > > which gfortran will give > > % gfortran10 -o z a.f90 > % ./z >1 1 1 1 This is less of an issue. We also currently fail on the following: subroutine s4 integer, parameter :: n = 4 integer, parameter :: x(transfer(n, n)) = 1 ! legal integer:: y(transfer(n, n)) = 2 ! legal integer, parameter :: k = size (x) ! ok integer, parameter :: m = size (y) ! fails, tracked separately print *, k, x, y if (k /= size (y)) stop 1 end For some reason we do not simplify SIZE(y), and this reason lies elsewhere. And it is not touch by my patch. > If you remove TRANSFER from the patch, it looks good to me. > We can revisit TRANSFER when Gerhard breaks gfortran, again! ;-) I'll bet he does, but don't hold your breath?
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 --- Comment #10 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2021-September/056571.html
[Bug fortran/102460] fortran internal compile error in coverage.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102460 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to fail||12.0 Last reconfirmed||2021-09-23 Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. The issue disappears if I comment out the line ENTRY ENTRY1() I also do not see it on 11-branch, but that may be related to my local build.
[Bug fortran/102460] fortran internal compile error in coverage.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102460 --- Comment #3 from anlauf at gcc dot gnu.org --- Reduced testcase: MODULE MOD2 IMPLICIT NONE CONTAINS SUBROUTINE SUB1() ENTRY ENTRY1() END SUBROUTINE SUB1 END MODULE MOD2
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 --- Comment #12 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #9) A tentative patch which fixes the remaining issue is posted here: https://gcc.gnu.org/pipermail/fortran/2021-September/056584.html in the hope to learn more about the frontend.
[Bug fortran/102510] Function call has unnecessary stride check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102510 --- Comment #3 from anlauf at gcc dot gnu.org --- It helps to look at the (Fortran) context. As written, the subroutine version is declared with explicit size contiguous arrays. If the caller has a non-contiguous (strided) result array, it needs to pack/unpack. For the function version - as is - we might need a temporary to handle different situations. However, if you offer the compiler the chance to inline the calls, and using optimization to inline the packing, you may get better code than you think. Compile this example with -O3 -mavx: module p use iso_fortran_env, only: r32 => real32 real(r32), dimension(8) :: a,b real(r32), dimension(8) :: c1, c2 real(r32), dimension(16) :: d1, d2 contains subroutine add2vecs1(a,b,c) real(r32), dimension(8), intent(in) :: a,b real(r32), dimension(8), intent(out) :: c c = a + b end subroutine add2vecs1 function add2vecs2(a,b) real(r32), dimension(8), intent(in) :: a,b real(r32), dimension(8) :: add2vecs2 add2vecs2 = a + b end function add2vecs2 !- subroutine s1 () call add2vecs1 (a, b, c1) end subroutine s1 !- subroutine s2 () c2 = add2vecs2 (a, b) end subroutine s2 !- subroutine s3 () call add2vecs1 (a, b, d1(1:16:2)) end subroutine s3 !- subroutine s4 () d2(1:16:2) = add2vecs2 (a, b) end subroutine s4 end You'll find that s1 and s2 compile to the same code, and the strided versions s3 and s4 (at least this is my reading of the assembly, but correct me if I am wrong). Is there really more to expect?
[Bug fortran/102520] [10/11/12 Regression] ICE in expand_constructor, at fortran/array.c:1802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102520 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-09-28 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Potential (nearly obvious) fix: diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c index b858bada18a..8d66e009f66 100644 --- a/gcc/fortran/array.c +++ b/gcc/fortran/array.c @@ -1798,6 +1805,9 @@ expand_constructor (gfc_constructor_base base) e = c->expr; + if (e == NULL) + return false; + if (empty_constructor) empty_ts = e->ts;
[Bug fortran/102521] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102521 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-09-28 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug fortran/102520] [10/11/12 Regression] ICE in expand_constructor, at fortran/array.c:1802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102520 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|--- |10.4 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Priority|P3 |P4 --- Comment #2 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2021-September/056591.html
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 --- Comment #13 from anlauf at gcc dot gnu.org --- Corrected patch that addresses the remaining issue (for valid code): https://gcc.gnu.org/pipermail/fortran/2021-September/056599.html
[Bug fortran/102510] Function call has unnecessary stride check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102510 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from anlauf at gcc dot gnu.org --- If you collect your procedures in a separate file, there is the possible question of what happens when you "use" these in another module. A possible expectation is that this situation should be handled with LTO. I have not checked whether this works (at the time of writing), though. I'ld like to close this issue for now. Please reopen or open a new one if you think there is room for improvement.
[Bug fortran/102521] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102521 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 --- Possibly related: program p type t integer :: n end type type(t), parameter :: a(4) = t(1) type(t), parameter :: c(*) = a end This gives an ICE already in add_init_expr_to_sym. So we likely screw up long before trans*.
[Bug fortran/102520] [10/11/12 Regression] ICE in expand_constructor, at fortran/array.c:1802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102520 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on affected branches. Closing. Thanks for the report!
[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |9.5 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.5 --- Comment #16 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/101327] ICE in find_array_element, at fortran/expr.c:1355
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101327 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |9.5 Status|NEW |RESOLVED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Richard Biener from comment #5) > So instead of doing *((T[0:] *)&a[ubound])[-idx] for accesses do > a[ubound - idx]? I think this assumption is correct. Of course 'a' could have a non-trivial stride (i.e. being /= 1), which is provided by the array descriptor. That should hopefully been respected by the suggested change.
[Bug tree-optimization/56688] static/saved variables prevent loop vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56688 anlauf at gcc dot gnu.org changed: What|Removed |Added CC|anlauf at gmx dot de |anlauf at gcc dot gnu.org --- Comment #9 from anlauf at gcc dot gnu.org --- The loop can be vectorized if the final value of the 'saved' scalar can be determined. Some vectorizing compilers (Cray, NEC) offer directives (e.g. lstval/nolstval) to control the evaluation of that scalar, and sometimes suggest to add that directive in front of the loop. I think the requirements for handling this are very similar to those for the OpenMP lastprivate declaration.
[Bug fortran/102521] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102521
--- Comment #3 from anlauf at gcc dot gnu.org ---
The code works if we replace the r.h.s. in the initialization by an array:
program p
type t
integer :: n
end type
! type(t), parameter :: a(4) = t(1)! ICE
type(t), parameter :: a(4) = spread (t(1), dim=1, ncopies=4) ! works
type(t), parameter :: c(*) = a
type(t), parameter :: b(2,2) = reshape(a, [2,2])
print *, b
end
The code in add_init_expr_to_sym looks fishy. We might possibly handle the
ICEing code here but don't:
2224 /* Add initializer. Make sure we keep the ranks sane. */
2225 if (sym->attr.dimension && init->rank == 0)
2226{
2227 mpz_t size;
2228 gfc_expr *array;
2229 int n;
2230 if (sym->attr.flavor == FL_PARAMETER
2231&& init->expr_type == EXPR_CONSTANT
2232&& spec_size (sym->as, &size)
2233&& mpz_cmp_si (size, 0) > 0)
(gdb) p init->expr_type
$1 = EXPR_STRUCTURE
[Bug libfortran/100954] writing to a character opens unit -10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100954 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||2021-10-01 Component|fortran |libfortran --- Comment #3 from anlauf at gcc dot gnu.org --- This is possibly a bookkeeping issue. Reduced testcase: program inquire implicit none integer :: iounit, ierr logical :: opened character(4) :: c ! open(newunit=iounit,file="testfile") write(c,'(a)') "abcd" iounit = -10 inquire(iounit, opened=opened,iostat=ierr) print *,iounit,'open?',opened,ierr iounit = -11 inquire(iounit, opened=opened,iostat=ierr) print *,iounit,'open?',opened,ierr endprogram inquire This prints -10 open? T 0 -11 open? F 0 but should print -10 open? F 0 -11 open? F 0 Note that the start value -10 comes from unit.c: #define NEWUNIT_START -10 If we uncomment before the internal write open(newunit=iounit,file="testfile") then we'll find that units -10 and -11 are opened: -10 open? T 0 -11 open? T 0 If we swap the open and internal write, then -11 is not opened: -10 open? T 0 -11 open? F 0
[Bug fortran/99348] ICE in resolve_structure_cons, at fortran/resolve.c:1286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99348
--- Comment #4 from anlauf at gcc dot gnu.org ---
This might actually be related to pr102521. The following variant compiles ok:
program p
type t
character(3) :: c
end type
! type(t), parameter :: x(1) = t('abc')
type(t), parameter :: x(1) = spread (t('abc'), dim=1, ncopies=1)
print *, x%c%len
end
[Bug fortran/102521] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102521
--- Comment #4 from anlauf at gcc dot gnu.org ---
Tentative patch:
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index b3c65b7175b..cebc59e4ab5 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -2228,12 +2228,15 @@ add_init_expr_to_sym (const char *name, gfc_expr
**initp, locus *var_locus)
gfc_expr *array;
int n;
if (sym->attr.flavor == FL_PARAMETER
- && init->expr_type == EXPR_CONSTANT
- && spec_size (sym->as, &size)
- && mpz_cmp_si (size, 0) > 0)
+ && (init->expr_type == EXPR_CONSTANT
+ || init->expr_type == EXPR_STRUCTURE)
+ && spec_size (sym->as, &size)
+ && mpz_cmp_si (size, 0) > 0)
{
array = gfc_get_array_expr (init->ts.type, init->ts.kind,
&init->where);
+ if (init->ts.type == BT_DERIVED)
+ array->ts.u.derived = init->ts.u.derived;
for (n = 0; n < (int)mpz_get_si (size); n++)
gfc_constructor_append_expr (&array->value.constructor,
n == 0
[Bug fortran/102521] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102521 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/2021-October/056617.html
[Bug fortran/102599] New: Wrong simplification of inquiry parameters for complex arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102599
Bug ID: 102599
Summary: Wrong simplification of inquiry parameters for complex
arrays
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gcc dot gnu.org
Target Milestone: ---
Consider:
program p
implicit none
complex, parameter :: x(2) = 1
real,parameter :: r(*) = x%re
real,parameter :: i(*) = x%im
print *, r,all(r== 1) ! wrong
print *, i,all(i== 0) ! wrong
print *, x%re, all(x%re == 1) ! OK
print *, x%im, all(x%im == 0) ! OK
end
This prints:
1. 0. T
1. 0. F
1. 1. T
0. 0. T
The first two lines should be identical to the last two.
The dump-tree has:
static real(kind=4) r[2] = {__complex__ (1.0e+0, 0.0), __complex__ (1.0e+0,
0.0)};
static real(kind=4) i[2] = {__complex__ (1.0e+0, 0.0), __complex__ (1.0e+0,
0.0)};
static complex(kind=4) x[2] = {__complex__ (1.0e+0, 0.0), __complex__
(1.0e+0, 0.0)};
which is nonsense for r, i.
Furthermore, all(x%re == 1) and all(x%im == 0) are not simplified, but that's
another story...
