[committed] libstdc++: Disable cacheline alignment for DJGPP [PR109741]

[Jonathan Wakely]

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=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
>


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!