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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #9 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Jerry DeLisle from comment #8)
> 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.
> 
This is true, but at that point the type is not strictly speaking lost, because
it's stored in the outer constructor.

What really kills the type is arith.cc's collection of reduce_* functions (in
this case reduce_binary_ac) that evaluate operators at compile time by picking
array constructor elements one by one without adding intermediary conversions
to the constructor type.

> 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.
No, I think we don't want to do that, because array constructor elements are
arbitrary expressions, so we use the generic expressions matching functions and
they don't have any seen_ts argument and we don't want to add one just for the
array constructor context.

> My intuition tells me it would be better
> if portions of this code are refactored little to avoid some of these
> recursive calls.
Well, recursive calls are inevitable, because the syntax definition is
recursive.  Array constructors can have arbitrary expressions in their bodies, 
those arbitrary expressions can have array constructors as operands, etc...

Reply via email to