From: Harald Anlauf <anlauf@gmx.de>
To: Andre Vehreschild <vehre@gmx.de>,
GCC-Patches-ML <gcc-patches@gcc.gnu.org>,
GCC-Fortran-ML <fortran@gcc.gnu.org>,
Paul Richard Thomas <paul.richard.thomas@gmail.com>
Subject: Re: [Patch, Fortran] Allow ref'ing PDT's len() in parameter-initializer [PR102003]
Date: Mon, 10 Jul 2023 20:55:29 +0200 [thread overview]
Message-ID: <3114593a-0197-62cd-41e9-59f2a8ae9f29@gmx.de> (raw)
In-Reply-To: <20230710174826.48f9230c@vepi2>
Hi Andre,
thanks for looking into this!
While it fixes the original PR, here is a minor extension of the
testcase that ICEs here with your patch:
program pr102003
type pdt(n)
integer, len :: n = 8
character(len=n) :: c
end type pdt
type(pdt(42)) :: p
integer, parameter :: m = len (p% c)
integer, parameter :: n = p% c% len
if (m /= 42) stop 1
if (len (p% c) /= 42) stop 2
print *, p% c% len ! OK
if (p% c% len /= 42) stop 3 ! OK
print *, n ! ICE
end
I get:
pdt_33.f03:14:27:
14 | integer, parameter :: n = p% c% len
| 1
Error: non-constant initialization expression at (1)
pdt_33.f03:20:31:
20 | print *, n ! ICE
| 1
internal compiler error: tree check: expected record_type or union_type
or qual_union_type, have integer_type in gfc_conv_component_ref, at
fortran/trans-expr.cc:2757
0x84286c tree_check_failed(tree_node const*, char const*, int, char
const*, ...)
../../gcc-trunk/gcc/tree.cc:8899
0xa6d6fb tree_check3(tree_node*, char const*, int, char const*,
tree_code, tree_code, tree_code)
../../gcc-trunk/gcc/tree.h:3617
0xa90847 gfc_conv_component_ref(gfc_se*, gfc_ref*)
../../gcc-trunk/gcc/fortran/trans-expr.cc:2757
0xa91bbc gfc_conv_variable
../../gcc-trunk/gcc/fortran/trans-expr.cc:3137
0xaa8e9c gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.cc:9594
0xaa92ae gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-expr.cc:9713
0xad67f6 gfc_trans_transfer(gfc_code*)
../../gcc-trunk/gcc/fortran/trans-io.cc:2607
0xa43cb7 trans_code
../../gcc-trunk/gcc/fortran/trans.cc:2449
0xad37c6 build_dt
../../gcc-trunk/gcc/fortran/trans-io.cc:2051
0xa43cd7 trans_code
../../gcc-trunk/gcc/fortran/trans.cc:2421
0xa84711 gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.cc:7762
0x9d9ca7 translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.cc:6929
0x9d9ca7 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.cc:7235
0xa40a1f gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.cc:229
The fortran-dump confirms that n is not simplified to a constant.
So while you're at it, do you also see a solution to this variant?
Harald
Am 10.07.23 um 17:48 schrieb Andre Vehreschild via Gcc-patches:
> Hi all,
>
> while browsing the pdt meta-bug I came across 102003 and thought to myself:
> Well, that one is easy. How foolish of me...
>
> Anyway, the solution attached prevents a pdt_len (or pdt_kind) expression in a
> function call (e.g. len() or kind()) to mark the whole expression as a pdt one.
> The second part of the patch in simplify.cc then takes care of either generating
> the correct component ref or when a constant expression (i.e.
> gfc_init_expr_flag is set) is required to look this up from the actual symbol
> (not from the type, because there the default value is stored).
>
> Regtested ok on x86_64-linux-gnu/Fedora 37.
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
next prev parent reply other threads:[~2023-07-10 18:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-10 15:48 Andre Vehreschild
2023-07-10 18:55 ` Harald Anlauf [this message]
2023-07-10 19:21 ` Andre Vehreschild
2023-07-11 16:23 ` Andre Vehreschild
2023-07-11 20:24 ` Harald Anlauf
2023-07-12 11:37 ` [Patch, Fortran, committed] " Andre Vehreschild
2023-07-11 21:09 ` [Patch, Fortran] " Harald Anlauf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3114593a-0197-62cd-41e9-59f2a8ae9f29@gmx.de \
--to=anlauf@gmx.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=paul.richard.thomas@gmail.com \
--cc=vehre@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).