--- Comment #12 from matz at gcc dot gnu dot org 2009-10-14 06:14 ---
Yeah, I'm sorry, I attached the testcase to the wrong bug report as said in
comment #5. It was about combinatoric explosion not about slow var-tracking.
I should probably have deleted the attachment from
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
--- Comment #5 from matz at gcc dot gnu dot org 2009-10-21 15:20 ---
Yes, I mean the second insertion. The phi node generated for that one (in the
first j-loop) prevents vectorization in r151561 (I haven't really tested
newer revs that r151590). Maybe some other stuff in later
--- Comment #6 from matz at gcc dot gnu dot org 2009-10-21 15:22 ---
Hmm, at least I don't remember any patch dealing with phi translation right
now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
--- Comment #8 from matz at gcc dot gnu dot org 2009-10-21 15:35 ---
But the important one (for zeusmp) is the first loop. That isn't vectorized
anymore (but was in r151560, i.e. there it vectorized two loops).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
--- Comment #11 from matz at gcc dot gnu dot org 2009-10-22 15:13 ---
Have patch.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #2 from matz at gcc dot gnu dot org 2009-10-22 15:26 ---
Works with 4.3 and 4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41797
--- Comment #12 from matz at gcc dot gnu dot org 2009-10-26 13:00 ---
Subject: Bug 41783
Author: matz
Date: Mon Oct 26 13:00:36 2009
New Revision: 153551
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153551
Log:
PR tree-optimization/41783
* tree-ssa
--- Comment #13 from matz at gcc dot gnu dot org 2009-10-26 13:04 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from matz at gcc dot gnu dot org 2009-11-18 15:04 ---
I'm not terribly thrilled by having to clutter the code with 20 lines of code
which should have been maybe two :-/ Even less so as nothing can make use
of the info. Let's drop it for now with a comment.
--- Comment #9 from matz at gcc dot gnu dot org 2007-05-21 07:45 ---
Richard, the problem isn't the compare or where to store the live values
alen and blen (FYI, the store looks invalid, because reload will not
immediately stop when it sees an invalid asm insn, but instead just pat
--- Comment #12 from matz at gcc dot gnu dot org 2007-05-21 09:03 ---
Exactly. If during expansion or at some other time before reload, doesn't
matter that much. Of course there's a remote possibility that some RTL
passes between expand and reload would do the copy prop
--- Comment #14 from matz at gcc dot gnu dot org 2007-05-21 09:35 ---
Yes. The place where I would think the work-around to become definitive is
exactly before regclass. Between it and reload nothing interesting happens
transformation wise.
--
http://gcc.gnu.org/bugzilla
--- Comment #1 from matz at gcc dot gnu dot org 2007-05-23 09:36 ---
The ObjC frontend seems to use IDENTIFIER_POINTER directly to produce
this encoding. This doesn't contain template arguments anymore. And from
quick reading of obj-act.c it's also not clear if it was really
--- Comment #37 from matz at gcc dot gnu dot org 2007-06-05 18:24 ---
> We are pointing to cell, and using that to access cell.i
No. We are pointing to cell.ii, and use that pointer to access cell.ii.i
(via in->i). Hence of course the points-to set of 'in' needs to i
--- Comment #9 from matz at gcc dot gnu dot org 2007-07-06 15:42 ---
This helps (the loop already tries to copy the content byte wise, but uses
the wrong modes for that), but someone knowledgeable in that bitfield business
should look at it. In particular it might happen that
--- Comment #4 from matz at gcc dot gnu dot org 2007-07-11 15:37 ---
Nope.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from matz at gcc dot gnu dot org 2010-02-18 15:13 ---
Created an attachment (id=19910)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19910&action=view)
candidate fix
Try this. I don't know how to write guality tests, but I think it has the
effects
--- Comment #3 from matz at gcc dot gnu dot org 2010-02-18 16:12 ---
At least varb isn't printed in fn3, because dse2 (after prologue_epilogue)
makes the expressions in the debug_insn be (clobber 0). Presumably because
frame elimination rewrites the address-takings, but not the
--- Comment #4 from matz at gcc dot gnu dot org 2010-02-18 16:40 ---
Created an attachment (id=19916)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19916&action=view)
do reg elimination
This will fix some more of the var[bc] references by eliminating
all registers in DEBUG
--- Comment #5 from matz at gcc dot gnu dot org 2010-02-18 16:50 ---
That leaves 'c' which isn't printed, because the setup of c (a stackslot)
is schedules to be part of the function call setup, the breakpoint is before
that setup, and hence the location of 'c'
--- Comment #10 from matz at gcc dot gnu dot org 2010-02-19 12:33 ---
Okay. You were right, my tree was a outdated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077
--- Comment #23 from matz at gcc dot gnu dot org 2010-02-19 13:19 ---
Richi: not really. It tries to separate paths where at least one has mostly
constants in their PHI args. This applies to this testcase for the first
chain of PHI nodes, which are separated as intended. But this
--- Comment #12 from matz at gcc dot gnu dot org 2010-02-23 14:31 ---
Yeah, I have a patch already which emits it before the last real use of an
SSA name (which by design of TER is a point where all constituent
subexpressions still have their correct value).
--
http://gcc.gnu.org
--- Comment #13 from matz at gcc dot gnu dot org 2010-02-23 16:42 ---
Subject: Bug 43077
Author: matz
Date: Tue Feb 23 16:41:52 2010
New Revision: 157009
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157009
Log:
PR debug/43077
* cfgexpand (expand_de
--- Comment #14 from matz at gcc dot gnu dot org 2010-02-23 16:46 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-09 16:47 ---
This happens only for vector modes which aren't supported by the target.
They will be assigned BLKmode stack slots which right now aren't handled
correctly (incidentally I wonder why Graphite is needed to e
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-15 16:13 ---
Subject: Bug 43300
Author: matz
Date: Mon Mar 15 16:13:28 2010
New Revision: 157461
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157461
Log:
PR middle-end/43300
* tree-out
--- Comment #6 from matz at gcc dot gnu dot org 2010-03-15 16:15 ---
Fixed. I put in a testcase that doesn't need graphite.
--
matz at gcc dot gnu dot org changed:
What|Removed |
-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
--- Comment #1 from matz at gcc dot gnu dot org 2010-03-17 14:02 ---
Created an attachment (id=20127)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20127&action=view)
testcase
Testcase reduced from ucnv_bld.c of libicu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-17 15:31 ---
It seems the jump threading somehow confuses cfgcleanup. Right after the
jumps are threaded (in tree_ssa_dominator_optimize after the call to
thread_through_all_blocks) the function looks like so:
:
goto
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-17 15:36 ---
Um, we cleanup the CFG before updating SSA form, hence no wonder that
the missing PHI nodes confuse it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-17 15:49 ---
Hmm, create_edge_and_update_destination_phis is supposed to add new PHI
arguments for the ultimate threading destination. But it only does so if
there are already PHI nodes in that BB. We need to create new ones
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-17 16:05 ---
Hmm, I wonder how that could cause the bug. Probably because we can't rely
on SSA form being uptodate during cfgcleanup, and hence looking up PHI
arguments is wrong, at least for those SSA names that are regis
--- Comment #9 from matz at gcc dot gnu dot org 2010-03-17 17:03 ---
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00774.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
--- Comment #10 from matz at gcc dot gnu dot org 2010-03-18 12:21 ---
Subject: Bug 43402
Author: matz
Date: Thu Mar 18 12:20:50 2010
New Revision: 157538
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157538
Log:
PR tree-optimization/43402
* tree-cfgc
--- Comment #11 from matz at gcc dot gnu dot org 2010-03-18 12:46 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from matz at gcc dot gnu dot org 2010-03-18 14:35 ---
Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-18 14:48 ---
I checked, and these and similar transformations are always guarded by
flag_unsafe_math_optimizations, so we should be fine, unless I missed a case
of course. If you notice one, please create a bug report
--- Comment #6 from matz at gcc dot gnu dot org 2010-03-18 16:08 ---
Subject: Bug 43419
Author: matz
Date: Thu Mar 18 16:07:53 2010
New Revision: 157543
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157543
Log:
PR middle-end/43419
* bu
--- Comment #6 from matz at gcc dot gnu dot org 2010-03-18 16:47 ---
Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-18 16:47 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-18 16:53 ---
That would indeed be my preferred approach. The alternative would be to
add much "if (x == error_mark_node)" sillyness all over the middle-end, like
the front-ends do. The middle-end should be able to
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-19 12:37 ---
Subject: Bug 43305
Author: matz
Date: Fri Mar 19 12:37:28 2010
New Revision: 157567
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157567
Log:
PR 43305
* bu
--- Comment #8 from matz at gcc dot gnu dot org 2010-03-19 12:38 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-19 15:33 ---
I have a patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00893.html
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-19 16:18 ---
I have a patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00899.html
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from matz at gcc dot gnu dot org 2010-03-19 16:23 ---
I'm not sure what you're asking. When the unpatched compiler the testcase
(with the printf or the x!=6->abort) will ICE with a checking compiler,
and produce wrong output ("0" or an abort) with
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-19 16:37 ---
Subject: Bug 43116
Author: matz
Date: Fri Mar 19 16:37:27 2010
New Revision: 157578
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157578
Log:
PR c++/43116
* attribs.c (decl_attribute
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-19 16:40 ---
Fixed for 4.5. Unassigning myself.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from matz at gcc dot gnu dot org 2010-03-19 16:55 ---
Actually I have a patch for this, need to polish it somewhat.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-19 16:59 ---
How about not calling cselib_process_insn on DEBUG_INSNs (or better make
cselib_process_insn ignore them).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42977
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-20 17:00 ---
But Simons patch was accepted. Simon: can you simply combine the two
testcases into one? No need to artificially lengthen the time for make check.
--
matz at gcc dot gnu dot org changed:
What
--- Comment #2 from matz at gcc dot gnu dot org 2010-03-22 11:57 ---
optimize_reg_copy_3 misses to replace in notes. Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from matz at gcc dot gnu dot org 2010-03-22 16:01 ---
For sched-deps.c there are two calls to cselib_lookup:
1) in sched_analize_1 (for writing to MEM)
2) in sched_analize_2 (for reading a MEM)
Regarding (2): cselib_lookup is called on a copy of X (made into T) which
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-22 16:29 ---
Subject: Bug 43475
Author: matz
Date: Mon Mar 22 16:28:51 2010
New Revision: 157640
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157640
Log:
PR middle-end/43475
*
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-22 16:30 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from matz at gcc dot gnu dot org 2010-03-22 16:34 ---
Re comment #6: well, then we still need to fix the c++98 case.
Re comment #7: note carefully how I have avoided is_pod<> in the testcase,
but instead used the internal mean to implement the former. That
--- Comment #10 from matz at gcc dot gnu dot org 2010-03-22 16:54 ---
Hmm, well, but there's code out there that expects the "old" TR1 semantic,
namely blocxx, and if the definition is indeed muddled than IMNSHO we should
retain the behaviour as it was in older GCC versi
--- Comment #14 from matz at gcc dot gnu dot org 2010-03-23 16:16 ---
Simply replace the recursive call to expand_expr_real_1 with a call to
expand_expr_real. That's the wrapper setting locations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
--- Comment #18 from matz at gcc dot gnu dot org 2010-03-23 16:46 ---
It should mostly not matter anymore as expand_expr_real_[12] and friends use
an explicit location parameter, stored away before expanding operands.
But to be safe, yes, expand_expr_real() should instead also restore
--- Comment #28 from matz at gcc dot gnu dot org 2010-04-06 10:34 ---
I don't think we should fix the double-accounting bug for the 4.5 series,
when we tried it on SPEC it caused several regression, meaning we would need
much more fine-tuning. We have time for that fo
--- Comment #33 from matz at gcc dot gnu dot org 2010-04-06 11:09 ---
Steven, please note that this PR was proposed WONTFIX for 4.5 already in
comment #15. The discussion after that was about something that is only
slightly related to this bug, something that wouldn't actually a
--- Comment #5 from matz at gcc dot gnu dot org 2010-04-08 13:40 ---
Um, how can r138953 be the reason when (as the original report says) it's
still okay with r153685? In any case, my patch just shuffled around the
activation/non-activation of the scheduler, so if at all it expo
--- Comment #19 from matz at gcc dot gnu dot org 2010-04-08 14:50 ---
This seems rather like a hack for our not-so-capable loop unroller. The
estimator already correctly knows that much of it will be optimized away,
hence it would make more sense for the code emitter to also not emit
--- Comment #4 from matz at gcc dot gnu dot org 2010-04-13 11:59 ---
No, we shouldn't unconditionally create REGs if the target isn't one, but
rather only if it doesn't match the predicate. Like so, which I'm testing
right now
--- Comment #5 from matz at gcc dot gnu dot org 2010-04-13 13:35 ---
Subject: Bug 43730
Author: matz
Date: Tue Apr 13 13:35:30 2010
New Revision: 158268
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158268
Log:
PR middle-end/43730
* bu
--- Comment #6 from matz at gcc dot gnu dot org 2010-04-13 13:47 ---
Subject: Bug 43730
Author: matz
Date: Tue Apr 13 13:47:11 2010
New Revision: 158270
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158270
Log:
PR middle-end/43730
* bu
--- Comment #7 from matz at gcc dot gnu dot org 2010-04-13 13:54 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from matz at gcc dot gnu dot org 2010-04-14 14:51 ---
Subject: Bug 42963
Author: matz
Date: Wed Apr 14 14:50:33 2010
New Revision: 158345
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158345
Log:
PR tree-optimization/42963
* tr
--- Comment #7 from matz at gcc dot gnu dot org 2010-04-14 14:53 ---
Fixed for 4.6. I propose to WONTFIX this for 4.5.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
esn't rewrite attributes
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy
--- Comment #1 from matz at gcc dot gnu dot org 2010-04-21 15:08 ---
Created an attachment (id=20454)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20454&action=view)
testcase
# gcc -O2 sra-nonnull.c && ./a.out
Segmentation fault
--
http://gcc.gnu.org/bugzil
--- Comment #3 from matz at gcc dot gnu dot org 2009-11-26 14:50 ---
I have a patch.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #4 from matz at gcc dot gnu dot org 2009-11-26 15:58 ---
Fixed in r154674.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from matz at gcc dot gnu dot org 2009-11-26 16:51 ---
I have a patch: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01474.html
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from matz at gcc dot gnu dot org 2009-11-27 13:09 ---
Subject: Bug 41906
Author: matz
Date: Fri Nov 27 13:08:58 2009
New Revision: 154704
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154704
Log:
PR c++/41906
* tree-eh.c (lower_catch): St
--- Comment #4 from matz at gcc dot gnu dot org 2009-11-27 13:26 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from matz at gcc dot gnu dot org 2009-11-27 14:25 ---
Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #7 from matz at gcc dot gnu dot org 2009-11-27 15:36 ---
Subject: Bug 42084
Author: matz
Date: Fri Nov 27 15:35:50 2009
New Revision: 154709
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154709
Log:
PR rtl-optimization/42084
* cfg
--- Comment #8 from matz at gcc dot gnu dot org 2009-11-27 15:37 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from matz at gcc dot gnu dot org 2009-12-01 11:24 ---
Hmpf, something fishy is going on, as this patch should have been only
refactoring without influence on the generated code. I'll look at it.
--
matz at gcc dot gnu dot org changed:
What|Re
--- Comment #42 from matz at gcc dot gnu dot org 2009-12-03 13:36 ---
Subject: Bug 38474
Author: matz
Date: Thu Dec 3 13:36:32 2009
New Revision: 154945
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154945
Log:
PR middle-end/38474
* cfgexpand.c
--- Comment #44 from matz at gcc dot gnu dot org 2009-12-03 21:05 ---
I'm glad. I plan to work on also the other slow part of expand, which is the
temp slot goo, but a full solution requires touching very old and stable parts
of GCC, hence is IMO nothing for stage 3. I have an ob
--- Comment #45 from matz at gcc dot gnu dot org 2009-12-08 13:56 ---
Subject: Bug 38474
Author: matz
Date: Tue Dec 8 13:56:06 2009
New Revision: 155087
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155087
Log:
PR middle-end/38474
* function.c (free_te
--- Comment #6 from matz at gcc dot gnu dot org 2009-12-13 21:51 ---
Subject: Bug 42027
Author: matz
Date: Sun Dec 13 21:51:34 2009
New Revision: 155196
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155196
Log:
PR tree-optimization/42027
* dojump.c
--- Comment #7 from matz at gcc dot gnu dot org 2009-12-13 21:53 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from matz at gcc dot gnu dot org 2009-12-13 21:57 ---
Mark it so.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #25 from matz at gcc dot gnu dot org 2009-12-13 23:48 ---
The reason that the testcase still is slow (and that the inner loop isn't
unrolled or vectorized) is still the calculation of countm1. The division
therein stays in the second inner loop, whereas with GCC 4.3 i
--- Comment #26 from matz at gcc dot gnu dot org 2009-12-14 04:55 ---
And if I fix this problem (so that only one reference to *n_9) remains
I hit the problem that the fortran frontend emits the computation of countm1
after the loop bound test. No pass is moving code in front of that
--- Comment #27 from matz at gcc dot gnu dot org 2009-12-14 05:25 ---
Created an attachment (id=19287)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19287&action=view)
three hacks
My current collection of patches and hacks for this problem. Obviously the
"if (0)&
--- Comment #35 from matz at gcc dot gnu dot org 2009-12-14 16:58 ---
Exactly my thinking (growing SCCs -> slow, sorting SCCs -> difficult).
What I thought about the trapping problem is that in this situation we could
ignore the trap test. We start with this situation:
bb1:
go
--- Comment #22 from matz at gcc dot gnu dot org 2009-12-16 23:36 ---
My patch only enables more vectorization. This seems to uncover a problem
in the vectorizer (which I haven't yet looked at).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #14 from matz at gcc dot gnu dot org 2009-12-16 23:43 ---
That's exactly what I fixed with my last patch. If this still results in a
difference it's caused by difference in cheapness of branches. I'll poke at
it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42027
--- Comment #15 from matz at gcc dot gnu dot org 2009-12-17 00:27 ---
Hmm, no, it's still my fault. Something must have gone wrong with my brain
when I thought the bug was fixed, no idea how that happened. The patch wasn't
complete.
--
matz at gcc dot gnu dot o
--- Comment #16 from matz at gcc dot gnu dot org 2009-12-17 01:42 ---
Created an attachment (id=19332)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19332&action=view)
Real fix
Now, before I blow it again, would you be so kind to test this patch (on top
of some recen
--- Comment #40 from matz at gcc dot gnu dot org 2009-12-18 21:40 ---
That's expected. There are three problems and the patch in comment #38 hacks
around only one of them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
--- Comment #5 from matz at gcc dot gnu dot org 2009-12-19 01:19 ---
To explain: the miscompilation is a result of the cloner (when cloning for the
find() call) creating a new tree for a local static variable (the 'm' in
main). After inlining we have:
if ( &mD.2
201 - 300 of 411 matches
Mail list logo
