> Ok, thanks for your reply. The 4.6 backend was testing if the hardware
> FP was live, and did some optimization whatever -fomit-frame-pointer or
> -fno-omit-frame-pointer. So it was not a valid optimization?
It was sort of a bug since -fno-omit-frame-pointer is in effect unless you
specify othe
>> I'm porting a private backend from an old 4.6 branch to the 6.1.0
>> release, and I have some troubles eliminating my frame pointer without
>> -fomit-frame-pointer option.
>> Elimination is correctly done with -fomit-frame-pointer.
> If the target's default is -fno-omit-frame-pointer, then it's
> I'm porting a private backend from an old 4.6 branch to the 6.1.0
> release, and I have some troubles eliminating my frame pointer without
> -fomit-frame-pointer option.
> Elimination is correctly done with -fomit-frame-pointer.
If the target's default is -fno-omit-frame-pointer, then it's as ex
Hi,
I'm porting a private backend from an old 4.6 branch to the 6.1.0
release, and I have some troubles eliminating my frame pointer without
-fomit-frame-pointer option.
Elimination is correctly done with -fomit-frame-pointer.
For an empty function (i.e. void f(void) {}), my hardware frame pointe
Dave Korn wrote:
> Dave Korn wrote:
>
>[ ... snip ... ]
>
> Sorry, the conclusion of that post evolved a bit while I was writing it,
> but I forgot to update the subject. This is what I should have posted it as.
> I'll start a fresh thread when I know more about the cause of the failure.
Dave Korn wrote:
[ ... snip ... ]
Sorry, the conclusion of that post evolved a bit while I was writing it,
but I forgot to update the subject. This is what I should have posted it as.
I'll start a fresh thread when I know more about the cause of the failure.
cheers,
DaveK
Dave Korn wrote:
> Dave Korn wrote:
>> H.J. Lu wrote:
>>> An IRA setjmp bug was fixed recently:
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38587
>>>
>>> Does it fix your problem?
>> I'm not sure, but my source tree is at r.143552, which is just a couple
>> of revs before your fix went in.
Dave Korn wrote:
> H.J. Lu wrote:
>> On Fri, Jan 23, 2009 at 5:29 PM, Dave Korn wrote:
>>>Hi all,
>>>
>>> re: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
>>> [Regression/4.4,P1 blocker IMHO: total failure of SjLj EH on Cygwin+MinGW]
>>>
>>> I have a simple testcase showing breakage in Sj
H.J. Lu wrote:
> On Fri, Jan 23, 2009 at 5:29 PM, Dave Korn wrote:
>>Hi all,
>>
>> re: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
>> [Regression/4.4,P1 blocker IMHO: total failure of SjLj EH on Cygwin+MinGW]
>>
>> I have a simple testcase showing breakage in SjLj EH on Cygwin. To cut
>
On Fri, Jan 23, 2009 at 5:29 PM, Dave Korn
wrote:
>Hi all,
>
> re: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952
> [Regression/4.4,P1 blocker IMHO: total failure of SjLj EH on Cygwin+MinGW]
>
> I have a simple testcase showing breakage in SjLj EH on Cygwin. To cut
> right to the chase, t
em:SI (reg/f:SI 0 ax [63]) [0 S4 A8])
(reg:SI 1 dx)) 41 {*movsi_1} (nil))
That is to say, it has performed frame-pointer elimination and replaced the
reference to the fp by a constant offset from the %esp. However, the offset
here is wrong; at least by the time we get to the final gene
11 matches
Mail list logo
