*PING**2 – Re: [Patch] Fortran: Fix Bind(C) char-len check, add ptr-contiguous check
PING**2 On 25.08.21 20:58, Tobias Burnus wrote: Early *PING*. (I also should still review several Fortan patches... There are lots of patches waiting for review :-/) On 20.08.21 19:24, Tobias Burnus wrote: The following is about interoperability (BIND(C)) only. * The patch adds a missing check for pointer + contiguous. (Rejected to avoid copy-in issues? Or checking issues?) * And it corrects an issue regarding len > 1 characters. While subroutine foo(x) character(len=2) :: x(*) is valid Fortran code (the argument can be "abce" or ['a','b','c','d'] or ...) – and would work also with bind(C) as the len=2 does not need to be passed as hidden argument as len is a constant. However, it is not valid nonetheless. OK? Comments? Tobias PS: Referenced locations in the standard (F2018): C1554 If proc-language-binding-spec is specified for a procedure, each of its dummy arguments shall be an interoperable procedure (18.3.6) or a variable that is interoperable (18.3.4, 18.3.5), assumed-shape, assumed-rank, assumed-type, of type CHARACTER with assumed length, or that has the ALLOCATABLE or POINTER attribute. 18.3.1: "... If the type is character, the length type parameter is interoperable if and only if its value is one. ..." "18.3.4 Interoperability of scalar variables": "... A named scalar Fortran variable is interoperable ... if it is of type character12its length is not assumed or declared by an expression that is not a constant expression." 18.3.5: Likewise but for arrays. 18.3.6 "... Fortran procedure interface is interoperable with a C function prototype ..." "(5) any dummy argument without the VALUE attribute corresponds to a formal parameter of the prototype that is of a pointer type, and either • the dummy argument is interoperable with an entity of the referenced type ..." (Remark: those are passed as byte stream) "• the dummy argument is a nonallocatable nonpointer variable of type CHARACTER with assumed character length and the formal parameter is a pointer to CFI_cdesc_t, • the dummy argument is allocatable, assumed-shape, assumed-rank, or a pointer without the CONTIGUOUS attribute, and the formal parameter is a pointer to CFI_cdesc_t, or (Remark: those two use an array descriptor, also for explicit-size/assumed-size arrays or for scalars.) • the dummy argument is assumed-type ..." - 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: [RFH] ME optimizes variable assignment away / Fortran bind(C) descriptor conversion
Hi all, hi Richard,
On 27.08.21 21:48, Richard Biener wrote:
It looks really nice with "-O1 -fno-inline" :-)
The callee 'rank_p()' is mostly optimized and in the
caller only those struct elements are set, which are used:
integer(kind=4) rank_p (struct CFI_cdesc_t & _this)
{
_1 = _this_11(D)->base_addr;
_2 = _this_11(D)->rank;
...
rnk_13 = (integer(kind=4)) _2;
return rnk_13;
}
void selr_p ()
{
...
struct CFI_cdesc_t01 cfi.7;
...
[local count: 537730764]:
cfi.7.rank = 1;
cfi.7.base_addr = 0B;
You need to do the accesses above using the generic 't' type as well, otherwise
they are non-conflicting TBAA wise.
First, I wonder why the following works with C:
struct gen_t { int n; int dim[]; }
int f (struct gen_t *x) {
if (x->n > 1) x->dim[0] = 5;
return x->n;
}
void test() {
struct { int n; int dim[2]; } y;
y.n = 2;
f ((struct gen_t*) &y);
}
Or doesn't it? In any case, that's how it is suggested
and 'y.n' is not accessed using 'gen_t' – there is only
a cast in the function call. (Which is not sufficient
in the Fortran FE-code generated code – as tried)
* * *
Otherwise, I can confirm that the following works.
Does this original dump now looks fine?
struct CFI_cdesc_t01 cfi.2;
...
((struct CFI_cdesc_t *) &cfi.2)->version = 1;
((struct CFI_cdesc_t *) &cfi.2)->rank = 1;
((struct CFI_cdesc_t *) &cfi.2)->type = 1025;
((struct CFI_cdesc_t *) &cfi.2)->attribute = 0;
((struct CFI_cdesc_t *) &cfi.2)->base_addr = intp.data;
((struct CFI_cdesc_t *) &cfi.2)->elem_len = 4;
...
irnk = rank_p ((struct CFI_cdesc_t *) &cfi.2);
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: Fwd: FortranCon 2021
Hi all, I want to note that the FortranCon 2021 is in the same week as the GNU Tools @ Linux Plumbers Conference, https://gcc.gnu.org/wiki/linuxplumbers2021 – Mon 20 to Fri 24 September, 07:00–11:00 a.m. PDT / 16:00–20:00 CEST with submission deadline next Tuesday. While the FortranCon is Thu 23 and Fri 24 September, 05:00–10:00 a.m. PDT / 14:00–19:00 CEST. (Submission deadline next Wednesday, https://tcevents.chem.uzh.ch/event/14/) If you choose the attend GNU Tools @ LPC, we may see us in one of a BoFs. Tobias PS: I think I will skip the FortranCon – also because additionally the OpenMP specification face-2-face meeting is in the same week (6a.m.–1.p.m. PDT / 15:00–22:00 CEST). – Regarding talking about GCC & OpenMP: I will talk about this in a joined talk at OpenMPCon on Monday 13 Sept. https://openmpcon.org/
Re: [Patch v2] C, C++, Fortran, OpenMP: Add support for device-modifiers for 'omp target device'
On Wed, Aug 25, 2021 at 12:14:09PM +0200, Marcel Vollweiler wrote: > Add support for device-modifiers for 'omp target device'. > > 'device_num' and 'ancestor' are now parsed on target device constructs for C, > C++, and Fortran (see OpenMP specification 5.0, p. 170). When 'ancestor' is > used, then 'sorry, not supported' is output. Moreover, the restrictions for > 'ancestor' are implemented (see OpenMP specification 5.0, p. 174f). > > gcc/c/ChangeLog: > > * c-parser.c (c_parser_omp_clause_device): Parse device-modifiers > 'device_num' > and 'ancestor' in 'target device' clauses. > > gcc/cp/ChangeLog: > > * parser.c (cp_parser_omp_clause_device): Parse device-modifiers > 'device_num' > and 'ancestor' in 'target device' clauses. > * semantics.c (finish_omp_clauses): Error handling. Constant device ids > must > evaluate to '1' if 'ancestor' is used. > > gcc/fortran/ChangeLog: > > * gfortran.h: Add variable for 'ancestor' in struct gfc_omp_clauses. > * openmp.c (gfc_match_omp_clauses): Parse device-modifiers 'device_num' > and 'ancestor' in 'target device' clauses. > * trans-openmp.c (gfc_trans_omp_clauses): Set > OMP_CLAUSE_DEVICE_ANCESTOR. > > gcc/ChangeLog: > > * gimplify.c (gimplify_scan_omp_clauses): Error handling. 'ancestor' > only > allowed on target constructs and only with particular other clauses. > * omp-expand.c (expand_omp_target): Output of 'sorry, not supported' if > 'ancestor' is used. > * omp-low.c (check_omp_nesting_restrictions): Error handling. No nested > OpenMP > structs when 'ancestor' is used. > (scan_omp_1_stmt): No usage of OpenMP runtime routines in a target > region when > 'ancestor' is used. > * tree-pretty-print.c (dump_omp_clause): Append 'ancestor'. > * tree.h (OMP_CLAUSE_DEVICE_ANCESTOR): Define macro. > > gcc/testsuite/ChangeLog: > > * c-c++-common/gomp/target-device-1.c: New test. > * c-c++-common/gomp/target-device-2.c: New test. > * c-c++-common/gomp/target-device-ancestor-1.c: New test. > * c-c++-common/gomp/target-device-ancestor-2.c: New test. > * c-c++-common/gomp/target-device-ancestor-3.c: New test. > * c-c++-common/gomp/target-device-ancestor-4.c: New test. > * gfortran.dg/gomp/target-device-1.f90: New test. > * gfortran.dg/gomp/target-device-2.f90: New test. > * gfortran.dg/gomp/target-device-ancestor-1.f90: New test. > * gfortran.dg/gomp/target-device-ancestor-2.f90: New test. > * gfortran.dg/gomp/target-device-ancestor-3.f90: New test. > * gfortran.dg/gomp/target-device-ancestor-4.f90: New test. Ok, thanks. Jakub
Re: [RFH] ME optimizes variable assignment away / Fortran bind(C) descriptor conversion
On Sun, Aug 29, 2021 at 10:07 AM Tobias Burnus wrote:
>
> Hi all, hi Richard,
>
> On 27.08.21 21:48, Richard Biener wrote:
> >> It looks really nice with "-O1 -fno-inline" :-)
> >>The callee 'rank_p()' is mostly optimized and in the
> >>caller only those struct elements are set, which are used:
> >>
> >> integer(kind=4) rank_p (struct CFI_cdesc_t & _this)
> >> {
> >>_1 = _this_11(D)->base_addr;
> >>_2 = _this_11(D)->rank;
> >> ...
> >>rnk_13 = (integer(kind=4)) _2;
> >>return rnk_13;
> >> }
> >>
> >> void selr_p ()
> >> {
> >> ...
> >>struct CFI_cdesc_t01 cfi.7;
> >> ...
> >> [local count: 537730764]:
> >>cfi.7.rank = 1;
> >>cfi.7.base_addr = 0B;
> > You need to do the accesses above using the generic 't' type as well,
> > otherwise they are non-conflicting TBAA wise.
>
> First, I wonder why the following works with C:
>
> struct gen_t { int n; int dim[]; }
>
> int f (struct gen_t *x) {
> if (x->n > 1) x->dim[0] = 5;
> return x->n;
> }
>
> void test() {
> struct { int n; int dim[2]; } y;
> y.n = 2;
> f ((struct gen_t*) &y);
> }
>
> Or doesn't it?
It probably doesn't and suffers from the same issue as your
original fortran code.
>In any case, that's how it is suggested
> and 'y.n' is not accessed using 'gen_t' – there is only
> a cast in the function call. (Which is not sufficient
> in the Fortran FE-code generated code – as tried)
>
> * * *
>
> Otherwise, I can confirm that the following works.
> Does this original dump now looks fine?
>
> struct CFI_cdesc_t01 cfi.2;
> ...
> ((struct CFI_cdesc_t *) &cfi.2)->version = 1;
> ((struct CFI_cdesc_t *) &cfi.2)->rank = 1;
> ((struct CFI_cdesc_t *) &cfi.2)->type = 1025;
> ((struct CFI_cdesc_t *) &cfi.2)->attribute = 0;
> ((struct CFI_cdesc_t *) &cfi.2)->base_addr = intp.data;
> ((struct CFI_cdesc_t *) &cfi.2)->elem_len = 4;
> ...
> irnk = rank_p ((struct CFI_cdesc_t *) &cfi.2);
Yes, that looks OK now. The idea is you can use the complete
types for storage allocation but you _always_ have to use the
incomplete (with flexarray member) type for all accesses.
Richard.
> 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
