--- Comment #14 from hubicka at ucw dot cz 2006-06-07 12:18 ---
Subject: Re: [4.2 regression] segfault in ipa-inline.c, if
(e->callee->local.disregard_inline_limits
>
>
> --- Comment #12 from pinskia at gcc dot gnu dot org 2006-06-07 06:00
> ---
> Wait
--- Comment #9 from hubicka at ucw dot cz 2008-12-05 12:59 ---
Subject: Re: [4.4 Regression] missed inlining on Core2 Duo due to apparent
wrong branch prediction/profile
> Honza, can you have a look here? I suspect the fortran decl issue prevent
Will do. We however don't di
--- Comment #11 from hubicka at ucw dot cz 2008-12-05 17:15 ---
Subject: Re: [4.4 Regression] missed inlining on Core2 Duo due to apparent
wrong branch prediction/profile
OK,
so the problem is that all the paths are leading to noreturn, so the
conditional deciding on what noreturn
--- Comment #7 from hubicka at ucw dot cz 2009-01-15 01:49 ---
Subject: Re: [4.4 regression] performance regression of sse code from 4.2/4.3
I guess th3 main difference here is that load + addps pair generate 2
uops, while mov + loading addps generate 3 since the move has to go
--- Comment #5 from hubicka at ucw dot cz 2009-05-08 19:44 ---
Subject: Re: [4.5 Regression] verify_eh_tree failed with -O2
This is very sick side case of updating prev_try pointer in
duplicate_eh_edges. I think it is clear that maintaining prev_try
pointer just to slightly speed up
--- Comment #3 from hubicka at ucw dot cz 2009-05-09 14:44 ---
Subject: Re: [4.5 Regression] Power bootstrap is broken in building libstdc++
Hi,
I am testing the attached patch. It makes testcase to compile, does it
solve bootstrap issues too?
Index: ipa.c
--- Comment #2 from hubicka at ucw dot cz 2009-05-09 18:29 ---
Subject: Re: [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274
The problem here is that combine constructs (set (pc) (pc)) as noo-op
move expecting it to be removed immediately. It is however
misinterpreted as
--- Comment #3 from hubicka at ucw dot cz 2009-05-09 18:52 ---
Subject: Re: [4.5 Regression] error: missing callgraph edge for call stmt
Hi,
I am testing the following:
Index: cgraphunit.c
===
--- cgraphunit.c
--- Comment #4 from hubicka at ucw dot cz 2009-05-09 21:06 ---
Subject: Re: [4.5 Regression] Revision 147294 failed 483.xalancbmk in SPEC
CPU 2006 at -O3
Hi,
I am testing the following patch thasolves the ICE.
Problem here was that we cleated ipa-cp clone and clonning proces
allowed
--- Comment #7 from hubicka at ucw dot cz 2009-06-30 12:46 ---
Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852
> The problem is that early inliner allows to increase code size estimate by
> inlining single function by up to 12 instructions. This is
--- Comment #3 from hubicka at ucw dot cz 2009-06-30 14:07 ---
Subject: Re: [4.4/4.5 Regression] DWARF for inlined subroutines refers to the
outlined copy
Hmm, I tought GCC was doing the same thing for years. So we need
abstract function for each inline?
Honza
--
http
--- Comment #11 from hubicka at ucw dot cz 2009-06-30 23:36 ---
Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852
> I see no effect whatsoever of the patch for for CSiBE on arm-elf-unknown.
At -Os?
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #4 from hubicka at ucw dot cz 2009-07-01 10:47 ---
Subject: Re: [4.3/4.4/4.5 Regression] tracer duplicates blocks w/o adjusting
EH tree
Hi,
the following patch should prevent tracer from copying resx. It is
remarkably ugly I need to unconstify all the copy_bb_p predicates
--- Comment #4 from hubicka at ucw dot cz 2009-07-02 10:05 ---
Subject: Re: [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274
> Would you mind seeing if your patch was the same?
I wanted to prevent the (set pc pc) trick, but this seems like easier fix
for the prob
--- Comment #13 from hubicka at ucw dot cz 2009-07-02 10:10 ---
Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852
OK, on i386 it has some effect according to our nightly tester
it is 3524421->3510754. The size used to be as low as 3431090
so it is just sm
--- Comment #7 from hubicka at ucw dot cz 2009-07-10 22:36 ---
Subject: Re: [4.5 Regression] another null pointer in
remove_unreachable_regions
> 569 EXECUTE_IF_SET_IN_BITMAP (i->aka, 0, n, bi)
> (gdb) p i->aka
> $1 = (bitmap) 0x0
oops, forgot a
--- Comment #5 from hubicka at ucw dot cz 2009-07-11 22:45 ---
Subject: Re: [4.5 Regression] internal compiler error: verify_ssa error:
definition in block 5 does not dominate use in block 7
Thinking about this more, we change here dominance relation in
not-so-obvious way. It is not
--- Comment #7 from hubicka at ucw dot cz 2009-07-12 16:18 ---
Subject: Re: [4.5 Regression] internal compiler error: verify_ssa error:
definition in block 5 does not dominate use in block 7
Hi,
there is interesting difficulty with this plan.
When we have something like
BB1: if
--- Comment #12 from hubicka at ucw dot cz 2009-07-12 22:44 ---
Subject: Re: [4.5 Regression] another null pointer in
remove_unreachable_regions
> The testsuite failure was due to a double paste into the testcase; fixing that
> maxes it work.
Uh, double application of patch..
--- Comment #3 from hubicka at ucw dot cz 2009-07-15 11:29 ---
Subject: Re: [4.5 Regression] segfault in useless_type_conversion_p
I hope that patch for PR40676 should cure those problems. I am just on
the way to Prague, but I will try to look into it tomorrow.
Honza
--
http
--- Comment #4 from hubicka at ucw dot cz 2009-07-23 16:15 ---
Subject: Re: [4.5 Regression] segfault in useless_type_conversion_p
Hi,
the problem here is in removing virtual PHI. We replace uses of the
virtual PHI results by the corresponding VAR_DECL and send symbol for
renaming
--- Comment #11 from hubicka at ucw dot cz 2009-07-29 08:08 ---
Subject: Re: Function object abstraction penalty with inline functions.
> I'll take this for now.
My preferred way of fixing this would be to include FRE pass.
Unfortunately my last benchmarks adding FRE earl
--- Comment #9 from hubicka at ucw dot cz 2005-11-21 14:44 ---
Subject: Re: [4.1 regression] EON regressed seriously on x86-64
>
>
> --- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-21 13:30
> ---
> Fixed at least on the mainline for 4.2.0.
I am
--- Comment #13 from hubicka at ucw dot cz 2006-07-21 15:13 ---
Subject: Re: [4.1/4.2 Regression] tree check ICE when attribute
externally_visible used
>
>
> --- Comment #12 from mmitchel at gcc dot gnu dot org 2006-07-21 08:38
> ---
> I think that Comment
--- Comment #10 from hubicka at ucw dot cz 2006-07-22 13:47 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
Hi,
this patch makes the -O2 case work pretty well on tree side. Inliner
expands code from 8MB to 40MB of GGC memory that seems
--- Comment #11 from hubicka at ucw dot cz 2006-07-22 17:12 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
Hi,
this avoids inliner to produce quadratically many STMT list nodes, so
inlining is now resonably fast. Next offenders are
--- Comment #12 from hubicka at ucw dot cz 2006-07-22 18:09 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
Hi,
I am attaching the .optimized dump of this testcase. It is quite good
demonstration on how SRA and TER tends to increase
--- Comment #14 from hubicka at ucw dot cz 2006-07-22 19:30 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
Hi,
with the attached patch I can cure the regmove quadratic behaviour and
the time report is not so unresonable now
--- Comment #16 from hubicka at ucw dot cz 2006-07-22 20:51 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
Hi,
with the attached patch that saves roughly 10 minutes of tree-into-ssa
pass, I can compile with -O3 -fno-tree-fre -fno-tree
--- Comment #5 from hubicka at ucw dot cz 2006-07-27 16:06 ---
Subject: Re: [Bug gcov/profile/28480] [4.2 Regression] inliner-1.c:31: ICE: in
set_bb_for_stmt, at tree-cfg.c:2775
Hi,
it is hitting sanity check in set_bb_for_stmt that is bit insane in this
context. I am testing patch to
--- Comment #32 from hubicka at ucw dot cz 2006-07-28 09:41 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
Hi,
I've added this testcase to our's memory regression tester (see
gcc-regression mainling list), so hopefully the
--- Comment #47 from hubicka at ucw dot cz 2006-08-08 06:28 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse x87 code on all
platforms than gcc 3
> In x86/x86-64 world one can be almost sure that the load+execute instruction
> pair will execute (marginaly to noti
--- Comment #37 from hubicka at ucw dot cz 2006-08-18 23:10 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
Hi,
to summary current process, the memory consumption seems to be in
control now:
comparing PR rtl-optimization/28071 testcase
--- Comment #38 from hubicka at ucw dot cz 2006-08-19 00:19 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
At -O0 we get time sinks:
life analysis : 0.75 (10%) usr 0.01 ( 3%) sys 0.78 ( 9%) wall
2714 kB ( 4%) ggc
--- Comment #39 from hubicka at ucw dot cz 2006-08-19 01:51 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
The -O1 time sinks:
life analysis : 25.44 (19%) usr 0.00 ( 0%) sys 25.49 (17%) wall
2565 kB ( 2%) ggc
inline
--- Comment #41 from hubicka at ucw dot cz 2006-08-20 00:58 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
Thank you for consideration,
Live on entry/exit code shows up high on -O3 compilation time too
(something like 30% of time without
--- Comment #11 from hubicka at ucw dot cz 2006-08-20 12:42 ---
Subject: Re: externally_visible attribute not effective with prior declaration
of symbol.
> Is there any reason why process_function_and_variable_attributes is called
> at the end of each TU rather than when all TU
--- Comment #18 from hubicka at ucw dot cz 2006-08-20 12:47 ---
Subject: Re: [4.1/4.2 Regression] internal compiler error in dwarf2out_finish
> (In reply to comment #14)
> Any news on the patch?
Sadly we are having just tip of the iceberg here. The patch to deffer
output of
--- Comment #13 from hubicka at ucw dot cz 2006-08-20 12:59 ---
Subject: Re: externally_visible attribute not effective with prior declaration
of symbol.
>
> If this is really true, then there are several bugs (in the FEs?) because
> there
> are numerous occu
--- Comment #14 from hubicka at ucw dot cz 2006-08-20 13:12 ---
Subject: Re: externally_visible attribute not effective with prior declaration
of symbol.
Hi,
this is patch I am testing now. Can you think of way to break it
(again? :))
The whole thing is a lot more sliperly than I
--- Comment #44 from hubicka at ucw dot cz 2006-08-21 02:59 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
Hi,
update at -O1 few patches later (different machine with "only" 500MB
ram, so some swappin occurs, but we almo
--- Comment #45 from hubicka at ucw dot cz 2006-08-21 12:56 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
Hi,
-O2 times:
Execution times (seconds)
life analysis : 18.08 ( 3%) usr 0.04 ( 1%) sys 19.42 ( 3%) wall
1120 kB
--- Comment #46 from hubicka at ucw dot cz 2006-08-21 17:11 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
Hi,
for completeness the -O3 -fno-tree-pre -fno-tree-fre results
(tree-pre/fre needs something little over 2GB of ram to converge
--- Comment #4 from hubicka at ucw dot cz 2006-10-15 22:20 ---
Subject: Re: [4.0/4.1/4.2 Regression] missed-optimization (in unneeded code
elimination)
> (insn:TI 38 37 26 2 (parallel [
> (set (reg:SI 1 dx [+4 ])
> (ashiftrt:SI (reg:SI
--- Comment #9 from hubicka at ucw dot cz 2006-10-15 22:33 ---
Subject: Re: [4.2 Regresion] gcc "used" attribute has no effect on local-scope
static variables
> Reopening because it is not fixed for non unit at a time mode (-O0 for C).
-O0 gets it right, just -O1 -fno-u
--- Comment #6 from hubicka at ucw dot cz 2006-10-19 19:36 ---
Subject: Re: compile time hog / deadloop.
>
>
> --- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-19 15:15
> ---
> It _looks_ like we're needlessly recursing into the BINFOs in
--- Comment #9 from hubicka at ucw dot cz 2006-10-19 23:32 ---
Subject: Re: compile time hog / deadloop.
Just for a record, we discussed this a bit on IRC. I origionally wrote
that loop copying logic from alias.c just to be sure that all the fields
from base clases are merged into
--- Comment #6 from hubicka at ucw dot cz 2007-02-03 21:55 ---
Subject: Re: [4.3 Regression] ICE with -fprofile-use
> size = ((histogram->hvalue.counters[0]
> + histogram->hvalue.counters[0] / 2)
> - / histogram->
--- Comment #2 from hubicka at ucw dot cz 2007-03-15 22:01 ---
Subject: Re: New: [4.3 Regression] 1000% Runtime regression for FreeFEM
navier-stokes example
> The regression was introduced between r120825 (10s runtime) and r120846 (110s
> runtime). The obvious candid
--- Comment #7 from hubicka at ucw dot cz 2007-04-06 16:07 ---
Subject: Re: "-O -fregmove" handles SSE scalar instructions incorrectly
> Investigating...
The attached patch to remove '%' seems correct to me. Merge operating
wrapping the (commutative) p
--- Comment #9 from hubicka at ucw dot cz 2007-04-06 17:01 ---
Subject: Re: "-O -fregmove" handles SSE scalar instructions incorrectly
>
>
> --- Comment #8 from stevenb dot gcc at gmail dot com 2007-04-06 16:43
> ---
> Subject: Re: "-O
--- Comment #66 from hubicka at ucw dot cz 2007-04-17 19:38 ---
Subject: Re: [4.1 regression] A file that can not be compiled in reasonable
time/space
Just to add some explanation to the numbers, df_scan_ref_pool is 50MB,
the bitmaps quoted are 8MB each. Given nature of the testcase
--- Comment #5 from hubicka at ucw dot cz 2008-09-02 10:14 ---
Subject: Re: [4.4 Regression]: gcc.c-torture/execute/931018-1.c int-compare.c
ieee/inf-2.c mzero6.c
> Honza, why is tree-inline.c:initialize_cfun not calling
> allocate_struct_function and *then* change whatever el
--- Comment #7 from hubicka at ucw dot cz 2008-09-02 20:29 ---
Subject: Re: [4.4 Regression]: gcc.c-torture/execute/931018-1.c int-compare.c
ieee/inf-2.c mzero6.c
>
>
> --- Comment #6 from hp at gcc dot gnu dot org 2008-09-02 10:41 ---
> (In reply t
--- Comment #4 from hubicka at ucw dot cz 2008-09-03 14:30 ---
Subject: Re: [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7290
Hi,
this is switch conversion bug. It attempts to convert the switch and
construct static array with &function_parameter in initializer
--- Comment #5 from hubicka at ucw dot cz 2008-09-03 18:33 ---
Subject: Re: [4.4 Regression] Segfault in decl_function_context
(TYPE_MAIN_VARIANT)
Testing:
* tree.c (build_function_type_skip_args): Build distinct type copy;
set TYPE_CONTEXT
--- Comment #12 from hubicka at ucw dot cz 2008-09-14 09:18 ---
Subject: Re: 7 Internal Compiler Errors when compiling OpenFOAM-1.5
> Honza,
>
> I may not be analyzing this correctly, but it looks like
> cgraph_remove_unreachable_nodes() may be removing something that
--- Comment #13 from hubicka at ucw dot cz 2008-09-14 09:24 ---
Subject: Re: 7 Internal Compiler Errors when compiling OpenFOAM-1.5
Looking at the log, it seems to be another leak where multiple
declarations points to single struct function. This is of course quite
evil bug with
--- Comment #12 from hubicka at ucw dot cz 2008-01-21 09:54 ---
Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel
and haydn tester using -O3 -funroll-loops -fpeel-loops -ffast-math
-march=native -mtune=native -mfpmath=sse has also started failing at
17th, so
--- Comment #11 from hubicka at ucw dot cz 2008-01-21 09:48 ---
Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel
Hi,
also one extra data point, britten tester that uses -O3
-fomit-frame-pointer -ftree-loop-linear -funroll-all-loops
-fprefetch-loop-arrays -march=k8
--- Comment #10 from hubicka at ucw dot cz 2008-01-21 09:44 ---
Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel
>
>
> --- Comment #8 from hjl dot tools at gmail dot com 2008-01-21 03:09
> ---
> Add -ffloat-store seems to fix the problem
--- Comment #9 from hubicka at ucw dot cz 2008-01-21 09:43 ---
Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel
>
>
> --- Comment #7 from hjl dot tools at gmail dot com 2008-01-20 16:43
> ---
> Oops. This one
Yes, it does make sense. I
--- Comment #15 from hubicka at ucw dot cz 2008-01-21 16:42 ---
Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel
> I tried -mpc64. It also works.
I would declare this a proof that it is extra preccision issue and
simply update testers to use -mpc64. It is w
--- Comment #18 from hubicka at ucw dot cz 2008-01-22 20:12 ---
Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel
> So, we indeed think this issue is invalid, right?
I am convinced so. -mpc64 does not change code generation. I messed up
the change of britten fl
--- Comment #5 from hubicka at ucw dot cz 2008-01-26 20:19 ---
Subject: Re: [4.3 regression] calling a function with undefined parameters
causes segmentation fault at -O1 or higher
> and if it is just not available (i == NULL) might give inconsistent
> answers.
I will look int
--- Comment #6 from hubicka at ucw dot cz 2008-01-27 13:54 ---
Subject: Re: [4.3 regression] calling a function with undefined parameters
causes segmentation fault at -O1 or higher
cgraph_local_info still behaves as expected returning NULL when info is
not computed yet. Unfortunately
--- Comment #8 from hubicka at ucw dot cz 2008-01-27 18:10 ---
Subject: Re: [4.3 regression] calling a function with undefined parameters
causes segmentation fault at -O1 or higher
> One more reason to gimplify unit-at-a-time...
Yep, on the other hand there is probably not much n
--- Comment #9 from hubicka at ucw dot cz 2008-01-27 19:24 ---
Subject: Re: [4.3 regression] calling a function with undefined parameters
causes segmentation fault at -O1 or higher
However the failure here is not early calling of cgraph_local_info (it
is ugly, but harmless, we are
--- Comment #6 from hubicka at ucw dot cz 2008-01-28 20:51 ---
Subject: Re: [4.3 regression] ICE with -fipa-cp -ffast-math
> No, I mean providing something like cgraph_update_edges_for_call_stmt (tree
> old, tree new); or alternatively cgraph_remove_edge_from_call_stmt
--- Comment #11 from hubicka at ucw dot cz 2008-01-29 17:51 ---
Subject: Re: [4.3 regression] calling a function with undefined parameters
causes segmentation fault at -O1 or higher
Hi,
the patch seems to pass my local testing, but on Zdenek's tester I get
curious results on
--- Comment #17 from hubicka at ucw dot cz 2008-01-30 15:56 ---
Subject: Re: [4.3 regression] calling a function with undefined parameters
causes segmentation fault at -O1 or higher
> These tests time out from time to time when the testing box is busy, that's
> quite
>
--- Comment #38 from hubicka at ucw dot cz 2008-01-30 23:19 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] performance loss (not inlining as
much??)
> AFAICT, they are exactly in the form that some targets like it (e.g.
> auto-inc/dec and SMALL_REGISTER_CLASS targets).
Yep, b
--- Comment #23 from hubicka at ucw dot cz 2008-01-30 23:20 ---
Subject: Re: [4.3 regression] calling a function with undefined parameters
causes segmentation fault at -O1 or higher
> (In reply to comment #21)
> > but why does this happen only with -O1?
>
> Rand
--- Comment #43 from hubicka at ucw dot cz 2008-02-01 22:45 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] performance loss (not inlining as
much??)
> TER will not replace any load into an expression if there is more than one use
> of the load. Your sample shows multiple uses o
--- Comment #8 from hubicka at ucw dot cz 2008-02-15 11:29 ---
Subject: Re: [4.2/4.3 Regression] ICE in coalesce_abnormal_edges
The split happens in loop_optimized_init during profile construction pass, not
in inliner.
#0 make_ssa_name (var=0xb7da1228, stmt=0xb7daf000) at
../../gcc
--- Comment #3 from hubicka at ucw dot cz 2008-02-20 21:05 ---
Subject: Re: [4.4 Regression]: FAIL: abi_check
> (In reply to comment #1)
> > Jan, is this related to your patch?
>
> And if it is, then there is another bug somewhere else anyways as it could
> only
--- Comment #5 from hubicka at ucw dot cz 2008-02-20 23:39 ---
Subject: Re: [4.4 Regression]: FAIL: abi_check
OK,
if it really is just inlining decision difference then we are fine.
I guess we can either update symbol list or mark always_inline
> because of a changing inlin
--- Comment #10 from hubicka at ucw dot cz 2008-03-03 00:50 ---
Subject: Re: [4.4 Regression]: FAIL: abi_check
> Confirmed, of course. Honza, any news on the inlining issue?
Sorry,
I looked into it, got confused and then distracted by other problem and
forgot to return back.
--- Comment #14 from hubicka at ucw dot cz 2008-03-03 23:46 ---
Subject: Re: [4.4 Regression]: FAIL: abi_check
> Honza, I'm sorry, can you please double-check the fix? On my x86_64-linux
> machines I'm not seeing any progress :(
Hi,
this is what I get from our thest
--- Comment #16 from hubicka at ucw dot cz 2008-03-04 07:03 ---
Subject: Re: [4.4 Regression]: FAIL: abi_check
> Note however, that the patch also didn't help Geoff's i686-linux tester, just
> have a look to gcc-testresults.
Sorry, I had two versions of patch and m
--- Comment #6 from hubicka at ucw dot cz 2008-03-19 23:06 ---
Subject: Re: [4.4 Regression] gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times
profile fails
This seems to affect about every target, but it is essentially harmless.
I am discussing with Zdenek the proper fix.
Honza
--- Comment #2 from hubicka at ucw dot cz 2008-03-20 10:32 ---
Subject: Re: FAIL: gcc.dg/cpp/cmdlne-d(I|M)-M.c scan-file
(^|\\n)cmdlne-d(I|M)-M[^\\n]*:[^\\n]*cmdlne-d(I|M)-M.c
> It fails everywhere, due to commit 133342. Author is informed and CC:ed.
Sorry for all the break
--- Comment #2 from hubicka at ucw dot cz 2008-04-01 00:15 ---
Subject: Re: [4.4 Regression]: Revision 133759 breaks ia64
>
>
> --- Comment #1 from wilson at tuliptree dot org 2008-03-31 22:42 ---
> Subject: Re: New: [4.4 Regression]: Revision 133759
&g
--- Comment #3 from hubicka at ucw dot cz 2008-04-02 09:35 ---
Subject: Re: New: [4.4 Regression] Revision 133787 breaks ia64
Hi,
I've added the assert to check that we don't initialize RTL world twice
without freeing it first (and thus that we don't leak memory). T
--- Comment #7 from hubicka at ucw dot cz 2008-04-03 06:12 ---
Subject: Re: [4.4 Regression] Revision 133787 breaks ia64
> The patch is OK.
>
> But won't all targets that have similar code need the same fix? If I cd
> to the config dir, and try "grep fina
--- Comment #10 from hubicka at ucw dot cz 2008-04-03 15:44 ---
Subject: Re: [4.4 Regression] Revision 133787 breaks ia64
> I am pretty sure I saw this one targeting sparc-rtems. Building an updated
> tree now to confirm it is the fix.
>
> ../../../../gcc/libstdc++-v3/
--- Comment #10 from hubicka at ucw dot cz 2009-02-12 10:28 ---
Subject: Re: [4.4 Regression] inlining causes explosion in debug info
> sizeof (tree_block) is 52 bytes on 32-bit hosts. Of these, 8 are unused (ann
> and type), 8 are frequently unused (block_fragment stuff --
--- Comment #2 from hubicka at ucw dot cz 2009-02-17 17:43 ---
Subject: Re: LTO and -fwhole-program do not play along well
Hi,
functions are brought local in function_and_variable_visibility that
needs to be scheduled after LTO is read in.
The pas computes externaly_visible flags that
--- Comment #4 from hubicka at ucw dot cz 2009-02-17 18:01 ---
Subject: Re: LTO and -fwhole-program do not play along well
> > Hi,
> > functions are brought local in function_and_variable_visibility that
> > needs to be scheduled after LTO is read in.
&g
--- Comment #8 from hubicka at ucw dot cz 2009-02-17 18:34 ---
Subject: Re: LTO and -fwhole-program do not play along well
> > -fwhole-program essentially hides everything except for main and
> > functions/variables explicitly marked via attribute, so this is
> > e
--- Comment #12 from hubicka at ucw dot cz 2009-02-18 01:42 ---
Subject: Re: LTO and -fwhole-program do not play along well
> I believe we should be set already. During LTO read, we execute
> ipa_passes, which runs all_small_ipa_passe
--- Comment #7 from hubicka at ucw dot cz 2009-02-19 14:59 ---
Subject: Re: [4.4 Regression] Inconsistent reject / accept of code
> Index: cp/pt.c
> ===
> --- cp/pt.c (revision 144292)
> +++ cp/pt.c (
--- Comment #9 from hubicka at ucw dot cz 2009-02-19 15:40 ---
Subject: Re: [4.4 Regression] Inconsistent reject / accept of code
> /* Check to see whether we know that this template will be
> instantiated in some other file, as with "extern template"
--- Comment #13 from hubicka at ucw dot cz 2009-02-20 14:39 ---
Subject: Re: [4.4 Regression] Inconsistent reject / accept of code
> > What that means is that we *must not* implicitly instantiate things
> > declared "extern template" unless they are DECL_DE
--- Comment #51 from hubicka at ucw dot cz 2009-02-22 14:47 ---
Subject: Re: [4.2/4.3/4.4 Regression] out of memory while parsing array with
many initializers
> Honza, you realize that the numbers are completely unreadable in bugzilla,
> right?
THey need some care to read, the c
--- Comment #54 from hubicka at ucw dot cz 2009-02-23 16:51 ---
Subject: Re: [4.2/4.3/4.4 Regression] out of memory while parsing array with
many initializers
> > Perhaps explicitly freeing would be good idea?
>
> I certainly have no objection to explicitly freeing s
--- Comment #9 from hubicka at ucw dot cz 2009-03-05 11:18 ---
Subject: Re: [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1
> --- Comment #8 from jakub at gcc dot gnu dot org 2009-03-05 08:07 ---
> Can you reproduce it with stage1 cc1plus (
--- Comment #9 from hubicka at ucw dot cz 2009-03-06 17:30 ---
Subject: Re: [4.4 Regression] ICE in referenced_var_lookup, at tree-dfa.c:563
> part. So, either tree-inline.c needs to do the same, or it can't use
> referenced_vars bit as a test whether it has been queued a
--- Comment #3 from hubicka at ucw dot cz 2009-04-06 09:28 ---
Subject: Re: [4.5 Regression] ICE building libstdc++v3 functexcept.cc
Hi,
this does not reproduce on my setup, but the following patch should fix it.
Honza
Index: except.c
--- Comment #1 from hubicka at ucw dot cz 2009-04-07 11:44 ---
Subject: Re: New: Local statics not promoted to const
ipa-reference definitly is supposed to do this transform. I will debug
why it does not in this testcase.
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
1 - 100 of 1243 matches
Mail list logo
