powerpc and powerpc64 flavours used to unconditionally specify -many
assembler option when invoking `as` binary.  This way, `as' accepted
mixed instructions.

For example, when building openbios for ppc, we have:

 powerpc-linux-gnu-gcc -m32 -m604 ... start.S

with previous versions of gcc, this resulted in

 as -a32 -mppc -many -mbig ...

now with gcc-16.1.0, the -many is missing:

 as -a32 -mppc -mbig ...

and `as` complains about unrecognized instructions such as clrldi,
mtmsrd, ld, std, - which are 64bits and are valid for this CPU type.

The same happens with powerpc64, which also omits -many now, so `as'
rejects other instructions, such as hrfid or nap, and there, adding
-many explicitly lets the build to continue.

I don't know if this is an intended change or not, - especially since
I know right to nothing about ppc assembly.  But it feels like it is
not intended.  On Fedora, gcc-16.1.1 does pass -many unconditionally,
as it were before.  So it feels like only debian is broken currently.

This issue breaks qemu build (#1143769).  I can work around this by
explicitly passing -Wa,-many in two places, but it feels wrong to do
that.

Thanks,

/mjt

Actually it is more interesting.  The firmware does have
memset() definition in there.

The original command line:

  hppa64-linux-gnu-ld -N -T o64/pafirmware.lds o64/head.o o64/version.o -X -o o64/hppa-firmware64.img -e startup \
     --as-needed o64/ccode32flat.o /usr/lib/gcc/hppa64-linux-gnu/16/libgcc.a

produces the original error messages:

  /usr/bin/hppa64-linux-gnu-ld.bfd: o64/ccode32flat.o: in function `hash_log_extend':
  ccode32flat.o.tmp.c:(.text+0x5400): undefined reference to `memset'
  /usr/bin/hppa64-linux-gnu-ld.bfd: o64/ccode32flat.o(.text+0x5400): cannot reach memset
  ccode32flat.o.tmp.c:(.text+0x5400): relocation truncated to fit: R_PARISC_PCREL22F against undefined symbol `memset'
  /usr/bin/hppa64-linux-gnu-ld.bfd: o64/ccode32flat.o: in function `tpm_add_measurement_to_log':
  ccode32flat.o.tmp.c:(.text+0x7130): undefined reference to `memset'
  /usr/bin/hppa64-linux-gnu-ld.bfd: o64/ccode32flat.o(.text+0x7130): cannot reach memset
  ccode32flat.o.tmp.c:(.text+0x7130): relocation truncated to fit: R_PARISC_PCREL22F against undefined symbol `memset'
  /usr/bin/hppa64-linux-gnu-ld.bfd: o64/ccode32flat.o: in function `tpm20_write_EfiSpecIdEventStruct':
  ccode32flat.o.tmp.c:(.text+0x72d8): undefined reference to `memset'
  /usr/bin/hppa64-linux-gnu-ld.bfd: o64/ccode32flat.o(.text+0x72d8): cannot reach memset
  ccode32flat.o.tmp.c:(.text+0x72d8): relocation truncated to fit: R_PARISC_PCREL22F against undefined symbol `memset'
  /usr/bin/hppa64-linux-gnu-ld.bfd: ccode32flat.o.tmp.c:(.text+0x73a0): undefined reference to `memset'
  /usr/bin/hppa64-linux-gnu-ld.bfd: o64/ccode32flat.o(.text+0x73a0): cannot reach memset
  ccode32flat.o.tmp.c:(.text+0x73a0): relocation truncated to fit: R_PARISC_PCREL22F against undefined symbol `memset'

all these are about local variable assignments like the
above.  But adding memset() symbol to the command line
fails differently:

  hppa64-linux-gnu-ld -N -T o64/pafirmware.lds o64/head.o o64/version.o -X -o o64/hppa-firmware64.img -e startup \
     --as-needed o64/ccode32flat.o o64/src/string.o /usr/lib/gcc/hppa64-linux-gnu/16/libgcc.a

(note the added o64/src/string.o here).  Now it complains about multiple
definitions of memset!

  /usr/bin/hppa64-linux-gnu-ld.bfd: o64/src/string.o: in function `memcpy':
  /build/pkg/build/b/hppa-fw/src/string.c:171: multiple definition of `memcpy'; \
   o64/ccode32flat.o:/build/pkg/build/b/hppa-fw/./src/string.c:171: first defined here

So the symbol is actually there, but somehow the linker can't find
it if the reference is made by gcc itself.

hmm..

/mjt

was gcc-defaults-ports pointing to 16 used for that build?

was gcc-defaults-ports pointing to 16 used for that build?

Yes, it was, initially.  However, exactly the same problem exists on powerpc and ppc64
platforms with native gcc.  This is why I reassigned it from ports to gcc-16.

Thanks,

/mjt

We believe that the bug you reported is fixed in the latest version of
qemu, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1143807@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Tokarev <mjt@tls.msk.ru> (supplier of updated qemu package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 13 Aug 2026 09:16:49 +0300
Source: qemu
Architecture: source
Version: 1:11.1.0+ds-1
Distribution: unstable
Urgency: medium
Maintainer: Debian QEMU Team <pkg-qemu-devel@lists.alioth.debian.org>
Changed-By: Michael Tokarev <mjt@tls.msk.ru>
Closes: 1143807
Changes:
 qemu (1:11.1.0+ds-1) unstable; urgency=medium
 .
   * new major upstream release, with the following security issues fixed:
     o CVE-2026-6502: Use-after-free within the virtio-gpu subsystem
     o CVE-2026-8348: Host memory exhaustion in 9pfs by limiting xattr fids
     o CVE-2026-9238: DoS in 9pfs via uncapped Treaddir allocation
     o CVE-2026-16457: Infinite loop in virtio_queue_empty() when evaluating
       packed vrings
https://gitlab.com/qemu-project/qemu/-/work_items/3968
     o CVE-2026-50626: OOB memory access in virtio-mmio transport mechanism
https://gitlab.com/qemu-project/qemu/-/work_items/3882
https://gitlab.com/qemu-project/qemu/-/work_items/3921
https://gitlab.com/qemu-project/qemu/-/work_items/3923
https://gitlab.com/qemu-project/qemu/-/work_items/3613
     o CVE-2026-63318: Read-only export bypass via O_TRUNC in 9pfs
https://gitlab.com/qemu-project/qemu/-/work_items/4000
     o CVE-2026-63319: Infinite loop or crash trigger in the usb-redir device
https://gitlab.com/qemu-project/qemu/-/work_items/3995
     o CVE-2026-66021: OOB read via DMA buffers in virtio-gpu blob handling
https://gitlab.com/qemu-project/qemu/-/work_items/3945
   * rules: do git checkout on vdso files on clean, if .git is present
   * gbp.conf, d/watch: switch to 11.1
   * patches/: remove 4 now-unused patches
   * patches/: refresh gnu-hurd.patch riscv-on-ppc64-gcc15-121689.patch
   * control: add gcc-sh4-linux-gnu & libc6-dev-sh4-cross to build-deps
     for sh4 vdso
   * rules: export cross_prefix_sh4 for sh4 vdso files
   * rules: specify compiler to build sh4eb vdso
   * control.mk: add 2 vdso files for sh4; set vdso-version to 11.1.0~
   * control.mk: checked-version := 11.1.0+ds
   * control,rules: remove glusterfs (removed upstream)
   * qemu-block-extra.NEWS: add a note about glusterfs remvoval
   * control.mk: add qemu-system-hexagon to qemu-system-misc
   * rules: remove --as-needed linker flag (it is enabled by default)
   * control: remove Priority: optional and Rules-Requires-Root: no
     (these are the default now)
   * control: Standards-Version: 4.7.4
   * control: drop oss4-dev (does not exist anymore)
   * lintian-overrdies
   * u-boot-cmd_process-fix-return-type.diff
   * seabios-hppa-work-around-1143851.diff: work around gcc-hppa bug #1143851
   * openbios-no-error-unused-but-set-variable.diff
   * work-around -Wa,-many issue by adding local gcc override to b/bin/
     (Closes: #1143807)
Checksums-Sha1:
 43078c8b380f0dbe49fe41ad602cadda07102205 9922 qemu_11.1.0+ds-1.dsc
 320b6a3da46bfb0f79072d4f9ba635fd8d1a87ee 39209148 qemu_11.1.0+ds.orig.tar.xz
 dd686b7c165df3f93b4f02d2d34ad009a9695383 129688 qemu_11.1.0+ds-1.debian.tar.xz
 bff7b250e79baf4be55fb94e7ba6d10ea3eb7bb9 7849 qemu_11.1.0+ds-1_source.buildinfo
Checksums-Sha256:
 8fea8073d92c733bd023b51ca3fe9f4364cbad2143226ef62a20dee6653c3fd5 9922 qemu_11.1.0+ds-1.dsc
 1bda0f7c9298e24e9b40bebb257e61d6e017d5dca425caa5e385dea4b43ce9fc 39209148 qemu_11.1.0+ds.orig.tar.xz
 71b95687550a25d3485b25f55897cb6469619714280fcec3131bb241669c47c4 129688 qemu_11.1.0+ds-1.debian.tar.xz
 b6f33961e781798ed90915b90ff55dacc7fea8b763abd508ae5520fc25e8d92e 7849 qemu_11.1.0+ds-1_source.buildinfo
Files:
 51289eddd1df354273cb6e162075afbc 9922 otherosfs optional qemu_11.1.0+ds-1.dsc
 f22b33b7d715ebcdeb5a5cf98d522c50 39209148 otherosfs optional qemu_11.1.0+ds.orig.tar.xz
 98dbe23b53794a9fc51063e49473c7b5 129688 otherosfs optional qemu_11.1.0+ds-1.debian.tar.xz
 4adf5c963f8836a48736e4509983bd11 7849 otherosfs optional qemu_11.1.0+ds-1_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZKoqtTHVaQM2a/75gqpKJDselHgFAmp9bJAACgkQgqpKJDse
lHhJhg/9EzBRBdBFtIyKD4tcroSb7Ol5UjoPKY+fgSZrI4t3S1zt6R2Au0SUF7bP
m88sCEuLf7w5qcreaDU8N5qz5J47gJk7Ck9ev0Lr1dn3WjPqnlAlWW4zGNZJq/AG
laLGOn6NxNNuIzjuo+I113vGMoBjo/ElzRle6Am9PVluWg5Ni7qSagK6NrFjyn4X
DedLXoJ/fx0tslD8neAOYWVkyxVcw6BpRDld2RRvqzn0cxwZDRz1EZAdHqqt9jHl
5a+n+0um5AvRT4zaMericYTEN3RMTcTo9SuogeyceqMqCHJ75Cb3Qk2ppdtaBZkr
j4Jo6YcxVDMbAwbCtBsFWxKAB8RMMAJf6LwEPXuwOtagpt07vxyjpd1VKzzg0oA7
VOGX8L5xi38ewhEJsKV3yYXrNfvoK7K6oTTKT31JKgflx4cqaQsBLnrMG2OIJE4U
7tZ/W+W+PsOw1f1rmHZ543jX2AO7JS8JtJTEXY2DVlXa63MEaaAZPKt1785mXO07
qgwywjiMUTVtjqTXFKZmbBULWfsZOZCghb64eQaKF9OZamJmvtR7c7OhKE3wxIuL
3HZUeAM0NweXnlfB1Ix9yqDAtUH6JzRXcpIvK0ho1oXWnN+uwwOob00bizsLOwEv
rdtPeihbhq14aE48YAlts2FxUmttLVzAkEpq2YS8IDoSHgA/MSc=
=NLEd
-----END PGP SIGNATURE-----

which command exactly fails? maybe show that with gcc -v to also show
the assembler invocations.