[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785

["ubizjak at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #22 from ubizjak at gmail dot com  2008-02-13 17:03 -------
(In reply to comment #21)
> > Currently, it is defined as:
> >
> > #define STACK_BOUNDARY BITS_PER_WORD
> 
> In this case how can it be 4? should not it be 32 or 64?

Yes, it _is_ 32 or 64. The point is, that IT IS NOT 128, so x86_64 (that has
sse2 enabled by default) would break left and right if STACK_BOUNDARY was
required to be 128 bit.

Looking through calls.c, it is obvious that PREFERRED_STACK_BOUNDARY pretty
much guarantees 128 bit stack alignment:

--cut here--
  /* Ensure current function's preferred stack boundary is at least
     what we need.  We don't have to increase alignment for recursive
     functions.  */
  if (cfun->preferred_stack_boundary < preferred_stack_boundary
      && fndecl != current_function_decl)
    cfun->preferred_stack_boundary = preferred_stack_boundary;
  if (fndecl == current_function_decl)
    cfun->recursive_call_emit = true;
--cut here--

IMO, there is no need for extra paranoia in darwin.h and following defines
should be removed:

/* On Darwin, the stack is 128-bit aligned at the point of every call.
   Failure to ensure this will lead to a crash in the system libraries
   or dynamic loader.  */
#undef STACK_BOUNDARY
#define STACK_BOUNDARY 128

/* Since we'll never want a stack boundary less aligned than 128 bits
   we need the extra work here otherwise bits of gcc get very grumpy
   when we ask for lower alignment.  We could just reject values less
   than 128 bits for Darwin, but it's easier to up the alignment if
   it's below the minimum.  */
#undef PREFERRED_STACK_BOUNDARY
#define PREFERRED_STACK_BOUNDARY (ix86_preferred_stack_boundary > 128   \
                                  ? ix86_preferred_stack_boundary       \
                                  : 128)

(Could someone with darwin bootstraps and regtest removal of these defines? Do
we even have an example of a failure for latest 4.3 if these are not defined?)

AFAICS, STACK_BOUNDARY should be set to the value of "push" insn - in the sense
that x86_64 doesn't define it to (...say...) 25 or some other random value. For
sure, it should mirror PARM_BOUNDARY, otherwise various strange things happen.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621