This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [PR72741] Encode OpenACC 'routine' directive's level of parallelism inside Fortran module files
- From: Thomas Schwinge <thomas at codesourcery dot com>
- To: Thomas Koenig <tkoenig at netcologne dot de>
- Cc: Tobias Burnus <burnus at net-b dot de>, <gcc-patches at gcc dot gnu dot org>, <fortran at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Thu, 14 Mar 2019 08:38:30 +0100
- Subject: Re: [PR72741] Encode OpenACC 'routine' directive's level of parallelism inside Fortran module files
- References: <5762190F.4030102@codesourcery.com> <87y35zmxcv.fsf@euler.schwinge.homeip.net> <20190228211701.GG7611@tucnak> <yxfph8c6hde9.fsf@hertz.schwinge.homeip.net> <09896653-ad4d-13c6-4341-3ffe1bdc0b8c@netcologne.de>
Hi Thomas!
On Wed, 13 Mar 2019 23:13:46 +0100, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Am 13.03.19 um 18:50 schrieb Thomas Schwinge:
> >> There are many ways to deal with it without bumping MOD_VERSION in a
> >> backwards but not forwards compatible way, so that a newer compiler will be
> >> able to parse old *.mod files, and newer compiler new ones as long as this
> >> problematic stuff doesn't appear in.
> > Like the attached, actually pretty simple now?
>
> Can you explain a) how this works
I'll be happy to elaborate, but I'm not sure at which level you'd like me
to explain?
This is basically the very same thing that's being done for other 'struct
symbol_attribute' flag fields, by interpreting the 'enum
oacc_routine_lop' values as individual flags, and with the corollary (to
maintain MOD_VERSION compatibility as best as we can) that we don't
stream out its default value (so doing correspondingly to when a "real"
flag's value is 'false').
> and b) how you tested it?
I had mentioned that in the commit message: with the relevant old/new GCC
combinations, using the included test case.
Happy to explain further, if necessary.
Grüße
Thomas