Hi! Are there any further questions, or am I good to commit my patch as posted?
On Thu, 14 Mar 2019 08:38:30 +0100, I wrote: > On Wed, 13 Mar 2019 23:13:46 +0100, Thomas Koenig <tkoe...@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
