public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2
@ 2022-12-16 15:15 jakub at gcc dot gnu.org
2022-12-16 15:53 ` [Bug modula2/108147] " jakub at gcc dot gnu.org
` (15 more replies)
0 siblings, 16 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-16 15:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
Bug ID: 108147
Summary: Bootstrap failure on powerpc64le-linux with m2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Bootstrap fails on powerpc64le-linux when modula 2 is enabled.
../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release
--enable-targets=powerpcle-linux --disable-multilib --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-gcc-major-version-only
--enable-libstdcxx-backtrace --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-13.0.0-20221215/obj-ppc64le-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-secureplt
--with-long-double-128 --with-long-double-format=ieee --with-cpu-32=power8
--with-tune-32=power8 --with-cpu-64=power8 --with-tune-64=power8
--build=ppc64le-redhat-linux
and the ICE I get is on:
/builddir/build/BUILD/gcc-13.0.0-20221215/obj-ppc64le-redhat-linux/./gcc/gm2
-B/builddir/build/BUILD/gcc-13.0.0-20221215/obj-ppc64le-redhat-linux/./gcc/ -c
-O2 -fexceptions -g -grecord-gcc-switches -Wall -Wformat-security
-Wp,-D_GLIBCXX_ASSERTIONS -mcpu=power8 -mtune=power8
-fasynchronous-unwind-tables -fstack-clash-protection -O2 -fexceptions -g
-grecord-gcc-switches -Wall -Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS
-mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables
-fstack-clash-protection -I.
-I/builddir/build/BUILD/gcc-13.0.0-20221215/gcc/m2/gm2-libs-min
-I/builddir/build/BUILD/gcc-13.0.0-20221215/gcc/m2/gm2-libs -fno-exceptions
-fno-m2-plugin -fno-scaffold-dynamic -fno-scaffold-main
../../../../libgm2/libm2min/../../gcc/m2/gm2-libs-min/M2RTS.mod -o M2RTS.lo
/builddir/build/BUILD/gcc-13.0.0-20221215/obj-ppc64le-redhat-linux/./gcc/cc1gm2
-msecure-plt -quiet -dumpbase M2RTS.mod -dumpbase-ext .mod -mcpu=power8
-mtune=power8 -mcpu=power8 -mtune=power8 -g -g -grecord-gcc-switches -O2 -O2
-Wall -Wformat-security -version -fasynchronous-unwind-tables
-fstack-clash-protection -fno-exceptions -fno-m2-plugin -fno-scaffold-dynamic
-fno-scaffold-main -B
/builddir/build/BUILD/gcc-13.0.0-20221215/obj-ppc64le-redhat-linux/./gcc/ -c
-fasynchronous-unwind-tables -fstack-clash-protection -fno-exceptions
-fno-m2-plugin -fno-scaffold-dynamic -fno-scaffold-main -I . -I
/builddir/build/BUILD/gcc-13.0.0-20221215/gcc/m2/gm2-libs-min -I
/builddir/build/BUILD/gcc-13.0.0-20221215/gcc/m2/gm2-libs -I
/usr/lib/gcc/ppc64le-redhat-linux/13/tune=power8/m2/m2pim -I
/usr/lib/gcc/ppc64le-redhat-linux/13/tune=power8/m2/m2log -I
/usr/lib/gcc/ppc64le-redhat-linux/13/tune=power8/m2/m2iso
../../../../libgm2/libm2min/../../gcc/m2/gm2-libs-min/M2RTS.mod -o
/tmp/ccAHJQJE.s
cc1gm2: warning: command-line option '-Wformat-security' is valid for
C/C++/ObjC/ObjC++ but not for Modula-2
GNU Modula-2 (GCC) version 13.0.0 20221215 (Red Hat 13.0.0-0)
(ppc64le-redhat-linux)
compiled by GNU C version 13.0.0 20221215 (Red Hat 13.0.0-0), GMP
version 6.2.1, MPFR version 4.1.1-p1, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Modula-2 (GCC) version 13.0.0 20221215 (Red Hat 13.0.0-0)
(ppc64le-redhat-linux)
compiled by GNU C version 13.0.0 20221215 (Red Hat 13.0.0-0), GMP
version 6.2.1, MPFR version 4.1.1-p1, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
/builddir/build/BUILD/gcc-13.0.0-20221215/gcc/m2/gm2-libs-min/M2RTS.def:41:27:
warning: In procedure 'RegisterModule': unused parameter 'name' in procedure
'RegisterModule'
41 | PROCEDURE RegisterModule (name: ADDRESS;
| ^~~~
terminate called after throwing an instance of 'unsigned int'
cc1gm2: internal compiler error: Aborted
0x103c716b crash_signal
../../gcc/toplev.cc:317
0x116465d7 __gnu_cxx::__verbose_terminate_handler()
../../../../libstdc++-v3/libsupc++/vterminate.cc:95
0x11644e13 __cxxabiv1::__terminate(void (*)())
../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
0x11644edf std::terminate()
../../../../libstdc++-v3/libsupc++/eh_terminate.cc:58
0x116451a3 __cxa_throw
../../../../libstdc++-v3/libsupc++/eh_throw.cc:98
0x111327df InvokeHandler
m2/gm2-libs-boot/RTExceptions.c:483
0x111327df RTExceptions_Raise
m2/gm2-libs-boot/RTExceptions.c:943
0x1113a717 sigbusDespatcher
../../gcc/m2/gm2-libs-ch/SysExceptions.c:125
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
@ 2022-12-16 15:53 ` jakub at gcc dot gnu.org
2022-12-16 16:01 ` jakub at gcc dot gnu.org
` (14 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-16 15:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The ICE seems to be during
#0 0x0000000010ffc2e8 in m2linemap_WarningAtf (location=456515,
message=0x11f57210 "In procedure 'RegisterModule': unused parameter 'name' in
procedure 'RegisterModule'")
at ../../gcc/m2/gm2-gcc/m2linemap.cc:202
#1 0x000000001111bb08 in M2Emit_EmitError (error=<optimized out>,
note=<optimized out>, token=<optimized out>, message=<optimized out>) at
m2/gm2-compiler-boot/M2Emit.c:85
#2 0x000000001102fb0c in FlushAll (e=0x11f52ee0, FatalStatus=0) at
m2/gm2-compiler-boot/M2Error.c:2418
#3 0x000000001102c2c0 in Compile (s=0x11f06160) at
m2/gm2-compiler-boot/M2Comp.c:208
#4 M2Comp_compile (filename=<optimized out>) at
m2/gm2-compiler-boot/M2Comp.c:760
#5 0x0000000011007048 in init_PerCompilationInit (filename=0x7ffffffff641
"../../../../libgm2/libm2min/../../gcc/m2/gm2-libs-min/M2RTS.mod") at
../../gcc/m2/gm2-gcc/init.cc:195
#6 0x0000000010fd505c in gm2_parse_input_files (filename_count=1,
filenames=0x11ef2fd0) at ../../gcc/m2/gm2-lang.cc:451
#7 gm2_langhook_parse_file () at ../../gcc/m2/gm2-lang.cc:458
#8 0x000000001127f54c in compile_file () at ../../gcc/toplev.cc:447
#9 0x0000000010892d0c in do_compile (no_backend=false) at
../../gcc/toplev.cc:2128
#10 toplev::main (this=<optimized out>, argc=<optimized out>, argv=<optimized
out>) at ../../gcc/toplev.cc:2282
#11 0x0000000010895c98 in main (argc=49, argv=0x7fffffffee38) at
../../gcc/main.cc:39
in particular in:
#0 vec<unsigned int, va_heap, vl_ptr>::using_auto_storage (this=<optimized
out>) at ../../gcc/vec.h:2218
#1 vec<unsigned int, va_heap, vl_ptr>::release (this=0x7fffffffe570) at
../../gcc/vec.h:1909
#2 auto_vec<unsigned int, 8ul>::~auto_vec (this=0x7fffffffe570,
__in_chrg=<optimized out>) at ../../gcc/vec.h:1574
#3 diagnostic_info::inlining_info::~inlining_info (this=0x7fffffffe570,
__in_chrg=<optimized out>) at ../../gcc/diagnostic.h:137
#4 diagnostic_info::~diagnostic_info (this=0x7fffffffe528,
__in_chrg=<optimized out>) at ../../gcc/diagnostic.h:111
#5 m2linemap_WarningAtf (location=<optimized out>, message=0x11f57210 "In
procedure 'RegisterModule': unused parameter 'name' in procedure
'RegisterModule'")
at ../../gcc/m2/gm2-gcc/m2linemap.cc:211
inside of that.
Seems the problem is that the return address is clobbered on the stack.
M2Emit_EmitError at the start saves the link register to 16(r1):
0x000000001111bab0 <M2Emit_EmitError(unsigned int, unsigned int, unsigned
int, DynamicStrings_String)+0>: lis r2,4563
0x000000001111bab4 <M2Emit_EmitError(unsigned int, unsigned int, unsigned
int, DynamicStrings_String)+4>: addi r2,r2,29696
=> 0x000000001111bab8 <M2Emit_EmitError(unsigned int, unsigned int, unsigned
int, DynamicStrings_String)+8>: mflr r0
0x000000001111babc <M2Emit_EmitError(unsigned int, unsigned int, unsigned
int, DynamicStrings_String)+12>: std r31,-8(r1)
0x000000001111bac0 <M2Emit_EmitError(unsigned int, unsigned int, unsigned
int, DynamicStrings_String)+16>: std r0,16(r1)
(0x000000001102fb0c is stored to 0x7fffffffe610 in my case).
But then:
Dump of assembler code for function m2linemap_WarningAtf(location_t, char
const*, ...):
0x0000000010ffc2e0 <+0>: lis r2,4563
0x0000000010ffc2e4 <+4>: addi r2,r2,29696
0x0000000010ffc2e8 <+8>: mflr r0
0x0000000010ffc2ec <+12>: std r30,-16(r1)
0x0000000010ffc2f0 <+16>: std r31,-8(r1)
0x0000000010ffc2f4 <+20>: std r0,16(r1)
0x0000000010ffc2f8 <+24>: stdu r1,-368(r1)
0x0000000010ffc2fc <+28>: vspltisw v0,0
0x0000000010ffc300 <+32>: lis r11,-32768
0x0000000010ffc304 <+36>: mr r30,r4
0x0000000010ffc308 <+40>: ori r11,r11,8
0x0000000010ffc30c <+44>: std r5,416(r1)
0x0000000010ffc310 <+48>: std r6,424(r1)
0x0000000010ffc314 <+52>: xxswapd vs0,vs32
0x0000000010ffc318 <+56>: li r0,0
0x0000000010ffc31c <+60>: clrldi r11,r11,32
0x0000000010ffc320 <+64>: std r7,432(r1)
=> 0x0000000010ffc324 <+68>: std r8,440(r1)
overwrites it.
Now the sizes of the automatic variables in m2linemap_WarningAtf are:
(gdb) p sizeof (diagnostic)
$42 = 136
(gdb) p sizeof (ap)
$43 = 8
(gdb) p sizeof (richloc)
$44 = 168
sum 312 bytes, the frame is 368 bytes. But where do those std r{5,6,7,8}
stores to 4{16,24,32,40}(r1) come from is something I haven't figured out yet,
probably register saves, but why does that overwrite the saved link register?
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
2022-12-16 15:53 ` [Bug modula2/108147] " jakub at gcc dot gnu.org
@ 2022-12-16 16:01 ` jakub at gcc dot gnu.org
2022-12-16 16:02 ` segher at gcc dot gnu.org
` (13 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-16 16:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
M2Emit_EmitError is:
71 extern "C" void M2Emit_EmitError (unsigned int error, unsigned int
note, unsigned int token, DynamicStrings_String message)
72 {
73 if (error)
74 {
75 m2linemap_ErrorAtf (M2LexBuf_TokenToLocation (token),
DynamicStrings_string (message));
76 }
77 else if (note)
78 {
79 /* avoid dangling else. */
80 m2linemap_NoteAtf (M2LexBuf_TokenToLocation (token),
DynamicStrings_string (message));
81 }
82 else
83 {
84 /* avoid dangling else. */
85 m2linemap_WarningAtf (M2LexBuf_TokenToLocation (token),
DynamicStrings_string (message));
86 }
87 }
Dump of assembler code for function M2Emit_EmitError(unsigned int, unsigned
int, unsigned int, DynamicStrings_String):
0x000000001111bab0 <+0>: lis r2,4563
0x000000001111bab4 <+4>: addi r2,r2,29696
0x000000001111bab8 <+8>: mflr r0
0x000000001111babc <+12>: std r31,-8(r1)
0x000000001111bac0 <+16>: std r0,16(r1)
0x000000001111bac4 <+20>: stdu r1,-48(r1)
0x000000001111bac8 <+24>: cmpdi r3,0
0x000000001111bacc <+28>: mr r31,r6
0x000000001111bad0 <+32>: mr r3,r5
0x000000001111bad4 <+36>: bne 0x1111bb60 <M2Emit_EmitError(unsigned
int, unsigned int, unsigned int, DynamicStrings_String)+176>
0x000000001111bad8 <+40>: cmpdi r4,0
0x000000001111badc <+44>: bne 0x1111bb20 <M2Emit_EmitError(unsigned
int, unsigned int, unsigned int, DynamicStrings_String)+112>
0x000000001111bae0 <+48>: bl 0x11054d48
<M2LexBuf_TokenToLocation(unsigned int)+8>
0x000000001111bae4 <+52>: nop
0x000000001111bae8 <+56>: mr r9,r3
0x000000001111baec <+60>: mr r3,r31
0x000000001111baf0 <+64>: mr r31,r9
0x000000001111baf4 <+68>: bl 0x1111f118
<DynamicStrings_string(DynamicStrings_String)+8>
0x000000001111baf8 <+72>: nop
0x000000001111bafc <+76>: mr r4,r3
0x000000001111bb00 <+80>: mr r3,r31
0x000000001111bb04 <+84>: bl 0x10ffc2e8
<m2linemap_WarningAtf(location_t, char const*, ...)+8>
0x000000001111bb08 <+88>: nop
0x000000001111bb0c <+92>: addi r1,r1,48
0x000000001111bb10 <+96>: ld r0,16(r1)
0x000000001111bb14 <+100>: ld r31,-8(r1)
0x000000001111bb18 <+104>: mtlr r0
0x000000001111bb1c <+108>: blr
0x000000001111bb20 <+112>: bl 0x11054d48
<M2LexBuf_TokenToLocation(unsigned int)+8>
0x000000001111bb24 <+116>: nop
0x000000001111bb28 <+120>: mr r9,r3
0x000000001111bb2c <+124>: mr r3,r31
0x000000001111bb30 <+128>: mr r31,r9
0x000000001111bb34 <+132>: bl 0x1111f118
<DynamicStrings_string(DynamicStrings_String)+8>
0x000000001111bb38 <+136>: nop
0x000000001111bb3c <+140>: mr r4,r3
0x000000001111bb40 <+144>: mr r3,r31
0x000000001111bb44 <+148>: bl 0x10ffc448
<m2linemap_NoteAtf(location_t, char const*, ...)+8>
0x000000001111bb48 <+152>: nop
0x000000001111bb4c <+156>: addi r1,r1,48
0x000000001111bb50 <+160>: ld r0,16(r1)
0x000000001111bb54 <+164>: ld r31,-8(r1)
0x000000001111bb58 <+168>: mtlr r0
0x000000001111bb5c <+172>: blr
0x000000001111bb60 <+176>: bl 0x11054d48
<M2LexBuf_TokenToLocation(unsigned int)+8>
0x000000001111bb64 <+180>: nop
0x000000001111bb68 <+184>: mr r9,r3
0x000000001111bb6c <+188>: mr r3,r31
0x000000001111bb70 <+192>: mr r31,r9
0x000000001111bb74 <+196>: bl 0x1111f118
<DynamicStrings_string(DynamicStrings_String)+8>
0x000000001111bb78 <+200>: nop
0x000000001111bb7c <+204>: mr r4,r3
0x000000001111bb80 <+208>: mr r3,r31
0x000000001111bb84 <+212>: bl 0x10ffc188
<m2linemap_ErrorAtf(location_t, char const*, ...)+8>
0x000000001111bb88 <+216>: nop
0x000000001111bb8c <+220>: addi r1,r1,48
0x000000001111bb90 <+224>: ld r0,16(r1)
0x000000001111bb94 <+228>: ld r31,-8(r1)
0x000000001111bb98 <+232>: mtlr r0
0x000000001111bb9c <+236>: blr
0x000000001111bba0 <+240>: .long 0x0
0x000000001111bba4 <+244>: .long 0x1000900
0x000000001111bba8 <+248>: .long 0x180
while the callee is:
200 void
201 m2linemap_WarningAtf (location_t location, const char *message, ...)
202 {
203 diagnostic_info diagnostic;
204 va_list ap;
205 rich_location richloc (line_table, location);
206
207 va_start (ap, message);
208 diagnostic_set_info (&diagnostic, message, &ap, &richloc,
DK_WARNING);
209 diagnostic_report_diagnostic (global_dc, &diagnostic);
210 va_end (ap);
211 }
with full disassembly above.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
2022-12-16 15:53 ` [Bug modula2/108147] " jakub at gcc dot gnu.org
2022-12-16 16:01 ` jakub at gcc dot gnu.org
@ 2022-12-16 16:02 ` segher at gcc dot gnu.org
2022-12-16 16:29 ` jakub at gcc dot gnu.org
` (12 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: segher at gcc dot gnu.org @ 2022-12-16 16:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
--- Comment #3 from Segher Boessenkool <segher at gcc dot gnu.org> ---
> 0x0000000010ffc2e0 <+0>: lis r2,4563
> 0x0000000010ffc2e4 <+4>: addi r2,r2,29696
> 0x0000000010ffc2e8 <+8>: mflr r0
> 0x0000000010ffc2ec <+12>: std r30,-16(r1)
> 0x0000000010ffc2f0 <+16>: std r31,-8(r1)
> 0x0000000010ffc2f4 <+20>: std r0,16(r1)
> 0x0000000010ffc2f8 <+24>: stdu r1,-368(r1)
> 0x0000000010ffc2fc <+28>: vspltisw v0,0
> 0x0000000010ffc300 <+32>: lis r11,-32768
> 0x0000000010ffc304 <+36>: mr r30,r4
> 0x0000000010ffc308 <+40>: ori r11,r11,8
> 0x0000000010ffc30c <+44>: std r5,416(r1)
> 0x0000000010ffc310 <+48>: std r6,424(r1)
> 0x0000000010ffc314 <+52>: xxswapd vs0,vs32
> 0x0000000010ffc318 <+56>: li r0,0
> 0x0000000010ffc31c <+60>: clrldi r11,r11,32
> 0x0000000010ffc320 <+64>: std r7,432(r1)
> => 0x0000000010ffc324 <+68>: std r8,440(r1)
> overwrites it.
> Now the sizes of the automatic variables in m2linemap_WarningAtf are:
> (gdb) p sizeof (diagnostic)
> $42 = 136
> (gdb) p sizeof (ap)
> $43 = 8
> (gdb) p sizeof (richloc)
> $44 = 168
> sum 312 bytes, the frame is 368 bytes. But where do those std r{5,6,7,8}
> stores to 4{16,24,32,40}(r1) come from is something I haven't figured out
> yet, probably register saves, but why does that overwrite the saved link
> register?
Those look like register saves yes. But the saved LR is at 384, not at 440?
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
` (2 preceding siblings ...)
2022-12-16 16:02 ` segher at gcc dot gnu.org
@ 2022-12-16 16:29 ` jakub at gcc dot gnu.org
2022-12-16 16:39 ` segher at gcc dot gnu.org
` (11 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-16 16:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
=> 0x000000001111bac0 <M2Emit_EmitError(unsigned int, unsigned int, unsigned
int, DynamicStrings_String)+16>: std r0,16(r1)
(gdb) p/x $r0
$46 = 0x1102fb0c
(gdb) p/x $r1
$47 = 0x7fffffffe600
so lr stored to 0x7fffffffe610, then
0x000000001111bac4 <M2Emit_EmitError(unsigned int, unsigned int, unsigned
int, DynamicStrings_String)+20>: stdu r1,-48(r1)
On entry to m2linemap_WarningAtf r1 is still 0x7fffffffe5d0, and the function
then does
0x0000000010ffc2f8 <+24>: stdu r1,-368(r1)
and 0x7fffffffe5d0 - 368 + 432:
0x0000000010ffc320 <+64>: std r7,432(r1)
0x0000000010ffc324 <+68>: std r8,440(r1)
is exactly at 0x7fffffffe610 where it overwrites the saved lr of parent.
I have double checked and M2Emit.c should see the
EXTERN void m2linemap_WarningAtf (location_t location, const char *message,
...);
prototype for the function, so both should agree it is varargs.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
` (3 preceding siblings ...)
2022-12-16 16:29 ` jakub at gcc dot gnu.org
@ 2022-12-16 16:39 ` segher at gcc dot gnu.org
2022-12-16 16:42 ` jakub at gcc dot gnu.org
` (10 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: segher at gcc dot gnu.org @ 2022-12-16 16:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=100799
--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Ah, it overwrites the saved LR some frame up, it writes to some wrong location
on the stack. It thinks the parameter save area is there.
This is eerily like PR100799.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
` (4 preceding siblings ...)
2022-12-16 16:39 ` segher at gcc dot gnu.org
@ 2022-12-16 16:42 ` jakub at gcc dot gnu.org
2022-12-16 17:56 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-16 16:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Actually, I see:
grep WarningAtf /tmp/*.ii
/tmp/M2Emit.ii:extern void m2linemap_WarningAtf (m2linemap_location_t location,
void * message);
/tmp/M2Emit.ii: m2linemap_WarningAtf (M2LexBuf_TokenToLocation (token),
DynamicStrings_string (message));
/tmp/m2linemap.ii:extern "C" void m2linemap_WarningAtf (location_t location,
const char *message, ...);
/tmp/m2linemap.ii:extern "C" void WarningAtf (location_t location, const char
*message, ...);
/tmp/m2linemap.ii:m2linemap_WarningAtf (location_t location, const char
*message, ...)
so there is indeed a mismatch between the caller which is told
m2linemap_WarningAtf is not varargs function,
and callee which compiles varargs function.
The preprocessed source says the wrong prototype comes from
m2/gm2-gcc/Gm2linemap.h
and I see the mismatch even in my x86_64-linux bootstrap, just the calling
convention doesn't care,
while powerpc64le-linux one clearly does care.
The first two lines of Gm2linemap.h are
/* do not edit automatically generated by mc from m2linemap. */
/* m2linemap.def provides access to GCC location_t.
m2linemap.def contains:
PROCEDURE ErrorAt (location: location_t; message: ADDRESS) ;
(*
PROCEDURE ErrorAtf (location: location_t; message: ADDRESS; ...) ;
PROCEDURE WarningAtf (location: location_t; message: ADDRESS; ...) ;
PROCEDURE NoteAtf (location: location_t; message: ADDRESS; ...) ;
*)
PROCEDURE ErrorAtf (location: location_t; message: ADDRESS) ;
PROCEDURE WarningAtf (location: location_t; message: ADDRESS) ;
PROCEDURE NoteAtf (location: location_t; message: ADDRESS) ;
so I guess it is known there is a mismatch and perhaps it isn't representable
in Modula-2,
but still this will never work on powerpc64le. So, could there be some
wrappers around the ... functions that just pass no arguments to them and are
callable from Modula-2?
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
` (5 preceding siblings ...)
2022-12-16 16:42 ` jakub at gcc dot gnu.org
@ 2022-12-16 17:56 ` jakub at gcc dot gnu.org
2022-12-16 18:02 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-16 17:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Assignee|gaius at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2022-12-16
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 54115
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54115&action=edit
gcc13-pr108147.patch
Untested fix.
One thing I wonder about though, does the FE guarantee that the % chars never
appear in the diagnostic strings? If not, we should incrementally call the
varargs functions with "%s", message rather than message (including error_at
and
internal_function).
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
` (6 preceding siblings ...)
2022-12-16 17:56 ` jakub at gcc dot gnu.org
@ 2022-12-16 18:02 ` jakub at gcc dot gnu.org
2022-12-16 18:27 ` segher at gcc dot gnu.org
` (7 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-16 18:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Short test that shows that on powerpc64le-linux:
void foo (int, ...);
void bar (int);
int baz (void) { foo (1); return 0; }
int qux (void) { bar (1); return 0; }
one gets at -O2 96 byte sized frame in baz case while only 32 byte sized frame
in qux.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
` (7 preceding siblings ...)
2022-12-16 18:02 ` jakub at gcc dot gnu.org
@ 2022-12-16 18:27 ` segher at gcc dot gnu.org
2022-12-16 18:29 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: segher at gcc dot gnu.org @ 2022-12-16 18:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
--- Comment #9 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #8)
> Short test that shows that on powerpc64le-linux:
> void foo (int, ...);
> void bar (int);
> int baz (void) { foo (1); return 0; }
> int qux (void) { bar (1); return 0; }
> one gets at -O2 96 byte sized frame in baz case while only 32 byte sized
> frame in qux.
This is because of crtl->outgoing_args_size for varargs functions. It is not
specific to ELFv2 afaics? Not sure why it seems to be easier to hit problems
there either.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
` (8 preceding siblings ...)
2022-12-16 18:27 ` segher at gcc dot gnu.org
@ 2022-12-16 18:29 ` jakub at gcc dot gnu.org
2022-12-16 23:10 ` gaius at gcc dot gnu.org
` (5 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-16 18:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #9)
> This is because of crtl->outgoing_args_size for varargs functions. It is not
> specific to ELFv2 afaics? Not sure why it seems to be easier to hit problems
> there either.
We only build ppc64le these days in Fedora, so that is the only power arch I
was testing (plus x86_64, i686, aarch64 and s390x).
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
` (9 preceding siblings ...)
2022-12-16 18:29 ` jakub at gcc dot gnu.org
@ 2022-12-16 23:10 ` gaius at gcc dot gnu.org
2022-12-16 23:37 ` gaius at gcc dot gnu.org
` (4 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: gaius at gcc dot gnu.org @ 2022-12-16 23:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
Gaius Mulley <gaius at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gaius at gcc dot gnu.org
--- Comment #11 from Gaius Mulley <gaius at gcc dot gnu.org> ---
Yes is looks as if '%' could be propagated though into the first parameter.
Changes could be made to m2linemap.cc to bump the parameters as you say with
"%s" as the first.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
` (10 preceding siblings ...)
2022-12-16 23:10 ` gaius at gcc dot gnu.org
@ 2022-12-16 23:37 ` gaius at gcc dot gnu.org
2022-12-18 15:50 ` segher at gcc dot gnu.org
` (3 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: gaius at gcc dot gnu.org @ 2022-12-16 23:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
--- Comment #12 from Gaius Mulley <gaius at gcc dot gnu.org> ---
The patch LGTM.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
` (11 preceding siblings ...)
2022-12-16 23:37 ` gaius at gcc dot gnu.org
@ 2022-12-18 15:50 ` segher at gcc dot gnu.org
2022-12-19 8:39 ` amodra at gmail dot com
` (2 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: segher at gcc dot gnu.org @ 2022-12-18 15:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
--- Comment #13 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Gaius Mulley from comment #11)
> Yes is looks as if '%' could be propagated though into the first parameter.
> Changes could be made to m2linemap.cc to bump the parameters as you say with
> "%s" as the first.
Compiling with -Wformat-security points out such problems. This is included
in -Wformat=2 which should be in -Wextra at least (but isn't), and would be
good to have in -Wall even imo.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
` (12 preceding siblings ...)
2022-12-18 15:50 ` segher at gcc dot gnu.org
@ 2022-12-19 8:39 ` amodra at gmail dot com
2022-12-19 14:00 ` cvs-commit at gcc dot gnu.org
2022-12-19 14:02 ` jakub at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: amodra at gmail dot com @ 2022-12-19 8:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amodra at gmail dot com
--- Comment #14 from Alan Modra <amodra at gmail dot com> ---
In C it would also be OK to simply not prototype the problem functions. No
prototype is better than a lying prototype..
eg.
void f1 (int, int);
void f2 (int, ...);
void f3 ();
int g1 (void) { f1 (1, 2); return 0; }
int g2 (void) { f2 (1, 2); return 0; }
int g3 (void) { f3 (1, 2); return 0; }
shows g1 with a frame of 32 bytes, g2 and g3 with 96.
We hit this sort of problem on ELFv2 because the ABI allows omitting the
64-byte paramater save area when the callee is known not to use it. The idea
of course is to minimize stack frames. (ELFv2 minimum frame is 32 bytes, ELFv1
which always allocates param save has a minimum of 112 byes.) Variadic
functions on both ABIs make use of the parameter save area because PowerPC64
uses a simple va_list type, a pointer to memory, requiring variadic functions
to save incoming arguments in registers to the parameter save area.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
` (13 preceding siblings ...)
2022-12-19 8:39 ` amodra at gmail dot com
@ 2022-12-19 14:00 ` cvs-commit at gcc dot gnu.org
2022-12-19 14:02 ` jakub at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-12-19 14:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
--- Comment #15 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:158b18ffa510105b239bd2f4a253ed33e21fcebc
commit r13-4781-g158b18ffa510105b239bd2f4a253ed33e21fcebc
Author: Jakub Jelinek <jakub@redhat.com>
Date: Mon Dec 19 14:20:36 2022 +0100
modula2: Fix up bootstrap on powerpc64le-linux [PR108147]
As mentioned in the PR, bootstrap with m2 enabled currently fails
on powerpc64le-linux, we get weird ICE after printing some diagnostics.
The problem is that mc creates from *.def prototypes like
extern void m2linemap_WarningAtf (m2linemap_location_t location, void *
message);
but the actual function definitions use
void m2linemap_WarningAtf (m2linemap_location_t location, void * message,
...) { code }
and on powerpc64le-linux such lying about the prototype results in
wrong-code, on the caller side we assume the function isn't varargs
and so don't reserve 64 bytes in the frame for it, while the callee
relies on the area being reserved and stores into it.
Fixed by adding non-stdarg wrappers around stdarg functions (because
we want va_list and pass it to diagnostics functions).
2022-12-19 Jakub Jelinek <jakub@redhat.com>
PR modula2/108147
* gm2-gcc/m2linemap.def (ErrorAtf, WarningAtf, NoteAtf):
Comment out prototypes with varargs.
* gm2-gcc/m2linemap.h (m2linemap_ErrorAtf, m2linemap_WarningAtf,
m2linemap_NoteAtf): No longer varargs.
* gm2-gcc/m2linemap.cc (m2linemap_ErrorAtf): Turned into a
non-varargs wrapper around ...
(m2linemap_ErrorAtf_1): ... this. New static function.
(m2linemap_WarningAtf): Turned into a non-varargs wrapper around
...
(m2linemap_WarningAtf_1): ... this. New static function.
(m2linemap_NoteAtf): Turned into a non-varargs wrapper around ...
(m2linemap_NoteAtf_1): ... this. New static function.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
` (14 preceding siblings ...)
2022-12-19 14:00 ` cvs-commit at gcc dot gnu.org
@ 2022-12-19 14:02 ` jakub at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-12-19 14:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed now.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2022-12-19 14:02 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-16 15:15 [Bug modula2/108147] New: Bootstrap failure on powerpc64le-linux with m2 jakub at gcc dot gnu.org
2022-12-16 15:53 ` [Bug modula2/108147] " jakub at gcc dot gnu.org
2022-12-16 16:01 ` jakub at gcc dot gnu.org
2022-12-16 16:02 ` segher at gcc dot gnu.org
2022-12-16 16:29 ` jakub at gcc dot gnu.org
2022-12-16 16:39 ` segher at gcc dot gnu.org
2022-12-16 16:42 ` jakub at gcc dot gnu.org
2022-12-16 17:56 ` jakub at gcc dot gnu.org
2022-12-16 18:02 ` jakub at gcc dot gnu.org
2022-12-16 18:27 ` segher at gcc dot gnu.org
2022-12-16 18:29 ` jakub at gcc dot gnu.org
2022-12-16 23:10 ` gaius at gcc dot gnu.org
2022-12-16 23:37 ` gaius at gcc dot gnu.org
2022-12-18 15:50 ` segher at gcc dot gnu.org
2022-12-19 8:39 ` amodra at gmail dot com
2022-12-19 14:00 ` cvs-commit at gcc dot gnu.org
2022-12-19 14:02 ` jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).