Richard Sandiford writes:
> Jan Hubicka writes:
>> the problem is sign overflow in time computation. Time should be
>> capped by MAX_TIME and we compute MAX_TIME * INLINE_SIZE_SCALE *
>> 2. This happens to be >2^31 & <2^32 so we overflow here because of use
>> of signed arithmetics.
>>
>> Index:
Jan Hubicka writes:
> the problem is sign overflow in time computation. Time should be
> capped by MAX_TIME and we compute MAX_TIME * INLINE_SIZE_SCALE *
> 2. This happens to be >2^31 & <2^32 so we overflow here because of use
> of signed arithmetics.
>
> Index: ipa-inline-analysis.c
> ===
> > This caused:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49179
> >
> >
>
> This also caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49091
>
Hi,
the problem is sign overflow in time computation. Time should be capped by
MAX_TIME
and we compute MAX_TIME * INLINE_SIZE_SCALE *
On Thu, May 26, 2011 at 9:53 PM, H.J. Lu wrote:
> On Fri, Apr 22, 2011 at 5:35 AM, Jan Hubicka wrote:
>> Hi,
>> this patch implements infrastructure to summarize function body size&time in
>> a
>> way that is sensitive on function context. At the moment context means
>>
>> 1) if function is in
On Fri, Apr 22, 2011 at 5:35 AM, Jan Hubicka wrote:
> Hi,
> this patch implements infrastructure to summarize function body size&time in a
> way that is sensitive on function context. At the moment context means
>
> 1) if function is inline or offline
> 2) if some of parameters are known compil
Honza,
This patch appears to fix the failure on AIX: my build progressed past
libstdc++.
Thanks, David
2011/4/30 Jan Hubicka :
>> On Thu, Apr 28, 2011 at 9:27 AM, Jan Hubicka wrote:
>> >> Honza,
>> >>
>> >> I continue to receive an ICE:
>> >>
>> >> /farm/dje/src/src/libstdc++-v3/include/precomp
> On Thu, Apr 28, 2011 at 9:27 AM, Jan Hubicka wrote:
> >> Honza,
> >>
> >> I continue to receive an ICE:
> >>
> >> /farm/dje/src/src/libstdc++-v3/include/precompiled/stdc++.h:94:0:
> >> /tmp/20110427/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/valarray:1163:1:
> >> internal compiler error: vector
> Honza,
>
> I continue to receive an ICE:
>
> /farm/dje/src/src/libstdc++-v3/include/precompiled/stdc++.h:94:0:
> /tmp/20110427/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/valarray:1163:1:
> internal compiler error: vector VEC(tree,base) index domain error, in
> evaluate_conditions_for_edge at i
Honza,
I continue to receive an ICE:
/farm/dje/src/src/libstdc++-v3/include/precompiled/stdc++.h:94:0:
/tmp/20110427/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/valarray:1163:1:
internal compiler error: vector VEC(tree,base) index domain error, in
evaluate_conditions_for_edge at ipa-inline-analys
>
> This may have caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48791
Oops, yes, it is mine. The insertion hook at expansion time is incorrectly
called
after function is expanded, not before.
ipa-prop should deregister itself earlier, but that can be done incrementally.
I am testi
On Wed, Apr 27, 2011 at 5:16 AM, Jan Hubicka wrote:
> Hi,
> I don't really have testcase for the HP nor AIX ICE, however I can reproduce
> same ICE when I hack x86 to
> not use ctors/dtors. This patch fixes it - the problem is that ipa-prop
> ignore newly added functions
> (the global ctor buil
Hi,
I don't really have testcase for the HP nor AIX ICE, however I can reproduce
same ICE when I hack x86 to
not use ctors/dtors. This patch fixes it - the problem is that ipa-prop ignore
newly added functions
(the global ctor built) while ipa-inline not and ipa-inline does use ipa-prop
for its
> Honza,
>
> This patch causes a bootstrap failure when building libstdc++ on AIX:
>
> In file included from
> /farm/dje/src/src/libstdc++-v3/include/precompiled/stdc++.h:94:0:
> /tmp/20110423/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/valarray:1163:1:
> internal compiler error: vector VEC(tree,
Honza,
This patch causes a bootstrap failure when building libstdc++ on AIX:
In file included from
/farm/dje/src/src/libstdc++-v3/include/precompiled/stdc++.h:94:0:
/tmp/20110423/powerpc-ibm-aix5.3.0.0/libstdc++-v3/include/valarray:1163:1:
internal compiler error: vector VEC(tree,base) index doma
> > The problem is that cgraph_node->uid will be sparse after merging. I
> > wonder if we want
> > to solve this by adding new uids to the analyzed nodes that will be denser?
> > Most of summaries
> > are actually attached to the analyzed nodes only.
>
> Can't we re-number the UIDs after mergin
On Sat, Apr 23, 2011 at 1:00 AM, Jan Hubicka wrote:
> Hi,
> the patch also solves inliner compile time problems for mozilla:
> garbage collection : 15.88 ( 4%) usr 0.00 ( 0%) sys 15.89 ( 4%) wall
> 0 kB ( 0%) ggc
> callgraph optimization: 3.10 ( 1%) usr 0.00 ( 0%) sys 3.09 (
Hi,
the patch also solves inliner compile time problems for mozilla:
garbage collection: 15.88 ( 4%) usr 0.00 ( 0%) sys 15.89 ( 4%) wall
0 kB ( 0%) ggc
callgraph optimization: 3.10 ( 1%) usr 0.00 ( 0%) sys 3.09 ( 1%) wall
15604 kB ( 1%) ggc
varpool construction : 0.69
17 matches
Mail list logo
