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 8D27B3858C2F for ; Wed, 17 May 2023 10:00:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8D27B3858C2F 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=1684317607; 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=6eSRl7nsaYe+dgbDd4MG5j+qHTuhOTCvxDt5OjkBF14=; b=LySr+bH02OPYgyxZlOUNolkS8eONQ3VG9Ct1VbC6W4tv5aZKssJ7TguHhO8w93pL9v+3MK aynHmWKcaIOHaXCoAIBUYz5Aa5uqjcBW3arD/Axx8XO0t6kuWmol3uh12SO0GfgqmlCpO9 IISSw2taQboLLhQ8+leIrVs4FmGIOzw= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-371-wBFmCIBTOtSag0Eg4WEyOg-1; Wed, 17 May 2023 06:00:05 -0400 X-MC-Unique: wBFmCIBTOtSag0Eg4WEyOg-1 Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2ad93fa7132so2530771fa.0 for ; Wed, 17 May 2023 03:00:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684317604; x=1686909604; 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=6eSRl7nsaYe+dgbDd4MG5j+qHTuhOTCvxDt5OjkBF14=; b=M8t+S/oHkm+ohUVq4iksKHug5Tl8truq+C0yKP5oLSCC8aweUtCeFzWpZfqNe+6HDT +ZJ3016iTPW91pJDh17xXFMVNCXPkw1gqhUVTKPW0MnINm/E36v3s4mDFkNo8ZoZANC2 EdbK1NtC8OZCKbsOGyopypTHU/lcXH7l3g+fo1mwIegWpA2wUlBslGZNn8PJnZQUobPW o4RN6JJ+ktGfULyWJ1Lwx+Elg7G9LvHI4HUNN8oar6Lw8B4/xBnl9emekzTdDbj//lLz fsmUY1OSOoONu4JkJf+Sigv4oEF/+h+n6qaLkuiKKoW2k/q38MAV76f/Z7WapyaoCsYR gNOQ== X-Gm-Message-State: AC+VfDzQniFvSkvqQHB1QGbYFbdBgB2MllEK6ZQhjuXEvvNKdG/oURxe Z261OatL/RcFgLTkIpGKhCnSV3z8RGQcCZzXQd+TiLQ2tzk+J6sYiCu8y6hkNLThzu+xJ31CeqJ N8VQeHRqa6V/IBhmbUebxjtVnWizzl82Urg== X-Received: by 2002:a2e:9051:0:b0:2ad:8380:770d with SMTP id n17-20020a2e9051000000b002ad8380770dmr9065663ljg.21.1684317604094; Wed, 17 May 2023 03:00:04 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5YPRUiMlMPiKuWlcsvRYfOTp2IhmSVTm1JkLomTtEcfPyQtKJwPjvVwiaK+3BSbtT09hniSyZXfGJkkSCTlWk= X-Received: by 2002:a2e:9051:0:b0:2ad:8380:770d with SMTP id n17-20020a2e9051000000b002ad8380770dmr9065653ljg.21.1684317603760; Wed, 17 May 2023 03:00:03 -0700 (PDT) MIME-Version: 1.0 References: <20230516173156.1826089-1-jwakely@redhat.com> In-Reply-To: From: Jonathan Wakely Date: Wed, 17 May 2023 10:59:52 +0100 Message-ID: Subject: Re: [committed] libstdc++: Disable cacheline alignment for DJGPP [PR109741] To: Martin Jambor Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="000000000000761b9505fbe0c064" X-Spam-Status: No, score=-13.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000761b9505fbe0c064 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 17 May 2023 at 10:32, Martin Jambor wrote: > Hello, > > On Tue, May 16 2023, Jonathan Wakely via Gcc-patches wrote: > > Tested powerpc64le-linux. Builds OK on djgpp too. > > > > Pushed to trunk. > > > > -- >8 -- > > > > DJGPP (and maybe other targets) uses MAX_OFILE_ALIGNMENT=3D16 which mea= ns > > that globals (and static objects) can't have alignment greater than 16. > > This causes an error for the locks defined in src/c++11/shared_ptr.cc > > because we try to align them to the cacheline size, to avoid false > > sharing. > > > > Add a configure check for the increased alignment, and live with false > > sharing where we can't increase the alignment. > > > > libstdc++-v3/ChangeLog: > > > > PR libstdc++/109741 > > * acinclude.m4 (GLIBCXX_CHECK_ALIGNAS_CACHELINE): Define. > > * config.h.in: Regenerate. > > * configure: Regenerate. > > * configure.ac: Use GLIBCXX_CHECK_ALIGNAS_CACHELINE. > > * src/c++11/shared_ptr.cc (__gnu_internal::get_mutex): Do not > > align lock table if not supported. use __GCC_DESTRUCTIVE_SIZE > > instead of hardcoded 64. > > The periodic tests that Martin Li=C5=A1ka left behind for me (for now) to > look at are now complaining that the configure and configure.ac in > libstdc++ are not in sync, the difference being (drum roll): > > diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure > index 188be08d716..412c4bf0e85 100755 > --- a/libstdc++-v3/configure > +++ b/libstdc++-v3/configure > @@ -71957,6 +71957,7 @@ _ACEOF > fi > > > +# For src/c++11/shared_ptr.cc alignment. > > > ac_ext=3Dcpp > Oh no! I was worried I'd actually broken something when I saw the email land in my inbox :-) Looks like I added that comment to configure.ac and then forgot to re-run autoreconf. > Can I commit this change or do I need to attempt to adjust the script to > ignore comments in configure or what would be the correct way to deal > with this? (Option requiring work on my side may take some time during > which the otherwise useful tests would not work, I am afraid). > > The "correct" fix is to run autoreconf in the libstdc++-v3 dir to regen the configure script, but for something this trivial it would also be fine to just make the change manually. I've pushed the regenerated file now, as r14-930-g7ddbc6171b383c Thanks for running those checks! --000000000000761b9505fbe0c064--