Re: [PATCH RFA] libstdc++: add more #if to std.cc (was Re: [Linaro-TCWG-CI] gcc-16-5581-g3ad2e2d707c3: 1 regression on arm)

On Sat, 6 Dec 2025 at 09:14, Jason Merrill <[email protected]> wrote:
>
> On 12/6/25 11:52 AM, [email protected] wrote:
> > Dear contributor,
> >
> > Our automatic CI has detected problems related to your patch(es). Please find some details below.
> >
> > In  arm-eabi v7-a softfp, after:
> >    | commit gcc-16-5581-g3ad2e2d707c3
> >    | Author: Jason Merrill <[email protected]>
> >    | Date:   Tue Nov 11 15:58:01 2025 +0530
> >    |
> >    |     driver/c++: add --compile-std-module
> >    |
> >    |     For simple testcases that want to use the std module, it would be useful to
> >    |     have a reasonably short way to request building the binary module form
> >    |     before the testcase.  So with this patch users can write
> >    | ... 31 lines of the commit log omitted.
> >
> > Produces 1 regression:
> >    |
> >    | regressions.sum:
> >    | Running g++:g++.dg/modules/modules.exp ...
> >    | FAIL: g++.dg/modules/compile-std1.C -std=c++26 (test for excess errors)
>
> It seems that module std doesn't compile on arm-eabi, which is good to know.
>
> There seem to be two general issues: first, that some of the <stdio.h>
> functions that <print> relies on aren't declared:
>
> > /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-sta\
> > ge2/arm-eabi/libstdc++-v3/include/print: In member function 'virtual void std::__format::_File_sink::_M_o\
> > verflow()':
> > /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-sta\
> > ge2/arm-eabi/libstdc++-v3/include/print:197:20: error: '::fwrite_unlocked' has not been declared; did you\
> >  mean '_fwrite_unlocked_r'?
> > /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-sta\
> > ge2/arm-eabi/libstdc++-v3/include/print: In constructor 'std::__format::_File_sink::_File_sink(FILE*, boo\
> > l)':
> > /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-sta\
> > ge2/arm-eabi/libstdc++-v3/include/print:212:9: error: '::flockfile' has not been declared; did you mean '\
> > _flockfile'?
> > /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-sta\
> > ge2/arm-eabi/libstdc++-v3/include/print: In destructor 'std::__format::_File_sink::~_File_sink()':
> > /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-sta\
> > ge2/arm-eabi/libstdc++-v3/include/print:218:11: error: '::putc_unlocked' has not been declared; did you m\
> > ean '_putc_unlocked_r'?
> > /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-sta\
> > ge2/arm-eabi/libstdc++-v3/include/print:219:9: error: '::funlockfile' has not been declared; did you mean\
> >  '_funlockfile'?
>
> It seems that newlib doesn't declare these functions under -std=c++26,
> only -std=gnu++26.  I don't know what the right approach to this is.
>
> and then a bunch of "not declared" exports, such as
>
> > /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-sta\
> > ge2/arm-eabi/libstdc++-v3/include/bits/std.cc:1002:14: error: 'condition_variable' has not been declared \
> > in 'std'
>
> This looks like just needing to add more #if to std.cc, as below.  OK
> for trunk?

OK

I keep going back and forth on whether we should provide dumb no-op
versions of std::mutex etc. for non-ghtreads targets, so that the
types exist they just don't do anything. We provide std::thread for
non-gthreads, but it only has a default constructor, so you can't
actually create new threads of execution with it.

And for this one we could just define the thread-safe pool as an alias
of the unsynchronized pool for non-gthreads:

+#if _GLIBCXX_HAS_GTHREADS
   using std::pmr::synchronized_pool_resource;
+#endif
   using std::pmr::unsynchronized_pool_resource;



>
> Incidentally, is it expected that arm-eabi doesn't support gthread?
>
> Jason