* [Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
2021-12-27 22:59 [Bug go/103847] New: gccgo SIGSEGV in libgo standard library on sparc64 matoro_gcc_bugzilla at matoro dot tk
@ 2021-12-27 23:00 ` matoro_gcc_bugzilla at matoro dot tk
2021-12-27 23:00 ` matoro_gcc_bugzilla at matoro dot tk
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: matoro_gcc_bugzilla at matoro dot tk @ 2021-12-27 23:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847
matoro <matoro_gcc_bugzilla at matoro dot tk> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |matoro_gcc_bugzilla@matoro.
| |tk
--- Comment #1 from matoro <matoro_gcc_bugzilla at matoro dot tk> ---
Created attachment 52072
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52072&action=edit
build-with-network.log
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
2021-12-27 22:59 [Bug go/103847] New: gccgo SIGSEGV in libgo standard library on sparc64 matoro_gcc_bugzilla at matoro dot tk
2021-12-27 23:00 ` [Bug go/103847] " matoro_gcc_bugzilla at matoro dot tk
@ 2021-12-27 23:00 ` matoro_gcc_bugzilla at matoro dot tk
2021-12-27 23:01 ` matoro_gcc_bugzilla at matoro dot tk
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: matoro_gcc_bugzilla at matoro dot tk @ 2021-12-27 23:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847
--- Comment #2 from matoro <matoro_gcc_bugzilla at matoro dot tk> ---
Created attachment 52073
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52073&action=edit
build-without-network.log
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
2021-12-27 22:59 [Bug go/103847] New: gccgo SIGSEGV in libgo standard library on sparc64 matoro_gcc_bugzilla at matoro dot tk
2021-12-27 23:00 ` [Bug go/103847] " matoro_gcc_bugzilla at matoro dot tk
2021-12-27 23:00 ` matoro_gcc_bugzilla at matoro dot tk
@ 2021-12-27 23:01 ` matoro_gcc_bugzilla at matoro dot tk
2021-12-28 17:47 ` ian at airs dot com
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: matoro_gcc_bugzilla at matoro dot tk @ 2021-12-27 23:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847
--- Comment #3 from matoro <matoro_gcc_bugzilla at matoro dot tk> ---
Oh, and just for reference, I did confirm that these crashes do not occur on
amd64.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
2021-12-27 22:59 [Bug go/103847] New: gccgo SIGSEGV in libgo standard library on sparc64 matoro_gcc_bugzilla at matoro dot tk
` (2 preceding siblings ...)
2021-12-27 23:01 ` matoro_gcc_bugzilla at matoro dot tk
@ 2021-12-28 17:47 ` ian at airs dot com
2021-12-29 0:53 ` matoro_gcc_bugzilla at matoro dot tk
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ian at airs dot com @ 2021-12-28 17:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847
--- Comment #4 from Ian Lance Taylor <ian at airs dot com> ---
There don't seem to be any sparc64-linux machines in the GCC compile farm, so I
can't recreate this myself.
Are you able to recreate the problem while running under gdb? A backtrace from
the point of the signal might help. The stack backtraces you included
unfortunately don't tell me anything useful. Thanks.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
2021-12-27 22:59 [Bug go/103847] New: gccgo SIGSEGV in libgo standard library on sparc64 matoro_gcc_bugzilla at matoro dot tk
` (3 preceding siblings ...)
2021-12-28 17:47 ` ian at airs dot com
@ 2021-12-29 0:53 ` matoro_gcc_bugzilla at matoro dot tk
2021-12-29 2:49 ` ian at airs dot com
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: matoro_gcc_bugzilla at matoro dot tk @ 2021-12-29 0:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847
--- Comment #5 from matoro <matoro_gcc_bugzilla at matoro dot tk> ---
(In reply to Ian Lance Taylor from comment #4)
> There don't seem to be any sparc64-linux machines in the GCC compile farm,
> so I can't recreate this myself.
>
> Are you able to recreate the problem while running under gdb? A backtrace
> from the point of the signal might help. The stack backtraces you included
> unfortunately don't tell me anything useful. Thanks.
For some reason despite compiling with debug symbols I can't seem to get gdb to
recognize the symbol table, all I get is:
$ GOMAXPROCS=1 CGO_ENABLED=1 GO111MODULE=on gdb -q --args /usr/bin/go-11 build
Reading symbols from /usr/bin/go-11...
(gdb) r
Starting program: /usr/bin/go-11 build
[New LWP 51735]
[New LWP 51736]
Thread 1 "go-11" received signal SIGSEGV, Segmentation fault.
0xfff80001010c11ac in ?? ()
(gdb) bt full
#0 0xfff80001010c11ac in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
$ file -L /usr/bin/go-11
/usr/bin/go-11: ELF 64-bit MSB pie executable, SPARC V9, relaxed memory
ordering, version 1 (SYSV), dynamically linked, interpreter
/lib64/ld-linux.so.2, for GNU/Linux 3.2.0, with debug_info, not stripped
$ ldd /usr/bin/go-11
linux-vdso.so.1 (0xfff8000100680000)
libgo.so.19 =>
/usr/lib/gcc/sparc64-unknown-linux-gnu/11.2.1/libgo.so.19 (0xfff8000100684000)
libm.so.6 => /lib64/libm.so.6 (0xfff80001020c0000)
libc.so.6 => /lib64/libc.so.6 (0xfff8000102278000)
libgcc_s.so.1 =>
/usr/lib/gcc/sparc64-unknown-linux-gnu/11.2.1/libgcc_s.so.1
(0xfff8000102508000)
/lib64/ld-linux.so.2 (0xfff8000100000000)
$ file -L /usr/lib/gcc/sparc64-unknown-linux-gnu/11.2.1/libgo.so.19
/usr/lib/gcc/sparc64-unknown-linux-gnu/11.2.1/libgo.so.19: ELF 64-bit MSB
shared object, SPARC V9, relaxed memory ordering, version 1 (SYSV), dynamically
linked, with debug_info, not stripped
$ readelf -S /usr/bin/go-11 | grep -i "debug"
[27] .debug_aranges PROGBITS 0000000000000000 005ad1e6
[28] .debug_info PROGBITS 0000000000000000 005ade86
[29] .debug_abbrev PROGBITS 0000000000000000 0075e02a
[30] .debug_line PROGBITS 0000000000000000 00772a5a
[31] .debug_frame PROGBITS 0000000000000000 007f5b20
[32] .debug_str PROGBITS 0000000000000000 007f5b70
[33] .debug_line_str PROGBITS 0000000000000000 00846a06
[34] .debug_loclists PROGBITS 0000000000000000 0084adc8
[35] .debug_rnglists PROGBITS 0000000000000000 0094e386
I am able to provide ssh access to the live system on which this is occurring -
would that be helpful or is that not really something you prefer to do in the
course of debugging?
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
2021-12-27 22:59 [Bug go/103847] New: gccgo SIGSEGV in libgo standard library on sparc64 matoro_gcc_bugzilla at matoro dot tk
` (4 preceding siblings ...)
2021-12-29 0:53 ` matoro_gcc_bugzilla at matoro dot tk
@ 2021-12-29 2:49 ` ian at airs dot com
2021-12-29 3:05 ` matoro_gcc_bugzilla at matoro dot tk
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: ian at airs dot com @ 2021-12-29 2:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847
--- Comment #6 from Ian Lance Taylor <ian at airs dot com> ---
I can try debugging it with ssh access. I'll want to build my own copy of
gccgo. Let me know where I should send the public key. Thanks.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
2021-12-27 22:59 [Bug go/103847] New: gccgo SIGSEGV in libgo standard library on sparc64 matoro_gcc_bugzilla at matoro dot tk
` (5 preceding siblings ...)
2021-12-29 2:49 ` ian at airs dot com
@ 2021-12-29 3:05 ` matoro_gcc_bugzilla at matoro dot tk
2021-12-29 23:53 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: matoro_gcc_bugzilla at matoro dot tk @ 2021-12-29 3:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847
--- Comment #7 from matoro <matoro_gcc_bugzilla at matoro dot tk> ---
(In reply to Ian Lance Taylor from comment #6)
> I can try debugging it with ssh access. I'll want to build my own copy of
> gccgo. Let me know where I should send the public key. Thanks.
matoro_gcc_bugzilla <at> matoro <dot> tk
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
2021-12-27 22:59 [Bug go/103847] New: gccgo SIGSEGV in libgo standard library on sparc64 matoro_gcc_bugzilla at matoro dot tk
` (6 preceding siblings ...)
2021-12-29 3:05 ` matoro_gcc_bugzilla at matoro dot tk
@ 2021-12-29 23:53 ` cvs-commit at gcc dot gnu.org
2021-12-30 18:43 ` ian at airs dot com
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-12-29 23:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Ian Lance Taylor <ian@gcc.gnu.org>:
https://gcc.gnu.org/g:62c3f75fd29e93054f3aeb8a623fd52c98c3db0b
commit r12-6147-g62c3f75fd29e93054f3aeb8a623fd52c98c3db0b
Author: Ian Lance Taylor <iant@golang.org>
Date: Wed Dec 29 15:08:32 2021 -0800
compiler, libgo: don't pad sparc64-linux epollevent
Change the compiler to not add zero padding because of zero-sized
fields named "_", since those can't be referenced anyhow.
Change the sparc-linux64 epollevent struct to name the alignment
field "_", to avoid zero padding.
Fixes PR go/103847
PR go/103847
* godump.c (go_force_record_alignment): Name the alignment
field "_".
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/374914
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
2021-12-27 22:59 [Bug go/103847] New: gccgo SIGSEGV in libgo standard library on sparc64 matoro_gcc_bugzilla at matoro dot tk
` (7 preceding siblings ...)
2021-12-29 23:53 ` cvs-commit at gcc dot gnu.org
@ 2021-12-30 18:43 ` ian at airs dot com
2022-01-01 5:32 ` cvs-commit at gcc dot gnu.org
2022-01-07 6:38 ` pinskia at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: ian at airs dot com @ 2021-12-30 18:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847
Ian Lance Taylor <ian at airs dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
--- Comment #9 from Ian Lance Taylor <ian at airs dot com> ---
This should be fixed on tip. Thanks for reporting it.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
2021-12-27 22:59 [Bug go/103847] New: gccgo SIGSEGV in libgo standard library on sparc64 matoro_gcc_bugzilla at matoro dot tk
` (8 preceding siblings ...)
2021-12-30 18:43 ` ian at airs dot com
@ 2022-01-01 5:32 ` cvs-commit at gcc dot gnu.org
2022-01-07 6:38 ` pinskia at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-01-01 5:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847
--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:7918d8270a43e42b0cba902ec17ce87b6a3c74a9
commit r12-6163-g7918d8270a43e42b0cba902ec17ce87b6a3c74a9
Author: Jakub Jelinek <jakub@redhat.com>
Date: Sat Jan 1 06:30:39 2022 +0100
testsuite: Adjust gcc.misc-tests/godump-1.c testcase
On Wed, Dec 29, 2021 at 03:54:03PM -0800, Ian Lance Taylor via Gcc-patches
wrote:
> PR go/103847
> * godump.c (go_force_record_alignment): Name the alignment
> field "_".
> --- a/gcc/godump.c
> +++ b/gcc/godump.c
> @@ -651,7 +651,7 @@ go_force_record_alignment (struct obstack *ob, const
char *type_string,
> unsigned int index, const char *error_string)
> {
> index = go_append_artificial_name (ob, index);
> - obstack_grow (ob, "_align ", 7);
> + obstack_grow (ob, "_ ", 2);
> if (type_string == NULL)
> obstack_grow (ob, error_string, strlen (error_string));
> else
This change caused
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _ts_nested struct { u
struct { s int16; Godump_0_pad \\\\[2\\\\]byte; Godump_1_align
\\\\[0\\\\]u?int32; }; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _ts_nested2 struct { u
struct { Godump_0_pad \\\\[4\\\\]byte; Godump_1_pad \\\\[2\\\\]byte; s int16; c
int8; Godump_2_pad
+\\\\[1\\\\]byte; Godump_3_pad \\\\[2\\\\]byte; Godump_4_align
\\\\[0\\\\]u?int32; }; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_gaps struct {
bf1 uint8; c uint8; bf2 uint8; Godump_0_pad \\\\[2\\\\]byte; s uint16;
Godump_1_align \\\\[0\\\\]int32; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad16_1 struct {
Godump_0_pad \\\\[1\\\\]byte; c uint8; Godump_1_align \\\\[0\\\\]int16; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad16_2 struct {
Godump_0_pad \\\\[2\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int16; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad32_1 struct {
Godump_0_pad \\\\[1\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int32; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad32_2 struct {
Godump_0_pad \\\\[4\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int32; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad64_1 struct {
Godump_0_pad \\\\[1\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad64_2 struct {
Godump_0_pad \\\\[8\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsn_anon struct { a
uint8; s uint16; b uint8; Godump_0_pad \\\\[.\\\\]byte; Godump_1_align
\\\\[0\\\\]int16; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsu_anon struct { c
uint8; Godump_0_pad \\\\[7\\\\]byte; Godump_1_align \\\\[0\\\\]u?int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu1 struct { c uint8;
Godump_0_pad \\\\[.\\\\]byte; Godump_1_align \\\\[0\\\\]u?int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu3_size struct { ca
\\\\[4\\\\+1\\\\]uint8; Godump_0_pad \\\\[.\\\\]byte; Godump_1_align
\\\\[0\\\\]u?int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu_nested struct { u
struct { s int16; Godump_0_pad \\\\[2\\\\]byte; Godump_1_align
\\\\[0\\\\]u?int32; }; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu_nested2 struct { u
struct { Godump_0_pad \\\\[4\\\\]byte; Godump_1_pad \\\\[2\\\\]byte; s int16; c
int8; Godump_2_pad
+\\\\[1\\\\]byte; Godump_3_pad \\\\[2\\\\]byte; Godump_4_align
\\\\[0\\\\]u?int32; }; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tu_size struct { ca
\\\\[4\\\\+1\\\\]uint8; Godump_0_pad \\\\[.\\\\]byte; Godump_1_align
\\\\[0\\\\]u?int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _s_nested struct { u
struct { s int16; Godump_0_pad \\\\[2\\\\]byte; Godump_1_align
\\\\[0\\\\]u?int32; }; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _s_nested2 struct { u
struct { Godump_0_pad \\\\[4\\\\]byte; Godump_1_pad \\\\[2\\\\]byte; s int16; c
int8; Godump_2_pad
+\\\\[1\\\\]byte; Godump_3_pad \\\\[2\\\\]byte; Godump_4_align
\\\\[0\\\\]u?int32; }; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_gaps struct { bf1
uint8; c uint8; bf2 uint8; Godump_0_pad \\\\[2\\\\]byte; s uint16;
Godump_1_align \\\\[0\\\\]int32; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad16_1 struct {
Godump_0_pad \\\\[1\\\\]byte; c uint8; Godump_1_align \\\\[0\\\\]int16; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad16_2 struct {
Godump_0_pad \\\\[2\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int16; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad32_1 struct {
Godump_0_pad \\\\[1\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int32; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad32_2 struct {
Godump_0_pad \\\\[4\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int32; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad64_1 struct {
Godump_0_pad \\\\[1\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sbf_pad64_2 struct {
Godump_0_pad \\\\[8\\\\]byte; c uint8; Godump_1_pad \\\\[.\\\\]byte;
Godump_2_align \\\\[0\\\\]int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _sn_anon struct { a
uint8; s uint16; b uint8; Godump_0_pad \\\\[.\\\\]byte; Godump_1_align
\\\\[0\\\\]int16; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _su_anon struct { c
uint8; Godump_0_pad \\\\[7\\\\]byte; Godump_1_align \\\\[0\\\\]u?int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _u1 struct { c uint8;
Godump_0_pad \\\\[.\\\\]byte; Godump_1_align \\\\[0\\\\]u?int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _u3_size struct { ca
\\\\[4\\\\+1\\\\]uint8; Godump_0_pad \\\\[.\\\\]byte; Godump_1_align
\\\\[0\\\\]u?int64; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _u_nested struct { u
struct { s int16; Godump_0_pad \\\\[2\\\\]byte; Godump_1_align
\\\\[0\\\\]u?int32; }; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _u_nested2 struct { u
struct { Godump_0_pad \\\\[4\\\\]byte; Godump_1_pad \\\\[2\\\\]byte; s int16; c
int8; Godump_2_pad
+\\\\[1\\\\]byte; Godump_3_pad \\\\[2\\\\]byte; Godump_4_align
\\\\[0\\\\]u?int32; }; }\$
+FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^var _u_size struct { ca
\\\\[4\\\\+1\\\\]uint8; Godump_0_pad \\\\[.\\\\]byte; Godump_1_align
\\\\[0\\\\]u?int64; }\$
on x86_64-linux.
The following patch adjusts the testcase for the above change.
2022-01-01 Jakub Jelinek <jakub@redhat.com>
* gcc.misc-tests/godump-1.c: Adjust for renaming of last
field from _align suffix to _ suffix.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
2021-12-27 22:59 [Bug go/103847] New: gccgo SIGSEGV in libgo standard library on sparc64 matoro_gcc_bugzilla at matoro dot tk
` (9 preceding siblings ...)
2022-01-01 5:32 ` cvs-commit at gcc dot gnu.org
@ 2022-01-07 6:38 ` pinskia at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-01-07 6:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |12.0
^ permalink raw reply [flat|nested] 12+ messages in thread