From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id 686D93858D28 for ; Thu, 4 May 2023 10:45:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 686D93858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-50bcb00a4c2so470412a12.1 for ; Thu, 04 May 2023 03:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683197105; x=1685789105; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nw/znjFnuL4Ui49fSn0ynYwIS1ytF87sfJVVdJ4QGAY=; b=VB5SAxa2zwsG5iFTizsgU4/TE9zCWZtXCLnyzli2ghi1h5okH9DngDD/9naOuTFHNW VmIr10KBP/a7D8IPKyIc3E7RM0cvX2fkaG4ZevnJBYXSuzfdgT8dWzM6eyHJmQYrL95T VN2uDkCV1WUpw+j39fH7/1BDPkDQknd/VuYGRejcqNk1pHRhb/cVDg3Ld9PfvSMIpWDp Z8Z6lhVeGepwB4hwaW33aSR9fA33JcqvU1IOkbjDce645vTaJ4CQX/bdOAVsoM5MHnJH JBIZF4rpAVFehP3hwEM4zQ/+Rus3o8ZzUOB/beWxCtYI5PnlWJqKgAedTRCRwJ8yNkrt 0tUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683197105; x=1685789105; h=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=nw/znjFnuL4Ui49fSn0ynYwIS1ytF87sfJVVdJ4QGAY=; b=F1H8FdzKKx/cYFdJ6mQPt1c/VY/OWyHg8DE1TXyk2dRULKnAeFR6n9OUcxwCejGCT0 XSnn286Ps2hyOWs7e6R4o1xNBK9uh2qq8NdpO8F1F0+ZXX09e+2YF5y0w7zwDeF2exl/ u5lH5IGcPJ54ttZxkKplvmb0qXNZW4+LsBnXEQ6h+obnyRG0XgXur52PPXztSzcEgrGq C8ecTZ/Bet1EEqoechx9zHv6hWxCztD+19MBGBlWcmwLu08d6kDkAfn6mtqUOG0MmuFn uo5PeO2V+gUyMMViXSS+/bNaf4gdejQZa11h7JhqLCjN0PjovlG31sQBd6dF20UUlDyT t3+w== X-Gm-Message-State: AC+VfDxujrvV6CAWD/GQDjbEhETNqZiq3zMMSeiK3OW6ZVjCDhWoBTqw jmXWbr96uNn1iGRpDKBrSaiQLKTkExV46RKmqD7vTPIjWNE= X-Google-Smtp-Source: ACHHUZ4TyRsOYCyf8/pxCye7D9SGeRqJX6JjMA73s7iS/ts32uajb0aFvW0l4MtywSTXx6nJuG5j0Pi/6x6yrLh4KHI= X-Received: by 2002:a17:907:1c8f:b0:94a:5a9e:9da0 with SMTP id nb15-20020a1709071c8f00b0094a5a9e9da0mr6612927ejc.77.1683197104729; Thu, 04 May 2023 03:45:04 -0700 (PDT) MIME-Version: 1.0 References: <7a44d8e8-19aa-79f7-f018-7d976b258ac7@gjlay.de> <33a61119-b6be-45fc-299d-beec7c59e5ad@gjlay.de> In-Reply-To: <33a61119-b6be-45fc-299d-beec7c59e5ad@gjlay.de> From: Jonathan Wakely Date: Thu, 4 May 2023 11:44:53 +0100 Message-ID: Subject: Re: g++ problem with order of evaluation of arguments of delete. To: Georg-Johann Lay Cc: gcc-help@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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 List-Id: On Thu, 4 May 2023 at 11:38, Georg-Johann Lay wrote: > > > > Am 04.05.23 um 12:12 schrieb Jonathan Wakely: > > On Thu, 4 May 2023 at 11:06, Jonathan Wakely wrote: > >> > >> On Thu, 4 May 2023 at 10:46, Georg-Johann Lay wrote: > >>> > >>> Given the following C++ code: > >>> > >>> struct Lexer; > >>> > >>> struct Token > >>> { > >>> Lexer* const lexer_; > >>> Token (Lexer *l) : lexer_(l) {} > >>> ~Token() = default; > >>> > >>> Token() = delete; > >>> Token (const Token&) = delete; > >>> Token (Token&&) = delete; > >>> void operator= (const Token&) = delete; > >>> void operator= (Token&&) = delete; > >>> }; > >>> > >>> struct Lexer > >>> { > >>> Token *token_; > >>> Lexer() = default; > >>> ~Lexer() { delete token_; } > >>> > >>> Lexer (const Lexer&) = delete; > >>> Lexer (Lexer&&) = delete; > >>> void operator= (const Lexer&) = delete; > >>> void operator= (Lexer&&) = delete; > >>> }; > >>> > >>> int main() > >>> { > >>> Lexer *lexer = new Lexer(); > >>> Token *token = new Token (lexer); > >>> lexer->token_ = token; > >>> delete token->lexer_; > >>> // delete lexer; // is OK > >>> } > >>> > >>> When I compile this with g++ v11.3 (same with g++ from master from > >>> 2023-04-20) and run > >>> > >>> $ g++ main-3.cpp -Os -W -Wall -Wextra -dumpbase "" -save-temps -dp && > >>> ./a.out > >>> > >>> Segmentation fault (core dumped) > >>> > >>> The assembly shows that the generated code does two calls to "delete" > >>> but just one call to "new", so it's clear something is going wrong. > >>> > >>> As far as I understand, the "delete token_" in ~Lexer is a sequence > >>> point, so that dereferencing token in "delete->lexer_" must be sequenced > >>> before calling ~Token ? > >>> > >>> Segmentation fault also occurs with -O0, but goes away when removing the > >>> "const" in "Lexer* const lexer_;". > >>> > >>> My question: Is this a GCC problem, or a problem with the code and > >>> sequence points? > >> > >> It's definitely a GCC bug. > >> > >> The code is compiled to something like: > >> > >> token->lexer_->~Lexer(); > >> operator delete(token->lexer_); > >> > >> But that means that we evaluate 'token' twice, even though it's been > >> invalidated by the destructor. It should be compiled to something more > >> like: > >> > >> auto* p = token->lexer_; > >> p->~Lexer(); > >> operator delete(p); > > > > The C++ standard is clear, see [expr.delete] p4: > > > > "The cast-expression in a delete-expression shall be evaluated exactly once." > > > > That wording has been present since C++98. > > > > Please file a bug. > > Thank you. I came across that clause, but why is "token->lexer_" in > delete's argument a cast? It isn't. "cast-expression" is just the name of a grammar production, it doesn't mean there's a cast present. delete-expression : ::opt delete cast-expression ::opt delete [ ] cast-expression cast-expression : unary-expression ( type-id ) cast-expression