[Bug rtl-optimization/56124] Redundant reload for loading from memory

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56124 bin.cheng changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug target/54414] New: ARM:mis-compiled prologue/epilogue on cortex-m0 when optimizing with -Os

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54414 Bug #: 54414 Summary: ARM:mis-compiled prologue/epilogue on cortex-m0 when optimizing with -Os Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONF

[Bug target/54414] ARM:mis-compiled prologue/epilogue on cortex-m0 when optimizing with -Os

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54414 --- Comment #1 from amker.cheng 2012-08-30 10:17:15 UTC --- I suspect that the call of arm_size_return_regs in function thumb1_extra_regs_pushed should also be covered as in http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00830.html

[Bug rtl-optimization/54133] regrename introduces additional dependencies

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54133 --- Comment #8 from amker.cheng 2012-09-25 07:45:02 UTC --- I have spent some time investigating this bug and now I think I understand the issue. The problematic instruction patterns which save/restore argument/return registers is gener

[Bug target/54989] FAIL: gcc.dg/hoist-register-pressure.c scan-rtl-dump hoist "PRE/HOIST: end of bb .* copying expression" on darwin

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54989 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot

[Bug other/55031] New: Documentation on RTL GCSE pass is outdated

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55031 Bug #: 55031 Summary: Documentation on RTL GCSE pass is outdated Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priori

[Bug target/54989] FAIL: gcc.dg/hoist-register-pressure.c scan-rtl-dump hoist "PRE/HOIST: end of bb .* copying expression" on darwin

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54989 --- Comment #7 from bin.cheng 2012-10-31 08:45:37 UTC --- I think this is fixed and it's a bug in 4.8.0. Hi Jack, could you verify that it is fixed? Thanks very much.

[Bug rtl-optimization/57540] New: stack pointer related loop invariants after reload

Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amker.cheng at gmail dot com For below program, void foo ( unsigned char *len, int alphaSize, int maxLen ) { int i, j, k; unsigned char tooLong

[Bug rtl-optimization/57540] stack pointer related loop invariants after reload

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57540 --- Comment #1 from bin.cheng --- The dump of loop_init is like, 72: r178:SI=0 106: L106: 90: NOTE_INSN_BASIC_BLOCK 6 91: r178:SI=r178:SI+0x1 94: r190:SI=r177:SI<<0x2 REG_DEAD r177:SI 95: r191:SI=sfp:SI+r190:SI REG_DEA

[Bug target/57540] stack pointer related loop invariants after reload

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57540 bin.cheng changed: What|Removed |Added Component|rtl-optimization|target --- Comment #2 from bin.cheng --- Thi

[Bug target/57540] stack pointer related loop invariants after reload for ARM mode

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57540 --- Comment #3 from bin.cheng --- I think this should be handled in expand. During expanding, GCC tries "base + scaled_offset + offset" pattern, which is invalid for targets like arm. At this point we still have a chance to refactor "base + offse

[Bug target/56102] Wrong rtx cost calculated for Thumb1

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102 bin.cheng changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/57540] stack pointer related loop invariants after reload for ARM mode

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57540 bin.cheng changed: What|Removed |Added Component|middle-end |target --- Comment #4 from bin.cheng --- Sor

[Bug target/58423] New: [ARM]ICE with shrink-wrap-sibcall.c on a15/neon/hard

Component: target Assignee: unassigned at gcc dot gnu.org Reporter: amker.cheng at gmail dot com GCC ICEed with shrink-wrap-sibcall.c on a15 with below command line: ./arm-none-eabi-gcc -O2 -marm -mcpu=cortex-a15 -mfpu=neon -mfloat-abi=hard shrink-wrap-sibcall.c -S -o shrink-wrap

[Bug target/58424] New: [ARM]gcc.target/arm/pr42575.c failed on arm

: target Assignee: unassigned at gcc dot gnu.org Reporter: amker.cheng at gmail dot com gcc is at revision r202599 and is configured as: ../gcc/configure build=i686-linux-gnu host=i686-linux-gnu target=arm-none-eabi prefix=.../trunk-orig/target/ disable-decimal-float disable-libffi

[Bug rtl-optimization/50663] New: conditional propagation missed in cprop.c pass

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50663 Bug #: 50663 Summary: conditional propagation missed in cprop.c pass Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement

[Bug rtl-optimization/50663] conditional propagation missed in cprop.c pass

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50663 --- Comment #1 from amker.cheng 2011-10-08 10:25:04 UTC --- Here comes the cause: Though the cprop.c pass collected the implicit_set information, it is recorded as local info of basic block, and cprop only does global propagation. The result is

[Bug rtl-optimization/44025] Multiple load 0 to register

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025 --- Comment #4 from amker.cheng 2011-11-02 06:03:56 UTC --- I noticed that for attached reduced test case "reduced_test.c", cse pass can eliminate such redundant load constant instructions. But since cse works on extended basic block, rather than

[Bug rtl-optimization/44025] Multiple load 0 to register

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44025 --- Comment #5 from amker.cheng 2011-11-02 06:05:23 UTC --- Created attachment 25687 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25687 reduced test case which can be handled by cse pass

[Bug rtl-optimization/52804] IRA/RELOAD allocate wrong register on ARM for cortex-m0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52804 --- Comment #6 from amker.cheng 2012-05-15 02:15:59 UTC --- No regression reported in trunk so far, I back ported it into 4.7 branch.

[Bug middle-end/51867] GCC generates inconsistent code for same sources calling builtin calls, like sqrtf

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51867 --- Comment #5 from amker.cheng 2012-06-18 02:03:21 UTC --- Should be fixed.

[Bug middle-end/53922] New: VRP: semantic conflict between range_includes_zero_p and value_inside_range

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53922 Bug #: 53922 Summary: VRP: semantic conflict between range_includes_zero_p and value_inside_range Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNC

[Bug middle-end/53922] VRP: semantic conflict between range_includes_zero_p and value_inside_range

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53922 --- Comment #2 from amker.cheng 2012-07-11 08:03:11 UTC --- Yes, the dump before pass vrp2 is like: main () { int (*) (int) cstore.6; int g.2; int g.0; : g.0_1 = g; if (g.0_1 != 0) goto ; else goto ; : : # cstore.6_9 = PH

[Bug middle-end/53922] VRP: semantic conflict between range_includes_zero_p and value_inside_range

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53922 --- Comment #3 from amker.cheng 2012-07-11 10:12:24 UTC --- vrp processes PHI node " # cstore.6_9 = PHI " in calling sequence: vrp_visit_phi_node -> vrp_meet When gcc gives up in function vrp_meet, it executes following code to derive an anti-

[Bug rtl-optimization/54133] New: regrename introduces additional dependencies

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54133 Bug #: 54133 Summary: regrename introduces additional dependencies Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement

[Bug target/52412] another unnecessary register move on arm

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52412 amker.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot

[Bug rtl-optimization/54133] regrename introduces additional dependencies

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54133 --- Comment #2 from amker.cheng 2012-08-01 07:49:51 UTC --- I measured this kind of regression in benchmark CSiBE on arm-none-eabi/cortex-m0 with Os optimization. Turns out most of the them are relate to paramter/return register moving, like the

[Bug rtl-optimization/54133] regrename introduces additional dependencies

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54133 --- Comment #5 from amker.cheng 2012-08-01 13:48:50 UTC --- Thanks for your patch, IMHO, I don't think the problem could be fixed in this way, because: 1. 78 r177:DF=r0:DF 80 [sp:SI]=r166:DF 81 [sp:SI+0x8]=r168:DF 82 [sp:SI+0x10]=r17

[Bug rtl-optimization/54133] regrename introduces additional dependencies

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54133 --- Comment #7 from amker.cheng 2012-08-02 10:18:41 UTC --- (In reply to comment #6) > > In experiment, if I disable r0/r1 from renaming, most regressions observed > > in > > CSiBE are gone. > > > > So how should this be fixed? Thanks. > > The

[Bug target/51835] ARM EABI violation when passing arguments to helper floating functions like __aeabi_d2iz

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51835 --- Comment #6 from amker.cheng 2012-02-06 05:51:25 UTC --- (In reply to comment #5) > (In reply to comment #2) > > This is only applicable to the 4.6 branch and trunk since support for the > > Cortex M4 wasn't added till 4.6. > > > > cheers >

[Bug tree-optimization/43491] Unnecessary temporary for global register variable

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491 --- Comment #8 from amker.cheng 2012-02-17 03:55:24 UTC --- (In reply to comment #7) > With tree hoisting we generate > > : > pretmp.5_19 = data_0; > pretmp.5_20 = data_3; > i_21 = pretmp.5_19 + pretmp.5_20; > if (data_3(D) != 0) > g

[Bug middle-end/37780] Conditional expression with __builtin_clz() should be optimized out

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37780 --- Comment #2 from amker.cheng 2012-03-20 07:58:09 UTC --- the special case could be easily detected when gimplifying. but actually I am not sure whether it can be done even in middle end, since the middle end should not depend on any target inf

[Bug target/52804] New: IRA/RELOAD allocate wrong register on ARM for cortex-m0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52804 Bug #: 52804 Summary: IRA/RELOAD allocate wrong register on ARM for cortex-m0 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED S

[Bug target/52804] IRA/RELOAD allocate wrong register on ARM for cortex-m0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52804 --- Comment #1 from amker.cheng 2012-04-03 16:43:30 UTC --- For insns before ira: (insn 82 81 83 3 (set (reg/f:SI 281 [ *o_15(D) ]) (mem/f:SI (reg/v/f:SI 315 [orig:275 o ] [275]) [2 *o_15(D)+0 S4 A32])) pr52804.c:18 186 {*thumb1_movsi_i

[Bug target/52804] IRA/RELOAD allocate wrong register on ARM for cortex-m0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52804 --- Comment #2 from amker.cheng 2012-04-16 09:00:08 UTC --- Any comments? Or could anyone help me confirm this issue? Thanks very much.

[Bug rtl-optimization/55190] [SH] ivopts causes loop setup bloat

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #3

[Bug rtl-optimization/50749] Auto-inc-dec does not find subsequent contiguous mem accesses

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #15

[Bug tree-optimization/39200] ivopts slows down SciMark sparse matrix benchmark

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39200 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #1

[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #13 from bin.cheng --- Sorry for bothering, I have reverted the patch. Will investigate it.

[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #14 from bin.cheng --- I found out the root cause of this ICE and will use the simplified code given by comment#9 as an example. The gimple dump before IVOPT is like: : : # c_2 = PHI __val_comp_iter (D.4949); p2 = D.4950;

[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #15 from bin.cheng --- Created attachment 31414 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31414&action=edit The generated assembly with/without patch for code in comment #9 on cortex-m3

[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #16 from bin.cheng --- I fixed the reported problem and posted new patch at http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01159.html Apology that I missed java in bootstrap for previous patch. This version passes bootstrap and test for

[Bug tree-optimization/59479] New: Inlining of static function bloats code size when Os

Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amker.cheng at gmail dot com Created attachment 31424 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31424&action=edit The preprocessed file for newlib/libc/stdio/findfp.c Hi, for attached prepr

[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #18 from bin.cheng --- Hi Dominique d'Humieres, Thanks for verifying it.

[Bug middle-end/39838] [4.7/4.8/4.9 regression] unoptimal code for two simple loops

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39838 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #15

[Bug middle-end/39838] [4.7/4.8/4.9 regression] unoptimal code for two simple loops

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39838 --- Comment #16 from bin.cheng --- For optimization level O2, the dump before IVOPT is like: : _21 = p_6(D)->count; if (_21 > 0) goto ; else goto ; : : # i_26 = PHI if (count_8(D) > 0) goto ; else goto ; :

[Bug tree-optimization/59479] Inlining of static function bloats code size when Os

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59479 --- Comment #2 from bin.cheng --- I will investigate it later. Just clarifying, the function is called three times by the caller, it would increase code size usually. BTW, could you explain a little about "2nd-order effect"? I am not familiar w

[Bug tree-optimization/52272] [4.7/4.8/4.9 regression] Performance regression of 410.bwaves on x86.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #21

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #17

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955 --- Comment #19 from bin.cheng --- > > >not about an iv use appearing in memory reference while not marked as > >address_p, and can be fixed by revise the existing check condition, is > >it true? > > No, even expressing an address this way is br

[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #5

[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536 --- Comment #6 from bin.cheng --- Hi, Sorry I don't have m68k environment to do the bootstrap, could anyone help dump "-fdump-tree-all-details -fdump-rtl-all-slim" with and without the patch for me? Otherwise I have to revert the patch and hold i

[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536 --- Comment #8 from bin.cheng --- (In reply to Andreas Schwab from comment #1) > Between r205951 and r205984. (In reply to H.J. Lu from comment #7) > (In reply to bin.cheng from comment #6) > > Hi, > > Sorry I don't have m68k environment to do th

[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536 --- Comment #9 from bin.cheng --- Turns out my crossed bare-metal tool works after deleting all preprocessed "# xxx file" lines, but why these lines matter?

[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536 --- Comment #10 from bin.cheng --- The offending loop before IVOPT is like: : # var_index_1889 = PHI <1(924), var_index_983(923)> # var_index.250_1269 = PHI <1(924), var_index.250_1959(923)> if (var_index.250_1269 < _1237) goto ; el

[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536 bin.cheng changed: What|Removed |Added CC||bernds at codesourcery dot com,

[Bug bootstrap/59536] [4.9 regression] internal compiler error: in cselib_record_set, at cselib.c:2376 breaks m68k-linux bootstrap

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536 --- Comment #13 from bin.cheng --- (In reply to Andreas Schwab from comment #12) > -fno-auto-inc-dec avoids the crash. Dup of #52306? It looks like, AFAICT. Only this time it's blocking bootstrap :(

[Bug c++/59555] New: bogus error: template with C linkage with preprocessed c++ file

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: amker.cheng at gmail dot com Created attachment 31478 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31478&action=edit preprocessed c++ file For attached preprocessed file, a

[Bug middle-end/52306] [4.8/4.9 regression] ICE in cselib_record_set, at cselib.c:2158

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #27

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #3

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519 --- Comment #4 from bin.cheng --- First clue. b_lsm.11_13 is recognized as chrec {1, +, 1}_2 with the patch, thus the loop can be vectorized now. : : # b.4_30 = PHI # prephitmp_28 = PHI # b_lsm.11_13 = PHI # ivtmp_46 = PHI c.1

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519 --- Comment #5 from bin.cheng --- For the offending loop: : : # b.4_30 = PHI # prephitmp_28 = PHI # b_lsm.11_13 = PHI # ivtmp_46 = PHI c.1_9 = prephitmp_28 | 1; b.4_12 = b.4_30 + 1; ivtmp_45 = ivtmp_46 - 1; if (ivtmp_45 !

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519 --- Comment #7 from bin.cheng --- (In reply to Jakub Jelinek from comment #6) > Created attachment 31562 [details] > gcc49-pr59519.patch > > I wonder if this isn't just a checking issue, the two PHI nodes created in > *new_exit_bb have the same a

[Bug tree-optimization/59519] [4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in slpeel_update_phi_nodes_for_guard1, at tree-vect-loop-manip.c:486

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519 --- Comment #10 from bin.cheng --- (In reply to Jakub Jelinek from comment #9) > BTW, the patch can hardly regress anything, it only affects cases that ICEd > before the patch. Em, I am worried if vectorization can handle peeled phi correctly for

[Bug rtl-optimization/43491] Unnecessary temporary for global register variable

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491 amker.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot

[Bug rtl-optimization/43491] Unnecessary temporary for global register variable

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491 --- Comment #3 from amker.cheng 2011-11-24 09:24:37 UTC --- (In reply to comment #1) > > I'm thinking that this is perfectly normal thing to do, and that the redundant > move is meant to disappear in a later pass. My guess is that IRA is choos

[Bug rtl-optimization/43491] Unnecessary temporary for global register variable

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491 --- Comment #4 from amker.cheng 2011-12-21 03:44:03 UTC --- This bug is even worse on mips. The cause is ssa-pre eliminates global register variable when it is the RHS of single assign statment, while following passes do not handle the const/reg

[Bug target/51835] New: ARM EABI violation when passing arguments to helper floating functions like __aeabi_d2iz

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51835 Bug #: 51835 Summary: ARM EABI violation when passing arguments to helper floating functions like __aeabi_d2iz Classification: Unclassified Product: gcc Version: 4.7.0

[Bug middle-end/51867] New: GCC generates inconsistent code for same sources calling builtin calls, like sqrtf

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51867 Bug #: 51867 Summary: GCC generates inconsistent code for same sources calling builtin calls, like sqrtf Classification: Unclassified Product: gcc Version: 4.7.0 Stat

[Bug middle-end/51867] GCC generates inconsistent code for same sources calling builtin calls, like sqrtf

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51867 --- Comment #1 from amker.cheng 2012-01-16 10:15:59 UTC --- The cause is in function expand_builtin, gcc checks following conditions: -- /* When not optimizing, generate calls to library functions for

[Bug middle-end/51867] GCC generates inconsistent code for same sources calling builtin calls, like sqrtf

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51867 --- Comment #3 from amker.cheng 2012-01-17 10:35:14 UTC --- test case c-c++-common/dfp/signbit-2.c depends on this check. the case is like: - /* { dg-options "-O0" } */ /* Check

[Bug tree-optimization/88932] [8/9 Regression] ICE: verify_ssa failed (Error: definition in block 29 does not dominate use in block 25)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88932 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #4

[Bug tree-optimization/82965] [8 regression][armeb] gcc.dg/vect/pr79347.c starts failing after r254379

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82965 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment

[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment

[Bug tree-optimization/49498] [4.7/4.8 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot

[Bug tree-optimization/55424] New: [4.8 Regression]gcc.dg/uninit-pred-8_b.c bogus warning line 23 on ARM/Cortex-M0/-Os

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55424 Bug #: 55424 Summary: [4.8 Regression]gcc.dg/uninit-pred-8_b.c bogus warning line 23 on ARM/Cortex-M0/-Os Classification: Unclassified Product: gcc Version: 4.8.0

[Bug tree-optimization/49498] [4.7/4.8 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 --- Comment #19 from bin.cheng 2012-11-21 13:24:02 UTC --- (In reply to comment #18) > *** Bug 55424 has been marked as a duplicate of this bug. *** Just for the record. If the analysis I gave in Comment #17 is right, this PR reveals an

[Bug rtl-optimization/54910] ARM: Missed optimization of very simple ctz function

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54910 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot

[Bug tree-optimization/55906] New: suboptimal code generated for post-inc on Thumb1

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55906 Bug #: 55906 Summary: suboptimal code generated for post-inc on Thumb1 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal

[Bug target/56058] New: GCC arm-none-eabi build failure

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56058 Bug #: 56058 Summary: GCC arm-none-eabi build failure Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority

[Bug target/56102] New: Wrong rtx cost calculated for Thumb1

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102 Bug #: 56102 Summary: Wrong rtx cost calculated for Thumb1 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Pr

[Bug target/56102] Wrong rtx cost calculated for Thumb1

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102 --- Comment #1 from bin.cheng 2013-01-25 03:46:59 UTC --- I have investigated this issue. GCC uses function init_lower_subreg to initialize costs of MOVE insn with different mode, then uses this information to decompose multi-word pseudo

[Bug target/56102] Wrong rtx cost calculated for Thumb1

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102 --- Comment #2 from bin.cheng 2013-01-25 07:25:34 UTC --- Created attachment 29270 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29270 correct test case The previous test case is not appropriate, because gcc won't split even with

[Bug rtl-optimization/56124] New: Redundant reload for loading from memory

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56124 Bug #: 56124 Summary: Redundant reload for loading from memory Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal

[Bug rtl-optimization/56124] Redundant reload for loading from memory

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56124 --- Comment #1 from bin.cheng 2013-01-28 02:43:10 UTC --- The root cause is in ira:scan_one_insn function. It decrease cost of memory for pseudo which are target of loading from memory: if (set != 0 && REG_P (SET_DEST (set)) && MEM_P

[Bug tree-optimization/56139] New: unmodified static data could go in .rodata, not .data

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56139 Bug #: 56139 Summary: unmodified static data could go in .rodata, not .data Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enh

[Bug target/53090] suboptimal ivopt

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53090 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #2

[Bug tree-optimization/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363 --- Comment #10 from bin.cheng --- Patch sent at http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00857.html , but it need to wait for stage 1. I will xfail it for now.

[Bug tree-optimization/60363] [4.9/4.10 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363 --- Comment #15 from bin.cheng --- Should be fixed now.

[Bug target/61367] New: Annoying rtx cost information in middle end dumps on arm/aarch64 targets

: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: amker.cheng at gmail dot com Created attachment 32877 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32877&action=edit zipped dump files. Given a simple progr

[Bug target/61411] [NEON] ICE in reload_cse_simplify_operands, at postreload.c:411

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61411 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot com

[Bug target/61411] [NEON] ICE in reload_cse_simplify_operands, at postreload.c:411

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61411 --- Comment #3 from bin.cheng --- Then I think it's a latent bug in LRA. It should consult back-end about legitimized address expressions.

[Bug tree-optimization/60280] New: gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c failed caused by preserving loop structure.

Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amker.cheng at gmail dot com gcc.target/arm/ivopts-2.c is like: /* { dg-do assemble } */ /* { dg-options "-Os -fdump-tree-ivopts -save-

[Bug tree-optimization/60280] gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c failed caused by preserving loop structure.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60280 --- Comment #1 from bin.cheng --- It's caused by patch at (revision r198333): http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01530.html After patching, forwarder basic block 6 in below dump didn't get removed: tr4 (short int * array, int n) { int

[Bug tree-optimization/60280] [4.9 Regression] gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c failed caused by preserving loop structure.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60280 --- Comment #3 from bin.cheng --- I think 4_8 is ok for this case. At least it doesn't have http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01530.html committed if I was right.

[Bug tree-optimization/60280] [4.9 Regression] gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c failed caused by preserving loop structure.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60280 bin.cheng changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug regression/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363 bin.cheng changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #2

[Bug regression/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363 --- Comment #3 from bin.cheng --- After patching 208165, there are two more jump threading opportunities for dom1 pass. Jump threading is doing alright, the interesting thing is why there is no such opportunities before patching. I attatched rel

[Bug regression/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363 --- Comment #4 from bin.cheng --- Although may be irrelavant. I found loop's latch doesn't get updated after removing the forwarder latch basic block. Previous patch only catches function remove_forwarder_block, but remove_forwarder_block_with_p

[Bug regression/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363 --- Comment #5 from bin.cheng --- Vrp1 generates below code: : if (b_elt_11(D) != 0B) goto ; else goto ; : # kill_elt_10 = PHI goto ; : kill_elt_14 = kill_elt_2->next; : # kill_elt_2 = PHI if (kill_elt_2 != 0B)

  1   2   >