This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]