From: Julian Brown <julian@codesourcery.com>
To: Bernhard Reutner-Fischer via Gcc-patches <gcc-patches@gcc.gnu.org>
Cc: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>,
<fortran@gcc.gnu.org>, <jakub@redhat.com>,
<tobias@codesourcery.com>
Subject: Re: [PATCH 8/8] OpenMP: Fortran "!$omp declare mapper" support
Date: Mon, 18 Sep 2023 11:19:17 +0100 [thread overview]
Message-ID: <20230918111917.6141b000@squid.athome> (raw)
In-Reply-To: <20230914171302.4bef7adc@nbbrfq.loc>
On Thu, 14 Sep 2023 17:13:02 +0200
Bernhard Reutner-Fischer via Gcc-patches <gcc-patches@gcc.gnu.org>
wrote:
> On Tue, 5 Sep 2023 12:28:28 -0700
> Julian Brown <julian@codesourcery.com> wrote:
>
> > + static bool
> > + equal (const omp_name_type<gfc_typespec *> &a,
> > + const omp_name_type<gfc_typespec *> &b)
> > + {
> > + if (a.name == NULL_TREE && b.name == NULL_TREE)
> > + return a.type == b.type;
>
> I'm curious if (and why) the type comparison above is safe and does
> not use gfc_compare_types () ?
>
> thanks,
Probably ignorance on my part! It works for (derived, class) types which
are canonicalized to exactly the same gfc_typespec, but you're likely
right that a more Fortran-ish notion of type equality should be used
here instead when comparing "declare mapper"s.
Or maybe using gfc_compare_types would smush too many types together
into one? E.g. if b.type is an extension of a.type, do we want those
types to be able to have separate mappers?
I'll have a look at addressing this when it's time to reroll these
patches.
Thanks,
Julian
next prev parent reply other threads:[~2023-09-18 10:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-05 19:28 [PATCH 0/8] OpenMP: lvalue parsing and "declare " Julian Brown
2023-09-05 19:28 ` [PATCH 1/8] OpenMP: lvalue parsing for map/to/from clauses (C++) Julian Brown
2023-12-20 14:31 ` Tobias Burnus
2024-01-05 12:23 ` Julian Brown
2024-01-07 15:04 ` Tobias Burnus
2024-01-09 23:02 ` Thomas Schwinge
2024-01-10 9:14 ` Jakub Jelinek
2024-01-10 13:17 ` Julian Brown
2023-09-05 19:28 ` [PATCH 2/8] OpenMP: lvalue parsing for map/to/from clauses (C) Julian Brown
2024-01-10 21:31 ` Tobias Burnus
2023-09-05 19:28 ` [PATCH 3/8] OpenMP: C++ "declare mapper" support Julian Brown
2023-09-05 19:28 ` [PATCH 4/8] OpenMP: Support OpenMP 5.0 "declare mapper" directives for C Julian Brown
2023-09-05 19:28 ` [PATCH 5/8] OpenMP, Fortran: Pass list number to gfc_free_omp_namelist Julian Brown
2023-09-05 19:28 ` [PATCH 6/8] OpenMP, Fortran: Per-directive control for gfc_trans_omp_clauses Julian Brown
2023-09-05 19:28 ` [PATCH 7/8] OpenMP, Fortran: Split out OMP clause checking Julian Brown
2023-09-05 19:28 ` [PATCH 8/8] OpenMP: Fortran "!$omp declare mapper" support Julian Brown
2023-09-14 15:13 ` Bernhard Reutner-Fischer
2023-09-18 10:19 ` Julian Brown [this message]
2023-09-21 22:52 ` Bernhard Reutner-Fischer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230918111917.6141b000@squid.athome \
--to=julian@codesourcery.com \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=rep.dot.nop@gmail.com \
--cc=tobias@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).