From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 62C843858280; Tue, 20 Sep 2022 09:57:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 62C843858280 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1663667853; bh=HXGp1pnE6OPYzJkjGlyIsqeQfce4Tj7AMIqCHL4amQM=; h=From:To:Subject:Date:From; b=LSGJzD3MbfBU+7Svu/WRJ9r8A/n17wArWWSpWEER7nx2M42MBOmyT3+xFKaKuntsy 4UC44A8pSNy9afgOo7zBY7iDOZ3LqVSh237UjM4Mmkw+sDKlEtapvFYYqVJUxx63sk 4oH4G3X9SFAIMzMwZJUPKLqzrrpS/rAjYpqn5kWQ= From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: =?UTF-8?B?W0J1ZyBmb3J0cmFuLzEwNjk3NV0gTmV3OiBSRkMg4oCTIGFkZDog?= =?UTF-8?B?JyEkR0NDIEFUVFJJQlVURSBwcm9tb3RlX2tpbmQgOjonIChjb252ZXJ0X2tp?= =?UTF-8?B?bmQpIGZvciBpbnRlZ2VyL2xvZ2ljYWwgZHVtbXkgYXR0cmlidXRlcywgY2Yu?= =?UTF-8?B?ICchRElSJCBJR05PUkVfVEtSKGspJw==?= Date: Tue, 20 Sep 2022 09:57:30 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: openacc, openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106975 Bug ID: 106975 Summary: RFC =E2=80=93 add: '!$GCC ATTRIBUTE promote_kind ::' (convert_kind) for integer/logical dummy attributes, cf. '!DIR$ IGNORE_TKR(k)' Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: openacc, openmp Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- When writing interfaces to library functions, the number of interfaces requ= ired to implement increases because the TKI rule requires that the kind of the actual argument and the actual argument must be the same. If the defined API supports, e.g., subroutine omp_set_dynamic (dynamic_threads) logical, intent (in) :: dynamic_threads end subroutine omp_set_dynamic and with -fdefault-integer-8 this implies that both kind=3D4 and kind=3D8 h= ave to be supported. (For instance, by two specific functions under the same generic name). Similar issues exist for type(c_ptr) omp_target_alloc(size, device_num) where 'size' should support all sizes, i.e. up to huge(0_c_size_t) but it m= ight be much more convenient to pass a default-kind integer in most cases. If the implementation now supports all those, it means: kind=3D4 for size, device_num (-m32) kind=3D8 for size, device_num (-m64 -fdefault-integer-8) kind=3D4 for size, kind=3D8 for device_num (-m32 -fdefault-integer-8) kind=3D8 for size, kind=3D4 for device_num (-m64) Albeit only supporting default integer or always forcing c_size_t for size might be possible. The API upstream interfaces might settle for a subset which might then change when realizing that the default-kind "integer" might not be sufficient for size... Other compilers permit: !DIR$ IGNORE_TKR(k) to ignore the K of TKR (or more). I assume/hope this implies kind promotion= and not just ignoring the kind =E2=80=93 otherwise it seems to be rather pointless = to me, contrary to full 'tkr' (only a pointer is needed). In any case, I think it makes sense to have something like: !$GCC ATTRIBUTE promote_kind :: but restricting it to: * only integer and logical * only scalars * possibly only to VALUE, but in principle also intent(in/out/inout) are = also fine. + conversion warnings following the existing ones for assignments. I used 'promote_kind' but other names like 'convert_kind' would be equally = good (bike-shading!) And I think for real/complex the accidental precision loss is great (e.g. f= or decimal 0.1 represented as binary) and the demand is too low to support it = for real/complex as well. Likewise, I do not see a real point in doing this promotion for arrays albe= it it would be possible similar to the copy-in/out for arrays. (And with the s= ame restrictions + implications on pointer association.) See also https://gcc.gnu.org/onlinedocs/gfortran/ATTRIBUTES-directive.html = for the existing attributes, in particular ATTRIBUTES which supports NO_ARG_CHE= CK (and DEPRECATED). * * * I marked it as OpenMP/OpenACC topic as the -fdefault-integer-8 issue occurs= a lot (=E2=86=92 libgomp/{openacc.f90,openacc_lib.h,omp_lib.{h,f90}.in} ) and= there might be more issues coming up. (Not publicly visible: Cf. OpenMP spec's omp_targ= et_* in Fortran disscussion in issue 3348.)=