From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by sourceware.org (Postfix) with ESMTPS id A270F385802D; Mon, 1 Mar 2021 22:21:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A270F385802D IronPort-SDR: 1w6kAZXUxQgroHIRWi7Mrh1oVBijd+7YDllno8mIMoTKoyDdRStpLHnPr/EUM+IR+VhBCZFett xapBpSeH/8Zg== X-IronPort-AV: E=McAfee;i="6000,8403,9910"; a="185940651" X-IronPort-AV: E=Sophos;i="5.81,216,1610438400"; d="scan'208";a="185940651" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Mar 2021 14:21:45 -0800 IronPort-SDR: 7JlCu+ukd2qN0ftRgg7SCsLUVzY0eEk+kxUv8JpjgXGoyPTLB/+ol1lKoC9jRR1mtLF4/3fm9f 4s7lan/oPanQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,216,1610438400"; d="scan'208";a="427082197" Received: from irsmsx605.ger.corp.intel.com ([163.33.146.138]) by fmsmga004.fm.intel.com with ESMTP; 01 Mar 2021 14:21:44 -0800 Received: from tjmaciei-mobl1.localnet (10.255.230.217) by IRSMSX605.ger.corp.intel.com (163.33.146.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 1 Mar 2021 22:21:43 +0000 From: Thiago Macieira To: Ville Voutilainen CC: libstdc++ , gcc-patches List Subject: Re: [PATCH 4/5] barrier: use int instead of unsigned char for the phase state Date: Mon, 1 Mar 2021 14:21:39 -0800 Message-ID: <8457077.xqWQSDyarL@tjmaciei-mobl1> Organization: Intel Corporation In-Reply-To: References: <1968544.UC5HiB4uFJ@tjmaciei-mobl1> <3732429.s6FRLjrGHh@tjmaciei-mobl1> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [10.255.230.217] X-ClientProxiedBy: orsmsx603.amr.corp.intel.com (10.22.229.16) To IRSMSX605.ger.corp.intel.com (163.33.146.138) X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2021 22:21:50 -0000 On Monday, 1 March 2021 14:04:34 PST Ville Voutilainen wrote: > Well, this would be different. What I'm suggesting is not quite that; > for any *new* facility, we'd make sure > that its draft macro and the final IS macro are different, but the > minimum value is the first draft version, > not anything below it. I don't care too much, that approach and yours > would work the same way. Things that already > had an IS value for a macro and haven't changed since don't need to be > changed. And we don't > need to bump all values of existing facilities either, just for those > that got changes, so some existing macros > would be considered lost causes. Like the ones we're talking about, > because the cats are already out of the > bag. But the code I posted, if people are careful to use write like I did, would allow us to have the experimental "we're not sure this is right" implementation of atomic waits, latches, barriers and semaphores right now. It would simply require that we decrement the macros by 1 in the libstdc++ headers. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering