Summary: | test failure on powerpc-linux-gnu | ||
---|---|---|---|
Product: | binutils | Reporter: | Efraim Flashner <efraim> |
Component: | binutils | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED MOVED | ||
Severity: | normal | CC: | efraim, nickc |
Priority: | P2 | ||
Version: | 2.36 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Attachments: |
signature.asc
signature.asc signature.asc |
Description
Efraim Flashner
2021-04-18 09:44:21 UTC
Hi Efraim, I am unable to reproduce these failures. (As in, when I run the libiberty testsuite from the 2.36 branch, all of the tests pass). I suppose in theory it could be related to the version of gcc you are using to build libiberty.a. I am using gcc 10.2.1 from Fedora 32. Do you have a copy of the gcc sources available ? If so, can you try running the libiberty testsuite from a build of those sources and see if it produces similar results. Cheers Nick Created attachment 13383 [details] signature.asc On Mon, Apr 19, 2021 at 02:51:30PM +0000, nickc at redhat dot com wrote: > Hi Efraim, > > I am unable to reproduce these failures. (As in, when I run the libiberty > testsuite from the 2.36 branch, all of the tests pass). > > I suppose in theory it could be related to the version of gcc you are using > to build libiberty.a. I am using gcc 10.2.1 from Fedora 32. > > Do you have a copy of the gcc sources available ? If so, can you try running > the libiberty testsuite from a build of those sources and see if it produces > similar results. > > Cheers > Nick > I ran the tests a couple of times. The first time I tested the libiberty from 10.4.0, 8.4.0 and 5.5.0 using Debian's gcc, 10.2.1. In all of those the tests all passed. Then I ran it again using the gcc I used when the tests failed, a statically linked gcc-5.5.0, using the saved environment from the reported failure. Again all the tests passed in all the gcc libiberty versions. (I realize that rust-test-demangle isn't in gcc-5.) I then downloaded a fresh copy of binutils-2.36.1 and ran the test suite for libiberty there using Debian's gcc-10.2.1. (ins)efraim@g4:~/workspace/binutils-2.36.1/libiberty$ make check make[1]: Entering directory '/home/efraim/workspace/binutils-2.36.1/libiberty/testsuite' gcc -DHAVE_CONFIG_H -g -O2 -I.. -I./../../include -o test-demangle \ ./test-demangle.c ../libiberty.a ./test-demangle < ./demangle-expected ./test-demangle: 347 tests, 0 failures ./test-demangle < ./d-demangle-expected ./test-demangle: 350 tests, 0 failures ./test-demangle < ./rust-demangle-expected FAIL at line 222, options --format=rust: in: _RMCs4fqI2P2rA04_13const_genericINtB0_4CharKc76_E out: <const_generic::Char<' exp: <const_generic::Char<'v'>> FAIL at line 285, options --format=auto: in: _RMCs4fqI2P2rA04_13const_genericINtB0_4CharKc76_E out: <const_generic::Char<' exp: <const_generic::Char<'v'>> ./test-demangle: 68 tests, 2 failures make[1]: *** [Makefile:58: check-rust-demangle] Error 1 make[1]: Leaving directory '/home/efraim/workspace/binutils-2.36.1/libiberty/testsuite' make: *** [Makefile:504: check-subdir] Error 2 (In reply to Efraim Flashner from comment #2) Hi Efraim, > I then downloaded a fresh copy of binutils-2.36.1 and ran the test suite > for libiberty there using Debian's gcc-10.2.1. > > (ins)efraim@g4:~/workspace/binutils-2.36.1/libiberty$ make check > make[1]: Entering directory > '/home/efraim/workspace/binutils-2.36.1/libiberty/testsuite' > gcc -DHAVE_CONFIG_H -g -O2 -I.. -I./../../include -o test-demangle \ > ./test-demangle.c ../libiberty.a [...] > ./test-demangle < ./rust-demangle-expected > FAIL at line 222, options --format=rust: I tried the same using Fedora's gcc-10.2.1-9.fc32.x86_64: % make check make[1]: Entering directory '/dev/shm/delme/build/libiberty/testsuite' gcc -DHAVE_CONFIG_H -g -O2 -I.. -I../../../binutils-2.36.1/libiberty /testsuite/../../include -o test-demangle \ ../../../binutils-2.36.1/libiberty/testsuite/test-demangle.c ../libiberty.a [...] ./test-demangle < ../../../binutils-2.36.1/libiberty/testsuite/rust-demangle-expected ./test-demangle: 68 tests, 0 failures Maybe it is a host problem. What kind of host machine are you using ? Cheers Nick Created attachment 13390 [details] signature.asc On Tue, Apr 20, 2021 at 01:55:47PM +0000, nickc at redhat dot com wrote: > I tried the same using Fedora's gcc-10.2.1-9.fc32.x86_64: > > % make check > make[1]: Entering directory '/dev/shm/delme/build/libiberty/testsuite' > gcc -DHAVE_CONFIG_H -g -O2 -I.. -I../../../binutils-2.36.1/libiberty > /testsuite/../../include -o test-demangle \ > ../../../binutils-2.36.1/libiberty/testsuite/test-demangle.c > ../libiberty.a > [...] > ./test-demangle < > ../../../binutils-2.36.1/libiberty/testsuite/rust-demangle-expected > ./test-demangle: 68 tests, 0 failures > > Maybe it is a host problem. What kind of host machine are you using ? (ins)efraim@g4:~$ neofetch --stdout efraim@g4 --------- OS: Debian GNU/Linux 11 (bullseye) ppc Host: PowerBook6,7 Kernel: 5.10.0-4-powerpc Uptime: 24 days, 23 hours, 25 mins Packages: 1779 (dpkg) Shell: bash 5.1.4 Resolution: 1024x768 CPU: 7447A (1) @ 1.420GHz GPU: AMD ATI Mobility Radeon 9550 Memory: 326MiB / 1504MiB I have experimented with pkgsrc on this machine in the past but nothing is sourced in my .bashrc. I have some guile libraries in /usr/local and I'm working on porting Guix but nothing installed from it currently. (In reply to Efraim Flashner from comment #4) > CPU: 7447A (1) @ 1.420GHz So, a 32-bit powerpc. Maybe this is a 32-bit vs 64-bit problem. Do you have access to any other type of machine that you could use for testing ? Cheers Nick It's most likely an endian bug. The same failure happens on ppc, ppc64, s390x, m68k. This is obvious: static void demangle_const_char (struct rust_demangler *rdm) { size_t hex_len; uint64_t value; // .... else if (value > ' ' && value < '~') /* Rust also considers many non-ASCII codepoints to be printable, but that logic is not easily ported to C. */ print_str (rdm, (char *) &value, 1); Created attachment 13392 [details] signature.asc On Tue, Apr 20, 2021 at 02:38:48PM +0000, nickc at redhat dot com wrote: > (In reply to Efraim Flashner from comment #4) > > > CPU: 7447A (1) @ 1.420GHz > > So, a 32-bit powerpc. Maybe this is a 32-bit vs 64-bit problem. > > Do you have access to any other type of machine that you could use for testing? I've run through the build and test suite using Guix on x86_64, aarch64 and ppc64le and on aarch64 on Debian (all passed). I have an RPi-1 floating around somewhere, I found the SD card with Debian armel on it but I'm not sure where the board went off to. I also might still have a 32-bit desktop I haven't powered on in a few years running Debian I can test. Right, using an s390 host I was able to reproduce the problem, both using the binutils 2.36.1 libiberty sources and the current gcc mainline libiberty sources. So now that I know that the bug is real I have refiled it with gcc, since they are the official maintainers of the libiberty library: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100177 |