From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id C35F63858C53 for ; Wed, 4 May 2022 15:52:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C35F63858C53 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-IronPort-AV: E=Sophos;i="5.91,198,1647331200"; d="scan'208";a="75118259" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 04 May 2022 07:52:32 -0800 IronPort-SDR: U/4sDIovTgUpfTxbCFaeRgT6LBOnIhWTFWVpePncf4oHzfIWVSIrkskY6Yrhy1zzvoJBiRzoiL VgHpMmfB5re2twfPW6WwJo2O6gBF1IqNRegORJ7NRGKnjsY/gxbosu0fGY1taIJFQXJZ+fN68b Fdxj3SqWE8VYtjA99qOw26hJlzGRInojkX+N5tKg0LbuQyGDhdGkz+6XS2mrGSWfKHOWS1bO9h zDswdAELAqEOy4/Z8LYgC6tjgMo6ojK5DgqWBeCwea7m6Sz+lpoN0gjpVWJ1f9RJAhgmgCXSt6 sAs= Message-ID: <9082d025-97bf-0456-3f5c-4e1177c69169@codesourcery.com> Date: Wed, 4 May 2022 17:52:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH] OpenMP, libgomp: Environment variable syntax extension. Content-Language: en-US To: Jakub Jelinek , Marcel Vollweiler CC: References: <392c847d-e798-2be3-a808-6888de6c90cd@codesourcery.com> From: Tobias Burnus In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-14.mgc.mentorg.com (139.181.222.14) To svr-ies-mbx-12.mgc.mentorg.com (139.181.222.12) X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2022 15:52:35 -0000 On 04.05.22 17:12, Jakub Jelinek via Gcc-patches wrote: > Though, there is one gotcha, if we had code where we parsed some var firs= t > and another one later and there was interdependence between the two, in > environ they can appear in any order. I think for interdependence it depends whether in a first step, only a flag or the string is stored or whether the data is fully evaluated. Especially for some 'global' entries, storing pointer to the string and evaluating it later makes sense. In some cases, evaluation the values (e.g. convert to integer) could be done early while checking the range could be done later. =E2=80=93 In any case, OMP_DISPLAY_ENV needs to be han= dled last =E2=80=93 but it can be parsed early (e.g. by setting a simple flag). Tobias PS: For completeness, I want to point out that in the current nonpublic draft (will show up as TR11 or OpenMP 6.0, I guess), some fixes related to one ICV (default-device-var =E2=86=92 global; issue #2740) and to the _D= EV rules (priority of variants, _all, fine-print, cleanup; PR #3175) was done. Those clarifications were found and discussed while the patch was written and, hence, are incorporated and should be nonsurprising. PPS: An example of an ICV which has to be evaluated before another is the to-be-added available-devices-icv that surely have to be evaluated before default-device-icv (=E2=86=92PR #3198; useful, fancy & overengeneere= d). But that one is surely not a GCC 13 topic. ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955