[Bug rtl-optimization/42575] arm-eabi-gcc 64-bit multiply weirdness
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2010-08-18 10:34 --- Subject: Bug 42575 Author: mkuvyrkov Date: Wed Aug 18 10:34:02 2010 New Revision: 163334 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163334 Log: gcc/ PR rtl-optimization/42575 * optabs.c (expand_doubleword_mult): Generate new pseudos to shorten live ranges. gcc/testsuite/ PR rtl-optimization/42575 * gcc.target/pr42575.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr42575.c Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575
[Bug rtl-optimization/42575] arm-eabi-gcc 64-bit multiply weirdness
--- Comment #8 from mkuvyrkov at gcc dot gnu dot org 2010-08-18 10:43 --- Bernd did all the heavy lifting for this patch. The above patch fixes the last piece of the problem -- extra move when compiling for ARMv7-A. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575
[Bug middle-end/45097] ICE: gimple check: expected gimple_assign(error_mark), have gimple_phi() in gimple_assign_lhs, at gimple.h:1724
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 08:11 --- Ramana, I confirmed that your patch fixes this PR moments before you posted you comment. It's a dup of 45067. *** This bug has been marked as a duplicate of 45067 *** -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45097
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 08:11 --- *** Bug 45097 has been marked as a duplicate of this bug. *** -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added CC||jingyu at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug tree-optimization/45101] [4.6 Regression] ICE: in insert_expr_in_table, at gcse.c:1213 with -gcse-las
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 10:03 --- This is due to a silly mistake of mine. I got operand ordering of insert_expr_in_table() wrong for -fgcse-las case. Will check in an obvious patch in several minutes. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-28 10:03:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45101
[Bug rtl-optimization/45101] [4.6 Regression] ICE: in insert_expr_in_table, at gcse.c:1213 with -gcse-las
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 10:10 --- Subject: Bug 45101 Author: mkuvyrkov Date: Wed Jul 28 10:09:53 2010 New Revision: 162622 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162622 Log: PR rtl-optimization/45101 * gcse.c (hash_scan_set): Fix argument ordering of insert_expr_in_table for gcse-las. Modified: trunk/gcc/ChangeLog trunk/gcc/gcse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45101
[Bug rtl-optimization/45101] [4.6 Regression] ICE: in insert_expr_in_table, at gcse.c:1213 with -gcse-las
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 10:14 --- Should be fixed by the above patch. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45101
[Bug rtl-optimization/45101] [4.6 Regression] ICE: in insert_expr_in_table, at gcse.c:1213 with -gcse-las
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 10:32 --- Done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45101
[Bug rtl-optimization/45101] [4.6 Regression] ICE: in insert_expr_in_table, at gcse.c:1213 with -gcse-las
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 10:32 --- Subject: Bug 45101 Author: mkuvyrkov Date: Wed Jul 28 10:32:10 2010 New Revision: 162623 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162623 Log: PR rtl-optimization/45101 * gcc.dg/pr45101.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr45101.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45101
[Bug rtl-optimization/45107] [4.6 Regression] ICE: in insert_expr_in_table, at gcse.c:1213 with -Os -gcse-las (another one)
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 14:25 --- Mine. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-28 14:25:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45107
[Bug bootstrap/45104] [4.6 Regression] Bootstrap failure: gcc/cp/decl.o differs
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 16:01 --- Can you please try the latest trunk with the patch in http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02185.html applied? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45104
[Bug rtl-optimization/45107] [4.6 Regression] ICE: in insert_expr_in_table, at gcse.c:1213 with -Os -gcse-las (another one)
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 16:14 --- Patch posted in http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02192.html . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45107
[Bug rtl-optimization/45107] [4.6 Regression] ICE: in insert_expr_in_table, at gcse.c:1213 with -Os -gcse-las (another one)
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 16:50 --- Subject: Bug 45107 Author: mkuvyrkov Date: Wed Jul 28 16:50:14 2010 New Revision: 162645 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162645 Log: PR rtl-optimization/45107 * gcse.c (hash_scan_set): Use max_distance for gcse-las. PR rtl-optimization/45107 * gcc.dg/pr45107.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr45107.c Modified: trunk/gcc/ChangeLog trunk/gcc/gcse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45107
[Bug bootstrap/45104] [4.6 Regression] Bootstrap failure: gcc/cp/decl.o differs
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 16:51 --- Thanks for checking. *** This bug has been marked as a duplicate of 45105 *** -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45104
[Bug debug/45105] [4.6 Regression] -fcompare-debug failure at -Os
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 16:51 --- *** Bug 45104 has been marked as a duplicate of this bug. *** -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45105
[Bug rtl-optimization/45107] [4.6 Regression] ICE: in insert_expr_in_table, at gcse.c:1213 with -Os -gcse-las (another one)
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2010-07-28 16:52 --- Should be fixed by the above patch. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45107
[Bug target/42495] redundant memory load
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:35 --- Subject: Bug 42495 Author: mkuvyrkov Date: Tue Jul 27 19:34:55 2010 New Revision: 162590 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162590 Log: PR rtl-optimization/40956 PR target/42495 PR middle-end/42574 * gcse.c (compute_code_hoist_vbeinout): Consider more expressions for hoisting. (hoist_code): Count occurences in current block too. Modified: trunk/gcc/ChangeLog trunk/gcc/gcse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
[Bug rtl-optimization/40956] Constants are never candidates for hoisting
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:35 --- Subject: Bug 40956 Author: mkuvyrkov Date: Tue Jul 27 19:34:55 2010 New Revision: 162590 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162590 Log: PR rtl-optimization/40956 PR target/42495 PR middle-end/42574 * gcse.c (compute_code_hoist_vbeinout): Consider more expressions for hoisting. (hoist_code): Count occurences in current block too. Modified: trunk/gcc/ChangeLog trunk/gcc/gcse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40956
[Bug middle-end/42574] [4.3/4.4/4.5/4.6 Regression] Address of global variable is calculated multiple times (missed CSE)
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:35 --- Subject: Bug 42574 Author: mkuvyrkov Date: Tue Jul 27 19:34:55 2010 New Revision: 162590 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162590 Log: PR rtl-optimization/40956 PR target/42495 PR middle-end/42574 * gcse.c (compute_code_hoist_vbeinout): Consider more expressions for hoisting. (hoist_code): Count occurences in current block too. Modified: trunk/gcc/ChangeLog trunk/gcc/gcse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574
[Bug middle-end/42574] [4.3/4.4/4.5/4.6 Regression] Address of global variable is calculated multiple times (missed CSE)
--- Comment #12 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:38 --- Subject: Bug 42574 Author: mkuvyrkov Date: Tue Jul 27 19:38:10 2010 New Revision: 162592 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162592 Log: PR target/42495 PR middle-end/42574 * gcse.c (hoist_expr_reaches_here_p): Remove excessive check. Modified: trunk/gcc/ChangeLog trunk/gcc/gcse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574
[Bug target/42495] redundant memory load
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:38 --- Subject: Bug 42495 Author: mkuvyrkov Date: Tue Jul 27 19:38:10 2010 New Revision: 162592 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162592 Log: PR target/42495 PR middle-end/42574 * gcse.c (hoist_expr_reaches_here_p): Remove excessive check. Modified: trunk/gcc/ChangeLog trunk/gcc/gcse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
[Bug target/42495] redundant memory load
--- Comment #8 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:42 --- Subject: Bug 42495 Author: mkuvyrkov Date: Tue Jul 27 19:42:15 2010 New Revision: 162594 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162594 Log: PR target/42495 PR middle-end/42574 * config/arm/arm.c (thumb1_size_rtx_costs): Add cost for J constants. * config/arm/arm.md (define_split J, define_split K): Make IRA/reload friendly. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
[Bug middle-end/42574] [4.3/4.4/4.5/4.6 Regression] Address of global variable is calculated multiple times (missed CSE)
--- Comment #13 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:42 --- Subject: Bug 42574 Author: mkuvyrkov Date: Tue Jul 27 19:42:15 2010 New Revision: 162594 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162594 Log: PR target/42495 PR middle-end/42574 * config/arm/arm.c (thumb1_size_rtx_costs): Add cost for J constants. * config/arm/arm.md (define_split J, define_split K): Make IRA/reload friendly. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574
[Bug target/42495] redundant memory load
--- Comment #9 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:45 --- Subject: Bug 42495 Author: mkuvyrkov Date: Tue Jul 27 19:44:51 2010 New Revision: 162595 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162595 Log: PR target/42495 PR middle-end/42574 * config/arm/arm.c (legitimize_pic_address): Use gen_calculate_pic_address pattern to emit calculation of PIC address. (will_be_in_index_register): New function. (arm_legitimate_address_outer_p, thumb2_legitimate_address_p,) (thumb1_legitimate_address_p): Use it provided !strict_p. * config/arm/arm.md (calculate_pic_address): New expand and split. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
[Bug middle-end/42574] [4.3/4.4/4.5/4.6 Regression] Address of global variable is calculated multiple times (missed CSE)
--- Comment #14 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:45 --- Subject: Bug 42574 Author: mkuvyrkov Date: Tue Jul 27 19:44:51 2010 New Revision: 162595 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162595 Log: PR target/42495 PR middle-end/42574 * config/arm/arm.c (legitimize_pic_address): Use gen_calculate_pic_address pattern to emit calculation of PIC address. (will_be_in_index_register): New function. (arm_legitimate_address_outer_p, thumb2_legitimate_address_p,) (thumb1_legitimate_address_p): Use it provided !strict_p. * config/arm/arm.md (calculate_pic_address): New expand and split. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574
[Bug rtl-optimization/40956] Constants are never candidates for hoisting
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:46 --- Subject: Bug 40956 Author: mkuvyrkov Date: Tue Jul 27 19:46:26 2010 New Revision: 162596 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162596 Log: PR rtl-optimization/40956 * config/arm/arm.c (thumb1_size_rtx_costs): Fix cost of simple constants. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40956
[Bug target/42495] redundant memory load
--- Comment #10 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:48 --- Subject: Bug 42495 Author: mkuvyrkov Date: Tue Jul 27 19:48:15 2010 New Revision: 162597 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162597 Log: PR target/42495 PR middle-end/42574 * basic-block.h (get_dominated_to_depth): Declare. * dominance.c (get_dominated_to_depth): New function, use get_all_dominated_blocks as a base. (get_all_dominated_blocks): Use get_dominated_to_depth. * gcse.c (occr_t, VEC (occr_t, heap)): Define. (hoist_exprs): Remove. (alloc_code_hoist_mem, free_code_hoist_mem): Update. (compute_code_hoist_vbeinout): Add debug print outs. (hoist_code): Partially rewrite, simplify. Use get_dominated_to_depth. * params.def (PARAM_MAX_HOIST_DEPTH): New parameter to avoid quadratic behavior. * params.h (MAX_HOIST_DEPTH): New macro. * doc/invoke.texi (max-hoist-depth): Document. Modified: trunk/gcc/ChangeLog trunk/gcc/basic-block.h trunk/gcc/doc/invoke.texi trunk/gcc/dominance.c trunk/gcc/gcse.c trunk/gcc/params.def trunk/gcc/params.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
[Bug middle-end/42574] [4.3/4.4/4.5/4.6 Regression] Address of global variable is calculated multiple times (missed CSE)
--- Comment #15 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:48 --- Subject: Bug 42574 Author: mkuvyrkov Date: Tue Jul 27 19:48:15 2010 New Revision: 162597 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162597 Log: PR target/42495 PR middle-end/42574 * basic-block.h (get_dominated_to_depth): Declare. * dominance.c (get_dominated_to_depth): New function, use get_all_dominated_blocks as a base. (get_all_dominated_blocks): Use get_dominated_to_depth. * gcse.c (occr_t, VEC (occr_t, heap)): Define. (hoist_exprs): Remove. (alloc_code_hoist_mem, free_code_hoist_mem): Update. (compute_code_hoist_vbeinout): Add debug print outs. (hoist_code): Partially rewrite, simplify. Use get_dominated_to_depth. * params.def (PARAM_MAX_HOIST_DEPTH): New parameter to avoid quadratic behavior. * params.h (MAX_HOIST_DEPTH): New macro. * doc/invoke.texi (max-hoist-depth): Document. Modified: trunk/gcc/ChangeLog trunk/gcc/basic-block.h trunk/gcc/doc/invoke.texi trunk/gcc/dominance.c trunk/gcc/gcse.c trunk/gcc/params.def trunk/gcc/params.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574
[Bug middle-end/42574] [4.3/4.4/4.5/4.6 Regression] Address of global variable is calculated multiple times (missed CSE)
--- Comment #16 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 21:06 --- Subject: Bug 42574 Author: mkuvyrkov Date: Tue Jul 27 21:06:31 2010 New Revision: 162600 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162600 Log: PR rtl-optimization/40956 PR target/42495 PR middle-end/42574 * gcc.target/arm/pr40956.c, gcc.target/arm/pr42495.c, * gcc.target/arm/pr42574.c: Add tests. Added: trunk/gcc/testsuite/gcc.target/arm/pr40956.c trunk/gcc/testsuite/gcc.target/arm/pr42495.c trunk/gcc/testsuite/gcc.target/arm/pr42574.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574
[Bug rtl-optimization/40956] Constants are never candidates for hoisting
--- Comment #8 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 21:06 --- Subject: Bug 40956 Author: mkuvyrkov Date: Tue Jul 27 21:06:31 2010 New Revision: 162600 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162600 Log: PR rtl-optimization/40956 PR target/42495 PR middle-end/42574 * gcc.target/arm/pr40956.c, gcc.target/arm/pr42495.c, * gcc.target/arm/pr42574.c: Add tests. Added: trunk/gcc/testsuite/gcc.target/arm/pr40956.c trunk/gcc/testsuite/gcc.target/arm/pr42495.c trunk/gcc/testsuite/gcc.target/arm/pr42574.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40956
[Bug target/42495] redundant memory load
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 21:06 --- Subject: Bug 42495 Author: mkuvyrkov Date: Tue Jul 27 21:06:31 2010 New Revision: 162600 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162600 Log: PR rtl-optimization/40956 PR target/42495 PR middle-end/42574 * gcc.target/arm/pr40956.c, gcc.target/arm/pr42495.c, * gcc.target/arm/pr42574.c: Add tests. Added: trunk/gcc/testsuite/gcc.target/arm/pr40956.c trunk/gcc/testsuite/gcc.target/arm/pr42495.c trunk/gcc/testsuite/gcc.target/arm/pr42574.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
[Bug rtl-optimization/40956] Constants are never candidates for hoisting
--- Comment #9 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 21:10 --- Should be fixed now by the above patch series. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40956
[Bug target/42495] redundant memory load
--- Comment #12 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 21:11 --- Should be fixed now by the above patch series. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
[Bug middle-end/42574] [4.3/4.4/4.5/4.6 Regression] Address of global variable is calculated multiple times (missed CSE)
--- Comment #17 from mkuvyrkov at gcc dot gnu dot org 2010-07-27 21:11 --- Should be fixed now by the above patch series. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574
[Bug middle-end/45015] New: ICE in cselib.c caused by fix for PR43051
The fix for PR43051 causes ICE when building GLIBC for ColdFire Linux. The problem was made latent on trunk by the fix for PR44492 (rev. 161328). It doesn't look like this patch fixes the underlying problem, but I may be wrong. Jacub, Do you think the fix for PR44492 legitimately fixes the ICE? To reproduce: 1. Revert rev. 161328 from trunk or revert to rev. 161327 2. Configure the compiler with $ .../configure --target=m68k-linux-gnu --with-arch=cf --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c --enable-shared --enable-lto --enable-symvers=gnu --enable-__cxa_atexit --disable-nls --enable-libgomp 3. $ .../cc1 ~/tmp/addmul_1.i -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-unwind-tables -g -o ~/tmp/addmul_1.s ... addmul_1.c: In function '__mpn_addmul_1': addmul_1.c:65:1: internal compiler error: in cselib_record_set, at cselib.c:2000 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE in cselib.c caused by fix for PR43051 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mkuvyrkov at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: m68k-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45015
[Bug middle-end/45015] ICE in cselib.c caused by fix for PR43051
--- Comment #1 from mkuvyrkov at gcc dot gnu dot org 2010-07-21 07:20 --- Created an attachment (id=21276) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21276action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45015
[Bug debug/45015] ICE in cselib.c caused by fix for PR43051
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2010-07-21 17:58 --- Created an attachment (id=21280) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21280action=view) Testcase for patch Thanks for looking into this problem! The patch fixes the original testcase but causes a segmentation fault when compiling libgcc. .../cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mcpu=54455 -auxbase-strip _muldi3.o -g -g -g -O2 -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fPIC -fvisibility=hidden -fremove-local-statics -o libgcc2.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45015
[Bug rtl-optimization/40956] Constants are never candidates for hoisting
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2010-06-19 19:57 --- I'm working on this bug among other improvements to RTL hoist pass. My plan is to enable hoisting of such simple constants, but only on very short distances, like 3-5 instructions, tunable through a new parameter. Targets like x86 can disable simple constant hoisting altogether, while targets like ARM would be able to enable it when optimizing for size. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-03-19 18:39:40 |2010-06-19 19:57:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40956
[Bug bootstrap/44456] [4.6 Regression] bootstrap fails on mips-linux CHOOSE_DYNAMIC_LINKER macro
--- Comment #1 from mkuvyrkov at gcc dot gnu dot org 2010-06-16 08:31 --- Fixed in revision 160824. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44456
[Bug target/42495] redundant memory load
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2010-06-08 10:41
---
Elimination of subsequent calculations of PIC addresses should be handled in
code hoisting optimization.
However, there are two problems that inhibit the optimization:
1. ARM backend outputs calculation of a PIC address as two instructions (load
GOT offset from constant pool and then load PIC address from GOT) and hoist
only handles expressions contained in a single_set().
2. Hoisting algorithm misses many opportunities for expression hoisting to
basic blocks that contain calculation of the expression. I.e., expr from bb4
will not be hoisted to bb2 even though it is trivially profitable:
bb2:
expr
condjump bb4
bb3:
no expr
jump bb5
bb4:
expr
bb5:
I'm testing patches to the ARM backend and code hoisting pass which fix the
above problems. The generated code calculates address of the global variable
only once:
goo:
push{r3, r4, r5, lr}
ldr r3, .L6
ldr r2, .L6+4
.LPIC0:
add r3, pc
ldr r5, [r3, r2]
mov r4, r0
ldr r3, [r5]
ldr r0, [r3]
cmp r0, #0
beq .L2
mov r1, r4
bl foo
.L2:
ldr r3, [r4]
mov r0, #0
cmp r3, #0
beq .L3
ldr r2, [r5]
cmp r3, r2
beq .L3
ldr r0, [r3]
.L3:
@ sp needed for prologue
pop {r3, r4, r5, pc}
.L7:
.align 2
.L6:
.word _GLOBAL_OFFSET_TABLE_-(.LPIC0+4)
.word gObj(GOT)
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot
|dot org |org
Status|WAITING |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-06-08 10:41:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
[Bug middle-end/42574] [4.3/4.4/4.5/4.6 Regression] Address of global variable is calculated multiple times (missed CSE)
--- Comment #10 from mkuvyrkov at gcc dot gnu dot org 2010-06-08 15:24
---
Steven, I'm shamelessly stealing this PR from you.
There are two sides to this missed optimization:
1. Calculation of PIC address is not CSE'd; this is the same as PR42495 and
will be fixed there.
2. Constant 400, which expands to 2 instructions is not CSE'd.
After addressing the first issue, the second problem can be fixed by asking
hoist to CSE complicated constants and making sure that RA will rematerialize
them instead of spilling under high register pressure.
We can define a constant complicated if it takes a PARALLEL -- (parallel
[(set (reg1) (const)) (clobber reg2)]) -- to set it; this is a common way of
defining instructions that should be split later and require a temporary
register to hold intermediate value.
I'm now testing a patch that makes ARM backend to expand constants into
parallels instead of sequences of two instructions and tweaking hoist to gcse
complicated const_int's.
The result is the following:
test:
push{r4, r5, r6, lr}
ldr r3, .L3
ldr r2, .L3+4
.LPIC0:
add r3, pc
ldr r5, [r3, r2]
mov r4, #200
lsl r4, r4, #1
mov r6, r0
ldr r0, [r5, r4]
bl func1
ldr r0, [r5, r4]
mov r1, r6
bl func2
cmp r0, #0
beq .L2
bl func
.L2:
ldr r0, [r5, r4]
bl func3
@ sp needed for prologue
pop {r4, r5, r6, pc}
.L4:
.align 2
.L3:
.word _GLOBAL_OFFSET_TABLE_-(.LPIC0+4)
.word glob(GOT)
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |mkuvyrkov at gcc dot gnu dot
|org |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574
[Bug bootstrap/44314] Powerpc64-unknown-linux-gnu bootstrap broken
--- Comment #1 from mkuvyrkov at gcc dot gnu dot org 2010-05-28 15:03 --- Subject: Bug 44314 Author: mkuvyrkov Date: Fri May 28 15:03:23 2010 New Revision: 159978 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159978 Log: PR bootstrap/44314 * config/alpha/linux.h, config/rs6000/linux.h, config/rs6000/linux64.h (OPTION_GLIBC): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/linux.h trunk/gcc/config/rs6000/linux.h trunk/gcc/config/rs6000/linux64.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44314
[Bug bootstrap/44314] Powerpc64-unknown-linux-gnu bootstrap broken
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2010-05-28 15:04 --- Fixed in rev. 159978. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44314
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #21 from mkuvyrkov at gcc dot gnu dot org 2010-05-05 20:28 --- Dominique, Have you been able to identify if there is an invalid optimization? It seems using -ffast-math -ffinite-math-only is very error-prone. -ffast-math implies -fassociative-math, which can generate NaNs, and -ffinite-math-only can further worsen the precision by additional optimizations. It may not be obvious to a casual GCC user that -ffinite-math-only gives more freedom to the optimization passes, not restricts the compiler to keep all math finite. FYI, -fassociative-math Allow re-association of operands in series of floating-point operations. This violates the ISO C and C++ language standard by possibly changing computa- tion result. NOTE: re-ordering may change the sign of zero as well as ignore NaNs and inhibit or create underflow or overflow (and thus cannot be used on a code which relies on rounding behavior like (x + 2**52) - 2**52). May also reorder floating-point comparisons and thus may not be used when ordered comparisons are required. This option requires that both -fno-signed-zeros and -fno-trapping-math be in effect. Moreover, it doesnt make much sense with -frounding-math. For Fortran the option is automatically enabled when both -fno-signed-zeros and -fno-trapping-math are in effect. The default is -fno-associative-math. ... -ffinite-math-only Allow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs. This option is not turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications. The default is -fno-finite-math-only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2010-05-02 18:02 --- Created an attachment (id=20536) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20536action=view) Revert previous patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804
[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands
--- Comment #12 from mkuvyrkov at gcc dot gnu dot org 2010-05-02 18:03 --- Ping. Richard S., Andreas, Any comment on the above analysis? AFAICT, the T constraint should accept operands if flag_pic !TARGET_PCREL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804
[Bug rtl-optimization/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands
--- Comment #10 from mkuvyrkov at gcc dot gnu dot org 2010-04-23 10:20 --- The problem seems to be in Richard's patch (http://article.gmane.org/gmane.comp.gcc.patches/130602) checked in r120961. All and all, it seems that revision 120961 should be reverted to enable 'T' constraint for (flag_pic !TARGET_PCREL). The 's' constraint is defined as == case 's': if (CONST_INT_P (op) || (GET_CODE (op) == CONST_DOUBLE GET_MODE (op) == VOIDmode)) break; case 'i': if (CONSTANT_P (op)) win = 1; break; == So, unless I'm missing something, the statement ... 's' doesn't accept anything if flag_pic is just wrong. FYI, the story behind 'T' constraint is described in comment in r27576: + In parallel with these new predicates, two new constraint letters + were defined: 'S' and 'T'. 'S' is the -mpcrel analog of 'm'. + 'T' replaces 's' in the non-pcrel case. It is a no-op in the pcrel case. + In the pcrel case 's' is only valid in combination with 'a' registers. + See addsi3, subsi3, cmpsi, and movsi patterns for a better understanding + of how these constraints are used. + ... + All of the ugliness with predicates and constraints is due to the + simple fact that the m68k does not allow a pc-relative addressing + mode as a destination. gcc does not distinguish between source and + destination addresses. Hence, if we claim that pc-relative address + modes are valid, e.g. GO_IF_LEGITIMATE_ADDRESS accepts them, then we + end up with invalid code. To get around this problem, we left + pc-relative modes as invalid addresses, and then added special + predicates and constraints to accept them. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added CC||rdsandiford at googlemail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804
[Bug rtl-optimization/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2010-04-21 10:47 --- There are two problems here: 1. The immediate problem is that movsi_m68k doesn't allow (const) to be moved to data register (see last alternative if movsi_m68k). 2. For reason, which I have not yet investigated, no alternative in addsi_internal match (set (reg) (plus (reg %a5) (const (unspec Andreas, do you know why movsi_m68k doesn't allow data register in the last alternative? (define_insn *movsi_m68k [(set (match_operand:SI 0 nonimmediate_operand =g,d,a) (match_operand:SI 1 general_src_operand damSnT,n,i))] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #13 from mkuvyrkov at gcc dot gnu dot org 2010-04-13 19:32 --- The SIGSEGV is due to -funsafe-math-optimizations being used with code like: == Re = eps*debm*DIAhy/(vis*sec) reo = Re IF ( Re.LT.1000. ) THEN i1 = INT(Re/200.) + 1 ELSEIF ( Re.LT.4000. ) THEN i1 = INT(Re/500.) + 4 ELSEIF ( Re.LT.1. ) THEN i1 = INT(Re/2000.) + 10 ELSEIF ( Re.GE.3. ) THEN IF ( Re.GE.4. ) Re = 4.D+00 i1 = INT(Re/1.) + 16 ELSE i1 = INT(Re/5000.) + 13 ENDIF i2 = i1 + 1 y1 = y(i1) y2 = y(i2) == Here we have index `i1' calculated from fp values and then casted to int. Segmentation fault occurs in `y1 = y(i1)' with i1 equal to 0x800c. This is in function S00061 in doduc_red.f90, not in s33022.f90. Also, to trigger the SIGSEGV it is necessary to compile both doduc_red.f90 and s33022.f90 with -O3 -funsafe-math-optimizations -ffinite-math-only. If either of the modules is compiled with -O2 the SIGSEGV does not occur. While I will not argue that my patch is 100% bug-free, this seems to be an invalid testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #14 from mkuvyrkov at gcc dot gnu dot org 2010-04-13 20:01 --- (In reply to comment #10) - D.1850_209 = -alt_90; - D.2093_151 = -alb_86; - D.1849_208 = D.1848_207 - alb_86; + D.2093_151 = -alt_90; + D.1849_208 = D.1848_207 - alt_90; D.1851_210 = D.1849_208 + -1.0e+0; - z1a_211 = D.1851_210 + D.1850_209; + D.2094_497 = -alb_86; + z1a_211 = D.1851_210 - alb_86; this doesn't look like an identity transform. You have to be careful with non-single use vars and make sure they do not end up on a reassociation chain. Though it does look fishy, this transformation is OK. In fact, the compiler oscillates a couple of times between using `-alb_86' and `-alt_90'. E.g., the before compiler does the following transformation during reassoc1: == - D.1849_208 = D.1848_207 - alb_86; + D.2045_228 = -alb_86; + D.1850_209 = -alt_90; + D.1849_208 = D.1848_207 + D.1850_209; == -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2010-04-12 16:38 --- Confirmed with mac os x gcc build. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-12 16:38:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2010-04-10 18:28 --- Would you please attach doduc.in so that I can reproduce this. == At line 161 of file /home/maxim/tmp/doduc_red.f90 (unit = 5, file = 'doduc.in') Fortran runtime error: End of file == Also, what is your configure line and with which exact parameters f951 gets invoked? (The compiler prints out the later if you add `-v' option to the command line). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #8 from mkuvyrkov at gcc dot gnu dot org 2010-04-10 19:20 --- Hm, I'm having hard time reproducing this on linux. Would you please attach dumps produced with -fdump-tree-reassoc for both before and after compilers. Thanks. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added CC|maxim at trivialbugs dot com|mkuvyrkov at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug middle-end/40815] redundant neg instruction caused by loop-invariant
--- Comment #10 from mkuvyrkov at gcc dot gnu dot org 2010-04-08 08:20 --- Subject: Bug 40815 Author: mkuvyrkov Date: Thu Apr 8 08:20:36 2010 New Revision: 158105 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158105 Log: PR middle-end/40815 * tree-ssa-reassoc.c (broken_up_substracts): Rename to plus_negates. (negate_value): Move code to push elements to broken_up_substracts ... (eliminate_plus_minus_pair): ... here. Push operands that have no negative pair to plus_negates. (repropagate_negates, init_reassoc, fini_reassoc): Update. PR middle-end/40815 * gcc.dg/tree-ssa/reassoc-19.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-19.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40815
[Bug middle-end/40815] redundant neg instruction caused by loop-invariant
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2010-04-08 08:31 --- Fixed in the above revision. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40815
[Bug target/43675] [m68k] Wrong code due to missing sign extension
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2010-04-07 16:06 --- Closing the PR. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43675
[Bug middle-end/40815] redundant neg instruction caused by loop-invariant
--- Comment #8 from mkuvyrkov at gcc dot gnu dot org 2010-03-11 08:57 --- Created an attachment (id=20080) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20080action=view) Fixed and tested patch Well, sure enough the initial patch had an error: `(-a) + (-b)' was getting optimized into `a + b' instead of (-a) - b. This new version was tested on x86_64 without regressions and fixes. Any comments before I post it to gcc-patches@ ? Thanks. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Attachment #20077|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40815
[Bug middle-end/40815] redundant neg instruction caused by loop-invariant
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2010-03-10 19:39
---
Created an attachment (id=20077)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20077action=view)
Proposed patch
Richard,
Thank you for the great pointers how to fix this bug. Here is the proposed
patch to fix it, I am now testing it on both x86_64 and ARM.
One thing I am not sure about in this patch is whether I am forgetting a check
before swapping the operands (to optimize `-a + b' into `b - a') -- is any
check needed for {PLUS, MINUS}_EXPR in this case?
Thank you.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40815
[Bug target/42516] [m68k] Suboptimal halfword swap on coldfire
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2009-12-27 20:05 --- Thanks for the bug report. I've posted a proposed patch in http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01142.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42516
[Bug target/36047] -pg does not work on large binaries and m68k
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2009-12-11 15:32 --- Subject: Bug 36047 Author: mkuvyrkov Date: Fri Dec 11 15:32:08 2009 New Revision: 155165 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155165 Log: 2009-12-11 Sebastian Andrzej Siewior bige...@linutronix.de PR target/36047 * config/m68k/linux.h: Remove LABELNO from the mcount statement. It is not used by glibc/uclibc and does not work with large binaries. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/linux.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36047
[Bug target/36047] -pg does not work on large binaries and m68k
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2009-12-11 15:35 --- This is now fixed with the above patch by Sebastian. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36047
[Bug target/36047] -pg does not work on large binaries and m68k
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2009-11-19 10:09 --- g...@breakpoint.cc, Would you please submit your patch to gcc-patc...@gcc.gnu.org. Only the linux.h version of FUNCTION_PROFILER causes problems, you can leave the m68k.h version as is. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36047
[Bug target/41302] Cast of return value from uint32 to pointer cannot be optimized by a jump to called rtn.
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2009-11-04 09:58 --- Subject: Bug 41302 Author: mkuvyrkov Date: Wed Nov 4 09:57:55 2009 New Revision: 153890 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153890 Log: 2009-11-04 Maxim Kuvyrkov ma...@codesourcery.com PR target/41302 * config/m68k/m68k.c (m68k_reg_present_p): New static function. (m68k_ok_for_sibcall_p): Handle different result return locations. 2009-11-04 Carlos O'Donell car...@codesourcery.com PR target/41302 * gcc.target/m68k/pr41302.c: New test. Added: trunk/gcc/testsuite/gcc.target/m68k/pr41302.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41302
[Bug target/41302] Cast of return value from uint32 to pointer cannot be optimized by a jump to called rtn.
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2009-11-04 11:47 --- Fixed. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41302
[Bug target/36047] -pg does not work on large binaries and m68k
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2009-11-04 16:57
---
It appears that 'lea' serves some compatibility purpose. The code is there
since 1995.
Recent GLIBC defines _mcount as
void
_mcount (void)
{
mcount_internal ((u_long)
__builtin_extract_return_addr (__builtin_return_address
(1)),
(u_long)
__builtin_extract_return_addr (__builtin_return_address
(0)));
}
so the value of %a1 is unused. Newlib and uClibc don't define _mcount for m68k
at all.
Andreas, I suggest simply removing the 'lea'; they seem to be no users for it.
Alternatively, for the !PIC case we may use 'lea label, %a1' (no pc-relative
relocation) and for the PIC case use a longer sequence, something like: 'move.l
#label@PC32, %a1\n add.l (-4, %pc), %a1'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36047
[Bug target/41302] Cast of return value from uint32 to pointer cannot be optimized by a jump to called rtn.
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2009-10-30 10:16 --- Patch posted at http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01790.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41302
[Bug target/36070] m68k/coldfire gcc build breaks due to sc_fpstate, sc_fpregs reference
--- Comment #1 from mkuvyrkov at gcc dot gnu dot org 2009-09-02 07:34 --- This is fixed on trunk. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36070
[Bug target/36070] m68k/coldfire gcc build breaks due to sc_fpstate, sc_fpregs reference
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2009-09-02 07:37 --- If you'd like to backport the fix, it is in revision http://gcc.gnu.org/viewcvs?view=revisionrevision=149663 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36070
[Bug middle-end/37053] [4.3/4.4/4.5 regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #15 from mkuvyrkov at gcc dot gnu dot org 2009-08-04 13:14 --- There are several (4, I think) patches posted in gcc-patches@ for this bug. A reload/recog maintainer is needed to choose the most appropriate one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
[Bug middle-end/37053] [4.3/4.4/4.5 regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #17 from mkuvyrkov at gcc dot gnu dot org 2009-08-04 13:43 --- I'll try the above two patches and will report in a couple of days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
[Bug middle-end/37053] [4.3/4.4/4.5 regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #13 from mkuvyrkov at gcc dot gnu dot org 2009-06-24 16:02 --- Created an attachment (id=18061) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18061action=view) Proposed patch Here is a patch moving precedence handling of pointers to powerpc backend. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
[Bug middle-end/37053] [4.3/4.4/4.5 regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #8 from mkuvyrkov at gcc dot gnu dot org 2009-06-23 11:39 --- (In reply to comment #6) But that was the meat of fixing PR28690. :-( The insn should satisfy the constraints of alternative 4. Well, not really. For the insn to match alternative 4 the pattern should be non-canonical. The last sentence in GCC Internals' canonicalization rules says: Further canonicalization rules are defined in the function commutative_operand_ precedence in gcc/rtlanal.c Unfortunately, commutative_operand_precendence() at the moment clearly states that a pointer (being that a MEM or a REG) has precedence over other RTX_OBJs. It is absolutely unclear to me why a pointer should have precedence over, say, multiplication or anything else (and yes, I've read PR28690). With my target-independent hat on, I would remove that PPC-specific hunk from commutative_operand_precendence() or, if that is really that important to PPC, add a new target hook so that different targets can enjoy privilege of defining that to whatever they seem fit. Adding such an obscure canonicalization rule for all targets seems unjustified. I'd like to get some feedback on the above before I start implementing new target hook to make all targets happy. Peter, I'm CCing you as the author of the commutative_operand_precendence() piece to get your opinion on the above. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added CC||mkuvyrkov at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
[Bug middle-end/37053] [4.3/4.4/4.5 regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #10 from mkuvyrkov at gcc dot gnu dot org 2009-06-23 12:26 --- (In reply to comment #9) But % makes it commutative, no? Yes, but that only means that the operands can be swapped *if* swap_commutative_operands_p() returns true. Due to the funny precedence that does not happen. So operand 2 matches operand 0, and operand 1 matches mSrIKLT. Matching procedures do not take commutativeness into account. Part of the problem are optimizations using commutativeness during reload. One way to paper over the issue is to forbid such optimizations during reload, but that may worsen code. And this approach is not as clean as letting backends decide if their .md files can handle funny canonicalization rules. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
[Bug middle-end/37053] [4.3/4.4/4.5 regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #12 from mkuvyrkov at gcc dot gnu dot org 2009-06-23 17:21 --- (In reply to comment #11) Still, I don't think a target hook is the solution. Even if it adds hack over hack, having the funny precedence rules only before reload could be a solution. For the record, I consider the hook to be a feature, the one which backends can use to tweak code generation, not a hack. At the moment, the precedence which favors pointers is a hack, but we cannot remove it due to powerpc being a important platform. Also, favoring the pointers may be useful for other similar to ppc platforms even if we are not aware of them right now. That said, conditioning the precedence on (!reload_in_progress !reload_completed) fixes the bug so I consider this to be the second best thing to a hook. It is not as good as a hook because there may be corner cases during reload when pointers should be favored on powerpc (multi-dimension array references, probably). On the other hand m68k need unrestricted (in the sense that all RTX_OBJ are the same) commutativeness during reload to avoid ICEs. So, conditioning pointer precedence on reload_in_progress has possible performance degradation on powerpc on one hand and ICE on m68k on the other. I'm pretty sure that we are talking about two different things. :-) Err, I don't fully follow you here. What are the two different things? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
[Bug bootstrap/40320] [4.5 Regression] Revision 148039 caused ICE: in extract_insn, at recog.c:2078
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2009-06-01 14:50 --- I've reverted the patch that caused the bootstrap failure. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40320
[Bug target/36047] -pg does not work on large binaries and m68k
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2009-03-16 11:35 --- Would you please attach a preprocessed testcase so one can reproduce the problem. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added CC||mkuvyrkov at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36047
[Bug target/35018] [m68k-elf] Gcc ouputs invalid asm when compiling with -O2 or higher
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2008-12-29 19:27 --- This is fixed only on trunk; 4.3 still has the bug. Do you think it's appropriate to close it anyway? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35018
[Bug target/37680] ICE: unable to generate reloads for: (insn:QI
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2008-12-12 11:31 --- Sorry, I've closed this bug hastily though the bug is not fixed 4.3 branch; the patch I was reffering to was only committed to trunk. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37680
[Bug target/37680] ICE: unable to generate reloads for: (insn:QI
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2008-12-12 11:28 --- This was fixed on trunk, presumably by IRA. I've also checked a clean up patch that fixed this failure on 4.3. See http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01031.html. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37680
[Bug target/35018] [m68k-elf] Gcc ouputs invalid asm when compiling with -O2 or higher
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2008-11-24 17:56 --- Subject: Bug 35018 Author: mkuvyrkov Date: Mon Nov 24 17:55:35 2008 New Revision: 142161 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142161 Log: PR target/35018 * config/m68k/m68k.md (ok_for_coldfire, enabled): New attributes. (addsi_lshrsi_31): Add ColdFire-friendly alternatives. * gcc.target/m68k/pr35018.c: New. Added: trunk/gcc/testsuite/gcc.target/m68k/pr35018.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35018
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #25 from mkuvyrkov at gcc dot gnu dot org 2008-08-06 06:25 --- Subject: Bug 35659 Author: mkuvyrkov Date: Wed Aug 6 06:23:47 2008 New Revision: 138759 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138759 Log: PR target/35659 * haifa-sched.c (sched_insn_is_legitimate_for_speculation_p): Move ... * sched-deps.c (sched_insn_is_legitimate_for_speculation_p): ... here. Don't allow predicated instructions for data speculation. * sched-int.h (sched_insn_is_legitimate_for_speculation_p): Move declaration. Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c trunk/gcc/sched-deps.c trunk/gcc/sched-int.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #26 from mkuvyrkov at gcc dot gnu dot org 2008-08-06 06:36 --- Subject: Bug 35659 Author: mkuvyrkov Date: Wed Aug 6 06:34:18 2008 New Revision: 138762 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138762 Log: Backport from mainline: 2008-08-06 Maxim Kuvyrkov [EMAIL PROTECTED] PR target/35659 * haifa-sched.c (sched_insn_is_legitimate_for_speculation_p): Move ... * sched-deps.c (sched_insn_is_legitimate_for_speculation_p): ... here. Don't allow predicated instructions for data speculation. * sched-int.h (sched_insn_is_legitimate_for_speculation_p): Move declaration. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/haifa-sched.c branches/gcc-4_3-branch/gcc/sched-deps.c branches/gcc-4_3-branch/gcc/sched-int.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #27 from mkuvyrkov at gcc dot gnu dot org 2008-08-06 06:38 --- Should be fixed on both trunk and 4_3-branch. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #23 from mkuvyrkov at gcc dot gnu dot org 2008-08-02 18:15 --- (In reply to comment #22) Maxim, have you had time to look at this bug? Given that it is generating bad code and is in 4.3.0 and 4.3.1 I was wondering if it will be fixed for 4.3.2. Sorry for the delay. I posted the fix at http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00112.html. I would appreciate if someone could test the cumulative patch of three fixes for ia64 speculation support or provide a single-file executable testcase for this bug. Here are links to two other bugfixes for ia64 speculation support: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00110.html http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00111.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #21 from mkuvyrkov at gcc dot gnu dot org 2008-06-26 09:23 --- Assign to self -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-06-24 15:04:50 |2008-06-26 09:23:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #16 from mkuvyrkov at gcc dot gnu dot org 2008-06-25 21:33 --- I can't reproduce the error with today mainline. When I put in one file 'PROGRAM PR35659' and 'SUBROUTINE TLSC (A,B,AUX,IPIV,EPS,X)' and compile it with any optimization level I get the same STOP 0 message. Am I doing something wrong? I can't spot the problem in the dumps you posted at debian.org. tlsc.s has a single example of data speculation which seems to be fine. Scheduler speculatively moves ld4.a r18 = [r44] before st4 [r59] = r14, -60 and then also speculates several uses of r18: cmp4.ge p6, p7 = r22, r18 ... (p7) ld4 r14 = [r62] ... (p7) st4 [r77] = r14 then it checks the speculation: chk.a.clr r18, .L69 and recovers if speculation failed: .L69: .mmi ld4 r18 = [r44] ;; cmp4.ge p6, p7 = r22, r18 nop 0 ;; .mmi nop 0 (p7) ld4 r14 = [r62] nop 0 ;; .mib (p7) st4 [r77] = r14 nop 0 br .L70 Anyway, can you help me reproduce the issue, so I can take a closer look? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug middle-end/34688] [4.1/4.2] ICE: output_operand: invalid expression as operand
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2008-03-25 15:26 --- Subject: Bug 34688 Author: mkuvyrkov Date: Tue Mar 25 15:25:37 2008 New Revision: 133521 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133521 Log: Backport from mainline: PR middle-end/34688 * final.c (output_addr_const): Handle TRUNCATE. PR middle-end/34688 * gcc.c-torture/compile/pr34688: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/compile/pr34688.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/final.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34688
[Bug middle-end/34688] [4.1/4.2] ICE: output_operand: invalid expression as operand
--- Comment #8 from mkuvyrkov at gcc dot gnu dot org 2008-03-25 15:26 --- Fixed on 4.2 as well. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34688
[Bug middle-end/34688] [4.1/4.2] ICE: output_operand: invalid expression as operand
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2008-01-27 18:47 --- Fixed in the above revision. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34688
[Bug middle-end/34688] [4.1/4.2] ICE: output_operand: invalid expression as operand
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2008-01-27 21:32 --- Right, sorry. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34688
[Bug middle-end/34688] [4.1/4.2] ICE: output_operand: invalid expression as operand
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2008-01-26 23:09 --- Subject: Bug 34688 Author: mkuvyrkov Date: Sat Jan 26 23:08:54 2008 New Revision: 131878 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131878 Log: PR middle-end/34688 * final.c (output_addr_const): Handle TRUNCATE. * gcc.c-torture/compile/pr34688: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr34688.c Modified: trunk/gcc/ChangeLog trunk/gcc/final.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34688
[Bug middle-end/34688] [4.1/4.2] ICE: output_operand: invalid expression as operand
-- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added CC||mkuvyrkov at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-07 14:04:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34688
[Bug target/33133] [4.3 Regression] ICE in try_ready, at haifa-sched.c:2958 with -O2/-O3
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2007-10-15 10:30 --- Subject: Bug 33133 Author: mkuvyrkov Date: Mon Oct 15 10:30:13 2007 New Revision: 129315 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129315 Log: PR target/33133 * haifa-sched.c (process_insn_forw_deps_be_in_spec): Check if speculation type of insn can be changed before trying to do that. * gcc.c-torture/compile/pr33133.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr33133.c Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33133
[Bug target/33133] [4.3 Regression] ICE in try_ready, at haifa-sched.c:2958 with -O2/-O3
--- Comment #8 from mkuvyrkov at gcc dot gnu dot org 2007-10-15 10:43 --- (In reply to comment #4) Confirmed. We see this a lot (building xgl, cups, john, xpdf, metacity, openssl and more). And just with -O2 in our cases. Are these failures fixed now? -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33133
[Bug target/31508] Error during compilation with flag -fschedule-insns
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2007-05-31 08:53 --- As mentioned by Andrew this is known issue. *** This bug has been marked as a duplicate of 9085 *** -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31508
[Bug rtl-optimization/9085] Unable to find register to spill when optimizing
--- Comment #9 from mkuvyrkov at gcc dot gnu dot org 2007-05-31 08:53 --- *** Bug 31508 has been marked as a duplicate of this bug. *** -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added CC||marat dot buharov at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9085
[Bug rtl-optimization/31806] miscompilation with -fschedule-insns2 -fno-threadsafe-statics
--- Comment #1 from mkuvyrkov at gcc dot gnu dot org 2007-05-30 14:30
---
This is an aliasing issue.
true_dependence () returns '0' on mems from insns 15 and 58. This is due to
MEM_READONLY_P () flag set on them.
(insn:HI 15 13 16 3 (set (mem/u/f/c/i:DI (symbol_ref:DI (_ZZ10testMethodvE1s)
[flags 0x2] var_decl 0x2e171c60 s) [5 s+0 S8 A64])
(reg:DI 0 ax [62])) 81 {*movdi_1_rex64} (insn_list:REG_DEP_TRUE 14
(nil))
(nil))
(insn 58 16 59 3 (set (reg/f:DI 3 bx [orig:59 s.1 ] [59])
(mem/u/f/c/i:DI (symbol_ref:DI (_ZZ10testMethodvE1s) [flags 0x2]
var_decl 0x2e171c60 s) [5 s+0 S8 A64])) 81 {*movdi_1_rex64} (nil)
(expr_list:REG_EQUIV (mem/u/f/c/i:DI (symbol_ref:DI (_ZZ10testMethodvE1s)
[flags 0x2] var_decl 0x2e171c60 s) [5 s+0 S8 A64])
(nil)))
I believe that comment in true_dependence ():
/* Read-only memory is by definition never modified, and therefore can't
conflict with anything. We don't expect to find read-only set on MEM,
but stupid user tricks can produce them, so don't die. */
conflicts with comment describing MEM_READONLY_P flag in rtl.h:
/* 1 in a REG, MEM, or CONCAT if the value is set at most once, anywhere. */
In mainline this bug is latent because code that initialize static variable and
code that use it are in the separate basic blocks. As long as scheduling works
on individual basic blocks the bug is hidden.
Confirm with fedora 6 system compiler.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
CC||mkuvyrkov at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-05-30 14:30:30
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31806
[Bug rtl-optimization/31806] miscompilation with -fschedule-insns2 -fno-threadsafe-statics
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2007-05-30 15:06 --- Created an attachment (id=13634) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13634action=view) Patch This patch fixes the issue but wasn't yet bootstrapped or tested in any other way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31806
[Bug rtl-optimization/31806] miscompilation with -fschedule-insns2 -fno-threadsafe-statics
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2007-05-30 15:22 --- Created an attachment (id=13635) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13635action=view) Patch Updated patch. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Attachment #13634|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31806
[Bug rtl-optimization/31806] miscompilation with -fschedule-insns2 -fno-threadsafe-statics
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2007-05-30 15:27 --- (In reply to comment #3) I don't think MEM_READONLY_P should be set. I think this is related to PR 31809. Memory location in question is a constant static variable in a function. When the function is run for the first time it will be initialized and after that will behave like a normal MEM_READONLY_P (). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31806
