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 7F4D83858C41 for ; Fri, 15 Mar 2024 17:48:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7F4D83858C41 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 7F4D83858C41 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710524935; cv=none; b=HpQyMN6NOo/HjxmngFCNwk7LbWTkTXAUJPLA/x8/ENrmm/qDE+gp2Nbj4NQ9EUZ5gMQLSi3Fwld0ffCWqoy0usTX8lx8tAPnteKHwOBhhk54hBEWxnpseRfRjuXV3IUg1tdIdiwTgh4OD7KRtLSENsDLFoBswJevWDveg38ByQY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710524935; c=relaxed/simple; bh=qH3m5Bh2JRPaDiiecembaFLP3fxRbO+x+2GfnpMOMhs=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=BvaHtkwBAmsHL3GHldqaL8rnNaDwrsPwE6SzB74fD/oRJOxd+rDpUjQ/JgRBi64ZlaGyo4tllnjNAZ/3A1qVWGqrsJM39JdQ4W9/Jo5/fdJQtRN1nUO1L+zKSvVH1a9S/QBynoadrWZuWZryY5oKjvTKOR7SJ0QMF5bc91wORco= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1710524933; 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=bQrgxPLGO9z75WSsGNaKivISTiNI7Biw53+hb998PaY=; b=a11Bqe4KK+PaCWuPMHf0Vew8ZZNCJw6zxq4fhKE/pJWqzes/kAM16gXBQkquTQF59WnmNX rEFwvB5PgDbeQ0lo2lXoijKhlGs0E54vBK4WzVCtSd/x7xEwFy4I7yoiRWCLJjNjktahVJ vdBL7ev84ELPiJYJk+DpoHs96iVDbW0= Received: from mail-ua1-f72.google.com (mail-ua1-f72.google.com [209.85.222.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-52-x-ZqhfKZPgmXS3pqWRLTAA-1; Fri, 15 Mar 2024 13:48:52 -0400 X-MC-Unique: x-ZqhfKZPgmXS3pqWRLTAA-1 Received: by mail-ua1-f72.google.com with SMTP id a1e0cc1a2514c-7db948b2b14so1282381241.2 for ; Fri, 15 Mar 2024 10:48:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710524931; x=1711129731; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bQrgxPLGO9z75WSsGNaKivISTiNI7Biw53+hb998PaY=; b=JLoCz41tPaI/OoYokHjUJU3Lcp6dFZ0ajx+rLj+n/dghQMJ/f8m87bcKAvkiTwZp1n tX/D70Ph+jNndx6EXOcvh8jFDDe2aqtx+yzfTnr+uvF9VohDH2e2HfSFxFNrwiYBm263 jbkOp8WLmIyz77X6Dv8UGJlXf48VLapBrxDbYfpjZ5vMFMbN+Gpw2cHrhlYQbVVhAR6U q7/JqrXQ2DMBpeXAafoi9rudc1BcoQZ2hXBNPRKiXbQ+rmReMYG60ohSrqi/+DeeDLDa ExYfncoD1ewRh0Jyb3Jxoc/gadwpq9Nt0V2kMTwdnaIzyesVcfH/sPowvq6eglEMdRZB yiuw== X-Gm-Message-State: AOJu0YyT6Rt1h8CvCc15pdbLTg5fN/uablmDb03T7GiczY8rOhnf6I0C toTkHOmkdc94VwaaIy6WEwJmxqny8LbncR38RoLGWxinCu/uXoVLCR2hgwvNZjVLmBX6yN68IT0 xGSx2pk4wOQrE2ZsBnASPpvNn64j15ItTKbM3BB+M6nqfdFAJzs25j6Q= X-Received: by 2002:a67:fa41:0:b0:473:214c:b270 with SMTP id j1-20020a67fa41000000b00473214cb270mr5720879vsq.22.1710524931431; Fri, 15 Mar 2024 10:48:51 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFn3/OUV826di1xyMshpQxosjlVhy2Vzjy1FbyfhzjlXHV4iJH6KKZ81o+f1HWLDFqNHPfyuA== X-Received: by 2002:a67:fa41:0:b0:473:214c:b270 with SMTP id j1-20020a67fa41000000b00473214cb270mr5720860vsq.22.1710524931073; Fri, 15 Mar 2024 10:48:51 -0700 (PDT) Received: from redhat.com (2603-7000-9500-34a5-0000-0000-0000-1db4.res6.spectrum.com. [2603:7000:9500:34a5::1db4]) by smtp.gmail.com with ESMTPSA id 12-20020a05621420cc00b00690cedd5be9sm2235489qve.125.2024.03.15.10.48.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Mar 2024 10:48:50 -0700 (PDT) Date: Fri, 15 Mar 2024 13:48:48 -0400 From: Marek Polacek To: Jason Merrill Cc: GCC Patches Subject: Re: [PATCH] c++: explicit inst of template method not generated [PR110323] Message-ID: References: <20240308170215.21919-1-polacek@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.2.12 (2023-09-09) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,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: On Thu, Mar 14, 2024 at 03:39:04PM -0400, Jason Merrill wrote: > On 3/8/24 12:02, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > Consider > > > > constexpr int VAL = 1; > > struct foo { > > template > > void bar(typename std::conditional::type arg) { } > > }; > > template void foo::bar<1>(int arg); > > > > where we since r11-291 fail to emit the code for the explicit > > instantiation. That's because cp_walk_subtrees/TYPENAME_TYPE now > > walks TYPE_CONTEXT ('conditional' here) as well, and in a template > > finds the B==VAL template argument. VAL is constexpr, which implies const, > > which in the global scope implies static. constrain_visibility_for_template > > then makes "struct conditional<(B == VAL), int, float>" non-TREE_PUBLIC. > > Then symtab_node::needed_p checks TREE_PUBLIC, sees it's 0, and we don't > > emit any code. > > > > I thought the fix would be some ODR-esque check to not consider > > constexpr variables/fns that are used just for their value. But > > it turned out to be tricky. For instance, we can't skip > > determine_visibility in a template; we can't even skip it for value-dep > > expressions. For example, no-linkage-expr1.C has > > > > using P = struct {}*; > > template > > void f(int(*)[((P)0, N)]) {} > > > > where ((P)0, N) is value-dep, but N is not relevant here: we have to > > ferret out the anonymous type. When instantiating, it's already gone. > > Hmm, how is that different from the B == VAL case? In both cases we're > naming an internal entity that gets folded away. > > I guess the difference is that B == VAL falls under the special allowance in > https://eel.is/c++draft/basic.def.odr#14.5.1 because it's a constant used as > a prvalue, and therefore is not odr-used under > https://eel.is/c++draft/basic.def.odr#5.2 > > So I would limit this change to decl_constant_var_p. Really we should also > be checking that the lvalue-rvalue conversion is applied, but that's more > complicated. Thanks. My previous version had it, but it didn't handle static constexpr int getval () { return 1; } template void baz(typename conditional::type arg) { } I'd say that "getval()" is one of "manifestly constant-evaluated expressions that are not value-dependent", so it should be treated the same as B == VAL. I don't know if this is important to handle. Do you want me to poke further or should we just go with decl_constant_var_p and leave it at that for now? Marek