https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #23 from Andreas Krebbel ---
Author: krebbel
Date: Fri Nov 18 14:44:54 2016
New Revision: 242590
URL: https://gcc.gnu.org/viewcvs?rev=242590=gcc=rev
Log:
Re-apply: Drop excess size used for run time allocated stack variables.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #22 from Andreas Krebbel ---
Author: krebbel
Date: Fri Nov 18 14:28:49 2016
New Revision: 242589
URL: https://gcc.gnu.org/viewcvs?rev=242589=gcc=rev
Log:
RS6000: Fix PR 77359: Properly align local variables in functions calling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #21 from Dominik Vogt ---
Patch posted here:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00266.html
This needs to pass the AIX testsuite which I cannot run with the available
resources.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #20 from David Edelsohn ---
If STACK_DYNAMIC_OFFSET has to be increased to 16, it has to be increased.
info->parm_size probably was adjusted for VMX parameters.
Note that GCC has gone through contortions with STACK_BOUNDARY,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #19 from Ulrich Weigand ---
I've been looking into this a bit with Dominik, and here's what I understand of
the problem so far:
- It really all starts with emit-rtl.c:init_emit doing:
REGNO_POINTER_ALIGN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #18 from David Edelsohn ---
As long as GCC claims that it can make a distinction between the various
alignments and macros, the GCC code generation must continue to honor it.
On AIX, at least, the ABI claims a different stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #17 from David Edelsohn ---
Created attachment 39891
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39891=edit
Experimental patch
If this patch is correct, then there is a general problem for Linux also.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #16 from Dominik Vogt ---
There's nothing wrong with applying that change, but it does not fix the
problem. I'm still debugging this and have it narrowed down to being related
with functions that use alloca() and call another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #15 from David Edelsohn ---
The AIX Subroutine Linkage Convention states:
"The address value in the stack pointer must be quadword-aligned. (The address
value must be a multiple of 16.)" - Stack Layout, Note 2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #14 from Dominik Vogt ---
Okay, it looks like outgoing_args_size is rounded up to a multiple of
preferred_stack_boundary, so there's no problem on s390 or other targets with a
stack allocation size smaller than STACK_BOUNDARY. So,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #13 from Dominik Vogt ---
> What do you mean by size of a stack slot?
On s390, if we have one "int" variables on the stack, this uses a "slot" 4
bytes. The stack pointer maintains an 8 byte alignmet though, i.e. SP is
changec by 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
David Edelsohn changed:
What|Removed |Added
Target|powerpc-ibm-aix*|powerpc*-*-*
--- Comment #12 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #11 from Dominik Vogt ---
But does that really match the Abi? On s390 (31 bit) we have an 8 byte aligned
stack pointer, but the size of a stack slot is just 4 bytes, so the offset from
the stack pointer may just be a multiple of 4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #10 from David Edelsohn ---
I was thinking more of
#define STACK_DYNAMIC_OFFSET(FUNDECL) \
(RS6000_ALIGN (crtl->outgoing_args_size, \
(TARGET_ALTIVEC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #9 from Dominik Vogt ---
> AIX increased the alignment when Altivec support was added. It
> appears that STACK_DYNAMIC_OFFSET should add a test for AIX.
Is the alignment of the dynamic area part of the AIX Abi?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #8 from Dominik Vogt ---
Something like this:
-- snip --
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 353f388..3158c24 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -1719,6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #7 from David Edelsohn ---
It looks like STACK_DYNAMIC_OFFSET will behave correctly on AIX if Altivec or
VSX is enabled. AIX increased the alignment when Altivec support was added.
It appears that STACK_DYNAMIC_OFFSET should add a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #6 from Dominik Vogt ---
> Presumably something in the rs6000 backend is not maintaining or not
> instructing the common part of GCC to maintain the alignment on AIX,
> but presumably is maintained on Linux.
Might be a problem with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #5 from Dominik Vogt ---
Sounds fair. So, either the bug is that the stack pointer has 8 byte
alignment, or the formula for STACK_DYNAMIC_OFFSET results in the the wrong
amount:
-- rs6000.h --
/* Offset from the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #4 from David Edelsohn ---
Altivec works on AIX, which requires 128 bit alignment. So GCC and AIX are able
to cooperate to generate the necessary alignment. The stack pointer is
supposed to maintain quadword alignment on AIX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
Dominik Vogt changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #2 from Dominik Vogt ---
It's a bit awkward because I don't have access to an AIX machine right now.
What's the "configure" line fron config.log, please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
David Edelsohn changed:
What|Removed |Added
Target||powerpc-ibm-aix*
23 matches
Mail list logo
