On 12/14/06, Benoît Jacob <[EMAIL PROTECTED]> wrote:
I don't understand why you say that. At the language specification level,
templates come with no inherent speed overhead. All of the template stuff is
unfolded at compile time, none of it remains visible in the binary, so it
shouldn't make the
Le mercredi 13 décembre 2006 23:09, Denis Vlasenko a écrit :
> C++ doesn't specify that compiler shall unroll loops, so it cannot be
> classified as "real" bug.
OK, but then, even if I explicitly ask gcc to unroll loops
with -funroll-loops, it still doesn't unroll them completely and is still as
On 12/13/06, Frank Riese <[EMAIL PROTECTED]> wrote:
One of my professors stated that a GCC Back End uses the Control Flow Graph as
its input and that generation of RTL expressions occurs later on.
That is not true.
What roles
do Back and Middle End play in generation of RTL? Would you conside
I am pleased to announce that the GCC Steering Committee has
appointed Eric Christopher as Darwin co-maintainer.
Please join me in congratulating Eric on his new role. Eric,
please update your listings in the MAINTAINERS file.
Happy hacking!
David
Disclaimer: I am not a compiler developer.
On Wednesday 13 December 2006 12:44, Benoît Jacob wrote:
> I'm developing a Free C++ template library (1) in which it is very important
> that certain loops get unrolled, but at the same time I can't unroll them by
> hand, because they depend on templat
Hi!
I need some clearification concerning the responsibilities of Middle End, Back
End, the generation of the control flow graph (CFG) and RTL. I looked at
several articles about the internal structure of the GCC and looked at the
internals documentation. However, I would like to have a second
Hi,
On Tue, 12 Dec 2006 16:52:33 +0100, Jakub Jelinek wrote:
...
> Here is something that would handle by default same_value retaddr_column:
[ http://sources.redhat.com/ml/gdb/2006-12/msg00100.html ]
Thanks for this backward compatible glibc unwinder patch. I wish to have it
accepted as a step i
Jack Howarth wrote:
I noticed that boehm-gc check doesn't work from within
the dejagnu framework. According to the notes in PR11412,
this was going to be fixable once the multi-lib stuff
was moved to the top level. I assume this has happened by
now so can we fix this for gcc 4.2?
I noticed that boehm-gc check doesn't work from within
the dejagnu framework. According to the notes in PR11412,
this was going to be fixable once the multi-lib stuff
was moved to the top level. I assume this has happened by
now so can we fix this for gcc 4.2?
Jack
Hi,
On Tue, 12 Dec 2006, Ulrich Drepper wrote:
> > Really? Well, that's one interpretation. I don't believe that,
> > though. It's certainly an inconsistency in the specification, which
> > says that null-termination is supported, and this implies that you
> > can't put a zero in there.
>
Hi,
On Mon, 11 Dec 2006, Jan Kratochvil wrote:
> currently (on x86_64) the gdb backtrace does not properly stop at the
> outermost
> frame:
>
> #3 0x0036ddb0610a in start_thread () from /lib64/tls/libpthread.so.0
> #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6
> #5 0x00
Hi,
On Tue, 12 Dec 2006, Andrew Haley wrote:
> > > In practice, %ebp either points to a call frame -- not necessarily
> > > the most recent one -- or is null. I don't think that having an
> > > optional frame pointer mees you can use %ebp for anything random at
> > > all, but we need to m
> ...which seems to be the case. Even when configure is told to use gld,
> somewhere down the line, gcc eventually decides that it should use
> /usr/ccs/bin/ld instead.
You need to rebuild the whole compiler if you want to switch from the Sun
tools to GNU binutils, i.e --with-gnu-ld should be pas
On 12/13/06, Menezes, Evandro <[EMAIL PROTECTED]> wrote:
> Meissner, Michael wrote:
> >>> 437.leslie3d -26%
> > it was felt that the PPRE patches that were added on
> November 13th were
> > the cause of the slowdown:
> > http://gcc.gnu.org/ml/gcc/2006-12/msg00023.html
> >
> > Has anybody tri
> Meissner, Michael wrote:
> >>> 437.leslie3d -26%
> > it was felt that the PPRE patches that were added on
> November 13th were
> > the cause of the slowdown:
> > http://gcc.gnu.org/ml/gcc/2006-12/msg00023.html
> >
> > Has anybody tried doing a run with just ppre disabled?
>
> Right. PPRE
On 12/13/06, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote:
Meissner, Michael wrote:
>>> 437.leslie3d-26%
> it was felt that the PPRE patches that were added on November 13th were
> the cause of the slowdown:
> http://gcc.gnu.org/ml/gcc/2006-12/msg00023.html
>
> Has anybody tried doing a r
Meissner, Michael wrote:
437.leslie3d-26%
it was felt that the PPRE patches that were added on November 13th were
the cause of the slowdown:
http://gcc.gnu.org/ml/gcc/2006-12/msg00023.html
Has anybody tried doing a run with just ppre disabled?
Right. PPRE appears to be the reason of slow
On Wed, 13 Dec 2006, Ian Lance Taylor wrote:
When I try it, gcc does unroll the loops. It completely unrolls the
inner loop, but only partially unrolls the outer loop. The reason it
doesn't completely unroll the outer loop is simply that gcc doesn't
attempt to completely unroll loops which cont
Benoît Jacob <[EMAIL PROTECTED]> writes:
> I'm developing a Free C++ template library (1) in which it is very important
> that certain loops get unrolled, but at the same time I can't unroll them by
> hand, because they depend on template parameters.
>
> My problem is that G++ 4.1.1 (Gentoo) do
begin quoting Eric Botcazou as of Thu, Nov 30, 2006 at 10:05:21PM +0100:
[snip]
> ... if the user is trying to link objects files assembled by the GNU assembler
> using the Sun linker.
...which seems to be the case. Even when configure is told to use gld,
somewhere down the line, gcc eventually d
I had already tried that. That doesn't change anything.
I had also tried passing a higher --param max-unroll-times. No effect.
So, any idea? The example program toto.cpp is so simple, I can't believe g++
can't handle it. Surely there must be something simple that I haven't
understood?
Benoit
On 12/13/06, Sandeep Kumar <[EMAIL PROTECTED]> wrote:
Hi all,
I tried compiling the above two programs :
on x86, 32 bit machines.
[EMAIL PROTECTED] ~]# gcc test.c
Try with optimization enabled (try -O1 and/or -O2).
Gr.
Steven
On 12/13/06, Benoît Jacob <[EMAIL PROTECTED]> wrote:
g++ -DUNROLL -O3 toto.cpp -o toto ---> toto runs in 0.3 seconds
g++ -O3 toto.cpp -o toto---> toto runs in 1.9 seconds
So what can I do? Is that a bug in g++? If yes, any hope to see it fixed soon?
You could try adding -funroll-
Quoting Steven Bosscher <[EMAIL PROTECTED]>:
> On 12/13/06, Joern Rennecke <[EMAIL PROTECTED]> wrote:
> > In http://gcc.gnu.org/ml/gcc/2006-12/msg00328.html, you wrote:
> > However, because the SH has delayed branches, there is always a guaranteed
> way
> > to find a register - one can be saved, a
Hi,
I'm developing a Free C++ template library (1) in which it is very important
that certain loops get unrolled, but at the same time I can't unroll them by
hand, because they depend on template parameters.
My problem is that G++ 4.1.1 (Gentoo) doesn't unroll these loops.
I have written a sta
Hi all,
I tried compiling the above two programs :
on x86, 32 bit machines.
And when I used objdump on that I saw the following code.
Can anyone help me know,
Why in the objdump of our first program the esp is decremented by 18H bytes
and in the second program the esp is decremented by 28H bytes.
On 12/13/06, Joern Rennecke <[EMAIL PROTECTED]> wrote:
In http://gcc.gnu.org/ml/gcc/2006-12/msg00328.html, you wrote:
However, because the SH has delayed branches, there is always a guaranteed way
to find a register - one can be saved, and then be restored in the delay slot.
Heh, that's an inte
In http://gcc.gnu.org/ml/gcc/2006-12/msg00328.html, you wrote:
>> On 06 Dec 2006 23:13:35 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> If you can't afford to lose a register, then I think your only option
>> is to pick some callee-saved register and have each branch instruction
>
28 matches
Mail list logo
