On Thu, Oct 24, 2024 at 10:22:29PM +0200, Thomas Koenig wrote:
>
> > I'll note that match.cc(gfc_match_type_spec) has to deal with
> > REAL as a possible intrinsic function. See the comment
> >
> > /* REAL is a real pain because it can be a type, intrinsic subprogram,
> > or list item in a type-list of an OpenMP reduction clause. Need to
> > differentiate REAL([KIND]=scalar-int-initialization-expr) from
> > REAL(A,[KIND]) and REAL(KIND,A). Logically, when this code was
> > written the use of LOGICAL as a type-spec or intrinsic subprogram
> > was overlooked. */
>
> You're right.
>
> I just looked at the code that matches REAL, and it's... ugh. I could
> copy that, but it would certainly be complicated and error-prone, and
> I would like to avoid that.
Come now, I wrote that code! :-) And, yes, it's ugly.
> @Peter: Based on this, I would really like to stick with UINT, which has
> none of these problems.
>
> > BTW, I haven't checked with code, yet. Do you permit UNSIGNED*4, etc?
> > I would discourage such a declaration.
>
> It is currently not rejected, but this is also something that should
> be done. I'll put it on my to-do list.
>
When I gave gfortran the ability to have a type-spec in an array
constructor, I deliberated choose to only allow standard conforming
type-specs. match.cc(gfc_match_type_spec) was introduced to reject
the *4 notation.
program p
unsigned*4 :: a(2)
a = [unsigned*4 :: 1u, 2u]
print *, a
end
% gfcx -o z a.f90 -funsigned && ./z
a.f90:3:17:
3 | a = [unsigned*4 :: 1u, 2u]
| 1
Error: Invalid type-spec at (1)
The place where you'll need think about rejecting *4 is
in decl.cc(gfc_match_decl_type_spec).
--
Steve
