public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Jambor <mjambor@suse.cz>
To: Jonathan Wakely <jwakely@redhat.com>
Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: [committed] libstdc++: Disable cacheline alignment for DJGPP [PR109741]
Date: Wed, 17 May 2023 11:32:10 +0200	[thread overview]
Message-ID: <ri61qjffgmd.fsf@suse.cz> (raw)
In-Reply-To: <20230516173156.1826089-1-jwakely@redhat.com>

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=16 which means
> 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ška 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=cpp


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).

Thanks,

Martin

  reply	other threads:[~2023-05-17  9:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-16 17:31 Jonathan Wakely
2023-05-17  9:32 ` Martin Jambor [this message]
2023-05-17  9:59   ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ri61qjffgmd.fsf@suse.cz \
    --to=mjambor@suse.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jwakely@redhat.com \
    --cc=libstdc++@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).