New size data -- hopefully it is sane this time.
Changes in experiment
1) shared libstdc++ is used with trunk gcc
2) bfd linker is used in both trunk and patched 4.4.3 compiler (which
used gold).
The size comparison for all C benchmarks in previous report is still
valid. The following is the corr
Rainer Orth wrote:
Tobias Burnus writes:
Rainer Orth wrote:
While the build completed with the patch I've posted, fortran testing
for the non-default multilib is completely broken, e.g.
That's in a way the a duplicate of PR 46516. Or at least the solution is
I don't think so: this seems to b
Hi,
Given a basic block BB, is there a way to tell if it will reach EXIT_BLOCK_PTR?
Thanks.
--
H.J.
MAINTAINERS lists:
m68hc11 portStephane Carrez stcar...@nerim.fr
However, the carbon copies of by patch for PR target/46436, as well
as the ping, bounced for the stated email address.
Reporting-MTA: dns; tyrande.nerim.net
X-Postfix-Queue-ID: E05DBB88E
X-Postfix-Sender: rfc82
On Thu, Nov 18, 2010 at 4:12 PM, Jan Hubicka wrote:
> Hi,
>> I'll get back to you with our local inlining changes. We're looking to move
>> development closer to trunk to reduce this divergence in the future.
>>
>> Our tuning was done primarily on big c++ programs. A significant size
>> improvem
Quoting Tom de Vries :
About the penalty, I don't really know. But since the optimization is
both filling delay slots and removing
duplicate code, it looks like a good idea to me.
It's usually beneficial, but for some microarchitectures, this kind of
code confuses the branch predictor.
So ther
Hi,
> I'll get back to you with our local inlining changes. We're looking to move
> development closer to trunk to reduce this divergence in the future.
>
> Our tuning was done primarily on big c++ programs. A significant size
> improvement came from aggressively inlining functions which might b
Hi Jeff,
However, that doesn't work for the second example:
...
beq$3,$0,$L14
nop
$L7:
andi$2,$2,0x
...
bne$3,$0,$L7
nop
$L14:
andi$2,$2,0x
...
...
What is different from the first example, is that here the beq owns
neither the
fall-throug
Snapshot gcc-4.5-20101118 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20101118/
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/branches
On Thu, 18 Nov 2010, Joern Rennecke wrote:
> You could do this with:
> typedef struct { int arch; void *p; } cumulative_args_t;
> or
> typedef struct { int arch; void *p; } *cumulative_args_t;
>
> with regards to the conversion function, that could be provided in
> target-def.h
>
> static inline
On Thu, 2010-11-18 at 09:18 -0800, Ian Lance Taylor wrote:
> Andrew has asked for autotesters for Java; I don't run any autotesters
> and I don't want to sign up for that. Can somebody volunteer for that?
> Presumably anybody currently running an autotester could add an explicit
> --enable-languag
* Rainer Orth wrote on Thu, Nov 18, 2010 at 06:32:59PM CET:
> Ralf Wildenhues writes:
> > * Rainer Orth wrote on Wed, Nov 17, 2010 at 09:15:55PM CET:
> >>
> >> * One cannot -lm to libquadmath_la_LIBADD since that gets passed to nm,
> >> which doesn't know (and doesn't need to be run) -lm.
> >
>
Quoting "Joseph S. Myers" :
struct cumulative_args could always be defined (automatically) to contain
a union between the target structures
This assumes
- every target uses a structure, and
- the names of all target's structures are unambigous, and
- the full definition of all the targets stru
On Thu, 18 Nov 2010, Joern Rennecke wrote:
> Quoting "Joseph S. Myers" :
>
> > You can perfectly well do type safety without using void *.
> >
> > struct cumulative_args;
> > type hook(struct cumulative_args *arg);
> >
> >
> > static inline struct x86_cumulative_args *
> > x86_get_cumulative_a
Quoting "Joseph S. Myers" :
You can perfectly well do type safety without using void *.
struct cumulative_args;
type hook(struct cumulative_args *arg);
static inline struct x86_cumulative_args *
x86_get_cumulative_args (struct cumulative_args *arg)
{struct cumulative_args *
return (struct x
On 11/18/10 10:31, Tom de Vries wrote:
I'm working on improving delay-slot scheduling and would appreciate
advice on a
problem I encountered.
Oh boy
The problem is: how to add support for placing a CODE_LABEL on an
instruction in
a delay slot?
My impression is that this is not support
Jeremy Hall writes:
> I wonder if its possible to improve the code generation for inline
> stringops when
> the length is known to be a multiple of 4 bytes?
The selection of the algorithm is fairly complex and depends on the
specific processor you are tuning for. See decide_alg in
config/i386/i
On Thu, 18 Nov 2010, Joern Rennecke wrote:
> Maybe you should talk more with your colleagues. I had protested when the
> CUMULATIVE_ARGS taking vectors were added to targetm, and I was told they'd
> be changed to taking void *, thus eliminating the problem.
> Now people don't want void * because
Quoting "Joseph S. Myers" :
On Thu, 18 Nov 2010, Joern Rennecke wrote:
1: At the end, target-def.h initalizes targetm, and whatever vectors we
might want to split out of it nor or in the future.
Disapprove, in the form in which you describe it. A key point of
splitting vectors is that dif
On 18/11/2010 17:18, Ian Lance Taylor wrote:
> At this point does anybody strongly object to committing the patch.
Nah, I've been persuaded by the arguments advanced and withdraw my previous
objection.
cheers,
DaveK
> I wouldn't mind this change. It is still the case that Ada will
> selectively turn itself off when it cannot find a stage0 gnat
> compiler, right?
Right.
I found an error in my size experiment set up -- (libstdc++ shared vs
non shared) -- please discard the size numbers -- will remeasure.
Thanks,
David
On Thu, Nov 18, 2010 at 4:02 AM, Jan Hubicka wrote:
> Hi,
> and for size, could you please also do -Os comparsions? I am aware that -O2
> inline
Ralf Wildenhues writes:
> * Rainer Orth wrote on Wed, Nov 17, 2010 at 09:15:55PM CET:
>>
>> * One cannot -lm to libquadmath_la_LIBADD since that gets passed to nm,
>> which doesn't know (and doesn't need to be run) -lm.
>
> That's a bug in the rule using nm then, though.
I'm not completely su
I'm working on improving delay-slot scheduling and would appreciate
advice on a
problem I encountered.
The problem is: how to add support for placing a CODE_LABEL on an
instruction in
a delay slot?
My impression is that this is not supported currently. One way to
implement this
would be to a
Tobias Burnus writes:
> Rainer Orth wrote:
>> While the build completed with the patch I've posted, fortran testing
>> for the non-default multilib is completely broken, e.g.
>
> That's in a way the a duplicate of PR 46516. Or at least the solution is
I don't think so: this seems to be an issue
Mark Mitchell writes:
> On 11/11/2010 3:20 PM, Ian Lance Taylor wrote:
>> On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor wrote:
>>> Currently we build the Java frontend and libjava by default. At the GCC
>>> Summit we raised the question of whether should turn this off, thus only
>>> buildi
On 11/18/2010 9:16 AM, Diego Novillo wrote:
> I wouldn't mind this change. It is still the case that Ada will
> selectively turn itself off when it cannot find a stage0 gnat
> compiler, right?
I don't mind this either, but let's treat them as orthogonal. Let's not
let a possible change on the A
On Thu, Nov 18, 2010 at 08:49, Arnaud Charlet wrote:
> And finally as some people have noted already, Ada exposes lots of
> interesting latent bugs in the middle-end by exercising code that is
> sometimes rarely used in other front-ends.
>
> So in short, I'm in favor of this change.
I wouldn't m
On Thu, Nov 18, 2010 at 3:58 AM, Jan Hubicka wrote:
>> Some text size measurement.
>>
>> Summary:
>> 1) LTO with -O3 bloats up code considerably;
> Yes, you need either -fwhole-program or -fuse-linker-plugin to make it behave
> sanely.
>
> For Mozilla I have best experience with -fuse-linker-plugi
On Thu, 18 Nov 2010, Joern Rennecke wrote:
> 1: At the end, target-def.h initalizes targetm, and whatever vectors we
> might want to split out of it nor or in the future.
Disapprove, in the form in which you describe it. A key point of
splitting vectors is that different vectors are linked in
> > I'd like to reiterate a request from the summit that is related to the
> > default languages discussion: Add Ada to the default languages in
> > exchange
> > for java+libjava. It builds nicely parallel (and fairly quick), doesn't
>
> I should point out while supporting this (and, in general,
On Thu, 18 Nov 2010, Michael Matz wrote:
> I'd like to reiterate a request from the summit that is related to the
> default languages discussion: Add Ada to the default languages in exchange
> for java+libjava. It builds nicely parallel (and fairly quick), doesn't
I should point out while sup
On Thu, Nov 18, 2010 at 4:59 PM, Richard Guenther
wrote:
> On Thu, Nov 18, 2010 at 4:41 PM, Michael Matz wrote:
>> Hi,
>>
>> On Thu, 18 Nov 2010, Jeff Law wrote:
>>
>>> > I think that it should still be the case that if you break Java, and
>>> > one of the Java testers catches you, you still have
What is annoying in the implementation of this patch:
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01810.html
is, that for what is essentially only a minor re-arranging of the
hook vectors, I had to create such a huge patch because all the
call sites of the moved hooks are affected, and also every
On 11/18/2010 07:50 AM, Ralf Wildenhues wrote:
* Rainer Orth wrote on Wed, Nov 17, 2010 at 09:15:55PM CET:
* One cannot -lm to libquadmath_la_LIBADD since that gets passed to nm,
which doesn't know (and doesn't need to be run) -lm.
That's a bug in the rule using nm then, though.
[...]
Using
On Thu, Nov 18, 2010 at 07:37, Mark Mitchell wrote:
> On 11/18/2010 2:00 AM, Andrew Haley wrote:
>
>> I made it pretty clear that as long as the autotesters build java, and I
>> get emails when something breaks, and you have the obligation to fix
>> whatever broke, I have no objection.
>
> Great.
On Thu, Nov 18, 2010 at 4:41 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 18 Nov 2010, Jeff Law wrote:
>
>> > I think that it should still be the case that if you break Java, and
>> > one of the Java testers catches you, you still have an obligation to
>> > fix the problem. All we're changing is whe
Hi,
On Thu, 18 Nov 2010, Jeff Law wrote:
> > I think that it should still be the case that if you break Java, and
> > one of the Java testers catches you, you still have an obligation to
> > fix the problem. All we're changing is whether you build Java by
> > default; nothing else.
>
> Agree
On 11/18/2010 2:00 AM, Andrew Haley wrote:
> I made it pretty clear that as long as the autotesters build java, and I
> get emails when something breaks, and you have the obligation to fix
> whatever broke, I have no objection.
Great. In contrast to Ian's statement, then, I think we *do* have a
On 11/18/10 02:23, Mark Mitchell wrote:
On 11/11/2010 3:20 PM, Ian Lance Taylor wrote:
On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor wrote:
Currently we build the Java frontend and libjava by default. At the GCC
Summit we raised the question of whether should turn this off, thus only
bui
Joern Rennecke wrote:
> Quoting Konrad Eisele :
>
>> Maybe there is a simple way to achieve both multilib and singlelib?
>
> The (short-term) simple way is to have two separate configurations.
> For a more flexible approach, look at how the SH port allows you to
> mix & match your multilibs.
>
>
Quoting Konrad Eisele :
Maybe there is a simple way to achieve both multilib and singlelib?
The (short-term) simple way is to have two separate configurations.
For a more flexible approach, look at how the SH port allows you to
mix & match your multilibs.
On Thu, Nov 18, 2010 at 2:00 AM, Andrew Haley wrote:
> On 11/18/2010 09:23 AM, Mark Mitchell wrote:
>> On 11/11/2010 3:20 PM, Ian Lance Taylor wrote:
>>> On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor wrote:
Currently we build the Java frontend and libjava by default. At the GCC
Su
Eric Botcazou wrote:
>> Jiri Gaisler has now signed the FSF copyleft (it took quite long to get
>> through the procedure) and I was said that I could post the patches
>> now.
>
> Thanks for your perseverance.
>
>> The patches are straightforward I think.
>> 1. Adds machine description gcc-4.4.2/g
> Jiri Gaisler has now signed the FSF copyleft (it took quite long to get
> through the procedure) and I was said that I could post the patches
> now.
Thanks for your perseverance.
> The patches are straightforward I think.
> 1. Adds machine description gcc-4.4.2/gcc/config/sparc/leon.md
> 2. gcc
On 11/18/2010 01:50 PM, H.J. Lu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42670#c8
I'm sorry, yesterday didn't follow those exchanges in any detail, was
too absorbed by something else. Thus, if I understand correctly,
updating the testsuite in such a way is more or less an obvious change
On Thu, Nov 18, 2010 at 3:35 AM, Paolo Carlini wrote:
> Hi,
>
> this is to warn people that between yesterday and today
> abi/demangle/regression/cw-13.cc regressed on x86 / x86_64 linux: it
> looks like somebody didn't regression test the C++ testsuite carefully
> enough.
>
> HJ, could you please
Hi,
and for size, could you please also do -Os comparsions? I am aware that -O2
inliner is tuned somewhat up at C++. This is given by fact that we do have C++
benchmark suite we use to monitor inlining.
http://gcc.opensuse.org/c++bench-frescobaldi/
Programs there are a lot more aggressive on abs
Hello,
Jiri Gaisler has now signed the FSF copyleft (it took quite long to get
through the procedure) and I was said that I could post the patches
now.
The patches are straightforward I think.
1. Adds machine description gcc-4.4.2/gcc/config/sparc/leon.md
2. gcc-4.4.2.ori/gcc/config/sparc/sparc.c:
> Some text size measurement.
>
> Summary:
> 1) LTO with -O3 bloats up code considerably;
Yes, you need either -fwhole-program or -fuse-linker-plugin to make it behave
sanely.
For Mozilla I have best experience with -fuse-linker-plugin --param
inline-unit-growth=5 That gives me about 16% code s
Hi Folks,
GCC 4.5.1 20100924 "-Os -minline-all-stringops" on Core i7
int
main( int argc, char *argv[] )
{
int i, a[256], b[256];
for( i = 0; i < 256; ++i ) // discourage optimization
a[i] = rand();
memcpy( b, a, argc * sizeof(int) );
printf( "%d\n", b[rand()] ); // discourag
Hi,
this is to warn people that between yesterday and today
abi/demangle/regression/cw-13.cc regressed on x86 / x86_64 linux: it
looks like somebody didn't regression test the C++ testsuite carefully
enough.
HJ, could you please run a binary search? Thanks a lot in advance,
Paolo.
On 11/18/2010 09:23 AM, Mark Mitchell wrote:
> On 11/11/2010 3:20 PM, Ian Lance Taylor wrote:
>> On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor wrote:
>>> Currently we build the Java frontend and libjava by default. At the GCC
>>> Summit we raised the question of whether should turn this off,
On 11/11/2010 3:20 PM, Ian Lance Taylor wrote:
> On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor wrote:
>> Currently we build the Java frontend and libjava by default. At the GCC
>> Summit we raised the question of whether should turn this off, thus only
>> building it when java is explicitly
54 matches
Mail list logo
