This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 06 Jan 2014 09:26:13 +0000
- Subject: [Bug tree-optimization/59644] [4.9 Regression] r206243 miscompiles Linux kernel
- Auto-submitted: auto-generated
- References: <bug-59644-4 at http dot gcc dot gnu dot org/bugzilla/>
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.