* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
@ 2013-12-30 23:43 ` jakub at gcc dot gnu.org
2013-12-31 8:17 ` trippels at gcc dot gnu.org
` (22 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-12-30 23:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Weird, I thought the kernel is compiled even with -mno-sse, so there shouldn't
be AVX used and thus no need for realignment anywhere. What arch is that?
i?86 or x86_64? Can you bisect which *.o file matters for this, and attach the
preprocessed source plus command line options? Perhaps start with comparison
of *.o files between r206242 and r206243? I'd be really surprised if it on the
kernel made a difference on many source files.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
2013-12-30 23:43 ` [Bug tree-optimization/59644] " jakub at gcc dot gnu.org
@ 2013-12-31 8:17 ` trippels at gcc dot gnu.org
2013-12-31 8:18 ` trippels at gcc dot gnu.org
` (21 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: trippels at gcc dot gnu.org @ 2013-12-31 8:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #2 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
kernel/printk/printk.o gets miscompiled.
% gcc -Wp,-MD,kernel/printk/.printk.o.d -nostdinc -isystem
/var/tmp/gcc_test_/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include
-I/var/tmp/linux/arch/x86/include -Iarch/x86/include/generated -Iinclude
-I/var/tmp/linux/arch/x86/include/uapi -Iarch/x86/include/generated/uapi
-I/var/tmp/linux/include/uapi -Iinclude/generated/uapi -include
/var/tmp/linux/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-fno-delete-null-pointer-checks -O2 -m64 -mno-mmx -mno-sse
-mpreferred-stack-boundary=3 -march=native -mno-red-zone -mcmodel=kernel
-funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1
-DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -pipe -Wno-sign-compare
-fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx
-Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable
-fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign
-fno-strict-overflow -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -DCC_HAVE_ASM_GOTO -D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(printk)" -D"KBUILD_MODNAME=KBUILD_STR(printk)"
-c -o kernel/printk/printk.o kernel/printk/printk.c --save-temps
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
2013-12-30 23:43 ` [Bug tree-optimization/59644] " jakub at gcc dot gnu.org
2013-12-31 8:17 ` trippels at gcc dot gnu.org
@ 2013-12-31 8:18 ` trippels at gcc dot gnu.org
2013-12-31 8:19 ` trippels at gcc dot gnu.org
` (20 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: trippels at gcc dot gnu.org @ 2013-12-31 8:18 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #3 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Created attachment 31547
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31547&action=edit
testcase
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (2 preceding siblings ...)
2013-12-31 8:18 ` trippels at gcc dot gnu.org
@ 2013-12-31 8:19 ` trippels at gcc dot gnu.org
2013-12-31 8:20 ` trippels at gcc dot gnu.org
` (19 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: trippels at gcc dot gnu.org @ 2013-12-31 8:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #4 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Created attachment 31548
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31548&action=edit
printk_good assembly
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (3 preceding siblings ...)
2013-12-31 8:19 ` trippels at gcc dot gnu.org
@ 2013-12-31 8:20 ` trippels at gcc dot gnu.org
2013-12-31 8:26 ` trippels at gcc dot gnu.org
` (18 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: trippels at gcc dot gnu.org @ 2013-12-31 8:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #5 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Created attachment 31549
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31549&action=edit
printk_bad assembly
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (4 preceding siblings ...)
2013-12-31 8:20 ` trippels at gcc dot gnu.org
@ 2013-12-31 8:26 ` trippels at gcc dot gnu.org
2013-12-31 11:47 ` jakub at gcc dot gnu.org
` (17 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: trippels at gcc dot gnu.org @ 2013-12-31 8:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #6 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
linux % diff -u kernel/printk/printk.o /var/tmp/linux/kernel/printk/printk.o
--- kernel/printk/printk.o 2013-12-31 09:23:45.569490147 +0100
+++ /var/tmp/linux/kernel/printk/printk.o 2013-12-31 09:23:22.066697479
+0100
@@ -2517,19 +2517,16 @@
printk_emit:
pushq %rbp
movq %rsp, %rbp
- pushq %r10
- leaq -56(%rbp), %rax
- leaq 16(%rbp), %r10
subq $72, %rsp
+ leaq 16(%rbp), %r10
movq %r9, -16(%rbp)
+ leaq -56(%rbp), %rax
leaq -80(%rbp), %r9
- movq %r10, -72(%rbp)
movl $40, -80(%rbp)
+ movq %r10, -72(%rbp)
movq %rax, -64(%rbp)
call vprintk_emit
- addq $72, %rsp
- popq %r10
- popq %rbp
+ leave
ret
.size printk_emit, .-printk_emit
.LCOLDE44:
@@ -2680,28 +2677,25 @@
printk:
pushq %rbp
movq %rsp, %rbp
- pushq %r10
- leaq -56(%rbp), %rax
- leaq 16(%rbp), %r10
subq $72, %rsp
+ leaq 16(%rbp), %r10
movq %rsi, -48(%rbp)
movq %rdx, -40(%rbp)
movq %rcx, -32(%rbp)
movq %r8, -24(%rbp)
- xorl %ecx, %ecx
+ leaq -56(%rbp), %rax
movq %r9, -16(%rbp)
movq %rdi, %r8
leaq -80(%rbp), %r9
+ xorl %ecx, %ecx
xorl %edx, %edx
orl $-1, %esi
xorl %edi, %edi
- movq %r10, -72(%rbp)
movl $8, -80(%rbp)
+ movq %r10, -72(%rbp)
movq %rax, -64(%rbp)
call vprintk_emit
- addq $72, %rsp
- popq %r10
- popq %rbp
+ leave
ret
.size printk, .-printk
.LCOLDE47:
@@ -4052,7 +4046,6 @@
printk_sched:
pushq %rbp
movq %rsp, %rbp
- pushq %r10
pushq %rbx
leaq 16(%rbp), %r10
subq $80, %rsp
@@ -4105,7 +4098,6 @@
#NO_APP
addq $80, %rsp
popq %rbx
- popq %r10
popq %rbp
ret
.size printk_sched, .-printk_sched
@@ -4691,26 +4683,23 @@
dump_stack_set_arch_desc:
pushq %rbp
movq %rsp, %rbp
- pushq %r10
- leaq -56(%rbp), %rax
- leaq 16(%rbp), %r10
subq $72, %rsp
+ leaq 16(%rbp), %r10
movq %rsi, -48(%rbp)
movq %rdx, -40(%rbp)
movq %rcx, -32(%rbp)
+ leaq -56(%rbp), %rax
movq %rdi, %rdx
leaq -80(%rbp), %rcx
movl $128, %esi
movq $dump_stack_arch_desc_str, %rdi
- movq %r10, -72(%rbp)
movq %r8, -24(%rbp)
movq %r9, -16(%rbp)
movl $8, -80(%rbp)
+ movq %r10, -72(%rbp)
movq %rax, -64(%rbp)
call vsnprintf
- addq $72, %rsp
- popq %r10
- popq %rbp
+ leave
ret
.size dump_stack_set_arch_desc, .-dump_stack_set_arch_desc
.LCOLDE92:
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (5 preceding siblings ...)
2013-12-31 8:26 ` trippels at gcc dot gnu.org
@ 2013-12-31 11:47 ` jakub at gcc dot gnu.org
2013-12-31 13:03 ` trippels at gcc dot gnu.org
` (16 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-12-31 11:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hjl.tools at gmail dot com,
| |hubicka at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, on this source file the only differences caused by r206243 are caused by
the
ix86_save_reg hunk, the 4 functions in question before pro_and_epilogue pass
don't need dynamic stack realignment, drap_reg is set to r10 but isn't live at
the beginning of the function, just used somewhere in the function. Previously
we'd save/restore it anyway, I assume just in case it would be used by the
epilogue if drap would be needed there (but it isn't), after my commit it isn't
saved (r10 is call used register, so there is no point in saving/restoring it).
So, I fail to see why this change is wrong, unless the kernel say calls one of
those functions from assembly and mistakenly assumes r10 is not clobbered by
the call.
Note that if stack realignment would happen, then r10 would not be preserved
even before the patch, in that case, while r10 is saved/restored, it is saved
after it has been set to the DRAP value.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (6 preceding siblings ...)
2013-12-31 11:47 ` jakub at gcc dot gnu.org
@ 2013-12-31 13:03 ` trippels at gcc dot gnu.org
2014-01-06 8:21 ` trippels at gcc dot gnu.org
` (15 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: trippels at gcc dot gnu.org @ 2013-12-31 13:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #8 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
>From the printk.i:
38333 int printk_emit(int facility, int level,
38334 const char *dict, size_t dictlen,
38335 const char *fmt, ...)
38336 {
38337 va_list args;
38338 int r;
38339
38340 __builtin_va_start(args,fmt);
38341 r = vprintk_emit(facility, level, dict, dictlen, fmt, args);
38342 __builtin_va_end(args);
38343
38344 return r;
38345 }
38346 ;
38347 # 1676 "kernel/printk/printk.c"
38348 int printk(const char *fmt, ...)
38349 {
38350 va_list args;
38351 int r;
38352 # 1689 "kernel/printk/printk.c"
38353 __builtin_va_start(args,fmt);
38354 r = vprintk_emit(0, -1, ((void *)0), 0, fmt, args);
38355 __builtin_va_end(args);
38356
38357 return r;
38358 }
38359 ;
dump_stack_set_arch_desc is also a call wrapped by __builtin_va_start
__builtin_va_end.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (7 preceding siblings ...)
2013-12-31 13:03 ` trippels at gcc dot gnu.org
@ 2014-01-06 8:21 ` trippels at gcc dot gnu.org
2014-01-06 8:48 ` trippels at gcc dot gnu.org
` (14 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: trippels at gcc dot gnu.org @ 2014-01-06 8:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.9.0
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (8 preceding siblings ...)
2014-01-06 8:21 ` trippels at gcc dot gnu.org
@ 2014-01-06 8:48 ` trippels at gcc dot gnu.org
2014-01-06 9:08 ` jakub at gcc dot gnu.org
` (13 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: trippels at gcc dot gnu.org @ 2014-01-06 8:48 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #11 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #10)
> If you have time, could you please try to bisect manually which of the 4
> functions matters for the bootstrap failure?
> Compile printk.s with both compilers and apply by hand only portions of the
> diff that are for individual routines?
Yes. I will try this later.
In the meantime I've found out that drivers/acpi/acpica/utxferror.c also
gets miscompiled. If I replace this two object files with good ones and
relink the kernel, everything runs fine (under qemu)...
utxferror shows the same pattern as seen in printk.
--- drivers/acpi/acpica/utxferror.o 2014-01-05 13:02:02.805477131 +0100
+++ /var/tmp/utxferror.o 2014-01-05 13:01:41.149293740 +0100
@@ -16,14 +16,13 @@
movq %rsp, %rbp
pushq %r13
pushq %r12
- pushq %r10
pushq %rbx
leaq 16(%rbp), %r10
movq %rdi, %rbx
movq $.LC0, %rdi
movq %rdx, %r13
- subq $80, %rsp
movl %esi, %r12d
+ subq $80, %rsp
movq %rcx, -56(%rbp)
movq %r8, -48(%rbp)
movq %r9, -40(%rbp)
@@ -45,7 +44,6 @@
call acpi_os_printf
addq $80, %rsp
popq %rbx
- popq %r10
popq %r12
popq %r13
popq %rbp
@@ -69,14 +67,13 @@
movq %rsp, %rbp
pushq %r13
pushq %r12
- pushq %r10
pushq %rbx
leaq 16(%rbp), %r10
movq %rdi, %rbx
movl %edx, %edi
movq %rcx, %r13
- subq $80, %rsp
movl %esi, %r12d
+ subq $80, %rsp
movq %r8, -48(%rbp)
movq %r9, -40(%rbp)
movq %r10, -112(%rbp)
@@ -101,7 +98,6 @@
call acpi_os_printf
addq $80, %rsp
popq %rbx
- popq %r10
popq %r12
popq %r13
popq %rbp
...
>From drivers/acpi/acpica/utxferror.c:
void ACPI_INTERNAL_VAR_XFACE
acpi_error(const char *module_name, u32 line_number, const char *format, ...)
{
va_list arg_list;
ACPI_MSG_REDIRECT_BEGIN;
acpi_os_printf(ACPI_MSG_ERROR);
va_start(arg_list, format);
acpi_os_vprintf(format, arg_list);
ACPI_MSG_SUFFIX;
va_end(arg_list);
ACPI_MSG_REDIRECT_END;
}
ACPI_EXPORT_SYMBOL(acpi_error)
void ACPI_INTERNAL_VAR_XFACE
acpi_exception(const char *module_name,
u32 line_number, acpi_status status, const char *format, ...)
{
va_list arg_list;
ACPI_MSG_REDIRECT_BEGIN;
acpi_os_printf(ACPI_MSG_EXCEPTION "%s, ",
acpi_format_exception(status));
va_start(arg_list, format);
acpi_os_vprintf(format, arg_list);
ACPI_MSG_SUFFIX;
va_end(arg_list);
ACPI_MSG_REDIRECT_END;
}
...
Strangely the changes in drivers/acpi/acpica/uterror.o doesn't seem to
matter (maybe the functions are not called with my config).
--- drivers/acpi/acpica/uterror.o 2014-01-05 13:09:05.216038006 +0100
+++ /var/tmp/uterror.o 2014-01-05 13:08:49.529722280 +0100
@@ -16,8 +16,9 @@
pushq %r14
pushq %r13
pushq %r12
- pushq %rbx
+ pushq %r10
leaq 16(%rbp), %r10
+ pushq %rbx
subq $72, %rsp
andb $32, %cl
movq %r9, -48(%rbp)
@@ -46,6 +47,7 @@
.L1:
addq $72, %rsp
popq %rbx
+ popq %r10
popq %r12
popq %r13
popq %r14
@@ -71,8 +73,9 @@
pushq %r14
pushq %r13
pushq %r12
- pushq %rbx
+ pushq %r10
leaq 16(%rbp), %r10
+ pushq %rbx
subq $72, %rsp
andb $32, %cl
movq %r9, -48(%rbp)
@@ -101,6 +104,7 @@
.L6:
addq $72, %rsp
popq %rbx
+ popq %r10
popq %r12
popq %r13
popq %r14
@@ -126,8 +130,9 @@
pushq %r14
pushq %r13
pushq %r12
- pushq %rbx
+ pushq %r10
leaq 16(%rbp), %r10
+ pushq %rbx
subq $72, %rsp
andb $32, %cl
movq %r9, -48(%rbp)
@@ -156,6 +161,7 @@
.L10:
addq $72, %rsp
popq %rbx
+ popq %r10
popq %r12
popq %r13
popq %r14
Here is the list of all changed object files (good vs. bad) for my
kernel config:
markus@x4 linux % diff -u /var/tmp/out_rev /var/tmp/out_jel
--- /var/tmp/out_rev 2014-01-05 11:41:35.064633494 +0100
+++ /var/tmp/out_jel 2014-01-05 11:55:52.135130812 +0100
@@ -5,24 +5,24 @@
86b5b45da1b54ed6746fa8a457b2821a
arch/x86/boot/compressed/early_serial_console.o
411ebccf66b24511da94ae4a13b62155 arch/x86/boot/compressed/head_64.o
48cd91f938d48dc7eb908dadedcd4f20 arch/x86/boot/compressed/misc.o
-cbc5ecb98704eac0fc091f044b9d809b arch/x86/boot/compressed/piggy.o
+a6f5b1b0e6f5827832edddb6d0ee2d72 arch/x86/boot/compressed/piggy.o
2fff163219ce8dfff09849407f142c3a arch/x86/boot/compressed/string.o
b01ed211b5831f92d73ee6dd3ee0e064 arch/x86/boot/copy.o
c7ed7abc749b387237ee384184d943f4 arch/x86/boot/cpucheck.o
68ff14ada81abb1ace1365704c3c284e arch/x86/boot/cpu.o
c8615d76ec849c1d6896030387c990d3 arch/x86/boot/early_serial_console.o
9747cf6c1e8cd634fc27aab29a83a34f arch/x86/boot/edd.o
-cfd8f479ed5bb8281d47f542709302d1 arch/x86/boot/header.o
+e1e6a16e7904465106ad135ed3259912 arch/x86/boot/header.o
0258b61aa020e3ff6ba29ae845a60dfe arch/x86/boot/main.o
96d3325b9fb43362821555fbd4916a5b arch/x86/boot/mca.o
35ef44c0a00636401b83f4751bc01783 arch/x86/boot/memory.o
690383f7adad217590994a7aee38d717 arch/x86/boot/pmjump.o
89be97c9d51a3c2a24ad8cadbb9eee43 arch/x86/boot/pm.o
-0e13409e48636bf21bba46ed7e880d32 arch/x86/boot/printf.o
+2838040d7fee9bde851daef848afe808 arch/x86/boot/printf.o
76852baa5dde81e795d4991eccdb8ad9 arch/x86/boot/regs.o
1586fb7fe439b4cfeb71c7e287bc1331 arch/x86/boot/string.o
fa2cdef10540afaabc05ac28c243524a arch/x86/boot/tty.o
-39e356419b10d2877b7d367c5afb9dbd arch/x86/boot/version.o
+34b1af91228314fbc0c3770baaf2a6e2 arch/x86/boot/version.o
17bd2a58aca02c1ba720a56c4e512540 arch/x86/boot/video-bios.o
9658738b90c08dc5ea4263fc30ae2f36 arch/x86/boot/video-mode.o
924804797c3b9b41aaddbf642cb96b04 arch/x86/boot/video.o
@@ -301,8 +301,8 @@
c331d714ab3ee9aff57165601afe8963 crypto/scatterwalk.o
3acc5297a53047b6fbdc188740c45499 crypto/shash.o
2e4eca17a0ec831c8c119669eeefe856 crypto/testmgr.o
-637ff9939cbcf5a95bb34b702ec558ac drivers/acpi/acpica/acpi.o
-637ff9939cbcf5a95bb34b702ec558ac drivers/acpi/acpica/built-in.o
+c5f6e4e41be1e6394b97756449c5c196 drivers/acpi/acpica/acpi.o
+c5f6e4e41be1e6394b97756449c5c196 drivers/acpi/acpica/built-in.o
53d63ee0f9b2e4c1f30ff75470af1d6b drivers/acpi/acpica/dsargs.o
63cdb8dc7b9905adc38f3a3311a7df43 drivers/acpi/acpica/dscontrol.o
8c5733c13f9d19d00a2de3c33de9a075 drivers/acpi/acpica/dsfield.o
@@ -424,7 +424,7 @@
f3a0eae44638cff2a0a9d7bd439a7299 drivers/acpi/acpica/utdebug.o
431816b0804e76ab331c65e3580d30dd drivers/acpi/acpica/utdecode.o
bc4f78c0a3f842f699a40ca2296b8e6e drivers/acpi/acpica/utdelete.o
-4c3a41ced7060b40aaf0136c00417e3c drivers/acpi/acpica/uterror.o
+23c02723aa2fecc8d59ebbd742f96e98 drivers/acpi/acpica/uterror.o
a65f3f04f8866fcbbc87ac54289ae34c drivers/acpi/acpica/uteval.o
9f4988cedbfa2cbbd06386b02ca8697b drivers/acpi/acpica/utexcep.o
31a5ca5180a9f786ea8c982eba8712ca drivers/acpi/acpica/utglobal.o
@@ -442,15 +442,15 @@
ba67e1a6de0c0e2b3a2a3f62186da973 drivers/acpi/acpica/utstate.o
94d62f0b051a917df04b719f4ce62be6 drivers/acpi/acpica/utstring.o
328363a3081b9e75c603f7d4818051a0 drivers/acpi/acpica/utxface.o
-a157a5ef7e3357f23a7acf01c22ec856 drivers/acpi/acpica/utxferror.o
+36b3fb3c1b290e006450b1b52ec93d9e drivers/acpi/acpica/utxferror.o
c105339334c858805e68e7de5ae5faf5 drivers/acpi/acpica/utxfinit.o
0ba796759f923c4edf5864bcec672f8d drivers/acpi/acpica/utxfmutex.o
f2a3eb10a186dc6312079f3c45a14ec8 drivers/acpi/acpi_cmos_rtc.o
-00af7e9aa76432e72cf7dda6a0624563 drivers/acpi/acpi.o
+d293786d61e484682501023ab61cdf28 drivers/acpi/acpi.o
5b48c7ecb0b6dc673f1895e4faff5744 drivers/acpi/acpi_platform.o
8f8efe3451af3d754b477ed019561454 drivers/acpi/acpi_processor.o
cbfd730e88f02749d4dd3a0d6665896a drivers/acpi/blacklist.o
-85317d13e5cb8ff44ec3c7ec6a6388be drivers/acpi/built-in.o
+e14cb24351648be6e06c9948865529cf drivers/acpi/built-in.o
d83075d588d639900d7c545cb4d3d3ac drivers/acpi/bus.o
4f857fdbf81e8fc278b2de958f453fa7 drivers/acpi/debugfs.o
3767919e734ff688378fa678d7121764 drivers/acpi/device_pm.o
@@ -458,7 +458,7 @@
5627def90323890574380b9b41fdfc4c drivers/acpi/event.o
7466a10082790cc6d20cdb8eca5a8ad9 drivers/acpi/glue.o
66c57894c980a61c3ecd2cfe81c87070 drivers/acpi/nvs.o
-95bb0175b15324a7a3b2c49298063223 drivers/acpi/osl.o
+0bf120f66aa60f3f16ad5ddfbb44a6c9 drivers/acpi/osl.o
018180b9871a95d3d6352592feffe4df drivers/acpi/pci_irq.o
23a7ccd30bcd3a3f65a4bb96c120d954 drivers/acpi/pci_link.o
76360d130029e43bbac3aa94bafad740 drivers/acpi/pci_root.o
@@ -476,7 +476,7 @@
bb382c3724af7d350261bbcf141f3414 drivers/acpi/sleep.o
6ce5f24b5d7b2ebd91c699098d1ee670 drivers/acpi/sysfs.o
dff9a6fc016308649b5197b8c7796c86 drivers/acpi/tables.o
-14885e648693fadfe5c73a2ea6a46e2f drivers/acpi/utils.o
+f5c8e637e37ce2d6ba43ce2b08da55fb drivers/acpi/utils.o
14c5f8ad0e2ad43e714d84f893b022b8 drivers/acpi/wakeup.o
ab0a4c8c62da160eaae565341c07f202 drivers/amba/built-in.o
c0c8c1019bbec238e2e93ca045ed917f drivers/ata/ahci.o
@@ -519,7 +519,7 @@
b3100c32fd6e5b9b7e7ea2f9b2daad91 drivers/block/loop.o
e556c35f8000c6c7589bd3b8908b5c2c drivers/block/pktcdvd.o
1c1abf383cb42ea816211480be0920b6 drivers/block/virtio_blk.o
-d714348f457b5f107e453879ec267000 drivers/built-in.o
+a4afcca6ac991d722b3def91bf526fd2 drivers/built-in.o
ab0a4c8c62da160eaae565341c07f202 drivers/bus/built-in.o
ccd31fb0dad3396b107854564140c552 drivers/cdrom/built-in.o
52a11290d8e6f6151fe075077db22d59 drivers/cdrom/cdrom.o
@@ -1005,11 +1005,11 @@
f825df4ef57f7066e9c3d42574d9c9a4 drivers/usb/storage/usb-storage.o
e9a1516cd377521ecae7e91e7ee01a0b drivers/usb/storage/usual-tables.o
15e765974e1eec471dd94fa0be73f9a8 drivers/usb/usb-common.o
-48ef781a456d09497dd3bc0d4a0a8840 drivers/vhost/built-in.o
+83cb226a9150eacf289ff9dd0087b061 drivers/vhost/built-in.o
e0f5c3affaa9b135094ab2c18590f04a drivers/vhost/net.o
b54c9f4eed659c4ebcae90a27cb4dc14 drivers/vhost/vhost_net.o
d87e8fc4c9f52cbe11339985ee8c7bce drivers/vhost/vhost.o
-0d35a43d2a06d20d69f256779447ac7c drivers/vhost/vringh.o
+3bc2ff710af7810d462dfff344865b5d drivers/vhost/vringh.o
cede224bfd4753fc43b75659f236a8e9 drivers/video/backlight/backlight.o
f44743b84ad8d8a6096c655224bd186c drivers/video/backlight/built-in.o
a4de8b9a049cba37c643465775a0c434 drivers/video/built-in.o
@@ -1095,7 +1095,7 @@
68875a115f3ba55f21ded7f13f61ce0b fs/bio.o
7b98c5a8b58b8d6a1b857090b6a4ab2b fs/block_dev.o
b9a4aea0fd0876f63d03c761c1299cbb fs/buffer.o
-d14785ba4e68f53119e8f3e4161169a1 fs/built-in.o
+b45e44a0a9c356547ddbca913b738485 fs/built-in.o
5e068dc4fc0c01a00cc4c8bd87435deb fs/char_dev.o
d784eb8b8368a01da3706190e74c7e47 fs/dcache.o
68b62b7e476ea4af01097644cf738615 fs/debugfs/built-in.o
@@ -1114,10 +1114,10 @@
af3d7d5b285f1c3024db511bb6232ca1 fs/ext4/balloc.o
3dd823a5ee4bceb814c1f13cddc0b214 fs/ext4/bitmap.o
f99d5ef1cd83e93411b00b2cd06e2904 fs/ext4/block_validity.o
-80047928a3d5d62886b9bcfa18d50ebd fs/ext4/built-in.o
+333e4fe44ba2c6fa70a7336785e60f12 fs/ext4/built-in.o
0b80c85cc22bd0083a21bd57649cbe98 fs/ext4/dir.o
9fe2d91f70b50071e90391a10e210818 fs/ext4/ext4_jbd2.o
-80047928a3d5d62886b9bcfa18d50ebd fs/ext4/ext4.o
+333e4fe44ba2c6fa70a7336785e60f12 fs/ext4/ext4.o
abecc073741363c783e9c96f77b61a23 fs/ext4/extents.o
8a7936190957d5234e427d5e995762bd fs/ext4/extents_status.o
db26d069911894345951d2e94ce7b051 fs/ext4/file.o
@@ -1128,7 +1128,7 @@
1ad01a26b6d81b0e54638f94fa2a9e81 fs/ext4/inline.o
ba86f47600e1b58ba8df782f8a22ff71 fs/ext4/inode.o
8bb9a58a706c6dfdfe0a9f09ac62a166 fs/ext4/ioctl.o
-c862ec0c06a2401d1cb78db5e46296c9 fs/ext4/mballoc.o
+3314d5a7cbc7a8bf7bf9bac0d266ad78 fs/ext4/mballoc.o
c912dd0752d1589e00f855e20ef23e3f fs/ext4/migrate.o
666774855b24ab1b853f61145cabc131 fs/ext4/mmp.o
aa4a7ce393d2b428ea92b7ad10c52ba5 fs/ext4/move_extent.o
@@ -1140,14 +1140,14 @@
84b02a4423ef363e8dafaa14051d12de fs/ext4/xattr.o
4858583c12b3fb8c35fa3cb74fab81ec fs/ext4/xattr_trusted.o
28c7eae121833651623b25419a51c33a fs/ext4/xattr_user.o
-0c2cd09e1c98ba7bdf949c2f2a9229d4 fs/fat/built-in.o
+7f55a5d112bd548d0c7438ab5a5978b8 fs/fat/built-in.o
bae702761238a5921382f4bcecf1a1b9 fs/fat/cache.o
ba63a63275407a6800e6a74bf1741ac1 fs/fat/dir.o
b0abd746de09578831c74181b5755069 fs/fat/fatent.o
-cd42d0be3cf2c54da811d268ae0798a5 fs/fat/fat.o
+9ca066906671272ad3cf39b871df9869 fs/fat/fat.o
bc3a8667443f579d8e220acd4be03a03 fs/fat/file.o
98de368dbaff27194a14d94d94243d0a fs/fat/inode.o
-73cb74afee3b8f3f0dc435bd041b8cf8 fs/fat/misc.o
+1f523d61693108efdc3dfbc3fc9ae4cc fs/fat/misc.o
42863a7c063584ff7fca34782f332f4b fs/fat/msdos.o
920d316d55e00cc461cc7d978f4da7e5 fs/fat/namei_msdos.o
91d8cd90d4fc8c8be10d5a321c2f2786 fs/fat/namei_vfat.o
@@ -1264,14 +1264,14 @@
01cc9c709f77229ac4383f8d6c98a776 fs/timerfd.o
59a16df4f2bd7a04399f7bab8847b1d6 fs/utimes.o
5e52305d9f3f7f407d29c47286f9fbad fs/xattr.o
-4939c5ee3ed7c87e8c2f6205a6d10a66 init/built-in.o
+c0c65b33b27fa083ab4a96818a55a0f2 init/built-in.o
7080656f7aa984cf73ad9acbeb3fdab5 init/calibrate.o
50bb47316a76b615734a37e72f6851d9 init/do_mounts.o
975070cf28a02c6e675768738dd9a68a init/init_task.o
322d4aa5d3cd16fcfcc5cb5d91fab62a init/main.o
d321721146c48eba65fc60fc8d1bec6d init/mounts.o
383a8bd3a8d5a713ccaf1057acc9c033 init/noinitramfs.o
-57baa63116facf4d8d8f2af86883ef8a init/version.o
+3e6b564319a622055e2cb5ed0535dd7d init/version.o
2f83f522b79ab0e3c91a1a0d99d67e16 ipc/built-in.o
e0c18d50df3d8d265809c1ec3e0f9f2a ipc/ipcns_notifier.o
3f4400b1366f91dafb9e6854b8788590 ipc/ipc_sysctl.o
@@ -1285,7 +1285,7 @@
0beba6fbcbadf7e730cd1d547f005368 ipc/util.o
1a1d081659ea2784f567e3303c2a1e76 kernel/acct.o
fd28ce41d77681d105deba2ee7ac64b7 kernel/async.o
-0b6d4b4204c739330b16a7064556d979 kernel/built-in.o
+b4f014b30cc42dea9c8f3cba095bdbce kernel/built-in.o
c24d866bb64bcd32a5e2b9f59f1067fd kernel/capability.o
0f00a351549e8fe7a3ce50bdbabfd913 kernel/configs.o
648e2dedc987548cf5b1ebbbb537734c kernel/cpu/built-in.o
@@ -1303,7 +1303,7 @@
e8d547275c342fe5a46a168596d53382 kernel/exec_domain.o
cff1ca4e39330c857e640f2df3660a52 kernel/exit.o
321b43688d6065387a712122ac89cdc3 kernel/extable.o
-e8321377f256ab8f6287049ddd705182 kernel/fork.o
+44ec4e8f61289cac93cefa8e837ed099 kernel/fork.o
87671a2d4db4c081c83f250441ff2986 kernel/futex.o
8d786c8d4399a00a5f3261914eb5a3b9 kernel/groups.o
83c9cee100d9a207fb82e4e69e3b05c5 kernel/hrtimer.o
@@ -1337,7 +1337,7 @@
8f206010c35b8983d787bc2cad231134 kernel/locking/spinlock.o
cc91727fe32f95a6d1fcca40826ace02 kernel/notifier.o
e3a99e9d3062cdcd9ddd7b636b5bc251 kernel/nsproxy.o
-a76ab8719b8f59084a9e70066528bdf1 kernel/panic.o
+91f0328dfa9856cf8636018ce35db532 kernel/panic.o
38b578eee3ab734c3f6cffe83bf807ad kernel/params.o
470c5a400fdf0607619df9549f4560d5 kernel/pid.o
09a8e90f2146ceb2e36c2ffc960645b5 kernel/posix-cpu-timers.o
@@ -1346,8 +1346,8 @@
0edc56d2bb12dd26850ae963507ae49f kernel/power/main.o
54f93ee69e7dc3160c320e459f64d751 kernel/power/poweroff.o
d4194de6fcbda21e3e46f2c506d8179a kernel/power/qos.o
-b9ea4b7edc58142c072c8012a62a714f kernel/printk/built-in.o
-ac4106e39942d0869c0481e5f3b5d841 kernel/printk/printk.o
+0aab057009fe3e9467e4cc9ea3cca537 kernel/printk/built-in.o
+bf7d10687e41d8d1dc4169e1032a6da3 kernel/printk/printk.o
b2af710db7a61d14c936641373863229 kernel/ptrace.o
440069c4f01e98e056fa23fab2327d93 kernel/range.o
8696af860f6627461db0ed03b6ed6619 kernel/rcu/built-in.o
@@ -1906,4 +1906,4 @@
55753c94a4295e732790dd300e3fc4b3 virt/kvm/irq_comm.o
62cfac36f0ae7db3b00eca61aa0b49b4 virt/kvm/kvm_main.o
ed482544fd1530ca42c6fbee95157aec virt/kvm/vfio.o
-ad2058c0c76b44d12e6653b259e992f7 vmlinux.o
+b3f991aed320990c6b218e58e2f16d30 vmlinux.o
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (9 preceding siblings ...)
2014-01-06 8:48 ` trippels at gcc dot gnu.org
@ 2014-01-06 9:08 ` jakub at gcc dot gnu.org
2014-01-06 9:17 ` trippels at gcc dot gnu.org
` (12 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-06 9:08 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Markus Trippelsdorf from comment #11)
> (In reply to Jakub Jelinek from comment #10)
> > If you have time, could you please try to bisect manually which of the 4
> > functions matters for the bootstrap failure?
> > Compile printk.s with both compilers and apply by hand only portions of the
> > diff that are for individual routines?
>
> Yes. I will try this later.
> In the meantime I've found out that drivers/acpi/acpica/utxferror.c also
> gets miscompiled. If I replace this two object files with good ones and
> relink the kernel, everything runs fine (under qemu)...
>
> utxferror shows the same pattern as seen in printk.
It is undestandable the patch changes how most/all stdarg functions are
compiled in the kernel, the question is why the kernel cares in certain cases.
Do you get some OOPS in the utxferror case or also silent hang without being
able to tell what is going on? In ACPI case, I'd guess if the routine calls
into BIOS that the BIOS (or whatever qemu uses instead of BIOS) might assume
16-byte stack alignment which is part of the ABI, but the kernel intentionally
only guarantees 8-byte stack alignment.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (10 preceding siblings ...)
2014-01-06 9:08 ` jakub at gcc dot gnu.org
@ 2014-01-06 9:17 ` trippels at gcc dot gnu.org
2014-01-06 9:26 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: trippels at gcc dot gnu.org @ 2014-01-06 9:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #13 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Markus Trippelsdorf from comment #11)
> > (In reply to Jakub Jelinek from comment #10)
> > > If you have time, could you please try to bisect manually which of the 4
> > > functions matters for the bootstrap failure?
> > > Compile printk.s with both compilers and apply by hand only portions of the
> > > diff that are for individual routines?
> >
> > Yes. I will try this later.
> > In the meantime I've found out that drivers/acpi/acpica/utxferror.c also
> > gets miscompiled. If I replace this two object files with good ones and
> > relink the kernel, everything runs fine (under qemu)...
> >
> > utxferror shows the same pattern as seen in printk.
>
> It is undestandable the patch changes how most/all stdarg functions are
> compiled in the kernel, the question is why the kernel cares in certain
> cases. Do you get some OOPS in the utxferror case or also silent hang
> without being able to tell what is going on? In ACPI case, I'd guess if the
> routine calls into BIOS that the BIOS (or whatever qemu uses instead of
> BIOS) might assume 16-byte stack alignment which is part of the ABI, but the
> kernel intentionally only guarantees 8-byte stack alignment.
It's also a silent hang in the utxferror case. In both cases the kernel
just executes the halt loop in early_idt_handler:
0xffffffff81a81165 <+69>: hlt
=> 0xffffffff81a81166 <+70>: jmp 0xffffffff81a81165
<early_idt_handler+69>
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (11 preceding siblings ...)
2014-01-06 9:17 ` trippels at gcc dot gnu.org
@ 2014-01-06 9:26 ` jakub at gcc dot gnu.org
2014-01-06 9:36 ` trippels at gcc dot gnu.org
` (10 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-06 9:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Markus Trippelsdorf from comment #13)
> > It is undestandable the patch changes how most/all stdarg functions are
> > compiled in the kernel, the question is why the kernel cares in certain
> > cases. Do you get some OOPS in the utxferror case or also silent hang
> > without being able to tell what is going on? In ACPI case, I'd guess if the
> > routine calls into BIOS that the BIOS (or whatever qemu uses instead of
> > BIOS) might assume 16-byte stack alignment which is part of the ABI, but the
> > kernel intentionally only guarantees 8-byte stack alignment.
>
> It's also a silent hang in the utxferror case. In both cases the kernel
> just executes the halt loop in early_idt_handler:
> 0xffffffff81a81165 <+69>: hlt
> => 0xffffffff81a81166 <+70>: jmp 0xffffffff81a81165
> <early_idt_handler+69>
I've been out of the kernel business for 13+ years or so, so don't remember
details, looking at head_64.S I wonder if you couldn't try to enable
CONFIG_EARLY_PRINTK and see if you get some better diagnostics.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (12 preceding siblings ...)
2014-01-06 9:26 ` jakub at gcc dot gnu.org
@ 2014-01-06 9:36 ` trippels at gcc dot gnu.org
2014-01-06 10:00 ` trippels at gcc dot gnu.org
` (9 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: trippels at gcc dot gnu.org @ 2014-01-06 9:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #15 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Markus Trippelsdorf from comment #13)
> > > It is undestandable the patch changes how most/all stdarg functions are
> > > compiled in the kernel, the question is why the kernel cares in certain
> > > cases. Do you get some OOPS in the utxferror case or also silent hang
> > > without being able to tell what is going on? In ACPI case, I'd guess if the
> > > routine calls into BIOS that the BIOS (or whatever qemu uses instead of
> > > BIOS) might assume 16-byte stack alignment which is part of the ABI, but the
> > > kernel intentionally only guarantees 8-byte stack alignment.
> >
> > It's also a silent hang in the utxferror case. In both cases the kernel
> > just executes the halt loop in early_idt_handler:
> > 0xffffffff81a81165 <+69>: hlt
> > => 0xffffffff81a81166 <+70>: jmp 0xffffffff81a81165
> > <early_idt_handler+69>
>
> I've been out of the kernel business for 13+ years or so, so don't remember
> details, looking at head_64.S I wonder if you couldn't try to enable
> CONFIG_EARLY_PRINTK and see if you get some better diagnostics.
Yeah, I've already tried this, but it doesn't produce any diagnostic at all.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (13 preceding siblings ...)
2014-01-06 9:36 ` trippels at gcc dot gnu.org
@ 2014-01-06 10:00 ` trippels at gcc dot gnu.org
2014-01-06 10:04 ` trippels at gcc dot gnu.org
` (8 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: trippels at gcc dot gnu.org @ 2014-01-06 10:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|target |tree-optimization
--- Comment #16 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Ok it's the second hunk that causes the hang:
@@ -2680,28 +2677,25 @@
printk:
pushq %rbp
movq %rsp, %rbp
- pushq %r10
- leaq -56(%rbp), %rax
- leaq 16(%rbp), %r10
subq $72, %rsp
+ leaq 16(%rbp), %r10
movq %rsi, -48(%rbp)
movq %rdx, -40(%rbp)
movq %rcx, -32(%rbp)
movq %r8, -24(%rbp)
- xorl %ecx, %ecx
+ leaq -56(%rbp), %rax
movq %r9, -16(%rbp)
movq %rdi, %r8
leaq -80(%rbp), %r9
+ xorl %ecx, %ecx
xorl %edx, %edx
orl $-1, %esi
xorl %edi, %edi
- movq %r10, -72(%rbp)
movl $8, -80(%rbp)
+ movq %r10, -72(%rbp)
movq %rax, -64(%rbp)
call vprintk_emit
- addq $72, %rsp
- popq %r10
- popq %rbp
+ leave
ret
.size printk, .-printk
.LCOLDE47:
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (14 preceding siblings ...)
2014-01-06 10:00 ` trippels at gcc dot gnu.org
@ 2014-01-06 10:04 ` trippels at gcc dot gnu.org
2014-01-06 10:09 ` hjl.tools at gmail dot com
` (7 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: trippels at gcc dot gnu.org @ 2014-01-06 10:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #17 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
If I add "pushq %r10" and "popq %r10" by hand, the kernel boots fine.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (15 preceding siblings ...)
2014-01-06 10:04 ` trippels at gcc dot gnu.org
@ 2014-01-06 10:09 ` hjl.tools at gmail dot com
2014-01-06 10:12 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: hjl.tools at gmail dot com @ 2014-01-06 10:09 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #18 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Markus Trippelsdorf from comment #17)
> If I add "pushq %r10" and "popq %r10" by hand, the kernel boots fine.
Is r10 used in th function? Please also try adjust
stack instead of push/pop.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (16 preceding siblings ...)
2014-01-06 10:09 ` hjl.tools at gmail dot com
@ 2014-01-06 10:12 ` jakub at gcc dot gnu.org
2014-01-06 10:21 ` trippels at gcc dot gnu.org
` (5 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-06 10:12 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Markus Trippelsdorf from comment #17)
> If I add "pushq %r10" and "popq %r10" by hand, the kernel boots fine.
Thanks. Now, can you please try to use pushq %r9 and popq %r9 instead?
I.e. whether this is about the stack pointer or whether something is really
upset about the %r10 call clobbered value changing in printk?
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (17 preceding siblings ...)
2014-01-06 10:12 ` jakub at gcc dot gnu.org
@ 2014-01-06 10:21 ` trippels at gcc dot gnu.org
2014-01-06 11:28 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: trippels at gcc dot gnu.org @ 2014-01-06 10:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #20 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #19)
> (In reply to Markus Trippelsdorf from comment #17)
> > If I add "pushq %r10" and "popq %r10" by hand, the kernel boots fine.
>
> Thanks. Now, can you please try to use pushq %r9 and popq %r9 instead?
Adding "pushq %r9" and "popq %r9" also results in a bootable kernel...
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (18 preceding siblings ...)
2014-01-06 10:21 ` trippels at gcc dot gnu.org
@ 2014-01-06 11:28 ` jakub at gcc dot gnu.org
2014-01-06 11:55 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-06 11:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Markus Trippelsdorf from comment #20)
> (In reply to Jakub Jelinek from comment #19)
> > (In reply to Markus Trippelsdorf from comment #17)
> > > If I add "pushq %r10" and "popq %r10" by hand, the kernel boots fine.
> >
> > Thanks. Now, can you please try to use pushq %r9 and popq %r9 instead?
>
> Adding "pushq %r9" and "popq %r9" also results in a bootable kernel...
Ah, I see what is going wrong, sorry for your wasted time.
The problem is that ix86_save_reg is called already with
crtl->stack_realign_finalized == false, e.g. in
ix86_initial_elimination_offset,
at that point ix86_save_reg will return true for the drap register and thus it
is accounted for during RA, but if we don't count it later on,
ix86_compute_frame_layout will compute a different layout.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (19 preceding siblings ...)
2014-01-06 11:28 ` jakub at gcc dot gnu.org
@ 2014-01-06 11:55 ` jakub at gcc dot gnu.org
2014-01-06 13:39 ` [Bug target/59644] " jakub at gcc dot gnu.org
` (2 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-06 11:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vmakarov at gcc dot gnu.org
--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, supposedly the:
10432 /* If drap has been set, but it actually isn't live at the
start
10433 of the function and !stack_realign, there is no reason to
set it up. */
10434 if (crtl->drap_reg && !stack_realign)
10435 {
10436 basic_block bb = ENTRY_BLOCK_PTR_FOR_FN (cfun)->next_bb;
10437 if (! REGNO_REG_SET_P (DF_LR_IN (bb), REGNO
(crtl->drap_reg)))
10438 {
10439 crtl->drap_reg = NULL_RTX;
10440 crtl->need_drap = false;
10441 }
10442 }
hunk needs to be performed somewhere else (at the start of ira function, or
during reload/LRA (reload_in_progress/lra_in_progress) or not at all.
Supposedly the second crtl->drap_reg = NULL_RTX hunk in that function is fine,
because that is done only if there are no %rsp/%rbp accesses in the function.
And the ix86_save_reg change would need guarding by some other flag (a bit in *
cfun->machine ?) that would be set when ix86_finalize_stack_realign_flags
performed the optimization (but couldn't clear drap_reg because it was needed,
but wasn't needed to be preserved).
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (20 preceding siblings ...)
2014-01-06 11:55 ` jakub at gcc dot gnu.org
@ 2014-01-06 13:39 ` jakub at gcc dot gnu.org
2014-01-06 21:38 ` jakub at gcc dot gnu.org
2014-01-06 21:39 ` jakub at gcc dot gnu.org
23 siblings, 0 replies; 25+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-06 13:39 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2014-01-06
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 31755
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31755&action=edit
gcc49-pr59644.patch
Untested fix. For the code quality cases this patch regresses, perhaps it
would be nice to have some LRA target hook where we could finalize the stack
realign flags earlier, still during LRA, but late enough that nothing would
need to be spilled in the various vector modes, if LRA would be able to cope
with just reshuffling the elimination offsets because of that (and even better
if it could deal with frame_pointer_needed -> !frame_pointer_needed change at
that point).
Vlad, do you think there could be such place in LRA (surely it would need to be
done before the final lra_eliminate). If we could even more accurately find
out if we really need aligned stack or not then, I'd hope it could improve code
quality.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (21 preceding siblings ...)
2014-01-06 13:39 ` [Bug target/59644] " jakub at gcc dot gnu.org
@ 2014-01-06 21:38 ` jakub at gcc dot gnu.org
2014-01-06 21:39 ` jakub at gcc dot gnu.org
23 siblings, 0 replies; 25+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-06 21:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Mon Jan 6 21:38:27 2014
New Revision: 206375
URL: http://gcc.gnu.org/viewcvs?rev=206375&root=gcc&view=rev
Log:
PR target/59644
* config/i386/i386.h (struct machine_function): Add
no_drap_save_restore field.
* config/i386/i386.c (ix86_save_reg): Use
!cfun->machine->no_drap_save_restore instead of
crtl->stack_realign_needed.
(ix86_finalize_stack_realign_flags): Don't clear drap_reg unless
this function clears frame_pointer_needed. Set
cfun->machine->no_drap_save_restore if clearing frame_pointer_needed
and DRAP reg is needed.
* gcc.target/i386/pr59644.c: New test.
Added:
trunk/gcc/testsuite/gcc.target/i386/pr59644.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/cp/ChangeLog
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/59644] [4.9 Regression] r206243 miscompiles Linux kernel
2013-12-30 23:03 [Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel trippels at gcc dot gnu.org
` (22 preceding siblings ...)
2014-01-06 21:38 ` jakub at gcc dot gnu.org
@ 2014-01-06 21:39 ` jakub at gcc dot gnu.org
23 siblings, 0 replies; 25+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-01-06 21:39 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Hopefully fixed now.
^ permalink raw reply [flat|nested] 25+ messages in thread