I would swear that I selected "reply all" but... Never mind, you put it right!
Cheers Paul On Thu, 12 Mar 2020 at 08:44, Tobias Burnus <tob...@codesourcery.com> wrote: > > (I assume that should have gone to gcc-patches@ and fortran@ as well.) > > > -------- Forwarded Message -------- > Subject: Re: [Fortran, OpenACC] Reject vars of different scope in $acc > declare (PR94120) > Date: Tue, 10 Mar 2020 18:02:41 +0000 > From: Paul Richard Thomas <paul.richard.tho...@gmail.com> > To: Tobias Burnus <tob...@codesourcery.com> > > > > Hi Tobias, > > This looks to be straightforward enough to me :-) OK for trunk. > > Thanks > > Paul > > On Tue, 10 Mar 2020 at 17:18, Tobias Burnus <tob...@codesourcery.com> wrote: > > [This fixes a bunch of issues found when actually only > > wanting to add a check for the following restriction.] > > > > OpenACC's "Declare Directive" has the following restriction: > > > > "A declare directive must be in the same scope > > as the declaration of any var that appears in > > the data clauses of the directive." > > > > The gfortran now rejects a "var" declared is in a different > > namespace than the "$acc declare". (Use-associated variables > > are already rejected.) Testing showed that a straight-forward > > check fails if the result variable is the function name – as > > then the function symbol is in the parent scope. — Extending > > the failing test to use a result variable showed that the > > current is-a-module-variable check didn't work and when fixing, > > one was running into a likewise issue. > > > > The reason that I exclude 's' being a module is that at > > resolution time, an is-variable check is done. > > > > > > The other changes are because the following restriction was > > mishandled: > > > > "In a Fortran module declaration section, only > > create, copyin, device_resident, and link clauses are allowed." > > > > But all examples where for variables using those in a module > > procedure … > > > > > > OK for the trunk? > > > > Cheers, > > > > Tobias > > > > PS: For those who wounder what happens in a BLOCK DATA construct: > > gfortran outrightly rejects 'acc declare'. (It probably should > > work for COMMON blocks with 'declare device_resident' – but > > currently the spec only permits it in program/subroutine/function > > + declaration part of a module.) > > > > PPS: The PR shows (for C) that one can construct a test case, > > which violates the OpenACC restriction and actually fails with > > an ICE. I have a draft patch for C (see PR) but not yet one for > > C++, hence, I start with the Fortran side. – I currently still > > struggle to write a same-scope check in C++. > > [The C test case in turn was a fallout of debugging an > > ICE-on-valid-code issue …] > > > > ----------------- > > Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / > > Germany > > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, > > Alexander Walter > > > > -- > "If you can't explain it simply, you don't understand it well enough" > - Albert Einstein > > ----------------- > Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, > Alexander Walter -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
