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 0B8B438493E2 for ; Thu, 12 Jan 2023 12:00:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0B8B438493E2 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=1673524840; 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=Le1EGuh0URbtl7NKbj6IjCw3/bDOADus9WKID9GYvuXFWHWWoy5owvUJ3Zmsvbz9C1PQko Tr7FH6fJCghy7TAxFy673j93r/144bhJ6VqSavtnR4dkI2edWI17nEKUvgtlUh52uI8PZc 07tpmWLKVUKnaq5/tHoD+IY8ZkSHNgM= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-164-9x7ziiVAO6mdNrrrVskyrg-1; Thu, 12 Jan 2023 07:00:37 -0500 X-MC-Unique: 9x7ziiVAO6mdNrrrVskyrg-1 Received: by mail-lj1-f199.google.com with SMTP id bn17-20020a05651c179100b0027905fa8e48so4761155ljb.15 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=ILfMqv5vV4iAWookpV98rm2ggQLd0bLe5f7sZ1ph0oxH0HIizhQ/0slIVymfxW9Lje ZRErOKYTb+cTGt3HiXpH/IQVlUZ360fgfuybLoGL7vu3vDZdvbtQ0Ba7aTEho7pSlJcC z1K67+4nTpXvwfCbYiz7ekVGMhP+5TbuqhC7wHDXLNETGBSuQmYQu8gQRP6wS3e0C9Zp PndPa62AwKVJ+JBkhsGNJ/lCyRvWx2yH58xIIiW1x8zO9Bsprr8hykg6m4+ZLOPSrkWv RJ+0YC4IaGkVHu+bxwONsERCqRCcf9jnIXniBA5oUQ2mKqDnKr1hhxICU+NwzB3pxuXQ bsSQ== X-Gm-Message-State: AFqh2kokQ2VafMyxB4CW6hvunytRtYb/xg5ic0BXc/I3A9HYb7ya225v gmqim49BKQK/emEXwR2goaDzxWiqLlzPu9q5zfxQSjB540g6YzwvoeaB7OR9IzIt0O3d5LJIIbI O7LGEi1vPXPaA+Aamzu3p45s3+3oZ8Vs4Ew== X-Received: by 2002:a05:6512:614:b0:4b0:65b0:7f30 with SMTP id b20-20020a056512061400b004b065b07f30mr3574693lfe.385.1673524835675; 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.1 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=unavailable 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?