(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
