[Bug c/56946] assignment expression work wired
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56946 Jie Zhang changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jiez at gcc dot gnu.org Resolution||INVALID --- Comment #2 from Jie Zhang 2013-04-13 13:10:43 UTC --- You need to add -lm to your command line. cos(0) is OK because gcc optimizes it away when compiling.
[Bug c/56946] assignment expression work wired
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56946 --- Comment #4 from Jie Zhang 2013-04-13 16:50:19 UTC --- (In reply to comment #3) > (In reply to comment #2) > > You need to add -lm to your command line. > gcc -lm -Wall assignment.c > > This is right?But it can't compile neither gcc -Wall assignment.c -lm
[Bug target/44290] [4.5 regression] __naked attribute is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290 --- Comment #31 from Jie Zhang 2010-12-21 04:16:19 UTC --- Patch for 4.5 was posted: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01351.html Waiting for approval.
[Bug driver/47137] [4.6 Regression] gcc incorrectly combines assembly inputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47137 --- Comment #13 from Jie Zhang 2011-01-04 10:21:29 UTC --- Author: jiez Date: Tue Jan 4 10:21:27 2011 New Revision: 168459 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168459 Log: PR driver/47137 * gcc.c (default_compilers[]): Set combinable field to 0 for all assembly languages. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c
[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42631 --- Comment #15 from Jie Zhang 2011-02-05 12:06:21 UTC --- Author: jiez Date: Sat Feb 5 12:06:18 2011 New Revision: 169851 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169851 Log: PR debug/42631 * web.c (entry_register): Don't clobber the number of the first uninitialized reference in used[]. testsuite/ PR debug/42631 * gcc.dg/pr42631.c: Update test. * gcc.dg/pr42631-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr42631-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr42631.c trunk/gcc/web.c
[Bug debug/47622] [4.6 Regression] FAIL: gcc.dg/pr42631.c scan-rtl-dump-not web "Web oldreg"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47622 Jie Zhang changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.07 02:37:06 Ever Confirmed|0 |1 --- Comment #3 from Jie Zhang 2011-02-07 02:37:06 UTC --- Confirmed.
[Bug testsuite/47622] [4.6 Regression] FAIL: gcc.dg/pr42631.c scan-rtl-dump-not web "Web oldreg"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47622 --- Comment #5 from Jie Zhang 2011-02-09 16:04:53 UTC --- I think my patch which causes this bug might be wrong after checking this test case in details. I may work out a new patch following Jeff's suggestion.
[Bug rtl-optimization/42631] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42631 --- Comment #16 from Jie Zhang 2011-02-10 04:22:48 UTC --- Author: jiez Date: Thu Feb 10 04:22:44 2011 New Revision: 169997 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169997 Log: PR testsuite/47622 Revert 2011-02-05 Jie Zhang PR debug/42631 * web.c (entry_register): Don't clobber the number of the first uninitialized reference in used[]. testsuite/ PR testsuite/47622 Revert 2011-02-05 Jie Zhang PR debug/42631 * gcc.dg/pr42631.c: Update test. * gcc.dg/pr42631-2.c: New test. Removed: trunk/gcc/testsuite/gcc.dg/pr42631-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr42631.c trunk/gcc/web.c
[Bug testsuite/47622] [4.6 Regression] FAIL: gcc.dg/pr42631.c scan-rtl-dump-not web "Web oldreg"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47622 --- Comment #6 from Jie Zhang 2011-02-10 04:22:49 UTC --- Author: jiez Date: Thu Feb 10 04:22:44 2011 New Revision: 169997 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169997 Log: PR testsuite/47622 Revert 2011-02-05 Jie Zhang PR debug/42631 * web.c (entry_register): Don't clobber the number of the first uninitialized reference in used[]. testsuite/ PR testsuite/47622 Revert 2011-02-05 Jie Zhang PR debug/42631 * gcc.dg/pr42631.c: Update test. * gcc.dg/pr42631-2.c: New test. Removed: trunk/gcc/testsuite/gcc.dg/pr42631-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr42631.c trunk/gcc/web.c
[Bug testsuite/47622] [4.6 Regression] FAIL: gcc.dg/pr42631.c scan-rtl-dump-not web "Web oldreg"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47622 Jie Zhang changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Jie Zhang 2011-02-10 04:31:54 UTC --- I reverted my patch which caused this bug. So this bug can be closed now.
[Bug rtl-optimization/47763] New: Useless initialization of register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47763
Summary: Useless initialization of register
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org
For arm-eabi target and options "-O2 -funroll-loops", gcc compiles the
following empty function
foo()
{
}
to
foo:
mov r0, #0
bx lr
Apparently the first instruction is useless.
[Bug rtl-optimization/47763] Useless initialization of register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47763 --- Comment #2 from Jie Zhang 2011-02-16 07:42:45 UTC --- OK. From this point, it's not empty. But if it returns an uninitialized value, why bother initialize r0 to 0. Btw, the patch in reviewing: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00787.html I just realized that we need a new PR number for the test case. So I reported this bug.
[Bug rtl-optimization/47763] Useless initialization of register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47763 --- Comment #4 from Jie Zhang 2011-02-16 07:59:19 UTC --- Yeah, normally we don't care about such cases. But this one comes from dhrystone. If it can be fixed cleanly, why not do it?
[Bug rtl-optimization/47763] Useless initialization of register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47763 --- Comment #6 from Jie Zhang 2011-02-16 08:32:14 UTC --- I think we all know that dhrystone is a bad benchmark. But some users don't. Which is more difficult: educating all users about that vs apply a simple patch in GCC to remove the useless initialization? 4.4 does has such initialization. But 4.5 has. Fixing this is an improvement and does not hurt. From another point, leaving it unfixed does not help GCC.
[Bug rtl-optimization/47763] Useless initialization of register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47763 --- Comment #7 from Jie Zhang 2011-02-16 08:49:46 UTC --- Sorry, in my last comment, I meant to say "4.4 does NOT have such initialization".
[Bug rtl-optimization/47763] Useless initialization of register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47763 --- Comment #9 from Jie Zhang 2011-02-16 11:29:50 UTC --- The clobber is optimized away in 172r.cprop3 because the register renaming in 171r.web breaks the def-use relationship between the clobber and the use in the following instruction when -funroll-loops is used. My patch prevents the renaming in such case.
[Bug rtl-optimization/47763] Useless initialization of register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47763 --- Comment #11 from Jie Zhang 2011-02-23 00:25:38 UTC --- Author: jiez Date: Wed Feb 23 00:25:34 2011 New Revision: 170422 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170422 Log: PR rtl-optimization/47763 * web.c (web_main): Ignore naked clobber when replacing register. testsuite/ PR rtl-optimization/47763 * gcc.dg/pr47763.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr47763.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/web.c
[Bug rtl-optimization/47763] Useless initialization of register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47763 Jie Zhang changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #12 from Jie Zhang 2011-02-23 00:27:15 UTC --- Fixed.
[Bug target/49862] bfin.c warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49862 --- Comment #2 from Jie Zhang 2012-03-09 05:54:30 UTC --- Author: jiez Date: Fri Mar 9 05:54:25 2012 New Revision: 185125 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185125 Log: PR target/49862 * config/bfin/bfin.c (hwloop_optimize): Fix unused variable warnings. (hwloop_pattern_reg): Fix set but not used warning. (bfin_reorg_loops): Remove unused parameter. (bfin_reorg): Update use of bfin_reorg_loops. Modified: trunk/gcc/ChangeLog trunk/gcc/config/bfin/bfin.c
[Bug target/49862] bfin.c warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49862 Jie Zhang changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-09 CC||jiez at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jiez at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Jie Zhang 2012-03-09 05:56:57 UTC --- Mine.
[Bug ada/51201] New: /bin/bash: gnatls: command not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51201 Bug #: 51201 Summary: /bin/bash: gnatls: command not found Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org On a x86_64-pc-linux-gnu host ../../git/configure --enable-languages=c --target=i686-pc-linux-gnu make[2]: Leaving directory `/home/jie/sources/gcc/builds/build/libdecnumber' /bin/bash: gnatls: command not found make[2]: Entering directory `/home/jie/sources/gcc/builds/build/gcc' It's caused by r177462: 2011-08-05 Nicolas Roche * gcc-interface/Makefile.in: Don't use directly ../xgcc to build shared libgnat. Use rather the value of GCC_FOR_TARGET. Fix issue with canadian cross. * gcc-interface/Make-lang.in: Add support for canadian cross setting.
[Bug ada/51201] /bin/bash: gnatls: command not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51201 --- Comment #2 from Jie Zhang 2011-11-18 02:51:35 UTC --- (In reply to comment #1) > "../../git/configure" Can you try with an absolute path instead? Yes. It has the same error. It happens when configured as a cross compiler, but not as a native compiler.
[Bug target/51552] bfin generates bad assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51552 Jie Zhang changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-17 CC||jiez at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jie Zhang 2011-12-17 03:06:37 UTC --- This was caused by r177218 for PR target/49864.
[Bug target/51552] bfin generates bad assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51552 --- Comment #2 from Jie Zhang 2011-12-21 04:35:19 UTC --- (gdb) p insn $23 = (rtx) 0x7701b180 (gdb) pr (parallel [ (unspec [ (const_int -4 [0xfffc]) ] 5) (set/f (mem:SI (plus:SI (reg/f:SI 14 SP) (const_int -4 [0xfffc])) [0 S4 A32]) (reg:SI 7 R7)) (set/f (reg/f:SI 14 SP) (plus:SI (reg/f:SI 14 SP) (const_int -4 [0xfffc]))) Before that commit, dwarf2out_frame_debug_expr (insn) will set any_cfis_emitted in dwarf2out_frame_debug, which will cause dwarf2out_flush_queued_reg_saves to emit the CFI. But after that commit, dwarf2out_frame_debug_expr (insn) will not set any_cfis_emitted.
[Bug target/86777] Bfin port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86777 --- Comment #1 from Jie Zhang --- (In reply to Richard Earnshaw from comment #0) > The bfin port needs updating for this CVE. See the linked meta bug for > details of possible actions required. For Blackfin, the speculative load only happens when the load instruction is the next instruction after conditional jump instruction. For example, conditional jump load The above load will be speculatively executed. But conditional jump add load this load will not. Is there a way to control speculation barrier being only inserted for the first case, but not for the second case? Thanks. Jie
[Bug lto/45790] 1308 new GCC h...@164592 regressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45790 Jie Zhang changed: What|Removed |Added CC||jiez at gcc dot gnu.org --- Comment #2 from Jie Zhang 2010-09-27 10:07:21 UTC --- The same issue was found on arm-none-eabi: http://gcc.gnu.org/ml/gcc-patches/2010-09/msg02004.html
[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360 Jie Zhang changed: What|Removed |Added CC||jiez at gcc dot gnu.org --- Comment #20 from Jie Zhang 2010-10-19 14:03:07 UTC --- Just for record, "./cc1 -march=sb1 -O3 j.i -fPIC" can reproduce this issue on latest trunk if r140151 is reversed.
[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360 --- Comment #21 from Jie Zhang 2010-10-19 16:58:58 UTC --- Another way to fix this bug: http://gcc.gnu.org/ml/gcc/2010-10/msg00281.html David, are you still interested to try this patch on sb1?
[Bug rtl-optimization/37360] [4.4 Regression] ICE in haifa-sched.c when compiling __popcountsi2 from libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360 --- Comment #23 from Jie Zhang 2010-10-23 00:38:16 UTC --- Author: jiez Date: Sat Oct 23 00:38:13 2010 New Revision: 165880 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165880 Log: PR rtl-optimization/37360 * config/mips/mips.c (cached_can_issue_more): New local variable. (mips_sched_reorder_1): New. (mips_sched_reorder): Use mips_sched_reorder_1. (mips_sched_reorder2): New. (mips_variable_issue): Set cached_can_issue_more. (TARGET_SCHED_REORDER2): Define to mips_sched_reorder2 instead of mips_sched_reorder. Revert 2008-09-09 Andrey Belevantsev PR rtl-optimization/37360 * haifa-sched.c (max_issue): Do not assert that we never issue more insns than issue_rate. Add comment. testsuite/ PR rtl-optimization/37360 * gcc.dg/pr37360.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr37360.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.c trunk/gcc/haifa-sched.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/46674] New: Weak alias was mistakenly optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674 Summary: Weak alias was mistakenly optimized away Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org Created attachment 22537 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22537 The test case This patch http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02275.html causes a failure when building glibc for arm-none-linux-gnueabi target. The reduced test case is attached. Without this patch, memchr is defined in the assembly: .size__memchr, .-__memchr .weak __GI_memchr .hidden __GI_memchr .set__GI_memchr,__memchr .global memchr .setmemchr,__GI_memchr .ident"GCC: (GNU) 4.6.0 20101026 (experimental)" but with this patch, memchr is not defined: .size__memchr, .-__memchr .weak__GI_memchr .hidden__GI_memchr .set__GI_memchr,__memchr .ident"GCC: (GNU) 4.6.0 20101026 (experimental)" When compiling the test case, -O is used on the command line.
[Bug middle-end/46674] [4.6 Regression] Weak alias is mistakenly optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674 Jie Zhang changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | --- Comment #2 from Jie Zhang 2010-11-29 04:57:56 UTC --- I still see the issue with the test case on latest GCC trunk on arm-none-linux-gnueabi target and native x86_64-linux-gnu. So I reopen it.
[Bug middle-end/46674] [4.6 Regression] Weak alias is mistakenly optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674
--- Comment #3 from Jie Zhang 2010-11-29 10:56:37 UTC
---
If I revert this change, this bug will disappear.
@@ -416,7 +415,7 @@ cgraph_remove_unreachable_nodes (bool be
found = true;
/* If so, we need to keep node in the callgraph. */
- if (found || node->needed)
+ if (found)
{
if (node->analyzed)
{
[Bug middle-end/46674] [4.6 Regression] Weak alias is mistakenly optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674 --- Comment #4 from Jie Zhang 2010-11-30 10:00:05 UTC --- Hah, I now know the root cause. It's "*__GI_memchr" that is added into the visible point set since it's a user provided name. But GCC looks for "__GI_memchr" later, which is not the same identifier as "*__GI_memchr". Is there a way to easily translate a "*__GI_memchr" identifier to a "__GI_memchr" one?
[Bug middle-end/46674] [4.6 Regression] Weak alias is mistakenly optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674 --- Comment #5 from Jie Zhang 2010-11-30 11:17:47 UTC --- Created attachment 22577 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22577 The patch I'm testing this patch.
[Bug middle-end/46674] [4.6 Regression] Weak alias is mistakenly optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674 --- Comment #6 from Jie Zhang 2010-11-30 23:58:54 UTC --- The patch for review: http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02973.html
[Bug middle-end/46674] [4.6 Regression] Weak alias is mistakenly optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674 --- Comment #7 from Jie Zhang 2010-12-02 04:10:04 UTC --- Author: jiez Date: Thu Dec 2 04:09:58 2010 New Revision: 167365 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167365 Log: PR middle-end/46674 * varasm.c (compute_visible_aliases): Handle user set assembler name. testsuite/ PR middle-end/46674 * gcc.dg/pr46674.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr46674.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c
[Bug middle-end/46667] [4.6 Regression] -freorder-blocks-and-partition -g failed and libstdc++ builds for arm-eabi are broken.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46667 Jie Zhang changed: What|Removed |Added CC||jiez at gcc dot gnu.org --- Comment #9 from Jie Zhang 2010-12-03 03:38:38 UTC --- I see the similar issue too when building libstdc++ for arm-none-linux-gnueabi target.
[Bug middle-end/46667] [4.6 Regression] -freorder-blocks-and-partition -g failed and libstdc++ builds for arm-eabi are broken.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46667 --- Comment #10 from Jie Zhang 2010-12-03 04:22:48 UTC --- Chung-Lin Tang told me he had a patch for this: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00137.html
[Bug target/44290] [4.5 regression] __naked attribute is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290 --- Comment #29 from Jie Zhang 2010-12-16 03:05:53 UTC --- Serge, yes. But GCC 4.5 branch is frozen now again.
