On Wed, 20 Nov 2019 at 11:10, Ville Voutilainen
<ville.voutilai...@gmail.com> wrote:
>
> On Wed, 20 Nov 2019 at 11:47, Christophe Lyon
> <christophe.l...@linaro.org> wrote:
> >
> > On Thu, 14 Nov 2019 at 16:55, Jonathan Wakely <jwak...@redhat.com> wrote:
> > >
> > > On 09/11/19 02:07 +0000, Smith-Rowland, Edward M wrote:
> > > >Here is the <tuple> part of C++20 p1032 Misc constexpr bits.
> > > >
> > > >Tested on x86_64-linux. OK?
> > >
> > > OK for trunk, thanks.
> > >
> >
> > Hi,
> >
> > The new test constexpr_allocator_arg_t.cc fails on arm and aarch64 and
> > many other targets according to gcc-testresults.
> > Is that expected?
>
> No, that's not expected. Can you give a link to the build log?
On (cross) aarch64, I can see:
FAIL: 20_util/tuple/cons/constexpr_allocator_arg_t.cc (test for excess errors)
Excess errors:
/libstdc++-v3/testsuite/20_util/tuple/cons/constexpr_allocator_arg_t.cc:48:
error: non-constant condition for static assertion
/libstdc++-v3/testsuite/20_util/tuple/cons/constexpr_allocator_arg_t.cc:48:
in 'constexpr' expansion of 'test_tuple()'
/libstdc++-v3/testsuite/20_util/tuple/cons/constexpr_allocator_arg_t.cc:31:
in 'constexpr' expansion of 'ta.std::tuple<int, double,
double>::tuple<std::allocator<int> >(std::allocator_arg, alloc)'
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/tuple:705:
error: 'constexpr std::_Tuple_impl<_Idx, _Head, _Tail
...>::_Tuple_impl(std::allocator_arg_t, const _Alloc&) [with _Alloc =
std::allocator<int>; long unsigned int _Idx = 0; _Head = int; _Tail =
{double, double}]' called in a constant expression
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/tuple:251:
error: call to non-'constexpr' function 'std::__uses_alloc_t<_Tp,
_Alloc, _Args ...> std::__use_alloc(const _Alloc&) [with _Tp = int;
_Alloc = std::allocator<int>; _Args = {}; std::__uses_alloc_t<_Tp,
_Alloc, _Args ...> = std::__uses_alloc_t<int, std::allocator<int> >]'
I see it failing at r278333, was it fixed since then?
