On 8 December 2010 00:12, Jeff Law wrote:
> On 12/07/10 12:29, Frédéric RISS wrote:
>>
>> Le mardi 07 décembre 2010 à 06:18 -0700, Jeff Law a écrit :
>>>
>>> On 12/06/10 15:07, Ian Lance Taylor wrote:
>>> Given the two loads don't have a def-use data dependency combine won't
>>> ever get the oppor
> On 12/07/2010 04:20 PM, Andi Kleen wrote:
>>
>> The only problem left is mixing of lto and non lto objects. this right
>> now is not handled. IMHO still the best way to handle it is to use
>> slim lto and then simply separate link the "left overs" after deleting
>> the LTO objects. This can be ac
I have noticed gcc 4.4.5 often produces less optimzed code
than the old 3.4.6. Below is the latest example. I am
starting to wonder if I need rebuild gcc 4.4.5 and/or
add new options to gcc when I compile. Any insight?
Jocke
const char *test(int i)
{
const char *p = "abc\0def\0gef";
On Tue, Dec 7, 2010 at 8:31 PM, Eugen Wagner
wrote:
> Hi,
> Are any kinds of flow-dependent points-to analysis computed on gimple
> in ssa form?
> in which pass?
In tree-ssa-structalias.c we compute points-to analysis. It is flow-sensitive
only for pointers in SSA form.
Richard.
>
> regards,
>
The GCC 4.5 branch is now frozen in preparation for a release candidate
of GCC 4.5.2 and a release of GCC 4.5.2 about a week later.
Please refrain from checking in any patches to the branch without
an explicit approval from a release manager.
Thanks,
Richard.
A release candidate for GCC 4.5.2 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.2-RC-20101208
and shortly its mirrors. It has been generated from SVN revision 167585.
I have so far bootstrapped and tested the release candidate on
x86_64-linux, bootstraps and tests on
{i686,ia64
On Wed, Dec 8, 2010 at 1:19 AM, Andi Kleen wrote:
>> On 12/07/2010 04:20 PM, Andi Kleen wrote:
>>>
>>> The only problem left is mixing of lto and non lto objects. this right
>>> now is not handled. IMHO still the best way to handle it is to use
>>> slim lto and then simply separate link the "left
Joakim Tjernlund writes:
> I have noticed gcc 4.4.5 often produces less optimzed code
> than the old 3.4.6. Below is the latest example. I am
> starting to wonder if I need rebuild gcc 4.4.5 and/or
> add new options to gcc when I compile. Any insight?
This question as stated is not really approp
On 12/08/10 01:40, Frederic Riss wrote:
On 8 December 2010 00:12, Jeff Law wrote:
On 12/07/10 12:29, Frédéric RISS wrote:
Le mardi 07 décembre 2010 à 06:18 -0700, Jeff Law a écrit :
On 12/06/10 15:07, Ian Lance Taylor wrote:
Given the two loads don't have a def-use data dependency combine won
On 8 December 2010 15:39, Jeff Law wrote:
> On 12/08/10 01:40, Frederic Riss wrote:
>> Sorry, I think I wasn't clear. I didn't mean constraints in term on
>> RTL template constraints, but 'constraints' coming from the new DI
>> destination of the load. More specifically: 2 SI loads can target
>> t
I have tried to play a bit with SMS on ia64 and I can't understand
what it is doing.
It seems that instead of getting some of the first insns out of the
loop into the prologue it simply gets an entire iteration out of the
loop and the loop's content stays approximately the same.
For example for
v
On 12/08/10 09:18, Frederic Riss wrote:
OK, I see your point, but I tend to think the the odds of the register
allocator being able to coalesce the additional DI->SI moves in the
pre-IRA approach are by far higher that the odds of having merge
candidates after register allocation.
I agree, but
On Wed, Dec 8, 2010 at 4:37 AM, Joakim Tjernlund
wrote:
>
> I have noticed gcc 4.4.5 often produces less optimzed code
> than the old 3.4.6. Below is the latest example. I am
> starting to wonder if I need rebuild gcc 4.4.5 and/or
> add new options to gcc when I compile. Any insight?
Jocke,
As I
On Dec 8, 2010, at 11:37 AM, Jeff Law wrote:
> On 12/08/10 09:18, Frederic Riss wrote:
>>
>> OK, I see your point, but I tend to think the the odds of the register
>> allocator being able to coalesce the additional DI->SI moves in the
>> pre-IRA approach are by far higher that the odds of having
Paul Koning writes:
> This probably has been discussed at length in the past, but as a
> relative newcomer I'll make this observation... I wonder how much is
> lost by GCC's insistence that multi-register values must be in
> adjacent registers. Obviously that's hard to change (the registers
> w
On 12/08/10 09:43, Paul Koning wrote:
On Dec 8, 2010, at 11:37 AM, Jeff Law wrote:
On 12/08/10 09:18, Frederic Riss wrote:
OK, I see your point, but I tend to think the the odds of the register
allocator being able to coalesce the additional DI->SI moves in the
pre-IRA approach are by far high
David Edelsohn wrote on 2010/12/08 17:38:11:
>
> On Wed, Dec 8, 2010 at 4:37 AM, Joakim Tjernlund
> wrote:
> >
> > I have noticed gcc 4.4.5 often produces less optimzed code
> > than the old 3.4.6. Below is the latest example. I am
> > starting to wonder if I need rebuild gcc 4.4.5 and/or
> > add
Hi Roy,
I guess SMS didn't pipeline your loop, and the
"prologue" code mentioned in your email is
an iteration peeled off from the loop. It has
nothing to do with prologue code.
I think there are two reasons that can explain why
your code is not pipelined:
1. Alias information is not enough to d
On Wed, Dec 8, 2010 at 5:54 AM, H.J. Lu wrote:
> On Wed, Dec 8, 2010 at 1:19 AM, Andi Kleen wrote:
>>> On 12/07/2010 04:20 PM, Andi Kleen wrote:
The only problem left is mixing of lto and non lto objects. this right
now is not handled. IMHO still the best way to handle it is to use
On 12/08/2010 01:19 AM, Andi Kleen wrote:
>>
>> Quite possibly a better way to deal with that is to provide a mechanism
>> for encapsulating arbitrary binary code objects inside the LTO IR.
>
> Then you would need to teach your assembler and everything
> else that may generate ELF objects to gener
On 12/08/2010 01:19 AM, Andi Kleen wrote:
>
> To be honest I don't really see the point of all this complexity you
> guys are proposing just to save fat LTO. Fat LTO is always a bad idea
> because it's slow and does lots of redundant work. If LTO is to become
> a more wide spread mode it has to g
On 8 December 2010 17:37, Jeff Law wrote:
> On 12/08/10 09:18, Frederic Riss wrote:
>>
>> OK, I see your point, but I tend to think the the odds of the register
>> allocator being able to coalesce the additional DI->SI moves in the
>> pre-IRA approach are by far higher that the odds of having merg
Sir i plan to make gcc port for android. I only know c++. Please tell me how
should i make.
On Wed, Dec 8, 2010 at 1:19 AM, Andi Kleen wrote:
>> On 12/07/2010 04:20 PM, Andi Kleen wrote:
>>>
>>> The only problem left is mixing of lto and non lto objects. this right
>>> now is not handled. IMHO still the best way to handle it is to use
>>> slim lto and then simply separate link the "left
ually committed.
Fang
A release candidate for GCC 4.5.2 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.2-RC-20101208
and shortly its mirrors. It has been generated from SVN revision 167585.
I have so far bootstrapped and tested the release candidate on
x86_64-linux, bootstraps and tes
On Wed, Dec 08, 2010 at 02:42:56PM +0100, Richard Guenther wrote:
>
> A release candidate for GCC 4.5.2 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.2-RC-20101208
>
> and shortly its mirrors. It has been generated from SVN revision 167585.
>
> I have
> As someone who encountered slim LTO on Unix 17 years ago (on MIPS) I can
> promise you that unless fat LTO is supported, there will never be a
Fat LTO is just too slow. I suspect with that kind of performance
penalty most people simply would not use it at all.
> successful transition. The amou
> On Wed, Dec 08, 2010 at 02:42:56PM +0100, Richard Guenther wrote:
>>
> This was built against ppl 0.10.2 and cloog 0.15.10.
Have you tried a bootstrap with neither ppl nor cloog ? I have yet to see
their value and I generally exclude them. This results ( thus far ) in
nice clean bootstrap bui
While testing how to parse C and C++ code for function prototypes from a plugin
(see http://gcc.gnu.org/ml/gcc/2010-12/msg00179.html)
I noticed that print_generic_decl() seems to output wrong data.
Consider the following function definition:
--
void barfunc (int foo, int abc, ..
On Wed, Dec 08, 2010 at 01:44:38PM -0500, Dennis Clarke wrote:
>
> > On Wed, Dec 08, 2010 at 02:42:56PM +0100, Richard Guenther wrote:
> >>
> > This was built against ppl 0.10.2 and cloog 0.15.10.
>
> Have you tried a bootstrap with neither ppl nor cloog ? I have yet to see
> their value and I
On Wed, Dec 8, 2010 at 11:05 AM, Jack Howarth wrote:
> On Wed, Dec 08, 2010 at 01:44:38PM -0500, Dennis Clarke wrote:
>>
>> > On Wed, Dec 08, 2010 at 02:42:56PM +0100, Richard Guenther wrote:
>> >>
>> > This was built against ppl 0.10.2 and cloog 0.15.10.
>>
>> Have you tried a bootstrap with nei
"viv0411.par...@gmail.com" writes:
> Sir i plan to make gcc port for android. I only know c++. Please tell me how
> should i make.
There already is a gcc port for Android.
If you mean that you want to build gcc for the Android target, see
http://gcc.gnu.org/install/ . Please take any questio
> On Wed, Dec 08, 2010 at 01:44:38PM -0500, Dennis Clarke wrote:
>>
>> > On Wed, Dec 08, 2010 at 02:42:56PM +0100, Richard Guenther wrote:
>> >>
>> > This was built against ppl 0.10.2 and cloog 0.15.10.
>>
>> Have you tried a bootstrap with neither ppl nor cloog ? I have yet to
>> see
>> their v
http://gcc.gnu.org/rsync.html says 17 Gb.
I just did it, and it's up to 22 Gb.
Joakim Tjernlund writes:
> I already sent in a bug with gccbug, hope it shows up
> How long do one have to wait until it is visible?
The gccbug script no longer works and has been removed from current
versions of gcc. You should get a bounce message. Please use
http://gcc.gnu.org/bugzilla/ ins
to go for 4.5, but I didn't see
> an entry log that it was actually committed.
We'll fix it for 4.5.3, the patch seems pretty big so is not
appropriate at this stage.
Richard.
> Fang
>
> > A release candidate for GCC 4.5.2 is available from
> >
> > ftp://gc
On Wed, 8 Dec 2010, Jack Howarth wrote:
> On Wed, Dec 08, 2010 at 01:44:38PM -0500, Dennis Clarke wrote:
> >
> > > On Wed, Dec 08, 2010 at 02:42:56PM +0100, Richard Guenther wrote:
> > >>
> > > This was built against ppl 0.10.2 and cloog 0.15.10.
> >
> > Have you tried a bootstrap with neither
> On Wed, 8 Dec 2010, Jack Howarth wrote:
>> On Wed, Dec 08, 2010 at 01:44:38PM -0500, Dennis Clarke wrote:
>> > > On Wed, Dec 08, 2010 at 02:42:56PM +0100, Richard Guenther wrote:
>> > >>
>> > > This was built against ppl 0.10.2 and cloog 0.15.10.
>> >
>> > Have you tried a bootstrap with neither
On Wed, Dec 08, 2010 at 09:16:23PM +0100, Richard Guenther wrote:
> On Wed, 8 Dec 2010, Jack Howarth wrote:
>
> > On Wed, Dec 08, 2010 at 01:44:38PM -0500, Dennis Clarke wrote:
> > >
> > > > On Wed, Dec 08, 2010 at 02:42:56PM +0100, Richard Guenther wrote:
> > > >>
> > > > This was built against
On Wed, Dec 8, 2010 at 1:52 PM, I wrote:
> This outputs "static void barfunc (int);" but the function is neither
> static nor does it expect only one int parameter...
here's another example where print_generic_decl() fails:
---
typedef void (*Handler)( int , void * );
Handler
On Wed, Dec 8, 2010 at 10:40 AM, Andi Kleen wrote:
> The gcc maintainers unfortunately didn't want to integrate the
> wrapper scripts to make it easy, but they can be always downloaded
> separately and I assume distributions will eventually ship
> them anyways.
No we do just not as scripts. We w
On Wed, 8 Dec 2010, Andrew Pinski wrote:
> On Wed, Dec 8, 2010 at 10:40 AM, Andi Kleen wrote:
> > The gcc maintainers unfortunately didn't want to integrate the
> > wrapper scripts to make it easy, but they can be always downloaded
> > separately and I assume distributions will eventually ship
>
On 08/12/2010 18:40, Andi Kleen wrote:
> Fat LTO is just too slow. I suspect with that kind of performance
> penalty most people simply would not use it at all.
How slow is "too" slow? How many people out of a hundred won't use it? Got
numbers, or just a gut feeling?
cheers,
DaveK
43 matches
Mail list logo
