On Fri, 7 Mar 2025 at 12:53, Christophe Lyon <christophe.l...@linaro.org>
wrote:
> 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.
>
Great, thanks for confirming it.
>
> I still haven't understood why the original version passed on some
> targets? (I assume so, I suppose you tested the patch before
> committing ;-) )
>
I did! :-)
> Even if not called, test06 would still have references I::operator==
> whatever the target?
>
Maybe the whole of test06 was optimized away as dead code.
