On Wed, 23 Jun 2021 at 10:43, Christophe LYON wrote: > > > On 23/06/2021 11:17, Jonathan Wakely via Libstdc++ wrote: > > On Wed, 23 Jun 2021 at 08:21, Christophe Lyon wrote: > >> This patch causes GCC build failures for bare-metal targets > >> (aarch64-elf, arm-eabi). For instance on arm-eabi, I'm seeing: > >> > >> In file included from > >> /tmp/1229695_7.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/future:38, > >> from > >> /tmp/1229695_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/include/precompiled/stdc++.h:105: > >> /tmp/1229695_7.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/mutex: > >> In function 'int std::__detail::__try_lock_impl(_Lockable&)': > >> /tmp/1229695_7.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/mutex:522:53: > >> error: expected primary-expression before ',' token > >> 522 | if (unique_lock<_Lockable> __lock{__lockable, try_to_lock}) > >> | ^ > >> In file included from > >> /tmp/1229695_7.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/future:38, > >> from > >> /tmp/1229695_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/include/precompiled/stdc++.h:105: > >> /tmp/1229695_7.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/mutex: > >> In function 'int std::__detail::__try_lock_impl(_Lockable&)': > >> /tmp/1229695_7.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/mutex:522:53: > >> error: expected primary-expression before ',' token > >> 522 | if (unique_lock<_Lockable> __lock{__lockable, try_to_lock}) > >> | ^ > >> make[4]: *** [Makefile:1862: > >> arm-none-eabi/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1 > > Sigh, __lockable is a macro in newlib: > > > > newlib/libc/include/sys/cdefs.h:#define __lockable > > __lock_annotate(lockable) > > > > I'll change the name. > > Thanks (sorry for being back ;-) Fixed with this patch, tested x86_64 and pushed to trunk.