[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [platform-testers] GNU MPFR 4.1.0 Release Candidate

From: Nelson H. F. Beebe
Subject: Re: [platform-testers] GNU MPFR 4.1.0 Release Candidate
Date: Sat, 13 Jun 2020 15:43:47 -0600

Over the last month, I have added QEMU emulated VMs for some less
common CPU types that I have used in the past, or plan to in the
future.  Some of them are reported on below.

For temporary local technical reasons, I could not run tests of
mpfr-4.1.0-rc1 on several hundred systems, as I usually do.  Instead,
I did manual builds with gcc, and where available, clang, on several
different CPU architectures.  Here are one-line summaries of each

Debian 10.4 32-bit MIPS 24kc Malta:     # TOTAL: 183    # PASS:  180    # SKIP: 

Debian 10.4 POWER9 little-endian:       # TOTAL: 183    # PASS:  183    # SKIP: 
 0                      [gcc 8.3.0]
                                        # TOTAL: 183    # PASS:  179    # SKIP: 
 3      # FAIL:  1      [clang 8.0.1]

Debian 11.0 ARM64 (aarch64 Cortex-A57)  # TOTAL: 183    # PASS:  181    # SKIP: 
 2                      [gcc 9.3.0]
                                        # TOTAL: 183    # PASS:  180    # SKIP: 
 3                      [clang 10.0.0]

Fedora 32 (Rawhide) RISC-V64:           # TOTAL: 183    # PASS:  181    # SKIP: 
 2                      [gcc 10.0.1]
Linux Mint 20 x86_64:                   # TOTAL: 183    # PASS:  183            
                        [gcc 9.3.0]
                                        # TOTAL: 183    # PASS:  181    # SKIP: 
 2                      [clang 10.0.0]

Ubuntu 18.04 S/390 (IBM zSeries)        # TOTAL: 183    # PASS:  181    # SKIP: 
 2                      [gcc 7.5.0]

Ubuntu 20.04 x86_64:                    # TOTAL: 183    # PASS:  183            
                        [gcc 9.3.0]
                                        # TOTAL: 183    # PASS:  181    # SKIP: 
 2                      [clang 10.0.0]
CentOS 7.7.1908 x86_64:                 # TOTAL: 18     # PASS:  182    # SKIP: 
 0      # FAIL:  1      [gcc-4.8.5]
                                        # TOTAL: 183    # PASS:  179    # SKIP: 
 3      # FAIL:  1      [clang 3.4.2]
                                        # TOTAL: 183    # PASS:  180    # SKIP: 
 2      # FAIL:  1      [clang 7.1.0]

Solaris 10 SPARC:                       # TOTAL: 183    # PASS:  179    # SKIP: 
 4                      [gcc 3.4.6]

Here is a summary of the skipped tests:

        % grep '^SKIP' T* | awk '{print $NF}' | sort | uniq -c
              1 talloc
             12 tget_set_d128
             12 tget_set_d64
              6 tset_float128

The failing tests are

        CentOS 7:               tversion (all three builds)
        Debian 10.4 POWER9:     tdigamma

The POWER9 tdigamma.log reports:

        [MPFR] tests_addsize(): too much memory (4202008 bytes)
        FAIL tdigamma (exit status: 134)

That VM has 1 CPU, 1GB DRAM, and 80GB disk, which is my standard VM
configuration, except in rare cases, and for ZFS, which generally need
at least 2GB or 4GB DRAM to run reliably. The POWER9 VM has only an
EXT4 filesystem.


(1) Of the test build systems, MIPS 24Kc, S/390, and SPARC are
    big-endian; the others are all little-endian.  There HAVE been O/S
    distributions for big-endian POWER systems, and IBM AIX was always
    big-endian, but every such distribution that I located a URL for
    has disappeared off the Web, and is not found on the Wayback
    Machine, either.

(2) clang on RISC-V64 will not compile anything because of a missing
    <gnu/stubs-lp64.h> header file; it should be in
    glibc-{dev,headers} (as on other systems), but is not in those
    packages, and a file search with rpm cannot find the missing file.

(3) Linux Mint 20 beta was released just yesterday (based on Ubuntu
    20.04, but with no ZFS support, just EXT4).

(4) On S/390, a build attempt with clang crashed the VM during the
    configure runs.  I can even do that with clang compilation of a
    simple hello.c file.  With gcc, I have built several large
    software packages, but I have also been able to crash the VM with
    simple code.  I tried running gdb on the a.out file that causes
    the crash, but it steps through to completion without failure.
    Running the same ./a.out separately instantly powers the VM off.

    This could be an Ubuntu Linux kernel issue, or a QEMU S/390
    emulator issue.  My physical Dell Precision 7920 workstation
    running Ubuntu 20.04 has QEMU emulator version 4.2.0, but version
    5.0.0 is now available, so I may try to do a separate build of
    that version, and then see whether I can run the VM with it.

    I have also tried building Debian 8.10.0 and 10.4.0 S/390 VMs, but
    found that they boot partway, then hang without further progress.

    I have installer DVDs for Ubuntu 19.10 S/390, but they are older
    than the 18.04 that I eventually got a running VM for, so I have
    not (yet) used them to build an S/390 VM.  Ubuntu 20.04
    (officially released in April 2020, but running here in beta
    releases since 26-Oct-2019) does not yet have S/390 DVDs.  I
    temporarily cannot reach several other VMs running Ubuntu family
    versions 19.04 and 19.10 to see what version of QEMU they have.

    On S/390 Linux, both gcc and clang contain code generators and
    language support ONLY for IEEE 754 arithmetic; the historical
    S/360 hexadecimal arithmetic, which is otherwise well supported by
    IBM hardware, and by QEMU, including 32-bit and 64-bit FMA
    instructions, is completely inaccessible with those compilers.  I
    view that as regrettable, even if the IEEE 754 formats are
    preferred for most modern software.

- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail:  -
- 155 S 1400 E RM 233              -
- Salt Lake City, UT 84112-0090, USA    URL: -

reply via email to

[Prev in Thread] Current Thread [Next in Thread]