Re: crash on __gmpz_init

2024-01-22 Thread Torbjörn Granlund 
"igor pesando - Dept of Physics, University of Torino"
 writes:

  thanks for the quick answer on the first case.
  But the issue is also present if I use malloc in C.

People have explained what you did wrong, which was several things.

Something you might consider: It would have been pretty surprising if
mpz_init was fundamentally broken, a function essentially every GMP
application program have beeing using for 30 years, don't you think?
Looking closer in such situations, considering the possibility of ones
own mistakes, might be a better approach.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: crash on __gmpz_init

2024-01-22 Thread igor pesando - Dept of Physics, University of Torino 

Hi Marc,
thanks for the quick answer on the first case.
But the issue is also present if I use malloc in C.
Bests
Igor P

On 22/01/24 11:02, Marc Glisse wrote:

Hello,

   mpz_class M[LINES][COLS];

you are trying to put an array with millions of elements on the stack, 
so the stack overflows. Very large arrays need to be allocated on the 
heap in C++ (new, malloc, or some wrapper like std::vector).


On Mon, 22 Jan 2024, igor pesando - Dept of Physics, University of 
Torino wrote:



Hi *,
first of all thanks for your work.

The programs are attached as required.


Best regards
Igor Pesando

*

The issue I have is that the allocation in of a matrix in c++ crashes
the program with SEGFAULT if the dimension are big enough.

LINES and COLS are the number of lines and columns of a matrix.


g++ -DLINES=5000 -DCOLS=5000 test2_mem.cpp -lgmp -lgmpxx -o t_500x500
./t_500x500
version6.2.1; bits/limb 64


g++ -DLINES=5000 -DCOLS=5000 test2_mem.cpp -lgmp -lgmpxx -o t_5000x5000
./t_5000x5000
Segmentation fault (core dumped)


The issue is not that my computer has not enough memory.
In facts when I run the corresponding program in C it crashes in 
__gmpz_init
BUT it does not crash when I allocate twice as much memory (SC is the 
scaling factor for the allocated memory).



gcc -DLINES=500 -DCOLS=500 -DSC=1 test2_mem.c -lgmp  -o tc_500x500
./tc_500x500
allocating 25; size=16


gcc -DLINES=5000 -DCOLS=5000 -DSC=1 test2_mem.c -lgmp  -o tc_5000x5000
igor@igor7a:~/tex/LCSFT/cpp/BUG_GMP_20240122$ ./tc_5000x5000
allocating 2500; size=16


gcc -DLINES=7000 -DCOLS=5000 -DSC=1 test2_mem.c -lgmp  -o tc_7000x5000
./tc_7000x5000 -g
allocating 3500; size=16
Segmentation fault (core dumped)


Twice as much memory
gcc -DLINES=7000 -DCOLS=5000 -DSC=2 test2_mem.c -lgmp  -o tc_7000x5000x2
./tc_7000x5000x2
allocating 3500; size=16


**
GDB

gdb ./tc_7000x5000

(gdb) r
Starting program: /home/igor/tex/LCSFT/cpp/BUG_GMP_20240122/tc_7000x5000
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/x86_64-linux-gnu/libthread_db.so.1".

allocating 3500; size=16

Program received signal SIGSEGV, Segmentation fault.
0x77f39c9b in __gmpz_init () from 
/lib/x86_64-linux-gnu/libgmp.so.10

(gdb) bt
#0  0x77f39c9b in __gmpz_init () from 
/lib/x86_64-linux-gnu/libgmp.so.10

#1  0x52e9 in main () at test2_mem.c:28

#1  0x52e9 in main () at test2_mem.c:28
(gdb) f 1
#1  0x52e9 in main () at test2_mem.c:28
28  mpz_init( M[ lin*LINES +col] );
(gdb) p lin
$1 = 5000
(gdb) p col
$2 = 63
(gdb)

here lin is


Please include the following in any report:


The GMP version number, and if pre-packaged or patched then say so.
gmp pre-packaged 6.2.1
gmp 6.3.0 from sources






A test program that makes it possible for us to reproduce the
bug. Include instructions on how to run the program.

In attachment


   A description of what is wrong. If the results are incorrect, in
   what way. If you get a crash, say so.

   If you get a crash, include a stack backtrace from the debugger if
   it’s informative (‘where’ in gdb, or ‘$C’ in adb).

Above


   Please do not send core dumps, executables or straces.


The ‘configure’ options you used when building GMP, if any.

   The output from ‘configure’, as printed to stdout, with any
   options used.



   The name of the compiler and its version. For gcc, get the version 
with ‘gcc -v’, otherwise perhaps ‘what `which cc`’, or similar.


gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
11.4.0-1ubuntu1~22.04' 
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 
--prefix=/usr --with-gcc-major-version-only --program-suffix=-11 
--program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --libdir=/usr/lib 
--enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie 
--with-system-zlib --enable-libphobos-checking=release

Re: crash on __gmpz_init

2024-01-22 Thread Vincent Lefevre 
On 2024-01-22 15:01:24 +0100, Vincent Lefevre wrote:
> I'm just surprised that GCC doesn't emit any warning
> (even with -O2 -Wall -Wextra), as some pointers are obviously
> incorrect.

The missing warning seems clearly a bug in GCC (I get a warning in
similar code, but not for the combination of malloc() and a loop),
which I've just reported:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113540

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: crash on __gmpz_init

2024-01-22 Thread Vincent Lefevre 
On 2024-01-22 14:34:21 +0100, Torbjorn Granlund wrote:
> Note that there are several typos for the dimensions in the examples, so
> making sense of things is pretty hard.

Indeed,

  mpz_init( M[ lin*LINES +col] );

should be lin*COLS + col.

I suspect a buffer overflow due to that (the allocated memory
is too small).

I'm just surprised that GCC doesn't emit any warning
(even with -O2 -Wall -Wextra), as some pointers are obviously
incorrect.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: crash on __gmpz_init

2024-01-22 Thread Vincent Lefevre 
On 2024-01-22 11:51:21 +0100, Vincent Lefevre wrote:
> On 2024-01-22 11:02:21 +0100, Marc Glisse wrote:
> > Hello,
> > 
> >   mpz_class M[LINES][COLS];
> > 
> > you are trying to put an array with millions of elements on the stack, so
> > the stack overflows. Very large arrays need to be allocated on the heap in
> > C++ (new, malloc, or some wrapper like std::vector).
> 
> Note that the user has a segmentation fault in __gmpz_init for
> test2_mem.c too (tc_7000x5000), which uses malloc(). See the
> gdb output.

I can reproduce the issue, even with a much smaller array:

qaa:~> gcc -DLINES=70 -DCOLS=10 -DSC=1 test2_mem.c -lgmp -o test2_mem
qaa:~> ./test2_mem
allocating 700; size=16
malloc(): corrupted top size
zsh: IOT instruction (core dumped)  ./test2_mem

And with valgrind:

==649064== Memcheck, a memory error detector
==649064== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==649064== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==649064== Command: ./test2_mem
==649064== 
allocating 700; size=16
==649064== Invalid write of size 8
==649064==at 0x488B147: __gmpz_init (in 
/usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0)
==649064==by 0x109271: main (in /home/vinc17/test2_mem)
==649064==  Address 0x4ad8040 is 0 bytes after a block of size 11,200 alloc'd
==649064==at 0x48407B4: malloc (vg_replace_malloc.c:381)
==649064==by 0x109218: main (in /home/vinc17/test2_mem)
==649064== 
==649064== Invalid write of size 8
==649064==at 0x488B14E: __gmpz_init (in 
/usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0)
==649064==by 0x109271: main (in /home/vinc17/test2_mem)
==649064==  Address 0x4ad8048 is 8 bytes after a block of size 11,200 alloc'd
==649064==at 0x48407B4: malloc (vg_replace_malloc.c:381)
==649064==by 0x109218: main (in /home/vinc17/test2_mem)
==649064== 

valgrind: m_mallocfree.c:278 (mk_plain_bszB): Assertion 'bszB != 0' failed.
valgrind: This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata.  If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away.  Please try that before reporting this as a bug.


host stacktrace:
==649064==at 0x580429AA: show_sched_status_wrk (m_libcassert.c:406)
==649064==by 0x58042AC7: report_and_quit (m_libcassert.c:477)
==649064==by 0x58042C57: vgPlain_assert_fail (m_libcassert.c:543)
==649064==by 0x5804CA6C: mk_plain_bszB (m_mallocfree.c:278)
==649064==by 0x5804CA6C: mk_plain_bszB (m_mallocfree.c:276)
==649064==by 0x5804CA6C: get_bszB_as_is (m_mallocfree.c:301)
==649064==by 0x5804CA6C: get_bszB (m_mallocfree.c:313)
==649064==by 0x5804CA6C: get_next_b (m_mallocfree.c:432)
==649064==by 0x5804CA6C: vgPlain_arena_malloc (m_mallocfree.c:1806)
==649064==by 0x58004FE4: vgMemCheck_new_block (mc_malloc_wrappers.c:370)
==649064==by 0x580051CA: vgMemCheck_malloc (mc_malloc_wrappers.c:405)
==649064==by 0x5809A08B: do_client_request (scheduler.c:1956)
==649064==by 0x5809A08B: vgPlain_scheduler (scheduler.c:1519)
==649064==by 0x580E1B6C: thread_wrapper (syswrap-linux.c:101)
==649064==by 0x580E1B6C: run_a_thread_NORETURN (syswrap-linux.c:154)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 649064)
==649064==at 0x48407B4: malloc (vg_replace_malloc.c:381)
==649064==by 0x487A968: __gmp_default_allocate (in 
/usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0)
==649064==by 0x4891FD3: __gmpz_realloc (in 
/usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0)
==649064==by 0x489305E: __gmpz_set_si (in 
/usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0)
==649064==by 0x1092CB: main (in /home/vinc17/test2_mem)
client stack range: [0x1FFEFFD000 0x1FFF000FFF] client SP: 0x1FFEFFF540
valgrind stack range: [0x1002CAA000 0x1002DA9FFF] top usage: 18792 of 1048576

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: crash on __gmpz_init

2024-01-22 Thread Torbjörn Granlund 
Vincent Lefevre  writes:

  On 2024-01-22 11:02:21 +0100, Marc Glisse wrote:
  > Hello,
  > 
  >   mpz_class M[LINES][COLS];
  > 
  > you are trying to put an array with millions of elements on the stack, so
  > the stack overflows. Very large arrays need to be allocated on the heap in
  > C++ (new, malloc, or some wrapper like std::vector).

  Note that the user has a segmentation fault in __gmpz_init for
  test2_mem.c too (tc_7000x5000), which uses malloc(). See the
  gdb output.

Note that there are several typos for the dimensions in the examples, so
making sense of things is pretty hard.

Seeing segfaults in mpz_init for crazy stack offsets is expected for
stack overflow, I think.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: crash on __gmpz_init

2024-01-22 Thread Vincent Lefevre 
On 2024-01-22 11:02:21 +0100, Marc Glisse wrote:
> Hello,
> 
>   mpz_class M[LINES][COLS];
> 
> you are trying to put an array with millions of elements on the stack, so
> the stack overflows. Very large arrays need to be allocated on the heap in
> C++ (new, malloc, or some wrapper like std::vector).

Note that the user has a segmentation fault in __gmpz_init for
test2_mem.c too (tc_7000x5000), which uses malloc(). See the
gdb output.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: crash on __gmpz_init

2024-01-22 Thread Marc Glisse 

Hello,

  mpz_class M[LINES][COLS];

you are trying to put an array with millions of elements on the stack, so 
the stack overflows. Very large arrays need to be allocated on the heap in 
C++ (new, malloc, or some wrapper like std::vector).


On Mon, 22 Jan 2024, igor pesando - Dept of Physics, University of Torino wrote:


Hi *,
first of all thanks for your work.

The programs are attached as required.


Best regards
Igor Pesando

*

The issue I have is that the allocation in of a matrix in c++ crashes
the program with SEGFAULT if the dimension are big enough.

LINES and COLS are the number of lines and columns of a matrix.


g++ -DLINES=5000 -DCOLS=5000 test2_mem.cpp -lgmp -lgmpxx -o t_500x500
./t_500x500
version6.2.1; bits/limb 64


g++ -DLINES=5000 -DCOLS=5000 test2_mem.cpp -lgmp -lgmpxx -o t_5000x5000
./t_5000x5000
Segmentation fault (core dumped)


The issue is not that my computer has not enough memory.
In facts when I run the corresponding program in C it crashes in __gmpz_init
BUT it does not crash when I allocate twice as much memory (SC is the scaling 
factor for the allocated memory).



gcc -DLINES=500 -DCOLS=500 -DSC=1 test2_mem.c -lgmp  -o tc_500x500
./tc_500x500
allocating 25; size=16


gcc -DLINES=5000 -DCOLS=5000 -DSC=1 test2_mem.c -lgmp  -o tc_5000x5000
igor@igor7a:~/tex/LCSFT/cpp/BUG_GMP_20240122$ ./tc_5000x5000
allocating 2500; size=16


gcc -DLINES=7000 -DCOLS=5000 -DSC=1 test2_mem.c -lgmp  -o tc_7000x5000
./tc_7000x5000 -g
allocating 3500; size=16
Segmentation fault (core dumped)


Twice as much memory
gcc -DLINES=7000 -DCOLS=5000 -DSC=2 test2_mem.c -lgmp  -o tc_7000x5000x2
./tc_7000x5000x2
allocating 3500; size=16


**
GDB

gdb ./tc_7000x5000

(gdb) r
Starting program: /home/igor/tex/LCSFT/cpp/BUG_GMP_20240122/tc_7000x5000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
allocating 3500; size=16

Program received signal SIGSEGV, Segmentation fault.
0x77f39c9b in __gmpz_init () from /lib/x86_64-linux-gnu/libgmp.so.10
(gdb) bt
#0  0x77f39c9b in __gmpz_init () from 
/lib/x86_64-linux-gnu/libgmp.so.10

#1  0x52e9 in main () at test2_mem.c:28

#1  0x52e9 in main () at test2_mem.c:28
(gdb) f 1
#1  0x52e9 in main () at test2_mem.c:28
28mpz_init( M[ lin*LINES +col] );
(gdb) p lin
$1 = 5000
(gdb) p col
$2 = 63
(gdb)

here lin is


Please include the following in any report:


The GMP version number, and if pre-packaged or patched then say so.
gmp pre-packaged 6.2.1
gmp 6.3.0 from sources






A test program that makes it possible for us to reproduce the
bug. Include instructions on how to run the program.

In attachment


   A description of what is wrong. If the results are incorrect, in
   what way. If you get a crash, say so.

   If you get a crash, include a stack backtrace from the debugger if
   it’s informative (‘where’ in gdb, or ‘$C’ in adb).

Above


   Please do not send core dumps, executables or straces.


The ‘configure’ options you used when building GMP, if any.

   The output from ‘configure’, as printed to stdout, with any
   options used.



   The name of the compiler and its version. For gcc, get the version with 
‘gcc -v’, otherwise perhaps ‘what `which cc`’, or similar.


gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-11 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie 
--with-system-zlib --enable-libphobos-checking=release 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32

crash on __gmpz_init

2024-01-22 Thread igor pesando - Dept of Physics, University of Torino 

Hi *,
first of all thanks for your work.

The programs are attached as required.


Best regards
Igor Pesando

*

The issue I have is that the allocation in of a matrix in c++ crashes
the program with SEGFAULT if the dimension are big enough.

LINES and COLS are the number of lines and columns of a matrix.


g++ -DLINES=5000 -DCOLS=5000 test2_mem.cpp -lgmp -lgmpxx -o t_500x500
./t_500x500
version6.2.1; bits/limb 64


g++ -DLINES=5000 -DCOLS=5000 test2_mem.cpp -lgmp -lgmpxx -o t_5000x5000
./t_5000x5000
Segmentation fault (core dumped)


The issue is not that my computer has not enough memory.
In facts when I run the corresponding program in C it crashes in __gmpz_init
BUT it does not crash when I allocate twice as much memory (SC is the 
scaling factor for the allocated memory).



gcc -DLINES=500 -DCOLS=500 -DSC=1 test2_mem.c -lgmp  -o tc_500x500
./tc_500x500
allocating 25; size=16


gcc -DLINES=5000 -DCOLS=5000 -DSC=1 test2_mem.c -lgmp  -o tc_5000x5000
igor@igor7a:~/tex/LCSFT/cpp/BUG_GMP_20240122$ ./tc_5000x5000
allocating 2500; size=16


gcc -DLINES=7000 -DCOLS=5000 -DSC=1 test2_mem.c -lgmp  -o tc_7000x5000
./tc_7000x5000 -g
allocating 3500; size=16
Segmentation fault (core dumped)


Twice as much memory
gcc -DLINES=7000 -DCOLS=5000 -DSC=2 test2_mem.c -lgmp  -o tc_7000x5000x2
./tc_7000x5000x2
allocating 3500; size=16


**
GDB

gdb ./tc_7000x5000

(gdb) r
Starting program: /home/igor/tex/LCSFT/cpp/BUG_GMP_20240122/tc_7000x5000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
allocating 3500; size=16

Program received signal SIGSEGV, Segmentation fault.
0x77f39c9b in __gmpz_init () from /lib/x86_64-linux-gnu/libgmp.so.10
(gdb) bt
#0  0x77f39c9b in __gmpz_init () from 
/lib/x86_64-linux-gnu/libgmp.so.10

#1  0x52e9 in main () at test2_mem.c:28

#1  0x52e9 in main () at test2_mem.c:28
(gdb) f 1
#1  0x52e9 in main () at test2_mem.c:28
28mpz_init( M[ lin*LINES +col] );
(gdb) p lin
$1 = 5000
(gdb) p col
$2 = 63
(gdb)

here lin is


Please include the following in any report:


The GMP version number, and if pre-packaged or patched then say so.
gmp pre-packaged 6.2.1
gmp 6.3.0 from sources






A test program that makes it possible for us to reproduce the
bug. Include instructions on how to run the program.

In attachment


A description of what is wrong. If the results are incorrect, in
what way. If you get a crash, say so.

If you get a crash, include a stack backtrace from the debugger if
it’s informative (‘where’ in gdb, or ‘$C’ in adb).

Above


Please do not send core dumps, executables or straces.


The ‘configure’ options you used when building GMP, if any.

The output from ‘configure’, as printed to stdout, with any
options used.



The name of the compiler and its version. For gcc, get the version 
with ‘gcc -v’, otherwise perhaps ‘what `which cc`’, or similar.


gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
11.4.0-1ubuntu1~22.04' 
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 
--prefix=/usr --with-gcc-major-version-only --program-suffix=-11 
--program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --libdir=/usr/lib 
--enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie 
--with-system-zlib --enable-libphobos-checking=release 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-XeT9lY/gcc-11-11.4.0/debian/tmp-gcn/usr 
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu