[Bug c++/45651] internal compiler error: in import_export_decl, at cp/decl2.c:2344
-- steven at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-12 13:40:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45651
[Bug fortran/36841] Eliminate gfortran_sum_r8 call for calculation involving multidimensional array multiplication followed by a sum along first dimension
--- Comment #3 from steven at gcc dot gnu dot org 2010-09-12 17:14 --- This is not a job for the FE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36841
[Bug fortran/36841] Eliminate gfortran_sum_r8 call for calculation involving multidimensional array multiplication followed by a sum along first dimension
--- Comment #5 from steven at gcc dot gnu dot org 2010-09-12 21:24 --- OK, I thought you meant that this would be something for a separate Fortran front end optimization pass. Expanding SUM differently is a job for the FE, yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36841
[Bug c++/45635] [4.6 regression] Failed to bootstrap on Linux/ia64
--- Comment #3 from steven at gcc dot gnu dot org 2010-09-11 12:58 --- Created an attachment (id=21776) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21776action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635
[Bug c++/45635] [4.6 regression] Failed to bootstrap on Linux/ia64
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-11 12:58:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635
[Bug c++/45635] [4.6 regression] Failed to bootstrap on Linux/ia64
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635
[Bug c/45358] Diagnostic could be issued for old C style a =+ b and similar cases
-- steven at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-linux-gnu| GCC host triplet|x86_64-linux-gnu| GCC target triplet|x86_64-linux-gnu| Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2010-08-20 19:46:42 date|| Summary|=+ oddness |Diagnostic could be issued ||for old C style a =+ b and ||similar cases http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45358
[Bug plugins/45346] hard-reg-set.h needs to be in the plugin include directory
--- Comment #2 from steven at gcc dot gnu dot org 2010-08-19 20:24 --- Gross. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45346
[Bug plugins/45346] hard-reg-set.h needs to be in the plugin include directory
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-19 20:28 --- The proper fix for this is not to just go back to the include everything everywhere. The proper fix is instead to move struct rtl_data out of function.h (as I have said before) and into e.g. emit-rtl.h. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45346
[Bug plugins/45348] cp/cp-tree.h in plugin header does not work.
--- Comment #1 from steven at gcc dot gnu dot org 2010-08-19 21:57 --- Makefile should be changed, the reference to c-family/c-common.h is intentionally relative to $srcdir. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-19 21:57:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45348
[Bug rtl-optimization/43494] [4.4/4.5/4.6 Regression] Overlooked dependency causes wrong scheduling, wrong code
--- Comment #23 from steven at gcc dot gnu dot org 2010-08-18 10:50 --- So the scheduler uses cselib to get a better view of the address, but cselib doesn't actually give a better address. And the solution is to just give up in that case? It seems to me that if cselib doesn't give a better address than XEXP(MEM,0) then the original address should be used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug middle-end/45325] target attribute doesn't work with -march=i586
--- Comment #2 from steven at gcc dot gnu dot org 2010-08-18 20:58 --- WONTFIX for an ICE seems a bit odd to me. Just needs a diagnostic to reject nonsense target attributes, or a sorry. But not an ICE. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325
[Bug middle-end/37565] __optimize__ attribute doesn't work correctly
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-18 20:59:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565
[Bug middle-end/37734] Missing optimization: gcc fails to reuse flags from already calculated expression for condition check with zero
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|target |middle-end Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-15 18:59:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37734
[Bug middle-end/44569] Debug statements passed to rtx
--- Comment #1 from steven at gcc dot gnu dot org 2010-08-15 19:05 --- Is this still a problem for you? I can try to help you here, but I need to know what patch I should apply and to what revision, to reproduce the problem. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44569
[Bug middle-end/44569] Debug statements passed to rtx
--- Comment #4 from steven at gcc dot gnu dot org 2010-08-15 20:48 --- Investigating... -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|WAITING |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-15 20:48:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44569
[Bug middle-end/45273] [4.4/4.5/4.6 Regression] The compiler depends on the host double (-fprofile-corection only)
--- Comment #1 from steven at gcc dot gnu dot org 2010-08-13 07:22 --- Should use sreal, then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45273
[Bug preprocessor/45227] libcpp Makefile does not enable instrumentation
--- Comment #1 from steven at gcc dot gnu dot org 2010-08-13 07:42 --- Does anyone have a daily autotester for profiled-bootstrap? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-13 07:42:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45227
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #19 from steven at gcc dot gnu dot org 2010-08-12 10:00 --- According to comment#14, a patch from Alexander Monakov introduced this bug, therefore: 1. this is a regression on a primary platform = priority should be set P1 -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, amonakov at gcc dot gnu ||dot org Summary|Optimization flag -O1 - |[4.3/4.4/4.5/4.6 Regression] |fschedule-insns2 causes |Optimization flag -O1 - |wrong code |fschedule-insns2 causes ||wrong code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #20 from steven at gcc dot gnu dot org 2010-08-12 10:00 --- ...and 2. Add richi and amonakov to CC: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #21 from steven at gcc dot gnu dot org 2010-08-12 10:08 --- Re. comment #14 I am a bit irritated why this bug survived the 4.4.0 and 4.5.0 release.: Yes, well, ARM maintainers have been in the CC-list for this bug since the beginning, and apparently it was even too much trouble for them to see if this is a regression or not... :-( Anyway, many thanks to Sebastian Huber for identifying the revision that introduced (or exposed) this bug. -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-12-22 11:16:40 |2010-08-12 10:08:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #23 from steven at gcc dot gnu dot org 2010-08-12 11:37 --- The patch from comment #16 only fixes the symptom, and only on ARM. It is not a proper fix for the generic problem that is apparently also visible on POWER. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug middle-end/45267] [4.5 regression] inlining fails with -m32
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-12 21:07 --- Re. comment #1: Looks more like that commit made this problem latent on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45267
[Bug middle-end/45267] [4.5 regression] inlining fails with -m32
--- Comment #5 from steven at gcc dot gnu dot org 2010-08-12 21:30 --- I don't think this is a heuristics bug at all. You're not getting an error or a warning about a missed optimization (inlining). You get a sorry, and that only happens if GCC tries but fails to inline an always_inline function. But the reason for the sorry is that the call is unlikely and code size would grow. That should never be checked for always_inline functions. The always_inline attribute is basically an attribute to shut off the inlining heuristics. A do as I say-attribute. The sorry means that GCC is not doing what you tell it to do. The heuristics changes in GCC 4.6 just paper over this problem. If I'm right, anyway, that this is an always_inline problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45267
[Bug c/45268] CPU2006 458.sjeng: type mismatch in array reference with -fwhole-program -combine
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-12 22:00 --- Indeed any attempt to fix -combine for checking failures would be a waste of resources that are better spent on LTO/WHOPR... -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45268
[Bug tree-optimization/45255] [4.6 regression] internal compiler error: verify_stmts failed with -fwhopr
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-11 10:17 --- WHOPR involved, MEM_REF involved... Richi? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45255
[Bug c++/44172] Compiling never ends
--- Comment #6 from steven at gcc dot gnu dot org 2010-08-11 15:27 --- I don't see how the compiler can know that this input causes an infinite loop. This is just the halting problem. Not a bug in the sense that there is anything to fix. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44172
[Bug middle-end/41551] [4.4 Regression] ia64: ICE: in instantiate_virtual_regs_in_insn, at function.c:1630
--- Comment #5 from steven at gcc dot gnu dot org 2010-08-09 17:11 --- http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg01067.html -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Known to fail||4.4.4 Known to work||4.2.0 4.5.0 4.6.0 Resolution|FIXED | Summary|ia64: ICE: in |[4.4 Regression] ia64: ICE: |instantiate_virtual_regs_in_|in |insn, at function.c:1630|instantiate_virtual_regs_in_ ||insn, at function.c:1630 Target Milestone|--- |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41551
[Bug middle-end/41551] [4.4 Regression] ia64: ICE: in instantiate_virtual_regs_in_insn, at function.c:1630
--- Comment #6 from steven at gcc dot gnu dot org 2010-08-09 17:11 --- Needs fixing in 4.4 still. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-09 17:11:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41551
[Bug middle-end/17982] stop calling assemble_external before final assembly output time
--- Comment #34 from steven at gcc dot gnu dot org 2010-08-09 21:13 --- The FIXME here is this one in varasm.c: --- /* We delay assemble_external processing until the compilation unit is finalized. This is the best we can do for right now (i.e. stage 3 of GCC 4.0) - the right thing is to delay it all the way to final. See PR 17982 for further discussion. */ static GTY(()) tree pending_assemble_externals; --- According to http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00491.html: The *proper* solution to this problem is to remove all calls to assemble_external from the front ends and even the RTL expander; it should only be done from final.c and varasm.c as we are emitting assembly. $ grep assemble_external c* */*.[ch] ada/gcc-interface/*.[ch] calls.c: assemble_external (fndecl); calls.c: assemble_external_libcall (fun); cp/cp-tree.h: so that assemble_external will work properly. So we have this flag to objc/objc-act.c: assemble_external (objc_get_class_decl); objc/objc-act.c: assemble_external (func); objc/objc-act.c: assemble_external (objc_assign_global_decl); objc/objc-act.c: assemble_external (objc_assign_strong_cast_decl); objc/objc-act.c: assemble_external (super_class); I think the ones in calls.c are OK. So only ObjC still calls assemble_external. Iain? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug objc/24777] objc needs to use normal builtins for functions it declares
--- Comment #4 from steven at gcc dot gnu dot org 2010-08-09 21:32 --- This blocks 17982. There are assemble_external calls are for objc_get_class_decl, objc_assign_global_decl, and objc_assign_strong_cast_decl. -- steven at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||17982 nThis|| Last reconfirmed|2007-07-09 05:57:42 |2010-08-09 21:32:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24777
[Bug rtl-optimization/45223] RTL PRE GCSE pass hoists trapping insn out of loop
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-07 10:57 --- Patch of comment #1 loops obviously OK to me. We shouldn't want to move trapping insns in any case that I can think of. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-07 10:57:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45223
[Bug fortran/45057] Unneeded temporary / missed bounds violation for PACK
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-06 21:21:08 date|| Summary|Unneded temporary / missed |Unneeded temporary / missed |bounds violation for PACK |bounds violation for PACK http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45057
[Bug fortran/44235] array temporary with high upper bound
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-06 21:24 --- What's the plan with the patch of comment #2? NB, the result of gfc_dep_compare_expr (l_start, r_start) could be cached instead of computed twice: + ((res = gfc_dep_compare_expr (l_start, r_start)) == 0 + || res == -1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44235
[Bug tree-optimization/45218] Mathematical simplification missed at tree-level
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-06 22:51:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45218
[Bug tree-optimization/45216] Rotate expressions not recognized at tree level
--- Comment #2 from steven at gcc dot gnu dot org 2010-08-06 23:02 --- pathetic... :) -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2010-08-06 23:02:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45216
[Bug tree-optimization/15596] [4.3/4.4/4.5/4.6 Regression] Missed optimization with bitfields with return value
--- Comment #18 from steven at gcc dot gnu dot org 2010-08-06 23:12 --- Martin, perhaps a test case you want to watch if you or someone else is going to play with SRA vs. bitfields. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15596
[Bug tree-optimization/45216] Rotate expressions not recognized at tree level
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-06 23:17 --- Related to PR17886, where it says that: gcc can detect the (x y)|(x (bitwidth-y)) idiom for rotate and convert it into the machine rotate instruction. But it only works when y is a constant and is not long long. But apparently even this case is not detected anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45216
[Bug bootstrap/45154] ICE in calc_dfs_tree, at dominance.c:394
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-01 10:38 --- Confirmed. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, jamborm at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-01 10:38:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45154
[Bug tree-optimization/10474] gcc should be able to delay the setup of the frame pointer (patrial outlining)
--- Comment #7 from steven at gcc dot gnu dot org 2010-08-01 10:40 --- Isn't this bug description just a request for shrink-wrapping? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474
[Bug tree-optimization/43940] DOM doesn't propagate constants properly
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-25 10:29 --- VRP does this with ASSERT_EXPRs. DOM does not optimize this because bb4 has two predecessors, and record_equivalences_from_incoming_edge only records from a single predecessor. This should probably be handled record_equivalences_from_phis by looking at the value of the incoming argument, before calling operand_equal_for_phi_arg_p. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43940
[Bug tree-optimization/43940] DOM doesn't propagate constants properly
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-25 16:25 --- cprop_into_successor_phis only propagates SSA_NAME_VALUEs, but not conditional copies/constants. May be a better place to fix this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43940
[Bug middle-end/45035] [4.6 Regression] FAIL: gcc.dg/guality/pr36728-2.c
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-24 12:38 --- Subject: Bug 45035 Author: steven Date: Sat Jul 24 12:37:51 2010 New Revision: 162499 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162499 Log: PR middle-end/45035 * alias.c (true_dependence_1): Fix thinko in merge of old true_dependence and canon_true_dependence. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45035
[Bug middle-end/45035] [4.6 Regression] FAIL: gcc.dg/guality/pr36728-2.c
--- Comment #5 from steven at gcc dot gnu dot org 2010-07-24 12:39 --- . -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45035
[Bug c/44041] [4.5 regression] -combine ICE: verify_gimple failed (invalid conversion in return statement)
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-24 21:21 --- IMA (-combine) = WONTFIX? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44041
[Bug c/23104] [4.3/4.4/4.5/4.6 Regression] C does not reject the same function in two different TUs with -combine
--- Comment #17 from steven at gcc dot gnu dot org 2010-07-24 21:22 --- IMA (-combine) = WONTFIX? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23104
[Bug tree-optimization/43940] DOM doesn't propagate constants properly
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-24 22:04 --- Investigating... -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-07-24 21:44:54 |2010-07-24 22:04:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43940
[Bug middle-end/45035] [4.6 Regression] FAIL: gcc.dg/guality/pr36728-2.c
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-07-23 07:42:27 |2010-07-23 08:20:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45035
[Bug middle-end/45035] [4.6 Regression] FAIL: gcc.dg/guality/pr36728-2.c
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-23 08:58 ---
Somehow managed to make a mistake in the merge for the case that x_addr is
non-NULL.
Index: alias.c
===
--- alias.c (revision 162430)
+++ alias.c (working copy)
@@ -2375,18 +2375,19 @@ true_dependence_1 (const_rtx mem, enum m
}
if (! x_addr)
-x_addr = XEXP (x, 0);
-
- if (!((GET_CODE (x_addr) == VALUE
- GET_CODE (mem_addr) != VALUE
- reg_mentioned_p (x_addr, mem_addr))
- || (GET_CODE (x_addr) != VALUE
-GET_CODE (mem_addr) == VALUE
-reg_mentioned_p (mem_addr, x_addr
{
- x_addr = get_addr (x_addr);
- if (!mem_canonicalized)
- mem_addr = get_addr (mem_addr);
+ x_addr = XEXP (x, 0);
+ if (!((GET_CODE (x_addr) == VALUE
+ GET_CODE (mem_addr) != VALUE
+ reg_mentioned_p (x_addr, mem_addr))
+ || (GET_CODE (x_addr) != VALUE
+GET_CODE (mem_addr) == VALUE
+reg_mentioned_p (mem_addr, x_addr
+ {
+ x_addr = get_addr (x_addr);
+ if (! mem_canonicalized)
+ mem_addr = get_addr (mem_addr);
+ }
}
base = find_base_term (x_addr);
Will bootstrap+test, and commit if it passes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45035
[Bug tree-optimization/45032] Missed optimization in ifcvt/crossjump
--- Comment #1 from steven at gcc dot gnu dot org 2010-07-22 20:58 --- Looks related to bug 20070. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45032
[Bug rtl-optimization/43494] [4.4/4.5/4.6 Regression] Overlooked dependency causes wrong scheduling, wrong code
--- Comment #16 from steven at gcc dot gnu dot org 2010-07-21 08:22 --- OK, I think I finally understand what Alexander tried to explain, and I've annotated the code. Alexander, does this look right to you? f1: // vector int f1(vector int t) .mmi mov r15 = r12 // 30: r12 = @temp1 mov r14 = r12 // 29: r14 = @temp1 addl r16 = 1, r0// 34: r16 = 1 ;; .mmi st8 [r15] = r32, 8 // 36: temp1[0:1] = t[0:1], r...@temp[2] ;; st8 [r15] = r33, -4 // 37: temp1[2:3] = t[2:3], r...@temp[1] nop 0 .mii ld8 r8 = [r14], 8 // 21: r8 = temp[0:1] nop 0 ;; nop 0 .mmb ld8 r9 = [r14] // 28: r9 = temp[2:3] st4 [r15] = r16 // 9: temp[1] = 1 br.ret.sptk.many b0 // 40: return r8:r9 .endp f1# -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug rtl-optimization/43494] [4.4/4.5/4.6 Regression] Overlooked dependency causes wrong scheduling, wrong code
--- Comment #18 from steven at gcc dot gnu dot org 2010-07-21 09:27 --- Created an attachment (id=21277) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21277action=view) debug log I think the problem is that fixed_scalar_and_varying_struct_p is called with a VALUE address, i.e. not expanded. See attached debug log. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug rtl-optimization/43494] [4.4/4.5/4.6 Regression] Overlooked dependency causes wrong scheduling, wrong code
--- Comment #19 from steven at gcc dot gnu dot org 2010-07-21 09:33 --- x_addr is a VALUE that has no locs: Breakpoint 4, true_dependence (mem=0x205ddf68, mem_mode=VOIDmode, x=0x205ddfb0, varies=0x20496720) at ../../trunk/gcc/alias.c:2330 2330 if (MEM_VOLATILE_P (x) MEM_VOLATILE_P (mem)) (gdb) cont Continuing. Breakpoint 11, get_addr (x=0x60316e28) at ../../trunk/gcc/alias.c:1726 1726 if (GET_CODE (x) != VALUE) (gdb) up #1 0x4036eb50 in true_dependence (mem=0x205ddf68, mem_mode=SImode, x=0x205ddfb0, varies=0x20496720) at ../../trunk/gcc/alias.c:2367 2367 x_addr = get_addr (x_addr); (gdb) down #0 get_addr (x=0x60316e28) at ../../trunk/gcc/alias.c:1726 1726 if (GET_CODE (x) != VALUE) (gdb) next 1728 v = CSELIB_VAL_PTR (x); (gdb) 1729 if (v) (gdb) 1731 for (l = v-locs; l; l = l-next) (gdb) p v-locs $72 = (struct elt_loc_list *) 0x0 (gdb) p debug_rtx(x) (value:DI 10:10 @0x60316e28/0x60316d10) $73 = void (gdb) So get_addr just returns the VALUE. Is it *ever* OK for get_addr to return a VALUE rtx? It seems to me this should never happen, and we should assert that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug rtl-optimization/43494] [4.4/4.5/4.6 Regression] Overlooked dependency causes wrong scheduling, wrong code
--- Comment #20 from steven at gcc dot gnu dot org 2010-07-21 09:49 --- Since this bug only triggers if cselib is used, the bug affects schedule_ebbs only. The other schedulers are !use_cselib schedulers. (Even sel-sched apparently does not use cselib, that's surprising!) OTOH, this bug can probably be triggered with -fsched2-use-superblocks on any target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug rtl-optimization/40552] wrong-code with -fsched2-use-superblocks and exceptions
--- Comment #1 from steven at gcc dot gnu dot org 2010-07-21 09:54 --- Investigating... -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-21 09:54:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40552
[Bug middle-end/39274] internal compiler error: in check_cfg, at haifa-sched.c, var-tracking
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-21 09:58 --- Look at the ia64 port (and a few others too, e.g. blackfin), they call compute_bb_for_insn first thing in machine reorg and that works. It is obviously not ideal, but the only pass between free_cfg and machine_reorg that can destroy the CFG is dbr_sched (delay branch scheduling). Anyway, out-of-tree port = INVALID. Feel free to re-open this bug report if you can reproduce it with an in-tree port, of course. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39274
[Bug tree-optimization/13745] [tree-ssa] expressions not converted back to array form
--- Comment #12 from steven at gcc dot gnu dot org 2010-07-21 20:54 --- Fixed with MEM_REF. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13745
[Bug tree-optimization/13952] [tree-ssa] SRA does not work for structs containing arrays
--- Comment #5 from steven at gcc dot gnu dot org 2010-07-21 21:00 --- Optimizes to an empty function for me with r162374. Probably thanks to Martin's SRA rewrite. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13952
[Bug target/45026] New: Empty function compiles to many loads and stores
Consider this test case:
typedef struct teststruct
{
double d;
char f1;
int arr[15];
} teststruct;
void
copystruct5 (teststruct param)
{
return;
}
The mighty copystruct5 function does absolutely nothing, so I expect this to be
compiled to absolutely nothing. But not so with r162374 at -O2:
.file t.c
.pred.safe_across_calls p1-p5,p16-p63
.text
.align 16
.align 64
.global copystruct5#
.type copystruct5#, @function
.proc copystruct5#
copystruct5:
.prologue
.spill 48
.mmi
.fframe 48
adds r12 = -48, r12
[.L2:]
.body
;;
mov r14 = r12
adds r15 = 16, r12
;;
.mmi
st8 [r14] = r32, 8
st8 [r15] = r34
nop 0
;;
.mmi
st8 [r14] = r33
nop 0
adds r14 = 24, r12
;;
.mmi
st8 [r14] = r35
nop 0
adds r14 = 32, r12
;;
.mmi
st8 [r14] = r36
nop 0
adds r14 = 40, r12
;;
.mmi
st8 [r14] = r37
nop 0
adds r14 = 48, r12
;;
.mmi
st8 [r14] = r38
nop 0
adds r14 = 56, r12
;;
.mib
st8 [r14] = r39
.restore sp
adds r12 = 48, r12
br.ret.sptk.many b0
.endp copystruct5#
.ident GCC: (GNU) 4.6.0 20100721 (experimental) [trunk revision
162374]
What's that?!
--
Summary: Empty function compiles to many loads and stores
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
GCC target triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45026
[Bug tree-optimization/14455] Structs that cannot alias are not SRA'd
--- Comment #7 from steven at gcc dot gnu dot org 2010-07-21 21:09 --- The SRA rewrite for GCC 4.6 probably fixes the SRA part of this bug report (at last!). Can someone with a powerpc box have a look? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org, jamborm at gcc dot gnu ||dot org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14455
[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-21 21:10:46 date|| Version|tree-ssa|4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44297
[Bug java/1812] zextract.c cleanup
--- Comment #7 from steven at gcc dot gnu dot org 2010-07-21 21:53 --- 9 years 0 progress Tom? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1812
[Bug target/44999] and r0, r0, #255 can be replace with uxtb in thumb2
--- Comment #1 from steven at gcc dot gnu dot org 2010-07-20 08:37 --- Note, it's often helpful for us non-ARM-assembly-gurus to explain the pattern you would like to have, instead of the mnemonic :-) -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-20 08:37:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44999
[Bug rtl-optimization/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
--- Comment #10 from steven at gcc dot gnu dot org 2010-07-20 13:20 ---
Re. comment 9: Well, the order of *this* store and *this* load is the
difference between the test case failing or passing. So I do not think the
problem is between this load and another store.
Before sched2 (or actually, .mach on ia64):
vector-2.c.213r.compgotos (notes, NOPs, bundle markers removed):
;; Function f1 (f1)
30 r15:DI=r12:DI
29 r14:DI=r12:DI
35 [r15:DI++]=r32:DI
36 [post r15:DI+=0xfffc]=r33:DI
9 [r15:DI]=r34:SI
21 r8:DI=[r14:DI++]
28 r9:DI=[r14:DI]
18 use r8:TI
39 {return;use b0:DI;}
After .sched2:
vector-2.c.215r.mach (notes, NOPs, bundle markers removed):
30 r15:DI=r12:DI
29 r14:DI=r12:DI
35 [r15:DI++]=r32:DI
36 [post r15:DI+=0xfffc]=r33:DI
21 r8:DI=[r14:DI++]
28 r9:DI=[r14:DI]
9 [r15:DI]=r34:SI
18 use r8:TI
39 {return;use b0:DI;}
Note that the only real change in the scheduling is that insn 9 is moved after
insn 21 and insn 28. insn 9 is the store [r15:DI]=r34:SI that later expands
to the st4 instruction.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug rtl-optimization/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
--- Comment #11 from steven at gcc dot gnu dot org 2010-07-20 13:22 ---
insn 28 and insn 9 in non-slim form, with assembler output:
//(insn:TI 28 48 9 2 vector-2.c:7 (set (reg:DI 9 r9 [+8 ])
//(mem/c/i:DI (reg/f:DI 14 r14 [351]) [2 t+8 S8 A64]))
//5 {movdi_internal} (expr_list:REG_DEAD (reg/f:DI 14 r14 [351])
//(nil)))
ld8 r9 = [r14] // 28 movdi_internal/5
//(insn 9 28 18 2 vector-2.c:5 (set (mem/s/j/c:SI (reg/f:DI 15 r15 [343])
// [2 t+4 S4 A32])
//(reg:SI 114 r34 [ a ])) 4 {movsi_internal}
//(expr_list:REG_DEAD (reg:SI 114 r34 [ a ])
// (expr_list:REG_DEAD (reg/f:DI 15 r15 [343])
//(nil
st4 [r15] = r34 // 9movsi_internal/6
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug target/15087] IA64: Wrong alignment for structure 8 byte
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-20 13:40 --- We might as well close this as WONTFIX, I don't think anyone is interested in fixing this. We would have to document this problem in the manual, but then at least we can close the Bugzilla entry. Thoughts? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15087
[Bug target/25372] Aligned args on IA64
--- Comment #6 from steven at gcc dot gnu dot org 2010-07-20 13:51 --- So what's the verdict, 4 years later. Is there a bug here, or can this PR be closed now? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25372
[Bug target/35658] [4.3 Regression] between -funroll-loops -fno-automatic -O2 and common block variable
--- Comment #16 from steven at gcc dot gnu dot org 2010-07-20 13:55 --- May be a dup of 43494, based on comment #7. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35658
[Bug rtl-optimization/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
--- Comment #12 from steven at gcc dot gnu dot org 2010-07-20 13:57 --- Bug 35658 is another case where a store is scheduled after a load that depends on the store. It may well be that bug 35658 and this bug are the same issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug target/3746] compilation of mips-tfile missing mips/a.out.h
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|echristo at apple dot com |unassigned at gcc dot gnu ||dot org Status|SUSPENDED |NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3746
[Bug tree-optimization/17955] Perform associative optimization when it is safe
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-20 14:02 --- No test case. Nothing to do here. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17955
[Bug objc/31281] ICE on ObjC try-catch blocks with next runtime
--- Comment #6 from steven at gcc dot gnu dot org 2010-07-20 14:03 --- Patches for this were commited in the last decade. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31281
[Bug target/26262] Named section support should infer segment name
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-20 14:04 --- This is still a problem. Iain, one for you? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org Last reconfirmed|2006-02-13 17:22:54 |2010-07-20 14:04:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26262
[Bug rtl-optimization/20972] Register allocator/reload uses auto-inc register in non-addressing operand
--- Comment #14 from steven at gcc dot gnu dot org 2010-07-20 14:06 --- If it works for Ramana, it works for me. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20972
[Bug target/30254] Need method to determine if AltiVec PIM is available
-- steven at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30254
[Bug rtl-optimization/43494] Overlooked dependency causes wrong scheduling, wrong code
--- Comment #14 from steven at gcc dot gnu dot org 2010-07-20 17:56 --- The options -O2 -fno-inline is enough to make the test case of comment #5 fail. This bug is not specific to -fpic / -fPIC, inlining of f1 just hides the bug for the non-PIC case. -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|gcc.c- |Overlooked dependency causes |torture/execute/vector-2.c |wrong scheduling, wrong code |fails with -fpic/-fPIC | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug rtl-optimization/43494] [4.4/4.5/4.6 Regression] Overlooked dependency causes wrong scheduling, wrong code
--- Comment #15 from steven at gcc dot gnu dot org 2010-07-20 18:08 --- Works with gcc-4.3 (Debian 4.3.5-1) 4.3.5, both with -fpic and with -fno-inline. That makes this bug a regression. CC:RM - who happens to know a thing or two about the alias analysis code also. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Known to work||4.3.5 Summary|Overlooked dependency causes|[4.4/4.5/4.6 Regression] |wrong scheduling, wrong code|Overlooked dependency causes ||wrong scheduling, wrong code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug tree-optimization/31849] [4.3/4.4/4.5/4.6 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)
--- Comment #53 from steven at gcc dot gnu dot org 2010-07-20 22:12 --- Could the OP be so kind to see if this is still a problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
[Bug web/15669] Usage of bugzilla Known to work and known to fail fields need documentation
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-20 22:15 --- Fixed with patch of comment #2. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15669
[Bug middle-end/41639] synchronisation primitives take unsigned as input and output values.
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-20 22:21 --- Mis-categorized as a treelang bug (?!). rth, you added these primitive types and the _sync_* builtins... Could you have a look at this bug and at the patch of comment #1, please? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org Component|treelang|middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41639
[Bug translation/32637] Swedish translation error
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-20 22:26 --- sv.po for gcc 4.5.0 has the fixed translation. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32637
[Bug debug/45006] [4.6 regression] Failed to bootstrap
--- Comment #6 from steven at gcc dot gnu dot org 2010-07-20 22:32 --- I have forwarded this problem to the French team of the Translation Project (http://translationproject.org/team/fr.html). -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2010-07-20 16:09:39 |2010-07-20 22:32:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45006
[Bug debug/45006] [4.6 regression] Failed to bootstrap
--- Comment #7 from steven at gcc dot gnu dot org 2010-07-20 22:33 --- obviously that latest comment was not for this bug (but for bug 32428), sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45006
[Bug translation/32428] odd french translation of strict aliasing -related warnings
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-20 22:33 --- I have forwarded this problem to the French team of the Translation Project (http://translationproject.org/team/fr.html). -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-20 22:33:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32428
[Bug translation/40884] error messages in .md files not translated
--- Comment #1 from steven at gcc dot gnu dot org 2010-07-20 22:37 --- Why should an .md file call error()? The ones in neon.md look like they should be internal_error, or something should catch the problem earlier. Should internal_error messages be translated? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-20 22:37:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40884
[Bug translation/39544] Grammar error in russian localization
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-20 22:40 --- Closing as invalid because the bug should be reported to the translation team for Russian (http://translationproject.org/team/ru.html). -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39544
[Bug translation/38173] Mistake in Russian translation of error text functional cast expression list treated as compound expression
--- Comment #1 from steven at gcc dot gnu dot org 2010-07-20 22:43 --- So, another translation bug that fell through the cracks. Unfortunately the GCC project does not maintain its own translations. This is taken care of by the Translation Project. The translation team for Russian has a web page here: http://translationproject.org/team/ru.html. Could you please file the bug there, instead? The bug is a Translation Project bug, and not a GCC bug, so I'm closing this as INVALID for GCC. Thanks for the report and sorry for the late reply. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38173
[Bug translation/36958] typos in french translation.
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-20 22:44 --- See http://translationproject.org/team/fr.html. Not a valid GCC bug report. Please do report the problem to the translation team for French. We should have some kind of forwarding system for this... -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36958
[Bug translation/32428] odd french translation of strict aliasing -related warnings
--- Comment #5 from steven at gcc dot gnu dot org 2010-07-20 22:45 --- Not a GCC bug = closing as INVALID for gcc. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32428
[Bug translation/39873] Wrong translation of output gcc -c -Q -march=core2 --help=target to Russian
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-20 22:46 --- Not a valid bug for GCC. Please report to the translation team for Russian instead, see http://translationproject.org/team/ru.html. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39873
[Bug rtl-optimization/41188] move_invariant_reg() damages CBRANCH instructions with CLOBBER attribute
--- Comment #12 from steven at gcc dot gnu dot org 2010-07-20 22:50 --- Someone should dust off the patch and submit it for trunk. Joern? -- steven at gcc dot gnu dot org changed: What|Removed |Added Component|regression |rtl-optimization Last reconfirmed|2009-08-31 06:20:14 |2010-07-20 22:50:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41188
[Bug rtl-optimization/44281] [4.3/4.4/4.5/4.6 Regression] Global Register variable pessimisation
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|regression |rtl-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-20 22:52:46 date|| Summary|Global Register variable|[4.3/4.4/4.5/4.6 Regression] |pessimisation and regression|Global Register variable ||pessimisation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44281
[Bug regression/43867] ICE on valid with PGO and -fwhole-program options on small example (istringstream) with gcc 4.5.0 only
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-20 22:53 --- Martin, PGO and IPA-CP -- isn't that your area of interest? :-) -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-20 22:53:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43867
[Bug target/43750] -march unconditionally added to COLLECT_GCC_OPTIONS
--- Comment #6 from steven at gcc dot gnu dot org 2010-07-20 22:56 --- Uros, what do you think of this bug, as i386 arch maintainer? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||uros at gcc dot gnu dot org Component|regression |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43750
[Bug middle-end/44982] [4.3/4.4/4.5/4.6 Regression] ICE in get_narrower, at tree.c:7832
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-19 09:58 --- Should be easy, this one. I like easy. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-07-19 09:12:57 |2010-07-19 09:58:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44982
[Bug rtl-optimization/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
--- Comment #8 from steven at gcc dot gnu dot org 2010-07-19 19:04 ---
Offending insns that are scheduled in the wrong order:
(insn:TI 28 48 9 2 vector-2.c:7 (set (reg:DI 9 r9 [+8 ])
(mem/c/i:DI (reg/f:DI 14 r14 [351]) [2 t+8 S8 A64])) 5 {movdi_internal}
(expr_list:REG_DEAD (reg/f:DI 14 r14 [351])
(nil)))
(insn 9 28 18 2 vector-2.c:5 (set (mem/s/j/c:SI (reg/f:DI 15 r15 [343]) [2 t+4
S4 A32])
(reg:SI 114 r34 [ a ])) 4 {movsi_internal} (expr_list:REG_DEAD (reg:SI
114 r34 [ a ])
(expr_list:REG_DEAD (reg/f:DI 15 r15 [343])
(nil
So the MEMs are:
load from (mem/c/i:DI (reg/f:DI 14 r14 [351]) [2 t+8 S8 A64])
store to (mem/s/j/c:SI (reg/f:DI 15 r15 [343]) [2 t+4 S4 A32])
There is no dependency of insn 28 on insn 9, even though this is a rather
obvious read-after-write dependency.
;; ==
;; -- basic block 2 from 30 to 39 -- after reload
;; ==
;; --- forward dependences:
;; --- EBB Dependences --- from bb2 to bb2
;; insn codebb dep prio cost reservation
;; -- --- ---
;; 30 5 2 0 3 1 2_A : 39 9 36 35
;; 29 5 2 0 2 1 2_A : 39 28 21
;; 35 5 2 1 2 1 2_M_only_um23 : 39 21 9 36
;; 36 5 2 2 1 1 2_M_only_um23 : 39 28 9
;;9 4 2 3 0 1 2_M_only_um23 : 39
;; 21 5 2 2 1 1 2_M_only_um01 : 39 18 28
;; 28 5 2 3 0 1 2_M_only_um01 : 39 18
;; 18-1 2 2 0 0 nothing : 39
;; 39 334 2 8 0 0 2_B :
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug rtl-optimization/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
--- Comment #5 from steven at gcc dot gnu dot org 2010-07-18 17:21 ---
It looks like a store is scheduled wrong.
Slightly reduced test case:
-- 8 #define vector
__attribute__((vector_size(16) ))
vector int f1(vector int t, int a)
{
((int*)t)[1] = a;
return t;
}
int main(void)
{
vector int a = {0, 0, 0, 0};
vector int c = {0, 1, 0, 0};
vector int a0;
a0 = f1(a, 1);
if (memcmp (a0, c, sizeof(a0)))
__builtin_abort ();
return 0;
}
-- 8
Compiled at -O2 -fno-inline -fpic this will abort. The assembler output for
f1 is this:
6 .global f1#
7 .type f1#, @function
8 .proc f1#
9 f1:
10 .prologue
11 .body
12 .mmi
13 mov r15 = r12
14 nop 0
15 mov r14 = r12
16 ;;
17 .mmi
18 st8 [r15] = r32, 8
19 ;;
20 st8 [r15] = r33, -4
21 nop 0
22 .mii
23 ld8 r8 = [r14], 8
24 nop 0
25 ;;
26 nop 0
27 .mmb
28 ld8 r9 = [r14]
29 st4 [r15] = r34
30 br.ret.sptk.many b0
31 .endp f1#
The store on line 29 looked suspicious because the three stores (lines 18, 20,
and 29) are together in the unscheduled version (i.e. with
-fno-schedule-insns2, lines 15, 17, and 19):
6 .global f1#
7 .type f1#, @function
8 .proc f1#
9 f1:
10 .prologue
11 .body
12 mov r15 = r12
13 mov r14 = r12
14 ;;
15 st8 [r15] = r32, 8
16 ;;
17 st8 [r15] = r33, -4
18 ;;
19 st4 [r15] = r34
20 ld8 r8 = [r14], 8
21 ;;
22 ld8 r9 = [r14]
23 br.ret.sptk.many b0
24 ;;
25 .endp f1#
The abort goes away if I hack the assembly manually with an extra bundle to
move the three stores back together:
.global f1# .global f1#
.type f1#, @function .type f1#, @function
.proc f1# .proc f1#
f1: f1:
.prologue .prologue
.body .body
.mmi.mmi
mov r15 = r12 mov r15 = r12
nop 0 nop 0
mov r14 = r12 mov r14 = r12
;; ;;
.mmi.mmi
st8 [r15] = r32, 8 st8 [r15] = r32, 8
;; ;;
st8 [r15] = r33, -4 st8 [r15] = r33, -4
nop 0 nop 0
;;
.mii
st4 [r15] = r34
nop 0
nop 0
.mii.mii
ld8 r8 = [r14], 8 ld8 r8 = [r14], 8
nop 0 nop 0
;; ;;
nop 0 nop 0
.mmb.mmb
ld8 r9 = [r14] ld8 r9 = [r14]
st4 [r15] = r34 | nop 0
br.ret.sptk.many b0 br.ret.sptk.many b0
.endp f1# .endp f1#
I am not an ia64 expert, but I see no reason why moving the store is a bad
idea. Will have to look at the RTL, and if that doesn't help I'll leave this to
a target specialist.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug rtl-optimization/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
--- Comment #6 from steven at gcc dot gnu dot org 2010-07-18 17:29 --- Smaller hand-changed assembly without new bundle (left aborts, right does not): .global f1# .global f1# .type f1#, @function .type f1#, @function .proc f1# .proc f1# f1: f1: .prologue .prologue .body .body .mmi.mmi mov r15 = r12 mov r15 = r12 nop 0 nop 0 mov r14 = r12 mov r14 = r12 ;; ;; .mmi.mmi st8 [r15] = r32, 8 st8 [r15] = r32, 8 ;; ;; st8 [r15] = r33, -4 st8 [r15] = r33, -4 nop 0 nop 0 .mii | ;; .mmb st4 [r15] = r34 ;; ld8 r8 = [r14], 8 ld8 r8 = [r14], 8 nop 0 ;; ;; nop 0 nop 0 .mmb.mmb ld8 r9 = [r14] ld8 r9 = [r14] st4 [r15] = r34 | nop 0 br.ret.sptk.many b0 br.ret.sptk.many b0 .endp f1# .endp f1# The only thing that seems to matter, is that st4 [r15] = r34 comes before ld8 r9 = [r14]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug rtl-optimization/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
--- Comment #7 from steven at gcc dot gnu dot org 2010-07-18 17:40 --- Ah, and since both r14 and r15 are initially copies of r12, they point to the same memory area (modulo auto-increments/decrements). So indeed an alias thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug rtl-optimization/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
