[Bug middle-end/79818] [7 Regression] wrong code with -fwrapv and -Os/-O1/-O2/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79818 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug middle-end/79818] [7 Regression] wrong code with -fwrapv and -Os/-O1/-O2/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79818 --- Comment #7 from Richard Biener --- Author: rguenth Date: Fri Mar 3 08:08:08 2017 New Revision: 245860 URL: https://gcc.gnu.org/viewcvs?rev=245860&root=gcc&view=rev Log: 2017-03-03 Richard Biener PR middle-end/79818 * match.pd ( X +- C1 CMP C2 -> X CMP C2 -+ C1): Add missing TYPE_OVERFLOW_UNDEFINED check. * gcc.dg/torture/pr79818.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr79818.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug c++/79822] [5/7 Regression] ICE with void statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79822 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Appeared on trunk in r238558.
[Bug rtl-optimization/79779] [5/6/7 Regression] ICE on an invalid code with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79779 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Martin Liška --- Thank you Vladimir for investigation, I know it's very not correct test-case :)
[Bug c++/79821] [7 regression] SEGV in cc1plus compiling 64-bit stdc++.h.gch/O2g.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79821 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Jonathan Wakely --- > Weird, that commit only changes the names of some variables. indeed, and I compared the .ii files to check if by some weird coincidence one of those got mangled by some Solaris macro, but nothing of the kind. > A similar patch has been committed to the gcc-5 and gcc-6 branches, so we > should be sure a similar ICE doesn't happen on the branches. I've now done sparc-sun-solaris2.12 bootstraps on both branches, as well as a mainline bootstrap on sparc-sun-solaris2.11 (same hardware), but all work fine. OTOH, a sparc-sun-solaris2.12 mainline bootstrap with gas instead of as fails just the same. Sometimes, small codegen or layout differences due to differing assembler capabilities can lead to unexpected memory corruption. However, I've now managed to run the failing cc1plus invocation (without -save-temps) under gdb: Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xfed6c634 in strlen () from /lib/libc.so.1 (gdb) where #0 0xfed6c634 in strlen () from /lib/libc.so.1 #1 0x009e0208 in gt_pch_note_object (obj=0xf938, note_ptr_cookie=0xf938, note_ptr_fn= 0xcfe544 ) at /var/gcc/reghunt/trunk/gcc/ggc-common.c:285 #2 0x008c95f8 in gt_pch_nx (v=) at /var/gcc/reghunt/trunk/gcc/vec.h:1130 #3 gt_pch_nx_vec_dw_attr_node_va_gc_ (x_p=0xf8238000) at gt-dwarf2out.h:948 #4 0x008c96a8 in gt_pch_nx_die_struct (x_p=) at gt-dwarf2out.h:720 #5 0x008c96d8 in gt_pch_nx_die_struct (x_p=) at gt-dwarf2out.h:722 #6 0x008c95f8 in gt_pch_nx (v=) at /var/gcc/reghunt/trunk/gcc/vec.h:1130 #7 gt_pch_nx_vec_dw_attr_node_va_gc_ (x_p=0xfb73eca8) at gt-dwarf2out.h:948 #8 0x008c96a8 in gt_pch_nx_die_struct (x_p=) at gt-dwarf2out.h:720 #9 0x00699d48 in gt_pch_nx_lang_tree_node (x_p=) at gt-cp-tree.h:1345 #10 0x0069813c in gt_pch_nx_lang_tree_node (x_p=) at gt-cp-tree.h:1042 #11 0x00699640 in gt_pch_nx_lang_tree_node (x_p=) at gt-cp-tree.h:1333 #12 0x0069813c in gt_pch_nx_lang_tree_node (x_p=) at gt-cp-tree.h:1042 #13 0x00699628 in gt_pch_nx_lang_tree_node (x_p=) at gt-cp-tree.h:1332 #14 0x00698980 in gt_pch_nx_lang_tree_node (x_p=) at gt-cp-tree.h:1154 #15 0x006d0b70 in gt_pch_nx_cp_binding_level (x_p=0xfb42c000) at gt-cp-name-lookup.h:174 #16 0x00697fc0 in gt_pch_nx_lang_tree_node (x_p=) at gt-cp-tree.h:1538 #17 0x006985a8 in gt_pch_nx_lang_tree_node (x_p=) at gt-cp-tree.h: #18 0x00698f48 in gt_pch_nx_lang_tree_node (x_p=) at gt-cp-tree.h:1227 #19 0x00699610 in gt_pch_nx_lang_tree_node (x_p=) at gt-cp-tree.h:1331 #20 0x00697cb0 in gt_pch_nx_lang_tree_node (x_p=) at gt-cp-tree.h:1496 #21 0x006d0cec in gt_pch_nx_cxx_binding (x_p=0xfb5847c8) at gt-cp-name-lookup.h:162 #22 0x00697fc0 in gt_pch_nx_lang_tree_node (x_p=) at gt-cp-tree.h:1538 #23 0x00698f30 in gt_pch_nx_lang_tree_node (x_p=) at gt-cp-tree.h:1226 #24 0x00699610 in gt_pch_nx_lang_tree_node (x_p=) at gt-cp-tree.h:1331 #25 0x00a5886c in gt_pch_nx (v=) at /var/gcc/reghunt/trunk/gcc/vec.h:1130 #26 gt_pch_nx_vec_tree_va_gc_ (x_p=0xfb976000) at gtype-desc.c:5174 #27 0x009e0a9c in gt_pch_save (f=0x17896c0 <_iob+64>) at /var/gcc/reghunt/trunk/gcc/ggc-common.c:437 #28 0x00785900 in c_common_write_pch () at /var/gcc/reghunt/trunk/gcc/c-family/c-pch.c:183 #29 0x00594e5c in c_parse_final_cleanups () at /var/gcc/reghunt/trunk/gcc/cp/decl2.c:4474 #30 0x00d04ae4 in compile_file () at /var/gcc/reghunt/trunk/gcc/toplev.c:467 #31 0x00d07860 in do_compile () at /var/gcc/reghunt/trunk/gcc/toplev.c:1984 #32 toplev::main (this=this@entry=0xffbfef66, argc=argc@entry=45, argv=argv@entry=0xffbfefcc) at /var/gcc/reghunt/trunk/gcc/toplev.c:2118 #33 0x0141598c in main (argc=45, argv=0xffbfefcc) at /var/gcc/reghunt/trunk/gcc/main.c:39 Here's where strlen SEGVs: (gdb) display/i $pc 1: x/i $pc => 0xfed6c634 : ld [ %o2 ], %o1 (gdb) p/x $o2 $1 = 0xf940 #1 0x009e0208 in gt_pch_note_object (obj=0xf938, note_ptr_cookie=0xf938, note_ptr_fn=0xcfe544 ) at /var/gcc/reghunt/trunk/gcc/ggc-common.c:285 285 (*slot)->size = strlen ((const char *)obj) + 1; (gdb) p obj $2 = (void *) 0xf938 (gdb) p (char *)obj $4 = 0xf938 "\001\257\257\257\257\257\257\257" pmap on cc1plus shows F880 104K rw-[ anon ] F9004096K rw-[ anon ] F9801640K rw-[ anon ] and indeed F900 + 4096K => F940, i.e. F940 is unmapped! Need to dig further why this happens. Rainer
[Bug tree-optimization/79824] New: [7 Regression] Failure to peel for gaps leads to read beyond mapped memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79824 Bug ID: 79824 Summary: [7 Regression] Failure to peel for gaps leads to read beyond mapped memory Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rsandifo at gcc dot gnu.org Target Milestone: --- Created attachment 40876 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40876&action=edit Testcase After r241959 we avoid peeling for gaps if the vector is aligned. That isn't safe because the gap itself could be vector-sized or wider. The attached testcase is based on pr49038.c and uses Richard's suggestion of __builtin_assumed_aligned.
[Bug target/79514] [5/6/7 Regression] ICE in curr_insn_transform, at lra-constraints.c:3773
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79514 --- Comment #19 from uros at gcc dot gnu.org --- Author: uros Date: Fri Mar 3 09:18:01 2017 New Revision: 245861 URL: https://gcc.gnu.org/viewcvs?rev=245861&root=gcc&view=rev Log: PR target/79514 * config/i386/i386.md (*pushxf_rounded): Use Pmode instead of DImode. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md
[Bug c++/79825] New: [7 Regression] Uninitialized uses in aggregate copies of empty structs (missed DCE in C++ gimplify)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79825
Bug ID: 79825
Summary: [7 Regression] Uninitialized uses in aggregate copies
of empty structs (missed DCE in C++ gimplify)
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Keywords: diagnostic, missed-optimization
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
With
struct A;
struct B {
B(A);
};
struct C {
template void m_fn1(PassT p1) { new B(p1); }
};
struct A {};
void fn1() {
C a;
a.m_fn1(A());
}
we see
;; Function void C::m_fn1(PassT) [with PassT = A] (null)
;; enabled by -tree-original
<;, <<< Unknown tree:
empty_class_expr >>>;>;, TARGET_EXPR ;, try
{
B::B ((struct B *) D.2373, *(struct A &) &D.2394);
}
gimplified to
void C::m_fn1(PassT) [with PassT = A] (struct C * const this, struct A p1)
{
struct A D.2394;
struct A D.2392;
struct A D.2399;
void * D.2373;
D.2394 = D.2399;
try
{
...
where this copy of an "empty" class prevails until .optimized.
The C++ gimplifier is supposed to eliminate such copies as the middle-end
sees 1-byte aggregates where it cannot readily eliminate anything.
The new fancy uninit warning now warns here as well:
t.C: In member function ‘void C::m_fn1(PassT) [with PassT = A]’:
t.C:6:56: warning: ‘’ is used uninitialized in this function
[-Wuninitialized]
template void m_fn1(PassT p1) { new B(p1); }
^~~
with the old machinery we only didn't warn because we for some reason
disregarded any aggregate uses:
use = gimple_vuse (stmt);
if (use
&& gimple_assign_single_p (stmt)
&& !gimple_vdef (stmt)
^^^
&& SSA_NAME_IS_DEFAULT_DEF (use))
[Bug c++/79825] [7 Regression] Uninitialized uses in aggregate copies of empty structs (missed DCE in C++ gimplify)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79825 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-03 Target Milestone|--- |7.0 Ever confirmed|0 |1
[Bug tree-optimization/79826] New: Unnecessary spills in vectorised loop version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79826 Bug ID: 79826 Summary: Unnecessary spills in vectorised loop version Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org CC: amker at gcc dot gnu.org, rguenth at gcc dot gnu.org Target Milestone: --- Created attachment 40877 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40877&action=edit Testcase The attached testcase is a sort of unrolled memcpy. The vectorised version of the loop has suboptimal register allocation (-O3 on aarch64): .L4: ldr q31, [x0] add x2, x2, 1 cmp x2, x8 ldr q30, [x0, 16] ldr q29, [x0, 32] ldr q28, [x0, 48] ldr q27, [x0, 64] ldr q26, [x0, 80] ldr q25, [x0, 96] ldr q24, [x0, 112] ldr q23, [x0, 128] ldr q22, [x0, 144] ldr q21, [x0, 160] ldr q20, [x0, 176] ldr q19, [x0, 192] ldr q18, [x0, 208] ldr q17, [x0, 224] ldr q16, [x0, 240] ldr q15, [x0, 256] add x0, x0, 528 ldr q14, [x0, -256] ldr q13, [x0, -240] ldr q12, [x0, -224] ldr q11, [x0, -208] ldr q10, [x0, -192] ldr q9, [x0, -176] ldr q8, [x0, -160] ldr q7, [x0, -144] ldr q6, [x0, -128] ldr q5, [x0, -112] ldr q4, [x0, -96] ldr q3, [x0, -80] ldr q2, [x0, -64] ldr q1, [x0, -48] ldr q0, [x0, -32] str q0, [sp, 64] //<--- splilling! ldr q0, [x0, -16] str q31, [x1] str q30, [x1, 16] str q29, [x1, 32] str q28, [x1, 48] str q27, [x1, 64] str q26, [x1, 80] str q25, [x1, 96] str q24, [x1, 112] str q23, [x1, 128] str q22, [x1, 144] str q21, [x1, 160] str q20, [x1, 176] str q19, [x1, 192] str q18, [x1, 208] str q17, [x1, 224] str q16, [x1, 240] str q15, [x1, 256] add x1, x1, 528 str q14, [x1, -256] str q13, [x1, -240] str q12, [x1, -224] str q11, [x1, -208] str q10, [x1, -192] str q9, [x1, -176] str q8, [x1, -160] str q7, [x1, -144] str q6, [x1, -128] str q5, [x1, -112] str q4, [x1, -96] str q3, [x1, -80] str q2, [x1, -64] str q1, [x1, -48] ldr q31, [sp, 64] str q0, [x1, -16] str q31, [x1, -32] bcc .L4 It uses too many registers and ends up spilling where really it shouldn't. It could just load and store one or two vector registers at a time and also interleave the loads and stores. The problem is that the scheduler cannot interleave the loads and stores. With -fsched-verbose=5 in the sched1 dump I see that there is an unexpected dependency between the stores and the last load in the load section: ;; --- Region Dependences --- b 5 bb 0 ;; insn codebb dep prio cost reservation ;; -- --- --- ;; 161 1016 5 0 8 6 ca57_load_model : 212m 208 201 171n ;; 163 1016 5 0 8 6 ca57_load_model : 212m 208 202 171n ;; 165 1016 5 0 8 6 ca57_load_model : 212m 208 203 171n ;; 167 1016 5 0 8 6 ca57_load_model : 212m 208 204 171n ;; 169 1016 5 0 7 6 ca57_load_model : 212m 208 205 171n ;; 171 1016 532 7 6 ca57_load_model : 212m 208 206 205nm 204nm 203nm 202nm 201nm 200nm 199nm 198nm 197nm 196nm 195nm 194nm 193nm 192nm 191nm 190nm 189nm 188nm 187nm 186nm 185nm 184nm 183nm 182nm 181nm 180nm 179nm 178nm 177nm 176nm 175nm 174nm ;; 174 1016 5 2 2 0 ca57_store_model: 212 209 205n ;; 175 1016 5 2 2 0 ca57_store_model: 212 209 205n ;; 176 1016 5 2 2 0 ca57_store_model: 212 209 205n ;; 177 1016 5 2 2 0 ca57_store_model: 212 209 205n ;; 178 1016 5 2 2 0 ca57_store_model: 212 209 205n ;; 179 1016 5 2 2 0 ca57_store_model: 212 209 205n ;; 180 1016 5 2 2 0 ca57_store_model: 212 209 205n ;; 181 1016 5 2 2 0 ca57_store_model: 212 209 205n Note how the last vector load (insn 171) says that all the stores foll
[Bug tree-optimization/79826] Unnecessary spills in vectorised loop version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79826 ktkachov at gcc dot gnu.org changed: What|Removed |Added Attachment #40877|0 |1 is obsolete|| --- Comment #1 from ktkachov at gcc dot gnu.org --- Created attachment 40878 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40878&action=edit Testcase without restrict I had accidentally modified the testcase before submitting the bug report. Attaching the correct one without the restrict modifiers that showcases the problem
[Bug c++/79791] -Werror=write-strings ignored with -Wpedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79791 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Fri Mar 3 09:58:10 2017 New Revision: 245864 URL: https://gcc.gnu.org/viewcvs?rev=245864&root=gcc&view=rev Log: PR c++/79791 * typeck.c (string_conv_p): In C++11, always call pedwarn with OPT_Wwrite_strings. * g++.dg/warn/Wwrite-strings-1.C: New test. * g++.dg/warn/Wwrite-strings-2.C: New test. * g++.dg/warn/Wwrite-strings-3.C: New test. * g++.dg/warn/Wwrite-strings-4.C: New test. * g++.dg/warn/Wwrite-strings-5.C: New test. * g++.dg/warn/Wwrite-strings-6.C: New test. * g++.dg/warn/Wwrite-strings-7.C: New test. * g++.dg/warn/Wwrite-strings-8.C: New test. * g++.dg/warn/Wwrite-strings-9.C: New test. * g++.dg/warn/Wwrite-strings-10.C: New test. * g++.dg/warn/Wwrite-strings-11.C: New test. * g++.dg/warn/Wwrite-strings-12.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wwrite-strings-1.C trunk/gcc/testsuite/g++.dg/warn/Wwrite-strings-10.C trunk/gcc/testsuite/g++.dg/warn/Wwrite-strings-11.C trunk/gcc/testsuite/g++.dg/warn/Wwrite-strings-12.C trunk/gcc/testsuite/g++.dg/warn/Wwrite-strings-2.C trunk/gcc/testsuite/g++.dg/warn/Wwrite-strings-3.C trunk/gcc/testsuite/g++.dg/warn/Wwrite-strings-4.C trunk/gcc/testsuite/g++.dg/warn/Wwrite-strings-5.C trunk/gcc/testsuite/g++.dg/warn/Wwrite-strings-6.C trunk/gcc/testsuite/g++.dg/warn/Wwrite-strings-7.C trunk/gcc/testsuite/g++.dg/warn/Wwrite-strings-8.C trunk/gcc/testsuite/g++.dg/warn/Wwrite-strings-9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c++/79791] -Werror=write-strings ignored with -Wpedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79791 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed for GCC 7.
[Bug c++/79825] [7 Regression] Uninitialized uses in aggregate copies of empty structs (missed DCE in C++ gimplify)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79825
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #1 from Richard Biener ---
gimplifying
D.2394 = TARGET_EXPR ;, <<< Unknown tree: empty_class_expr >>>;
doesn't hit the
else if (simple_empty_class_p (TREE_TYPE (op0), op1))
{
/* Remove any copies of empty classes. Also drop volatile
variables on the RHS to avoid infinite recursion from
gimplify_expr trying to load the value. */
case. Fix:
Index: gcc/cp/cp-gimplify.c
===
--- gcc/cp/cp-gimplify.c(revision 245863)
+++ gcc/cp/cp-gimplify.c(working copy)
@@ -549,6 +549,7 @@ simple_empty_class_p (tree type, tree op
return
((TREE_CODE (op) == COMPOUND_EXPR
&& simple_empty_class_p (type, TREE_OPERAND (op, 1)))
+ || TREE_CODE (op) == EMPTY_CLASS_EXPR
|| is_gimple_lvalue (op)
|| INDIRECT_REF_P (op)
|| (TREE_CODE (op) == CONSTRUCTOR
[Bug c++/79827] New: genautomata segmentation fault on NI-RT Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79827 Bug ID: 79827 Summary: genautomata segmentation fault on NI-RT Linux Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pkrizek at tes dot cz Target Milestone: --- Can't build GCC from source. Specific Linux distro: National Instruments RT Linux. Using the straightforward approach "download from your web - follow instructions - build" lead to the error like the log below - couldn't pass through genautomata. So I made a static gcc 6.3.0 on Ubuntu 15.04 which was built without problems. Then I copied the static gcc compiler to the National Instruments distro, made sure that their proprietary gcc is absent and symlinked gcc, cc etc. to my static version. Same result again - could't build genautomata. See log below (this time copy+paste). Reproducible on both physical and virtual machine with their distro. I can send you the whole virtual machine (uncompressed <1.8GiB) if you wish so that you can reproduce the bug. - g++ -std=gnu++98 -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -no-pie -o build/genautomata \ build/genautomata.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/hash-table.o build/read-md.o build/errors.o ../build-x86_64-pc-linux-gnu/libiberty/libiberty.a -lm build/genautomata /Flash/gcc/build/gcc-6.3.0/gcc/common.md /Flash/gcc/build/gcc-6.3.0/gcc/config/i386/i386.md \ insn-conditions.md > tmp-automata.c /bin/sh: line 1: 3668 Segmentation fault build/genautomata /Flash/gcc/build/gcc-6.3.0/gcc/common.md /Flash/gcc/build/gcc-6.3.0/gcc/config/i386/i386.md insn-conditions.md > tmp-automata.c Makefile:2184: recipe for target 's-automata' failed make[3]: *** [s-automata] Error 139
[Bug tree-optimization/79826] Unnecessary spills in vectorised loop version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79826 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-03 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- The vectorizer doesn't do anything to mark things aliased - it just emits vectorized stmts in unfortunate order and dependence analysis in the RTL scheduler is too weak to undo the harm. For the testcase with restrict it shows that the vectorizer fails to transfer any MR_DEPENDENCE_* (restrict) info from the original refs to the vector refs. The vectorizer could also generate MR_DEPENDENCE_* info from data-ref analysis itself (not just copying pre-existing stuff properly). In the past there were patches for "data dependence export to RTL" which is something that nowadays could be done (in some approximate way) via setting MR_DEPENDENCE_* from data dependence analysis (but one has to carefully review RTL code like unrolling if it properly handles MR_DEPENDENCE_* when copying BBs). First and foremost the vectorizer needs to preserve existing MR_DEPENDENCE_* (wouldn't help the testcase w/o restrict). Then I think we want to do a simple scheduling of memory operations on GIMPLE to reduce register pressure given on GIMPLE we have way more powerful dependence analysis.
[Bug tree-optimization/79824] [7 Regression] Failure to peel for gaps leads to read beyond mapped memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79824 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-03-03 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug c++/79822] [5/7 Regression] ICE with void statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79822 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |5.5
[Bug c++/79821] [7 regression] SEGV in cc1plus compiling 64-bit stdc++.h.gch/O2g.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79821 Richard Biener changed: What|Removed |Added Keywords||build --- Comment #3 from Richard Biener --- possibly GC parameter sensitive
[Bug tree-optimization/79828] New: missing div-by-zero warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828
Bug ID: 79828
Summary: missing div-by-zero warning
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Building the kernel with gcc-7.0.1 (r245831 at the time of testing), we ran
into a warning from objtool about a function ending in an undefined
instruction:
drivers/pwm/pwm-hibvt.o: warning: objtool: hibvt_pwm_get_state() falls through
to next function hibvt_pwm_apply()
I reduced the test case to a trivial division by zero:
static inline int return0(void) { return 0; }
int provoke_div0_warning(void) { return 1 / return0(); }
which gets turned into a single trapping instruction
(aarch64)
0018 :
18: d4207d00brk #0x3e8
(x86-64)
0010 :
10: 0f 0b ud2
This seems to be a result of r242636, and in the discussion
on that patch, I found a remark from Jeff Law that there
should be a warning for it:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00508.html
I think that having this gcc warning would have been
rather useful in debugging the kernel build warning.
Any chance this could be added?
[Bug c++/79819] collect2 undefined reference when -O0. Regression (or bugfix?) since gcc5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79819 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Richard Biener --- Thus invalid.
[Bug tree-optimization/79828] missing div-by-zero warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-03 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Biener --- The warning exists in the frontends only at the moment. Note such warning in the middle-end has the chance of false positives from (for example) path isolation.
[Bug c++/79827] genautomata segmentation fault on NI-RT Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79827 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-03-03 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Which target did you configure for (please show the configure line). Also please try do debug the genautomata invocation -- does it maybe overflow your stack (any low stacklimit set?)
[Bug c++/79827] genautomata segmentation fault on NI-RT Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79827 --- Comment #2 from Petr Křížek --- Config commands: configCmd="$srcDir/configure --enable-languages=c++\ --disable-multilib\ --prefix=$prefixDir\ --disable-shared --enable-static\ \ --with-gmp=$prefixDir\ --with-mpfr=$prefixDir\ --with-mpc=$prefixDir\ --with-isl=$prefixDir" $configCmd--with-boot-ldflags=" -static -static-libgcc " || exit 1 Both--disable-multilib and--enable-multilib give the same result. At the end I need a 32bit-capable compiler. I don't know how to debug the genautomata and/or manipulate the system stack under Linux. Maybe the stack really overflows? Petr On 3.3.2017 11:29, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79827 > > Richard Biener changed: > > What|Removed |Added > > Status|UNCONFIRMED |WAITING > Last reconfirmed||2017-03-03 > Ever confirmed|0 |1 > > --- Comment #1 from Richard Biener --- > Which target did you configure for (please show the configure line). > Also please try do debug the genautomata invocation -- does it maybe overflow > your stack (any low stacklimit set?) >
[Bug c++/79827] genautomata segmentation fault on NI-RT Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79827 --- Comment #3 from Petr Křížek --- Config commands: configCmd="$srcDir/configure --enable-languages=c++\ --disable-multilib\ --prefix=$prefixDir\ --disable-shared --enable-static\ \ --with-gmp=$prefixDir\ --with-mpfr=$prefixDir\ --with-mpc=$prefixDir\ --with-isl=$prefixDir" $configCmd--with-boot-ldflags=" -static -static-libgcc " || exit 1 Both--disable-multilib and--enable-multilib give the same result. At the end I need a 32bit-capable compiler. I don't know how to debug the genautomata and/or manipulate the system stack under Linux. Maybe the stack really overflows? Petr On 3.3.2017 11:29, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79827 > > Richard Biener changed: > > What|Removed |Added > > Status|UNCONFIRMED |WAITING > Last reconfirmed||2017-03-03 > Ever confirmed|0 |1 > > --- Comment #1 from Richard Biener --- > Which target did you configure for (please show the configure line). > > Also please try do debug the genautomata invocation -- does it maybe overflow > your stack (any low stacklimit set?) >
[Bug c++/79827] genautomata segmentation fault on NI-RT Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79827 --- Comment #4 from Petr Křížek --- Config commands: configCmd="$srcDir/configure --enable-languages=c++\ --disable-multilib\ --prefix=$prefixDir\ --disable-shared --enable-static\ \ --with-gmp=$prefixDir\ --with-mpfr=$prefixDir\ --with-mpc=$prefixDir\ --with-isl=$prefixDir" $configCmd--with-boot-ldflags=" -static -static-libgcc " || exit 1 Both--disable-multilib and--enable-multilib give the same result. At the end I need a 32bit-capable compiler. I don't know how to debug the genautomata and/or manipulate the system stack under Linux. Maybe the stack really overflows? Petr On 3.3.2017 11:29, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79827 > > Richard Biener changed: > > What|Removed |Added > > Status|UNCONFIRMED |WAITING > Last reconfirmed||2017-03-03 > Ever confirmed|0 |1 > > --- Comment #1 from Richard Biener --- > Which target did you configure for (please show the configure line). > > Also please try do debug the genautomata invocation -- does it maybe overflow > your stack (any low stacklimit set?) > TES VSETIN s.r.o. , Jiraskova 691, 755 01 Vsetin, IC: 24815276, DIC: CZ24815276. Zapsaná u rejstříkového soudu v Ostravě v oddilu C vložka 52829.
[Bug tree-optimization/79828] missing div-by-zero warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828 --- Comment #2 from Arnd Bergmann --- (In reply to Richard Biener from comment #1) > Note such warning in the middle-end has the chance of false > positives from (for example) path isolation. Would it be possible to warn if a function always traps? The kernel function that found this does not get inlined and has only one return statement, which never gets reached.
[Bug tree-optimization/79828] missing div-by-zero warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I'm afraid the warning would be huge amounts of false positives due to path isolation/jump threading and similar optimization.
[Bug tree-optimization/79828] missing div-by-zero warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828 --- Comment #4 from Jakub Jelinek --- s/would be/would have/
[Bug c++/79796] [5/6/7 Regression] ICE with NSDMI and this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79796 --- Comment #3 from Marek Polacek --- gimplify_expr can't stomach created in get_nsdmi. Wait, there's a dup or at least a very similar PR.
[Bug c++/79821] [7 regression] SEGV in cc1plus compiling 64-bit stdc++.h.gch/O2g.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79821 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Richard Biener --- > possibly GC parameter sensitive Indeed: the default is GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Increasing either param tenfold lets the compilation succeed. Rainer
[Bug c++/79796] [5/6/7 Regression] ICE with NSDMI and this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79796 --- Comment #4 from Marek Polacek --- That was PR77659 which has been fixed on the trunk.
[Bug c++/79825] [7 Regression] Uninitialized uses in aggregate copies of empty structs (missed DCE in C++ gimplify)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79825 --- Comment #2 from Richard Biener --- Author: rguenth Date: Fri Mar 3 11:30:32 2017 New Revision: 245866 URL: https://gcc.gnu.org/viewcvs?rev=245866&root=gcc&view=rev Log: 2017-03-03 Richard Biener PR c++/79825 * cp-gimplify.c (simple_empty_class_p): Handle EMPTY_CLASS_EXPR. * g++.dg/warn/Wuninitialized-8.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/warn/Wuninitialized-8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug c++/79825] [7 Regression] Uninitialized uses in aggregate copies of empty structs (missed DCE in C++ gimplify)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79825 Markus Trippelsdorf changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Markus Trippelsdorf --- Fixed, thanks.
[Bug tree-optimization/79828] missing div-by-zero warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828 --- Comment #5 from Marc Glisse --- If we only warn when the trap is always executed as Arnd suggests (determined in a similar way as uninitialized vs maybe-uninitialized), I guess there should be fewer false positive (only cloning seems likely to produce them). On the other hand, it would likely miss most interesting warnings (although it would have helped the kernel this once, apparently).
[Bug rtl-optimization/79574] ICE in want_to_gcse_p, at gcse.c:804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79574 --- Comment #4 from Martin Liška --- Author: marxin Date: Fri Mar 3 11:53:14 2017 New Revision: 245868 URL: https://gcc.gnu.org/viewcvs?rev=245868&root=gcc&view=rev Log: GCSE: Use HOST_WIDE_INT instead of int (PR rtl-optimization/79574). 2017-03-03 Martin Liska PR rtl-optimization/79574 * gcse.c (struct gcse_expr): Use HOST_WIDE_INT instead of int. (hash_scan_set): Likewise. (dump_hash_table): Likewise. (hoist_code): Likewise. 2017-03-03 Martin Liska PR rtl-optimization/79574 * gcc.dg/pr79574-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr79574-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/gcse.c trunk/gcc/testsuite/ChangeLog
[Bug c++/79827] genautomata segmentation fault on NI-RT Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79827 --- Comment #5 from Petr Křížek --- Sorry for dupplication, I didn't understand the warning about e-mail attachments.
[Bug tree-optimization/79803] [5/6/7 Regression] ICE in tree_ssa_prefetch_arrays, at tree-ssa-loop-prefetch.c:1982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79803 --- Comment #4 from Martin Liška --- Author: marxin Date: Fri Mar 3 11:53:56 2017 New Revision: 245869 URL: https://gcc.gnu.org/viewcvs?rev=245869&root=gcc&view=rev Log: Add -Wdisabled-optimization to loop prefetching pass (PR tree-optimization/79803). 2017-03-03 Martin Liska PR tree-optimization/79803 * tree-ssa-loop-prefetch.c (tree_ssa_prefetch_arrays): Remove assert. (pass_loop_prefetch::execute): Disabled optimization if an assumption about L1 cache size is not met. 2017-03-03 Martin Liska PR tree-optimization/79803 * gcc.dg/tree-ssa/pr79803.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr79803.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-prefetch.c
[Bug tree-optimization/79828] missing div-by-zero warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828 --- Comment #6 from Jakub Jelinek --- If the warning has false positives, then I'm sure the kernel will turn it off anyway like it does with tons of other warnings.
[Bug c++/79822] [5/7 Regression] ICE with void statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79822 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 40879 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40879&action=edit gcc7-pr79822.patch Untested fix.
[Bug lto/79760] ICE in type_in_anonymous_namespace_p in ipa-utils.h:219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79760 --- Comment #4 from Martin Liška --- Author: marxin Date: Fri Mar 3 11:58:03 2017 New Revision: 245870 URL: https://gcc.gnu.org/viewcvs?rev=245870&root=gcc&view=rev Log: Properly handle __cxa_pure_virtual visibility (PR lto/79760). 2017-03-03 Jan Hubicka PR lto/79760 * ipa-devirt.c (maybe_record_node): Properly handle __cxa_pure_virtual visibility. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c
[Bug tree-optimization/79803] [5/6 Regression] ICE in tree_ssa_prefetch_arrays, at tree-ssa-loop-prefetch.c:1982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79803 Martin Liška changed: What|Removed |Added Known to work||7.0 Summary|[5/6/7 Regression] ICE in |[5/6 Regression] ICE in |tree_ssa_prefetch_arrays, |tree_ssa_prefetch_arrays, |at |at |tree-ssa-loop-prefetch.c:19 |tree-ssa-loop-prefetch.c:19 |82 |82 Known to fail||5.4.0, 6.3.0 --- Comment #5 from Martin Liška --- Fixed on trunk so far.
[Bug lto/79760] ICE in type_in_anonymous_namespace_p in ipa-utils.h:219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79760 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-03 Known to work||7.0 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||5.4.0, 6.3.0 --- Comment #5 from Martin Liška --- Fixed on trunk so far.
[Bug rtl-optimization/79780] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79780 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/46854] PowerPC optimization regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46854 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Segher Boessenkool --- Current trunk does (with -O2) test: mr. 10,3 lis 3,.LANCHOR0@ha la 3,.LANCHOR0@l(3) beqlr 0 .p2align 5,,31 .L3: lbzu 9,1(3) cmpwi 7,9,0 bne 7,.L3 addic. 10,10,-1 bne 0,.L3 blr and with -Os test: lis 9,.LANCHOR0@ha la 9,.LANCHOR0@l(9) .L2: cmpwi 7,3,0 bne 7,.L3 mr 3,9 blr .L3: lbzu 10,1(9) cmpwi 7,10,0 bne 7,.L3 addi 3,3,-1 b .L2 Both are reasonable, with no obvious inefficiency; I'm closing this bug as fixed. (Note that since a few years we generate bdnz only in inner loops).
[Bug c++/79782] [7 Regression] ICE: tree check: expected tree_list, have void_type in emit_mem_initializers, at cp/init.c:1225
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79782 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- If this comes from upstream, then most likely upstream zlib doesn't build on cygwin64 either. So either you have too old cygwin and newer one supports it, or it would be nice to figure out why this changed upstream.
[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771 --- Comment #2 from Jakub Jelinek --- There is https://github.com/madler/zlib/commit/b4ce6caf0992296230e4e25b22a63e418bdf4dcf but not enough further info why it has changed. So, report upstream?
[Bug target/79807] [5/6/7 Regression] ICE in extract_insn, at recog.c:2311 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79807 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Mar 3 12:24:53 2017 New Revision: 245871 URL: https://gcc.gnu.org/viewcvs?rev=245871&root=gcc&view=rev Log: PR target/79807 * config/i386/i386.c (ix86_expand_multi_arg_builtin): If target is a memory operand, increase num_memory. (ix86_expand_args_builtin): Likewise. * gcc.target/i386/pr79807.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr79807.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/79807] [5/6 Regression] ICE in extract_insn, at recog.c:2311 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79807 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[5/6/7 Regression] ICE in |[5/6 Regression] ICE in |extract_insn, at|extract_insn, at |recog.c:2311 (error:|recog.c:2311 (error: |unrecognizable insn)|unrecognizable insn) --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/79827] genautomata segmentation fault on NI-RT Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79827 Richard Biener changed: What|Removed |Added Keywords||build Target||x86_64-linux Host||x86_64-linux Build||x86_64-linux --- Comment #6 from Richard Biener --- So I assume this is x86_64-linux. Can you try without --with-boot-ldflags=" -static -static-libgcc " as that is pretty non-standard? Did you make sure to set LD_LIBRARY_PATH in a way that picks up the runtime libraries for the compiler you built on Ubuntu (and are using to build gcc on NI RT Linux)? Doing > ldd gcc/build/genautomata should tell you if there are any odd pickups. You can debug genautomata with > cd gcc > gdb --args build/genautomata /Flash/gcc/build/gcc-6.3.0/gcc/common.md > /Flash/gcc/build/gcc-6.3.0/gcc/config/i386/i386.md insn-conditions.md (gdb) run (gdb) bt which should give you a backtrace. Of course you need gdb (can use the NI one).
[Bug c++/79827] genautomata segmentation fault on NI-RT Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79827 --- Comment #7 from Richard Biener --- You can look at imposed limits with > ulimit -a and for example raise stack limit with > ulimit -s unlimited
[Bug bootstrap/79829] New: Assumes host CC and CXX behave the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79829 Bug ID: 79829 Summary: Assumes host CC and CXX behave the same Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- When (due to a glitch) having host gcc 4.8 but host g++ 4.3 I run into [ 121s] g++ -std=gnu++98 -I../../../libcpp -I. -I../../../libcpp/../include -I ../../../libcpp/include -fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tab les -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -W -Wall -Wno-narrowing -W write-strings -Wmissing-format-attribute -pedantic -Wno-long-long -fno-exceptio ns -fno-rtti -I../../../libcpp -I. -I../../../libcpp/../include -I../../../libcp p/include -DPACKAGE_SUFFIX=\"-7\" -c -o charset.o -MT charset.o -MMD -MP -MF . deps/charset.Tpo ../../../libcpp/charset.c [ 121s] cc1plus: error: unrecognized command line option "-Wno-narrowing" because libcpp uses the host _C_ compiler for its ACX_PROG_CC_WARNING_OPTS checks while later using the host _C++_ compiler for doing the actual compilation. It looks like it is ACX_PROG_CC_WARNING_OPTS itself which forces the use of C here. Not sure if worth fixing.
[Bug c++/79830] New: GCC generates counterproductive code surrounding very simple loops (improvement request)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79830
Bug ID: 79830
Summary: GCC generates counterproductive code surrounding very
simple loops (improvement request)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kobalicek.petr at gmail dot com
Target Milestone: ---
It seems that GCC tries very hard to optimize loops, but in my case it's
counterproductive. I have illustrated the problem in the following C++ code and
disassembly.
Loops that are constructed this way need only one variable (`i`) as a loop
counter and use sign flag to check whether the loop is done or not. Typically
such loop requires simple check at the beginning (`sub` and `js`) and at the
end. The purpose of such loop is to save registers and to only require minimal
code surrounding the loop.
However, it seems that GCC tries to convert such loop into something else and
requires a lot of operations to do that, resulting in bigger and slower code.
When using `-Os` GCC produces code that I would expect, however, I don't want
to optimize for size globally.
It's not a compiler bug, but I think that in this case this optimization
doesn't make any sense and only adds to the executable/library size. I doubt
this leads to any improvement and it would be nice if GCC can somehow discover
to not do this for these kind of loops.
Also, here is a compiler explorer URL, for people wanting to compare:
https://godbolt.org/g/oeDGmy
Consider the following C++ code
---
#include
#if defined(_MSC_VER)
# include
#else
# include
#endif
void transform(double* dst, const double* src, const double* matrix, size_t
length) {
__m256d m_00_11 = _mm256_castpd128_pd256(_mm_set_pd(matrix[3], matrix[0]));
__m256d m_10_01 = _mm256_castpd128_pd256(_mm_set_pd(matrix[1], matrix[2]));
__m256d m_20_21 = _mm256_broadcast_pd(reinterpret_cast(matrix
+ 4));
m_00_11 = _mm256_permute2f128_pd(m_00_11, m_00_11, 0);
m_10_01 = _mm256_permute2f128_pd(m_10_01, m_10_01, 0);
intptr_t i = static_cast(length);
while ((i -= 8) >= 0) {
__m256d s0 = _mm256_loadu_pd(src + 0);
__m256d s1 = _mm256_loadu_pd(src + 4);
__m256d s2 = _mm256_loadu_pd(src + 8);
__m256d s3 = _mm256_loadu_pd(src + 12);
__m256d a0 = _mm256_add_pd(_mm256_mul_pd(s0, m_00_11), m_20_21);
__m256d a1 = _mm256_add_pd(_mm256_mul_pd(s1, m_00_11), m_20_21);
__m256d a2 = _mm256_add_pd(_mm256_mul_pd(s2, m_00_11), m_20_21);
__m256d a3 = _mm256_add_pd(_mm256_mul_pd(s3, m_00_11), m_20_21);
__m256d b0 = _mm256_mul_pd(_mm256_shuffle_pd(s0, s0, 0x1), m_10_01);
__m256d b1 = _mm256_mul_pd(_mm256_shuffle_pd(s1, s1, 0x1), m_10_01);
__m256d b2 = _mm256_mul_pd(_mm256_shuffle_pd(s2, s2, 0x1), m_10_01);
__m256d b3 = _mm256_mul_pd(_mm256_shuffle_pd(s3, s3, 0x1), m_10_01);
_mm256_storeu_pd(dst + 0, _mm256_add_pd(a0, b0));
_mm256_storeu_pd(dst + 4, _mm256_add_pd(a1, b1));
_mm256_storeu_pd(dst + 8, _mm256_add_pd(a2, b2));
_mm256_storeu_pd(dst + 12, _mm256_add_pd(a3, b3));
dst += 16;
src += 16;
}
i += 8;
while ((i -= 2) >= 0) {
__m256d s0 = _mm256_loadu_pd(src);
__m256d a0 = _mm256_add_pd(_mm256_mul_pd(s0, m_00_11), m_20_21);
__m256d b0 = _mm256_mul_pd(_mm256_shuffle_pd(s0, s0, 0x1), m_10_01);
_mm256_storeu_pd(dst, _mm256_add_pd(a0, b0));
dst += 4;
src += 4;
}
if (i & 1) {
__m128d s0 = _mm_loadu_pd(src + 0);
__m128d a0 = _mm_add_pd(_mm_mul_pd(s0, _mm256_castpd256_pd128(m_00_11)),
_mm256_castpd256_pd128(m_20_21));
__m128d b0 = _mm_mul_pd(_mm_shuffle_pd(s0, s0, 0x1),
_mm256_castpd256_pd128(m_10_01));
_mm_storeu_pd(dst + 0, _mm_add_pd(a0, b0));
}
}
Which is compiled to the following
--
(-O2 -mavx -fno-exceptions -fno-tree-vectorize)
See comments describing what I din't like..
transform(double*, double const*, double const*, unsigned long):
vmovsd xmm4, QWORD PTR [rdx]
mov r9, rcx
vmovsd xmm5, QWORD PTR [rdx+16]
sub r9, 8
vmovhpd xmm4, xmm4, QWORD PTR [rdx+24]
vbroadcastf128 ymm6, XMMWORD PTR [rdx+32]
mov r8, rcx
vmovhpd xmm5, xmm5, QWORD PTR [rdx+8]
vperm2f128 ymm4, ymm4, ymm4, 0
vperm2f128 ymm5, ymm5, ymm5, 0
js .L6
;; <--- Weird
mov rax, r9
sub rcx, 16
mov r8, r9
and rax, -8
mov rdx, rsi
sub rcx, rax
mov rax, rdi
;; <--- Weird
.L5:
vmovupd xmm3, XMMWORD PTR [rdx]
sub r8, 8
sub rax, -128
sub rdx, -128
vinsertf128 ymm3, ymm3, XMMWORD PTR [rdx-112], 0x1
vmovupd xmm2, XMMWORD PTR [rdx-96]
[Bug tree-optimization/79830] GCC generates counterproductive code surrounding very simple loops (improvement request)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79830 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-03 CC||amker at gcc dot gnu.org Component|c++ |tree-optimization Version|unknown |7.0.1 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- It is induction variable optimization (-fivopts) that re-writes the main induction variable. We have Original cost 17 (complexity 2) Final cost 17 (complexity 2) Selected IV set for loop 2 at t.C:44, 4 avg niters, 0 expressions, 1 IVs: Candidate 5: Var befor: ivtmp.25_108 Var after: ivtmp.25_107 Incr POS: before exit test IV struct: Type: sizetype Base: 0 Step: 32 Biv:N Overflowness wrto loop niter: No-overflow Replacing exit test: if (i_32 >= 0) but it doesn't seem to account the extra cost for the exit test replacement when facing equal original/final cost.
[Bug tree-optimization/79830] GCC generates counterproductive code surrounding very simple loops (improvement request)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79830 --- Comment #2 from Petr --- I'm not sure I follow with the exit test. I mean the code should be correct as each point has x|y coord, which is two doubles, so length 8 means 16 doubles (I converted from my production code into a simpler form that uses only native types). However, I think that the problem is also that if this code was handwritten it would only use 3 registers (dst, src, and i), but GCC uses: rax|rcd|rdx|rsi|rdi|r8|r9 which is a lot and the same code in 32-bit mode contains one short spill of GP register. Basically if I needed more GP registers inside the function the problem would be much bigger (but no clue if GCC would use different approach in that case).
[Bug tree-optimization/79830] GCC generates counterproductive code surrounding very simple loops (improvement request)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79830 --- Comment #3 from Petr --- Sorry for misunderstanding, I really read initially that you replaced the exit condition in the sample code :)
[Bug middle-end/79831] New: [DOC][CHKP] Missing -Wchkp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79831 Bug ID: 79831 Summary: [DOC][CHKP] Missing -Wchkp Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: ienkovich at gcc dot gnu.org Target Milestone: --- We miss documentation for the option.
[Bug rtl-optimization/79812] [7 Regression] ICE in simplify_binary_operation_1, at simplify-rtx.c:3586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79812 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-03-03 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Looking into this.
[Bug c++/79796] [5/6/7 Regression] ICE with NSDMI and this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79796
--- Comment #5 from Marek Polacek ---
Surprisingly my naïve attempt to fix this works:
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8047,6 +8047,8 @@ build_over_call (struct z_candidate *cand, int flags,
tsubst_flags_t complain)
{
arg = cp_build_indirect_ref (arg, RO_NULL, complain);
val = build2 (MODIFY_EXPR, TREE_TYPE (to), to, arg);
+ if (cxx_dialect >= cxx14)
+ replace_placeholders (arg, to);
}
else
{
and the C++ testsuite passes.
[Bug c++/79832] New: [C++14/17] result of array subscript operator should be xvlaue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79832
Bug ID: 79832
Summary: [C++14/17] result of array subscript operator should
be xvlaue
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: felix.morgner at gmail dot com
Target Milestone: ---
According to ISO14882:2014 [expr.sub] (as well as the current draft) the
following should yield an xvalue on line 3 (arr{}[0]):
int main() {
using arr = int[3];
arr{}[0];
}
since 'arr{}' is an array prvalue. It seems that it does not in GCC since the
following code compiles just fine:
int main() {
using arr = int[3];
&arr{}[0];
}
even though taking the address of an xvalue (the result of subscripting the
array prvalue) is invalid. There exists a relevant DR1213 (pre C++14) here:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1213 which
introduced the notion that subscripting a non lvalue array yields an xvalue.
Compiled using -Wall -Wextra -pedantic with GCC 6.3.1
[Bug c++/79832] [C++14/17] result of subscripting non lvalue array should be xvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79832 --- Comment #1 from Felix Morgner --- adjusted the title to be more clear. sorry!
[Bug middle-end/68270] [MPX] Common pattern for variable sized data clashes with MPX bound checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68270
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-03-03
CC||marxin at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #4 from Martin Liška ---
The issue is not solved, let's consider:
$ cat /tmp/chkp.ii
typedef struct a *b;
struct a {
struct {
int e[1];
} f;
};
int g(b ptr)
{
return ptr->f.e[1];
}
$ ./xgcc -B. /tmp/chkp.ii -Werror -c -mmpx -fcheck-pointer-bounds -O1 -Wall
-fchkp-flexible-struct-trailing-arrays
/tmp/chkp.ii: In function ‘int g.chkp(b,
\xe2\x80\x98pointer_bounds_typ\xe2\x80\x99 not supported by dump_type#, void, ...)’:
/tmp/chkp.ii:9:20: error: memory access check always fail [-Werror=chkp]
return ptr->f.e[1];
^
cc1plus: all warnings being treated as errors
It's wrong and reason is explained in Richi's email:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00172.html
I'm testing the patch.
[Bug target/79793] Incorrect stack alignment for interrupt handler in 64-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79793 --- Comment #2 from Yulia Koval --- Patch posted at https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00178.html
[Bug target/79812] [7 Regression] ICE in simplify_binary_operation_1, at simplify-rtx.c:3586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79812 --- Comment #2 from Jakub Jelinek --- Created attachment 40880 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40880&action=edit gcc7-pr79812.patch Untested fix.
[Bug target/79812] [7 Regression] ICE in simplify_binary_operation_1, at simplify-rtx.c:3586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79812 Jakub Jelinek changed: What|Removed |Added CC||uros at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Guess it would be nice to check somewhere in genrecog.c or similar that if we have a vec_select with parallel (rather than say match_parallel) inside of it, then it has the right number of elements.
[Bug tree-optimization/79828] missing div-by-zero warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828 --- Comment #7 from Jeffrey A. Law --- The thing is, if we could prove the trap is always executed, then we'd just zap everything prior to the trap without visible side effects and everything after the trap. It's actually not an interesting case. It's critical to remember that a trap introduced by the compiler is on a *path* through the CFG and a series of conditionals has to be met for the trap to be executed. The compiler has already tried to prove the path is infeasible and failed. In fact, that pass was originally introduced specifically because there are cases where the compiler will never be able to prove a particular problem path can't execute and as a result it must keep the path in the CFG, which in turn leads to false positives from -Wuninitialized later. By isolating the path and introducing a trap on that path, the CFG simplifies in useful ways *and* if the program were to erroneously get on the path, it gets halted prior to execution of undefined behavior which is desirable from a security standpoint. There is some code in tree-ssa-uninit.c which does predicate analysis to further reduce the set of false positives for -Wuninitialized. However, that code won't solve the problems that folks are looking at here (if it did, we wouldn't have erroneous path isolation to begin with).
[Bug tree-optimization/79828] missing div-by-zero warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79828 --- Comment #8 from Arnd Bergmann --- (In reply to Jakub Jelinek from comment #6) > If the warning has false positives, then I'm sure the kernel will turn it > off anyway like it does with tons of other warnings. That is well possible. I try to catch new warnings early by building lots of kernels with random configurations and sending kernel fixes, but if there are more than a few dozen instances and none of them are interesting kernel bugs, I'd also turn off that warning. I have started going through all available warnings to see how much output they generate (97GB on an allmodconfig kernel build when turning them all on with gcc, more with clang), with the intention of re-enabling the more useful ones, but will take a while to get there as I can only enable them after having fixed all the warnings we get.
[Bug tree-optimization/79699] small memory leak in MPFR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79699 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Sebor --- Fixed in r245878.
[Bug tree-optimization/79699] small memory leak in MPFR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79699 --- Comment #7 from Martin Sebor --- Author: msebor Date: Fri Mar 3 16:35:00 2017 New Revision: 245878 URL: https://gcc.gnu.org/viewcvs?rev=245878&root=gcc&view=rev Log: PR tree-optimization/79699 - small memory leak in MPFR gcc/ChangeLog: * context.c (context::~context): Free MPFR caches to avoid a memory leak on program exit. Modified: trunk/gcc/ChangeLog trunk/gcc/context.c
[Bug target/43763] segfault when using by -mwarn-cell-microcode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43763 --- Comment #4 from Segher Boessenkool --- Author: segher Date: Fri Mar 3 17:00:50 2017 New Revision: 245880 URL: https://gcc.gnu.org/viewcvs?rev=245880&root=gcc&view=rev Log: rs6000: Fix for -mwarn-cell-microcode (PR43763) If using -mwarn-cell-microcode, rs6000_final_prescan_insn calls get_insn_template to get the name of the machine instruction. But, get_insn_template calls the output template if that is code, and that then can modify recog_data (it is normal to change the operands, for example). This patch saves and restores recog_data around the call to get_insn_template to fix the problems this causes. PR target/43763 * config/rs6000/rs6000.c (rs6000_final_prescan_insn): Save and restore recog_data (including the operand rtxes inside it) around the call to get_insn_template. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug c++/79833] New: std::put_time has the wrong values for 2 digit years
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79833
Bug ID: 79833
Summary: std::put_time has the wrong values for 2 digit years
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jllansf at lirr dot org
Target Milestone: ---
When using the %y specifier on the std::put_time function the documentation
both for std::put_time and the posix strptime() read:
y: The last two digits of the year. When format contains neither a C
conversion specifier nor a Y conversion specifier, values in the range [69,99]
shall refer to years 1969 to 1999 inclusive and values in the range [00,68]
shall refer to years 2000 to 2068 inclusive;
Running the following sample code:
int main(int argc, char * argv[]) {
std::tm t = {0};
std::istringstream ss("03/03/17 11:03:16");
ss.imbue(std::locale("en_US.UTF8"));
ss >> std::get_time(&t, "%m/%d/%y %H:%M:%S");
if (ss.fail()) {
std::cout << "Parse failed\n";
} else {
std::cout << std::put_time(&t, "%c") << '\n';
}
}
Yields: "Sun Mar 3 11:03:16 1917"
When based on the documentation since 17, is in the [00,68] range it should
instead Result in the value "Sun Mar 3 11:03:16 2017"
[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854 --- Comment #10 from Jerry DeLisle --- We are not handling the internal unit check correctly in unit.c (get_unit) and we return a NULL to the caller which is then interpreted as an error. I am working on the fix now. (just a little head scratching)
[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571 --- Comment #7 from Vladimir Makarov --- I am working on the PR. I hope the fix will be ready at the beginning of the next week.
[Bug target/43763] segfault when using by -mwarn-cell-microcode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43763 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org
[Bug inline-asm/79804] ICE in print_reg, at config/i386/i386.c:17637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79804
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-03-03
Component|target |inline-asm
Ever confirmed|0 |1
--- Comment #2 from Uroš Bizjak ---
Minimized testcase:
--cut here--
void foo (int x)
{
register int r20 asm ("20") = x;
asm volatile ("# %0" : : "r" (r20));
}
--cut here--
(gdb) f 2
#2 0x00e8fcdc in print_reg (x=0x70265f18, code=0, file=0x1fd3620)
at /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:17634
17634 gcc_assert (regno != ARG_POINTER_REGNUM
(gdb) list
17629 else
17630 msize = GET_MODE_SIZE (GET_MODE (x));
17631
17632 regno = REGNO (x);
17633
17634 gcc_assert (regno != ARG_POINTER_REGNUM
17635 && regno != FRAME_POINTER_REGNUM
17636 && regno != FPSR_REG
17637 && regno != FPCR_REG);
17638
(gdb) p debug_rtx (x)
(reg/v:SI 20 frame [ r20 ])
$3 = void
While we can change the assert to an error, I really wonder how the numeric
name gets pass "invalid register name" check. Naming a register e.g "x20" gets
us:
pr79804.c: In function ‘foo’:
pr79804.c:3:16: error: invalid register name for ‘r20’
register int r20 asm ("x20") = x;
I'll recategorize this PR to a generic inline-asm component.
[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #8 from Bernd Schmidt ---
I was also playing with this before I noticed Jakub was investigating. As an
experiment, I came up with the following, trying to recognize situations where
picking one alternative would cause an infinite cycle:
Index: lra-constraints.c
===
--- lra-constraints.c (revision 245685)
+++ lra-constraints.c (working copy)
@@ -1899,6 +1899,7 @@ process_alt_operands (int only_alternati
int reload_nregs, reload_sum;
bool costly_p;
enum reg_class cl;
+ bool must_not_reload_op1 = false;
/* Calculate some data common for all alternatives to speed up the
function. */
@@ -1932,6 +1933,15 @@ process_alt_operands (int only_alternati
= regno_reg_rtx[hard_regno[nop]];
}
+ /* See if we have an insn of the form
+ (set (pseudo) (something)
+ If yes, then we should not try to reload operand 1 into a pseudo,
+ because this would cause an infinite cycle. */
+ if (curr_insn_set != NULL_RTX
+ && operand_reg[0] != NULL_RTX
+ && hard_regno[0] < 0)
+must_not_reload_op1 = true;
+
/* The constraints are made of several alternatives. Each operand's
constraint looks like foo,bar,... with commas separating the
alternatives. The first alternatives for all operands go
@@ -2193,7 +2203,10 @@ process_alt_operands (int only_alternati
switch (get_constraint_type (cn))
{
case CT_REGISTER:
- cl = reg_class_for_constraint (cn);
+ if (nop == 1 && must_not_reload_op1)
+ cl = NO_REGS;
+ else
+ cl = reg_class_for_constraint (cn);
if (cl != NO_REGS)
goto reg;
break;
Sadly, it seems to be ineffective (or at least incomplete), it goes into a
different infinite cycle.
[Bug target/77687] frame access after release without redzone on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77687 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-03-03 Ever confirmed|0 |1
[Bug target/50467] Compiler can move stack cleanup before last memory reference involving the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50467 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Segher Boessenkool --- This is a duplicate of 77687, which is fixed on trunk. *** This bug has been marked as a duplicate of bug 77687 ***
[Bug target/77687] frame access after release without redzone on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77687 Segher Boessenkool changed: What|Removed |Added CC||meissner at gcc dot gnu.org --- Comment #5 from Segher Boessenkool --- *** Bug 50467 has been marked as a duplicate of this bug. ***
[Bug fortran/79596] translation: argument to gfc_internal_error should not be translated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79596 --- Comment #2 from Roland Illig --- (In reply to Dominique d'Humieres from comment #1) > > Internal errors should not be translated. Their only purpose is to give > > information back to the developers, and this information should not be > > modified by any translator. > > I agree, but how do achieve that? gcc/Makefile.in contains the po/gcc.pot target, which uses po/exgettext. I assume that somewhere there is some list of functions that take translatable strings, since xgettext has to decide which of these functions take printf-style arguments and which take gcc-internal-style arguments. The gfc_internal_error function should be removed from that list. I could not find this list anywhere, though.
[Bug tree-optimization/78687] inefficient code generated for eggs.variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78687 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #5 from Martin Jambor --- Mine.
[Bug tree-optimization/71437] [7 regression] Performance regression after r235817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71437 Jeffrey A. Law changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #15 from Jeffrey A. Law --- So what looks real promising here. 1. Pull the "handle_dominating_asserts" bits out of tree-ssa-threadedge and into tree-vrp.c. They really should have been there all along. 2. Improve DOM's handling of BIT_AND_EXPR/BIT_IOR_EXPR to avoid a couple minor regressions due to #1. 3. Push some common code from tree-vrp.c/tree-ssa-dom.c into tree-ssa-threadedge.c. 4. Change the random walk order for threading in tree-vrp.c to a domwalk 5. Record data from ASSERT_EXPRs during threading domwalk 6. Query the expression hash table in simplify_stmt_for_jump_threading It all sounds more complex than it is. In addition to fixing bz71437, it starts some refactoring towards addressing bz78496 and cutting down on the amount of work we're doing for jump threading.
[Bug libstdc++/77854] std::deque doesn't use allocator's size_type and difference_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77854 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-03 Ever confirmed|0 |1
[Bug c++/58987] [5/6/7 Regression] ICE with template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58987 Volker Reichelt changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code Known to work||4.7.0, 4.7.2 Summary|[c++11] ICE with template |[5/6/7 Regression] ICE with |alias |template alias --- Comment #1 from Volker Reichelt --- Although the default template parameter is not used here, the code is probably ill-formed, so that we actually have a regression here. This bug is related to PR77339.
[Bug c/79834] New: c/c-parser.c: make code more i18n-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79834 Bug ID: 79834 Summary: c/c-parser.c: make code more i18n-friendly Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- The following code pattern occurs several times: c_parser_error (parser, "%<#pragma acc update%> may only be " "used in compound statements"); Each of these occurrences has to be translated individually by a translator for each of the supported human languages. This creates unnecessary work. It would be less work (and fewer chances of introducing typos) to have only one template: c_parser_error (parser, "%<#pragma %s%> may only be " "used in compound statements", "acc update"); The code in c/c-parser.c and cp/parser.c should therefore use the second pattern consistently.
[Bug c/79835] New: load to a variable outside the scope of a function is optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79835
Bug ID: 79835
Summary: load to a variable outside the scope of a function is
optimized out
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugreporting at gmx dot com
Target Milestone: ---
We use tcmalloc. Tcmalloc allows hooks that can be called during malloc. I was
using a static __thread thread-local variable to prevent re-entrance. I.e.,
in_malloc_hook = 1;
...do work that might call malloc...
in_malloc_hook = 0;
Sometimes the line setting in_malloc_hook = 1 would be optimized away.
I worked up an example that shows this problem without using tcmalloc.
First, create mymalloc.o that supplies a malloc() function from this mymalloc.c
file:
/*
* gcc -g -O2 -Wall mymalloc.c -c -o mymalloc.o
*/
#include
#include
static void (*mymalloc_hook)(const void *ptr, size_t size);
void mymalloc_addhook(void (*f)(const void *ptr, size_t size)) {
mymalloc_hook = f;
}
void *malloc(size_t count) { // Will work the same way regardless of
fno-tree-dse if this is changed to mymalloc.
void *ptr = sbrk(count);
mymalloc_hook(ptr, count);
return ptr;
}
Next, link this .o into the following program, example.c:
/*
$ gcc -g -O2 -Wall example.c mymalloc.o -o example
$ ./example
0x55d73b3a4000 64 0x55d73b3a4040
0x55d73b3a4000
$ gcc -g -O2 -fno-tree-dse -Wall example.c mymalloc.o -o example
$ ./example
0x55d31f3ea000 64 (nil)
0x55d31f3ea000
*/
#include
#include
void mymalloc_addhook(void (*f)(const void *ptr, size_t size));
// Will work the same way regardless of fno-tree-dse if void *malloc(size_t) is
declared here.
static int in_hook = 0;
static int allocating = 0;
static void *buffer = NULL;
void *foo(void);
void hook(const void *ptr, size_t size) {
void *current;
if (in_hook) {
return;
}
in_hook = 1;
current = foo();
printf("%p %ld %p\n", ptr, size, current);
in_hook = 0;
}
void *foo(void) {
if (!buffer) {
if (allocating) {
return NULL;
}
allocating = 1; // Without -fno-tree-dse, this is optimized
out.
buffer = malloc(64);
allocating = 0;
}
return buffer;
}
int main() {
mymalloc_addhook(&hook);
printf("%p\n", foo());
return 0;
}
Then run the program. Note that the expectation is that, when we print out
current, it will always be (nil) because we guard against calling malloc more
than once.
However, this only happens with older versions of gcc (4.4.7) but not with
newer versions (4.9.2 and up). Using fno-tree-dse will get the correct
behavior.
The problem seems to be that gcc thinks that malloc is a builtin, even when it
is being provided by an external library (e.g., mymalloc.o or tcmalloc). It
therefore thinks that malloc cannot change a file-local variable, so it can
optimize out the load.
However, in this case, we have replaced malloc, and it can call back into
functions that change or test this file-local (or global? didn't test that)
variable.
If the name of the function "malloc" is changed, then (nil) is always returned
for the value of current, as expected.
The gcc command is in the comments. This works with many different versions of
gcc, from 4.9.2 and up.
$ gcc --version
gcc (Debian 6.3.0-5) 6.3.0 20170124
$ uname -a
Linux 4.9.0-1-amd64 #1 SMP Debian 4.9.2-2 (2017-01-12) x86_64 GNU/Linux
[Bug middle-end/79805] [7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79805 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Mar 3 19:32:01 2017 New Revision: 245882 URL: https://gcc.gnu.org/viewcvs?rev=245882&root=gcc&view=rev Log: PR middle-end/79805 * internal-fn.def (ATOMIC_BIT_TEST_AND_SET, ATOMIC_BIT_TEST_AND_RESET, ATOMIC_BIT_TEST_AND_COMPLEMENT, ATOMIC_COMPARE_EXCHANGE): Remove ECF_NOTHROW. * gimple-fold.c (fold_builtin_atomic_compare_exchange): Set gimple_call_nothrow_p flag based on whether original builtin can throw. If it can, emit following stmts on the fallthrough edge. * tree-ssa-ccp.c (optimize_atomic_bit_test_and): Similarly, except don't create new bb if inserting just debug stmts on the edge, try to insert them on the fallthru bb or just reset debug stmts. * g++.dg/opt/pr79805.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr79805.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/internal-fn.def trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c
[Bug middle-end/79835] load to a variable outside the scope of a function is optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79835 Andrew Pinski changed: What|Removed |Added Component|c |middle-end --- Comment #1 from Andrew Pinski --- You need to mark the variable as volatile as gcc thinks malloc does not change any global visiable state. There is a duplicate of this issue already but I can't find it right now.
[Bug libfortran/78379] Processor-specific versions for matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 --- Comment #27 from Thomas Koenig --- (In reply to # David Edelsohn from comment #26) > What is AVX-specific, as opposed to SIMD vector size-specific, about this > feature? It seems that this should be enabled for all SIMD architectures of > the appropriate width. You're right, this might as well apply to other architectures where SIMD instructions are available only on some architectures, but cannot be turned on by default because they are not universally implemented. I would need three pieces of information: - What to put into the libgfortran config file to check if the installed binutils support the SIMD extension in question - How to check at runtime for the specific processor version - Which options to pass to __attribute__((__target__ .. Then it is relatively straightforward to put this in.
[Bug c/79836] New: typo in c/c-parser.c: pragma omp ordered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79836 Bug ID: 79836 Summary: typo in c/c-parser.c: pragma omp ordered Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- error_at (loc, "%<#pragma omp ordered%> with % clause may " "only be used in compound statements"); It must be % (the percent is missing for the closing quote).
[Bug libfortran/78379] Processor-specific versions for matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379 --- Comment #28 from David Edelsohn --- Because PPC64LE Linux reset the base ISA level, VSX now is enabled by default, so a function clone for VSX probably isn't necessary. While special versions might help AIX and PPC64BE, with lower ISA defaults, those are not the focus.
[Bug c/79837] New: incomplete diagnostic in c-parser: expected +, *, -, &, ^, |, &&, ||, min or identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79837 Bug ID: 79837 Summary: incomplete diagnostic in c-parser: expected +, *, -, &, ^, |, &&, ||, min or identifier Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- c_parser_error (parser, "expected %<+%>, %<*%>, %<-%>, %<&%>, " "%<^%>, %<|%>, %<&&%>, %<||%>, % or identifier"); There is a ", max" missing after "min".
[Bug c/79836] typo in c/c-parser.c: pragma omp ordered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79836 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Fri Mar 3 19:56:54 2017 New Revision: 245883 URL: https://gcc.gnu.org/viewcvs?rev=245883&root=gcc&view=rev Log: PR c/79836 * c-parser.c (c_parser_generic_selection): Use %<_Generic%> instead of %<_Generic>. (c_parser_omp_ordered): Use % instead of %. (c_parser_omp_target_exit_data): Use % instead of %. Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c
[Bug c/79836] typo in c/c-parser.c: pragma omp ordered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79836 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- Fixed together with 2 other similar issues. Thanks for reporting these.
[Bug fortran/79838] New: inconsistent trailing dot in diagnostic "The name %qs has already been used"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79838
Bug ID: 79838
Summary: inconsistent trailing dot in diagnostic "The name %qs
has already been used"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
gfc_error ("The name %qs at %C has already been used as "
"an external module name.", use_list->module_name);
This error message, in contrast to almost every other error message, has a
trailing period. This period should be removed.
[Bug c/79837] incomplete diagnostic in c-parser: expected +, *, -, &, ^, |, &&, ||, min or identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79837 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Fri Mar 3 20:16:58 2017 New Revision: 245885 URL: https://gcc.gnu.org/viewcvs?rev=245885&root=gcc&view=rev Log: PR c/79837 * c-parser.c (c_parser_omp_clause_reduction): Don't mention % or % in the diagnostics, instead mention identifier. (c_parser_omp_declare_reduction): Don't mention % in the diagnostics. Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c
[Bug c/79837] incomplete diagnostic in c-parser: expected +, *, -, &, ^, |, &&, ||, min or identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79837 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- No, min and max are identifiers, so no need to mention them.
[Bug middle-end/79805] [7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79805 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug libstdc++/79839] New: malloc(0) returns 0 on AIX even with _LINUX_SOURCE_COMPAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79839
Bug ID: 79839
Summary: malloc(0) returns 0 on AIX even with
_LINUX_SOURCE_COMPAT
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jaideepbajwa at hotmail dot com
Target Milestone: ---
Target: aix
malloc(0) returning 0 is expected behaviour on AIX but compiling with
-D_LINUX_SOURCE_COMPAT, malloc(0) should return a valid pointer. As per:
https://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.basetrf1/malloc.html
It doesn't work for c++ program which includes . In the header it
states:
// Get rid of those macros defined in in lieu of real functions.
...
#undef malloc
The above seems to be causing the issue and resetting the behaviour of
-D_LINUX_SOURCE_COMPAT.
Code to reproduce:
>cat malloc.cpp
#include
//#include //<-- Works this stdlib
#include
int main() {
printf("%p \n", malloc(0));
return 0;
}
>g++ malloc.cpp -D_LINUX_SOURCE_COMPAT
>./a.out
0
