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 D155D3858C60 for ; Thu, 28 Sep 2023 16:18:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D155D3858C60 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=1695917935; 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=1l/sksfNpMFmmmi8YE1aBpyg8bj59tDFZioiNv/kSrc=; b=iMTgluaqHbs1tTXp9j48KGjxp2+XQVnj6Ru26WAIPyUpQqdLXYNCDCn/TTSXzcRdrygDPS N3WmUoCdG8tRncSn6By19gUwwulT3hroiBz1/SolfwQ1BMDlCmAqx5iKClQVYt1vkTDr1v uWFQ95+cSw54G9mFaWLR1a/q7wmG5hU= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-629-jbo-ZsDJNpGm47Fd336xXg-1; Thu, 28 Sep 2023 12:18:54 -0400 X-MC-Unique: jbo-ZsDJNpGm47Fd336xXg-1 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2bbbaa6001dso203487071fa.3 for ; Thu, 28 Sep 2023 09:18:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695917932; x=1696522732; h=content-transfer-encoding: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=1l/sksfNpMFmmmi8YE1aBpyg8bj59tDFZioiNv/kSrc=; b=qmSJGjS+Yk1cslYk3zH9YOih70rHtizZVhf7JpPU/22C5Hqf3mbHg6jUie4fqgZ2Sq 53U6KmGKOTVdiCZDFPq3AsCbS9cD0VIUKXJxK6u8lEKGw+mFu0SUERABsXKFcS045Bw2 PAK3rIrVl2huEoegRxRHWMZu457rMi3eXfIntFYBItzAxg9fx29xzcOgWxBla0fgf1lw zyQ4IF/2AsgfRyRFCtXU1Km1Xn25L1SYKo386pvFUUEuSzZmTSQK8dUc+Ty2P5FLezi+ CG8TjJRNoiXecY+qD1ZKnilWyIzWjjAbLD5XzQTIC29wRvjjne57VHpSO1S0ZQgC/ZOV knqw== X-Gm-Message-State: AOJu0YzvyoY5hmx8LEpvrMsx4IWRydmqsl8eNnzikSQCIBmEeiwbeDwc vHYPic1K4RH2gWEXJkiF+vbkXYZRc2dIwjLWLoMw+mQF85FKnrUkFtaowjqHrkFlccA25KzmDZg 4qTosZ70AczF/EddG98ouFn1IMgWA+oA= X-Received: by 2002:a2e:88c8:0:b0:2bf:f68a:b129 with SMTP id a8-20020a2e88c8000000b002bff68ab129mr1588119ljk.36.1695917932593; Thu, 28 Sep 2023 09:18:52 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHjWozzXlxN9MOMkJGVm2vMyD/98Jpr9758QNvqQgvYEQy61V2STjov+x9wHK61KT0s3RA1tUP/Io6dNqRfdH0= X-Received: by 2002:a2e:88c8:0:b0:2bf:f68a:b129 with SMTP id a8-20020a2e88c8000000b002bff68ab129mr1588106ljk.36.1695917932268; Thu, 28 Sep 2023 09:18:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Thu, 28 Sep 2023 17:18:41 +0100 Message-ID: Subject: Re: [PATCH] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11 [PR 111050] To: =?UTF-8?Q?Fran=C3=A7ois_Dumont?= Cc: rs2740@gmail.com, "libstdc++" , gcc-patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.2 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 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 Wed, 27 Sept 2023 at 05:44, Fran=C3=A7ois Dumont = wrote: > > Still no chance to get feedback from TC ? Maybe I can commit the below > then ? I've heard back from Tim now. Please use "Tim Song " as the author. You can change the commit again using git commit --amend --author "Tim Song " OK for trunk with that change - thanks for waiting. > > AFAICS on gcc mailing list several gcc releases were done recently, too > late. There have been no releases this month, so the delay hasn't caused any prob= lems. > > > On 14/09/2023 06:46, Fran=C3=A7ois Dumont wrote: > > Author: TC > > Date: Wed Sep 6 19:31:55 2023 +0200 > > > > libstdc++: Force _Hash_node_value_base methods inline to fix abi > > (PR111050) > > > > https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3D1b6f047683720593261= 3ddb2b3429a55c26c409d > > > > changed _Hash_node_value_base to no longer derive from > > _Hash_node_base, which means > > that its member functions expect _M_storage to be at a different > > offset. So explosions > > result if an out-of-line definition is emitted for any of the > > member functions (say, > > in a non-optimized build) and the resulting object file is then > > linked with code built > > using older version of GCC/libstdc++. > > > > libstdc++-v3/ChangeLog: > > > > PR libstdc++/111050 > > * include/bits/hashtable_policy.h > > (_Hash_node_value_base<>::_M_valptr(), > > _Hash_node_value_base<>::_M_v()) > > Add [[__gnu__::__always_inline__]]. > > > > Ok to commit ? > > > > On 12/09/2023 18:09, Jonathan Wakely wrote: > >> On Mon, 11 Sept 2023 at 18:19, Fran=C3=A7ois Dumont > >> wrote: > >>> > >>> On 11/09/2023 13:51, Jonathan Wakely wrote: > >>>> On Sun, 10 Sept 2023 at 14:57, Fran=C3=A7ois Dumont via Libstdc++ > >>>> wrote: > >>>>> Following confirmation of the fix by TC here is the patch where I'm > >>>>> simply adding a 'constexpr' on _M_next(). > >>>>> > >>>>> Please let me know this ChangeLog entry is correct. I would prefer > >>>>> this > >>>>> patch to be assigned to 'TC' with me as co-author but I don't know > >>>>> how > >>>>> to do such a thing. Unless I need to change my user git identity > >>>>> to do so ? > >>>> Sam already explained that, but please check with Tim how he wants t= o > >>>> be credited, if at all. He doesn't have a copyright assignment, and > >>>> hasn't added a DCO sign-off to the patch, but it's small enough to n= ot > >>>> need it as this is the first contribution credited to him. > >>>> > >>>> > >>>>> libstdc++: Add constexpr qualification to > >>>>> _Hash_node::_M_next() > >>>> What has this constexpr addition got to do with the ABI change and t= he > >>>> always_inline attributes? > >>>> > >>>> It certainly doesn't seem like it should be the summary line of the > >>>> git commit message. > >>> Oops, sorry, that's what I had started to do before Tim submitted > >>> anything. > >>> > >>> Here is latest version: > >> No patch attached, and the ChangeLog below still mentions the constexp= r. > >> > >> I've pinged Tim via another channel to ask him about the author > >> attribution. > >> > >> > >>> Author: TC > >>> Date: Wed Sep 6 19:31:55 2023 +0200 > >>> > >>> libstdc++: Force inline on _Hash_node_value_base methods to > >>> fix abi > >>> (PR111050) > >>> > >>> https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3D1b6f0476837205932= 613ddb2b3429a55c26c409d > >>> > >>> changed _Hash_node_value_base to no longer derive from > >>> _Hash_node_base, which means > >>> that its member functions expect _M_storage to be at a differen= t > >>> offset. So explosions > >>> result if an out-of-line definition is emitted for any of the > >>> member functions (say, > >>> in a non-optimized build) and the resulting object file is then > >>> linked with code built > >>> using older version of GCC/libstdc++. > >>> > >>> libstdc++-v3/ChangeLog: > >>> > >>> PR libstdc++/111050 > >>> * include/bits/hashtable_policy.h > >>> (_Hash_node_value_base<>::_M_valptr(), > >>> _Hash_node_value_base<>::_M_v()) > >>> Add [[__gnu__::__always_inline__]]. > >>> (_Hash_node<>::_M_next()): Add constexpr. > >>> > >>> Co-authored-by: Fran=C3=A7ois Dumont > >>> > >>> Ok for you TC (Tim ?) ? > >>> > >>> >