Jean Christophe Beyler writes:
> I set up your patch and I get an internal error on this test program:
You're right. I haven't handled the case properly when the constant itself
was an anchor constant (e.g. 0). Try this version.
Adam
* cse.c (get_const_anchors): New function.
Hi,
I think I found a generic problem for fixed point constant folding.
In fold-const.c:11872 gcc tries to apply:
/* Transform (x >> c) << c into x & (-1<> c
into x & ((unsigned)-1 >> c) for unsigned types. */
I attached a simple patch which fixes the problem by not applying this
"Bingfeng Mei" writes:
> In foo function, compute_record_mode function will set the mode for
> struct COMPLEX as BLKmode partly because STRICT_ALIGNMENT is 1 on my
> target. In TARGET_RETURN_IN_MEMORY hook, I return 1 for BLKmode type
> and 0 otherwise for small size (<8) (like MIPS). Thus, this
Dear all,
I've been working on explaining to GCC the cost of loads/stores on my
target and I arrived to this problem. Consider the following code:
uint64_t sum = 0;
for(i=0; i
"Ph. Marek" writes:
> Philipp Marek marek.priv.at> writes:
>> > gcc -S tmp.S for some reason prints to stdout, so gcc -S tmp.S > tmp.s
>> > is what you need
>> Thank you very much, I'll take a look.
> I tried very hard to achieve that; and one time it seemed to work, but I
> cannot
> make it wo
Eric Fisher writes:
> I'd like to get more helpful information from the final .S file, such
> as basic block info, so that I can draw a cfg graph through a script.
The basic block information and the CFG graph is not reliable at that
point in the compilation. Your patch will work reliably for s
On Mon, Mar 16, 2009 at 7:06 PM, Toon Moene wrote:
> [ Perhaps we need a somewhat larger audience for this one, as it isn't a
> gfortran specific issue (despite the COMMONs). ]
>
> The reporter of this problem (perhaps it's necessary to open a bugzilla PR)
> uses:
>
> It is GNU/linux on x86_64, f
[ Perhaps we need a somewhat larger audience for this one, as it isn't a
gfortran specific issue (despite the COMMONs). ]
The reporter of this problem (perhaps it's necessary to open a bugzilla
PR) uses:
It is GNU/linux on x86_64, fedora 10
kernel 2.6.27.12-170.2.5.fc10.x86_64
glibc-2.9-3.x
On Mon, Mar 16, 2009 at 06:19:01PM +0100, Joel Porquet wrote:
> 2009/3/12 Daniel Jacobowitz :
> > On Thu, Mar 12, 2009 at 02:02:36PM +0100, Joel Porquet wrote:
> >> > Check what symbol is at, or near, 0x4003 + 22368. It's probably
> >> > the GOT plus a constant bias.
> >>
> >> It seems there i
2009/3/12 Daniel Jacobowitz :
> On Thu, Mar 12, 2009 at 02:02:36PM +0100, Joel Porquet wrote:
>> > Check what symbol is at, or near, 0x4003 + 22368. It's probably
>> > the GOT plus a constant bias.
>>
>> It seems there is nothing at this address. Here is the program header:
>
> Don't know then
On Mon, Mar 16, 2009 at 12:11 PM, Adam Nemet wrote:
> Ramana Radhakrishnan writes:
>> [Resent because of account funnies. Apologies to those who get this twice]
>>
>> Hi,
>>
>> > > This problem is reported every once in a while, all targets with
>> > small
>> > > load-immediate instructions suffer
On Mon, Mar 16, 2009 at 2:52 PM, Ramana Radhakrishnan
wrote:
> Wouldn't doing this in CSE only solve the problem within an extended basic
> block and not necessarily across the program ? Surely you'd want to do it
> globally or am I missing something very basic here ?
Why so serious^Wsurely?
I t
Ramana Radhakrishnan writes:
> [Resent because of account funnies. Apologies to those who get this twice]
>
> Hi,
>
> > > This problem is reported every once in a while, all targets with
> > small
> > > load-immediate instructions suffer from this, especially since GCC
> > 4.0
> > > (i.e. since t
Bingfeng Mei wrote:
> I just updated our porting to include last 2-3 weeks of GCC
> developments. I noticed a large number of test failures at -O1 that
> use a user-defined data type (based on a special register file of
> our processor). All variables of such type are now spilled to memory
> which
I got mixed results with icc
for
--
short a;
void g(short);
void f(void)
{ g(a); }
--
it produces a movswl. For
---
void g(int);
void f(short a) {
g(a);
}
--
it produces a movswq.
For the original tes
Hello,
I just updated our porting to include last 2-3 weeks of GCC developments. I
noticed a large number of test failures at -O1 that use a user-defined data
type (based on a special register file of our processor). All variables of such
type are now spilled to memory which we don't allow at -O
What about allowing for more backports from the graphite
branch if this drags out for an extended period of time? In
particular, I am thinking of those changes in graphite branch
that might reduce those cases where -fgraphite-identity
degrades the performance of the resulting code.
villa gogh wrote:
> hi
> now i'm trying to construct def-use chain after the PASS_LEAF_REGS.
> for the ssa form structure has been destoried during the former
> passes.
> I have found that gcc provides a way to build the def-use chain in the
> PASS_REGRENAME, but it only contains the defs and uses
hi
now i'm trying to construct def-use chain after the PASS_LEAF_REGS.
for the ssa form structure has been destoried during the former
passes.
I have found that gcc provides a way to build the def-use chain in the
PASS_REGRENAME, but it only contains the defs and uses all in one
basic block.
so if
[Resent because of account funnies. Apologies to those who get this twice]
Hi,
> > This problem is reported every once in a while, all targets with
> small
> > load-immediate instructions suffer from this, especially since GCC
> 4.0
> > (i.e. since tree-ssa). But it seems there is just not enoug
Zuxy Meng wrote:
> Hi,
>
> "Timothy Madden" 写入消息
!
>> I am sure having twice the number of registers (sse+387) would make a
>> big difference.
You're not counting the rename registers, you're talking about 32-bit mode
only, and you're discounting the different mode of accessing the registers.
>>
On 3/16/09, Paolo Bonzini wrote:
>AND R1, R0, #31
>MOV R2, R2, SHIFT R1
>ANDS R1, R0, #32
>MOVNE R2, R2, SHIFT #31
>MOVNE R2, R2, SHIFT #1
>
> or
>
>ANDS R1, R0, #32
>MOVNE R2, R2, SHIFT #-32
>SUB R1, R1, R0 ; R1 = (x >= 32 ? 32 - x : -x)
>MOV R2,
NightStrike wrote:
> On Fri, Mar 13, 2009 at 1:58 PM, Joseph S. Myers
> wrote:
>> Given the SC request we need to stay in Stage 4 rather than trying to work
>> around it.
>
> What if GCC went back to stage 3 until the issue is resolved, thus
> opening the door for a number of stage3-type patches
Hi,
"Timothy Madden" 写入消息
news:5078d8af0903120218i23b69a4bma28ad9b3f1bd4...@mail.gmail.com...
On Thu, Mar 12, 2009 at 1:15 AM, Jan Hubicka wrote:
Timothy Madden wrote:
> Hello
>
> Is -mfpmath=both for i386 and x86-64 still experimental in gcc 4.3, as
> the in the online manual page ?
[...]
Philipp Marek marek.priv.at> writes:
> > gcc -S tmp.S for some reason prints to stdout, so gcc -S tmp.S > tmp.s
> > is what you need
> Thank you very much, I'll take a look.
I tried very hard to achieve that; and one time it seemed to work, but I cannot
make it work again.
As an example I'm tryin
Martin Guy wrote:
> On 3/14/09, Paolo Bonzini wrote:
>> Hans-Peter Nilsson wrote:
>> > The answer to the question is "no", but I'd guess the more
>> > useful answer is "yes", for different definitions of "truncate".
>>
>> Ok, after my patches you will be able to teach GCC about this definition
>
On 3/14/09, Paolo Bonzini wrote:
> Hans-Peter Nilsson wrote:
> > The answer to the question is "no", but I'd guess the more
> > useful answer is "yes", for different definitions of "truncate".
>
> Ok, after my patches you will be able to teach GCC about this definition
> of truncate.
I expect
27 matches
Mail list logo
