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