From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) by sourceware.org (Postfix) with ESMTPS id C96F33858CDA for ; Mon, 26 Sep 2022 14:46:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C96F33858CDA Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=acm.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qt1-x836.google.com with SMTP id s18so4211351qtx.6 for ; Mon, 26 Sep 2022 07:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date; bh=CoyK9nzXXadH9b/WPMOkh1z2jWhIkZqmsJKZV2sg2eE=; b=hv3Fk4HD71YfSCXfKn0+JaMOJtLrn5+YncQPCx/+49MohocNCkCmhwzDUIuNywRr1y elJi62x2UgW9bcOgzuKymy5omjwBS3JS4uC46ip+69Op9DbG5EpBMxv0m9O+DUl7qoG1 8s/vSySbvFCAl5BBwLIjq6QNuk6+VfXpjy5PcuolfvPwjS5yptNkbdqCcrhPnzLkJujs iNH3tL2kVspcSfgMUpd8TRUhnBdfYUwVn6DJf7pShCpv8IRVVP7RxifKCZwfwMBCvntz 6UrUTREhpOZMEX/kKnz0NzoRA93cJbG5lpSMLb4h9NSVIl7MxuSKkK9g4qFpzIQj6tgt ndBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date; bh=CoyK9nzXXadH9b/WPMOkh1z2jWhIkZqmsJKZV2sg2eE=; b=Q7Cb2HSXGsT8hZt7K8DjE2KBDEYvGWs2/17tPy/m86lXedgH/dsp7qZs6PARop2k8Y 9GbeG1j5qF3WjWeap5t+AuO1j0dCTB2gACzbWDs6+yU8MeYysoyeIwxtZklHObkEZSD+ c23+0K0O8Xdo8iccXuWxwX0GoG2tgnoe+S2odNqM0eKepLnEK7MVrAMzYUNqMDQdFgk/ TjClCOXQ7B0PNPg8ryMUOIM3m023g0z/xJPFkmjCqWXv4rIuD58H25QLKVLGbThL0Dfr zCQduf+CZP8zD86amJ6rgMQNwDIvjIv6zsI550mhHzdmEhlcBButR1wGc47kge8wWWPA 8Zog== X-Gm-Message-State: ACrzQf2FsiY0P7xQQdah+6OJOvqxzr9wFXdnVmjaVcgnUVKKXrPMZQdO WPMf5YZFvr/7m8BhUIevoxo= X-Google-Smtp-Source: AMsMyM5SoYfLyOxMjWqOwhho8Thzr7jA/GxuVrGIbHWbpKUYwCMzh6RlNeCBToHVS3Kq2ABrY2wMdg== X-Received: by 2002:a05:622a:192:b0:35c:f7df:5d50 with SMTP id s18-20020a05622a019200b0035cf7df5d50mr17837168qtw.603.1664203617089; Mon, 26 Sep 2022 07:46:57 -0700 (PDT) Received: from ?IPV6:2620:10d:c0a3:1407:bb5b:4f29:715d:d2b6? ([2620:10d:c091:500::6:a953]) by smtp.googlemail.com with ESMTPSA id fd6-20020a05622a4d0600b0035bb732ac93sm11665421qtb.88.2022.09.26.07.46.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Sep 2022 07:46:56 -0700 (PDT) Sender: Nathan Sidwell Message-ID: Date: Mon, 26 Sep 2022 10:46:55 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [PATCH] c++ modules: ICE with class NTTP argument [PR100616] Content-Language: en-US From: Nathan Sidwell To: Patrick Palka Cc: gcc-patches@gcc.gnu.org, jason@redhat.com References: <20220922182502.3218391-1-ppalka@redhat.com> <91a5a188-c4f2-39ff-fff4-8a667f515a19@acm.org> <0745ddf7-8e48-909b-d8e2-a9a1e4064cef@idea> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3032.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 9/26/22 10:08, Nathan Sidwell wrote: > On 9/23/22 09:32, Patrick Palka wrote: > >> Judging by the two commits that introduced/modified this part of >> maybe_register_incomplete_var, r196852 and r214333, ISTM the code >> is really only concerned with constexpr static data members (whose >> initializer may contain a pointer-to-member for a currently open class). >> So maybe we ought to restrict the branch like so, which effectively >> disables this part of maybe_register_incomplete_var during stream-in, and >> guarantees that outermost_open_class doesn't return NULL if the branch is >> taken? > > I think the problem is that we're streaming these VAR_DECLs as regular > VAR_DECLS, when we should be handling them as a new kind of object > fished out from the template they're instantiating. (I'm guessing > that'll just be a new tag, a type and an initializer?) > > Then on stream-in we can handle them in the same way as a non-modules > compilation handles such redeclarations.  I.e. how does: > > template struct C { }; > struct A { }; > C c1; // #1 > C c2; // #2 > > work.  Presumably at some point #2's A{} gets unified such that we find > the instantation that occurred at #1? > > I notice the template arg for C is a var decl mangled as > _ZTAXtl1AEE, which is a 'template paramete object for A{}'.  I see > that's a special mangler 'mangle_template_parm_object', called from > get_template_parm_object.  Perhaps these VAR_DECLs need an additional > in-tree flag that the streamer can check for? I wonder if we're setting the module attachment for these variables sanely? They should be attached to the global module. My guess is the pushdecl_top_level_and_finish call in get_templatE_parm_object is not doing what is needed (as well as the other issues). -- Nathan Sidwell