On 03/13/2015 06:04 PM, Marc Gauthier wrote:
> Other than the required 16-byte stack alignment, there's nothing in
> the ABI that requires these extra 16 bytes. Perhaps there was a bad
> implementation of the alloca exception handler at some point a long
> time ago that prompted the extra 16 byte
On Fri, Mar 13, 2015 at 03:56:38PM -0500, Segher Boessenkool wrote:
> On Fri, Mar 13, 2015 at 11:36:47PM +0300, Max Filippov wrote:
> > >> 2. alloca seems to make an additional 16-bytes padding to each stack
> > >> allocation: alloca(1) results in moving sp down by 32 bytes, alloca(17)
> > >> m
On Fri, Mar 13, 2015 at 11:36:47PM +0300, Max Filippov wrote:
> >> 2. alloca seems to make an additional 16-bytes padding to each stack
> >> allocation: alloca(1) results in moving sp down by 32 bytes, alloca(17)
> >> moves it by 48 bytes, etc.
> >
> > This sounds like PR 50938, 47353, 34548, m
On Fri, Mar 13, 2015 at 11:18 PM, Segher Boessenkool
wrote:
> On Fri, Mar 13, 2015 at 05:54:48PM +0300, Max Filippov wrote:
>> 2. alloca seems to make an additional 16-bytes padding to each stack
>> allocation: alloca(1) results in moving sp down by 32 bytes, alloca(17)
>> moves it by 48 bytes
On Fri, Mar 13, 2015 at 05:54:48PM +0300, Max Filippov wrote:
> 2. alloca seems to make an additional 16-bytes padding to each stack
> allocation: alloca(1) results in moving sp down by 32 bytes, alloca(17)
> moves it by 48 bytes, etc.
This sounds like PR 50938, 47353, 34548, maybe more? Happ
On Fri, Mar 13, 2015 at 8:08 PM, augustine.sterl...@gmail.com
wrote:
> On Fri, Mar 13, 2015 at 10:04 AM, Marc Gauthier wrote:
>> Other than the required 16-byte stack alignment, there's nothing in
>> the ABI that requires these extra 16 bytes. Perhaps there was a bad
>> implementation of the all
On Fri, Mar 13, 2015 at 10:04 AM, Marc Gauthier wrote:
> Other than the required 16-byte stack alignment, there's nothing in
> the ABI that requires these extra 16 bytes. Perhaps there was a bad
> implementation of the alloca exception handler at some point a long
> time ago that prompted the ext
augustine.sterl...@gmail.com wrote:
> On Fri, Mar 13, 2015 at 7:54 AM, Max Filippov wrote:
[...]
> > 2. alloca seems to make an additional 16-bytes padding to each stack
> > allocation: alloca(1) results in moving sp down by 32 bytes,
> > alloca(17)
> > moves it by 48 bytes, etc. This paddin
On Fri, Mar 13, 2015 at 7:54 AM, Max Filippov wrote:
> 1. in windowed ABI stack pointer update is always split into two opcodes:
> add and movsp. How gcc optimization passes are supposed to know that
> 'movsp' is related to 'add' and that stack allocation is complete only after
> movsp?
The
Hi Sterling,
I've got an issue building gdb for xtensa linux with gcc, reported it here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65416
Looking at it I've got two questions, can you help me with them?
1. in windowed ABI stack pointer update is always split into two opcodes:
add and movsp.
10 matches
Mail list logo