Kean Johnston wrote:
Ok I am no compiler expert, so this may be totally impossible,
and if so I'd appreciate an education, but this is what I
instinctively thought of when first thinking about this problem.
Note that never mind SSE1, even conventional 8-byte fpt, while
not requiring fpt for c
On Fri, Oct 14, 2005 at 04:35:48PM -0700, Kean Johnston wrote:
> This seems far less invasive that redefining an ABI.
No, it isn't less invasive.
Your first case is not too difficult. No more difficult, really,
than supporting alloca. Indeed, this is more or less exactly the
code we emit in mai
Yes. You can thank Intel for this.
Thank you Intel :)
With the introduction of SSE1, something had to change in order
to satisfy hardware constraints. Intel initially proposed some
scheme that performed dynamic stack alignment in functions that
use SSE1 instructions, and multiple entry poin
On Fri, Oct 14, 2005 at 02:14:10PM -0700, Kean Johnston wrote:
> How can that possibly ever work? Is the assumption then
> that the only code GCC will ever work with is code that
> GCC compiled? In effect what this implies is that GCC
> is re-defining the ABI.
Yes. You can thank Intel for this.
On Oct 14, 2005, at 4:43 PM, Kean Johnston wrote:
It indicated that sibling calling optimization in main should
be disabled for targets that need to up the stack alignment,
otherwise you get the stack alignment of a lower one than
While that may be true, I think the problem is broader.
This
Yes, in fact that's *exactly* what GCC is assuming.
And it will be true for all code that GCC generates.
How can that possibly ever work? Is the assumption then
that the only code GCC will ever work with is code that
GCC compiled? In effect what this implies is that GCC
is re-defining the ABI. It
On Fri, Oct 14, 2005 at 01:43:03PM -0700, Kean Johnston wrote:
> Also, when you say "stack going into main is 16 byte aligned",
> what specifically do you mean? that its 16-byte aligned before
> the call to main() itself? That at the first insn in main, most
> likely a push %ebp, its 16-byte align
On Fri, Oct 14, 2005 at 01:43:03PM -0700, Kean Johnston wrote:
> However, I dont think the stack being aligned on a 16-byte
> boundary into main will help, unless GCC is assuming (and I
> dont see how it possibly could) that every function would
> likewise be aligned.
Yes, in fact that's *exactly*
On Fri, Oct 14, 2005 at 01:43:03PM -0700, Kean Johnston wrote:
> >It indicated that sibling calling optimization in main should
> >be disabled for targets that need to up the stack alignment,
> >otherwise you get the stack alignment of a lower one than
> While that may be true, I think the problem
It indicated that sibling calling optimization in main should
be disabled for targets that need to up the stack alignment,
otherwise you get the stack alignment of a lower one than
While that may be true, I think the problem is broader.
I took out the main1() function and put it into a separate
On Oct 14, 2005, at 3:55 PM, Andrew Pinski wrote:
On Oct 14, 2005, at 3:43 PM, Kean Johnston wrote:
What does the fact that -fno-optimize-sibling-calls worked
indicate really? Without that option something really does
seem to be mis-calculating the stack offsets by 4. What may
be of interest
On Oct 14, 2005, at 3:43 PM, Kean Johnston wrote:
What does the fact that -fno-optimize-sibling-calls worked
indicate really? Without that option something really does
seem to be mis-calculating the stack offsets by 4. What may
be of interest here is that aside from the vect/* tests,
the only o
Can you try -fno-optimize-sibling-calls and see if that works?
Yes, it did, thank you.
If so, then the problem is that we sibling calls should not be
done in main. To fix the testcase anyways to be correct is to
put "return 0;" after the call to main1. Since right now the
return of main could
Can you just fix your OS instead?
My OS is just fine, thank you very much. You disappoint me.
I expected better from you.
It is most likely of absolutely no consequence to you, and
this has nothing to do with GCC so this is the very last I
will say on this subject to you, but you really did hurt
On Oct 14, 2005, at 3:11 PM, Kean Johnston wrote:
All,
I am getting a lot of test suite failures with almost all of
the vect/* tests. I am using pr18400.c from the test suite
as an example here, becuase its about the smallest one I
can find. Here is what is generated at -O2:
Can you try -fno
On Fri, Oct 14, 2005 at 03:13:55PM -0400, Andrew Pinski wrote:
>
> On Oct 14, 2005, at 3:11 PM, Kean Johnston wrote:
>
> >All,
> >
> >I am getting a lot of test suite failures with almost all of
> >the vect/* tests. I am using pr18400.c from the test suite
> >as an example here, becuase its about
On Oct 14, 2005, at 3:11 PM, Kean Johnston wrote:
All,
I am getting a lot of test suite failures with almost all of
the vect/* tests. I am using pr18400.c from the test suite
as an example here, becuase its about the smallest one I
can find. Here is what is generated at -O2:
Can you just fi
17 matches
Mail list logo
