Re: [RFC] Change conversion function for unsigned from UINT to UNSIGNED
On Thu, Oct 24, 2024 at 07:46:28PM +0200, Thomas Koenig wrote: > > Peter Klausler noted in the discussion on github that Sun Fortran, > from which the UNSIGNED proposal was drawn, used UNSIGNED instead > of UINT for conversion of other types to UNSIGNED > (see https://docs.oracle.com/cd/E19205-01/819-5263/aevnb/index.html ). > Peter suggested that it would make sense for gfortran to follow that, > and that he would then also do the same in f18. > > For better compatibility with existing code (however much this may be), > I think it makes sense to also follow the existing practice, rather > than the J3 paper; and it also makes sense to keep such an extension > (for now, at least) synchronized between different compilers. This > might also increase the motivation of the committee to accept this > proposal. > > So, is such a patch OK in general? I would then prepare it. > There is also a documentation patch, which I have not yet finished. As Peter and you are doing the heavy lifting with the implementation details, I think this comes down to what he and you agree upon. UINT seems to naturally fit with AINT, ANINT, INT, and NINT. The 4 intrinsic function come from F77 and the 6 character limit, which isn't an issue today. In addition, for those coming from C/C++ (uint) is used in casting. OTOH, REALi and LOGICAL are used for conversion and UNSIGNED matches the overloading of the type with the conversion function. 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. */ BTW, I haven't checked with code, yet. Do you permit UNSIGNED*4, etc? I would discourage such a declaration. -- Steve
Re: [RFC] Change conversion function for unsigned from UINT to UNSIGNED
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
Re: [RFC] Change conversion function for unsigned from UINT to UNSIGNED
Hi Steve, 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. @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. Best regards Thomas
