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>
