From: Tobias Burnus <tburnus@baylibre.com>
To: Thomas Schwinge <tschwinge@baylibre.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [Patch] OpenACC: Update libgomp.texi + openacc{.f90,_lib.h} for 3.1 arg-name changes
Date: Fri, 1 Mar 2024 15:09:58 +0100 [thread overview]
Message-ID: <bda4a56b-001a-4d52-b49d-9273ecb113dc@baylibre.com> (raw)
In-Reply-To: <87sf1a6qa1.fsf@euler.schwinge.ddns.net>
[-- Attachment #1: Type: text/plain, Size: 3548 bytes --]
Hi Thomas,
Thomas Schwinge wrote:
> On 2024-02-27T20:11:30+0100, Tobias Burnus<tburnus@baylibre.com> wrote:
>> The attached patch updates the manual to match OpenACC 3.3
>> specification for the implemented routines.
> But not update references to OpenACC 3.3, too?
As the change is not really visible (except when using Fortran
keywords), it was not really clear to me whether the reference should be
either changed to *or* augmented by the OpenACC 3.1 *or* 3.3
specification reference.
What do you prefer? 3.1 or 3.3, in addition or instead of the existing
2.x (?) references?
> The questions is whether we want to do this now, or once we actually
> support 3.1 or 3.3; what was your intention for preparing this now?
Fallout of some bug fixes I intended to to in the .texi file, which in
turn was a fallout of the trivial addition of the 3.3 interfaces for
Fortran. Well, then I realized that 3.1 changed the argument names as well.
I think we should at least do the .texi bug fixes. Additionally, those
'type, dimension(:[,:]...)' look very odd – thus, I would be inclined to
do those as well.
Otherwise, it is more the question when to break the keyword= API;
fortunately, it is not an ABI issue as the compiler just uses it to
reorder the arguments back to the original declaration.
>> NOTE: Those argument names *do* have an effect and can be a breaking
>> change as Fortran permits using the arg name in the call, e.g.,
>> call acc_copyin(a=myVar) ! old
>> must now be called either as
>> call acc_copyin(data_arg=myVar) ! new
>> or as
>> call acc_copyin(myVar) ! works with old and new names
>> As the latter is way more common, the spec change hopefully does not
>> break too many programs.
> I wonder: would it happen to be possible via "Fortran interface magic" to
> actually support several variants of named arguments? I agree we can
> drop any bogus GCC-local variants, but is it possible to support all the
> official variants?
Obviously not as the default (Fortran + real world) is to use no
keywords – and then the two variants become ambiguous. Therefore,
Fortran doesn't permit to combine two specific functions that only
differ in this aspect.
If a real-world program uses the keywords by ill chance, it still had
the very same problem depending on the compiler version and vendor as
that's an upstream spec change.
The simple solution on the program side is just to drop the keyword –
then it will work with either variant.
I think only very programs are affected – possibly even none. And I
wonder how other compilers handle this, given that they also started
implementing (selected) OpenACC 2.7 and 3.x features (including 3.3, as
real-world programs proof).
>> And, finally, it synced over all named constants from openacc.f90 to
>> config/accel/openacc.f90.
> I don't think that's necessary: as I understand, that one's for
> 'acc_on_device' only?
I think you are right — unless 'f951' is run on the device side, which
won't happen for offloading, the accelerator version of the module file
is not read – only the host version. The named constants will be
expanded early to their numeric value and only the procedure calls
remain. — Of those, only 'acc_on_device' has to be available on the
device side and — hence, it is used at lto/link time by the device-side
of the linker (by linking libgomp.a).
Thus, I withdraw this change as not being required, not harming, but
wasting some GCC-build-time (only) file storage size and CPU cycles.
Tobias
prev parent reply other threads:[~2024-03-01 14:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 19:11 Tobias Burnus
2024-03-01 13:21 ` Thomas Schwinge
2024-03-01 14:09 ` Tobias Burnus [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bda4a56b-001a-4d52-b49d-9273ecb113dc@baylibre.com \
--to=tburnus@baylibre.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=tschwinge@baylibre.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).