* [Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
2022-11-16 19:06 [Bug fortran/107721] New: Lost typespec with constant expressions using array constructors and parentheses anlauf at gcc dot gnu.org
@ 2023-01-30 0:26 ` jvdelisle at gcc dot gnu.org
2023-01-30 0:28 ` jvdelisle at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2023-01-30 0:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
CC| |jvdelisle at gcc dot gnu.org
Last reconfirmed| |2023-01-30
Status|UNCONFIRMED |NEW
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
2022-11-16 19:06 [Bug fortran/107721] New: Lost typespec with constant expressions using array constructors and parentheses anlauf at gcc dot gnu.org
2023-01-30 0:26 ` [Bug fortran/107721] " jvdelisle at gcc dot gnu.org
@ 2023-01-30 0:28 ` jvdelisle at gcc dot gnu.org
2023-01-30 0:29 ` jvdelisle at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2023-01-30 0:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gscfq@t-online.de
--- Comment #1 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
*** Bug 107820 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
2022-11-16 19:06 [Bug fortran/107721] New: Lost typespec with constant expressions using array constructors and parentheses anlauf at gcc dot gnu.org
2023-01-30 0:26 ` [Bug fortran/107721] " jvdelisle at gcc dot gnu.org
2023-01-30 0:28 ` jvdelisle at gcc dot gnu.org
@ 2023-01-30 0:29 ` jvdelisle at gcc dot gnu.org
2023-02-03 2:34 ` jvdelisle at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2023-01-30 0:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org
--- Comment #2 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I will see if I can find this.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
2022-11-16 19:06 [Bug fortran/107721] New: Lost typespec with constant expressions using array constructors and parentheses anlauf at gcc dot gnu.org
` (2 preceding siblings ...)
2023-01-30 0:29 ` jvdelisle at gcc dot gnu.org
@ 2023-02-03 2:34 ` jvdelisle at gcc dot gnu.org
2023-02-03 3:54 ` jvdelisle at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2023-02-03 2:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #3 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I have a copy of the standard so I will answer my own question. This is a
comment:
In a situation like this:
print *, [integer :: ([1.0])] ** 2
My brain wants to say reject it because 1.0 is not an integer. I will check
further as I said, but yet another example to me where the standard is
counter-intuitive to me.
I will be even bold and say the idea of even having a typespec in this form
seems, shall I say, not so bright. But, there it is.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
2022-11-16 19:06 [Bug fortran/107721] New: Lost typespec with constant expressions using array constructors and parentheses anlauf at gcc dot gnu.org
` (3 preceding siblings ...)
2023-02-03 2:34 ` jvdelisle at gcc dot gnu.org
@ 2023-02-03 3:54 ` jvdelisle at gcc dot gnu.org
2023-02-03 7:07 ` kargl at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2023-02-03 3:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #4 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Well folks, I like to document my thought process.
From the 2022 draft standard we have:
R781 ac-value is expr or ac-implied-do
R782 ac-implied-do is ( ac-value-list , ac-implied-do-control )
In our code within array.cc we are clearly matching for R782.
However, we are not really trying to match expr of R781.
Our basic problem here is we have the following:
print *, [integer :: ([1.0])] ** 2
The ([1.0]) portion is clearly not an ac-implied-do, so what is it?
So is it an expr?
R1023 expr is [ expr defined-binary-op ] level-5-expr
Looks to me that it is an expr.
print *, ([1.0]) works quite well.
We have, therefore an expr.
In array.cc we have gfc_match_array_constructor. As far as I can tell we are
matching the ac-implied-do, however we are not even trying to match expr.
Let's see what we can do about it.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
2022-11-16 19:06 [Bug fortran/107721] New: Lost typespec with constant expressions using array constructors and parentheses anlauf at gcc dot gnu.org
` (4 preceding siblings ...)
2023-02-03 3:54 ` jvdelisle at gcc dot gnu.org
@ 2023-02-03 7:07 ` kargl at gcc dot gnu.org
2023-02-04 4:08 ` jvdelisle at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: kargl at gcc dot gnu.org @ 2023-02-03 7:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #4)
>
> print *, ([1.0]) works quite well.
>
> We have, therefore an expr.
>
> In array.cc we have gfc_match_array_constructor. As far as I can tell we
> are matching the ac-implied-do, however we are not even trying to match expr.
>
> Let's see what we can do about it.
>
Yes, it's an expr. The matching happens in gfc_match_array_constructor()
when you get to lines 1311ff
for (;;)
{
m = match_array_cons_element (&head);
if (m == MATCH_ERROR)
goto cleanup;
if (m == MATCH_NO)
goto syntax;
if (gfc_match_char (',') == MATCH_NO)
break;
}
If you deep dive into match_array_cons_element(), you see
m = match_array_list (result);
if (m != MATCH_NO)
return m;
m = gfc_match_expr (&expr);
if (m != MATCH_YES)
return m;
There's your expression mapping. The problem is that for
[integer :: ([1.0])] ** 2, simplification of the expression
([1.0]) returns ([1.0]) and expr_type of EXPR_OP.
So, when we walk the array constructor in lines 1368ff
if (gfc_numeric_ts (&ts))
{
m = walk_array_constructor (&ts, head);
if (m == MATCH_ERROR)
return m;
}
the walker cannot apply a type conversion.
My take is that simplification of ([1.0]) needs to reduce
this to [1.0], which then allows the code to compile. I
had a patch that did this, but it failed with (([1.0])).
I modified the patch to accept (([1.0])), and it of course
failed with ((([1.0]))).
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
2022-11-16 19:06 [Bug fortran/107721] New: Lost typespec with constant expressions using array constructors and parentheses anlauf at gcc dot gnu.org
` (5 preceding siblings ...)
2023-02-03 7:07 ` kargl at gcc dot gnu.org
@ 2023-02-04 4:08 ` jvdelisle at gcc dot gnu.org
2023-02-04 16:45 ` jvdelisle at gcc dot gnu.org
2023-02-20 23:46 ` jvdelisle at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2023-02-04 4:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #6 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I had to go back in the Standard to deepen my understanding. Yes simplifying
it would help. I think what we need to do is acknowledge that we should match
'(' and if found, recursively call the gfc_match_array_constructor and check
for the closing ')' on the other end of it.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
2022-11-16 19:06 [Bug fortran/107721] New: Lost typespec with constant expressions using array constructors and parentheses anlauf at gcc dot gnu.org
` (6 preceding siblings ...)
2023-02-04 4:08 ` jvdelisle at gcc dot gnu.org
@ 2023-02-04 16:45 ` jvdelisle at gcc dot gnu.org
2023-02-20 23:46 ` jvdelisle at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2023-02-04 16:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #7 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I should mention, this also fails:
print *, [real :: ((/2, 3/))] ** 2
So we also have to deal with this. I think I have it figured out.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
2022-11-16 19:06 [Bug fortran/107721] New: Lost typespec with constant expressions using array constructors and parentheses anlauf at gcc dot gnu.org
` (7 preceding siblings ...)
2023-02-04 16:45 ` jvdelisle at gcc dot gnu.org
@ 2023-02-20 23:46 ` jvdelisle at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2023-02-20 23:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #8 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
FWIW : I think the typespec is being lost because the initial call into
gfc_match_array_constructor which finds and matches the typespec sets a local
variable seen_ts which is used later in that function to do the type conversion
steps. However, before that happens a call from gfc_match_array_constructor
into match_array_cons_element then results in a subsequent call to
gfc_match_array_constructor where there is no typespec left to match. The local
seen_ts is set to false so the conversion code does not get called.
Killing parens does not fix any of this. I think what is needed is the seen_ts
needs to be passed down the call chain to preserve it during the
match_array_cons_element process. My intuition tells me it would be better if
portions of this code are refactored little to avoid some of these recursive
calls.
^ permalink raw reply [flat|nested] 10+ messages in thread