|
 |
4ac4fd |
2005-09-23 Alexandre Oliva <aoliva@redhat.com>
|
|
|
4ac4fd |
|
|
|
4ac4fd |
* config/rs6000/sysv4.h (PREFERRED_STACK_BOUNDARY): New,
|
|
|
4ac4fd |
same as STACK_BOUNDARY as in rs6000.h.
|
|
|
4ac4fd |
|
|
|
4ac4fd |
--- gcc/config/rs6000/sysv4.h.orig
|
|
|
4ac4fd |
+++ gcc/config/rs6000/sysv4.h
|
|
|
4ac4fd |
@@ -395,6 +395,22 @@ do { \
|
|
|
4ac4fd |
#undef STACK_BOUNDARY
|
|
|
4ac4fd |
#define STACK_BOUNDARY (TARGET_ALTIVEC_ABI ? 128 : 64)
|
|
|
4ac4fd |
|
|
|
4ac4fd |
+/* The definition above is actually wrong, since it doesn't use
|
|
|
4ac4fd |
+ 128-bit alignment on ppc64 like the ABI mandates. It was removed
|
|
|
4ac4fd |
+ in newer versions of GCC. The correct definition would be the one
|
|
|
4ac4fd |
+ below, from rs6000.h. Unfortunately, changing it would increase
|
|
|
4ac4fd |
+ the stack alignment expectations of newly-compiled functions, that
|
|
|
4ac4fd |
+ might be called by functions compiled with the old compiler. If
|
|
|
4ac4fd |
+ the latter didn't keep the stack sufficiently aligned. This may
|
|
|
4ac4fd |
+ happen if the latter uses alloca() or dynamically-sized arrays. We
|
|
|
4ac4fd |
+ compensate for the error here, getting the compiler to keep the
|
|
|
4ac4fd |
+ stack aligned to the correct boundary, but not assuming it is
|
|
|
4ac4fd |
+ sufficiently aligned. Code that still assumes proper alignment
|
|
|
4ac4fd |
+ will fail and require recompilation with this patch or a newer
|
|
|
4ac4fd |
+ compiler, but most of the code will work without change. */
|
|
|
4ac4fd |
+#define PREFERRED_STACK_BOUNDARY \
|
|
|
4ac4fd |
+ ((TARGET_32BIT && !TARGET_ALTIVEC_ABI) ? 64 : 128)
|
|
|
4ac4fd |
+
|
|
|
4ac4fd |
/* Real stack boundary as mandated by the appropriate ABI. */
|
|
|
4ac4fd |
#define ABI_STACK_BOUNDARY ((TARGET_EABI && !TARGET_ALTIVEC_ABI) ? 64 : 128)
|
|
|
4ac4fd |
|