[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 Target Milestone|--- |10.4 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #19 from anlauf at gcc dot gnu.org --- Fixed on mainline and backported to 11- and 10-branch. Probably too risky for 9-branch. Closing. Thanks for the report!
[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 #18 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:dea2e6c7b5af2ec620fd94d824f006440907a34d commit r10-10170-gdea2e6c7b5af2ec620fd94d824f006440907a34d Author: Harald Anlauf Date: Thu Sep 30 20:29:31 2021 +0200 Fortran: resolve expressions during SIZE simplification gcc/fortran/ChangeLog: PR fortran/102458 * simplify.c (simplify_size): Resolve expressions used in array specifications so that SIZE can be simplified. gcc/testsuite/ChangeLog: PR fortran/102458 * gfortran.dg/pr102458b.f90: New test. (cherry picked from commit b19bbfb1482505367dd19ae4ab1ea19e36802b6a)
[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 #17 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:4aabb9ac284fea307aa70bb8ae4bdce298461bc7 commit r10-10169-g4aabb9ac284fea307aa70bb8ae4bdce298461bc7 Author: Harald Anlauf Date: Fri Sep 24 19:10:15 2021 +0200 Fortran - improve checking for intrinsics allowed in constant expressions gcc/fortran/ChangeLog: PR fortran/102458 * expr.c (is_non_constant_intrinsic): Check for intrinsics excluded in constant expressions (F2018:10.1.12). (gfc_is_constant_expr): Use that check. gcc/testsuite/ChangeLog: PR fortran/102458 * gfortran.dg/pr102458.f90: New test. (cherry picked from commit 082b3588ee01399b93fe73acd2ac181ec2ee3536)
[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 #16 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:a3abacbaebc5583885600840cf2d968341be0275 commit r11-9065-ga3abacbaebc5583885600840cf2d968341be0275 Author: Harald Anlauf Date: Thu Sep 30 20:29:31 2021 +0200 Fortran: resolve expressions during SIZE simplification gcc/fortran/ChangeLog: PR fortran/102458 * simplify.c (simplify_size): Resolve expressions used in array specifications so that SIZE can be simplified. gcc/testsuite/ChangeLog: PR fortran/102458 * gfortran.dg/pr102458b.f90: New test. (cherry picked from commit b19bbfb1482505367dd19ae4ab1ea19e36802b6a)
[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 #15 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:082b3588ee01399b93fe73acd2ac181ec2ee3536 commit r11-9064-g082b3588ee01399b93fe73acd2ac181ec2ee3536 Author: Harald Anlauf Date: Fri Sep 24 19:10:15 2021 +0200 Fortran - improve checking for intrinsics allowed in constant expressions gcc/fortran/ChangeLog: PR fortran/102458 * expr.c (is_non_constant_intrinsic): Check for intrinsics excluded in constant expressions (F2018:10.1.12). (gfc_is_constant_expr): Use that check. gcc/testsuite/ChangeLog: PR fortran/102458 * gfortran.dg/pr102458.f90: New test. (cherry picked from commit 84cccff60a978174271a30042bf7841d2ae436eb)
[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 #14 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:b19bbfb1482505367dd19ae4ab1ea19e36802b6a commit r12-3993-gb19bbfb1482505367dd19ae4ab1ea19e36802b6a Author: Harald Anlauf Date: Thu Sep 30 20:29:31 2021 +0200 Fortran: resolve expressions during SIZE simplification gcc/fortran/ChangeLog: PR fortran/102458 * simplify.c (simplify_size): Resolve expressions used in array specifications so that SIZE can be simplified. gcc/testsuite/ChangeLog: PR fortran/102458 * gfortran.dg/pr102458b.f90: New test.
[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/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/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 #11 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:84cccff60a978174271a30042bf7841d2ae436eb commit r12-3884-g84cccff60a978174271a30042bf7841d2ae436eb Author: Harald Anlauf Date: Fri Sep 24 19:10:15 2021 +0200 Fortran - improve checking for intrinsics allowed in constant expressions gcc/fortran/ChangeLog: PR fortran/102458 * expr.c (is_non_constant_intrinsic): Check for intrinsics excluded in constant expressions (F2018:10.1.2). (gfc_is_constant_expr): Use that check. gcc/testsuite/ChangeLog: PR fortran/102458 * gfortran.dg/pr102458.f90: New test.
[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/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 #8 from Steve Kargl --- On Wed, Sep 22, 2021 at 09:17:18PM +, anlauf at gcc dot gnu.org wrote: > 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=edit > Revised patch including testcase > 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, 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 If you remove TRANSFER from the patch, it looks good to me. We can revisit TRANSFER when Gerhard breaks gfortran, again! ;-)
[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=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 --- Comment #6 from anlauf at gcc dot gnu.org --- Created attachment 51497 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51497=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 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #3) > (In reply to anlauf from comment #2) > > I think the problem is we consider command_argument_count() as a pure > > function, > > so that gfc_is_constant_expr returns true. > > Well, it is a pure function. Fortran 2018, page 327, > > All standard intrinsic functions are pure. I think we need to look at the specific function in gfc_is_constant_expr. The Fortran standard has 10.1.12 Constant expression A constant expression is an expression with limitations that make it suitable for use as a kind type parameter, initializer, or named constant. It is an expression in which each operation is intrinsic, and each primary is ... (5) a reference to an elemental standard intrinsic function, where each argument is a constant expression, (6) a reference to a standard intrinsic function that is transformational, other than COMMAND_ARGUMENT_COUNT, GET_TEAM, NULL, NUM_IMAGES, TEAM_NUMBER, THIS_IMAGE, or TRANSFER, where each argument is a constant expression, So, if I untangle (6), gfortran needs to reject the listed intrinsic function except for TRANSFER where a different restrict applies.
[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 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to anlauf from comment #2) > I think the problem is we consider command_argument_count() as a pure > function, > so that gfc_is_constant_expr returns true. Well, it is a pure function. Fortran 2018, page 327, All standard intrinsic functions are pure.
[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 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- There are several variants : $ cat z3.f90 subroutine s integer :: a(num_images()) = 1 print *, a end $ cat z4.f90 subroutine s integer :: a(this_image()) = 1 print *, a end $ cat z7.f90 subroutine s integer :: a(command_argument_count()) = 1 a = 2 end $ cat z8.f90 program p block integer :: a(command_argument_count()) = 1 print *, a end block end $ cat za.f90 function f() integer :: a(command_argument_count()) = 0 a = 1 end $ cat zb.f90 program p block integer :: n(command_argument_count()) = 0 n = 1 end block end $ gfortran-12-20210919 -c zb.f90 zb.f90:3:44: 3 | integer :: n(command_argument_count()) = 0 |1 internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:6426 0x797a5b gfc_trans_auto_array_allocation(tree_node*, gfc_symbol*, gfc_wrapped_block*) ../../gcc/fortran/trans-array.c:6426 0x7b1f17 gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*) ../../gcc/fortran/trans-decl.c:4921 0x8054e1 gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.c:2311 0x78e4a7 trans_code ../../gcc/fortran/trans.c:2014 0x7b4c04 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6919 0x73af76 translate_all_program_units ../../gcc/fortran/parse.c:6572 0x73af76 gfc_parse_file() ../../gcc/fortran/parse.c:6841 0x78761f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
