On Wed, 5 Mar 2025 at 23:32, Jonathan Wakely <jwak...@redhat.com> wrote:
>
> On Mon, 3 Mar 2025 at 09:27, Jonathan Wakely <jwak...@redhat.com> wrote:
> >
> > On Mon, 3 Mar 2025 at 09:10, Christophe Lyon <christophe.l...@linaro.org>
> > wrote:
> > >
> > > Hi Jonathan,
> > >
> > > On Sun, 2 Mar 2025 at 23:28, Jonathan Wakely via Gcc-regression
> > > <gcc-regression@gcc.gnu.org> wrote:
> > > >
> > > > On Sun, 2 Mar 2025 at 02:42, <ci_not...@linaro.org> wrote:
> > > > >
> > > > > Dear contributor,
> > > > >
> > > > > Our automatic CI has detected problems related to your patch(es).
> > > > > Please find some details below.
> > > > >
> > > > > In arm-eabi cortex-m7 hard, after:
> > > > > | commit gcc-15-7765-g3866ca796d5
> > > > > | Author: Jonathan Wakely <jwak...@redhat.com>
> > > > > | Date: Thu Feb 27 13:27:17 2025 +0000
> > > > > |
> > > > > | libstdc++: Fix ranges::move and ranges::move_backward to use
> > > > > iter_move [PR105609]
> > > > > |
> > > > > | The ranges::move and ranges::move_backward algorithms are
> > > > > supposed to
> > > > > | use ranges::iter_move(iter) instead of std::move(*iter),
> > > > > which matters
> > > > > | for an iterator type with an iter_move overload findable by
> > > > > ADL.
> > > > > | ... 16 lines of the commit log omitted.
> > > > >
> > > > > Produces 8 regressions:
> > > > > |
> > > > > | regressions.sum:
> > > > > | Running libstdc++:libstdc++-dg/conformance.exp ...
> > > > > | FAIL: 25_algorithms/move/constrained.cc -std=gnu++20 (test for
> > > > > excess errors)
> > > > > | UNRESOLVED: 25_algorithms/move/constrained.cc -std=gnu++20
> > > > > compilation failed to produce executable
> > > > > | FAIL: 25_algorithms/move/constrained.cc -std=gnu++26 (test for
> > > > > excess errors)
> > > > > | UNRESOLVED: 25_algorithms/move/constrained.cc -std=gnu++26
> > > > > compilation failed to produce executable
> > > > > | ... and 4 more
> > > >
> > > > It looks like thumb has some unusual linking requirements that I'm not
> > > > familiar with, so undefined functions (which are never actually called
> > > > in the test) cause linker errors:
> > > >
> > > > /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include/bits/iterator_concepts.h:155:(.text._Z6test06N8pr1056091IE+0x6):
> > > > undefined reference to `pr105609::iter_move(pr105609::I const&)'
> > > > /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/arm-eabi/bin/ld:
> > > > (_ZN8pr1056099iter_moveERKNS_1IE): Unknown destination type
> > > > (ARM/Thumb) in /tmp/ccqKQGzN.o
> > >
> > > This is a "recent" linker warning, which I added sometime during last
> > > year (so you need recent binutils if you want to try to reproduce the
> > > problem).
> > > It means that for some reason the destination symbol lacks a tag (asm
> > > directive) saying whether it's a thumb or an arm function. This is
> > > used by the linker when deciding which type of stub to insert (if
> > > any).
> > > For instance: ".type myfunc, %function"
> > > but normally the compiler adds this for you.
> > >
> > > But you mention "undefined functions", so that would probably be the
> > > reason, but how can the link succeed? Are you linking with "-z undefs"
> > > ?
> >
> > See e.g. libstdc++-v3/testsuite/25_algorithms/move/constrained.cc
> > The test06 function uses undefined member functions such as
> > I::operator== but because test06 is never called, it shouldn't matter.
> >
> > I can move test06 to a separate { dg-do compile } test, where the
> > linker isn't involved at all.
>
> I hope this is fixed at
>
> r15-7842-gc21d5a3591fd761872e18278e1cd8ec18e36d4cb
>
Indeed, the tests now pass.
I still haven't understood why the original version passed on some
targets? (I assume so, I suppose you tested the patch before
committing ;-) )
Even if not called, test06 would still have references I::operator==
whatever the target?
Thanks,
Christophe
