Re: [Patch, Fortran] libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056]

[Tobias Burnus <tobias@codesourcery.com>]

Hi Harald,

On 13.12.22 21:53, Harald Anlauf via Gcc-patches wrote:

>> I now did so - except for three fixes (cf. changelog). See also
>> PR: https://gcc.gnu.org/PR108056
>>
>> There is no testcase as it needs to be compiled by GCC <= 11 and then
>> run with linking (dynamically) to a GCC 12 or 13 libgfortran.
>
> I've looked at the resulting ISO_Fortran_binding.c vs. the 11-branch
> version and am still trying to understand the resulting differences
> in the code, in what respect they might be relevant or not.

Hmm, if I run a diff, I do not see much differences.

Note: We only talk about those two functions, the other functions are used
by both GCC <= 11 and GCC >= 12.

Fortunately, these functions matter most as they map GFC internals to CFI
internals or vice versa. Most other functions are user callable and there
incompatibilities are less likely to show up and GCC 11 users also could
profit from fixes there. It looks as if CFI_section and CFI_select_part had
some larger changes, likewise CFI_setpointer.

Back to differences: 'diff -U0 -p -w' against the last GCC 11 branch shows:

...
@@ -35,0 +37,2 @@ export_proto(cfi_desc_to_gfc_desc);
+/* NOTE: Since GCC 12, the FE generates code to do the conversion
+   directly without calling this function.  */
@@ -63 +66 @@ cfi_desc_to_gfc_desc (gfc_array_void *d,
-  d->dtype.version = s->version;
+  d->dtype.version = 0;
@@ -76,0 +80 @@ cfi_desc_to_gfc_desc (gfc_array_void *d,
+  if (GFC_DESCRIPTOR_DATA (d))
@@ -79,3 +83,7 @@ cfi_desc_to_gfc_desc (gfc_array_void *d,
-      GFC_DESCRIPTOR_LBOUND(d, n) = (index_type)s->dim[n].lower_bound;
-      GFC_DESCRIPTOR_UBOUND(d, n) = (index_type)(s->dim[n].extent
-                                               + s->dim[n].lower_bound - 1);
+       CFI_index_t lb = 1;
+
+       if (s->attribute != CFI_attribute_other)
+         lb = s->dim[n].lower_bound;
+
+       GFC_DESCRIPTOR_LBOUND(d, n) = (index_type)lb;
+       GFC_DESCRIPTOR_UBOUND(d, n) = (index_type)(s->dim[n].extent + lb - 1);
@@ -89,0 +98,2 @@ export_proto(gfc_desc_to_cfi_desc);
+/* NOTE: Since GCC 12, the FE generates code to do the conversion
+   directly without calling this function.  */
@@ -100,2 +110,2 @@ gfc_desc_to_cfi_desc (CFI_cdesc_t **d_pt
-    d = malloc (sizeof (CFI_cdesc_t)
-               + (CFI_type_t)(CFI_MAX_RANK * sizeof (CFI_dim_t)));
+    d = calloc (1, (sizeof (CFI_cdesc_t)
+                   + (CFI_type_t)(CFI_MAX_RANK * sizeof (CFI_dim_t))));
@@ -107 +117 @@ gfc_desc_to_cfi_desc (CFI_cdesc_t **d_pt
-  d->version = s->dtype.version;
+  d->version = CFI_VERSION;
@@ -153 +163 @@ void *CFI_address (const CFI_cdesc_t *dv
...

> Given that this is a somewhat delicate situation we're in, is there
> a set of tests that I could run *manually* (i.e. compile with gcc-11
> and link with gcc-12/13) to verify that this best-effort fix should
> be good enough for the common user?
>
> Just a suggestion of a few "randomly" chosen tests?

Probably yes. I don't have a better suggestion. The problem is that it
usually only matters in some corner cases, like in the PR where a not
some argument is passed to the GFC→CFI conversion but first a Fortran
function is called with TYPE(*) any only then it is passed on. – Such
cases are usually not in the testsuite. (With GCC 12 we have a rather
complex testsuite, but obviously it also does not cover everything.)


>> Note: It is strongly recommended to use GCC 12 (or 13) with
>> array-descriptor
>> C interop as many issues were fixed. [...]
>
> Well, in the real world there are larger installations with large
> software stacks, and it is easier said to "compile each component
> with the same compiler version" than done...

I concur – but there were really many fixes for the array descriptor /
TS29113 in GCC 12.

It is simply not possible to fix tons of bugs and be 100% compatible
with the working bits of the old version – especially if they only work
if one does not look sharply at the result. (Like here, were 'type' is
wrong, which does not matter unless in programs which use them.)

Thanks,

Tobias

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