http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
--- Comment #9 from Jan Hubicka 2010-11-10 22:35:46 UTC
---
The inline heuristics should take that into account. But at the moment
io block simply always prevent inlining function with IO into function without
IO.
We consider function with more t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
--- Comment #11 from Jan Hubicka 2010-11-10 22:50:08
UTC ---
Ok, it might be interesting to run some fortran benchmarks with the
large-stack-frame parameter
bumped up. If it helps, I think we can just do so for 4.6.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
--- Comment #14 from Jan Hubicka 2010-11-10 23:05:25
UTC ---
> Note that the IO block escapes and thus cannot be coalesced with others in
> the same function. I had a frontend patch to re-use the same IO struct
> across multiple calls but that w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45721
--- Comment #3 from Jan Hubicka 2010-11-11 14:16:07 UTC
---
Hi,
handling of weaks and weakrefs is indeed deeply broken with LTO. I plan to
look into it after pushing more of the stuff
I don't want to get into mainline too late in stage3. That is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46423
--- Comment #4 from Jan Hubicka 2010-11-11 14:57:57 UTC
---
> --- Comment #3 from Richard Guenther 2010-11-11
> 14:22:23 UTC ---
> The testcase is supposed to not ICE or hang, the diagnostics indeed come
> and go, so it's fine to expect them ag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46446
--- Comment #2 from Jan Hubicka 2010-11-12 04:49:49 UTC
---
> The above ones are just caused by including -flto -flto-partition=none in the
> torture flags now, not to mention they fail before with -flto :).
Yes, those are old failures, just with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334
--- Comment #13 from Jan Hubicka 2010-11-15 15:22:19
UTC ---
Static profile estimation problem, to be exact. LTO is just triggering it by
bringing in enough of context ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46367
--- Comment #6 from Jan Hubicka 2010-11-15 15:37:12 UTC
---
> doesn't terminate but endlessly recurses. I can't see how it should work
> in a cgraph cycle:
It recurse only on edges that are already inlined and inlined edges should
never form a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371
--- Comment #6 from Jan Hubicka 2010-11-17 23:01:58 UTC
---
The problem with not recomputing address taken flag is solved. The testcase
still
failed to iling because of type mismatch (i.e. one() instead of one(void)).
You probably could fix your
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076
--- Comment #13 from Jan Hubicka 2010-11-18 12:07:51
UTC ---
> That said - the middle-end doesn't really have a notion of "unprototyped".
> That's a concept the frontend should lower (at call-sites, but that
> requires some middle-end infrastruct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46554
--- Comment #2 from Jan Hubicka 2010-11-19 10:57:57 UTC
---
> I thought partial inlining would maybe fix this? Otherwise it's really a
> case that needs IP analysis.
Not with -Os, we really know that it will optimize away.
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510
--- Comment #19 from Jan Hubicka 2010-11-21 16:16:51
UTC ---
> ../../../work/libgomp/barrier.c:41:1: internal compiler error: in
> decide_is_variable_needed, at varpool.c:341
Hmm, interesting, get_emutls_init_templ_addr should no longer call
fin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510
--- Comment #22 from Jan Hubicka 2010-11-21 17:47:33
UTC ---
> Honza,
> I don't know how to do a backtrace in gdb when the compiler exits in gdb
> during the run as...
>
> Program exited with code 04.
breakpoint on internal_error should hel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510
--- Comment #26 from Jan Hubicka 2010-11-21 18:55:03
UTC ---
> This seems to work:
This is OK, thanks!
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46528
--- Comment #18 from Jan Hubicka 2010-11-25 12:56:35
UTC ---
> we do CFG manipulations based on debug stmts (verified with a later
> assert that triggers on -O2 -g -fprofile-use).
>
> It's of course unfortunate that we do this BB splitting at al
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #13 from Jan Hubicka 2010-12-02 08:47:28
UTC ---
> Yeh, precisely. The ironly file is a placeholder into which we put the
> symbols found in the lto symtab so that they can take part in the link and
> their resolutions be determine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760
--- Comment #6 from Jan Hubicka 2010-12-02 09:00:51 UTC
---
Hi,
at one point I tried profiledbootstrap and problem is that we can not merge
multiple LTO files
that has been profiled different amount of times. This happens during our
build becaus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760
--- Comment #8 from Jan Hubicka 2010-12-02 09:22:38 UTC
---
Hi,
you can still test bootstrap with simply commenting out that sorry. It should
give, sort-of, sane results.
I will implement counter rescaling once I get some time for it - it is not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #16 from Jan Hubicka 2010-12-02 15:34:48
UTC ---
> It's valid I think and we try to work out fPIC ourselves in the funny
> LTO option handling code (but the options are not re-applied at ltrans
> stage I think, so it doesn't work at a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46820
--- Comment #7 from Jan Hubicka 2010-12-11 13:31:21 UTC
---
> int __attribute__((used)) bar(void)
> {
> return 0;
> }
> __asm__(".weak\tfoo\n\t.set\tfoo,bar");
>
> bar ends up in a different partition than the asm which then of course
> doesn'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #10 from Jan Hubicka 2010-12-11 15:01:34
UTC ---
> This explanation doesn't stand: for instance, ARM EABI exclusively uses
> .init_array, and the execution order for those is forward. And when linking
> static libraries, the order of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46820
--- Comment #8 from Jan Hubicka 2010-12-11 15:03:44 UTC
---
Note that while working on mozilla, I noticed that SUN's compiler extends the
toplevel asm syntax by allowing parameters (and the usual %n references to
them). It probably makes sense t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #12 from Jan Hubicka 2010-12-11 16:17:38
UTC ---
> > 2) I believe that the backwarding order of .ctor section was concious
> > QOI issue. I wonder how much legacy code this might break when static
> > libraries start init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #28 from Jan Hubicka 2010-12-11 21:01:08
UTC ---
So I take that, the ctor order is to support priotities, since the
.ctor.priority sections get merged into single and ordered in increasing rather
than decreasing order, while init_arra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916
--- Comment #17 from Jan Hubicka 2010-12-14 10:58:40
UTC ---
> well the pre-existing implementation of :
>
> static section *
> darwin_text_section (int reloc, int weak)
> {
> if (reloc)
> return (weak
> ? darwin_sections[text_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916
--- Comment #19 from Jan Hubicka 2010-12-14 13:18:30
UTC ---
Hi,
does the following patch fix the problem?
darwin_text_section no longer needs to care about hot/cold code since this is
already done in darwin_function_section.
In fact you might a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #60 from Jan Hubicka 2010-12-14 13:25:32
UTC ---
> Sure, if you want to play with that I have no principled objections. I only
> add
> here that we probably have another related PR filed by Ian (is already in CC?)
> and that, as far
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916
--- Comment #33 from Jan Hubicka 2010-12-14 17:32:16
UTC ---
> minor update (this removes a test for reorder & partition + exceptions that is
> carried out too early)
This seem sane to me. I've also posted more fixed to function partitioning
tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916
--- Comment #41 from Jan Hubicka 2010-12-14 22:46:09
UTC ---
> well, unless some interaction from the typo.. (possible) .. AFAICT most of the
> fallout is multiple definitions of .eh symbols...
Actually forcing hot&cold sections to coincide migh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916
--- Comment #51 from Jan Hubicka 2010-12-15 01:52:59
UTC ---
> which I assume should have be a change to...
>
> ! base_section = darwin_text_section (weak);
Ah, yes. Sorry for the typo. Does it make any difference?
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46956
--- Comment #1 from Jan Hubicka 2010-12-15 11:55:41 UTC
---
__GLOBAL__sub_I__GCC_gcc_4_6_reghunt_gcc_testsuite_g__.dg_pch_system_1.C_867072EB_51FA32F0:
__GLOBAL__sub_I__GCC_gcc_4_6_reghunt_gcc_testsuite_g__.dg_pch_system_1.C_867072EB_B88D4144:
H
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916
--- Comment #58 from Jan Hubicka 2010-12-15 13:33:15
UTC ---
> [ the key change is that there need to be coalesced sections for the DECL_WEAK
> () -- I am not strongly saying the sections need to be pre-declared - if you
> think that named sectio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916
--- Comment #60 from Jan Hubicka 2010-12-15 13:49:51
UTC ---
Hi,
yes please try with the darwin bits alone and the hunk in opts.c enabling
function reordering when partitioning is on.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916
--- Comment #63 from Jan Hubicka 2010-12-15 14:07:16
UTC ---
OK,
if the darwin changes + opts.c change solves the problem, lets submit the patch
and I will try to re-review the bb-reorder patch and we can deal with the
problem
incrementally. Than
--- Comment #17 from hubicka at ucw dot cz 2010-04-29 09:27 ---
Subject: Re: [4.4/4.5/4.6 Regression] Performance
degradation for simple fibonacci numbers calculation
This is not correct, when profile is guessed we should look into the
frequencies.
I guess profile is wrong
--- Comment #2 from hubicka at ucw dot cz 2010-04-30 08:45 ---
Subject: Re: [4.6 Regression] FAIL:
gcc.dg/lto/20090126-1 c_lto_20090126-1_0.o-c_lto_20090126-1_0.o
Hi,
the problem here is that the testcase combine -O0 module into -O3 module. This
results in optimization
--- Comment #2 from hubicka at ucw dot cz 2010-04-30 10:57 ---
Subject: Re: SPEC2000 GCC fails to build with
-fprofile-generate -O2 -ffast-math -flto -fwhole-program
This smeells like notice_global_symbol issue again that computes assembler name
on random first symbol in
--- Comment #28 from hubicka at ucw dot cz 2010-05-06 13:50 ---
Subject: Re: [4.6 Regression]
kernel/rtmutex.c:1138:1: internal compiler error: in
cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009
>
>
> --- Comment #27 from justinmattock
--- Comment #32 from hubicka at ucw dot cz 2010-05-08 09:23 ---
Subject: Re: [4.6 Regression]
kernel/rtmutex.c:1138:1: internal compiler error: in
cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009
> o.k... took me a bit, but I got that system up
--- Comment #4 from hubicka at ucw dot cz 2010-05-15 08:39 ---
Subject: Re: [4.6 Regression] emutls is broken under a
range of circumstances.
The problem is because emultls is handling declarations in a way so references
are not visible to
middle end. I guess we need to put
--- Comment #4 from hubicka at ucw dot cz 2010-05-15 08:41 ---
Subject: Re: r159371 breaks bootstrap on
x86_64-apple-darwin10
> It appears that only darwin uses the set_user_assembler_name() call so we
> ought to be able to restore the previous behavior with...
Does thi
--- Comment #7 from hubicka at ucw dot cz 2010-05-15 09:35 ---
Subject: Re: [4.6 Regression] emutls is broken under a
range of circumstances.
Hi,
we can either go with DECL_PRESERVE that is kind of hack but makes situation no
worse.
Correct fix is to lower emultls earlier so
--- Comment #11 from hubicka at ucw dot cz 2010-05-15 13:48 ---
Subject: Re: [4.6 Regression] emutls is broken under a
range of circumstances.
> I'd rather go with the DECL_PRESERVE_P hack for now.
Problem with this is that emultls is still broken with LTO. As so
--- Comment #12 from hubicka at ucw dot cz 2010-05-15 13:49 ---
Subject: Re: [4.6 Regression] emutls is broken under a
range of circumstances.
> I guess, otherwise, we have to intercept every circumstance where a __thread
> var might be used .. and interpose the exchang
--- Comment #19 from hubicka at ucw dot cz 2010-05-16 15:00 ---
Subject: Re: r159371 breaks bootstrap on
x86_64-apple-darwin10
>
>
> --- Comment #17 from iains at gcc dot gnu dot org 2010-05-16 13:51
> ---
> (In reply to comment #16)
> > l
--- Comment #21 from hubicka at ucw dot cz 2010-05-16 17:22 ---
Subject: Re: r159371 breaks bootstrap on
x86_64-apple-darwin10
>
> hmmm.. I don't quite understand this..
> the original ld error was:
> ld: codegen problem, can't use rel32 to externa
--- Comment #7 from hubicka at ucw dot cz 2010-05-19 15:11 ---
Subject: Re: lto1: ICE: tree check: expected field_decl,
have type_decl in gimple_types_compatible_p, at gimple.c:3597
> I suppose this is an alias but we fail to clear its body/block tree. We end
> up refer
--- Comment #4 from hubicka at ucw dot cz 2010-06-09 10:29 ---
Subject: Re: Redundant looping pure functions
whose return value is dead are not optimized out
> > >Why do we remove register LHS in DCE again?
> >
> > Because it reduces the amount of garba
--- Comment #4 from hubicka at ucw dot cz 2010-06-16 16:13 ---
Subject: Re: [4.6 Regression]
gcc.c-torture/execute/frame-address.c
> Confirmed on powerpc-linux. check_fa tail calls check_fa_mid, ignoring the
> fact that check_fa_mid is passed the address of a check_fa
--- Comment #7 from hubicka at ucw dot cz 2010-06-17 06:41 ---
Subject: Re: [4.6 Regression]
gcc.c-torture/execute/frame-address.c
> Hmm. Well, perhaps the thing to do is ensure we don't get a tail call by
> making the same change as in
> http://gcc.gnu.org/
--- Comment #2 from hubicka at ucw dot cz 2010-06-21 08:44 ---
Subject: Re: [4.6 Regression] Revision 159362 caused
multiple failures on the libstdc++-v3 tests
I was fixing bug like this, where function was extern inline and had address
taken in the unit.
Inliner removed
--- Comment #5 from hubicka at ucw dot cz 2010-06-28 08:27 ---
Subject: Re: [4.6 Regression] Partial inlining
breaks C++
> I see those too, for cris-elf; assert failures (49 of them; regress-5 ->
> regress-54). They are *not* gone as of r161481.
In that case I guess
--- Comment #1 from hubicka at ucw dot cz 2010-06-29 13:25 ---
Subject: Re: New: Debug info for partially inlined
functions
Thanks for opening PR on this. One thing I was planning to look into soon is
to make
progress at least reversible - i.e. find way to declare the fact
--- Comment #2 from hubicka at ucw dot cz 2010-07-05 19:02 ---
Subject: Re: Type of ADDR_EXPR in CALL_EXPR
not rebuilt when function is cloned
> It turns out that the problem is that when build_function_type_skip_args
> creates
> the new type, TYPE_POINTER_TO for the
--- Comment #4 from hubicka at ucw dot cz 2010-07-05 19:18 ---
Subject: Re: Type of ADDR_EXPR in CALL_EXPR
not rebuilt when function is cloned
> Hi Honza, my original patch was silly, I'm trying this instead:
This seems fine, thanks!
Honza
--
http://gcc.gnu.org/
--- Comment #5 from hubicka at ucw dot cz 2010-07-06 11:41 ---
Subject: Re: Mozilla build ICE at Invalid first
operand of MEM_REF.
> What's the patch needed to trigger it?
The DECL_BY_REFERENCE change. THe one I sent to list should be enough. So if
you could look int
--- Comment #7 from hubicka at ucw dot cz 2010-07-06 12:00 ---
Subject: Re: Mozilla build ICE at Invalid first
operand of MEM_REF.
> Well, that sounds like caused by your needs_to_live_in_memory change.
>
> There is asymmetry wrt caller / callee and DECL_BY_REFERENCE
--- Comment #4 from hubicka at ucw dot cz 2010-07-06 21:06 ---
Subject: Re: Violation of one-definition rule
Mine is bit more stuble since the duplicated decl does nolead to linker error
unless LTO is used, but might be same or smilar problem.
I made workaround for now and can confirm
--- Comment #6 from hubicka at ucw dot cz 2010-07-07 23:01 ---
Subject: Re: [4.6 Regression] Bootstrap fails with
partial inlining (r161382)
great work! Could you, please, post me the fnsplit, einline2 and inline dumps?
Perhaps I can work out what is wrong there.
(and
--- Comment #7 from hubicka at ucw dot cz 2010-07-09 17:09 ---
Subject: Re: =?iso-8859-2?Q?Bogus_?=
=?iso-8859-2?Q?=22type_of_=91nsLayoutModule=5FNSModule=92_doe?=
=?iso-8859-2?Q?s?= not match original declaration" waning compiling
Mozilla
Hi,
with the
--- Comment #6 from hubicka at ucw dot cz 2010-07-11 12:06 ---
Subject: Re: Maybe bogus Use of type ?struct
nsCSSStyleSheet? with two mismatching declarations at field
?mRuleProcessors? warnings in Mozilla
> Should this (and the other one) not be mentioned upstr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48354
--- Comment #7 from Jan Hubicka 2011-05-24 18:53:14 UTC
---
> Honza, can you try this on mozilla?
Can try, but only after returning from Bertinoro. All connections I found here
filters VPN.
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49194
--- Comment #3 from Jan Hubicka 2011-05-27 16:15:02 UTC
---
> I agree if the called function is big and it is very unlikely (most probably
> just in PROB_VERY_UNLIKELY cases) -finline-functions-called-once shouldn't
> inline.
-finline-functions-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49194
--- Comment #7 from Jan Hubicka 2011-05-27 18:47:56 UTC
---
>
> We used to play with inlining limits (gcc had some really bad decisions), but
> the meaning of the numbers kept changing from one gcc version to another, and
> the heuristics gcc us
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49286
--- Comment #1 from Jan Hubicka 2011-06-05 11:55:22 UTC
---
The problem is that GCC do not see that evil_long is used by the asm statement.
Static variables are renamed (in order to produce single .s file you can't have
two different statics with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49289
--- Comment #1 from Jan Hubicka 2011-06-05 13:42:33 UTC
---
on x86_64 you want -fno-asynchronous-unwind-info. Eh-frame is mandated by the
PS-ABI.
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49282
--- Comment #4 from Jan Hubicka 2011-06-06 11:49:48 UTC
---
> I suppose we keep pointers to inline summaries live across the growth.
Well, we should not. It is resized in inline_summary_alloc () and that
function
is called always before we get a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #104 from Jan Hubicka 2011-06-18 08:53:37
UTC ---
> Even with 8c1fce46fc0 reverted libxul fails to link during
> a profiledbuild. Normal build is fine.
I didn't really tested profiledbuild for a while, so I will check.
Last time I tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49383
--- Comment #3 from Jan Hubicka 2011-06-18 09:00:22 UTC
---
Hi,
the problem is in cgraph_only_called_directl_p call within
call_abi_of_interest.
Getting the one can probably fix the problem by:
Index: rs6000.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49383
--- Comment #8 from Jan Hubicka 2011-06-23 17:09:43 UTC
---
Hi,
sorry for late reply, I was not reading bugs ML very curefully on the GCC
gathering...
> Honza, the code here is called during expansion of functions. If called at
> the
> start of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49533
--- Comment #3 from Jan Hubicka 2011-06-27 10:53:14 UTC
---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49533
>
> --- Comment #2 from Markus Trippelsdorf
> 2011-06-27 10:25:13 UTC ---
> (In reply to comment #1)
> > The patch you quote has th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49568
--- Comment #4 from Jan Hubicka 2011-07-01 08:40:13 UTC
---
> Confirmed, we shouldn't be emitting ~B because it's not needed. Probably
> introduced by r173517,
>
> 2011-05-06 Jan Hubicka
>
> * cgraph.c (cgraph_add_thunk): Create rea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49568
--- Comment #6 from Jan Hubicka 2011-07-01 09:30:41 UTC
---
> This is Tru64 UNIX with ECOFF, no named sections, no COMDAT groups.
Yep, I know, but the question is how absence of COMDAT groups changes behaviour
of thunks.
The problem here is that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49615
--- Comment #4 from Jan Hubicka 2011-07-04 10:05:10 UTC
---
split_bbs_on_noreturn_calls is supposed to handle this scenario...
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
--- Comment #15 from Jan Hubicka 2011-07-05 11:08:50
UTC ---
>
> Do you think you could spin a script which also tests memcmp?
memcmp is different story. Few years back I rewrote memcpy/memset codegen to
allow choosing
from several basic implem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49353
--- Comment #5 from Jan Hubicka 2011-07-07 22:01:07 UTC
---
Thanks for working on this!
I guess we could also get rid of the rest of visibility fixup code? (i.e.
copying COMDAT_GROUP into thunks&same body aliases
and adding them into the cgraph c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49772
--- Comment #5 from Jan Hubicka 2011-08-04 18:32:27 UTC
---
> What happens is that in expand_call_inline we fail the inlining via
> an error, but at this point of course the edge points to the inline
> clone and that stays so.
>
> I suppose when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49463
--- Comment #10 from Jan Hubicka 2011-08-05 14:50:55
UTC ---
I don't see those at my setup. Will check. Is that with the plugin?
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50005
--- Comment #2 from Jan Hubicka 2011-08-07 23:41:45 UTC
---
> Casting the VEC_length call to (int) fixes the problem, and is consistent with
> several other comparisons involving VEC_int in this file:
Oops, the patch is OK.
Honza
--- Comment #4 from hubicka at ucw dot cz 2008-01-03 21:05 ---
Subject: Re: [4.3 regression] ICE with "-fprofile-arcs -fopenmp"
> (which compiles) profile counters are added before omp expansion and once
> again
> for the child function. Is there a reason why pass
--- Comment #6 from hubicka at ucw dot cz 2008-01-04 17:28 ---
Subject: Re: [4.3 regression] ICE with "-fprofile-arcs -fopenmp"
> + if (flag_openmp)
> +{
> + tree stmt = last_stmt (e->src);
> + if (stmt)
> + {
> + /* Avoid i
--- Comment #2 from hubicka at ucw dot cz 2008-01-07 22:38 ---
Subject: Re: New: Inlining heuristics issue
I should also add that this is one of examples where Martin's switch
optimization pass would do miracles. If organized before inlining we
would end up with one static
--- Comment #3 from hubicka at ucw dot cz 2008-01-07 23:46 ---
Subject: Re: New: Inlining heuristics issue
Hi,
I am testing the attached patch. It simply accounts two instructions
for each case label, I guess it does not make much sense to try to do
something smarter until we move
--- Comment #5 from hubicka at ucw dot cz 2008-01-08 12:15 ---
Subject: Re: Inlining heuristics issue
> I think we want to account PHI nodes as real copies instead (d->count +=
> PHI_NUM_ARGS (...)) -- if they involve real operands (not VOPs).
We ignore cost of MODIF
--- Comment #7 from hubicka at ucw dot cz 2008-01-08 12:22 ---
Subject: Re: Inlining heuristics issue
With some experimentation, the PHI change makes the costs to go up in
quite weird ways not taking into account that most of PHIs are
elliminated by coalescing. So I will stay with
--- Comment #10 from hubicka at ucw dot cz 2008-01-08 14:14 ---
Subject: Re: Inlining heuristics issue
> yes, many PHIs are eliminated by coalescing. If you wanted to experiment at
> some point for more accuracy, you can look at the PHI arguments. Any argument
> which has a
--- Comment #11 from hubicka at ucw dot cz 2008-01-11 14:04 ---
Subject: Re: internal compiler error: in cgraph_estimate_size_after_inlining,
at ipa-inline.c:106
The bug re-appeared due to yet another reorganization of IPA pass queue.
The issues with function changing their types are
--- Comment #34 from hubicka at ucw dot cz 2008-01-15 15:59 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] -Winline does not respect
-fno-default-inline
> Yes, this is what I understand. I think we need a new flag specifying
> if in the source the 'inline' keyword was
--- Comment #4 from hubicka at ucw dot cz 2008-05-02 11:11 ---
Subject: Re: [4.4 Regression] always_inline attribute is broken at -O0
Hi,
I am testing the following patch that restores inlining at -O0.
Index: tree-pass.h
--- Comment #6 from hubicka at ucw dot cz 2008-05-02 21:44 ---
Subject: Re: [4.4 Regression] always_inline attribute is broken at -O0
Just for record, I am still testing the patch.
The testing scripts I used broke in a way that they ended up testing
empty patches (this is obviously
--- Comment #8 from hubicka at ucw dot cz 2008-05-02 21:59 ---
Subject: Re: [4.4 Regression] always_inline attribute is broken at -O0
> FAIL: g++.dg/opt/pr30965.C scan-tree-dump-times optimized ";; Function" 2
> FAIL: gcc.c-torture/execute/va-arg-pack-1.c compilati
--- Comment #4 from hubicka at ucw dot cz 2008-07-10 13:43 ---
Subject: Re: [4.3/4.4 Regression] .debug_line first line is behind the first
instruction
> One problem
> is that already the into_cfglayout pass does some optimizations I wouldn't
> think are appropriate
--- Comment #14 from hubicka at ucw dot cz 2006-01-23 17:43 ---
Subject: Re: ACATS FAIL c34006a cc1226b on x86-linux with -mtune=k8
It does not :( I will get to machine with Ada compiler only tonight, but
I will try to review the PARTIAL_REG_STALL code, perhaps there is
something
--- Comment #20 from hubicka at ucw dot cz 2006-01-25 13:43 ---
Subject: Re: [4.2 Regression] ACATS c34006a cc1226b failure on x86
Very good catch! Here is C testcase. I need to setup testing, then I
will try to debug the problem in combiner.
Honza
struct a
{
int a
--- Additional Comments From hubicka at ucw dot cz 2005-05-18 22:22 ---
Subject: Re: [Bug gcov/profile/20815] -fprofile-use barfs with "coverage
mismatch for function '...' while reading counter 'arcs'."
coverage_checksum_string already knows a bit about
--- Additional Comments From hubicka at ucw dot cz 2005-05-18 22:47 ---
Subject: Re: [Bug gcov/profile/20815] -fprofile-use barfs with "coverage
mismatch for function '...' while reading counter 'arcs'."
>
> --- Additional Comments From hub
--- Additional Comments From hubicka at ucw dot cz 2005-05-20 17:22 ---
Subject: Re: [4.1 regression] ICE using -ftree-vectorize
>
> --- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-20
> 16:56 ---
> The problem disappeared with Jan Hubicka&#x
--- Additional Comments From hubicka at ucw dot cz 2005-05-23 09:44 ---
Subject: Re: [4.1 Regression] gcc.dg/pch/inline-4.c fails
Hi,
I finally reproduced it on IA-64 machine. I am testing the attached
fix. Can you please try if it fixes your problem too?
2005-05-23 Jan Hubicka
--- Additional Comments From hubicka at ucw dot cz 2005-06-16 08:36 ---
Subject: Re: [4.1 regression] ICE with -ftree-vectorize
>
> --- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-16
> 08:32 ---
> Honza, this was introduced with your
--- Additional Comments From hubicka at ucw dot cz 2005-06-17 13:53 ---
Subject: Re: [4.1 regression] ICE with -ftree-vectorize
>
> --- Additional Comments From dorit at il dot ibm dot com 2005-06-17
> 12:58 ---
> > bug.c: In function 'foo':
>
901 - 1000 of 1244 matches
Mail list logo
