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.129.124]) by sourceware.org (Postfix) with ESMTPS id C7C9E3858C74 for ; Fri, 1 Mar 2024 16:46:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C7C9E3858C74 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C7C9E3858C74 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709311588; cv=none; b=rp+NY1UGrRmepUjygKCDUxRiFbXdym0+ZHC6KPu2NfhdAjdTNeyb3OcWdoz2n0STKvFeFwd2XEsYDE/ljzh2QuhDJWPL70u0VWatea7lpQUsis5Zk2+2JAIl52sLLr75F51kyUWGI4utl2w13SxKju2DlJNftGY8nhmqlbl8xf0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709311588; c=relaxed/simple; bh=y7TBQ+QhQEjFskDHVfbzGmYrjw9mB2Cm7OJyC1NFLeE=; h=DKIM-Signature:From:Date:To:Subject:Message-ID:MIME-Version; b=mwaCIfEW4Tx+BcfjaoTY66VmZztRny8weQxdqN0vONpLvt3nb/7HAhVch3wvoz/gUmq2H9+zCpkKjlXHMauacvVS2nA+lwSU6q6hntzxTHM0ZUN3DIRIDi0gFxtxuW8vQQX/wfooVMggqtRMp1XKjhA2WlvJlXcFOjNSIOc3UIk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709311585; 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: in-reply-to:in-reply-to:references:references; bh=lT2Ph2tcemsmh+IW6X/d36DHUyMPssrVa9ZHUAT2ebY=; b=I51ZPorYqjmTEBSE7z51f28lNFe2hCT2fxVghUoGTWXwRQV29tuv2zDlhrEXub79QN9oDl 8pIHlka6GV60BOHIr3gErbrhiMMeH9lgtrS6CIQ5UzRtM/wCj1kw0qi5sWYIZgwzht77P7 4q/BK8/OHRzBsf/Aeafh0zK40atRVDE= Received: from mail-oi1-f200.google.com (mail-oi1-f200.google.com [209.85.167.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-477-TkV6dclZMdCQkmm4y08xeA-1; Fri, 01 Mar 2024 11:46:23 -0500 X-MC-Unique: TkV6dclZMdCQkmm4y08xeA-1 Received: by mail-oi1-f200.google.com with SMTP id 5614622812f47-3c1a8342d69so2827947b6e.3 for ; Fri, 01 Mar 2024 08:46:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709311563; x=1709916363; h=mime-version:references:message-id:in-reply-to:subject:cc:to:date :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=W9nD8fKwTSUWARYnEfmBeAF4GVg8kX2nSsSkyaX5E1M=; b=C2kAqBnlhtKUSMuaU1dEd2ixfR6bX5+PUAl3G6laAPHqX1ghxMu3tXQEeWOZEAiwAO N7GwxDBBpjzZzy5ZaHvL9zYIApgTiMUI9OMyad8aukqyt40rTIEDCWTf6ZdmZM8YKkBv yVG/UNAt8Cix9YXHRiPSq1S6F/iMc11+MnyW2ecqaz3/LE/tuky9oBnL4T2I7ybAh29X coU23AJvpNNz4WSf1t4mTc5Rnci+UIl2Lik6HhkcvhyGwoo8fx2rETG7KMFmisgEjHLR SYVpAC05/JDJhZ4Z3NNSwEVXkz5otvIe/onlB6H56bSyE4vFpihZplJO46O9anneNBun 6DhQ== X-Forwarded-Encrypted: i=1; AJvYcCXR/JD68xcoOj4TgGJLQEpdXICOhpdCgQaixflltRouNlH7HD/RxTOHkFhgFNeit901ET7s3tzq3f/cr7+Gm1GxMHFRbydVhg== X-Gm-Message-State: AOJu0YyXkf+fIhvKHm1pz4e/3Apq8FFV9x9ldzqG3e2idMohXQDfTD2u hI//uHBplxrqTwePheOkbdt9kAVIEo9EWGtIHLxkon1lIYxEW81D4UtWvBILob8Yer0oVU1EOdS 92mH7ubjn96ocIkW2V5wPsA1ZGZFZaXLCuk+oO4FmD03n8a++KpfAbkk= X-Received: by 2002:aca:280c:0:b0:3c1:d0b1:b917 with SMTP id 12-20020aca280c000000b003c1d0b1b917mr2024579oix.49.1709311562784; Fri, 01 Mar 2024 08:46:02 -0800 (PST) X-Google-Smtp-Source: AGHT+IE7Km8S+P4JaCkLget5K9Qr7/uzTX5IxdOZaaDXMdpF5fpOpbJw+SmBbX2slcgTIKpsKaxGww== X-Received: by 2002:aca:280c:0:b0:3c1:d0b1:b917 with SMTP id 12-20020aca280c000000b003c1d0b1b917mr2024567oix.49.1709311562476; Fri, 01 Mar 2024 08:46:02 -0800 (PST) Received: from [192.168.1.130] (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id t5-20020ac87605000000b0042e93e97957sm1844108qtq.34.2024.03.01.08.46.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 08:46:00 -0800 (PST) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Fri, 1 Mar 2024 11:45:59 -0500 (EST) To: Jason Merrill cc: Patrick Palka , gcc-patches@gcc.gnu.org, nathan@acm.org Subject: Re: [PATCH] c++/modules: depending local enums [PR104919, PR106009] In-Reply-To: <72695b26-0963-4530-9ee1-236b64829321@redhat.com> Message-ID: <1d95c19d-b2e3-4241-f153-1b6770e634f6@idea> References: <20240229205639.4112668-1-ppalka@redhat.com> <67615f3d-4d61-4f2c-8405-66fa1c2cdd93@redhat.com> <32846614-cd68-4912-8630-7b19098511d1@redhat.com> <72695b26-0963-4530-9ee1-236b64829321@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="8323329-915557801-1709311560=:3760645" X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,BODY_8BITS,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,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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-915557801-1709311560=:3760645 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Fri, 1 Mar 2024, Jason Merrill wrote: > On 3/1/24 10:32, Jason Merrill wrote: > > On 3/1/24 10:00, Patrick Palka wrote: > > > On Fri, 1 Mar 2024, Jason Merrill wrote: > > > > > > > On 2/29/24 15:56, Patrick Palka wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > > > > OK for trunk? > > > > > > > > > > -- >8 -- > > > > > > > > > > For local enums defined in a non-template function or a function > > > > > template > > > > > instantiation it seems we neglect to make the function depend on the > > > > > enum > > > > > definition, which ultimately causes streaming to fail due to the enum > > > > > definition not being streamed before uses of its enumerators are > > > > > streamed, > > > > > as far as I can tell. > > > > > > > > I would think that the function doesn't need to depend on the local enum > > > > in > > > > order for the local enum to be streamed before the use of the > > > > enumerator, > > > > which comes after the definition of the enum in the function body? > > > > > > > > Why isn't streaming the body of the function outputting the enum > > > > definition > > > > before the use of the enumerator? > > > > > > IIUC (based on observing the behavior for local classes) streaming the > > > definition of a local class/enum as part of the function definition is > > > what we want to avoid; we want to treat a local type definition as a > > > logically separate definition and stream it separately (similar > > > to class defns vs member defns I guess).  And by not registering a > > > dependency > > > between the function and the local enum, we end up never streaming out > > > the local enum definition separately and instead stream it out as part > > > of the function definition (accidentally) which we then can't stream in > > > properly. > > > > > > Perhaps the motivation for treating local type definitions as logically > > > separate from the function definition is because they can leak out of a > > > function with a deduced return type: > > > > > >    auto f() { > > >      struct A { }; > > >      return A(); > > >    } > > > > > >    using type = decltype(f()); // refers directly to f()::A > > > > Yes, I believe that's what modules.cc refers to as a "voldemort". > > > > But for non-voldemort local types, the declaration of the function doesn't > > depend on them, only the definition.  Why doesn't streaming them in the > > definition work properly? > > And does your 99426 patch address that problem? I don't think so, that patch should only affect declaration merging (of a streamed-in local type with the corresponding in-TU local type after their containing function is merged). > > This was nearly enough to make things work, except we now ran into > > issues with the local TYPE/CONST_DECL copies when streaming the > > constexpr version of a function body. It occurred to me that we don't > > need to make copies of local types when copying a constexpr function > > body; only VAR_DECLs etc need to be copied for sake of recursive > > constexpr calls. So this patch adjusts copy_fn accordingly. > > Maybe adjust can_be_nonlocal instead? It seems unnecessary in general > to remap types and enumerators for inlining. Unfortunately this approached caused a boostrap failure with Ada: raised STORAGE_ERROR : stack overflow or erroneous memory access The patch was --- a/gcc/tree-inline.cc +++ b/gcc/tree-inline.cc @@ -725,6 +725,9 @@ can_be_nonlocal (tree decl, copy_body_data *id) if (TREE_CODE (decl) == FUNCTION_DECL) return true; + if (TREE_CODE (decl) == TYPE_DECL || TREE_CODE (decl) == CONST_DECL) + return true; + /* Local static vars must be non-local or we get multiple declaration problems. */ if (VAR_P (decl) && !auto_var_in_fn_p (decl, id->src_fn)) > > Jason > > --8323329-915557801-1709311560=:3760645--