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: Thu, 02 Jan 2014 07:58:55 +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 #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).