Debian Bug report logs - #972789
qemu: FTBFS on arm{el,hf}: /<<PKGBUILDDIR>>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is not compatible

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Sebastian Ramacher <sramacher@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: qemu: FTBFS on arm{el,hf}: /<<PKGBUILDDIR>>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is not compatible

Date: Fri, 23 Oct 2020 18:50:42 +0200

[Message part 1 (text/plain, inline)]

Source: qemu
Version: 1:5.1+dfsg-4
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)

binNMUs of qemu for the libbrlapi transition failed to build on armel
and armhf:
| cc -iquote /<<PKGBUILDDIR>>/b/qemu/linux-user/m68k -iquote linux-user/m68k -iquote /<<PKGBUILDDIR>>/tcg/arm -isystem /<<PKGBUILDDIR>>/linux-headers -isystem /<<PKGBUILDDIR>>/b/qemu/linux-headers -iquote . -iquote /<<PKGBUILDDIR>> -iquote /<<PKGBUILDDIR>>/accel/tcg -iquote /<<PKGBUILDDIR>>/include -iquote /<<PKGBUILDDIR>>/disas/libvixl -I/usr/include/pixman-1   -pthread -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -fPIE -DPIE  -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99  -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -I/usr/include/p11-kit-1  -DSTRUCT_IOVEC_DEFINED  -I/usr/include/libpng16  -I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/capstone -isystem ../linux-headers -iquote .. -iquote /<<PKGBUILDDIR>>/target/m68k -DNEED_CPU_H -iquote /<<PKGBUILDDIR>>/include -I/<<PKGBUILDDIR>>/linux-user/m68k -I/<<PKGBUILDDIR>>/linux-user/host/arm -I/<<PKGBUILDDIR>>/linux-user -Ilinux-user/m68k -MMD -MP -MT linux-user/m68k/signal.o -MF linux-user/m68k/signal.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g   -c -o linux-user/m68k/signal.o /<<PKGBUILDDIR>>/linux-user/m68k/signal.c
| /<<PKGBUILDDIR>>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is not compatible
|    44 | };
|       | ^
|  <array_type 0xb5b48ba0
|     type <integer_type 0xb6f94420 unsigned int asm_written public unsigned SI
|         size <integer_cst 0xb692ee58 constant 32>
|         unit-size <integer_cst 0xb692ee70 constant 4>
|         align:32 warn_if_not_align:0 symtab:-1229976864 alias-set -1 canonical-type 0xb6f94420 precision:32 min <integer_cst 0xb693f0f0 0> max <integer_cst 0xb693f0d8 4294967295>
|         pointer_to_this <pointer_type 0xb6944ba0>>
|     SI size <integer_cst 0xb692ee58 32> unit-size <integer_cst 0xb692ee70 4>
|     align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb5b48ba0
|     domain <integer_type 0xb676d6c0
|         type <integer_type 0xb6f94060 sizetype public unsigned SI size <integer_cst 0xb692ee58 32> unit-size <integer_cst 0xb692ee70 4>
|             align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb6f94060 precision:32 min <integer_cst 0xb692ee88 0> max <integer_cst 0xb692e000 4294967295>>
|         SI size <integer_cst 0xb692ee58 32> unit-size <integer_cst 0xb692ee70 4>
|         align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb676d6c0 precision:32 min <integer_cst 0xb692ee88 0> max <integer_cst 0xb692ee88 0>>>
| /<<PKGBUILDDIR>>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_MODE’ of ‘TYPE_CANONICAL’ is not compatible
|  <array_type 0xb5b48ba0
|     type <integer_type 0xb6f94420 unsigned int asm_written public unsigned SI
|         size <integer_cst 0xb692ee58 constant 32>
|         unit-size <integer_cst 0xb692ee70 constant 4>
|         align:32 warn_if_not_align:0 symtab:-1229976864 alias-set -1 canonical-type 0xb6f94420 precision:32 min <integer_cst 0xb693f0f0 0> max <integer_cst 0xb693f0d8 4294967295>
|         pointer_to_this <pointer_type 0xb6944ba0>>
|     SI size <integer_cst 0xb692ee58 32> unit-size <integer_cst 0xb692ee70 4>
|     align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb5b48ba0
|     domain <integer_type 0xb676d6c0
|         type <integer_type 0xb6f94060 sizetype public unsigned SI size <integer_cst 0xb692ee58 32> unit-size <integer_cst 0xb692ee70 4>
|             align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb6f94060 precision:32 min <integer_cst 0xb692ee88 0> max <integer_cst 0xb692e000 4294967295>>
|         SI size <integer_cst 0xb692ee58 32> unit-size <integer_cst 0xb692ee70 4>
|         align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb676d6c0 precision:32 min <integer_cst 0xb692ee88 0> max <integer_cst 0xb692ee88 0>>>
|  <array_type 0xb5b48b40
|     type <integer_type 0xb6054f00 abi_ulong asm_written public unsigned SI
|         size <integer_cst 0xb692ee58 constant 32>
|         unit-size <integer_cst 0xb692ee70 constant 4>
|         user align:16 warn_if_not_align:0 symtab:-1241131856 alias-set -1 canonical-type 0xb6f94420 precision:32 min <integer_cst 0xb693f0f0 0> max <integer_cst 0xb693f0d8 4294967295>
|         pointer_to_this <pointer_type 0xb5aaef60>>
|     no-force-blk BLK size <integer_cst 0xb692ee58 32> unit-size <integer_cst 0xb692ee70 4>
|     user align:16 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb5b48ba0
|     domain <integer_type 0xb676d6c0
|         type <integer_type 0xb6f94060 sizetype public unsigned SI size <integer_cst 0xb692ee58 32> unit-size <integer_cst 0xb692ee70 4>
|             align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb6f94060 precision:32 min <integer_cst 0xb692ee88 0> max <integer_cst 0xb692e000 4294967295>>
|         SI size <integer_cst 0xb692ee58 32> unit-size <integer_cst 0xb692ee70 4>
|         align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0xb676d6c0 precision:32 min <integer_cst 0xb692ee88 0> max <integer_cst 0xb692ee88 0>>>
| /<<PKGBUILDDIR>>/linux-user/m68k/signal.c:44:1: internal compiler error: ‘verify_type’ failed

See
https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=armhf&ver=1%3A5.1%2Bdfsg-4%2Bb1&stamp=1603242447&raw=0
for example

Cheers
-- 
Sebastian Ramacher

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 972789@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Sebastian Ramacher <sramacher@debian.org>, 972789@bugs.debian.org

Subject: Re: Bug#972789: qemu: FTBFS on arm{el,hf}: /<<PKGBUILDDIR>>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is not compatible

Date: Sat, 24 Oct 2020 07:38:39 +0300

23.10.2020 19:50, Sebastian Ramacher wrote:
> Source: qemu
> Version: 1:5.1+dfsg-4
> Severity: serious
> Tags: ftbfs sid bullseye
> Justification: fails to build from source (but built successfully in the past)

> binNMUs of qemu for the libbrlapi transition failed to build on armel
> and armhf:

> | /<<PKGBUILDDIR>>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is not compatible
> |    44 | };
> |       | ^

Hmm. So this looks like a gcc ICE bug. Here's the code in question:

struct target_sigframe
{
    abi_ulong pretcode;
    int sig;
    int code;
    abi_ulong psc;
    char retcode[8];
    abi_ulong extramask[TARGET_NSIG_WORDS-1];
    struct target_sigcontext sc;
};

...
> | /<<PKGBUILDDIR>>/linux-user/m68k/signal.c:44:1: internal compiler error: ‘verify_type’ failed

I'm not sure what I have to do with this, besides reassigning it to gcc.

BTW, symbol TYPE_CANONICAL is not used/referenced by qemu sources.

/mjt

Message #15 received at 972789@bugs.debian.org (full text, mbox, reply):

From: Sebastian Ramacher <sramacher@debian.org>

To: Michael Tokarev <mjt@tls.msk.ru>, 972789@bugs.debian.org

Cc: gcc-10@packages.debian.org

Subject: Re: Bug#972789: qemu: FTBFS on arm{el,hf}: /<<PKGBUILDDIR>>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is not compatible

Date: Wed, 28 Oct 2020 12:30:41 +0100

[Message part 1 (text/plain, inline)]

Control: reassign -1 gcc-10 10.2.0-15
Control: tags -1 upstream
Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97323
Control: affects -1 src:qemu

On 2020-10-24 07:38:39 +0300, Michael Tokarev wrote:
> 23.10.2020 19:50, Sebastian Ramacher wrote:
> > Source: qemu
> > Version: 1:5.1+dfsg-4
> > Severity: serious
> > Tags: ftbfs sid bullseye
> > Justification: fails to build from source (but built successfully in the past)
> 
> > binNMUs of qemu for the libbrlapi transition failed to build on armel
> > and armhf:
> 
> > | /<<PKGBUILDDIR>>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is not compatible
> > |    44 | };
> > |       | ^
> 
> Hmm. So this looks like a gcc ICE bug. Here's the code in question:
> 
> struct target_sigframe
> {
>     abi_ulong pretcode;
>     int sig;
>     int code;
>     abi_ulong psc;
>     char retcode[8];
>     abi_ulong extramask[TARGET_NSIG_WORDS-1];
>     struct target_sigcontext sc;
> };
> 
> ...
> > | /<<PKGBUILDDIR>>/linux-user/m68k/signal.c:44:1: internal compiler error: ‘verify_type’ failed
> 
> I'm not sure what I have to do with this, besides reassigning it to gcc.
> 
> BTW, symbol TYPE_CANONICAL is not used/referenced by qemu sources.

Indeed, that's a bug in gcc which was already reported upstream.
Reassigning accordingly.

Cheers
-- 
Sebastian Ramacher

[signature.asc (application/pgp-signature, inline)]

Message #32 received at 972789@bugs.debian.org (full text, mbox, reply):

From: Matthias Klose <doko@debian.org>

To: 975219@bugs.debian.org, 975153@bugs.debian.org, 974073@bugs.debian.org, 975142@bugs.debian.org, 972789@bugs.debian.org

Subject: lowering severity

Date: Sat, 28 Nov 2020 12:00:23 +0100

Control: severity 975153 important
Control: severity 975219 important
Control: severity 974073 important
Control: severity 972789 important
Control: severity 975142 important

compiler is now built again with release checkings enabled.

Message #39 received at 972789@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: 972789@bugs.debian.org

Subject: Re: Bug#972789: qemu: FTBFS on arm{el,hf}: /<<PKGBUILDDIR>>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is not compatible

Date: Thu, 10 Dec 2020 00:59:57 +0300

On Wed, 28 Oct 2020 12:30:41 +0100 Sebastian Ramacher <sramacher@debian.org> wrote:
> On 2020-10-24 07:38:39 +0300, Michael Tokarev wrote:
...
> > Hmm. So this looks like a gcc ICE bug. Here's the code in question:
> > ...
> > > | /<<PKGBUILDDIR>>/linux-user/m68k/signal.c:44:1: internal compiler error: ‘verify_type’ failed
> > 
> > I'm not sure what I have to do with this, besides reassigning it to gcc.
> > 
> > BTW, symbol TYPE_CANONICAL is not used/referenced by qemu sources.
> 
> Indeed, that's a bug in gcc which was already reported upstream.
> Reassigning accordingly.

I dunno what happened, either it was new gcc or new qemu, but this issue
is gone - as of today's upload of qemu 5.2 it built successfully on both
armhf and armel.

Guess we can close this bugreport, what do you think?

/mjt

Message #44 received at 972789-done@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: 972789-done@bugs.debian.org

Subject: Re: Bug#972789: qemu: FTBFS on arm{el,hf}: /<<PKGBUILDDIR>>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is not compatible

Date: Tue, 9 Mar 2021 13:40:48 +0300

On Fri, 23 Oct 2020 18:50:42 +0200 Sebastian Ramacher <sramacher@debian.org> wrote:
> Source: qemu
> Version: 1:5.1+dfsg-4
> Severity: serious
> Tags: ftbfs sid bullseye
> Justification: fails to build from source (but built successfully in the past)

Since some version of gcc-10 this issue stopped appearing.
Closing this bugreport now.

If you think this is incorrect, fell free to reopen it.

Thanks,

/mjt

Send a report that this bug log contains spam.