Minimal examples fail on armhf

[stephanlachnit]

The minimal examples fail to compile on the armhf architecture. This was found by Debian's CI (tested twice to make sure it's not a random failure).
The bug report is here and the log here.

The interesting part starts in line 1941:

Building CXX object minimal/CMakeFiles/ptl-minimal.dir/minimal.cc.o
In file included from /usr/include/c++/10/map:61,
                 from /usr/include/PTL/Utility.hh:30,
                 from /usr/include/PTL/Globals.hh:36,
                 from /usr/include/PTL/Threading.hh:28,
                 from /usr/include/PTL/AutoLock.hh:246,
                 from /usr/include/PTL/PTL.hh:22,
                 from /tmp/autopkgtest-lxc.czgi6jo2/downtmp/autopkgtest_tmp/minimal/minimal.cc:22:
/usr/include/c++/10/bits/stl_map.h: In member function ‘std::map<_Key, _Tp, _Compare, _Alloc>::mapped_type& std::map<_Key, _Tp, _Compare, _Alloc>::operator[](const key_type&) [with _Key = std::thread::id; _Tp = long long unsigned int; _Compare = std::less<std::thread::id>; _Alloc = std::allocator<std::pair<const std::thread::id, long long unsigned int> >]’:
/usr/include/c++/10/bits/stl_map.h:501:37: note: parameter passing for argument of type ‘std::_Rb_tree<std::thread::id, std::pair<const std::thread::id, long long unsigned int>, std::_Select1st<std::pair<const std::thread::id, long long unsigned int> >, std::less<std::thread::id>, std::allocator<std::pair<const std::thread::id, long long unsigned int> > >::const_iterator’ changed in GCC 7.1
  501 |    __i = _M_t._M_emplace_hint_unique(__i, std::piecewise_construct,
      |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  502 |          std::tuple<const key_type&>(__k),
      |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  503 |          std::tuple<>());
      |          ~~~~~~~~~~~~~~~             

I have to be honest, I don't know what is going on here. The examples work fine on other architectures (amd64, arm64, i386, ppc64el), and iirc it worked fine before with PTL 1.0.2.

The CI runs on Debian Sid, which is the rolling development version of Debian. GCC is at version 10.3.0.

[jrmadsen]

So the best I can tell from these logs is that there isn't an actual compiler error, or even a compiler warning. I think the compiler is making a note about a change in the STL implementation and redirecting that message to stderr and the testing system is configured to fail if anything gets written to stderr.

[stephanlachnit]

Ah that makes sense. In fact now searching through the log, there is no error or warning, just notes.
The test indeed fails on stderr output.
Thanks for your help and sorry for bothering!