http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #21 from Jakub Jelinek ---
(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 han
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #20 from Markus Trippelsdorf ---
(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 yo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #19 from Jakub Jelinek ---
(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. wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #18 from H.J. Lu ---
(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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #17 from Markus Trippelsdorf ---
If I add "pushq %r10" and "popq%r10" by hand, the kernel boots fine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
Markus Trippelsdorf changed:
What|Removed |Added
Component|target |tree-optimization
--- Comment #16 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #15 from Markus Trippelsdorf ---
(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 kern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #14 from Jakub Jelinek ---
(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
> > c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #13 from Markus Trippelsdorf ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #12 from Jakub Jelinek ---
(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 boo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #11 from Markus Trippelsdorf ---
(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 compil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #10 from Jakub Jelinek ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
Markus Trippelsdorf changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #9 from Jakub Jelinek ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #8 from Markus Trippelsdorf ---
>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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #6 from Markus Trippelsdorf ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #5 from Markus Trippelsdorf ---
Created attachment 31549
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31549&action=edit
printk_bad assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #4 from Markus Trippelsdorf ---
Created attachment 31548
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31548&action=edit
printk_good assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #3 from Markus Trippelsdorf ---
Created attachment 31547
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31547&action=edit
testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #2 from Markus Trippelsdorf ---
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/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59644
--- Comment #1 from Jakub Jelinek ---
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
23 matches
Mail list logo
