[Bug fortran/107721] New: Lost typespec with constant expressions using array constructors and parentheses

[Bug fortran/107721] New: Lost typespec with constant expressions using array constructors and parentheses

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721

            Bug ID: 107721
           Summary: Lost typespec with constant expressions using array
                    constructors and parentheses
           Product: gcc
           Version: 13.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 pr107680, I noticed the following issue:

program p
  print *, "*** Expect integer:"
  print *, [integer ::  [1.0] ] **  2
  print *, [integer :: ([1.0])] **  2
  print *, "*** Expect real:"
  print *, [real    ::  [2] ]   **  2
  print *, [real    :: ([2])]   **  2
  print *, "*** Expect complex:"
  print *, [complex ::  [3] ]   **  2
  print *, [complex :: ([3])]   **  2
end

There should be no effect by the parentheses here, but with 11-branch onwards
I get:

 *** Expect integer:
           1
   1.00000000    
 *** Expect real:
   4.00000000    
           4
 *** Expect complex:
             (9.00000000,0.00000000)
           9


Intel correctly prints:

 *** Expect integer:
           1
           1
 *** Expect real:
   4.000000    
   4.000000    
 *** Expect complex:
 (9.000000,0.0000000E+00)
 (9.000000,0.0000000E+00)


Note that 10-branch and older ICE on this code...

[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses

[jvdelisle at gcc dot gnu.org]

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

[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses

[jvdelisle at gcc dot gnu.org]

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. ***

[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses

[jvdelisle at gcc dot gnu.org]

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.

[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses

[jvdelisle at gcc dot gnu.org]

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.

[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses

[jvdelisle at gcc dot gnu.org]

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.

[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses

[kargl at gcc dot gnu.org]

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]))).

[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses

[jvdelisle at gcc dot gnu.org]

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.

[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses

[jvdelisle at gcc dot gnu.org]

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.

[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses

[jvdelisle at gcc dot gnu.org]

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.