Bug#973443: src/init2.c:52: MPFR assertion failure

2020-10-30 Thread Vincent Lefevre
On 2020-10-30 13:34:31 -0400, John Scott wrote:
> I was fooling around with Arb and it seems that this program causes
> an assertion failure in MPFR, although ASan and UBSan don't point to
> any misusage by Arb. (Curiously if you change the numerical string
> from "0" to "0.5" then Arb does segfault outright, but I think that's
> unrelated.)
> 
> One can build the program below with -lflint-arb to link:
> #include 
> #include 
> int main(void) {
> arb_t x;
> arb_init(x);
> if(arb_set_str(x, "0", WORD_MAX)) {
> exit(EXIT_FAILURE);
> } else {
> arb_printd(x, WORD_MAX);
> arb_clear(x);
> }
> }
> 
> and this causes
> ../../src/init2.c:52: MPFR assertion failed: ((p) >= 1 && (p) <= 
> ((mpfr_prec_t) mpfr_uprec_t) -1) >> 1) - 256)))
> Aborted

This is not a MPFR bug: a precision that is larger than MPFR_PREC_MAX
is provided. In the MPFR manual:

   The “precision” is the number of bits used to represent the
significand of a floating-point number; the corresponding C data type is
‘mpfr_prec_t’.  The precision can be any integer between ‘MPFR_PREC_MIN’
and ‘MPFR_PREC_MAX’.  In the current implementation, ‘MPFR_PREC_MIN’ is
equal to 1.

   Warning!  MPFR needs to increase the precision internally, in order
to provide accurate results (and in particular, correct rounding).  Do
not attempt to set the precision to any value near ‘MPFR_PREC_MAX’,
otherwise MPFR will abort due to an assertion failure.  However, in
practice, the real limitation will probably be the available memory on
your platform, and in case of lack of memory, the program may abort,
crash or have undefined behavior (depending on your C implementation).

> It seems this is related to the WORD_MAX limit in arb_printd(). Replacing
> it with WORD_MAX/8 one gets (in GMP)
> GNU MP: Cannot allocate memory (size=479903576292600072)
> Aborted

This time, I assume that the MPFR precision is less than MPFR_PREC_MAX,
but this is still much too large for the available memory.

This looks like a user-side error. I suppose that in arb, WORD_MAX
is a technical limitation (like MPFR_PREC_MAX in MPFR), but other
limitations may be reached in practice (on 64-bit machines, the
available memory should be the real limitation, though various
technical limitations may be reached before you get an error on
the available memory).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Results for 10.2.0 (Debian 10.2.0-16) testsuite on s390x-ibm-linux-gnu

2020-10-30 Thread Matthias Klose
LAST_UPDATED: Obtained from git: releases/gcc-10.2.0 revision 
ee5c3db6c5b2c3332912fb4c9cfa2864569ebd9a

=== acats tests ===

=== acats Summary ===
# of expected passes2320
# of unexpected failures0
Native configuration is s390x-ibm-linux-gnu

=== g++ tests ===


Running target unix
FAIL: c-c++-common/asan/global-overflow-1.c   -O2  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -O3 -g  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -Os  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  output pattern test
FAIL: g++.dg/asan/function-argument-3.C   -O0  execution test
FAIL: g++.dg/asan/function-argument-3.C   -O1  output pattern test
FAIL: g++.dg/asan/function-argument-3.C   -O2  output pattern test
FAIL: g++.dg/asan/function-argument-3.C   -O3 -g  output pattern test
FAIL: g++.dg/asan/function-argument-3.C   -Os  output pattern test
FAIL: g++.dg/asan/function-argument-3.C   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  output pattern test
FAIL: g++.dg/asan/function-argument-3.C   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  output pattern test
FAIL: g++.dg/asan/large-func-test-1.C   -O2  output pattern test
FAIL: g++.dg/asan/large-func-test-1.C   -O3 -g  output pattern test
FAIL: g++.dg/asan/large-func-test-1.C   -Os  output pattern test
FAIL: g++.dg/asan/large-func-test-1.C   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  output pattern test
FAIL: g++.dg/asan/large-func-test-1.C   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/Wattributes.c  -std=gnu++98  (test for errors, line 404)
FAIL: c-c++-common/Wattributes.c  -std=gnu++14  (test for errors, line 404)
FAIL: c-c++-common/Wattributes.c  -std=gnu++17  (test for errors, line 404)
FAIL: c-c++-common/Wattributes.c  -std=gnu++2a  (test for errors, line 404)
FAIL: g++.dg/gomp/tls-5.C  -std=c++14  scan-assembler-not .data
FAIL: g++.dg/gomp/tls-5.C  -std=c++17  scan-assembler-not .data
FAIL: g++.dg/gomp/tls-5.C  -std=c++2a  scan-assembler-not .data
FAIL: g++.dg/guality/pr55665.C   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  line 23 p == 40
FAIL: g++.dg/tls/thread_local7.C  -std=c++14  scan-assembler-not .data
FAIL: g++.dg/tls/thread_local7.C  -std=c++17  scan-assembler-not .data
FAIL: g++.dg/tls/thread_local7.C  -std=c++2a  scan-assembler-not .data
FAIL: g++.dg/tls/thread_local7g.C  -std=c++14  scan-assembler-not .data
FAIL: g++.dg/tls/thread_local7g.C  -std=c++17  scan-assembler-not .data
FAIL: g++.dg/tls/thread_local7g.C  -std=c++2a  scan-assembler-not .data

=== g++ Summary for unix ===

# of expected passes190485
# of unexpected failures31
# of expected failures  709
# of unsupported tests  8679

Running target unix/-fstack-protector
FAIL: c-c++-common/asan/global-overflow-1.c   -O2  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -O3 -g  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -Os  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  output pattern test
FAIL: c-c++-common/asan/global-overflow-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  output pattern test
FAIL: g++.dg/asan/function-argument-3.C   -O0  execution test
FAIL: g++.dg/asan/function-argument-3.C   -O1  output pattern test
FAIL: g++.dg/asan/function-argument-3.C   -O2  output pattern test
FAIL: g++.dg/asan/function-argument-3.C   -O3 -g  output pattern test
FAIL: g++.dg/asan/function-argument-3.C   -Os  output pattern test
FAIL: g++.dg/asan/function-argument-3.C   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  output pattern test
FAIL: g++.dg/asan/function-argument-3.C   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  output pattern test
FAIL: g++.dg/asan/large-func-test-1.C   -O2  output pattern test
FAIL: g++.dg/asan/large-func-test-1.C   -O3 -g  output pattern test
FAIL: g++.dg/asan/large-func-test-1.C   -Os  output pattern test
FAIL: g++.dg/asan/large-func-test-1.C   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  output pattern test
FAIL: g++.dg/asan/large-func-test-1.C   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  output pattern test
FAIL: c-c++-common/Wattributes.c  -std=gnu++98  (test for errors, line 404)
FAIL: c-c++-common/Wattributes.c  -std=gnu++14  (test for errors, line 404)
FAIL: c-c++-common/Wattributes.c  -std=gnu++17  (test for errors, line 404)
FAIL: c-c++-common/Wattributes.c  -std=gnu++2a  (test for errors, line 404)
FAIL: g++.dg/gomp/tls-5.C  -std=c++14  scan-assembler-not .data
FAIL: g++.dg/gomp/tls-5.C  -std=c++17  scan-assembler-not .data
FAIL: 

Results for 10.2.0 (Debian 10.2.0-16) testsuite on i686-pc-linux-gnu

2020-10-30 Thread Matthias Klose
LAST_UPDATED: Obtained from git: releases/gcc-10.2.0 revision 
ee5c3db6c5b2c3332912fb4c9cfa2864569ebd9a

=== acats tests ===

=== acats Summary ===
# of expected passes2320
# of unexpected failures0
Native configuration is i686-pc-linux-gnu

=== brig tests ===


Running target unix

=== brig Summary ===

# of unsupported tests  1
=== g++ tests ===


Running target unix
FAIL: g++.dg/abi/anon1.C  -std=c++98  scan-assembler-not globl
FAIL: g++.dg/abi/anon1.C  -std=c++14  scan-assembler-not globl
FAIL: g++.dg/abi/anon1.C  -std=c++17  scan-assembler-not globl
FAIL: g++.dg/abi/anon1.C  -std=c++2a  scan-assembler-not globl
FAIL: g++.dg/abi/anon4.C  -std=c++98  scan-assembler-not comdat
FAIL: g++.dg/abi/anon4.C  -std=c++14  scan-assembler-not comdat
FAIL: g++.dg/abi/anon4.C  -std=c++17  scan-assembler-not comdat
FAIL: g++.dg/abi/anon4.C  -std=c++2a  scan-assembler-not comdat
FAIL: g++.dg/pr71694.C  -std=gnu++98  scan-assembler-not movl
FAIL: g++.dg/pr71694.C  -std=gnu++14  scan-assembler-not movl
FAIL: g++.dg/pr71694.C  -std=gnu++17  scan-assembler-not movl
FAIL: g++.dg/pr71694.C  -std=gnu++2a  scan-assembler-not movl
FAIL: g++.dg/stackprotectexplicit2.C  -std=gnu++98  scan-assembler-times 
stack_chk_fail 2
FAIL: g++.dg/stackprotectexplicit2.C  -std=gnu++14  scan-assembler-times 
stack_chk_fail 2
FAIL: g++.dg/stackprotectexplicit2.C  -std=gnu++17  scan-assembler-times 
stack_chk_fail 2
FAIL: g++.dg/stackprotectexplicit2.C  -std=gnu++2a  scan-assembler-times 
stack_chk_fail 2
FAIL: g++.dg/guality/pr55665.C   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  line 23 p == 40
FAIL: g++.dg/ubsan/vla-1.C   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects 
 execution test

=== g++ Summary for unix ===

# of expected passes190660
# of unexpected failures18
# of expected failures  705
# of unsupported tests  7953

Running target unix/-fstack-protector
FAIL: g++.dg/abi/anon1.C  -std=c++98  scan-assembler-not globl
FAIL: g++.dg/abi/anon1.C  -std=c++14  scan-assembler-not globl
FAIL: g++.dg/abi/anon1.C  -std=c++17  scan-assembler-not globl
FAIL: g++.dg/abi/anon1.C  -std=c++2a  scan-assembler-not globl
FAIL: g++.dg/abi/anon4.C  -std=c++98  scan-assembler-not comdat
FAIL: g++.dg/abi/anon4.C  -std=c++14  scan-assembler-not comdat
FAIL: g++.dg/abi/anon4.C  -std=c++17  scan-assembler-not comdat
FAIL: g++.dg/abi/anon4.C  -std=c++2a  scan-assembler-not comdat
FAIL: g++.dg/pr71694.C  -std=gnu++98  scan-assembler-not movl
FAIL: g++.dg/pr71694.C  -std=gnu++14  scan-assembler-not movl
FAIL: g++.dg/pr71694.C  -std=gnu++17  scan-assembler-not movl
FAIL: g++.dg/pr71694.C  -std=gnu++2a  scan-assembler-not movl
FAIL: g++.dg/stackprotectexplicit2.C  -std=gnu++98  scan-assembler-times 
stack_chk_fail 2
FAIL: g++.dg/stackprotectexplicit2.C  -std=gnu++14  scan-assembler-times 
stack_chk_fail 2
FAIL: g++.dg/stackprotectexplicit2.C  -std=gnu++17  scan-assembler-times 
stack_chk_fail 2
FAIL: g++.dg/stackprotectexplicit2.C  -std=gnu++2a  scan-assembler-times 
stack_chk_fail 2
FAIL: g++.dg/guality/pr55665.C   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  line 23 p == 40
FAIL: g++.dg/ubsan/vla-1.C   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects 
 execution test

=== g++ Summary for unix/-fstack-protector ===

# of expected passes190660
# of unexpected failures18
# of expected failures  705
# of unsupported tests  7953

=== g++ Summary ===

# of expected passes381320
# of unexpected failures36
# of expected failures  1410
# of unsupported tests  15906
/build/gcc-10-riGBJo/gcc-10-10.2.0/build/gcc/xg++  version 10.2.0 (Debian 
10.2.0-16) 

=== gcc tests ===


Running target unix
FAIL: gcc.dg/sibcall-11.c scan-assembler jmp
XPASS: gcc.dg/guality/example.c   -O0  execution test
XPASS: gcc.dg/guality/example.c   -O1  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/example.c  -Og -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/example.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/guality.c   -O0  execution test
XPASS: gcc.dg/guality/guality.c   -O1  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O2  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O3 -g  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -Os  -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c  -Og -DPREVENT_OPTIMIZATION  execution test
XPASS: gcc.dg/guality/guality.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  -DPREVENT_OPTIMIZATION execution test
XPASS: gcc.dg/guality/guality.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION execution test
XPASS: 

Bug#973443: src/init2.c:52: MPFR assertion failure

2020-10-30 Thread John Scott
Package: libmpfr6
Version: 4.1.0-3
Severity: normal
X-Debbugs-Cc: 

I was fooling around with Arb and it seems that this program causes
an assertion failure in MPFR, although ASan and UBSan don't point to
any misusage by Arb. (Curiously if you change the numerical string
from "0" to "0.5" then Arb does segfault outright, but I think that's
unrelated.)

One can build the program below with -lflint-arb to link:
#include 
#include 
int main(void) {
arb_t x;
arb_init(x);
if(arb_set_str(x, "0", WORD_MAX)) {
exit(EXIT_FAILURE);
} else {
arb_printd(x, WORD_MAX);
arb_clear(x);
}
}

and this causes
../../src/init2.c:52: MPFR assertion failed: ((p) >= 1 && (p) <= ((mpfr_prec_t) 
mpfr_uprec_t) -1) >> 1) - 256)))
Aborted

It seems this is related to the WORD_MAX limit in arb_printd(). Replacing
it with WORD_MAX/8 one gets (in GMP)
GNU MP: Cannot allocate memory (size=479903576292600072)
Aborted

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (2, 'unstable'), (1, 'testing-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libmpfr6 depends on:
ii  libc6 2.31-4
ii  libgmp10  2:6.2.0+dfsg-6

libmpfr6 recommends no packages.

libmpfr6 suggests no packages.

-- no debconf information



Re: Bug#973414: libmozjs-78-0: invalid opcodes in libmozjs when launching GDM3

2020-10-30 Thread Martin-Éric Racine
pe 30. lokak. 2020 klo 13.50 Simon McVittie (s...@debian.org) kirjoitti:
> On Fri, 30 Oct 2020 at 10:35:21 +0200, Martin-Éric Racine wrote:
> > [  165.903916] traps: gnome-shell[869] trap invalid opcode ip:b5518f8a 
> > sp:b17d6d80 error:0 in libmozjs-78.so.78.3.0[b4b98000+98c000]
>
> Which specific x86 CPU is this? I see `uname -m` is i586 rather than the
> expected i686 (and there's only one core), so presumably it's somewhere
> close to our architecture baseline, either above or below.  The baseline
> is -march=i686 since gcc-6_6.1.1-1 and stretch, according to the research
> I did for .

Geode LX800. This is technically a 686 but it doesn't support PAE, so
the CPU family remains 586.

> The /proc/cpuinfo would be useful information, since that includes a list
> of capability flags.

processor: 0
vendor_id: AuthenticAMD
cpu family: 5
model: 10
model name: Geode(TM) Integrated Processor by AMD PCS
stepping: 2
cpu MHz: 498.025
cache size: 128 KB
physical id: 0
siblings: 1
core id: 0
cpu cores: 1
apicid: 0
initial apicid: 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu: yes
fpu_exception: yes
cpuid level: 1
wp: yes
flags: fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext
3dnowext 3dnow cpuid 3dnowprefetch vmmcall
bugs: sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips: 996.05
clflush size: 32
cache_alignment: 32
address sizes: 32 bits physical, 32 bits virtual
power management:

> cc gcc maintainers (in the absence of an i386 porter contact): Is there
> a more formal/detailed specification for what CPU extensions we do and
> don't intend to require on i386?

AFAIK plain 686 (without PAE) is the baseline. Debian's
linux-image-686 actually is configured for Geode.

> Does Firefox work on this machine?
>
> Did older versions of GNOME Shell (buster or stretch) work on this machine?
> If yes, do they have acceptable performance in practice?

Both have worked until whatever is currently in Stable. Firefox as-is,
gnome-shell using the X wrapper.

Martin-Éric



Re: Bug#973414: libmozjs-78-0: invalid opcodes in libmozjs when launching GDM3

2020-10-30 Thread Simon McVittie
Control: tags -1 + moreinfo

On Fri, 30 Oct 2020 at 10:35:21 +0200, Martin-Éric Racine wrote:
> [  165.903916] traps: gnome-shell[869] trap invalid opcode ip:b5518f8a 
> sp:b17d6d80 error:0 in libmozjs-78.so.78.3.0[b4b98000+98c000]

Which specific x86 CPU is this? I see `uname -m` is i586 rather than the
expected i686 (and there's only one core), so presumably it's somewhere
close to our architecture baseline, either above or below.  The baseline
is -march=i686 since gcc-6_6.1.1-1 and stretch, according to the research
I did for .

The /proc/cpuinfo would be useful information, since that includes a list
of capability flags.

cc gcc maintainers (in the absence of an i386 porter contact): Is there
a more formal/detailed specification for what CPU extensions we do and
don't intend to require on i386?

If this CPU is at or slightly above the baseline and mozjs78 is using
non-baseline instructions, then that's a bug in the mozjs78 source (most
likely the JIT) or the packaging. If this is the case, I suspect that our
upstream (Mozilla) will refuse to support older CPUs, so we will have to
choose between making non-upstreamable changes or declaring that mozjs78
violating the baseline is wontfix. Our i386 mozjs78 is already built in a
configuration that upstream don't support, because they assume SSE on i386,
but SSE isn't part of our baseline, so we are still using the legacy i387
FPU instructions and their weird extended-precision behaviour; some tests
fail and are skipped as a result.

If it's slightly below the baseline (only a few missing opcodes), then it
isn't a bug for packages to not work, but it's possible that you get away
with it most of the time because the missing opcodes are rarely emitted?

Does Firefox work on this machine?

Did older versions of GNOME Shell (buster or stretch) work on this machine?
If yes, do they have acceptable performance in practice?

> [  204.840919] traps: gnome-session-f[939] trap invalid opcode ip:b4e7f86a 
> sp:bfcc1460 error:0 in librsvg-2.so.2.47.0[b4e6d000+5b7000]

If this is considered a mozjs78 bug, then librsvg has a similar bug
(possibly related to Rust, which they both use); or if your CPU is just
too old to run binaries compiled with Debian's post-stretch assumptions,
then the same applies to librsvg.

librsvg is likely to be more of a problem than mozjs78, because you can
take mozjs78 out of the critical path by using XFCE, LXDE or one of the
GNOME 2 forks like MATE and GNOME Flashback, but if this is a desktop
system you are still going to want to render SVGs.

smcv