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 A7ED9384640E for ; Wed, 24 Apr 2024 22:39:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A7ED9384640E 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 A7ED9384640E 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=1713998381; cv=none; b=UWFUXVnIsXsCXvZESHy3Af5Qef71f0KhU/DAXQMPQQVH/yN5W3TC7/Z4vi9N+Xs0Davtc3iRoAmQHlTt8K9l7cqOIip0Q05vXKaVZn+GOlYD1H4pIqDa5bwFVLw3ZBjCwRkSCfrhhl+O5Oze39FFG9okdhM6x8GUIJgOHbKteqs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713998381; c=relaxed/simple; bh=Uzh8e5yGdmS+Sa7Lz+pOwEKeuHNlfYelDEJrONdz5pY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=E+9AC3ZO/f3UxS4/nVDvSIxhYRAr2dlwojbLEXlZKkgrAhOM3ZsTccKeraTX3a3j/pIzd7F5UaKBwEHelrm3sUOHeqi3tSC3DP/a2xMHp7QiRAYfa5bXb+9VYGhSOf6O0L3t7y3SkY03BafKlvkOBbzs2zGeVEpaJbd9v5zLjC0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1713998379; 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=jU9SUs7iWp8JvBDh5XGSFwfbSXoSWs2akm0yOk/4Lwg=; b=MtwliuFGxkiZs2ukEcLTFP+8hcNE4RethDz6wMXk/K7x23NxHQOIn6wT18+s81kMzPjesg EouFKML6uPDUxlw7J1/BHXCWObmcBShCSgyYHALaO18Rwxzqt1X/LoPIFBu+YbIZipCPNy Qy8FCnhRSb6fhf0VSTMwyJcpIhPu4dc= Received: from mail-vs1-f71.google.com (mail-vs1-f71.google.com [209.85.217.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-644-eX5ceSMIPeCxgZT1UEgMgQ-1; Wed, 24 Apr 2024 18:39:37 -0400 X-MC-Unique: eX5ceSMIPeCxgZT1UEgMgQ-1 Received: by mail-vs1-f71.google.com with SMTP id ada2fe7eead31-47b5fbe6e56so208741137.3 for ; Wed, 24 Apr 2024 15:39:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713998377; x=1714603177; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jU9SUs7iWp8JvBDh5XGSFwfbSXoSWs2akm0yOk/4Lwg=; b=cKGBXQS7sxIIZcu++XjTSFtrOr0lz01FJy+DbIURH5AcxdhqXye6VijUFqvQkSnbov 5o8ruWmJnEz78sPI1zzqgc1GHMJG1H5gxf6smaSj3OycL8oEkRTI9L5+PZ0CYgnSpqR7 JRdd/FjsDrXHoV6JOhk1sdBiVNlKtwpTEfFxGiFQQoadxClNynmiVNIciJX9dn6Zajf9 SbpG119oJhLfDvbG2c65yQyKb5bfyZ1sWwotf8WrhzL/mi8J0NjajVaHySHpo1RF5DS3 7X6LrvzjrYsn5T+4Oyb76ILc5Vg/pkQE7QWl4OJRNrufEQ+SCPe6GPhOf8+fMgmlof7Q twWA== X-Gm-Message-State: AOJu0Yz3sYQn45kUhTQ45huDSt2Rn76B1S9tLg+Q7pWdLOoLQcdbQ8vi ZIDHsP/PD7jVcF0Yqfn3x6OvBNIz46Kis+FHp3u2zU3c0CmfZaiBqRtatFQsuB4XMuHGNa8hfZY ZbdhKxIxQBicrQRvXmD76zVL2kweny1e8ij+FIFBH8CtilDcVXGSsokM= X-Received: by 2002:a05:6102:3a66:b0:47c:13ce:f061 with SMTP id bf6-20020a0561023a6600b0047c13cef061mr2073723vsb.34.1713998377244; Wed, 24 Apr 2024 15:39:37 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGTNXIYzlERHdvrzLqviKS5e+Fo+OLRUMIIpX5EcQBuTpZqlqs+QkiDORaesMoQJTa13gwQLw== X-Received: by 2002:a05:6102:3a66:b0:47c:13ce:f061 with SMTP id bf6-20020a0561023a6600b0047c13cef061mr2073650vsb.34.1713998375441; Wed, 24 Apr 2024 15:39:35 -0700 (PDT) Received: from [192.168.1.130] (130-44-146-16.s12558.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.146.16]) by smtp.gmail.com with ESMTPSA id w20-20020ac87194000000b00439622fb8f4sm4750299qto.39.2024.04.24.15.39.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Apr 2024 15:39:34 -0700 (PDT) Message-ID: Date: Wed, 24 Apr 2024 18:39:33 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] c++, v3: Retry the aliasing of base/complete cdtor optimization at import_export_decl time [PR113208] To: Jakub Jelinek , Jonathan Wakely , Jan Hubicka Cc: gcc-patches@gcc.gnu.org, Richard Biener , Patrick Palka References: <5fe9db40-4bff-4be4-a434-6509133f26e3@redhat.com> From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 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_H4,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_WEB,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no 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 4/24/24 09:16, Jakub Jelinek wrote: > On Wed, Apr 24, 2024 at 10:16:05AM +0100, Jonathan Wakely wrote: >>> That fixes the testcases too, but seems to regress >>> +FAIL: libstdc++-abi/abi_check > >> There are explicit instantiation definitions that should instantiate >> those types: >> >> src/c++17/fs_dir.cc:template class std::__shared_ptr; >> src/c++17/fs_dir.cc:template class >> std::__shared_ptr; >> src/c++17/fs_path.cc:template class std::__shared_ptr> fs::filesystem_error::_Impl>; >> >> So the missing symbols should be present in cow-fs_dir.o and cow-fs_path.o > > So this boils down to (cvise reduced): > namespace __gnu_cxx { enum _Lock_policy { _S_single, _S_mutex, _S_atomic } const __default_lock_policy = _S_atomic; } > namespace std { > using __gnu_cxx::__default_lock_policy; > using __gnu_cxx::_Lock_policy; > template struct __shared_ptr { constexpr __shared_ptr() {} }; > namespace filesystem { > struct _Dir; > struct directory_iterator { __shared_ptr<_Dir> _M_dir; }; > void end() { directory_iterator(); } } > extern template class __shared_ptr; > } > namespace fs = std::filesystem; > template class std::__shared_ptr; > at -O2, previously it used to emit > _ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev > _ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE1EEC2Ev > but now no longer does with the yesterday posted PR113208 patch. > > The following updated patch fixes that by calling note_vague_linkage_fn for > the cdtor clones from maybe_clone_body if the flags suggest that the > maybe-in-charge cdtor had tentative_decl_linkage -> note_vague_linkage_fn > called too. And then I've noticed that in some cases the updated comdat > group set by maybe_clone_body (*C5* or *D5*) was then overwritten again by > maybe_make_one_only. So the patch tweaks cxx_comdat_group, so that when > some comdat group has been chosen already it doesn't try to use some > different one. > > Bootstrapped/regtested on x86_64-linux and i686-linux, this one doesn't > regress anything unlike the earlier patch. > > 2024-04-24 Jakub Jelinek > > PR lto/113208 > * decl2.cc (tentative_decl_linkage): Use comdat_linkage also > for implicit instantiations of maybe in charge ctors/dtors > if -fimplicit-templates or -fimplicit-inline-templates and > -fweak and target supports aliases. > * optimize.cc (maybe_clone_body): Call note_vague_linkage_fn > on clone if fn has DECL_INTERFACE_KNOWN, DECL_NOT_REALLY_EXTERN > and DECL_DEFER_OUTPUT flags set. > * decl.cc (cxx_comdat_group): For DECL_CLONED_FUNCTION_P > functions if SUPPORTS_ONE_ONLY return DECL_COMDAT_GROUP if already > set. > > * g++.dg/abi/comdat2.C: New test. > * g++.dg/abi/comdat3.C: New test. > * g++.dg/lto/pr113208_0.C: New test. > * g++.dg/lto/pr113208_1.C: New file. > * g++.dg/lto/pr113208.h: New file. > > --- gcc/cp/decl2.cc.jj 2024-04-23 14:49:41.933186265 +0200 > +++ gcc/cp/decl2.cc 2024-04-24 15:17:09.043625729 +0200 > @@ -3314,7 +3314,16 @@ tentative_decl_linkage (tree decl) > to mark the functions at this point. */ > if (DECL_DECLARED_INLINE_P (decl) > && (!DECL_IMPLICIT_INSTANTIATION (decl) > - || DECL_DEFAULTED_FN (decl))) > + || DECL_DEFAULTED_FN (decl) > + /* For implicit instantiations of cdtors, > + if import_export_decl would use comdat linkage, > + make sure to use it right away, so that maybe_clone_body > + can use aliases. See PR113208. */ > + || (DECL_MAYBE_IN_CHARGE_CDTOR_P (decl) > + && (flag_implicit_templates > + || flag_implicit_inline_templates) > + && flag_weak > + && TARGET_SUPPORTS_ALIASES))) It seems wrong to set DECL_INTERFACE_KNOWN for cdtors that might get an explicit instantiation later, and likewise for comdat_linkage when !flag_weak; instead of adding this condition to the if, how about adding an else like > else if (DECL_MAYBE_IN_CHARGE_CDTOR_P (decl)) > /* For implicit instantiations of cdtors, > if import_export_decl would use comdat linkage, > make sure to use it right away, so that maybe_clone_body > can use aliases. See PR113208. */ > maybe_make_one_only (decl); ? Jason