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 7DDF33858C83 for ; Fri, 3 Mar 2023 18:14:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7DDF33858C83 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677867283; 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=gS4ZNf2OdtyQu8RPRHgpsFmXcsXJ9mwSf5ykBRwNspc=; b=EHMkKOyRYufgmV29yckRWmpu3lRD2BM2gTKwgvvHaBMnM+ABMtAIqIxAo9cmJf6FWJp3i4 tY8r9GjDs4cCx/sIfAhmLzSxrsoCbEzsa6yZ5Rm+iOgvJrWE3MvTjARiQZN3Og8tyFbkIE ykR0YuKov/k37bOf0oi7ZRGjomjiv+I= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-487-KON6LyvQM469SgApAYoPzQ-1; Fri, 03 Mar 2023 13:14:33 -0500 X-MC-Unique: KON6LyvQM469SgApAYoPzQ-1 Received: by mail-lj1-f198.google.com with SMTP id 10-20020a05651c12ca00b0028fd85f2e0aso860314lje.22 for ; Fri, 03 Mar 2023 10:14:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=gS4ZNf2OdtyQu8RPRHgpsFmXcsXJ9mwSf5ykBRwNspc=; b=hK4sxcezEpYbBxLJmgx7A6O2JYa53fgJL4iGLZyMPaCI6PPdaFfHzweiIl1SE3qTiq zfjFNFPIVzgWF/dGIsyOp1x77bP6UyCPt+R5OeZk0MTQEot2+v/A8LAKeMPonrD9BnfG 4mxQclZJ8/8jA4WgXjHO3djPKCtHxho2Rr3f7iCGhlrN8koUUh6M8Wt6PHUEki6wILgs navNXVbzubCgIoBmXsdTQemhRg5koKFsWnizg1aItaAy+Al7osVyguOIoxflDWnfpQqT uHeHQoMrGPIL0inclYEFpOGGmYM/7YFSoacI1LS+27Zhb7411LsM5TeN/+YCndZ5RM7Q 6d1Q== X-Gm-Message-State: AO0yUKUsJwgxQOTivJsFxmaLADmsidB+F/PNgRM2jyx9sRd+XdSEVVGM WaTfEP7q/Zi+jUdgChPwEF9Lccyb2ufh5CcbsRhVClrhsN6jXaaJET7NW923NFXyM4pmCVcN+cb y5sgTJRhf/k7jZ1lCv2Nho9AnrX5HVWU= X-Received: by 2002:ac2:5fe6:0:b0:4d8:5037:6da0 with SMTP id s6-20020ac25fe6000000b004d850376da0mr893922lfg.8.1677867272258; Fri, 03 Mar 2023 10:14:32 -0800 (PST) X-Google-Smtp-Source: AK7set8Rg2tnp3Bwwer7Dldon6Bs2yINLPvmLKvLV5h5/8eeojR7amMxvjiem0vmK6HcUax5sKouFQskLAHyxa3hvS8= X-Received: by 2002:ac2:5fe6:0:b0:4d8:5037:6da0 with SMTP id s6-20020ac25fe6000000b004d850376da0mr893915lfg.8.1677867272011; Fri, 03 Mar 2023 10:14:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Fri, 3 Mar 2023 18:14:20 +0000 Message-ID: Subject: Re: [libstdc++] Use __gthread_join in jthread/95989 To: Alexandre Oliva Cc: Jonathan Wakely , gcc-patches , "libstdc++" , Bernd Edlinger X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="000000000000ba964705f602ea50" 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,HTML_MESSAGE,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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: --000000000000ba964705f602ea50 Content-Type: text/plain; charset="UTF-8" On Fri, 3 Mar 2023 at 18:12, Jonathan Wakely wrote: > > > On Fri, 3 Mar 2023 at 17:47, Alexandre Oliva wrote: > >> On Mar 3, 2023, Jonathan Wakely wrote: >> >> > On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely >> wrote: >> >> Jakub previously suggested doing this for PR 61841, which was a similar >> >> problem with pthread_create: >> >> >> >> __asm ("" : : "r" (&pthread_create)); would not be optimized away. >> >> >> >> >> >> That would avoid the multiple copies. >> >> Not really. There would be multiple copies of the code that loads >> pthread_create's address. And we don't really need the address, a >> single never-executed call would do. I've explored these possibilities >> a bit, and here's what I've come up with: a private static member >> function that we output in units that instantiate the thread template >> ctor, to pass its address to _M_start_thread. Since it's never actually >> called, we don't really need the hacks in some of the alternatives I >> left in place, mainly for your enjoyment. >> >> They all work equally well, just as efficient per-instantiation at >> runtime, a little different space and loading overheads, but the last >> one, that is enabled, is my favorite: only PLT relocations, that we'd >> likely get anyway, no full-address resolution, and as-short-as-possible >> calls, enough to get a relocation with a strong reference to pull the >> symbol in when linking, but as short as possible call sequences, because >> of the type cast. >> > > And those expressions aren't ever optimized away as unused? > Oh, I missed that they're called after casting them, I didn't notice the trailing (). That would be UB to call them through the wrong pointer type, so the compiler could decide they're unreachable, but it seems to work for now. Thanks! --000000000000ba964705f602ea50--