On Thu, 2009-10-08 at 08:49 +0200, Zdenek Dvorak wrote:
> Hi,
>
> > > Ah, indeed. Sorry for being confused. Is tree-niter-desc->assumptions
> > > or ->may_be_zero non-NULL?
> >
> > Yes both. I attached the gdb content for both.
>
> you need to check may_be_zero, which in your case should conta
> On Wed, Oct 7, 2009 at 7:21 PM, Tobias Grosser
> wrote:
> > On Wed, 2009-10-07 at 18:30 +0200, Tobias Grosser wrote:
> >> On Wed, 2009-10-07 at 17:44 +0200, Richard Guenther wrote:
> >> > On Wed, Oct 7, 2009 at 5:35 PM, Tobias Grosser
> >> > wrote:
> >> > > On Wed, 2009-10-07 at 17:23 +0200, Ri
Hi,
> > Ah, indeed. Sorry for being confused. Is tree-niter-desc->assumptions
> > or ->may_be_zero non-NULL?
>
> Yes both. I attached the gdb content for both.
you need to check may_be_zero, which in your case should contain
something like N <= 49. If this condition is true, the number of
ite
Edd Barrett writes:
> I would be really interested to know how GCC:
> * Decides whether or not to embed tables in the data segment of the binary.
> * Selects the comparisons in the above tree.
The relevant code is expand_case and friends in gcc/stmt.c. Where a
jump table should go is decided
Interestingly, on darwin, it appears that the trigger for the generation
of the duplicate .eh symbols is not -freorder-blocks-and-partition but the
additional use of -fprofile-use -D_PROFILE_USE. When I drop the profiling
from gcc.dg/tree-prof/bb-reorg.c and gcc.dg/tree-prof/pr34999.c, they comp
While constructing a patch to resolve PR41313 on darwin, I noticed an oddity.
The problem in PR41313 is due to hot/cold partitioning not being understood by
darwin_emit_unwind_label() such that duplicate .eh symbols can be created. This
can be fixed by restoring the previous behavior for disabl
Hi there,
I am new here, so I wish to take a second to introduce myself and what
I am working on, then ultimately why I am posting on this list. Also I
will apologise if this is the wrong place to post this query. If this
is so, perhaps you could point me in the right direction.
I have just start
On Wed, Oct 7, 2009 at 7:21 PM, Tobias Grosser
wrote:
> On Wed, 2009-10-07 at 18:30 +0200, Tobias Grosser wrote:
>> On Wed, 2009-10-07 at 17:44 +0200, Richard Guenther wrote:
>> > On Wed, Oct 7, 2009 at 5:35 PM, Tobias Grosser
>> > wrote:
>> > > On Wed, 2009-10-07 at 17:23 +0200, Richard Guenther
On Wed, 2009-10-07 at 18:30 +0200, Tobias Grosser wrote:
> On Wed, 2009-10-07 at 17:44 +0200, Richard Guenther wrote:
> > On Wed, Oct 7, 2009 at 5:35 PM, Tobias Grosser
> > wrote:
> > > On Wed, 2009-10-07 at 17:23 +0200, Richard Guenther wrote:
> > >> On Wed, Oct 7, 2009 at 5:16 PM, Tobias Grosser
Hi,
thanks for the report! It is actually more promising than I've
expected. A while ago I did similar tests with whole-program and
--combine and we didn't get very consistent with performance (I saw also
code size reductions). I guess geomaverage will go down for specint
after vpr/gcc/perlbmk/g
On Wed, Oct 7, 2009 at 5:35 PM, Tobias Grosser
wrote:
> On Wed, 2009-10-07 at 17:23 +0200, Richard Guenther wrote:
>> On Wed, Oct 7, 2009 at 5:16 PM, Tobias Grosser
>> wrote:
>> > On Wed, 2009-10-07 at 16:42 +0200, Richard Guenther wrote:
>> >> On Wed, Oct 7, 2009 at 4:37 PM, Tobias Grosser
>> >>
On Wed, 2009-10-07 at 17:23 +0200, Richard Guenther wrote:
> On Wed, Oct 7, 2009 at 5:16 PM, Tobias Grosser
> wrote:
> > On Wed, 2009-10-07 at 16:42 +0200, Richard Guenther wrote:
> >> On Wed, Oct 7, 2009 at 4:37 PM, Tobias Grosser
> >> wrote:
> >> > I try to analyse this code:
> >> > ---
On Wed, Oct 7, 2009 at 5:16 PM, Tobias Grosser
wrote:
> On Wed, 2009-10-07 at 16:42 +0200, Richard Guenther wrote:
>> On Wed, Oct 7, 2009 at 4:37 PM, Tobias Grosser
>> wrote:
>> > I try to analyse this code:
>> > --
>> > int foo (int N)
>> > {
>
On Wed, 2009-10-07 at 16:42 +0200, Richard Guenther wrote:
> On Wed, Oct 7, 2009 at 4:37 PM, Tobias Grosser
> wrote:
> > I try to analyse this code:
> > --
> > int foo (int N)
> > {
> > int ftab[257];
> > int i, j;
> >
> > for (i = 0; i < N -
> It sounds to me like this confusion comes from "LTO plugins". Isn't
> it just "LTO plugin"? That is, a specific plugin?
There is one GCC plugin. LLVM has another one. The fully qualified
name is probably something like "gold plugin for gcc lto".
> --
> Daniel Jacobowitz
> CodeSourcery
>
Chee
Diego Novillo writes:
> On Wed, Oct 7, 2009 at 10:34, Daniel Jacobowitz wrote:
>> On Wed, Oct 07, 2009 at 04:29:29PM +0200, Basile STARYNKEVITCH wrote:
>>> I suppose LTO plugins means plugin dlopen-ed in lto-plugin/lto-symtab.c
>>
>> It sounds to me like this confusion comes from "LTO plugins".
On Wed, Oct 7, 2009 at 4:37 PM, Tobias Grosser
wrote:
> I try to analyse this code:
> --
> int foo (int N)
> {
> int ftab[257];
> int i, j;
>
> for (i = 0; i < N - 7488645; i++)
> j = ftab [i];
>
> return j;
> }
>
On Wed, Oct 7, 2009 at 10:34, Daniel Jacobowitz wrote:
> On Wed, Oct 07, 2009 at 04:29:29PM +0200, Basile STARYNKEVITCH wrote:
>> I suppose LTO plugins means plugin dlopen-ed in lto-plugin/lto-symtab.c
>
> It sounds to me like this confusion comes from "LTO plugins". Isn't
> it just "LTO plugin"?
On Wed, Oct 7, 2009 at 4:25 PM, Vladimir Makarov wrote:
> Jan Hubicka wrote:
>>
>> So things seems to work now plus minus as expected. I.e. LTO builds
>> seems similar to combined builds and whole-programs improves code size
>> quite noticeably.
>> Runtime results for gzip are pretty much unchang
I try to analyse this code:
--
int foo (int N)
{
int ftab[257];
int i, j;
for (i = 0; i < N - 7488645; i++)
j = ftab [i];
return j;
}
--
The number of iterations I get is:
(unsig
On Wed, Oct 07, 2009 at 04:29:29PM +0200, Basile STARYNKEVITCH wrote:
> I suppose LTO plugins means plugin dlopen-ed in lto-plugin/lto-symtab.c
It sounds to me like this confusion comes from "LTO plugins". Isn't
it just "LTO plugin"? That is, a specific plugin?
--
Daniel Jacobowitz
CodeSourcer
On Wed, Oct 7, 2009 at 10:29, Basile STARYNKEVITCH
wrote:
> I suppose LTO plugins means plugin dlopen-ed in lto-plugin/lto-symtab.c
No, it does not mean that. As I said already, these are plugins for
gold, the linker. It is gold the one that uses it.
Diego.
Diego Novillo wrote:
On Wed, Oct 7, 2009 at 10:10, Basile STARYNKEVITCH
wrote:
Then I would imagine it requires a copyright transfer to FSF different of
the one covering GCC development. The legal document covering my
contribution cites specifically GCC (not binutils).
Getting that copyright
Jan Hubicka wrote:
So things seems to work now plus minus as expected. I.e. LTO builds
seems similar to combined builds and whole-programs improves code size
quite noticeably.
Runtime results for gzip are pretty much unchanged, but that is
expected. I am quite curoius about full SPEC run.
Bef
On Wed, Oct 7, 2009 at 10:12, Ian Lance Taylor wrote:
> Diego Novillo writes:
>
>> On Wed, Oct 7, 2009 at 09:55, Basile STARYNKEVITCH
>> wrote:
>>
>>> Are LTO plugins fondamentally different from others, non LTO plugins?
>>
>> Yes, it should be probably be named 'linker' plugins. It's a plugin
Diego Novillo writes:
> On Wed, Oct 7, 2009 at 09:55, Basile STARYNKEVITCH
> wrote:
>
>> Are LTO plugins fondamentally different from others, non LTO plugins?
>
> Yes, it should be probably be named 'linker' plugins. It's a plugin
> for gold to allow extraction of individual .o files out of sta
On Wed, Oct 7, 2009 at 10:10, Basile STARYNKEVITCH
wrote:
> Then I would imagine it requires a copyright transfer to FSF different of
> the one covering GCC development. The legal document covering my
> contribution cites specifically GCC (not binutils).
>
> Getting that copyright transfer signed
On Wed, 7 Oct 2009, David Edelsohn wrote:
> I am pleased to announce that the GCC Steering Committee has
> appointed Diego Novillo, Rafael Avila de Espindola, and Richard Guenther
> as LTO Reviewers, and Rafael Avila de Espindola and Cary Coutant as
> LTO Plugin Reviewers.
>
> Thanks
Diego Novillo wrote:
On Wed, Oct 7, 2009 at 09:55, Basile STARYNKEVITCH
wrote:
Are LTO plugins fondamentally different from others, non LTO plugins?
Yes, it should be probably be named 'linker' plugins. It's a plugin
for gold to allow extraction of individual .o files out of static
archives
> Btw, that new comdat behavior is very well reasonable. In
> whole-program mode it should be the old one though.
It is another effect of the patch that in whole-program we bring all
comdat functions static except for those having address taken (so the
address must be same from all modules)
I was
On Wed, Oct 7, 2009 at 09:55, Basile STARYNKEVITCH
wrote:
> Are LTO plugins fondamentally different from others, non LTO plugins?
Yes, it should be probably be named 'linker' plugins. It's a plugin
for gold to allow extraction of individual .o files out of static
archives during LTO compiles.
David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
appointed Diego Novillo, Rafael Avila de Espindola, and Richard Guenther
as LTO Reviewers, and Rafael Avila de Espindola and Cary Coutant as
LTO Plugin Reviewers.
Sorry, but what exactly are LTO plugins?
I am pleased to announce that the GCC Steering Committee has
appointed Diego Novillo, Rafael Avila de Espindola, and Richard Guenther
as LTO Reviewers, and Rafael Avila de Espindola and Cary Coutant as
LTO Plugin Reviewers.
Thanks to everyone for their hard work bringing LTO to GCC
On Wed, Oct 7, 2009 at 2:33 PM, Jan Hubicka wrote:
>> Anyway, as regards *which* specific functions are not inlined, I would
>> say all the functions which break the ABI test as newly exported symbols
>> should be checked, like the above, 'std::ios_base::getloc() const'. I'm
>> attaching below a c
> Anyway, as regards *which* specific functions are not inlined, I would
> say all the functions which break the ABI test as newly exported symbols
> should be checked, like the above, 'std::ios_base::getloc() const'. I'm
> attaching below a complete list, from my libstdc++.log, but I would
> guess
Hi Honza,
>>> 2
>>> _ZNKSt8ios_base6getlocEv
>>> std::ios_base::getloc() const
>>> version status: incompatible
>>> GLIBCXX_3.4
>>> type: function
>>> status: added
>>>
>>> Are there very recent inlining changes?
>>>
>> Yes.
>>
> This might be patch I commited today morning. It would h
> > 2
> > _ZNKSt8ios_base6getlocEv
> > std::ios_base::getloc() const
> > version status: incompatible
> > GLIBCXX_3.4
> > type: function
> > status: added
> >
> > Are there very recent inlining changes?
>
> Yes.
This might be patch I commited today morning. It would help if you
could just send m
Richard Guenther wrote:
> Yes.
>
Thanks ;) I'm going to tighten the patterns asap, cannot hurt. For the
record, on testresults there are no big traces of this issue, this is
puzzling, no idea why some people do not reproduce my problems...
Paolo.
On Wed, Oct 7, 2009 at 12:24 PM, Paolo Carlini wrote:
> Hi,
>
> today I'm seeing an ABI check failure in mainline, x86_64-linux, 11
> incompatible symbols: my preliminary analysis shows that the problem is
> the recurring one, simple, but annoying: some small functions are not
> inlined anymore, t
Hi,
today I'm seeing an ABI check failure in mainline, x86_64-linux, 11
incompatible symbols: my preliminary analysis shows that the problem is
the recurring one, simple, but annoying: some small functions are not
inlined anymore, thus inadvertently exported (with an old version
number, because of
Apologies if you receive multiple copies of this call.
CALL FOR PAPERS
2nd Workshop on
GCC Research Opportunities
On Wed, Oct 7, 2009 at 8:53 AM, Charles J. Tabony
wrote:
> Fellow GCC developers,
>
> Does GCC make any effort to collapse control-flow that is guaranteed to
> have undefined behavior? Such an optimization would improve performance
> of Proc_2 from Dhrystone:
>
>
> typedef int One_Fifty;
> t
42 matches
Mail list logo
