[Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel

[Bug tree-optimization/59644] New: [4.9 Regression] r206243 miscompiles Linux kernel

[trippels at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644

            Bug ID: 59644
           Summary: [4.9 Regression] r206243 miscompiles Linux kernel
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: trippels at gcc dot gnu.org

Starting with r206243 the Linux kernel gets miscompiled.
It just hangs very early during boot (before first printk).

[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel

[jakub at gcc dot gnu.org]

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.

[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel

[trippels at gcc dot gnu.org]

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

[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel

[trippels at gcc dot gnu.org]

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

[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel

[trippels at gcc dot gnu.org]

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

[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel

[trippels at gcc dot gnu.org]

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

[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel

[trippels at gcc dot gnu.org]

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:

[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel

[jakub at gcc dot gnu.org]

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

[trippels at gcc dot gnu.org]

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

[trippels at gcc dot gnu.org]

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

[trippels at gcc dot gnu.org]

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

[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel

[jakub at gcc dot gnu.org]

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

[trippels at gcc dot gnu.org]

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>

[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel

[jakub at gcc dot gnu.org]

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.

[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel

[trippels at gcc dot gnu.org]

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.

[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel

[trippels at gcc dot gnu.org]

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:

[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel

[trippels at gcc dot gnu.org]

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

[hjl.tools at gmail dot com]

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

[jakub at gcc dot gnu.org]

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

[trippels at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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 target/59644] [4.9 Regression] r206243 miscompiles Linux kernel

[jakub at gcc dot gnu.org]

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.

[Bug target/59644] [4.9 Regression] r206243 miscompiles Linux kernel

[jakub at gcc dot gnu.org]

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

[Bug target/59644] [4.9 Regression] r206243 miscompiles Linux kernel

[jakub at gcc dot gnu.org]

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.