Re: Team Collaboration Considerations
On Sun, Dec 4, 2022 at 5:53 AM Jerry D via Fortran wrote: > 1. Slack has adopted some limitations on being able to go back and look > at older posts. Functionally it is quite good and integrates well > with github. > 2. I looked at Element and Fractal which use the Matrix protocols. > Very open source, not so mature yet. > 3. Mattermost looks pretty good and was easy to set up. The free > version is a bit better than Slacks. GCC C++ uses it. > > If we can get a concensus I would happy to get something set up . I am > leaning to Mattermost. The mobile phone app is easy and the web browser > works fine. > > I do think in the long run, doing this will help everyone greatly. > > Any thoughts from all? Hi, I haven't commented earlier as I haven't been active in GFortran development for a couple of years (new job, kids, etc. etc.). So don't take my opinions too seriously. But in general, yes, I do think IRC is showing its age in an increasingly multi-device and mobile world. From a Free Software perspective, adopting a closed platform like Slack is perhaps not ideal, if alternatives exist. And I believe the free (as in beer) version of Slack has some significant limitations compared to the licensed one. Matrix is perhaps the one with the most future potential, but maybe it's not really there yet. While I haven't used Mattermost myself, I've heard good things about it. And as long as it's not used as some sort of permanent record of things instead of the mailing list, I guess it's relatively easy to switch to another platform in the future. Just to be sure, this is some hosted version, and not something which Jerry must maintain himself on some server in a dusty corner? As for the perennial question of how to attract new contributors, yeah, it's hard. I'm happy to see that Harald has gotten off to a flying start, amazing! I also do note with some satisfaction that there's some good efforts to make modern Fortran attractive for developers, and not just something you use because the codebase you work on was started 4 decades ago. Gtk-Fortran was an early example of this which showed that modern Fortran could be useful outside the core numerics domain. I'm also thinking of the https://fortran-lang.org site and associated efforts like the 'stdlib', a more fleshed out 'standard' library (https://stdlib.fortran-lang.org/ ), and the package manager FPM (https://fpm.fortran-lang.org ). Keeping in touch with these people, and suggesting that people help that effort if they aren't comfortable with hacking on the compiler outright, could be a way of growing the open source Fortran programmer base, which could eventually grow into contributors to the compiler itself? In particular if they want to use some newfangled Fortran feature that doesn't work in GFortran; scratching your own itch is always a good motivator! -- Janne Blomqvist
Re: Team Collaboration Considerations
On 12/13/22 12:10 AM, Janne Blomqvist wrote: --- snip -- Any thoughts from all? Hi, I haven't commented earlier as I haven't been active in GFortran development for a couple of years (new job, kids, etc. etc.). So don't take my opinions too seriously. But in general, yes, I do think IRC is showing its age in an increasingly multi-device and mobile world. From a Free Software perspective, adopting a closed platform like Slack is perhaps not ideal, if alternatives exist. And I believe the free (as in beer) version of Slack has some significant limitations compared to the licensed one. Matrix is perhaps the one with the most future potential, but maybe it's not really there yet. While I haven't used Mattermost myself, I've heard good things about it. And as long as it's not used as some sort of permanent record of things instead of the mailing list, I guess it's relatively easy to switch to another platform in the future. Just to be sure, this is some hosted version, and not something which Jerry must maintain himself on some server in a dusty corner? As for the perennial question of how to attract new contributors, yeah, it's hard. I'm happy to see that Harald has gotten off to a flying start, amazing! I also do note with some satisfaction that there's some good efforts to make modern Fortran attractive for developers, and not just something you use because the codebase you work on was started 4 decades ago. Gtk-Fortran was an early example of this which showed that modern Fortran could be useful outside the core numerics domain. I'm also thinking of the https://fortran-lang.org site and associated efforts like the 'stdlib', a more fleshed out 'standard' library (https://stdlib.fortran-lang.org/ ), and the package manager FPM (https://fpm.fortran-lang.org ). Keeping in touch with these people, and suggesting that people help that effort if they aren't comfortable with hacking on the compiler outright, could be a way of growing the open source Fortran programmer base, which could eventually grow into contributors to the compiler itself? In particular if they want to use some newfangled Fortran feature that doesn't work in GFortran; scratching your own itch is always a good motivator! Hi Janne, great to hear from you and thanks for mentioning the efforts of others. Best regards, Jerry
[Patch, Fortran] libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056]
This is a 12/13 regression as come changes to fix the GFC/CFI descriptor
that went into GCC 12 fail with the (bogus) descriptor passed via by a
GCC-11-compiled program.
As later GCC 12 changes moved the descriptor to the front end, those
functions are only in libgomp.so to cater for old program. Richard
suggested in the PR that the best way is to move to the GCC 11 version,
such that libgfortran.so won't regress.
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.
OK for mainline and GCC 12?
* * *
Note: It is strongly recommended to use GCC 12 (or 13) with array-descriptor
C interop as many issues were fixed. Like for the testcase in the PR; in GCC 11
the type arriving in libgomp is BT_ASSUME ('type(*)'). But as the effective
argument is passed as array descriptor through out, the 'float' (real(4)) type
info is actually preservable (as GCC 12 cf. testcase of comment 0 and my comment
in the PR for the C part of the testcase).(*)
Tobias
((*) This is not possible if using a scalar 'type(*)' or a non-array-descriptor
array in between. I think GCC 12 uses 'CFI_other' in the information-is-lost
case.)
-
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
libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056]
Since GCC 12, the conversion between the array descriptors formats - the
internal (GFC) and the C binding one (CFI) moved to the compiler itself
such that the cfi_desc_to_gfc_desc/gfc_desc_to_cfi_desc functions are only
used with older code (GCC 9 to 11). The newly added checks caused asserts
as older code did not pass the proper values (e.g. real(4) as effective
argument arrived as BT_ASSUME type as the effective type got lost inbetween).
As proposed in the PR, revert to the GCC 11 version - known bugs is better
than some fixes and new issues. Still, GCC 12 is much better in terms of
TS29113 support and should really be used.
This patch uses the current libgomp version of the GCC 11 branch, except
it fixes the GFC version number (which is 0), uses calloc instead of malloc,
and sets the lower bound to 1 instead of keeping it as is for
CFI_attribute_other.
libgfortran/ChangeLog:
PR libfortran/108056
* runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc,
gfc_desc_to_cfi_desc): Mostly revert to GCC 11 version for
those backward-compatiblity-only functions.
diff --git a/libgfortran/runtime/ISO_Fortran_binding.c b/libgfortran/runtime/ISO_Fortran_binding.c
index 342df4275b9..e63a717a69b 100644
--- a/libgfortran/runtime/ISO_Fortran_binding.c
+++ b/libgfortran/runtime/ISO_Fortran_binding.c
@@ -39,60 +39,31 @@ export_proto(cfi_desc_to_gfc_desc);
void
cfi_desc_to_gfc_desc (gfc_array_void *d, CFI_cdesc_t **s_ptr)
{
- signed char type;
- size_t size;
int n;
+ index_type kind;
CFI_cdesc_t *s = *s_ptr;
if (!s)
return;
- /* Verify descriptor. */
- switch (s->attribute)
-{
-case CFI_attribute_pointer:
-case CFI_attribute_allocatable:
- break;
-case CFI_attribute_other:
- if (s->base_addr)
- break;
- runtime_error ("Nonallocatable, nonpointer actual argument to BIND(C) "
- "dummy argument where the effective argument is either "
- "not allocated or not associated");
- break;
-default:
- runtime_error ("Invalid attribute type %d in CFI_cdesc_t descriptor",
- (int) s->attribute);
- break;
-}
GFC_DESCRIPTOR_DATA (d) = s->base_addr;
+ GFC_DESCRIPTOR_TYPE (d) = (signed char)(s->type & CFI_type_mask);
+ kind = (index_type)((s->type - (s->type & CFI_type_mask)) >> CFI_type_kind_shift);
/* Correct the unfortunate difference in order with types. */
- type = (signed char)(s->type & CFI_type_mask);
- switch (type)
-{
-case CFI_type_Character:
- type = BT_CHARACTER;
- break;
-case CFI_type_struct:
- type = BT_DERIVED;
- break;
-case CFI_type_cptr:
- /* FIXME: PR 100915. GFC descriptors do not distinguish between
- CFI_type_cptr and CFI_type_cfunptr. */
- type = BT_VOID;
- break;
-default:
- break;
-}
-
- GFC_DESCRIPTOR_TYPE (d) = type;
- GFC_DESCRIPTOR_SIZE (d) = s->elem_len;
+ if (GFC_DESCRIPTOR_TYPE (d) == BT_CHARACTER)
+GFC_DESCRIPTOR_TYPE (d) = BT_DERIVED;
+ else if (GFC_DESCRIPTOR_TYPE (d) == BT_DERIVED)
+GFC_DESCRIPTOR_TYPE (d) = BT_CHARACTER;
+
+ if (!s->rank || s->dim[0].sm == (CFI_index_t)s->elem_len)
+GFC_DESCRIPTOR_SIZE (d) = s->elem_len;
+ else if (GFC_DESCRIPTOR_TYPE (d) != BT_DERIVED)
+GFC_DESCRIPTOR_SIZE (d) = kind;
+ else
+GFC_DESCRIPTOR_SIZE (d) = s->elem_len;
d->dtype.version =
[Patch] Fortran: Extend align-clause checks of OpenMP's allocate clause
I missed that 'align' needs to be a power of 2 - contrary to 'aligned',
which does not have this restriction for some odd reason.
OK for mainline?
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
Fortran: Extend align-clause checks of OpenMP's allocate directive
gcc/fortran/ChangeLog:
* openmp.cc (resolve_omp_clauses): Check also for
power of two.
libgomp/ChangeLog:
* testsuite/libgomp.fortran/allocate-3.f90: Fix ALIGN
usage, remove unused -fdump-tree-original.
* testsuite/libgomp.fortran/allocate-4.f90: New.
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 686f924b47a..5468cc97969 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -7315,11 +7315,12 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses *omp_clauses,
|| n->u.align->ts.type != BT_INTEGER
|| n->u.align->rank != 0
|| gfc_extract_int (n->u.align, &alignment)
- || alignment <= 0)
+ || alignment <= 0
+ || !pow2p_hwi (alignment))
{
- gfc_error ("ALIGN modifier requires a scalar positive "
- "constant integer alignment expression at %L",
- &n->u.align->where);
+ gfc_error ("ALIGN modifier requires at %L a scalar positive "
+ "constant integer alignment expression that is a "
+ "power of two", &n->u.align->where);
break;
}
}
diff --git a/libgomp/testsuite/libgomp.fortran/allocate-3.f90 b/libgomp/testsuite/libgomp.fortran/allocate-3.f90
index a39819164d6..1fa0bb932c3 100644
--- a/libgomp/testsuite/libgomp.fortran/allocate-3.f90
+++ b/libgomp/testsuite/libgomp.fortran/allocate-3.f90
@@ -1,5 +1,4 @@
! { dg-do compile }
-! { dg-additional-options "-fdump-tree-original" }
use omp_lib
implicit none
@@ -23,6 +22,7 @@ integer :: q, x,y,z
! { dg-error "Object 'omp_high_bw_mem_alloc' is not a variable" "" { target *-*-* } .-1 }
!$omp end parallel
-!$omp parallel allocate( align(q) : x) firstprivate(x) ! { dg-error "31:ALIGN modifier requires a scalar positive constant integer alignment expression at" }
+!$omp parallel allocate( align(128) : x) firstprivate(x) ! OK
!$omp end parallel
+
end
diff --git a/libgomp/testsuite/libgomp.fortran/allocate-4.f90 b/libgomp/testsuite/libgomp.fortran/allocate-4.f90
new file mode 100644
index 000..ddb507ba8e4
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/allocate-4.f90
@@ -0,0 +1,42 @@
+! { dg-do compile }
+
+
+subroutine test()
+use iso_c_binding, only: c_intptr_t
+implicit none
+integer, parameter :: omp_allocator_handle_kind = 1 !! <<<
+integer (kind=omp_allocator_handle_kind), &
+ parameter :: omp_high_bw_mem_alloc = 4
+integer :: q, x,y,z
+integer, parameter :: cnst(2) = [64, 101]
+
+!$omp parallel allocate( omp_high_bw_mem_alloc : x) firstprivate(x) ! { dg-error "Expected integer expression of the 'omp_allocator_handle_kind' kind" }
+!$omp end parallel
+
+!$omp parallel allocate( allocator (omp_high_bw_mem_alloc) : x) firstprivate(x) ! { dg-error "Expected integer expression of the 'omp_allocator_handle_kind' kind" }
+!$omp end parallel
+
+!$omp parallel allocate( align (q) : x) firstprivate(x) ! { dg-error "32:ALIGN modifier requires at \\(1\\) a scalar positive constant integer alignment expression that is a power of two" }
+!$omp end parallel
+
+!$omp parallel allocate( align (32) : x) firstprivate(x) ! OK
+!$omp end parallel
+
+!$omp parallel allocate( align(q) : x) firstprivate(x) ! { dg-error "31:ALIGN modifier requires at \\(1\\) a scalar positive constant integer alignment expression that is a power of two" }
+!$omp end parallel
+
+!$omp parallel allocate( align(cnst(1)) : x ) firstprivate(x) ! OK
+!$omp end parallel
+
+!$omp parallel allocate( align(cnst(2)) : x) firstprivate(x) ! { dg-error "31:ALIGN modifier requires at \\(1\\) a scalar positive constant integer alignment expression that is a power of two" }
+!$omp end parallel
+
+!$omp parallel allocate( align( 31) :x) firstprivate(x) ! { dg-error "32:ALIGN modifier requires at \\(1\\) a scalar positive constant integer alignment expression that is a power of two" }
+!$omp end parallel
+
+!$omp parallel allocate( align (32.0): x) firstprivate(x) ! { dg-error "32:ALIGN modifier requires at \\(1\\) a scalar positive constant integer alignment expression that is a power of two" }
+!$omp end parallel
+
+!$omp parallel allocate( align(cnst ) : x ) firstprivate(x) ! { dg-error "31:ALIGN modifier requires at \\(1\\) a scalar positive constant integer alignment expression that is a power of two" }
+!$omp end parallel
+end
Re: [Patch, Fortran] libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056]
Hi Tobias,
Am 13.12.22 um 17:29 schrieb Tobias Burnus:
This is a 12/13 regression as come changes to fix the GFC/CFI descriptor
that went into GCC 12 fail with the (bogus) descriptor passed via by a
GCC-11-compiled program.
As later GCC 12 changes moved the descriptor to the front end, those
functions are only in libgomp.so to cater for old program. Richard
suggested in the PR that the best way is to move to the GCC 11 version,
such that libgfortran.so won't regress.
that appears to be the most reasonable & practical way to go.
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 verified that the testcase in the PR does not crash with
the re-modified 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.
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?
OK for mainline and GCC 12?
* * *
Note: It is strongly recommended to use GCC 12 (or 13) with
array-descriptor
C interop as many issues were fixed. Like for the testcase in the PR; in
GCC 11
the type arriving in libgomp is BT_ASSUME ('type(*)'). But as the effective
argument is passed as array descriptor through out, the 'float'
(real(4)) type
info is actually preservable (as GCC 12 cf. testcase of comment 0 and my
comment
in the PR for the C part of the testcase).(*)
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've just had another personal experience during my daytime job.)
Thanks for your effort so far!
Harald
Tobias
((*) This is not possible if using a scalar 'type(*)' or a
non-array-descriptor
array in between. I think GCC 12 uses 'CFI_other' in the
information-is-lost case.)
-
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
Re: [Patch, Fortran] libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056]
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
Re: [Patch, Fortran] libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056]
Hi Tobias, Am 13.12.22 um 22:41 schrieb Tobias Burnus: Note: We only talk about those two functions, the other functions are used by both GCC <= 11 and GCC >= 12. yes. 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; I was wondering what the significance of "version" is. In ISO_Fortran_binding.h we seem to always have #define CFI_VERSION 1 and it did not change with gcc-12. If it is just decoration (for now), then it is not important. I just didn't see where it is used. @@ -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); Oh, now I see that on 11-branch in trans-expr.c we set a hard-coded attribute = 2 instead of using CFI_attribute_other, even if that was available as a macro defining the very same value. Thus it is ok. @@ -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; This treatment of "version" was the equivalent to the above that confused me. Assuming we were to change CFI_VERSION in gcc-13+, is this the right choice here regarding backward compatibility? 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.) Well, I understand we have to draw a line here, whether we reproduce every bug in <= gcc-11 where the user may have attempted to implement a workaround. That might be tough. 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.) True. I was only thinking of the 90+ percent of valid and common uses that we really consider important. So besides the "version" question ok from my side. Thanks, Harald 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
Re: [Patch, Fortran] libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056]
Hi Harald, On 13.12.22 23:27, Harald Anlauf wrote: Am 13.12.22 um 22:41 schrieb Tobias Burnus: 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; I was wondering what the significance of "version" is. In ISO_Fortran_binding.h we seem to always have #define CFI_VERSION 1 and it did not change with gcc-12. The version is 1 for CFI but it is 0 for GFC. However, as we do not check the GFC version anywhere and it is not publicly exposed, it does not really matter. Still, "d->dtype.version = 0;" matches what the compiler itself produces – and for consistency, setting it to 0 is better than setting it to 1 (via CFI's version field). Actually 'dtype.version' is not really set anywhere; at least gfc_get_dtype_rank_type(...) does not set it; zero initialization is most common but it could be also some random value. In libgfortran, GFC_DTYPE_CLEAR explicitly sets it to 0. @@ -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; This treatment of "version" was the equivalent to the above that confused me. Assuming we were to change CFI_VERSION in gcc-13+, is this the right choice here regarding backward compatibility? I don't think we will change CFI version any time soon as we rather closely follow the Fortran standard and I do not see any changes which are required there. NOTE: As s->dtype.version is either 0 or some random value, setting version in the CFI / ISO C descriptor to 1, be it as literal or as macro constant, makes it the same as CFI_VERSION. And: I don't think we will change CFI_VERSION or the structure of the CFI array descriptor any time soon; there does not seem to be any need for it, it matches the Fortran standard one well (and no plans seem to be planed on that side) and, finally, changing an array descriptor is painful! However, using '1; /* CFI_VERSION in GCC 11 and at time of writing. */' would also work – but I would expect that we will go through all CFI users if we ever change the descriptor (and bump the version), possibly adding version-number dependent code. So besides the "version" question ok from my side. I hope I could answer the latter. 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
