Good to go Tobias.

Jerry

On 7/14/21 5:50 AM, Burnus, Tobias wrote:
Ping**2

On Juli 8, 2021 I wrote:

*Ping*

I intent to incorporate Sandra's suggestions, except for the beginning of line 
spacing - that's needed to avoid exceeding the 80 character line limit. I did 
not include an updated patch as just pinging is easier on a mobile during 
vacation :-)

Thanks,

Tobias

Loosemore, Sandra wrote:

On 7/1/21 11:08 AM, Tobias Burnus wrote:
Hi all,

this patch came up when discussing Sandra's TS29113 patch internally.
There is presumably also some overlap with José's patches.

This patch tries to rectify the BIND(C) CHARACTER handling on the
diagnostic side, only. That is: what to accept and what
to reject for which Fortran standard.


The rules are:

* [F2003-F2018] Interoperable is character(len=1)
    → F2018, 18.3.1  Interoperability of intrinsic types
    (General, unchanged)

* Fortran 2008: In some cases, const-length chars are
    permitted as well:
    → F2018, 18.3.4  Interoperability of scalar variables
    → F2018, 18.3.5  Interoperability of array variables
    → F2018, 18.3.6  Interoperability of procedures and procedure interfaces
   [= F2008, 15.3.{4,5,6}
For global vars with bind(C), 18.3.4 + 18.3.5 applies directly (TODO:
Add support, not in this patch)
For passed-by ref dummy arguments, 18.3.4 + 18.3.5 are referenced in
- F2008: R1229  proc-language-binding-spec is language-binding-spec
           C1255 (R1229) <see wording there>
- F2018, F2018, C1554

While it is not very clearly spelt out, I regard 'char parm[4]'
interoperable with 'character(len=4) :: a', 'character(len=2) :: b(2)'
and 'character(len=1) :: c(4)' for both global variables and for
dummy arguments.

* Fortran 2018/TS29113:  Uses additionally CFI array descriptor
    - allocatable, pointer:  must be len=:
    - nonallocatable/nonpointer: len=* → implies array descriptor also
      for assumed-size/explicit-size/scalar arguments.
    - All which all passed by an array descriptor already without further
      restrictions: assumed-shape, assumed-rank, i.e. len=<nonconst> seems
      to be also fine
→ 18.3.6 under item (5) bullet point 2 and 3 plus (6).


I hope I got the conditions right. I also fixed an issue with
character(len=5) :: str – the code in trans-expr.c did crash for
scalars  (decl.c did not check any constraints for arrays).
I believe the condition is wrong and for len=<const> no descriptor
is used.

Any comments, remarks?
I gave this patch a try on my TS 29113 last night.  Changing the error
messages kind of screwed up my list of FAILs, but I did see that it also
caught some invalid character arguments in
interoperability/typecodes-scalar.f90 and
interoperability/typecodes-scalar-ext.f90 (which are already broken by 2
other major gfortran bugs I still need to file PRs for).  :-S

I haven't tried to review the patch WRT correctness with the
requirements of the standard yet, but I have a few nits about error
messages....

+               /* F2018, 18.3.6 (6).  */
+               if (!sym->ts.deferred)
+                 {
+                   gfc_error ("Allocatable and pointer character dummy "
+                              "argument %qs at %L must have deferred length "
+                              "as procedure %qs is BIND(C)", sym->name,
+                              &sym->declared_at, sym->ns->proc_name->name);
+                   retval = false;
+                 }
This is the error the two aforementioned test cases started giving, but
message is confusing and doesn't read well (it was a pointer dummy, not
"allocatable and pointer").  Maybe just s/and/or/, or customize the
message depending on which one it is?

+                   gfc_error ("Character dummy argument %qs at %L must be "
+                              "of constant length or assumed length, "
+                              "unless it has assumed-shape or assumed-rank, "
+                              "as procedure %qs has the BIND(C) attribute",
+                              sym->name, &sym->declared_at,
+                              sym->ns->proc_name->name);
I don't think either "assumed-shape" or "assumed-rank" should be
hyphenated in this context unless that exact hyphenation is a term of
art in the Fortran standard or other technical documentation.  In normal
English, adjective phrases are usually only hyphenated when they appear
immediately before the noun they modify; "assumed-shape array", but "an
array with assumed shape".

+               else if (!gfc_notify_std (GFC_STD_F2018,
+                                         "Character dummy argument %qs at %L"
+                                         " with nonconstant length as "
+                                         "procedure %qs is BIND(C)",
+                                         sym->name, &sym->declared_at,
+                                         sym->ns->proc_name->name))
+                 retval = false;
+             }
Elsewhere the convention seems to be to format strings split across
multiple lines with a space at the end of each chunk rather than at the
beginning.

-Sandra
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Reply via email to