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 A14BD3858C5E for ; Fri, 3 Mar 2023 18:14:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A14BD3858C5E 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=1677867275; 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=GcuenNdAXC9y6alZhcnazXx1thc+Me+boYsIWzpn2aoGBUGwVl8CxK4cULHwy4REeesylV OqotgbywLEu3j5suP0a8/5LJT9yRZ1AaO7VWQIYjxn6GK9/8sTBXBsmbyOmO7OSzT4X682 KEKRFX09t/zCjz/vRQw2fF37vfhm7kg= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-397--P096TdxORq6NfDH3lcQmA-1; Fri, 03 Mar 2023 13:14:33 -0500 X-MC-Unique: -P096TdxORq6NfDH3lcQmA-1 Received: by mail-lj1-f199.google.com with SMTP id f4-20020a05651c160400b002959ea5bc51so862392ljq.9 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=XfaYxaO+/vwd+AfGwyowOEk/WG7O2QvPgOr6TAIXWHaTVoRnsu4VPV5n+VUI09UKkJ of53TUFjPAq6ak2sZOU8T/rY+TKT6DGlU1PrAydA/hdcsjOhEpdGfP+JtF6Yu6gmyuKh 0UK/sj3dKDoUL2jbt4ROSGoHm7eAfaJOzj2aqV2vWu11gaQPkwbjp4kM8doRXz3iAMoX qDbZ1ZVM7YsK8Hgj2FkTayMREItSiram3hCQUa8bl8J7G9TGOqHNp0nyh65A/4Uqef6E FfGmZNX6xqsJQH2OBerxlfeF+Aacto2CDRJpkky8tC/VWt/N6orhbgqRDqVU2CQbsMz+ NzjQ== X-Gm-Message-State: AO0yUKUWHWcXaz0NBHEYI5EnRzVNQsYgUHXQnxz5VAOeohGfqKScV9Py bi3UVZe96tpf9DtQRCgJYCT0TJ6k7aL+/b2cjNS0rmP8srcnIQom5VKn9BPcoSllst6uLTFwb0S tPtLqp1EGJTZehT8slHsd65QJTEyr7dh6Uw== X-Received: by 2002:ac2:5fe6:0:b0:4d8:5037:6da0 with SMTP id s6-20020ac25fe6000000b004d850376da0mr893923lfg.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.7 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--