Hi!
As Cesar asked for it, there is now a Git branch
tschwinge/omp/pr72741-wip containing these changes (plus some other
pending changes that I didn't single out at this time), at
<https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/tschwinge/omp/pr72741-wip>.
(I expect it does, but I didn't verify that this actually builds; I have
further changes on top of that.) Cesar, please tell me if you'd like me
to push this to GitHub, in case you want to use their review/commentary
functions, or the like.
On Thu, 11 Aug 2016 17:40:26 +0200, Jakub Jelinek <ja...@redhat.com> wrote:
> On Thu, Aug 11, 2016 at 05:18:43PM +0200, Thomas Schwinge wrote:
> > --- gcc/fortran/gfortran.h
> > +++ gcc/fortran/gfortran.h
> > /* Symbol attribute structure. */
> > -typedef struct
> > +typedef struct symbol_attribute
> > {
> While symbol_attribute is already bloated, I don't like bloating it this
> much further. Do you really need it for all symbols, or just all subroutines?
Certainly not for all symbole; just for what is valid to be used with the
OpenACC routine directive, which per OpenACC 2.0a, 2.13.1 Routine
Directive is:
In Fortran the syntax of the routine directive is:
!$acc routine clause-list
!$acc routine( name ) clause-list
In Fortran, the routine directive without a name may appear within the
specification part of a subroutine or function definition, or within an
interface body for a subroutine or function in an interface block, and applies
to the containing subroutine or function. The routine directive with a name may
appear in the specification part of a subroutine, function or module, and
applies to the named subroutine or function.
(Pasting that in full just in case that contains some additional Fortran
lingo, meaning more than "subroutines".)
> In the latter case, it is much better to add some openacc specific pointer
> into the namespace structure and stick everything you need into some custom
> structure it will refer to. E.g. look at gfc_omp_declare_simd struct
> in ns->omp_declare_simd.
Thanks for the suggestion, I'll look into that.
> omp_clauses_locus makes no sense, symbol_attribute contains parsed info from
> many different clauses, which one it is?
Well, it makes some sense -- it works no worse than the existing code ;-)
-- but I agree that it's not exactly pretty. To the best of my
knowledge, in Fortran OpenACC/OpenMP clauses parsing, we're currently not
tracking (saving) specific location information for individual clauses
(at least, that's what a casual scan through the code, and
gfc_match_oacc_routine or gfc_match_omp_declare_target in particular make
me think: gfc_omp_clauses collects all clause data, but only contains a
single "locus loc" member (which maybe I should have used instead of
"old_loc", the location information for the directive itself?). Maybe I
misunderstood, and we do have more precise location information available
for individual clauses? In that case, I'll happily use that, of course.
Grüße
Thomas
