From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id C83E53836011 for ; Thu, 12 Jan 2023 12:00:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C83E53836011 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673524838; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OLfSsimL1BmBmxUc/jhtoX77Ip2RZPrNM2O/pfZ5Z28=; b=GKTOZ/uwHYkxaafKhgB5i+AE0q1ZFzsYC07LNJwjx5R2s9Z7SZUO5L0bI6/3nJ+s9pkGDo TU74RzCm+3q/PfXQhwRBVX+6qTX/Bikt0obeosYCTpPysBmW3SMDNoeZODmuj4ai/nibco 4bh0aCikqCZDfZYmrmGhYZVYSYICwDw= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-128--aGTNNz-OgO95JmHVmKoeg-1; Thu, 12 Jan 2023 07:00:37 -0500 X-MC-Unique: -aGTNNz-OgO95JmHVmKoeg-1 Received: by mail-lj1-f200.google.com with SMTP id a11-20020a05651c210b00b0027fc4f018a1so4718538ljq.8 for ; Thu, 12 Jan 2023 04:00:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OLfSsimL1BmBmxUc/jhtoX77Ip2RZPrNM2O/pfZ5Z28=; b=hkdlgaD8RJMXraJ4nqtls9+VZYVeQME4NlLCfh7XrexSL2qA4w2Iu05p//EO7R3drV Xf6GksmpkAFr32LUCdWUXDx0LQc6il5cj/RKMKZfBpb+ltGR/HXUmd6cz5xv0WXp0qoj 8V+vR6iB8pXQHrYIekWroszXzS8HzxRgMkdmlcjc3wmBQnOFhfcJHi43ZEcV9En75cs5 Qs86SFR8jWQKoDeUIMfo7t4sEClCotE0u7W2jHja58QSSYqEf4wxpNCJ35vvzLc4meXP /wLNy+JKJKAisTfsziQotR0MdcEvNX34P8E4ZomuwAvccqwOT8xEVIucmHR1UMxGYDQl +lNw== X-Gm-Message-State: AFqh2kpQTGcSSkUbXiHqjW9slQMpMHwiQQ633MTllAuH83XD/6YYoigF ZbNBE7TM/x4YcSrgwvERtDu//UKUhClOvWCRpIug6FWLVioO9zaryn/E+mCZM0KBrAlBJmGkipd K3vLNpX15cfFUFs4T9Zb2OG4ItbEVE6o= X-Received: by 2002:a05:6512:614:b0:4b0:65b0:7f30 with SMTP id b20-20020a056512061400b004b065b07f30mr3574692lfe.385.1673524835514; Thu, 12 Jan 2023 04:00:35 -0800 (PST) X-Google-Smtp-Source: AMrXdXvA3AuBlWWeWf2GSKfkNIjgYAK0XZwrTJrO/IB61o1gu9nyODjQTqTngi+/1mQfzI5Xrk7BD+ObBjxjP1SgEJU= X-Received: by 2002:a05:6512:614:b0:4b0:65b0:7f30 with SMTP id b20-20020a056512061400b004b065b07f30mr3574690lfe.385.1673524835258; Thu, 12 Jan 2023 04:00:35 -0800 (PST) MIME-Version: 1.0 References: <20230106115402.178926-1-jwakely@redhat.com> In-Reply-To: From: Jonathan Wakely Date: Thu, 12 Jan 2023 12:00:23 +0000 Message-ID: Subject: Re: libstdc++: Fix deadlock in debug iterator increment [PR108288] To: =?UTF-8?Q?Fran=C3=A7ois_Dumont?= Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 12 Jan 2023 at 05:52, Fran=C3=A7ois Dumont wrote: > > Small update for an obvious compilation issue and to review new test > case that could have lead to an infinite loop if the increment issue was > not detected. > > I also forgot to ask if there is more chance for the instantiation to be > elided when it is implemented like in the _Safe_local_iterator: > return { __cur, this->_M_sequence }; No, that doesn't make any difference. > > than in the _Safe_iterator: > return _Safe_iterator(__cur, this->_M_sequence); > > In the case where the user code do not use it ? > > Fully tested now, ok to commit ? > > Fran=C3=A7ois > > On 11/01/23 07:03, Fran=C3=A7ois Dumont wrote: > > Thanks for fixing this. > > > > Here is the extension of the fix to all post-increment/decrement > > operators we have on _GLIBCXX_DEBUG iterator. Thanks, I completely forgot we have other partial specializations, I just fixed the one that showed a deadlock in the user's example! > > I prefer to restore somehow previous implementation to continue to > > have _GLIBCXX_DEBUG post operators implemented in terms of normal post > > operators. Why? Implementing post-increment as: auto tmp =3D *this; ++*this; return tmp; is the idiomatic way to write it, and it works fine in this case. I don't think it performs any more work than your version, does it? Why not use the idiomatic form? Is it just so that post-inc of a debug iterator uses post-inc of the underlying iterator? Why does that matter?