[Bug target/67351] Missed optimisation on 64-bit field compared to 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67351
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
||ubizjak at gmail dot com
--- Comment #3 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Uroš Bizjak from comment #2)
(In reply to Allan Jensen from comment #0)
Gcc will expand and detect field setting on 32-bit integers, but for some
reason miss the opportunity on 64-bit.
The immediates for 64bit logic insns are limited to sign-extended 32bit
values, so this probably limits combine to combine several insns into one.
One example is:
(insn 8 6 9 2 (parallel [
(set (reg:DI 100)
(lshiftrt:DI (reg/v:DI 98 [ a ])
(const_int 48 [0x30])))
(clobber (reg:CC 17 flags))
]) test.cpp:63 538 {*lshrdi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 9 8 10 2 (parallel [
(set (reg:DI 101)
(ashift:DI (reg:DI 100)
(const_int 48 [0x30])))
(clobber (reg:CC 17 flags))
]) test.cpp:63 504 {*ashldi3_1}
(expr_list:REG_DEAD (reg:DI 100)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
combine tries to:
Trying 8 - 9:
Failed to match this instruction:
(parallel [
(set (reg:DI 101)
(and:DI (reg/v:DI 98 [ a ])
(const_int -281474976710656 [0x])))
(clobber (reg:CC 17 flags))
])
However, tree optimizers pass to expand the following sequence:
a = giveMe64 ();
a$rgba_5 = MEM[(struct MyRgba64 *)a];
_6 = a$rgba_5 16;
_7 = a$rgba_5 48;
_8 = _7 48;
_10 = _6 16;
_11 = _10 4294967295;
_13 = a$rgba_5 65535;
_15 = _13 | 264913582817280;
_16 = _8 | _15;
_14 = _11 | _16;
MEM[(struct MyRgba64 *)D.2451] = _14;
return D.2451;
Richi, can these shifts be converted to equivalent masking in tree optimizers?
[Bug target/67351] Missed optimisation on 64-bit field compared to 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67351
--- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Uroš Bizjak from comment #3)
(In reply to Uroš Bizjak from comment #2)
(In reply to Allan Jensen from comment #0)
Gcc will expand and detect field setting on 32-bit integers, but for some
reason miss the opportunity on 64-bit.
The immediates for 64bit logic insns are limited to sign-extended 32bit
values, so this probably limits combine to combine several insns into one.
One example is:
(insn 8 6 9 2 (parallel [
(set (reg:DI 100)
(lshiftrt:DI (reg/v:DI 98 [ a ])
(const_int 48 [0x30])))
(clobber (reg:CC 17 flags))
]) test.cpp:63 538 {*lshrdi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 9 8 10 2 (parallel [
(set (reg:DI 101)
(ashift:DI (reg:DI 100)
(const_int 48 [0x30])))
(clobber (reg:CC 17 flags))
]) test.cpp:63 504 {*ashldi3_1}
(expr_list:REG_DEAD (reg:DI 100)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
combine tries to:
Trying 8 - 9:
Failed to match this instruction:
(parallel [
(set (reg:DI 101)
(and:DI (reg/v:DI 98 [ a ])
(const_int -281474976710656 [0x])))
(clobber (reg:CC 17 flags))
])
However, tree optimizers pass to expand the following sequence:
a = giveMe64 ();
a$rgba_5 = MEM[(struct MyRgba64 *)a];
_6 = a$rgba_5 16;
_7 = a$rgba_5 48;
_8 = _7 48;
_10 = _6 16;
_11 = _10 4294967295;
_13 = a$rgba_5 65535;
_15 = _13 | 264913582817280;
_16 = _8 | _15;
_14 = _11 | _16;
MEM[(struct MyRgba64 *)D.2451] = _14;
return D.2451;
Richi, can these shifts be converted to equivalent masking in tree
optimizers?
They should be or at least Naveen's patches should handle them. There is an
open bug filed doing a N N and one filed for a N N already (I filed
it).
[Bug target/67351] Missed optimisation on 64-bit field compared to 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67351 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- Oh his patch only handled multiplies/divide and not shifts. But it should be easy to add them to match.pd to simplify this at the tree level.
[Bug target/67351] Missed optimisation on 64-bit field compared to 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67351 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Allan Jensen from comment #0) Gcc will expand and detect field setting on 32-bit integers, but for some reason miss the opportunity on 64-bit. The immediates for 64bit logic insns are limited to sign-extended 32bit values, so this probably limits combine to combine several insns into one.
[Bug target/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67317 --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Segher Boessenkool from comment #3) Does this need to be an unspec at all? Of course not. We are looking to replace unspecs with standard RTXes. Do you have any recommendation on how we can represent this carry-setting insn to satisfy combine?
[Bug middle-end/67351] Missed optimisation on 64-bit field compared to 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67351 --- Comment #1 from Allan Jensen linux at carewolf dot com --- Created attachment 36254 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36254action=edit Compiled test assembler
[Bug middle-end/67330] ICE handling weak attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67330 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Let me see what others think.
[Bug tree-optimization/66372] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66372 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- This seems to be fixed now.
[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67005 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Marek Polacek from comment #6) Hm, adding || (e2-flags EDGE_IRREDUCIBLE_LOOP) doesn't work; the E2 edge doesn't have the EDGE_IRREDUCIBLE_LOOP flag, even if I recompute that flag via mark_irreducible_loops. So maybe set LOOPS_NEED_FIXUP every time we remove an edge? I did some measurements on a GCC regtest. The edge removal was triggered ~13000 times, but for only ~4000 out of that was loop_exit_edge_p (bb-loop_father, e) true -- setting LOOPS_NEED_FIXUP unconditionally would be maybe too expensive thus.
[Bug target/67272] [HSA] register allocator expects that every register must be assigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67272 --- Comment #5 from Michael Matz matz at gcc dot gnu.org --- Author: matz Date: Tue Aug 25 16:02:38 2015 New Revision: 227176 URL: https://gcc.gnu.org/viewcvs?rev=227176root=gccview=rev Log: PR target/67272 PR target/67296 * hsa.h (hsa_function_representation): Remove prologue member. * hsa-dump.c (dump_hsa_cfun): Iterator over all BBs. * hsa-gen.c (hsa_function_representation): Don't init prologue, start with zero bbs. (hsa_function_representation::get_shadow_reg): Use entry block, not prologue member. (hsa_init_data_for_cfun): Create hsa_bb for entry/exit blocks. (hsa_deinit_data_for_cfun): Deallocate also for entry/exit blocks. (gen_hsa_insns_for_kernel_call): Don't use UINT64_MAX, but the built-in max value of the type. (gen_function_def_parameters): Don't use prologue member, but the hsa bb for entry bb. (wrap_all_hsa_calls): Iterate over all BBs. * hsa-regalloc.c (naive_process_phi): Revert 2015-08-19 change. (naive_outof_ssa): Iterate over all BBs. (dump_hsa_cfun_regalloc): Ditto. (linear_scan_regalloc): Ditto. (regalloc): Ditto. Modified: branches/hsa/gcc/ChangeLog.hsa branches/hsa/gcc/hsa-dump.c branches/hsa/gcc/hsa-gen.c branches/hsa/gcc/hsa-regalloc.c branches/hsa/gcc/hsa.h
[Bug target/67296] [HSA] ICE in register allocator (assignment of this argument in a ctor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67296 --- Comment #1 from Michael Matz matz at gcc dot gnu.org --- Author: matz Date: Tue Aug 25 16:02:38 2015 New Revision: 227176 URL: https://gcc.gnu.org/viewcvs?rev=227176root=gccview=rev Log: PR target/67272 PR target/67296 * hsa.h (hsa_function_representation): Remove prologue member. * hsa-dump.c (dump_hsa_cfun): Iterator over all BBs. * hsa-gen.c (hsa_function_representation): Don't init prologue, start with zero bbs. (hsa_function_representation::get_shadow_reg): Use entry block, not prologue member. (hsa_init_data_for_cfun): Create hsa_bb for entry/exit blocks. (hsa_deinit_data_for_cfun): Deallocate also for entry/exit blocks. (gen_hsa_insns_for_kernel_call): Don't use UINT64_MAX, but the built-in max value of the type. (gen_function_def_parameters): Don't use prologue member, but the hsa bb for entry bb. (wrap_all_hsa_calls): Iterate over all BBs. * hsa-regalloc.c (naive_process_phi): Revert 2015-08-19 change. (naive_outof_ssa): Iterate over all BBs. (dump_hsa_cfun_regalloc): Ditto. (linear_scan_regalloc): Ditto. (regalloc): Ditto. Modified: branches/hsa/gcc/ChangeLog.hsa branches/hsa/gcc/hsa-dump.c branches/hsa/gcc/hsa-gen.c branches/hsa/gcc/hsa-regalloc.c branches/hsa/gcc/hsa.h
[Bug middle-end/67351] New: Missed optimisation on 64-bit field compared to 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67351 Bug ID: 67351 Summary: Missed optimisation on 64-bit field compared to 32-bit Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: linux at carewolf dot com Target Milestone: --- Created attachment 36253 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36253action=edit Test Gcc will expand and detect field setting on 32-bit integers, but for some reason miss the opportunity on 64-bit. This was discovered as gcc was inexplicably slower compared to clang on the 64-bit case but not when using 32bit.
[Bug target/67296] [HSA] ICE in register allocator (assignment of this argument in a ctor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67296 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Michael Matz matz at gcc dot gnu.org --- Fixed more completely than for PR 67272, so the fix for that one is superseded as well.
[Bug middle-end/64544] ../../gcc-svn/gcc/cgraphunit.c:2183:1: internal compiler error: in check_probability, at basic-block.h:581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64544 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Should be fixed. If not, please reopen and be sure to add a preprocessed source file.
[Bug tree-optimization/67349] [5 regression] ICE on optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67349
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Target|h8300 |
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-08-25
CC||trippels at gcc dot gnu.org
Component|target |tree-optimization
Summary|ICE on optimization |[5 regression] ICE on
||optimization
Ever confirmed|0 |1
--- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Trunk and gcc-4.9 are fine.
trippels@gcc2-power8 ~ % cat syn.i
struct list_head
{
struct list_head *prev;
};
extern void __wait_rcu_gp (void*);
const int a = sizeof 0;
static inline __attribute__ ((always_inline no_instrument_function)) void
rcu_barrier_sched (void)
{
struct list_head b[a];
__wait_rcu_gp (b);
}
static inline __attribute__ ((always_inline no_instrument_function)) void
rcu_barrier (void)
{
rcu_barrier_sched ();
}
struct
{
void *wait;
} c[] = { rcu_barrier, rcu_barrier_sched };
trippels@gcc2-power8 ~ % /home/trippels/gcc_5/usr/local/bin/gcc -c -O2 syn.i
syn.i: In function ‘rcu_barrier_sched’:
syn.i:8:1: internal compiler error: Segmentation fault
rcu_barrier_sched (void)
^
0x107e9053 crash_signal
../../gcc/gcc/toplev.c:383
0x10937a64 tree_check
../../gcc/gcc/tree.h:2850
0x10937a64 fold_builtin_alloca_with_align
../../gcc/gcc/tree-ssa-ccp.c:2067
0x10937a64 ccp_fold_stmt
../../gcc/gcc/tree-ssa-ccp.c:2172
0x109d85a3
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-propagate.c:1177
0x10dd228b dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:188
0x109d7993 substitute_and_fold(tree_node* (*)(tree_node*), bool
(*)(gimple_stmt_iterator*), bool)
../../gcc/gcc/tree-ssa-propagate.c:1272
0x1092f0eb ccp_finalize
../../gcc/gcc/tree-ssa-ccp.c:941
0x1092f0eb do_ssa_ccp
../../gcc/gcc/tree-ssa-ccp.c:2382
0x1092f0eb execute
../../gcc/gcc/tree-ssa-ccp.c:2414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/67055] [5/6 Regression] Segmentation fault in fold_builtin_alloca_with_align in tree-ssa-ccp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67055 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||ysato at users dot sourceforge.jp --- Comment #12 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 67349 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/67349] [5 regression] ICE on optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67349 --- Comment #3 from Yoshinori Sato ysato at users dot sourceforge.jp --- I tested gcc version 6.0.0 20150710 (experimental) (GCC) I'll trying latest trunk. Thanks,
[Bug inline-asm/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67317 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-08-25 Ever confirmed|0 |1
[Bug middle-end/67340] [6 Regression] ICE: in convert_move, at expr.c:279
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67340 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||hppa*-*-* CC||aoliva at gcc dot gnu.org Target Milestone|--- |6.0
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #27 from Joshua Kinard kumba at gentoo dot org --- (In reply to Richard Biener from comment #26) Don't hold your breath. Basically somebody who can reproduce it has to find the root-cause and a fix. 4.9.3 works, and the problem appears specific to genmatch with the '--gimple' argument. I guess I can test to see if 5.0.0 is also affected, and then start diffing the genmatch.c files between working/non-working version to trace the problem down. That will be quicker than git bisecting on these machines (old SGI machines). Can't stay stuck on 4.9.x forever...
[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67005 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Still ICEs; probably it's just about adding loops_state_set (LOOPS_NEED_FIXUP); somewhere into tree-ssa-dce.c?
[Bug tree-optimization/67349] [5 regression] ICE on optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67349 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- dup. *** This bug has been marked as a duplicate of bug 67055 ***
[Bug tree-optimization/67055] [5 Regression] Segmentation fault in fold_builtin_alloca_with_align in tree-ssa-ccp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67055
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Summary|[5/6 Regression]|[5 Regression] Segmentation
|Segmentation fault in |fault in
|fold_builtin_alloca_with_al |fold_builtin_alloca_with_al
|ign in tree-ssa-ccp.c |ign in tree-ssa-ccp.c
--- Comment #13 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Another testcase:
trippels@gcc2-power8 ~ % cat syn.i
struct list_head
{
struct list_head *prev;
};
extern void __wait_rcu_gp (void*);
const int a = sizeof 0;
static inline __attribute__ ((always_inline no_instrument_function)) void
rcu_barrier_sched (void)
{
struct list_head b[a];
__wait_rcu_gp (b);
}
static inline __attribute__ ((always_inline no_instrument_function)) void
rcu_barrier (void)
{
rcu_barrier_sched ();
}
struct
{
void *wait;
} c[] = { rcu_barrier, rcu_barrier_sched };
trippels@gcc2-power8 ~ % /home/trippels/gcc_5/usr/local/bin/gcc -c -O2 syn.i
syn.i: In function ‘rcu_barrier_sched’:
syn.i:8:1: internal compiler error: Segmentation fault
rcu_barrier_sched (void)
^
0x107e9053 crash_signal
../../gcc/gcc/toplev.c:383
0x10937a64 tree_check
../../gcc/gcc/tree.h:2850
0x10937a64 fold_builtin_alloca_with_align
../../gcc/gcc/tree-ssa-ccp.c:2067
0x10937a64 ccp_fold_stmt
../../gcc/gcc/tree-ssa-ccp.c:2172
0x109d85a3
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-propagate.c:1177
0x10dd228b dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:188
0x109d7993 substitute_and_fold(tree_node* (*)(tree_node*), bool
(*)(gimple_stmt_iterator*), bool)
../../gcc/gcc/tree-ssa-propagate.c:1272
0x1092f0eb ccp_finalize
../../gcc/gcc/tree-ssa-ccp.c:941
0x1092f0eb do_ssa_ccp
../../gcc/gcc/tree-ssa-ccp.c:2382
0x1092f0eb execute
../../gcc/gcc/tree-ssa-ccp.c:2414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target|powerpc-darwin |powerpc-darwin, ||mips64-linux-n32 Status|WAITING |NEW --- Comment #26 from Richard Biener rguenth at gcc dot gnu.org --- Don't hold your breath. Basically somebody who can reproduce it has to find the root-cause and a fix.
[Bug c++/67313] [6 Regression] ICE: in vague_linkage_p, at cp/decl2.c:1878 with -fno-weak and variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67313 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c++/67315] [4.9 Regression] Strange 'this' pointer behavior when calling virtual function with different optimization attributes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67315 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.4
[Bug c++/67315] [4.9 Regression] Strange 'this' pointer behavior when calling virtual function with different optimization attributes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67315 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I think this is a dup of the bug with the i386 backend issue of local calling conventions and its interaction with optimization attributes (optimize setting). Somebody find it ... ;)
[Bug tree-optimization/67326] [5/6 Regression] -ftree-loop-if-convert-stores does not vectorize conditional assignment (anymore)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67326 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||missed-optimization Last reconfirmed||2015-08-25 CC||rguenth at gcc dot gnu.org, ||venkataramanan.kumar at amd dot co ||m Ever confirmed|0 |1 Summary|[5.2/6.0 regression]|[5/6 Regression] |-ftree-loop-if-convert-stor |-ftree-loop-if-convert-stor |es does not vectorize |es does not vectorize |conditional assignment |conditional assignment |(anymore) |(anymore) Target Milestone|--- |6.0 Severity|normal |enhancement --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- This is because in condAssign1 v3 is not accessed always and thus we do not know (ok, stupid ifcvt limitation) that v3[i] is not accessed out-of-bounds. Previous to 2015-07-10 Richard Biener rguent...@suse.de PR tree-optimization/66823 * tree-if-conv.c (memrefs_read_or_written_unconditionally): Fix inverted predicate. ifcvt's reasoning was oh, v3[i] is _not_ equal to v2[i] which is always accessed, thus it's fine to access it always as well. I fixed this bug but did not try to enhance ifcvts idea of what operations can trap (v3[i] is thought to eventually trap because we do not try to analyze what values 'i' can have). So in 4.9 and earlier this only works becuase of the above bug. So, kind of confirmed, but it's really an enhancement request. AFAIR Venkat is working in this area.
[Bug c++/67315] [4.9 Regression] Strange 'this' pointer behavior when calling virtual function with different optimization attributes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67315 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- PR 54068 ?
[Bug tree-optimization/67312] [6 Regression] ICE: SIGSEGV in expand_expr_real_1 (expr.c:9561) with -ftree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67312 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- We shouldn't do coalesce-vars at -O0 I think.
[Bug middle-end/67118] gcc and gfortran started crashing recently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67118 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-08-25 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Severity|blocker |normal
[Bug middle-end/67298] [6 Regression] 254.gap in SPEC CPU 2000 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67298 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-08-25 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Probably INVALID then...
[Bug middle-end/66984] ICE: fold_binary changes type of operand, causing failure in verify_gimple_assign_binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- Assuming fixed then.
[Bug target/67349] ICE on optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67349 Mikhail Maltsev miyuki at gcc dot gnu.org changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #1 from Mikhail Maltsev miyuki at gcc dot gnu.org --- I cannot reproduce this with current trunk (h8300 cross), but earlier revisions (including 5.2 release) do crash even on x86_64. I suppose this is the same bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67055#c9 Please provide the output of h8300-unknown-linux-gcc -v.
[Bug middle-end/67341] [ICE] libgo build failure: in mark_stmt_if_obviously_necessary, at tree-ssa-dce.c:278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67341 Mikhail Maltsev miyuki at gcc dot gnu.org changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #1 from Mikhail Maltsev miyuki at gcc dot gnu.org --- Probably a dup of PR67284. At least for me bootstrap passes even with -O3 (with --enable-checking=yes, though) with r227145.
[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021
--- Comment #21 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Bill Schmidt from comment #20)
We still don't vectorize the original code example on Power. It appears
that this is being disabled because of an alignment issue. The data
references are being rejected by:
product.f:9:0: note: can't force alignment of ref: REALPART_EXPR
*a.0_24[_50]
and similar for the other three DRs. This happens due to this code in
vect_compute_data_ref_alignment:
if (base_alignment TYPE_ALIGN (vectype))
{
/* Strip an inner MEM_REF to a bare decl if possible. */
if (TREE_CODE (base) == MEM_REF
integer_zerop (TREE_OPERAND (base, 1))
TREE_CODE (TREE_OPERAND (base, 0)) == ADDR_EXPR)
base = TREE_OPERAND (TREE_OPERAND (base, 0), 0);
if (!vect_can_force_dr_alignment_p (base, TYPE_ALIGN (vectype)))
{
if (dump_enabled_p ())
{
dump_printf_loc (MSG_NOTE, vect_location,
can't force alignment of ref: );
dump_generic_expr (MSG_NOTE, TDF_SLIM, ref);
dump_printf (MSG_NOTE, \n);
}
return true;
}
Here TYPE_ALIGN (vectype) is 128 (Power vectors are normally aligned on a
128-bit value), and base_alignment is 64. a.0 is defined as:
complex(kind=8) [0:D.1831] * restrict a.0;
In both ELFv1 and ELFv2 ABIs for Power, a complex type is defined to have
the same alignment as the underlying type. So complex double has 8-byte
alignment.
On earlier versions of Power, the decision is fine, because unaligned
accesses are expensive prior to POWER8. With POWER8, though, an unaligned
access will (most of the time) perform as well as an aligned access. So
ideally we would like to teach the vectorizer to allow vectorization here.
It seems like vect_supportable_dr_alignment ought to be considered as part
of the SLP vectorization decision here, rather than just comparing the base
alignment with the vector type alignment. Adding a check for that allows
things to get a little further, but we still don't vectorize the block. (I
haven't yet looked into why, but I assume more needs to be done downstream
to handle this case.)
My understanding of the vectorizer is not yet very deep, so before going too
far down the wrong path, I'd like your opinion on the best approach to
fixing the problem. Thanks!
I see it only failing due to cost issues (tried ppc64le and -mcpu=power8).
The unaligned loads cost 3 and we end up with
t.f90:8:0: note: Cost model analysis:
Vector inside of loop cost: 40
Vector prologue cost: 8
Vector epilogue cost: 4
Scalar iteration cost: 12
Scalar outside cost: 6
Vector outside cost: 12
prologue iterations: 0
epilogue iterations: 0
t.f90:8:0: note: cost model: the vector iteration cost = 40 divided by the
scalar iteration cost = 12 is greater or equal to the vectorization factor = 1.
Note that we are (still) not very good in estimating the SLP cost as we
account 4 vector loads here (because we essentially will end up with
4 different permutations used), so the unaligned part is accounted for
too much and likely the permutation cost as well. Both are a limitation
of the SLP data structures and not easily fixable. With
-fvect-cost-model=unlimited I see both loops vectorized.
Bill
[Bug tree-optimization/67328] range test rather than single bit test for code testing enum values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67328
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2015-08-25
Ever confirmed|0 |1
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Note this is already fold-const.c:optimize_bit_field_compare at work. With
-DALT (non-working code) we get
;; Function test_pic (null)
;; enabled by -tree-original
{
if ((BIT_FIELD_REF *info, 8, 0 3) + 254 = 1)
and
;; Function test_exe (null)
;; enabled by -tree-original
{
if ((SAVE_EXPR BIT_FIELD_REF *info, 8, 0 3) == 0 || (SAVE_EXPR
BIT_FIELD_REF *info, 8, 0 3) == 2)
from it. Without -DALT
;; Function test_pic (null)
;; enabled by -tree-original
{
if ((SAVE_EXPR BIT_FIELD_REF *info, 8, 0 3) == 3 || (SAVE_EXPR
BIT_FIELD_REF *info, 8, 0 3) == 1)
;; Function test_exe (null)
;; enabled by -tree-original
{
if ((BIT_FIELD_REF *info, 8, 0 3) = 1)
I see more that a single bit test for both cases btw, mostly because we
need to mask the padding. Not sure what optimal code you expect here.
[Bug c++/67318] [6 regression] Parsing error when using abbreviated integral type names in template parameter pack declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67318 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug debug/67293] Very large DW_AT_const_value produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67293 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #2) I'm fine with introducing some limit on the size of const values, with a param. As for the other question, I think you've answered that yourself, if the const ends up in the source, then that is supposedly because something needed its address. At that point it is much better to be able to print that address in the debugger. If you want to stream DW_AT_const_value early and actually rewrite the DWARF during LTO later, rather than just reference unmodified DIEs from other DIEs, then you could if you end up having an address actually remove the DW_AT_const_value and replace it with DW_AT_location if possible. A DWARF optimizer could do this indeed. With the current laid out scheme for LTO debug we will add a DW_AT_location late if the object is instantiated thus the debugger will see both. But I will have to pro-actively add the DW_AT_const_value early in case the object doesn't get emitted - but I definitely want to limit the size of the eventually pointless DWARF. I can do the re-writing (remove DW_AT_const_value if we have a location) for the non-LTO path though (and also try adding a DW_AT_const_value with a larger size-cut-off if we don't).
[Bug target/67349] New: ICE on optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67349 Bug ID: 67349 Summary: ICE on optimization Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ysato at users dot sourceforge.jp Target Milestone: --- Created attachment 36252 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36252action=edit problem source I got following error. $ LANG=C h8300-unknown-linux-gcc -c -O2 -fconserve-stack sync.c In file included from include/linux/rcupdate.h:429:0, from include/linux/rcusync.h:5, from kernel/rcu/sync.c:1: include/linux/rcutiny.h: In function 'rcu_barrier_sched': include/linux/rcutiny.h:55:91: internal compiler error: Segmentation fault 0xb11f6f crash_signal ../../gcc/toplev.c:352 0xc1fe56 tree_check ../../gcc/tree.h:2857 0xc1fe56 fold_builtin_alloca_with_align ../../gcc/tree-ssa-ccp.c:2110 0xc1fe56 ccp_fold_stmt ../../gcc/tree-ssa-ccp.c:2215 0xca6cba substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) ../../gcc/tree-ssa-propagate.c:1226 0xe6a7f7 dom_walker::walk(basic_block_def*) ../../gcc/domwalk.c:177 0xca64a9 substitute_and_fold(tree_node* (*)(tree_node*), bool (*)(gimple_stmt_iterator*), bool) ../../gcc/tree-ssa-propagate.c:1319 0xc17efc ccp_finalize ../../gcc/tree-ssa-ccp.c:951 0xc17efc do_ssa_ccp ../../gcc/tree-ssa-ccp.c:2410 0xc17efc execute ../../gcc/tree-ssa-ccp.c:2442 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. without -fconserve-stack in no problem.
[Bug c++/67350] New: auto deduction error in variable template lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67350
Bug ID: 67350
Summary: auto deduction error in variable template lambda
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: norbert.pfeiler+gcc.gnu.org/bugzilla at gmail dot com
Target Milestone: ---
templatetypename T
auto test = [](){
return T{};
};
int main() {
testint();
}
error: use of 'testint' before deduction of 'auto'
Clang 3.6.2 accepts…
I’m not exactly sure this code is valid, but i can’t find much about variable
templates and lambdas.
[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67005 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Note we already do /* If we made a BB unconditionally exit a loop then this transform alters the set of BBs in the loop. Schedule a fixup. */ if (loop_exit_edge_p (bb-loop_father, e)) loops_state_set (LOOPS_NEED_FIXUP); remove_edge (e2); thus this would need to add sth like || e2-flags IRREDUCIBLE_LOOP
[Bug tree-optimization/67323] Use non-unit stride loads by preference when applicable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67323 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-25 CC|richard.guenther at gmail dot com |rguenth at gcc dot gnu.org Depends on||66721 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. We go down the SLP path here because the vectorizer thinks that SLP is always cheaper than using interleaving (which generally is true if there were not targets which can do the load plus interleave with load-lanes ...). I think this may be a regression as well because I enhanced SLP to apply to way more cases. Note that my plan is to make the vectorizer consider both (well, not really, but this bug shows I maybe should try), SLP and non-SLP, and evaluate based on costs which route to go. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66721 [Bug 66721] [6 regression] gcc.target/i386/pr61403.c FAILs
[Bug c++/67345] -Woverloaded-virtual false negative: Does not warn on overloaded virtual function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67345 --- Comment #2 from EisahLee at gmx dot de --- I see the hiding as a potential design error, or however that is called: A shortcoming of the way the methods were named. Clang 4.5 does not warn until there is such a bad call. Is there a compiler + flag combination that can provide such a warning?
[Bug tree-optimization/67306] Patterns ICEs when moved using simplify and match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67306 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/67306] Patterns ICEs when moved using simplify and match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67306 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Aug 25 10:29:09 2015 New Revision: 227163 URL: https://gcc.gnu.org/viewcvs?rev=227163root=gccview=rev Log: 2015-08-25 Richard Biener rguent...@suse.de PR middle-end/67306 * genmatch.c (expr::gen_transform): Verify the result of builtin_decl_implicit. (dt_simplify::gen_1): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/genmatch.c
[Bug c++/67315] [4.9 Regression] Strange 'this' pointer behavior when calling virtual function with different optimization attributes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67315 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- This is hard to bisect, because checking compilers ICE on it, which got fixed only in r217737 (and introduced in r202187).
[Bug testsuite/67203] [6 regression] FAIL: g++.dg/tree-ssa/pr61034.C -std=gnu++11 scan-tree-dump-times fre2 free 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67203 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Bah, so this boils down to PUSH_ARGS_REVERSED and its affect on gimplification and thus initial GIMPLE. In this case PUSH_ARGS_REVERSED == 1 wins. (for the operator- calls code for b * c and c * d is emitted first) So we could add an effective target push_args_reversed ... iff that's easy enough to fill-in. Or explicitely add target matches. Or spend more time on trying to analyze why order matters for SCCVN here (it's all about -count CSE).
[Bug tree-optimization/67323] Use non-unit stride loads by preference when applicable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67323 --- Comment #2 from Michael Collison michael.collison at linaro dot org --- Richard, Should I create a test case that fails until you resolve this in GCC 6? On 08/25/2015 02:14 AM, rguenth at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67323 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-25 CC|richard.guenther at gmail dot com |rguenth at gcc dot gnu.org Depends on||66721 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. We go down the SLP path here because the vectorizer thinks that SLP is always cheaper than using interleaving (which generally is true if there were not targets which can do the load plus interleave with load-lanes ...). I think this may be a regression as well because I enhanced SLP to apply to way more cases. Note that my plan is to make the vectorizer consider both (well, not really, but this bug shows I maybe should try), SLP and non-SLP, and evaluate based on costs which route to go. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66721 [Bug 66721] [6 regression] gcc.target/i386/pr61403.c FAILs
[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67005 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Yeah, though somewhere would be all the time if we and up removing an edge. I've meant to see whether we can restrict it to removed an edge with IRREDUCIBLE_LOOP flag set, but then we'd have to compute that first and we only do that for 'aggressive' aka CDDCE. Didn't get around to play with that ;) (note the ICE appears after CDDCE only, but I would need to convince myself that regular DCE can't trigger the same issue - I think it can't)
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #28 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 25 Aug 2015, kumba at gentoo dot org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #27 from Joshua Kinard kumba at gentoo dot org --- (In reply to Richard Biener from comment #26) Don't hold your breath. Basically somebody who can reproduce it has to find the root-cause and a fix. 4.9.3 works, and the problem appears specific to genmatch with the '--gimple' argument. I guess I can test to see if 5.0.0 is also affected, and then start diffing the genmatch.c files between working/non-working version to trace the problem down. That will be quicker than git bisecting on these machines (old SGI machines). Can't stay stuck on 4.9.x forever... Can you also nail the issue down to using --disable-checking? For the powerpc case I think we run into a miscompile of stage2 and thus genmatch.c is really only the trigger and wouldn't be the place for a fix (well, maybe a workaround is fine for the GCC 5 branch here)
[Bug tree-optimization/67326] [5/6 Regression] -ftree-loop-if-convert-stores does not vectorize conditional assignment (anymore)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67326
vekumar at gcc dot gnu.org changed:
What|Removed |Added
CC||vekumar at gcc dot gnu.org
--- Comment #2 from vekumar at gcc dot gnu.org ---
Hi Richard,
As a first step I am trying to allow if conversion to happen under
-ftree-loop-if-convert-stores for cases where we know it is already accessed
(read) outside unconditionally once and also the memory access is read and
write.
__attribute__((aligned(32))) float a[LEN]; void
test() { for (int i = 0; i LEN; i++) {
if (a[i] (float)0.) { //== Already read here unconditionally
a[i] =3 ; //== if we now it is read and write memory access
we can allow if conversion.
}
As you said the cases in PR we need to enhance if-conversion pass to do bounds
checking the array a accessing using values of i.
[Bug tree-optimization/67323] Use non-unit stride loads by preference when applicable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67323 --- Comment #3 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 25 Aug 2015, michael.collison at linaro dot org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67323 --- Comment #2 from Michael Collison michael.collison at linaro dot org --- Richard, Should I create a test case that fails until you resolve this in GCC 6? If you can provide one that I can check in together with a fix that would be nice. Having it in the tree now and FAILing isn't according to our policies. On 08/25/2015 02:14 AM, rguenth at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67323 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-25 CC|richard.guenther at gmail dot com |rguenth at gcc dot gnu.org Depends on||66721 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. We go down the SLP path here because the vectorizer thinks that SLP is always cheaper than using interleaving (which generally is true if there were not targets which can do the load plus interleave with load-lanes ...). I think this may be a regression as well because I enhanced SLP to apply to way more cases. Note that my plan is to make the vectorizer consider both (well, not really, but this bug shows I maybe should try), SLP and non-SLP, and evaluate based on costs which route to go. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66721 [Bug 66721] [6 regression] gcc.target/i386/pr61403.c FAILs
[Bug tree-optimization/67323] Use non-unit stride loads by preference when applicable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67323 --- Comment #4 from Michael Collison michael.collison at linaro dot org --- Hi Richard, No I do not have a fix now. Thanks for the info on the policy. On 08/25/2015 03:05 AM, rguenther at suse dot de wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67323 --- Comment #3 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 25 Aug 2015, michael.collison at linaro dot org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67323 --- Comment #2 from Michael Collison michael.collison at linaro dot org --- Richard, Should I create a test case that fails until you resolve this in GCC 6? If you can provide one that I can check in together with a fix that would be nice. Having it in the tree now and FAILing isn't according to our policies. On 08/25/2015 02:14 AM, rguenth at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67323 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-25 CC|richard.guenther at gmail dot com |rguenth at gcc dot gnu.org Depends on||66721 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. We go down the SLP path here because the vectorizer thinks that SLP is always cheaper than using interleaving (which generally is true if there were not targets which can do the load plus interleave with load-lanes ...). I think this may be a regression as well because I enhanced SLP to apply to way more cases. Note that my plan is to make the vectorizer consider both (well, not really, but this bug shows I maybe should try), SLP and non-SLP, and evaluate based on costs which route to go. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66721 [Bug 66721] [6 regression] gcc.target/i386/pr61403.c FAILs
[Bug middle-end/63510] Wrong line number in Wstrict-overflow message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510 --- Comment #8 from Chen Gang gang.chen.5i5j at gmail dot com --- For the latest gcc, it still has this issue, I shall try to fix it during these days (hope can fix it within this month). Thanks.
[Bug target/67353] [avr] Option-ize Warning appears to be a misspelled signal / interrupt handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67353 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-25 Target Milestone|--- |6.0 Ever confirmed|0 |1 Severity|normal |enhancement
[Bug target/67344] PowerPC unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67344 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Segher Boessenkool segher at gcc dot gnu.org --- Fixed.
[Bug middle-end/67341] [ICE] libgo build failure: in mark_stmt_if_obviously_necessary, at tree-ssa-dce.c:278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67341 --- Comment #3 from Gary Funck gary at intrepid dot com --- (In reply to Marek Polacek from comment #2) Gary, could you please try this again? I'd hope this has really been fixed with my recentish Go patch. Confirmed - fixed.
[Bug target/67352] [avr] incorrect warning with -Waddr-space-convert and array in struct in __flash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67352 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-08-25 Ever confirmed|0 |1
[Bug target/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67317 --- Comment #5 from Segher Boessenkool segher at gcc dot gnu.org --- Combine can handle most RTL expressions, although it sometimes simplifies (or simplifies) more than you want. I think in this case what is already done in *addmode3_cc_overflow will work well, but I do not know x86 CC modes terribly well. You'll need to experiment a bit to find something that works well in all interesting cases.
[Bug target/67353] New: [avr] Option-ize Warning appears to be a misspelled signal / interrupt handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67353 Bug ID: 67353 Summary: [avr] Option-ize Warning appears to be a misspelled signal / interrupt handler Product: gcc Version: 5.2.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: target Assignee: gjl at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Target: avr Add -W flag to control the mentioned warning or turn it into an error.
[Bug target/67346] PowerPC: could not split insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67346 --- Comment #3 from Segher Boessenkool segher at gcc dot gnu.org --- Author: segher Date: Tue Aug 25 19:35:15 2015 New Revision: 227183 URL: https://gcc.gnu.org/viewcvs?rev=227183root=gccview=rev Log: rs6000: Fix PR67346 *iormode_mask is a define_insn_and_split, so it shouldn't use can_create_pseudo in its instruction condition, because IRA can then create such an instruction, and the condition becomes false before the insn is split. Use a scratch instead. 2015-08-25 Segher Boessenkool seg...@kernel.crashing.org PR target/67346 * config/rs6000/rs6000.md (*iormode_mask): Use a match_scratch. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md
[Bug middle-end/67341] [ICE] libgo build failure: in mark_stmt_if_obviously_necessary, at tree-ssa-dce.c:278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67341 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Thanks.
[Bug target/67344] PowerPC unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67344 --- Comment #3 from Segher Boessenkool segher at gcc dot gnu.org --- Author: segher Date: Tue Aug 25 19:32:28 2015 New Revision: 227182 URL: https://gcc.gnu.org/viewcvs?rev=227182root=gccview=rev Log: rs6000: Fix PR67344 The *andmode3_imm_dot_shifted pattern is a define_insn_and_split, like most dot patterns: if its output is not assigned cr0 but some other cr reg, it splits to a non-dot insn and a compare. Unfortunately that non-dot insn will clobber cr0 as well. We could add another clobber (with =X,x), but then that second alternative is never useful; instead, just remove that second alternative. 2015-08-25 Segher Boessenkool seg...@kernel.crashing.org PR target/67344 * config/rs6000/rs6000.md (*andmode3_imm_dot_shifted): Change to a define_insn, remove second alternative. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md
[Bug target/67346] PowerPC: could not split insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67346 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Segher Boessenkool segher at gcc dot gnu.org --- Fixed. Thanks for the report, these csmith tests pick out things nothing else does :-)
[Bug libstdc++/60519] Debug mode should check comparators for irreflexivity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60519 --- Comment #5 from François Dumont fdumont at gcc dot gnu.org --- Author: fdumont Date: Tue Aug 25 20:27:03 2015 New Revision: 227189 URL: https://gcc.gnu.org/viewcvs?rev=227189root=gccview=rev Log: 2015-08-24 François Dumont fdum...@gcc.gnu.org PR libstdc++/60519 * include/debug/formatter.h (_Debug_msg_id::__msg_irreflexive_ordering): New enum entry. * include/debug/functions.h (_Irreflexive_checker): New. (__is_irreflexive, __is_irreflexive_pred): New. * include/debug/macros.h (__glibcxx_check_irreflexive, __glibcxx_check_irreflexive_pred): New macros. (__glibcxx_check_irreflexive2, __glibcxx_check_irreflexive_pred2): New macros limited to post-C++11 mode. * include/debug/debug.h (__glibcxx_requires_irreflexive, __glibcxx_requires_irreflexive_pred): New macros, use latter. (__glibcxx_requires_irreflexive2, __glibcxx_requires_irreflexive_pred2): Likewise. * include/bits/stl_algo.h (partial_sort_copy): Add irreflexive debug check. (partial_sort_copy): Likewise. (lower_bound): Likewise. (upper_bound): Likewise. (equal_range): Likewise. (binary_search): Likewise. (inplace_merge): Likewise. (includes): Likewise. (next_permutation): Likewise. (prev_permutation): Likewise. (is_sorted_until): Likewise. (minmax_element): Likewise. (partial_sort): Likewise. (nth_element): Likewise. (sort): Likewise. (merge): Likewise. (stable_sort): Likewise. (set_union): Likewise. (set_intersection): Likewise. (set_difference): Likewise. (set_symmetric_difference): Likewise. (min_element): Likewise. (max_element): Likewise. * include/bits/stl_algobase.h (lower_bound): Likewise. (lexicographical_compare): Likewise. * include/bits/stl_heap.h (push_heap): Likewise. (pop_heap): Likewise. (make_heap): Likewise. (sort_heap): Likewise. (is_heap_until): Likewise. * testsuite/25_algorithms/lexicographical_compare/debug/ irreflexive_neg.cc: New. * testsuite/25_algorithms/lower_bound/debug/irreflexive.cc: New. * testsuite/25_algorithms/partial_sort_copy/debug/irreflexive_neg.cc: New. Added: trunk/libstdc++-v3/testsuite/25_algorithms/lexicographical_compare/debug/ trunk/libstdc++-v3/testsuite/25_algorithms/lexicographical_compare/debug/irreflexive_neg.cc trunk/libstdc++-v3/testsuite/25_algorithms/lower_bound/debug/ trunk/libstdc++-v3/testsuite/25_algorithms/lower_bound/debug/irreflexive.cc trunk/libstdc++-v3/testsuite/25_algorithms/partial_sort_copy/debug/ trunk/libstdc++-v3/testsuite/25_algorithms/partial_sort_copy/debug/irreflexive_neg.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_algo.h trunk/libstdc++-v3/include/bits/stl_algobase.h trunk/libstdc++-v3/include/bits/stl_heap.h trunk/libstdc++-v3/include/debug/debug.h trunk/libstdc++-v3/include/debug/formatter.h trunk/libstdc++-v3/include/debug/functions.h trunk/libstdc++-v3/include/debug/macros.h trunk/libstdc++-v3/src/c++11/debug.cc
[Bug middle-end/67330] ICE handling weak attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67330 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Aug 25 20:28:59 2015 New Revision: 227190 URL: https://gcc.gnu.org/viewcvs?rev=227190root=gccview=rev Log: PR middle-end/67330 * varasm.c (declare_weak): Return after giving an error. * c-common.c (handle_weak_attribute): Don't check whether the visibility can be changed here. * gcc.dg/weak/weak-18.c: New test. Added: trunk/gcc/testsuite/gcc.dg/weak/weak-18.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c
[Bug middle-end/67330] ICE handling weak attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67330 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67005 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Taking this over for now.
[Bug target/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67317
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
Target||x86_64-*-*
Status|WAITING |NEW
Component|inline-asm |target
--- Comment #2 from Marc Glisse glisse at gcc dot gnu.org ---
Self-contained:
typedef unsigned long long u64;
u64 testcarry(u64 a, u64 b, u64 c, u64 d)
{
u64 result0, result1;
__builtin_ia32_addcarryx_u64(__builtin_ia32_addcarryx_u64(0, a, c, result0),
b, d, result1);
return result0 ^ result1;
}
[Bug rtl-optimization/10837] noreturn attribute causes no sibling calling optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837 --- Comment #12 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Richard Henderson from comment #2) Working as designed. (1) It often takes more insns to pop the stack frame than to make the call. (2) You get a proper backtrace from abort. (3) http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00180.html Glibc has been using ENTRY (__memmove_chk) movl12(%esp), %eax cmpl%eax, 16(%esp) jb __chk_fail jmp memmove END (__memmove_chk) since 2004. #1 and #2 shouldn't be the reason not to optimize. I am using: /* Due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837 noreturn attribute disable tail call optimization. Removes noreturn attribute to enable tail call optimization. */ extern void *chk_fail (void) __asm__ (__chk_fail) attribute_hidden; to work around this.
[Bug middle-end/67341] [ICE] libgo build failure: in mark_stmt_if_obviously_necessary, at tree-ssa-dce.c:278
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67341 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-08-25 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Gary, could you please try this again? I'd hope this has really been fixed with my recentish Go patch.
[Bug target/67352] New: [avr] incorrect warning with -Waddr-space-convert and array in struct in __flash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67352
Bug ID: 67352
Summary: [avr] incorrect warning with -Waddr-space-convert and
array in struct in __flash
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Keywords: addr-space, diagnostic
Severity: normal
Priority: P3
Component: target
Assignee: gjl at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Target: avr
== C source ==
typedef struct
{
char a, b[3];
} S;
const __flash char* get_b1 (const __flash S *s)
{
return s-b;
}
extern const __flash S ab;
const __flash char* get_b2 (void)
{
return ab.b;
}
== Command line ==
$ avr-gcc -mmcu=atmega8 main.c -Werror=addr-space-convert -fsyntax-only
== avr-gcc Output ==
main.c: In function 'get_b1':
main.c:8:4: error: conversion from address space 'generic' to address space
'__flash' [-Werror=addr-space-convert]
main.c: In function 'get_b2':
main.c:15:4: error: conversion from address space 'generic' to address space
'__flash' [-Werror=addr-space-convert]
[Bug target/67352] [avr] incorrect warning with -Waddr-space-convert and array in struct in __flash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67352 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |6.0
[Bug c++/67354] New: internal compiler error: in add_to_same_comdat_group, at symtab.c:421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67354
Bug ID: 67354
Summary: internal compiler error: in add_to_same_comdat_group,
at symtab.c:421
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bgreen0 at gmail dot com
Target Milestone: ---
Created attachment 36255
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36255action=edit
preprocessor output
The attached preprocessed code generates an internal compiler error when
compiled with the -Os option. Tested with g++ 5.1 and 5.2.
Preprocessed file attached.
Here is the command line out output:
$ g++ -v -save-temps -std=gnu++11 -Wall -Wextra -Os -c -o gccbug.o gccbug.cpp
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-5.2.0/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --with-default-libstdcxx-abi=gcc4-compatible
Thread model: posix
gcc version 5.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu++11' '-Wall' '-Wextra' '-Os'
'-c' '-o' 'gccbug.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1plus -E -quiet -v -D_GNU_SOURCE
gccbug.cpp -mtune=generic -march=x86-64 -std=gnu++11 -Wall -Wextra -Os
-fpch-preprocess -o gccbug.ii
ignoring nonexistent directory
/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0
/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0/x86_64-unknown-linux-gnu
/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0/backward
/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu++11' '-Wall' '-Wextra' '-Os'
'-c' '-o' 'gccbug.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1plus -fpreprocessed gccbug.ii
-quiet -dumpbase gccbug.cpp -mtune=generic -march=x86-64 -auxbase-strip
gccbug.o -Os -Wall -Wextra -std=gnu++11 -version -o gccbug.s
GNU C++11 (GCC) version 5.2.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version
3.1.3-p4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++11 (GCC) version 5.2.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version
3.1.3-p4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 18422b8e6e00646fd4f8fbf484d27148
gccbug.cpp: In instantiation of ‘Test::Test(Args ...) [with Args = {}]’:
/usr/include/c++/5.2.0/ext/new_allocator.h:120:4: required from ‘void
__gnu_cxx::new_allocator_Tp::construct(_Up*, _Args ...) [with _Up = Test;
_Args = {}; _Tp = Test]’
/usr/include/c++/5.2.0/bits/alloc_traits.h:256:4: required from ‘static
std::_Requiretypename std::allocator_traits_Alloc::__construct_helper_Tp,
_Args::type std::allocator_traits_Alloc::_S_construct(_Alloc, _Tp*,
_Args ...) [with _Tp = Test; _Args = {}; _Alloc = std::allocatorTest;
std::_Requiretypename std::allocator_traits_Alloc::__construct_helper_Tp,
_Args::type = void]’
/usr/include/c++/5.2.0/bits/alloc_traits.h:402:16: required from ‘static
decltype (_S_construct(__a, __p,
(forward_Args)(std::allocator_traits::construct::__args)...))
std::allocator_traits_Alloc::construct(_Alloc, _Tp*, _Args ...) [with _Tp
= Test; _Args = {}; _Alloc = std::allocatorTest; decltype (_S_construct(__a,
__p, (forward_Args)(std::allocator_traits::construct::__args)...)) = type
error]’
/usr/include/c++/5.2.0/bits/shared_ptr_base.h:522:39: required from
‘std::_Sp_counted_ptr_inplace_Tp, _Alloc,
_Lp::_Sp_counted_ptr_inplace(_Alloc, _Args ...) [with _Args = {}; _Tp =
Test; _Alloc = std::allocatorTest; __gnu_cxx::_Lock_policy _Lp =
(__gnu_cxx::_Lock_policy)2u]’
/usr/include/c++/5.2.0/bits/shared_ptr_base.h:617:4: required from
‘std::__shared_count_Lp::__shared_count(std::_Sp_make_shared_tag, _Tp*, const
[Bug tree-optimization/67328] range test rather than single bit test for code testing enum values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67328 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Alan Modra amodra at gmail dot com --- Maybe adding #if ALT only confused the issue. For -UALT -O1 on x86_64 I get test_pic: testb $1, (%rdi) je .L1 addl$1, result(%rip) .L1: rep ret test_exe: movzbl (%rdi), %eax andl$3, %eax cmpb$1, %al ja .L3 addl$1, result(%rip) .L3: rep ret For test_exe I would like to see the following equivalent and better optimised code. test_exe: testb $2, (%rdi) jne .L3 addl$1, result(%rip) .L3: rep ret The optimisation to a bit test for test_pic happens in reassoc1, or at least that's where the process starts.
[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67005
--- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org ---
Hm, adding || (e2-flags EDGE_IRREDUCIBLE_LOOP) doesn't work; the E2 edge
doesn't have the EDGE_IRREDUCIBLE_LOOP flag, even if I recompute that flag via
mark_irreducible_loops. So maybe set LOOPS_NEED_FIXUP every time we remove an
edge?
FTR, the CFG looks like
f ()
{
int a.0_4;
int a.0_7;
bb 2:
a.0_4 = a;
if (a.0_4 == 0)
goto bb 3 (lbl);
else
goto bb 4;
lbl:
bb 4:
a.0_7 = a;
if (a.0_7 != 0)
goto bb 5;
else
goto bb 3 (lbl);
bb 5:
a = 8;
goto bb 3 (lbl);
}
so the 2 - 4 and 2 - 3 edges are multiple entries of a loop -- why aren't
they EDGE_IRREDUCIBLE_LOOP?
[Bug libfortran/48511] Implement Steele-White algorithm for numeric output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48511 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #14 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Seeing the PR track, it seems both Janne and Jerry are against reimplementing Steele-White. I am too: unless we can show very good features or speed improvement, we'd best do exactly what we do now, i.e. use the system's libc (and possibly libquadmath). So I am closing this PR as WONTFIX. In any case, if we wanted to have faster floating-point I/O, we should move to something more modern than Steele-White. The current state of the art (as implemented in new language runtimes, such as Julia, rust, modern javascript, etc.) is to combine grisu3 (http://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf) with dragon4 (Steele-White) as a fall-back for the cases where grisu3 doesn't round exactly.
[Bug target/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67317 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #3 from Segher Boessenkool segher at gcc dot gnu.org --- These things would normally be taken care of by combine, but combine of course does not know what the UNSPEC_ADD_CARRY's mean. Does this need to be an unspec at all?
[Bug tree-optimization/67253] [6 Regression] ICE at -O3 on x86_64-linux-gnu (verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67253 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r222360.
