From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <amonakov@ispras.ru>
Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84])
 by sourceware.org (Postfix) with ESMTPS id 459E43858412
 for <gcc-patches@gcc.gnu.org>; Mon, 11 Jul 2022 09:16:57 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 459E43858412
Received: from [10.10.3.121] (unknown [10.10.3.121])
 by mail.ispras.ru (Postfix) with ESMTPS id 9BE6F40737A7;
 Mon, 11 Jul 2022 09:16:50 +0000 (UTC)
Date: Mon, 11 Jul 2022 12:16:50 +0300 (MSK)
From: Alexander Monakov <amonakov@ispras.ru>
To: Rui Ueyama <rui314@gmail.com>
cc: =?ISO-8859-15?Q?Martin_Li=A8ka?= <mliska@suse.cz>, 
 Richard Biener <richard.guenther@gmail.com>, 
 GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 3/3] lto-plugin: implement LDPT_GET_API_VERSION
In-Reply-To: <CACKH++Zfy2k2+cZ5E8b68zxV5Uz3OzdsGE72AZXUbAVrT3WBpw@mail.gmail.com>
Message-ID: <862b4381-c377-ac7a-476c-e7ced3c29c2c@ispras.ru>
References: <803a0290-3909-b9c5-2461-b1740a00c63a@suse.cz>
 <bb9bf388-21d7-80d8-8474-6453fae50a49@suse.cz>
 <146a46f1-3a56-48c5-386f-c15633cc6781@ispras.ru>
 <37b52d36-d1dd-f291-0baa-0cf670493692@suse.cz>
 <CAFiYyc0AZSH5AuKo+fEj0doA+i77O+egK8ArugYbBM=nJBGcxQ@mail.gmail.com>
 <4e3df681-9523-4781-d324-9a6e230f495a@suse.cz>
 <CACKH++YcJ=fA-hC-R_=G9DV0C1ZJifPSh7wZ3rcFXZtMXqRgtw@mail.gmail.com>
 <3dc13790-a22d-c4d6-6cfe-ab9b567968ff@suse.cz>
 <CAFiYyc3C5tgM-rgZbRhF53eBKsERifiYuuab6FhC1AqSb-JvSA@mail.gmail.com>
 <b71724de-6511-8965-7132-c84d4e6b33a8@suse.cz>
 <CACKH++bkVcKSP5=0-1wBxJXO5OVW4GdMYg2ouYjDTZsUeccn9g@mail.gmail.com>
 <e5e84d3c-777c-0367-f575-62801526c506@suse.cz>
 <b0e6b1bd-1735-347-5a4b-3e7b40fa41bf@ispras.ru>
 <CACKH++Zfy2k2+cZ5E8b68zxV5Uz3OzdsGE72AZXUbAVrT3WBpw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 SPF_HELO_NONE, SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jul 2022 09:17:01 -0000

On Mon, 11 Jul 2022, Rui Ueyama wrote:

> > but ignoring min_api_supported is wrong, and assuming max_api_supported > 0
> > is also wrong. It really should check how given [min; max] range intersects
> > with its own range of supported versions.
> 
> Currently only one version is defined which is LAPI_V1. I don't think
> LAPI_UNSPECIFIED is a version number; rather, it's an unspecified
> value. No ordering should be defined between a defined value and an
> unspecified value. If LAPI_UNSPECIFIED < LAPI_V1, it should be renamed
> LAPI_V0.

You still cannot rely on API guarantees of LAPI_V1 when the plugin does not
advertise it (thread safety of claim_file in this particular case).

And you still should check the intersection of supported API ranges
and give a sane diagnostic when min_api_supported advertised by the plugin
exceeds LAPI_V1 (though, granted, the plugin could error out as well in this
case).

Alexander