This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran, OOP] PR 44962: [OOP] ICE with specification expression SIZE(<CLASS>)


>>> Frankly, I do not quite understand the check. [...]
>>>
>> Well, in general array bounds are only required to be specification
>> expressions (F08:R516-518). However, there is an additional
>> constraint. In F03 it was:
>>
>> C542 (R511) An explicit-shape array whose bounds are not
>> initialization expressions shall be a dummy argument, a function
>> result, or an automatic array of a procedure.
>>
>> In F08 it is:
>>
>> C531 (R516) An explicit-shape-spec whose bounds are not constant expressions shall appear only in a subprogram, derived type de finition, BLOCK construct, or interface body.
>>
>
> Can you add a comment before the gfc_is_constant_expr to state what the
> function is actually doing (e.g. checking for specification expressions
> while taking additionally the given constraints into account.)

Well, it's actually not checking for specification expressions (which
is what gfc_specification_expr does), but it checks for constant
expressions, which are defined in chapter 7.1.12 of F08.


>> If I am interpreting the above restrictions correctly, then components
>> had to have constant array bounds in F03, while in F08 they don't have
>> to be constant. Is that right?
>
> Seems so, but I somehow do not understand how this is supposed to work;
> probably somehow like:
>
> subroutine foo(n)
> ?type t
> ? ?integer :: a(n)
> ?end type t
> ...
> end

Probably.


> As you check for specification expressions, you cannot simply remove the
> check. The reason is that check_specification_function excludes
> intrinsic functions (cf. "specification function" in the standard).

No. Firstly, in "gfc_is_constant_expr" we're not checking for
specification expressions. Second, constant expressions can *only*
contain intrinsic functions.

I think a "specification function" is a special case of a
"specification expression". AFAICS, specification expressions in
general can of course include intrinsic functions.

If one checks for constant expressions and demands that they have been
simplified, I think one can really reject all EXPR_FUNCTIONS: A
function in a constant expr must be intrinsic, and those should be
simplified away to a constant already. And no, specification functions
are not constant. Quite the opposite: They cannot be!

In fact, 'check_specification_function' can be removed, since it is
equivalent to 'external_spec_function', and is only used in this one
place where it is completely inappropriate.


> I do not think that one needs to exclude the random functions (who says
> that the array size needs to be deterministic).

Well, I think the intention of "constant expressions" is to be
something which can be evaluated to a constant at *compile* time. This
is not the case for non-deterministic random functions.

I'm now regtesting the attached patch. Any further comments?

Cheers,
Janus

Attachment: pr44962_v4.diff
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]