"Jay Freeman (saurik)" writes:
>> As you know, I wanted to allow for future expansion. I agree that it
>> would be possible to avoid storing MORESTACK_SEGMENTS--that would trade
>> off space for time, since it would mean that setcontext would have to
>> walk up the list. I think CURRENT_STACK i
From: "Joseph S. Myers"
Date: Wed, 29 Feb 2012 17:17:17 + (UTC)
Thanks for looking into all of these issues.
> (c) Various functions do not set errno correctly (many cases) or raise the
> proper floating-point exceptions (a smaller number of cases - both
> spurious exceptions where not per
I've reviewed many (not yet all) of glibc's open "math" component bugs. I
hope some actual summary information on what the current state of libm
looks like may be of interest to the people involved in the various past
discussions of better libm for GCC or glibc - and those interested in
fixing
Le 29/02/2012 17:08, Richard Guenther a écrit :
> On Wed, Feb 29, 2012 at 4:41 PM, Aurelien Buhrig
> wrote:
>> Le 29/02/2012 16:15, Richard Guenther a écrit :
>>> On Wed, Feb 29, 2012 at 4:08 PM, Aurelien Buhrig
>>> wrote:
> The issue is most probably that on GIMPLE we only deal with ptr
On Wed, Feb 29, 2012 at 4:41 PM, Aurelien Buhrig
wrote:
> Le 29/02/2012 16:15, Richard Guenther a écrit :
>> On Wed, Feb 29, 2012 at 4:08 PM, Aurelien Buhrig
>> wrote:
>>>
The issue is most probably that on GIMPLE we only deal with ptr_mode,
not Pmode, and IVOPTs thinks that pointer ind
Le 29/02/2012 16:15, Richard Guenther a écrit :
> On Wed, Feb 29, 2012 at 4:08 PM, Aurelien Buhrig
> wrote:
>>
>>> The issue is most probably that on GIMPLE we only deal with ptr_mode,
>>> not Pmode, and IVOPTs thinks that pointer induction variables will
>>> have ptr_mode. To fix this the cost c
On Wed, Feb 29, 2012 at 4:08 PM, Aurelien Buhrig
wrote:
>
>> The issue is most probably that on GIMPLE we only deal with ptr_mode,
>> not Pmode, and IVOPTs thinks that pointer induction variables will
>> have ptr_mode. To fix this the cost computation would need to take
>> into account ptr_mode t
> The issue is most probably that on GIMPLE we only deal with ptr_mode,
> not Pmode, and IVOPTs thinks that pointer induction variables will
> have ptr_mode. To fix this the cost computation would need to take
> into account ptr_mode to Pmode conversions _and_ would need to
> consider Pmode IVs i
On Wed, Feb 29, 2012 at 3:50 PM, Bin.Cheng wrote:
> On Mon, Jan 2, 2012 at 10:54 PM, Richard Guenther
> wrote:
>> On Mon, Jan 2, 2012 at 3:09 PM, Amker.Cheng wrote:
>>> On Mon, Jan 2, 2012 at 9:37 PM, Richard Guenther
>>> wrote:
>>>
Well, with
Index: gcc/tree-ssa-pre.c
=
On Mon, Jan 2, 2012 at 10:54 PM, Richard Guenther
wrote:
> On Mon, Jan 2, 2012 at 3:09 PM, Amker.Cheng wrote:
>> On Mon, Jan 2, 2012 at 9:37 PM, Richard Guenther
>> wrote:
>>
>>> Well, with
>>>
>>> Index: gcc/tree-ssa-pre.c
>>> ===
On Wed, Feb 29, 2012 at 9:11 AM, Aurelien Buhrig
wrote:
> Hi,
>
> I'm porting a gcc backend (4.6.1) for a 16-bit MCU with PSI pmode, and
> SI ptr_mode.
>
> I have a QoR problem with loops: the chosen IVs are often not good.
> I looked at tree-ssa-loop-ivopts.c but it is hard to understand that
> c
Hi,
I'm porting a gcc backend (4.6.1) for a 16-bit MCU with PSI pmode, and
SI ptr_mode.
I have a QoR problem with loops: the chosen IVs are often not good.
I looked at tree-ssa-loop-ivopts.c but it is hard to understand that
code. So sorry if my questions are a bit confused but I would like to
un
12 matches
Mail list logo
