You said you would fix this several nights ago, but I still
haven't seen any changes to fixincludes since then.
When will you get around to fixing these regressions you
introduced?
Thank you.
Hi Michael,
Thank you for the details.
On Thu, Mar 18, 2010 at 8:17 AM, Michael Meissner
wrote:
>> > Note, that many hash tables are computed by the modulus operation, which is
>> > often fairly expensive (and on machines without a hardware divide unit,
>> > requiring a function call). I would
Snapshot gcc-4.5-20100318 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100318/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Thu, 2010-03-18 at 19:20 +0800, Amker.Cheng wrote:
> Does it possible that the method would ever result in register
> allocator failure?
> In my understanding, doesn't reload pass would do whatever it can to make
> all insns' constraints satisfied?
In theory, there should be no failure. In pra
This is the beta release of binutils 2.20.51.0.7 for Linux, which is
based on binutils 2010 0318 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
> Google is your friend...
Thanks Jack. As you can see in comment #46 of pr40106, I have found
my own way. In my previous attempts I have made two mistakes:
(1) I tried to use the search engine of the gcc mailing lists that
kept parsing optimize_insn_for_speed_p as if the _ were spaces.
(2) I did
"Paulo J. Matos" writes:
> On Thu, Mar 18, 2010 at 6:51 AM, Andrew Pinski wrote:
>> On Wed, Mar 17, 2010 at 11:38 PM, Paulo J. Matos wrote:
>>
>>
>> I cannot remember when half
>> float support came in though, I thought it was only added on the trunk
>> or did you backport that support too.
>>
On Thu, Mar 18, 2010 at 2:30 AM, Jim Wilson wrote:
> On Wed, 2010-03-17 at 11:27 +0800, fanqifei wrote:
>> You are correct. The reload pass emitted the clr.w insn.
>> However, I can see loop opt passes after reload:
>> problem1.c.174r.loop2_invariant1
>
> Not unless you have a modified toolchain.
On 2010-03-18 15:49:05 +, Joseph S. Myers wrote:
> And the same rule on pow(-0, y) is present in 754-2008 (I don't know
> whether this was deliberately following the C definition, or deciding
> independently that this was the right definition, but you may know as a
> listed member of the bal
On Thu, Mar 18, 2010 at 04:25:03PM +0100, Richard Guenther wrote:
> On Wed, 17 Mar 2010, Jakub Jelinek wrote:
>
> > On Wed, Mar 17, 2010 at 09:26:29PM +0100, Jakub Jelinek wrote:
> > > That will very much pessimize debug info. While we are now always in
> > > -funit-at-a-time mode, that doesn't m
On Thu, Mar 18, 2010 at 12:23 PM, Alain Ketterlin
wrote:
>
> I've reported here recently about gcc producing conditional branches
> with static outcome. I've finally managed to produce a simple
> self-contained example. Here it is:
>
> int f()
> {
> static int LSW=-1;
> double x=0.987654321;
On Thu, 18 Mar 2010, Vincent Lefevre wrote:
> On 2010-03-18 15:32:04 +0100, Michael Matz wrote:
> > > So, pow(-0.0, 0.5) should return +0. But sqrt(-0.0) should return -0
> > > according to the IEEE 754 standard (and F.9.4.5 from ISO C99).
> >
> > Yes, and I don't know why they specified it like
On Thu, Mar 18, 2010 at 04:34:56PM +0100, Vincent Lefevre wrote:
> On 2010-03-18 15:32:04 +0100, Michael Matz wrote:
> > But unfortunately you are right, this expansion can only be done for
> > -fno-signed-zeros. (FWIW the general expandsion of pow(x,N/2) where
> > N!=1 is already guarded by unsafe
On 2010-03-18 15:32:04 +0100, Michael Matz wrote:
> > So, pow(-0.0, 0.5) should return +0. But sqrt(-0.0) should return -0
> > according to the IEEE 754 standard (and F.9.4.5 from ISO C99).
>
> Yes, and I don't know why they specified it like that. After all
> (-0)*(-0)==+0 (not ==-0), so the ab
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Michael Matz
> Sent: 18 March 2010 15:13
> To: Frank Isamov
> Cc: gcc@gcc.gnu.org
> Subject: Re: Coloring problem - Pass 0 for finding allocno costs
>
> Hi,
>
> On Thu, 18 Mar 2010, Frank Isam
Hi,
I am trying to implement a simple load 8 bytes instruction.
I tried to use movdi so that it would allocate two sequential
registers for the load.
It starts well but in pass subreg1 the insns are decomposed and all DI
operands are replaced with SI.
I understand that this is a desireable optimz
On Wed, 17 Mar 2010, Jakub Jelinek wrote:
> On Wed, Mar 17, 2010 at 09:26:29PM +0100, Jakub Jelinek wrote:
> > That will very much pessimize debug info. While we are now always in
> > -funit-at-a-time mode, that doesn't mean DECL_RTL is computed early enough.
> > From the file scope non-static va
Hi,
On Thu, 18 Mar 2010, Frank Isamov wrote:
> From the h file:
>
> #define REG_CLASS_CONTENTS \
> {
> \
> {0x, 0x, 0x}, /* NO_REGS*/ \
> {0x, 0x, 0x}, /* D_REGS*/ \
On Thu, Mar 18, 2010 at 04:07:28PM +0100, Dominique Dhumieres wrote:
> May I remind my original question:
>
> > In the block "Handle constant exponents." in gcc/builtins.c, the condition
> > !optimize_size has been replaced with optimize_insn_for_speed_p () between
> > gcc 4.3 and 4.4, but I have
May I remind my original question:
> In the block "Handle constant exponents." in gcc/builtins.c, the condition
> !optimize_size has been replaced with optimize_insn_for_speed_p () between
> gcc 4.3 and 4.4, but I have not been able to find when and why.
> Does anybody remembers the when and why?
> -Original Message-
> From: Frank Isamov [mailto:frank.isa...@gmail.com]
> Sent: 18 March 2010 14:29
> To: Ian Bolton
> Subject: Re: Coloring problem - Pass 0 for finding allocno costs
>
> On Thu, Mar 18, 2010 at 3:51 PM, Ian Bolton
> wrote:
> >> The problem I see is that for registers 1
Hi,
On Thu, 18 Mar 2010, Vincent Lefevre wrote:
> On 2010-03-16 16:18:17 +0100, Richard Guenther wrote:
> > pow (a, 0.5) is always expanded to sqrt(a).
>
> This violates the ISO C99 standard for -0.0.
>
> According to N1256, F.9.4.4:
>
> pow(±0, y) returns +0 for y > 0 and not an odd integer
-- Forwarded message --
From: Frank Isamov
Date: Thu, Mar 18, 2010 at 4:28 PM
Subject: Re: Coloring problem - Pass 0 for finding allocno costs
To: Ian Bolton
On Thu, Mar 18, 2010 at 3:51 PM, Ian Bolton wrote:
>> The problem I see is that for registers 100,101 I get best registe
On 2010-03-18 14:43:39 +0100, Vincent Lefevre wrote:
> This violates the ISO C99 standard for -0.0.
>
> According to N1256, F.9.4.4:
>
> pow(±0, y) returns +0 for y > 0 and not an odd integer.
>
> So, pow(-0.0, 0.5) should return +0. But sqrt(-0.0) should return -0
> according to the IEEE 754
> The problem I see is that for registers 100,101 I get best register
> class D instead of R - actually they get the same cost and D is chosen
> (maybe because it is first).
Hi Frank.
Do D and R overlap? It would be useful to know which regs are in
which class, before trying to understand what i
On 2010-03-16 16:18:17 +0100, Richard Guenther wrote:
> pow (a, 0.5) is always expanded to sqrt(a).
This violates the ISO C99 standard for -0.0.
According to N1256, F.9.4.4:
pow(±0, y) returns +0 for y > 0 and not an odd integer.
So, pow(-0.0, 0.5) should return +0. But sqrt(-0.0) should retu
Ok. Thanks!
Then I will persuade the guys who develop the MCU to add one or more
base registers to ease the reload problem, and besides, I will add
some virtual registers( who are static "memory".) to hold 16,32 bit
mode variables.Hope these 2 solutions can make better codes. Now I
just begin to b
Hi,
In my backend, I have a problem with the pass which determines the
best register class for a virtual register (Pass 0 for finding allocno
costs).
In all insns in this example both R_REGS and D_REGS register classes
are applicable (but all registers in an insn should be from the same
register
It could be very very useful to add tatic Stack Usage Analysis for C/C
++. Something like -fstack-usage already done in gnat
thanks
I've reported here recently about gcc producing conditional branches
with static outcome. I've finally managed to produce a simple
self-contained example. Here it is:
int f()
{
static int LSW=-1;
double x=0.987654321;
unsigned char ix = *((char *)&x);
if(ix==0xdd || ix==0x3f)
> The reasoning here is
> that if splitting will result in worse code, then we shouldn't have
> accepted it in the first place. If dropping this alternative results in
> register allocator failures for some strange reason, then we accept it
> and generate the 3 instruction sequence with a new defi
On 03/18/2010 05:22 AM, Jae Hyuk Kwak wrote:
> On Wed, Mar 17, 2010 at 1:04 PM, Michael Meissner
> wrote:
>> Note, that many hash tables are computed by the modulus operation, which is
>> often fairly expensive (and on machines without a hardware divide unit,
>> requiring a function call). I woul
On Wed, Mar 17, 2010 at 3:35 PM, Paulo J. Matos wrote:
> So, let me see if I got this write.
This is not meant as a spam mail but I can't help myself to correct
this horrible mistake. Obviously I meant "right", instead of "write".
:)
[Having this error spread across multiple mailing list archives
On Thu, Mar 18, 2010 at 6:51 AM, Andrew Pinski wrote:
> On Wed, Mar 17, 2010 at 11:38 PM, Paulo J. Matos wrote:
>
>
> I cannot remember when half
> float support came in though, I thought it was only added on the trunk
> or did you backport that support too.
>
Thanks for the tips. However, I did
34 matches
Mail list logo
