Subject says it all, I guess.
Jakub
Kaveh R. GHAZI wrote:
> Hello,
>
> A prerelease tarball of the upcoming MPC 0.7 is available here:
> http://www.multiprecision.org/mpc/download/mpc-0.7-dev.tar.gz
>
> Please help test it for portability and bugs by downloading and compiling
> it on systems you have access to.
Fell at the first
Dave Korn wrote:
> Fell at the first hurdle for me:
>
> gcc-4 -shared-libgcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D_FORTIFY_SOURCE=2
> -p
> edantic -Wall -Wextra -Werror -O2 -pipe -MT inp_str.lo -MD -MP -MF
> .deps/inp_str
> .Tpo -c inp_str.c -DDLL_EXPORT -DPIC -o .libs/inp_str.o
> cc1: war
Dave Korn wrote:
> Attached allowed it to build,
And with that patch:
> ===
> All 45 tests passed
> ===
cheers,
DaveK
On Wed, Aug 26, 2009 at 03:02:44PM -0400, Bradley Lucier wrote:
> On Wed, 2009-08-26 at 20:38 +0200, Paolo Bonzini wrote:
> >
> > > When I worked at AMD, I was starting to suspect that it may be more
> > > beneficial
> > > to re-enable the first schedule insns pass if you were compiling in 64-bit
Hi,
I'm using gcc version 4.1.2 20080704 (Red Hat 4.1.2-44) for a x86
target. The info page says:
`-mpush-args'
`-mno-push-args'
Use PUSH operations to store outgoing parameters. This method is
shorter and usually equally fast as method using SUB/MOV
operations and is enabled by d
Dear all,
I have been also been looking into how to generate a function call for
certain operations. I've looked at various other targets for a similar
problem/solution but have not seen anything. On my target
architecture, we have certain optimized versions of the multiplication
for example.
I w
Peter Bergner wrote:
On Mon, 2009-08-24 at 23:56 +, Charles J. Tabony wrote:
I am seeing a performance regression on the port I maintain, and I would
appreciate some pointers.
When I compile the following code
void f(int *x, int *y){
*x = 7;
*y = 4;
}
with GCC 4.3.2, I get the des
On 08/31/2009 07:20 PM, Jean Christophe Beyler wrote:
Ok, is it normal to see a ashift with a negative value though or is
this already sign of a (potentially) different problem?
I seem to recall that it's normal. Combine was originally
written in the days of VAX, where negative shifts were all
On 08/31/2009 05:06 PM, Richard Henderson wrote:
The following patch appears to work for both. I'll commit
it after a bootstrap and test cycle completes.
Committed with one additional change, to prevent VRP
from crashing.
r~
(vrp_visit_stmt): Be prepared for non-interesting stmts.
Minor correction to my previous email:
On Tue, Sep 1, 2009 at 10:08 AM, Godmar Back wrote:
>
> gb...@setzer [39](~/tmp) > cat call.c
> void caller(void) {
> extern void callee(int);
> callee(5);
> }
This:
> gb...@setzer [40](~/tmp) > gcc -mno-push-args -S call.c
should be '-mpush-args' as
Is it required that the same compiler that generated lto objects be used
to read them? I've come across a couple ICEs with the current revision
reading lto objects created by a slightly older version but same
configuration. Is this simply invalid usage of my part?
Regards,
Ryan Mansfield
On Tue, Sep 1, 2009 at 11:42, Ryan Mansfield wrote:
> Is it required that the same compiler that generated lto objects be used to
> read them? I've come across a couple ICEs with the current revision reading
> lto objects created by a slightly older version but same configuration. Is
> this simply
On 08/28/2009 12:38 AM, Adam Nemet wrote:
... To assist the linker we need to annotate the indirect call
with the function symbol.
Since the call is expanded early...
Having experimented with this on Alpha a few years back,
the only thing I can suggest is to not expand them early.
I use a com
Godmar Back writes:
> It appears to me that '-mno-push-args' is the enabled by default (*),
> and not '-mpush-args'.
The default varies by processor--it dependson the -mtune option.
> Moreover, since -maccumulate-outgoing-args
> implies -mno-push-args, it appears that the only way to obtain
> '
Jean Christophe Beyler writes:
> I have been also been looking into how to generate a function call for
> certain operations. I've looked at various other targets for a similar
> problem/solution but have not seen anything. On my target
> architecture, we have certain optimized versions of the mu
On 08/19/2009 06:50 AM, Mohamed Shafi wrote:
mov _h,d4
mov _h+4,d5
mov _j,d2
mov _j+4,d3
addd4,d2
adcd5,d3
irrespective of which endian it is.
What could i be missing here? Should i add anything specific for this
in the back-end?
Diego Novillo wrote:
On Tue, Sep 1, 2009 at 11:42, Ryan Mansfield wrote:
Is it required that the same compiler that generated lto objects be used to
read them? I've come across a couple ICEs with the current revision reading
lto objects created by a slightly older version but same configuration
I have looked at how other targest use the
init_builtins/expand_builtins. Of course, I don't understand
everything there but it seems indeed to be more for generating a
series of instructions instead of a function call. I haven't seen
anything resembling what I want to do.
I had also first thought
Ryan Mansfield writes:
> The objects were created with rev 15 and being read using 151271.
> No, I can't reproduce the ICE using the same version.
> Thanks for confirming this is not expected to work.
Is it the intent that this work properly in the future? It is not
absurd to imagine that s
On Tue, Sep 1, 2009 at 14:32, Frank Ch. Eigler wrote:
> Ryan Mansfield writes:
>
>> The objects were created with rev 15 and being read using 151271.
>> No, I can't reproduce the ICE using the same version.
>> Thanks for confirming this is not expected to work.
>
> Is it the intent that this w
On Tue, Sep 1, 2009 at 12:31 PM, Ian Lance Taylor wrote:
> Godmar Back writes:
>
>> It appears to me that '-mno-push-args' is the enabled by default (*),
>> and not '-mpush-args'.
>
> The default varies by processor--it dependson the -mtune option.
I don't know how to find out which tuning is ena
Status
==
The 4.4 branch is open for commits under the usual release branch
rules.
The timing of the 4.4.2 release (at least two months after the 4.4.1
release, so no sooner than September 22) at a point when there are no
P1 regressions open for the branch) has yet to be determined.
Quality
Richard Henderson writes:
> On 08/28/2009 12:38 AM, Adam Nemet wrote:
> > ... To assist the linker we need to annotate the indirect call
> > with the function symbol.
> >
> > Since the call is expanded early...
>
> Having experimented with this on Alpha a few years back,
> the only thing I can sug
On Wed, 2009-08-26 at 17:12 -0500, Peter Bergner wrote:
> On Wed, 2009-08-26 at 23:30 +0200, Richard Guenther wrote:
> > Hmm. I suppose if you conditionalize it on flag_schedule_insns it might be
> > an overall win. Care to SPEC test that change?
>
> I assume you mean like the change below? Yea
On Tue, 2009-09-01 at 10:38 -0400, Vladimir Makarov wrote:
> We could do update_equiv_regs in a separate pass before the 1st insn
> scheduling as it was before IRA.
IIRC, update_equiv_regs() was always called as part of local-alloc,
so it was always after sched1 even before IRA. That said, movin
Peter Bergner wrote:
On Tue, 2009-09-01 at 10:38 -0400, Vladimir Makarov wrote:
We could do update_equiv_regs in a separate pass before the 1st insn
scheduling as it was before IRA.
IIRC, update_equiv_regs() was always called as part of local-alloc,
so it was always after sched1 even b
On 09/01/2009 12:48 PM, Adam Nemet wrote:
I see. So I guess you're saying that there is little chance to optimize the
loop I had in my previous email ;(.
Not at the rtl level. Gimple-level loop splitting should do it though.
Now suppose we split late, shouldn't we still assume that data-flo
Diego Novillo wrote:
On Tue, Sep 1, 2009 at 11:42, Ryan Mansfield wrote:
Is it required that the same compiler that generated lto objects be used to
read them? I've come across a couple ICEs with the current revision reading
lto objects created by a slightly older version but same configurat
On Tue, 2009-09-01 at 16:46 -0400, Vladimir Makarov wrote:
> Peter Bergner wrote:
> > Were you going to whip that patch up or did you want me to?
> >
> I am going to do it by myself.
Great! I'd like to see how your patch affects POWER6 performance.
Do you have access to a POWER6 box? If not, can
Richard Henderson writes:
> On 09/01/2009 12:48 PM, Adam Nemet wrote:
> > I see. So I guess you're saying that there is little chance to optimize the
> > loop I had in my previous email ;(.
>
> Not at the rtl level. Gimple-level loop splitting should do it though.
>
> > Now suppose we split lat
Actually, what I've done is probably something in between what you
were suggesting and what I was initially doing. If we consider the
multiplication, I've modified the define_expand for example to:
(define_expand "muldi3"
[(set (match_operand:DI 0 "register_operand" "")
(mult:DI (match_o
Jean Christophe Beyler writes:
> First off: does this seem correct?
Awkward though it is, it may be more reliable to build a small tree here
and pass it to expand_call. This assumes that you want to use the
standard ABI when calling this function.
Then your second issue would go away.
Ian
I don't think I quite understand what you're meaning. I want to use
the standard ABI, basically I want to transform certain operations
into function calls.
In regard to what you said, do you mean I should build the tree before
the expand pass, by writing a new pass that will work on the trees
inst
Finally, I guess the one thing I can do is simply generate
pseudo_registers and copy all my registers into the pseudos before the
call I make.
Then I do my expand like I showed above.
And finally, move everything back.
Later passes will remove anything that was not needed, anything that
was will
Jean Christophe Beyler writes:
> In regard to what you said, do you mean I should build the tree before
> the expand pass, by writing a new pass that will work on the trees
> instead of rtx?
Oh, sorry, I'm an idiot. I forgot that you only have RTL at this point.
I would go with what you wrote
Snapshot gcc-4.4-20090901 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090901/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi,
On Mon, 31 Aug 2009, Pedro Lamarão wrote:
> 2009/8/28 Pedro Lamarão :
>
> > I have not yet made complete size and execution speed measurements, though.
> > I've run the test suite and there are some failures; I think many of
> > them are not regressions when compared with a pure build with C
38 matches
Mail list logo
