https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69013
davidxl at google dot com changed:
What|Removed |Added
CC||davidxl at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303
--- Comment #8 from davidxl at google dot com ---
Created attachment 31495
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31495action=edit
Patch file : cleanup + more predicate simplification rules
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303
--- Comment #10 from davidxl at google dot com ---
My patch does this.
1) it first does aggressive simplification iteratively (more rules can be added
later).
2) it then does normalization by building up larger predicate trees by
following ud
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303
--- Comment #11 from davidxl at google dot com ---
The false negative bug introduced in the patch is fixed. Will submit the patch
for review soon.
(In reply to davidxl from comment #10)
My patch does this.
1) it first does aggressive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303
davidxl at google dot com changed:
What|Removed |Added
CC||davidxl at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
davidxl at google dot com changed:
What|Removed |Added
CC||davidxl at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
--- Comment #8 from davidxl at google dot com ---
(In reply to Neil Vachharajani from comment #7)
It seems like the whole problem is that the loop early exit goes through
bb_6 which is the same path the back-edge goes through.
There is also one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
--- Comment #9 from davidxl at google dot com ---
(In reply to Richard Biener from comment #5)
Confirmed with the C++ FE, works with the C FE. Does not warn on trunk (for
no good reason I think, the reason seems to be presence of loop structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
--- Comment #10 from davidxl at google dot com ---
When an incoming edge to a phi is a critical edge, the 'use BB' for the phi arg
should be in the split BB of the edge. Pushing the use into either the Source
BB or the dest BB will result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57375
--- Comment #3 from davidxl at google dot com ---
(In reply to Sriraman Tallam from comment #2)
IMO, This is working as expected.
You define corei7 only in mv12-aux1.cc, so the compilation of mv12.C and
mv12-aux.cc do not see the corei7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57378
--- Comment #3 from davidxl at google dot com ---
Can the resolver node be updated? or a new dispatcher/resolver is created?
The user code looks fine to me, which exposes the implementation limitation.
David
(In reply to Sriraman Tallam from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955
davidxl at google dot com changed:
What|Removed |Added
CC||davidxl at google dot
https://codereview.appspot.com/7426043/diff/1/gcc/gcov-io.h
File gcc/gcov-io.h (right):
https://codereview.appspot.com/7426043/diff/1/gcc/gcov-io.h#newcode1013
gcc/gcov-io.h:1013: GCOV_LINKAGE void gcov_seek (gcov_position_t
/*position*/, int /* from_end */)
I think it is better to create a new
Looks good to me.
https://codereview.appspot.com/7426043/
https://codereview.appspot.com/7393058/diff/8001/libgcc/dyn-ipa.c
File libgcc/dyn-ipa.c (right):
https://codereview.appspot.com/7393058/diff/8001/libgcc/dyn-ipa.c#newcode235
libgcc/dyn-ipa.c:235: /* Return module_id. FUNC_GUID is the global
unique id. */
Add a comment here that the returned
The coverage.c related patch is not uploaded properly. Will be reviewed
seperately.
David
https://codereview.appspot.com/7393058/diff/1/gcc/gcov-dump.c
File gcc/gcov-dump.c (right):
https://codereview.appspot.com/7393058/diff/1/gcc/gcov-dump.c#newcode581
gcc/gcov-dump.c:581: const char
The change in gcov-io.h is from a different patch.
David
https://codereview.appspot.com/6968046/diff/1/gcc/gcov-io.c
File gcc/gcov-io.c (right):
https://codereview.appspot.com/6968046/diff/1/gcc/gcov-io.c#newcode688
gcc/gcov-io.c:688:
Have you compared this with this impl:
while (x)
{
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487
--- Comment #19 from davidxl at google dot com 2012-09-11 17:44:29 UTC ---
How much saving do we get by not writing out the 0 entries? With the
proposed change, how less frequent is the problem occuring?
David
On Tue, Sep 11, 2012 at 10:38 AM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487
--- Comment #21 from davidxl at google dot com 2012-09-11 18:08:26 UTC ---
Assuming the size of histogram for the same file does not vary that
much, is it better to round the size to the next power of 2 -- 60
entries will need print out 64 etc
Ok for google branches.
David
http://codereview.appspot.com/6427063/
Where is the string table management code? The gcov.c file is not
properly uploaded either.
David
http://codereview.appspot.com/6427063/diff/5001/gcc/gcov-io.c
File gcc/gcov-io.c (right):
http://codereview.appspot.com/6427063/diff/5001/gcc/gcov-io.c#newcode280
gcc/gcov-io.c:280:
On 2012/08/24 21:51:24, cmang wrote:
Fixed formatting issues.
The gcov.c is still not uploaded properly.
===
--- gcc/gcov.c (revision 190359)
+++ gcc/gcov.c (working copy)
@@ -222,6 +222,7 @@ typedef struct pmu_data
{
http://codereview.appspot.com/6427063/diff/11002/gcc/gcov-io.h
File gcc/gcov-io.h (right):
http://codereview.appspot.com/6427063/diff/11002/gcc/gcov-io.h#newcode688
gcc/gcov-io.h:688: gcov_unsigned_t index; /* The corresponding string
table index */
Is this field necessary?
http://codereview.appspot.com/6351086/diff/1/gcc/gcov-io.h
File gcc/gcov-io.h (right):
http://codereview.appspot.com/6351086/diff/1/gcc/gcov-io.h#newcode396
gcc/gcov-io.h:396: gcov_unsigned_t num_hot_counters;/* number of
counters to reach a given
Should it be made into an array accessed with
other than the update issue, good for google branch.
David
http://codereview.appspot.com/6282045/diff/4003/libgcc/libgcov.c
File libgcc/libgcov.c (right):
http://codereview.appspot.com/6282045/diff/4003/libgcc/libgcov.c#newcode1127
libgcc/libgcov.c:1127: cs_prg-num_hot_counters =
http://codereview.appspot.com/6306054/diff/1/cgraph.h
File cgraph.h (right):
http://codereview.appspot.com/6306054/diff/1/cgraph.h#newcode410
cgraph.h:410:
Why not putting this into value-prof.h?
http://codereview.appspot.com/6306054/diff/1/ipa-split.c
File ipa-split.c (right):
ok for google branches -- LTO specific bugs should be isolated and
submitted upstream.
David
http://codereview.appspot.com/6306054/diff/5001/value-prof.c
File value-prof.c (right):
http://codereview.appspot.com/6306054/diff/5001/value-prof.c#newcode1720
value-prof.c:1720: direct_call2 = 0;
Ok
http://codereview.appspot.com/6282045/diff/1/gcc/gcov-io.h
File gcc/gcov-io.h (right):
http://codereview.appspot.com/6282045/diff/1/gcc/gcov-io.h#newcode544
gcc/gcov-io.h:544: gcov_unsigned_t sum_cutoff_percent;/* sum_all cutoff
percentage computed
Is there a need to record this?
Ok with better naming for the dummy function such as
'__gcov_dummy_ref1'. Another choice is to let __gcov_flush calls
__gcov_dump + __gcov_reset -- but the dump_completed state needs to be
saved and restored.
David
http://codereview.appspot.com/6276043/
It might be better to separate the data structure name change
(niter_desc to loop_desc) into a different patch. Other than that, the
patch looks good to me (for google branches only) Unroller really needs
more heuristics like this instead of just looking at size.
David
Ok for google branches (please also backport to google/gcc_47 branch.
David
On 2012/05/01 20:37:44, asharif wrote:
On 2012/04/30 19:54:14, asharif wrote:
I backported the following patch:
2012-03-12 Richard Guenther mailto:rguent...@suse.de
* gthr.h (__GTHREAD_MUTEX_INIT_FUNCTION):
http://codereview.appspot.com/6099055/diff/1/loop-unroll.c
File loop-unroll.c (right):
http://codereview.appspot.com/6099055/diff/1/loop-unroll.c#newcode156
loop-unroll.c:156: static bool
An empty line here.
http://codereview.appspot.com/6099055/diff/1/loop-unroll.c#newcode182
http://codereview.appspot.com/5975045/diff/6001/config/i386/i386.md
File config/i386/i386.md (right):
http://codereview.appspot.com/5975045/diff/6001/config/i386/i386.md#newcode16974
config/i386/i386.md:16974: ;; gets too big.
The comments may need to be updated.
It would be nice to add some unit/regression test cases of some sort.
David
http://codereview.appspot.com/5851044/diff/1/callgraph.c
File callgraph.c (right):
http://codereview.appspot.com/5851044/diff/1/callgraph.c#newcode309
callgraph.c:309: if (!is_prefix_of (_ZL, name))
How about static
ok for google branches after checkin validation.
David
http://codereview.appspot.com/5851044/
Ok for google branches after updating the doc/invoke.texi file.
David
http://codereview.appspot.com/5825054/
ok for google-46 after the minor changes below. Make sure default lipo
testing is well covered too.
David
http://codereview.appspot.com/5746044/diff/11001/cgraph.c
File cgraph.c (right):
http://codereview.appspot.com/5746044/diff/11001/cgraph.c#newcode2887
cgraph.c:2887:
Ok for google branches for now.
thanks,
David
http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c
File gcc/predict.c (right):
http://codereview.appspot.com/5504086/diff/1004/gcc/predict.c#newcode958
gcc/predict.c:958: find_qualified_ssa_name (tree t1, tree t2)
Better change the
ok for google branches with the above changes. Please continue to seek
upstream approval.
David
http://codereview.appspot.com/5461043/diff/19001/gcc/doc/invoke.texi
File gcc/doc/invoke.texi (right):
http://codereview.appspot.com/5461043/diff/19001/gcc/doc/invoke.texi#newcode403
Also need to update doc/invoke.texi file for the new option.
http://codereview.appspot.com/5461043/diff/16001/gcc/cfgexpand.c
File gcc/cfgexpand.c (right):
http://codereview.appspot.com/5461043/diff/16001/gcc/cfgexpand.c#newcode1531
gcc/cfgexpand.c:1531: record_or_union_type_has_array
http://codereview.appspot.com/5535046/diff/1/gcc/config/i386/i386.c
File gcc/config/i386/i386.c (right):
http://codereview.appspot.com/5535046/diff/1/gcc/config/i386/i386.c#newcode26032
gcc/config/i386/i386.c:26032: +M_AMDFAM15,
Maybe better to change 10 to 10H, and 15 to 15H in the name as
http://codereview.appspot.com/5490054/diff/1011/config/i386/i386.c
File config/i386/i386.c (right):
http://codereview.appspot.com/5490054/diff/1011/config/i386/i386.c#newcode26569
config/i386/i386.c:26569: +mversion_for_core2 (tree *optimization_node,
- mversionable_for_core2_p ?
http://codereview.appspot.com/5416043/diff/12001/gcc/config/i386/i386.c
File gcc/config/i386/i386.c (left):
http://codereview.appspot.com/5416043/diff/12001/gcc/config/i386/i386.c#oldcode10928
gcc/config/i386/i386.c:10928: if (current_function_decl != NULL_TREE
I am not sure how the hack you
Ok, Cary's explanation makes sense. Please update the comments to make
it clearer.
http://codereview.appspot.com/5416043/diff/1/gcc/config/i386/i386.c
File gcc/config/i386/i386.c (right):
http://codereview.appspot.com/5416043/diff/1/gcc/config/i386/i386.c#newcode10927
http://codereview.appspot.com/5488054/diff/4002/tree-vect-stmts.c
File tree-vect-stmts.c (right):
http://codereview.appspot.com/5488054/diff/4002/tree-vect-stmts.c#newcode3712
tree-vect-stmts.c:3712: }
The check can be put into a helper function.
http://codereview.appspot.com/5488054/
ok for google/main.
David
http://codereview.appspot.com/5483046/
to 'section_name'
by ix86_elf_asm_named_section(). */
On 2011/12/02 01:57:17, harshit wrote:
On 2011/11/28 22:16:27, davidxl wrote:
Explain more on the comdat handling.
I have limited knowledge about comdat sections, so can't give a
detailed
explanation on why the assembler emits an error.
What does
http://codereview.appspot.com/5416043/diff/6001/gcc/config/i386/i386.c
File gcc/config/i386/i386.c (right):
http://codereview.appspot.com/5416043/diff/6001/gcc/config/i386/i386.c#newcode10881
gcc/config/i386/i386.c:10881: + '_function_patch_epilogue'. The
backpointer section can be used to
Please also explain the need for backpointer section.
David
http://codereview.appspot.com/5416043/diff/1/gcc/config/i386/i386.c
File gcc/config/i386/i386.c (right):
http://codereview.appspot.com/5416043/diff/1/gcc/config/i386/i386.c#newcode10801
gcc/config/i386/i386.c:10801: +static bool
Add
http://codereview.appspot.com/5303083/diff/28001/gcc/tree-tsan.c
File gcc/tree-tsan.c (right):
http://codereview.appspot.com/5303083/diff/28001/gcc/tree-tsan.c#newcode227
gcc/tree-tsan.c:227: var = varpool_node_for_asm (id);
Use cgraph_node_for_asm instead.
Have you run through SPEC, and SPEC06 with this change? What is the
instrumentation overhead using gcc?
David
http://codereview.appspot.com/5303083/
http://codereview.appspot.com/5303083/diff/3002/gcc/tree-tsan.c
File gcc/tree-tsan.c (right):
http://codereview.appspot.com/5303083/diff/3002/gcc/tree-tsan.c#newcode1075
gcc/tree-tsan.c:1075: for (eidx = 0; VEC_iterate (edge, exit_bb-preds,
eidx, e); eidx++)
Use FOR_EACH_EDGE macro
Have not done with reviewing. This is the first batch.
David
http://codereview.appspot.com/5303083/diff/1/gcc/passes.c
File gcc/passes.c (right):
http://codereview.appspot.com/5303083/diff/1/gcc/passes.c#newcode1423
gcc/passes.c:1423: NEXT_PASS (pass_tsan);
Move this to the same place as
there is array ref with runtime index --
this is mainly for alias analysis.
On 2011/10/17 23:04:50, kcc wrote:
On 2011/10/17 22:33:17, davidxl wrote:
Discard 2) -- it is not correct. What Asan needs is slightly
different.
Yea.
I actually have a test where this instrumentation does something
http://codereview.appspot.com/5272048/diff/18001/tree-asan.c
File tree-asan.c (right):
http://codereview.appspot.com/5272048/diff/18001/tree-asan.c#newcode325
tree-asan.c:325: base = build_addr (t, current_function_decl);
You need to create a temp var and build as gimple assignment. See
http://codereview.appspot.com/5272048/diff/18001/tree-asan.c
File tree-asan.c (right):
http://codereview.appspot.com/5272048/diff/18001/tree-asan.c#newcode325
tree-asan.c:325: base = build_addr (t, current_function_decl);
There are issues with creating address expressions from TARGET_MEM_REF
in
fasan option also needs to be documented in doc/invoke.texi.
http://codereview.appspot.com/5272048/diff/2001/tree-asan.c
File tree-asan.c (right):
http://codereview.appspot.com/5272048/diff/2001/tree-asan.c#newcode54
tree-asan.c:54: ShadowValue = (char*)ShadowAddr;
*(char*) ShadowAddr;
is slightly different.
David
On 2011/10/17 22:26:55, davidxl wrote:
Two suggestions:
1) You only need to deal with GIMPLE_ASSIGN (lhs and rhs) for all
memory
references)
2) use get_base_address function to compute base address.
http://codereview.appspot.com/5272048/
Ok for google branches
It is better to have a higher level compiler option to be introduced
for this purpose instead of asking user to specify the plugin path.
The option should enable 1) ffunction-sections; 2) cgraph note section
genration; 3) enable the plugin. One possibility is to enhance
http://codereview.appspot.com/4798045/diff/1/ipa.c
File ipa.c (right):
http://codereview.appspot.com/4798045/diff/1/ipa.c#newcode1034
ipa.c:1034: {
Has varpool node linking happened at this point? If not, the new code
here is not excersised.
Ok for google/main after the minor cleanups. Incorporate comments from
maintainers when available.
David
http://codereview.appspot.com/4563044/diff/1/gcc/gcse.c
File gcc/gcse.c (right):
http://codereview.appspot.com/4563044/diff/1/gcc/gcse.c#newcode5050
gcc/gcse.c:5050: if (ld_motion_count =
LGTM
http://codereview.appspot.com/4446047/diff/1/gcc/libgcov.c
File gcc/libgcov.c (right):
http://codereview.appspot.com/4446047/diff/1/gcc/libgcov.c#newcode155
gcc/libgcov.c:155: filename? filename : , e, v);
Better split it into two different printfs as the format is different --
otherwise
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46306
Summary: inefficient code generated for array accesses
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46200
davidxl davidxl at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46279
Summary: cmov not hoisted out of the loop
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46281
Summary: Inefficient unswitching (too many copies)
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46265
davidxl davidxl at gcc dot gnu.org changed:
What|Removed |Added
CC||davidxl at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46265
--- Comment #3 from davidxl davidxl at gcc dot gnu.org 2010-11-03 05:59:30
UTC ---
Another example gcc fails to ifcvt (succeeds only if only one statement is in
if and else block.
void ref_int_p(int *);
void foo (int j, int k)
{
int i;
int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46235
Summary: inefficient bittest code generation
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46236
Summary: Local aggregate not eliminated
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46200
davidxl davidxl at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45972
davidxl davidxl at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
--- Comment #26 from davidxl at gcc dot gnu dot org 2010-08-31 17:45
---
Good observation re. the number of IVs in the final set. This usually points to
some problem/bug in the cost function. I briefly looked at this case -- it
indeed exposes two more bugs in the cost model:
1
--- Comment #25 from davidxl at gcc dot gnu dot org 2010-08-30 16:41
---
(In reply to comment #24)
(In reply to comment #20)
(In reply to comment #16)
adjust summary according to the last timings
I am surprised to see such big differences between trunk and previous
--- Comment #20 from davidxl at gcc dot gnu dot org 2010-08-30 03:10
---
(In reply to comment #16)
adjust summary according to the last timings
I am surprised to see such big differences between trunk and previous releases.
Compiling this test case with the those options on my
--- Comment #21 from davidxl at gcc dot gnu dot org 2010-08-30 03:19
---
(In reply to comment #17)
tree iv optimization : 32.57 (20%) usr 0.10 ( 5%) sys 32.73 (20%) wall
322095 kB (18%) ggc
20% is still completely unreasonable for IV optimization.
There was a patch
--- Comment #10 from davidxl at gcc dot gnu dot org 2010-08-28 06:00
---
fixed in r163610.
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from davidxl at gcc dot gnu dot org 2010-08-27 17:01 ---
Will take a look
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from davidxl at gcc dot gnu dot org 2010-07-30 17:23 ---
Seems -Os specific -- also reproducible on x86. With -O2, the result is
expected.
David
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from davidxl at gcc dot gnu dot org 2010-07-29 17:21 ---
Fixed in r162687
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from davidxl at gcc dot gnu dot org 2010-07-29 05:51 ---
The problem is that before the ivopt patch, the ivopt patch introduced a iv
candidate that is unconditionally initialized with b:
ivtmp_xxx = b (D);
After the patch, this assignment no longer exists, and the use
--- Comment #4 from davidxl at gcc dot gnu dot org 2010-07-19 16:34 ---
Fixed in r162310.
David
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from davidxl at gcc dot gnu dot org 2010-07-14 04:12 ---
This seems to be specific to powerpc.
Could you attach the dump files with options:
-O2 -Wuninitialized -fdump-tree-cddce2 -fdump-tree-uninit-details
Thanks,
David
(In reply to comment #0)
Subject testcase
--- Comment #3 from davidxl at gcc dot gnu dot org 2010-04-22 17:04 ---
(In reply to comment #2)
(In reply to comment #1)
so it doesn't consider the struct with the array for total scalarization
for some reason. Martin?
Well, that was a deliberate decision when fixing PR
--- Comment #11 from davidxl at gcc dot gnu dot org 2010-04-20 23:55
---
(In reply to comment #2)
(In reply to comment #1)
check() can return 1 on the first call and 0 on the second and if *argv is
NULL
then then bug will be used uninitialized.
right, but this doesn't matter
--- Comment #8 from davidxl at gcc dot gnu dot org 2010-04-21 00:27 ---
(In reply to comment #2)
Note this is not fully a regression but really a progression.
What is happening now is only partial optimizations is happen before the
warning to happen.
I was unable to reduce
--- Comment #1 from davidxl at gcc dot gnu dot org 2010-04-21 00:29 ---
(In reply to comment #0)
When compiling the source with -Wall -O, gcc gives the following warning:
% gcc -c -Wall -O gcc_test.c
gcc_test.c: In function ?functionLeon?:
gcc_test.c:11: warning: ?reference? may
--- Comment #6 from davidxl at gcc dot gnu dot org 2010-02-03 18:30 ---
See discussions in http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00138.html
about changing dynamic types using placement new -- it is basically not allowed
-- so the optimization is valid.
David
--
davidxl
--- Comment #8 from davidxl at gcc dot gnu dot org 2010-02-03 21:44 ---
(In reply to comment #7)
It is valid to use placement new to construct a more or less derived type
which would change the vtable pointer.
Thus I think this bug is still invalid.
How did you reach
--- Comment #11 from davidxl at gcc dot gnu dot org 2010-02-03 21:55
---
(In reply to comment #9)
Ah, Set aside the standard. Another user who wants to make up his own
semantics for a standardized language. No, no, and damn no.
Of course, things like this can be brought up
--- Comment #13 from davidxl at gcc dot gnu dot org 2010-02-03 22:05
---
(In reply to comment #12)
Btw, a destructor call also changes the vtbl pointer.
ctors, dtors, wrapper function calls etc are all handled. Detailed write up
will be available at some point. To put it a simple
--- Comment #3 from davidxl at gcc dot gnu dot org 2009-12-23 19:37 ---
This bug is ARM specific (thumb) mode. In x86, the hoisting is unnecessary as
the move instruction support the imm form.
The issue here is more in the GIMPLE canonicalization (target specific). In
this case
--- Comment #2 from davidxl at gcc dot gnu dot org 2009-12-09 18:07 ---
Fixed in r155111.
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from davidxl at gcc dot gnu dot org 2009-03-27 18:25 ---
See SVN revision 145121 for the fix.
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from davidxl at gcc dot gnu dot org 2009-03-27 18:28 ---
See r145118 for the fix.
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davidxl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39557
--- Comment #1 from davidxl at gcc dot gnu dot org 2009-03-25 23:10 ---
Created an attachment (id=17542)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17542action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39557
--- Comment #1 from davidxl at gcc dot gnu dot org 2009-03-24 17:50 ---
Created an attachment (id=17538)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17538action=view)
Test case
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from davidxl at gcc dot gnu dot org 2009-03-24 17:51 ---
Created an attachment (id=17539)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17539action=view)
patch file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39548
--- Comment #5 from davidxl at gcc dot gnu dot org 2009-03-24 21:25 ---
(In reply to comment #3)
It might be better to place the check after the loop (and put an assert in
set_copy_of_val that triggers the copy may not happen).
This sounds good.
David
--
http://gcc.gnu.org
1 - 100 of 108 matches
Mail list logo
