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