[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- 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?
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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.o2014-01-05 13:01:41.149293740 +0100
@@ -16,14 +16,13 @@
movq%rsp, %rbp
pushq %r13
pushq %r12
- pushq %r10
pushq %rbx
leaq16(%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 @@
callacpi_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
leaq16(%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 @@
callacpi_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
leaq16(%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
leaq16(%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
leaq16(%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_rev2014-01-05 11:41:35.064633494 +0100
+++ /var/tmp/out_jel2014-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
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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.
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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: 0x81a81165 +69:hlt = 0x81a81166 +70:jmp0x81a81165 early_idt_handler+69
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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: 0x81a81165 +69:hlt = 0x81a81166 +70:jmp0x81a81165 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.
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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: 0x81a81165 +69:hlt = 0x81a81166 +70:jmp0x81a81165 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.
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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 - leaq16(%rbp), %r10 subq$72, %rsp + leaq16(%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) callvprintk_emit - addq$72, %rsp - popq%r10 - popq%rbp + leave ret .size printk, .-printk .LCOLDE47:
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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.
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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.
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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?
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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...
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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.
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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).
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- The reason why some changes appear in stdarg functions is: ix86_update_stack_boundary: /* x86_64 vararg needs 16byte stack alignment for register save area. */ if (TARGET_64BIT cfun-stdarg crtl-stack_alignment_estimated 128) crtl-stack_alignment_estimated = 128; and kernel uses -mno-sse -mpreferred-stack-boundary=3 But because of -mno-sse, that is completely unnecessary, as setup_incoming_varargs_64 does: /* FPR size of varargs save area. We don't need it if we don't pass anything in SSE registers. */ if (TARGET_SSE cfun-va_list_fpr_size) ix86_varargs_fpr_size = X86_64_SSE_REGPARM_MAX * 16; else ix86_varargs_fpr_size = 0; thus for !TARGET_SSE it never even allocates the fpr save area that would need the bigger alignment. So IMHO we might as well change ix86_update_stack_boundary to add !TARGET_SSE into the condition. Still, that doesn't explain why the kernel doesn't like it. As I said earlier, the explanation could be that something doesn't expect r10 to be clobbered across some of these calls, or perhaps something assumes 64bit stack alignment in the called function (but with -mpreferred-stack-boundary=3 that would be broken assumption).
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(printk) -DKBUILD_MODNAME=KBUILD_STR(printk) -c -o kernel/printk/printk.o kernel/printk/printk.c --save-temps
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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=31547action=edit testcase
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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=31548action=edit printk_good assembly
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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=31549action=edit printk_bad assembly
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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 - leaq16(%rbp), %r10 subq$72, %rsp + leaq16(%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) callvprintk_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 - leaq16(%rbp), %r10 subq$72, %rsp + leaq16(%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) callvprintk_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 leaq16(%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 - leaq16(%rbp), %r10 subq$72, %rsp + leaq16(%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) callvsnprintf - addq$72, %rsp - popq%r10 - popq%rbp + leave ret .size dump_stack_set_arch_desc, .-dump_stack_set_arch_desc .LCOLDE92:
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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.
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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.
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
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.
