[Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |13.3 Status|UNCONFIRMED |RESOLVED Keywords||ice-on-valid-code --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14, and backported to 13-branch. Closing.
[Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:77cf842869ddda8cfcdbb7db6e65ecfb9ac432fc commit r13-8406-g77cf842869ddda8cfcdbb7db6e65ecfb9ac432fc Author: Steve Kargl Date: Fri Feb 23 22:05:04 2024 +0100 Fortran: ALLOCATE statement, SOURCE/MOLD expressions with subrefs [PR114024] PR fortran/114024 gcc/fortran/ChangeLog: * trans-stmt.cc (gfc_trans_allocate): When a source expression has substring references, part-refs, or %re/%im inquiries, wrap the entity in parentheses to force evaluation of the expression. gcc/testsuite/ChangeLog: * gfortran.dg/allocate_with_source_27.f90: New test. * gfortran.dg/allocate_with_source_28.f90: New test. Co-Authored-By: Harald Anlauf (cherry picked from commit 80d126ba99f4b9bc64d4861b3c4bae666497f2d4)
[Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024 --- Comment #4 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:80d126ba99f4b9bc64d4861b3c4bae666497f2d4 commit r14-9160-g80d126ba99f4b9bc64d4861b3c4bae666497f2d4 Author: Steve Kargl Date: Fri Feb 23 22:05:04 2024 +0100 Fortran: ALLOCATE statement, SOURCE/MOLD expressions with subrefs [PR114024] PR fortran/114024 gcc/fortran/ChangeLog: * trans-stmt.cc (gfc_trans_allocate): When a source expression has substring references, part-refs, or %re/%im inquiries, wrap the entity in parentheses to force evaluation of the expression. gcc/testsuite/ChangeLog: * gfortran.dg/allocate_with_source_27.f90: New test. * gfortran.dg/allocate_with_source_28.f90: New test. Co-Authored-By: Harald Anlauf
[Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024 --- Comment #3 from kargl at gcc dot gnu.org --- Created attachment 57482 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57482=edit patch The attached patch fixes this PR. It includes a new testcase and passes regression testing.
[Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #2 from kargl at gcc dot gnu.org ---
This is ugly. Essentially, the translation of an allocate statement is
mot prepared to have a complex-part-ref as the source expression. For this
code
program foo
implicit none
complex :: cmp(3)
real, allocatable :: xx(:), yy(:), zz(:)
cmp = (3.45,6.78)
allocate (xx, source = cmp%re) ! ICE
allocate (yy, source = cmp(1:3)%re) ! ICE
allocate (zz, source = (cmp%re))
print *, xx
print *, yy
print *, zz
end
The lines marked with ICE will cause gfortran to, well, ICE. The
following patch cures the issues by impose a set of parentheses
about the source expression. There is likely a better way.
diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 5247d3d39d7..6ff3f12d7ed 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -6355,8 +6355,24 @@ gfc_trans_allocate (gfc_code * code, gfc_omp_namelist
*omp_allocate)
vtab_needed = (al->expr->ts.type == BT_CLASS);
gfc_init_se (, NULL);
- /* When expr3 is a variable, i.e., a very simple expression,
-then convert it once here. */
+
+ /* When expr3 is a variable, i.e., a very simple expression, then
+convert it once here. Note, if one has source = z%re or z%im,
+then things can go sideways with the complex-part-ref, so wrap
+the entity in parentheses to force evaluation of an expression.
+That is, the else-branch of the ensuing if-else-stmt is entered. */
+
+ if (code->expr3->ref
+ && ((code->expr3->ref->u.i == INQUIRY_RE
+ || code->expr3->ref->u.i == INQUIRY_IM)
+ || (code->expr3->ref->type == REF_ARRAY
+ && code->expr3->ref->u.ar.type == AR_SECTION)))
+ {
+ gfc_expr *etmp = gfc_get_parentheses (code->expr3);
+ code->expr3 = gfc_copy_expr (etmp);
+ gfc_free_expr (etmp);
+ }
+
if (code->expr3->expr_type == EXPR_VARIABLE
|| code->expr3->expr_type == EXPR_ARRAY
|| code->expr3->expr_type == EXPR_CONSTANT)
[Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024 --- Comment #1 from Steve Kargl --- On Tue, Feb 20, 2024 at 09:42:21PM +, kargl at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024 > > allocate (xx, source = cmp%re) > > > gfcx -c 0093/0093_0130.f90 > 0093/0093_0130.f90:10:36: > >10 | allocate (xx, source = cmp(1:3)%re) > |1 Whoops. Wrong backtrace. Nonetheless, I still has an issue with cmp%re. Note, inserting parentheses allows the code to compile, i.e, 'source = (cmp%re))'.
