From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=tKts=FC=mentor.com=Julian_Brown@sourceware.org>
Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153])
	by sourceware.org (Postfix) with ESMTPS id F20193858D32;
	Mon, 18 Sep 2023 10:19:50 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F20193858D32
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com
X-CSE-ConnectionGUID: 00kLJebNQfKZJUprB+n9HQ==
X-CSE-MsgGUID: kGQUXAHSRNivku+Bkw5lyQ==
X-IronPort-AV: E=Sophos;i="6.02,156,1688457600"; 
   d="scan'208";a="19404497"
Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167])
  by esa1.mentor.iphmx.com with ESMTP; 18 Sep 2023 02:19:49 -0800
IronPort-SDR: JCcegNOxZF663bwYJPw5ZfibemyyAw4/xfi4koeQP7/X0a81Ar2F9B6tzioBkU0awBUtVORb14
 G0dQ3AtTPLeWkqy4Q4KtImLGjE13kElbVEp/0D5OtCaSOCc77cS/EaGfw2h2+yYMVVm32HAegy
 32+9L9EeQeyvUFP0jDVbf+AsN4aO4fc5joQVnbPxfPTOXD91exfkj2WvEVLMvyM7an2cQyaqYz
 o3KeVbR26cP5N07vY4sQ5AL68B7Hplom2n6MU13PBAHCXcf14xbnzbyhFRgWT7l22Hp3wcHntO
 fRg=
Date: Mon, 18 Sep 2023 11:19:17 +0100
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
Message-ID: <20230918111917.6141b000@squid.athome>
In-Reply-To: <20230914171302.4bef7adc@nbbrfq.loc>
References: <cover.1693941292.git.julian@codesourcery.com>
	<2aaa9204cded930d85531c3e2a32a6c07cf6d545.1693941293.git.julian@codesourcery.com>
	<20230914171302.4bef7adc@nbbrfq.loc>
Organization: Siemens Embedded
X-Mailer: Claws Mail 4.1.1git78 (GTK 3.24.38; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [137.202.0.90]
X-ClientProxiedBy: svr-ies-mbx-12.mgc.mentorg.com (139.181.222.12) To
 svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11)
X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <fortran.gcc.gnu.org>

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