[Bug preprocessor/69543] [6/7/8 Regression] _Pragma does not apply within macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Target Milestone|7.0 |8.0 Summary|[6/7 Regression] _Pragma|[6/7/8 Regression] _Pragma |does not apply within macro |does not apply within macro
[Bug tree-optimization/79534] [7 Regression] tree-ifcombine aarch64 performance regression with trunk@245151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at redhat dot com
[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at redhat dot com
[Bug rtl-optimization/79405] [8 Regression] Compile-time hog w/ -O2 (-Os, -O3) on 32-bit BE powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79405 Jeffrey A. Law changed: What|Removed |Added Target Milestone|7.0 |8.0 Summary|[7 Regression] Compile-time |[8 Regression] Compile-time |hog w/ -O2 (-Os, -O3) on|hog w/ -O2 (-Os, -O3) on |32-bit BE powerpc targets |32-bit BE powerpc targets --- Comment #9 from Jeffrey A. Law --- Targeting gcc-8 to attempt Richi's suggestion to change iteration ordre to look like: for (BBs in RPO order) for (insn in BB) repeat: for (use in insn) if (propagate_into (use)) goto repeat;
[Bug rtl-optimization/79405] [7 Regression] Compile-time hog w/ -O2 (-Os, -O3) on 32-bit BE powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79405 --- Comment #8 from Jeffrey A. Law --- Author: law Date: Fri Mar 31 22:49:53 2017 New Revision: 246627 URL: https://gcc.gnu.org/viewcvs?rev=246627&root=gcc&view=rev Log: PR rtl-optimization/79405 * fwprop.c (propagations_left): New variable. (forward_propagate_into): Decrement it. (fwprop_init): Initialize it. (fw_prop): If the variable has reached zero, stop propagating. (fwprop_addr): Ditto. gcc/testsuite/ PR rtl-optimization/79405 gcc.dg/pr79405.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr79405.c Modified: trunk/gcc/ChangeLog trunk/gcc/fwprop.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/61428] wrong "maybe-uninitialized" (jump threading? predicate analysis?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61428 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #3 from Jeffrey A. Law --- This is a case where DOM, VRP and backwards jump threading all fail to simplify the CFG enough, leaving it in a state where the uninit pass is unable to prove the all the paths to free lock_1 are properly guarded. It is the case that VRP1, DOM2, DOM3, VRP2 all successively simplify the CFG, each time they expose an opportunity to thread jumps deeper int the CFG. But in the end, we can only thread through a single join point in the CFG each iteration due to limitations in the copier used by VRP/DOM. The pass best suited for tackling this would be the backwards jump threader. But it doesn't yet know how to extract a constant equivalence from a conditional. So it never has the chance to see the deep jump threads because there are no assignments to need_lock_1. If we were able to derive those equivalences, I suspect the backward threader would likely clean up the CFG significantly. ANyway, we're left with a fairly complex CFG with merge points in very inconvenient places -- making it impossible for tree-ssa-uninit to prove the uses of lock_1 are properly guarded.
[Bug middle-end/59500] Bogus maybe-uninitialized (|| converted to nested-if)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59500 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jeffrey A. Law --- Per c#6.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 59500, which changed state. Bug 59500 Summary: Bogus maybe-uninitialized (|| converted to nested-if) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59500 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 56748, which changed state. Bug 56748 Summary: Bogus uninitialized warning with nested if condition https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56748 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/56748] Bogus uninitialized warning with nested if condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56748 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Not sure when this was fixed, but it works fine on the trunk. VRP1/DOM2 are able to thread the conditional branches (which removes unexecutable paths) with the net result is all the uninitialized uses of b.0 are ultimately removed.
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 Bill Schmidt changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #10 from Bill Schmidt --- For C++, "type_6" indicates that TYPE_DEPENDENT_P_VALID is nonzero for the type. This apparently gets set for the basic SI type during C++ language-dependent initialization, but only after the first two V4SI types are created. Here's the backtrace when this occurs: Breakpoint 8, dependent_type_p (type=0x3fffb5b10738) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23486 23486 TYPE_DEPENDENT_P_VALID (type) = 1; (gdb) ptr type constant 32> unit size constant 4> align 32 symtab 0 alias set -1 canonical type 0x3fffb5b10738 precision 32 min max pointer_to_this > (gdb) bt #0 dependent_type_p (type=0x3fffb5b10738) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23486 #1 0x104c7220 in dependent_type_p_r (type=0x3fffb5d33fa8) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23366 #2 0x104c7c10 in dependent_type_p (type=0x3fffb5d33fa8) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23485 #3 0x104c71c0 in dependent_type_p_r (type=0x3fffb5d34050) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23360 #4 0x104c7c10 in dependent_type_p (type=0x3fffb5d34050) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:23485 #5 0x1046fa5c in uses_template_parms (t=0x3fffb5d34050) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/pt.c:9351 #6 0x106d0b3c in build_cplus_array_type (elt_type=0x3fffb5d34050, index_type=0x0) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/tree.c:899 #7 0x103db958 in cxx_init_decl_processing () at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/decl.c:4154 #8 0x1057c22c in cxx_init () at /home/wschmidt/gcc/gcc-mainline-test2/gcc/cp/lex.c:250 #9 0x1119a5a8 in lang_dependent_init ( name=0x3bb8 "pr79905.cpp") at /home/wschmidt/gcc/gcc-mainline-test2/gcc/toplev.c:1763 #10 0x1119ae7c in do_compile () at /home/wschmidt/gcc/gcc-mainline-test2/gcc/toplev.c:1986 #11 0x1119b448 in toplev::main (this=0x3316, argc=24, argv=0x3738) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/toplev.c:2134 #12 0x11f2f160 in main (argc=24, argv=0x3738) at /home/wschmidt/gcc/gcc-mainline-test2/gcc/main.c:39 (gdb) I think we will need a C++ expert to advise what to do about this. I'm now officially out of my league. CCing Jason for advice on who we should ask.
[Bug target/80108] ICE in aggregate_value_p at function.c:2028
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80108 --- Comment #10 from kelvin at gcc dot gnu.org --- FWIW, I tried another variant on the patch, which is shown below. This variant handles all of the p9-specific target options the same, as seen below: Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c (revision 246573) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -4273,8 +4273,32 @@ rs6000_option_override_internal (bool global_init_ /* For the newer switches (vsx, dfp, etc.) set some of the older options, unless the user explicitly used the -mno- to disable the code. */ if (TARGET_P9_VECTOR || TARGET_MODULO || TARGET_P9_DFORM_SCALAR - || TARGET_P9_DFORM_VECTOR || TARGET_P9_DFORM_BOTH > 0 || TARGET_P9_MINMAX) -rs6000_isa_flags |= (ISA_3_0_MASKS_SERVER & ~rs6000_isa_flags_explicit); + || TARGET_P9_DFORM_VECTOR || TARGET_P9_DFORM_BOTH > 0 + || TARGET_P9_MINMAX) +{ + if (have_cpu) + { + if (cpu_index == PROCESSOR_POWER9) + /* legacy behavior: allow -mcpu-power9 with certain capabilities + (eg -mno-vsx) explicitly disabled. */ + rs6000_isa_flags |= + (ISA_3_0_MASKS_SERVER & ~rs6000_isa_flags_explicit); + else + error ("Power9 target option is incompatible with -mcpu= for " + " less than power9"); + } +#ifdef KELVIN_REMOVE + else if ((ISA_3_0_MASKS_SERVER & rs6000_isa_flags_explicit) + != (ISA_3_0_MASKS_SERVER & rs6000_isa_flags + & rs6000_isa_flags_explicit)) + /* Enforce that none of the ISA_3_0_MASKS_SERVER flags + were explicitly cleared. */ + error ("-mpower9-minmax incompatible with explicitly disabled options"); +#endif + else + rs6000_isa_flags |= + (ISA_3_0_MASKS_SERVER & ~rs6000_isa_flags_explicit); +} else if (TARGET_P8_VECTOR || TARGET_DIRECT_MOVE || TARGET_CRYPTO) rs6000_isa_flags |= (ISA_2_7_MASKS_SERVER & ~rs6000_isa_flags_explicit); else if (TARGET_VSX) This variant also results in numerous regressions: 942 new fewer "expected passes", 4 more "unexpected failures", 339 more "unsupported tests".
[Bug c/80274] There is an unoptimized direct memory write of 16bit value on x86_64 with O2 and O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80274 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from H.J. Lu --- It is done on purpose to avoid Length Changing Prefix Stall: [hjl@gnu-6 tmp]$ cat s.c void foo() { *(unsigned short *)0x=1; } [hjl@gnu-6 tmp]$ gcc -S -O2 s.c -mtune-ctrl="^lcp_stall" [hjl@gnu-6 tmp]$ cat s.s .file "s.c" .text .p2align 4,,15 .globl fo .type foo, @function foo: .LFB0: .cfi_startproc movw$1, 65535 ret .cfi_endproc .LFE0: .size foo, .-foo .ident "GCC: (GNU) 6.3.1 20170216 (Red Hat 6.3.1-3)" .section.note.GNU-stack,"",@progbits [hjl@gnu-6 tmp]$
[Bug c++/77339] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: in cp_parser_type_name, at cp/parser.c:16532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77339 --- Comment #6 from Volker Reichelt --- *** Bug 58987 has been marked as a duplicate of this bug. ***
[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 Status|NEW |RESOLVED Known to work||7.0.1 Resolution|--- |DUPLICATE --- Comment #2 from Volker Reichelt --- Fixed with the patch for PR77339, so marking as duplicate. *** This bug has been marked as a duplicate of bug 77339 ***
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 --- Comment #9 from Bill Schmidt --- I believe the problem has to do with the basic integer type for SI mode changing hash values after it is first created. I stopped in make_vector_type for all vectors created with 4 elements, and found three of them with a base type having SI mode. The first two had the same base integer type, reported as "int public SI". Both were canonicalized to the first one that was created, all good. The third had the same base integer type, but that type had changed slightly in the meanwhile. It was now reported as "int public type_6 SI". As a result, this appeared to change the hash for vector types based upon it. This third type was created in response to the "vector int b;" decl (the AltiVec decl); and the hash of this type was now unique, so it was canonicalized to itself. Interestingly, the V4i type was created without ever going through the make_vector_type interface. I haven't tracked down where it came from, but I believe that to be irrelevant. When we ICE, the V4i type exists, is based on the same "int public type_6 SI" type, and canonicalizes to the AltiVec type. So the problem is not that the AltiVec and V4i types are incompatible. We ICE when observing that the very first type created is not canonicalized to the same type as the V4i type is. My theory is that the change involving "type_6" is responsible for this.
[Bug middle-end/79915] ICE in final_scan_insn, at final.c:2982 (could not split insn) on mips* when compiling libstdc++ with -mlong-calls -mno-abicalls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79915 mpf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-03-31 CC||mpf at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||7.0.1 --- Comment #5 from mpf at gcc dot gnu.org --- This is a bug coming from LRA rematerialisation. The issue is that one or more LEA64 instructions get rematerialized at a point where there are no other spills to resolve. Each LEA64 instruction introduces a new scratch which is a copy of the original scratch but is unallocated. lra_need_for_spills_p says false in this circumstance but is 'wrong'. One option is to simply go round the LRA loop one more time (and ensure that the lra_spill code does not assert because of there being no spills to deal with; it effectively becomes a NOP). There are plenty of alternative solutions which would involve determining whether remat introduced any new scratches and only running the loop again in that situation. We could also optimise to avoid running the lra_spill code as we really need to get to the top of the loop to re-run assignment I believe. It almost seems cleaner to continue round the LRA loop after remat and rely on the single exit point but I assume it was an optimisation to exit immediately after remat if it resolves all remaining spills. Vladimir: Is my description detailed enough for you to understand the issue or should I add dumps as well for a testcase? Is there anything 'safe enough' to do at this point of release? I'm testing my quick fix as below in case it is a suitable solution. diff --git a/gcc/lra-spills.c b/gcc/lra-spills.c index 492fc18..863136d 100644 --- a/gcc/lra-spills.c +++ b/gcc/lra-spills.c @@ -565,7 +565,6 @@ lra_spill (void) /* We do not want to assign memory for former scratches. */ && ! lra_former_scratch_p (i)) pseudo_regnos[n++] = i; - lra_assert (n > 0); pseudo_slots = XNEWVEC (struct pseudo_slot, regs_num); for (i = FIRST_PSEUDO_REGISTER; i < regs_num; i++) { diff --git a/gcc/lra.c b/gcc/lra.c index ed1f062..c906d94 100644 --- a/gcc/lra.c +++ b/gcc/lra.c @@ -2490,8 +2490,6 @@ lra (FILE *f) /* We need full live info -- see the comment above. */ lra_create_live_ranges (lra_reg_spill_p, true); live_p = true; - if (! lra_need_for_spills_p ()) - break; } lra_spill (); /* Assignment of stack slots changes elimination offsets for
[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671 --- Comment #85 from Jason Merrill --- (In reply to Bernd Edlinger from comment #84) > all valid examples used a union with an array of unsigned char. Right? There doesn't need to be a union, just an array of unsigned char.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63224 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Jeffrey A. Law --- Because of the -Os & size of duplicated block heuristic issue, this is ultimately a duplicate of 36550. Fix jump threading to recognize when the duplicate block will ultimately be eliminated as dead code and both bugs get fixed. *** This bug has been marked as a duplicate of bug 36550 ***
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 63224, which changed state. Bug 63224 Summary: false positive for -Wmaybe-uninitialized at -Os (not -O2) with && transformed to & https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63224 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/36550] Wrong "may be used uninitialized" warning (conditional PHIs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550 Jeffrey A. Law changed: What|Removed |Added CC||joel at gcc dot gnu.org --- Comment #16 from Jeffrey A. Law --- *** Bug 63224 has been marked as a duplicate of this bug. ***
[Bug middle-end/36550] Wrong "may be used uninitialized" warning (conditional PHIs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36550 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #15 from Jeffrey A. Law --- Note that Os throttles jump threading as jump threading often increases codesize. That's why you get this warning at -Os, but not at -O2.Jump threading does not have a good way to estimate how much of the duplicated block will be eliminated as dead code. In this testcase, the contents of the duplicated block would be entirely eliminated as dead code making threading jumps 100% free from a codesize standpoint. That's where I think the focus is better spent (rather than adding additional cases to tree-ssa-uninit.c). Improve the jump threading heuristics -- the net result will be better code *and* the warning goes away as a side effect.
[Bug target/80086] ICE: in extract_constrain_insn, at recog.c:2213 for the gcc.dg/vect/slp-perm-6.c test on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80086 mpf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from mpf at gcc dot gnu.org --- Same issue as reported against GCC 5 and 6.
[Bug middle-end/70736] false positive uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70736 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Fixed a year or so (gcc-6 era). No plans to backport.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 70736, which changed state. Bug 70736 Summary: false positive uninitialized warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70736 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63224 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #10 from Jeffrey A. Law --- Note that Os throttles jump threading as jump threading often increases codesize. That's why you get this warning at -Os, but not at -O2.Jump threading does not have a good way to estimate how much of the duplicated block will be eliminated as dead code. In the reduced testcase, the contents of the duplicated block would be entirely eliminated as dead code making threading jumps 100% free from a codesize standpoint. That's where I think the focus is better spent (rather than adding additional cases to tree-ssa-uninit.c). Improve the jump threading heuristics -- the net result will be better code *and* the warning goes away as a side effect.
[Bug target/80057] typo in mips.opt: Virtualization Application Specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80057 mpf at gcc dot gnu.org changed: What|Removed |Added CC||mpf at gcc dot gnu.org --- Comment #3 from mpf at gcc dot gnu.org --- I agree there is an inconsistency here (or several actually but not all can be fixed). We refer to the Virtualization Application-Specific Extension with shortened forms of Virtualization ASE or VZ ASE. Unfortunately the option name -mvirt is not -mvz but I can't fix that. We can fix the description though so it matches terms used elsewhere: Use Virtualization (VZ) instructions. I'll push a patch for it.
[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60818 --- Comment #23 from Segher Boessenkool --- I have a patch for the problem in comments 17 and 19 (which is different from the problems in earlier comments, only some of which i can reproduce).
[Bug middle-end/61112] Simple example triggers false-positive -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61112 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #4 from Jeffrey A. Law --- Fixed long ago.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 61112, which changed state. Bug 61112 Summary: Simple example triggers false-positive -Wmaybe-uninitialized warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61112 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/59500] Bogus maybe-uninitialized (|| converted to nested-if)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59500 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #6 from Jeffrey A. Law --- This was fixed a few years ago by: Author: amker Date: Wed Feb 26 01:49:35 2014 + PR target/60280 * tree-cfgcleanup.c (tree_forwarder_block_p): Protect loop preheaders and latches only if requested. Fix latch if it is removed. * tree-ssa-dom.c (tree_ssa_dominator_optimize): Set LOOPS_HAVE_PREHEADERS. PR target/60280 * gnat.dg/renaming5.adb: Change to two expected gotos. * gcc.dg/tree-ssa/pr21559.c: Change back to three expected jump threads. * gcc.dg/tree-prof/update-loopch.c: Check two "Invalid sum" messages for removed basic block. * gcc.dg/tree-ssa/ivopt_1.c: Fix unreliable scanning string. * gcc.dg/tree-ssa/ivopt_2.c: Ditto. * gcc.dg/tree-ssa/ivopt_3.c: Ditto. * gcc.dg/tree-ssa/ivopt_4.c: Ditto.
[Bug sanitizer/79572] [6 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 Jakub Jelinek changed: What|Removed |Added Assignee|mpolacek at gcc dot gnu.org|jakub at gcc dot gnu.org Summary|[6/7 Regression] reference |[6 Regression] reference |binding to null pointer not |binding to null pointer not |reported with |reported with |-fsanitize=undefined|-fsanitize=undefined --- Comment #14 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug bootstrap/79255] [6 Regression] PGO bootstrap fails on x86_64/ppc64le building Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79255 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[6/7 Regression] PGO|[6 Regression] PGO |bootstrap fails on |bootstrap fails on |x86_64/ppc64le building Ada |x86_64/ppc64le building Ada --- Comment #10 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug bootstrap/79255] [6/7 Regression] PGO bootstrap fails on x86_64/ppc64le building Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79255 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Fri Mar 31 18:40:35 2017 New Revision: 246622 URL: https://gcc.gnu.org/viewcvs?rev=246622&root=gcc&view=rev Log: PR debug/79255 * dwarf2out.c (decls_for_scope): If BLOCK_NONLOCALIZED_VAR is a FUNCTION_DECL, pass it as decl instead of origin to process_scope_var. * gcc.dg/pr79255.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr79255.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/79572] [6/7 Regression] reference binding to null pointer not reported with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79572 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Fri Mar 31 18:39:25 2017 New Revision: 246621 URL: https://gcc.gnu.org/viewcvs?rev=246621&root=gcc&view=rev Log: PR c++/79572 * c-ubsan.h (ubsan_maybe_instrument_reference): Change argument to tree *. * c-ubsan.c (ubsan_maybe_instrument_reference): Likewise. Handle not just NOP_EXPR to REFERENCE_TYPE, but also INTEGER_CST with REFERENCE_TYPE. * cp-gimplify.c (cp_genericize_r): Sanitize INTEGER_CSTs with REFERENCE_TYPE. Adjust ubsan_maybe_instrument_reference caller for NOP_EXPR to REFERENCE_TYPE. * g++.dg/ubsan/null-8.C: New test. Added: trunk/gcc/testsuite/g++.dg/ubsan/null-8.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-ubsan.c trunk/gcc/c-family/c-ubsan.h trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug target/80108] ICE in aggregate_value_p at function.c:2028
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80108 --- Comment #9 from kelvin at gcc dot gnu.org --- I've got a patch now that resolves this problem without creating regressions. I'm attaching it for "discussion" here before I post for "official review". Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c (revision 246573) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -4273,8 +4273,30 @@ rs6000_option_override_internal (bool global_init_ /* For the newer switches (vsx, dfp, etc.) set some of the older options, unless the user explicitly used the -mno- to disable the code. */ if (TARGET_P9_VECTOR || TARGET_MODULO || TARGET_P9_DFORM_SCALAR - || TARGET_P9_DFORM_VECTOR || TARGET_P9_DFORM_BOTH > 0 || TARGET_P9_MINMAX) + || TARGET_P9_DFORM_VECTOR || TARGET_P9_DFORM_BOTH > 0) rs6000_isa_flags |= (ISA_3_0_MASKS_SERVER & ~rs6000_isa_flags_explicit); + else if (TARGET_P9_MINMAX) +{ + if (have_cpu) + { + if (cpu_index == PROCESSOR_POWER9) + /* legacy behavior: allow -mcpu-power9 with certain capabilities + (eg -mno-vsx) explicitly disabled. */ + rs6000_isa_flags |= + (ISA_3_0_MASKS_SERVER & ~rs6000_isa_flags_explicit); + else + error ("Power9 target option is incompatible with -mcpu= for " + " less than power9"); + } + else if ((ISA_3_0_MASKS_SERVER & rs6000_isa_flags_explicit) + != (ISA_3_0_MASKS_SERVER & rs6000_isa_flags + & rs6000_isa_flags_explicit)) + /* Enforce that none of the ISA_3_0_MASKS_SERVER flags + were explicitly cleared. */ + error ("-mpower9-minmax incompatible with explicitly disabled options"); + else + rs6000_isa_flags |= ISA_3_0_MASKS_SERVER; +} else if (TARGET_P8_VECTOR || TARGET_DIRECT_MOVE || TARGET_CRYPTO) rs6000_isa_flags |= (ISA_2_7_MASKS_SERVER & ~rs6000_isa_flags_explicit); else if (TARGET_VSX) I'm seeking feedback on whether this is the treatment you are all comfortable with. Note that the way I handle TARGET_P9_MINMAX is very different than the way we handle other p9-specific target options (see the first line replaced by this patch). An earlier draft of my patch handled all six of these options the same way that my patch handles TARGET_P9_MINMAX, but that resulted in 942 fewer "expected passes", 4 more "unexpected failures", and 309 more "unsupported tests" in the gcc summary. It is these inconsistencies that make me a little uncomfortable with how this solution is structured. I welcome feedback and suggestions for further refinement.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574 Jeffrey A. Law changed: What|Removed |Added Blocks||19794 Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #11 from Jeffrey A. Law --- Ultimately this is a missed jump thread. In vrp1 after insertion of ASSERT_EXPRs we have: ;; basic block 2, loop depth 0, count 0, freq 1005, maybe hot ;;prev block 0, next block 11, flags: (NEW, REACHABLE, VISITED) ;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE) if (flag_6(D) == 0) goto ; [33.00%] else goto ; [67.00%] ;;succ: 3 [33.0%] (TRUE_VALUE,EXECUTABLE) ;;11 [67.0%] (FALSE_VALUE,EXECUTABLE) ;; basic block 11, loop depth 0, count 0, freq 673, maybe hot ;;prev block 2, next block 3, flags: (NEW) ;;pred: 2 [67.0%] (FALSE_VALUE,EXECUTABLE) flag_14 = ASSERT_EXPR ; goto ; [100.00%] ;;succ: 4 [100.0%] (FALLTHRU) ;; basic block 3, loop depth 0, count 0, freq 332, maybe hot ;;prev block 11, next block 4, flags: (NEW, REACHABLE, VISITED) ;;pred: 2 [33.0%] (TRUE_VALUE,EXECUTABLE) flag_13 = ASSERT_EXPR ; value_10 = get_value (); ;;succ: 4 [100.0%] (FALLTHRU,EXECUTABLE) ;; basic block 4, loop depth 0, count 0, freq 1005, maybe hot ;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED) ;;pred: 3 [100.0%] (FALLTHRU,EXECUTABLE) ;;11 [100.0%] (FALLTHRU) # value_12 = PHI ;;succ: 5 [100.0%] (FALLTHRU,EXECUTABLE) ;; basic block 5, loop depth 1, count 0, freq 6700, maybe hot ;;prev block 4, next block 8, flags: (NEW, REACHABLE, VISITED) ;;pred: 4 [100.0%] (FALLTHRU,EXECUTABLE) ;;9 [100.0%] (FALLTHRU,DFS_BACK,EXECUTABLE) ;;succ: 8 [100.0%] (FALLTHRU,EXECUTABLE) ;; basic block 8, loop depth 2, count 0, freq 1, maybe hot ;;prev block 5, next block 10, flags: (NEW) ;;pred: 5 [100.0%] (FALLTHRU,EXECUTABLE) ;;10 [100.0%] (FALLTHRU,DFS_BACK,EXECUTABLE) _1 = flag_6(D) == 0; _2 = value_12 != 0; _3 = _1 & _2; if (_3 != 0) goto ; [33.00%] else goto ; [67.00%] The key is to realize that the path 2->11->8 will always then transfer control to 6 (because _3 will always have the value zero). If we were to thread that jump, then the uninitialized use of value_7 would disappear. I've got some code that I think would pick this up, but I haven't installed it because it was developed after stage1 close and does not fix any known regressions. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794 [Bug 19794] [meta-bug] Jump threading related bugs
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 --- Comment #8 from Bill Schmidt --- But hm, build_vector_type calls make_vector_type which canonicalizes using type_hash_canon, so this seems ok. Perhaps the problem is with the V4i type?
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 52078, which changed state. Bug 52078 Summary: Bogus may be used uninitialized warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52078 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/52078] Bogus may be used uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52078 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- If we look at the VRP dump after ASSERT_EXPR insertion it's obvious what needs to happen here: ; basic block 2, loop depth 0, count 0, freq 1, maybe hot ;;prev block 0, next block 7, flags: (NEW, REACHABLE, VISITED) ;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE) if (nname_6(D) != oname_7(D)) goto ; [70.00%] else goto ; [30.00%] ;;succ: 3 [70.0%] (TRUE_VALUE,EXECUTABLE) ;;7 [30.0%] (FALSE_VALUE,EXECUTABLE) ;; basic block 7, loop depth 0, count 0, freq 3000, maybe hot ;;prev block 2, next block 3, flags: (NEW) ;;pred: 2 [30.0%] (FALSE_VALUE,EXECUTABLE) nname_12 = ASSERT_EXPR ; oname_15 = ASSERT_EXPR ; goto ; [100.00%] ;;succ: 4 [100.0%] (FALLTHRU) ;; basic block 3, loop depth 0, count 0, freq 7000, maybe hot ;;prev block 7, next block 4, flags: (NEW, REACHABLE, VISITED) ;;pred: 2 [70.0%] (TRUE_VALUE,EXECUTABLE) nname_11 = ASSERT_EXPR ; oname_14 = ASSERT_EXPR ; _10 = __builtin_strcmp (nname_11, oname_14); oname_16 = ASSERT_EXPR ; nname_13 = ASSERT_EXPR ; ;;succ: 4 [100.0%] (FALLTHRU,EXECUTABLE) ;; basic block 4, loop depth 0, count 0, freq 1, maybe hot ;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED) ;;pred: 3 [100.0%] (FALLTHRU,EXECUTABLE) ;;7 [100.0%] (FALLTHRU) # cmp_4 = PHI <_10(3), cmp_8(D)(7)> _1 = nname_6(D) == oname_7(D); _2 = cmp_4 == 0; _3 = _1 | _2; if (_3 != 0) goto ; [46.00%] else goto ; [54.00%] ;;succ: 6 [46.0%] (TRUE_VALUE,EXECUTABLE) ;;5 [54.0%] (FALSE_VALUE,EXECUTABLE) If we traverse the edge 2->7, then we know that nname == oname (which is shown in the IL via the ASSERT_EXPRs in BB7).We can use that to simplify the computation of _3 in BB4 and ultimately thread 2->7->6 and eliminate the test of cmp_4 on the threaded path (it becomes dead). That eliminates the uninitialized use. This is fixed on the trunk, most likely due to the work for pr71437 which looks to exploit ASSERT_EXPRs more aggressively.
[Bug tree-optimization/80275] New: Poor (but valid) code generated by optimizer passing optimizer list to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80275 Bug ID: 80275 Summary: Poor (but valid) code generated by optimizer passing optimizer list to function Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: cuzdav at gmail dot com Target Milestone: --- Codegen regression from the 5.x series of g++. After 6.1, g++ produces poor code for f2() below, when it should be identical to f1(). Command line: g++ -O2 -v -std=c++14 minbad.cpp // minbad.cpp #include int g() { return 1234; } int f1() { return std::min(std::min(1, g()), 4); } int f2() { return std::min({1, g(), 4}); } The actual disassembly looks like this: g(): mov eax, 1234 ret f1(): mov eax, 1 ret f2(): lea rsi, [rsp-24] lea rax, [rsp-24] mov DWORD PTR [rsp-24], 1 mov DWORD PTR [rsp-20], 1234 mov DWORD PTR [rsp-16], 4 lea rcx, [rsi+12] lea rdx, [rax+4] mov eax, 1 .L4: add rdx, 4 cmp rdx, rcx je .L3 .L8: cmp eax, DWORD PTR [rdx] jle .L4 mov eax, DWORD PTR [rdx] add rdx, 4 cmp rdx, rcx jne .L8 .L3: rep ret Compiler Info (this is not a mac-specific problem.) - g++-6 -v -std=c++14 /tmp/minbad.cpp Using built-in specs. COLLECT_GCC=g++-6 COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/6.3.0_1/libexec/gcc/x86_64-apple-darwin16.3.0/6.3.0/lto-wrapper Target: x86_64-apple-darwin16.3.0 Configured with: ../configure --build=x86_64-apple-darwin16.3.0 --prefix=/usr/local/Cellar/gcc/6.3.0_1 --libdir=/usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6 --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-6 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release --enable-lto --with-build-config=bootstrap-debug --disable-werror --with-pkgversion='Homebrew GCC 6.3.0_1' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --enable-plugin --disable-nls --enable-multilib Thread model: posix gcc version 6.3.0 (Homebrew GCC 6.3.0_1) COLLECT_GCC_OPTIONS='-v' '-std=c++14' '-mmacosx-version-min=10.12.4' '-asm_macosx_version_min=10.12' '-shared-libgcc' '-mtune=core2' /usr/local/Cellar/gcc/6.3.0_1/libexec/gcc/x86_64-apple-darwin16.3.0/6.3.0/cc1plus -quiet -v -D__DYNAMIC__ /tmp/minbad.cpp -fPIC -quiet -dumpbase minbad.cpp -mmacosx-version-min=10.12.4 -mtune=core2 -auxbase minbad -std=c++14 -version -o /var/folders/d_/97dm5hss6cq7y8jlfxh3k6xrsw2_zt/T//cc9vAOcI.s GNU C++14 (Homebrew GCC 6.3.0_1) version 6.3.0 (x86_64-apple-darwin16.3.0) compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6/gcc/x86_64-apple-darwin16.3.0/6.3.0/../../../../../../x86_64-apple-darwin16.3.0/include" #include "..." search starts here: #include <...> search starts here: /usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6/gcc/x86_64-apple-darwin16.3.0/6.3.0/../../../../../../include/c++/6.3.0 /usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6/gcc/x86_64-apple-darwin16.3.0/6.3.0/../../../../../../include/c++/6.3.0/x86_64-apple-darwin16.3.0 /usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6/gcc/x86_64-apple-darwin16.3.0/6.3.0/../../../../../../include/c++/6.3.0/backward /usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6/gcc/x86_64-apple-darwin16.3.0/6.3.0/include /usr/local/include /usr/local/Cellar/gcc/6.3.0_1/include /usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6/gcc/x86_64-apple-darwin16.3.0/6.3.0/include-fixed /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. GNU C++14 (Homebrew GCC 6.3.0_1) version 6.3.0 (x86_64-apple-darwin16.3.0) compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 61c7027fd27bf9cda4c9b1dfc6e5d124 COLLECT_GCC_OPTIONS='-v' '-std=c++14' '-mmacosx-version-min=10.12.4' '-shared-libgcc' '-mtune=core2' as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=10.12 -o /var/folders/d_/97dm5hss6cq7y8jlfxh3k6xrsw2_zt/T//ccipBAqo.o /var/folders/d_/97dm5hss6cq7y8jlfxh3k6xrsw2_zt/T//cc9vAOcI.s Apple LLVM version 8.0.0 (clang-800.0.42.1) Target: x86_64-apple-darwin16.4.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefa
[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905 --- Comment #7 from Bill Schmidt --- In rs6000.c: rs6000_handle_altivec_attribute(), the altivec(vector__) attribute is used to assign V4SI_type_node as the associated type in this case. V4SI_type_node has a canonical type field that points to itself. This type is created in rs6000_init_builtins() as follows: V4SI_type_node = build_vector_type (intSI_type_node, 4); My guess is that we need to call some interface that will look for an existing type and canonicalize to that one, but I don't know how any of this front-endish stuff works. I'll keep looking.
[Bug c++/78850] Parameter of returned generic lambda allegedly shadows parameter of free function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78850 Michael Tsang changed: What|Removed |Added CC||miklcct at gmail dot com --- Comment #1 from Michael Tsang --- I think the following is related to this, where the parameter of a returned lambda is mis-interpreted as shadowing a local variable: [michael@samsung-rv510 ~]$ cat fix.cpp #include using std::cin; using std::cout; struct Factorial { template unsigned long operator()(Function self, unsigned long n) const { return n ? n * self(self, n - 1) : 1; } }; template auto y(Function f) { return [f](auto n) { return f(f, n); }; } int main() { unsigned long n; cin >> n; cout << y(Factorial())(n) << '\n'; return 0; } [michael@samsung-rv510 ~]$ g++ -Wshadow -std=c++14 fix.cpp -o fix fix.cpp: In instantiation of 'y(Function):: [with auto:1 = long unsigned int; Function = Factorial]': fix.cpp:21:29: required from here fix.cpp:13:22: warning: declaration of 'n' shadows a previous local [-Wshadow] return [f](auto n) { ^ fix.cpp:19:19: note: shadowed declaration is here unsigned long n; ^
[Bug c/80274] New: There is an unoptimized direct memory write of 16bit value on x86_64 with O2 and O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80274 Bug ID: 80274 Summary: There is an unoptimized direct memory write of 16bit value on x86_64 with O2 and O3. Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zloten at mail dot ru Target Milestone: --- The next code: void foo() { *(unsigned short*)0x=1; } Compiles to: foo(): mov eax, 1 mov WORD PTR ds:65535, ax ret But must be: foo(): mov WORD PTR ds:65535, 1 ret The bug occurs with any options at optimization levels O2, O3. But this is ok at optimization level O. The bug occurs since 4.8.1 version of GCC. PS: For any other sizes (8bit, 32bit and 64bit) the output is correct: mov BYTE PTR ds:65535, 1 ;unsigned byte mov DWORD PTR ds:65535, 1;unsigned int mov QWORD PTR ds:65535, 1;unsigned long long int
[Bug c++/80273] New: cv-qualified auto with trailing return type incorrectly accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80273 Bug ID: 80273 Summary: cv-qualified auto with trailing return type incorrectly accepted Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- GCC incorrectly accepts auto const meow() -> int; [dcl.fct]/2 says only plain 'auto' is allowed. Possibly related to bug 67012.
[Bug c++/80267] [7 Regression] Compiling aborts when template/auto/lambda occur in some way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80267 --- Comment #4 from Marek Polacek --- Although the problem probably arises in process_outer_var_ref, where with decl_maybe_constant_var_p now returning true for references we take a different path which likely messes things up, but no idea what's going on.
[Bug c++/80272] New: g++ runs out of memory and crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80272 Bug ID: 80272 Summary: g++ runs out of memory and crashes Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bkropki at yahoo dot co.uk Target Milestone: --- Created attachment 41096 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41096&action=edit C++ code which crashes g++ g++ runs out of memory and crashes, when the following simple code is compiled #include const int ARR_SIZE = 0x1; // 64 K struct A { char whatever; A() { whatever = 0; }; // removing constructor removes the problem }; class B { std::array, ARR_SIZE> values; public: B(); }; B::B() : values{} // removing explicit initialisation of values (i.e. removing ": values{}") removes the problem {} int main() { return 0; }
[Bug c++/80177] wrong fixit hint for misspelled static_assert: __cpp_static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80177 --- Comment #2 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01580.html
[Bug target/80107] ICE in final_scan_insn, at final.c:2964
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80107 Pat Haugen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Pat Haugen --- Fixed.
[Bug c++/80267] [7 Regression] Compiling aborts when template/auto/lambda occur in some way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80267 --- Comment #3 from Marek Polacek --- (I'm using the testcase in Comment 1.) a() is a function template, so when we instantiate it, we call tsubst_expr with args = int to all stuff in BIND_EXPR_BODY of the function. We'll end up calling tsubst_copy for VAR_DECL 'c' in the nested lambda. lookup_name tries to find an instatiation of 'c', but the one it finds has a different context ("auto &c = b;" vs "c;" from the outer lambda), so we ignore that and do r = tsubst_decl (t, args, complain); which created a new VAR_DECL, with DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P = 0. The type of this decl is a reference, so if (decl_maybe_constant_var_p (r)) is true so we do tree init = tsubst_init (DECL_INITIAL (t), r, args, complain, in_decl); and init = maybe_constant_init (init); so INIT is "*b". It's not reduced_constant_expression_p so DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P is left unset. Which means that decl_constant_var_p (r) in the assert doesn't hold and we crash. So there's a discrepancy in DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P for the specializations of 'c'. The original one has it (set in cp_finish_decl -- the initializer "b" is potential_constant_expression), but the second one doesn't have it ("*b" isn't reduced_constant_expression_p.
[Bug target/80107] ICE in final_scan_insn, at final.c:2964
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80107 --- Comment #2 from Pat Haugen --- Author: pthaugen Date: Fri Mar 31 15:59:46 2017 New Revision: 246619 URL: https://gcc.gnu.org/viewcvs?rev=246619&root=gcc&view=rev Log: PR target/80107 * config/rs6000/rs6000.md (extendhi2): Add test for TARGET_VSX_SMALL_INTEGER. * gfortran.dg/pr80107.f: New. Added: trunk/gcc/testsuite/gfortran.dg/pr80107.f Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64883 --- Comment #46 from nightstrike --- Test now passes on mingw-w64
[Bug tree-optimization/49498] [5/6/7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning (predicate analysis bugs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 --- Comment #30 from Jeffrey A. Law --- Author: law Date: Fri Mar 31 15:26:18 2017 New Revision: 246618 URL: https://gcc.gnu.org/viewcvs?rev=246618&root=gcc&view=rev Log: PR tree-optimization/49498 * gcc.dg/uninit-pred-8_b.c: Reenable DOM. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/uninit-pred-8_b.c
[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64883 --- Comment #45 from nightstrike --- Testing these now: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/466ef13e8468636e76a80342c6c0ee9e4c17bca3/ https://sourceforge.net/p/mingw-w64/mingw-w64/ci/edd8fa8648ae04a2f63d92498abeccffbfd0ba1f/
[Bug c++/77277] -fdiagnostics-color=always disabled on _WIN32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77277 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The author of that patch should contribute it then, see that https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps There are some minor formatting issues and some other issues (e.g. the arrays should be static const, there is no need to initialize them at runtime, it just wants a "named" string literal), but the most important thing is we can't just take random patches out of other spots without the author contributing them.
[Bug tree-optimization/49498] [5/6/7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning (predicate analysis bugs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 --- Comment #29 from Jeffrey A. Law --- Yes, I checked cris-elf. I've got the patch to reenable DOM for that test in my local tree.
[Bug sanitizer/79993] [5/6/7 Regression] ICE in tree_to_uhwi, at tree.c:7344
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79993 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- So far I have: --- gcc/cp/typeck2.c.jj 2017-03-02 08:08:42.0 +0100 +++ gcc/cp/typeck2.c2017-03-31 15:36:54.366928789 +0200 @@ -739,7 +739,9 @@ split_nonconstant_init (tree dest, tree if (TREE_CODE (init) == TARGET_EXPR) init = TARGET_EXPR_INITIAL (init); - if (TREE_CODE (init) == CONSTRUCTOR) + if (TREE_CODE (init) == CONSTRUCTOR + || (TREE_CODE (init) == STRING_CST + && array_of_runtime_bound_p (TREE_TYPE (dest { init = cp_fully_fold (init); code = push_stmt_list (); @@ -1066,7 +1068,7 @@ digest_init_r (tree type, tree init, boo } } - if (type != TREE_TYPE (init)) + if (type != TREE_TYPE (init) && !array_of_runtime_bound_p (type)) { init = copy_node (init); TREE_TYPE (init) = type; --- gcc/cp/init.c.jj2017-03-21 08:04:13.0 +0100 +++ gcc/cp/init.c 2017-03-31 16:38:18.346535659 +0200 @@ -4199,7 +4199,12 @@ build_vec_init (tree base, tree maxindex else if (from_array) { if (init) - /* OK, we set base2 above. */; + { + /* OK, we set base2 above. */ + if (TREE_CODE (init) == STRING_CST + && array_of_runtime_bound_p (atype)) + empty_list = true; + } else if (CLASS_TYPE_P (type) && ! TYPE_HAS_DEFAULT_CONSTRUCTOR (type)) { and the remaining part is changing build_vec_init, so that it will perform the memcpy (MEM_REF = STRING_CST) followed by the initialization of the rest.
[Bug c/78732] Wrong description for Wendif-labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78732 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Fixed on trunk in r246616.
[Bug c/78732] Wrong description for Wendif-labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78732 --- Comment #2 from David Malcolm --- Author: dmalcolm Date: Fri Mar 31 14:24:27 2017 New Revision: 246616 URL: https://gcc.gnu.org/viewcvs?rev=246616&root=gcc&view=rev Log: Fix description of Wendif-labels (PR documentation/78732) gcc/c-family/ChangeLog: PR documentation/78732 * c.opt (Wendif-labels): Fix description to refer to #else rather than #elif. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt
[Bug middle-end/26461] liveness of thread local references across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461 Tor Myklebust changed: What|Removed |Added CC||tmyklebu at gmail dot com --- Comment #17 from Tor Myklebust --- (In reply to Jakub Jelinek from comment #14) > Even if we have an option that avoids CSE of TLS addresses across function > calls (or attribute for specific function), what would you expect to happen > when user takes address of TLS variables himself: > __thread int a; > void > foo () > { > int *p = &a; > *p = 10; > bar (); // Changes threads > *p += 10; > } > ? The address can be stored anywhere, so the compiler can't do anything > with it. And of course such an option would cause major slowdown of > anything using TLS, not only it would need to stop CSEing TLS addresses > late, but stop treating TLS addresses as constant in all early optimizations > as well. When you take &a, gcc docs specify that you get the address of the running thread's instance of a, which is a reasonable pointer for any thread to use as long as the running thread is alive. So everyone already expects that code like this: __thread int a; void *bar(void *p) { printf("%i %i\n", *(int *)p, a); } int main() { a = 42; pthread_t pth; pthread_create(&pth, bar, &a); pthread_join(pth, 0); } should print "42 0" as p should point to the main thread's instance of a while the reference of a in the third argument to printf in bar should reference the child thread's instance of a, which is zero because TLS is initialised to zero. It seems that your example: __thread int a; void foo() { int *p = &a; *p = 10; bar (); // Changes threads *p += 10; } must twice modify the instance of a in the thread that started running foo, which is different behaviour from: __thread int a; void baz() { int *p = &a; *p = 10; bar (); // Changes threads p = &a; *p += 10; } which must modify the instance of a in the thread that started running baz() once and the instance of a that finishes running baz() once, since bar may change the value at %fs:0 by changing threads. Perhaps there is a more serious problem with this whole idea if signal handlers are permitted to twiddle the running thread.
[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60818 --- Comment #22 from Segher Boessenkool --- The combination that makes it die is: Trying 18, 17 -> 19: Successfully matched this instruction: (set (reg:CC 176) (reg:CC 164)) Where insn 18 is (set (reg:SI 174) (gt:SI (reg:CC 164) (const_int 0 [0]))) and insn 17 is (set (reg:SI 173) (lt:SI (reg:CC 164) (const_int 0 [0]))) and insn 19 is (insn 19 18 22 2 (set (reg:CCUNS 176) (compare:CCUNS (reg:SI 173) (reg:SI 174))) "60818-19.c":4 772 {*cmpsi_unsigned} (expr_list:REG_DEAD (reg:SI 174) (expr_list:REG_DEAD (reg:SI 173) (nil the combined insn should not simply copy the CC (it needs to swap the greater-than and smaller-than results), and it needs to return a CCUNS anyway. Where did this come from...
[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60818 --- Comment #21 from Segher Boessenkool --- You don't even need -Os for this last testcase, only -misel.
[Bug driver/80271] New: Support environment variable CLICOLOR_FORCE to enable -fdiagnostics-color
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80271 Bug ID: 80271 Summary: Support environment variable CLICOLOR_FORCE to enable -fdiagnostics-color Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: jhasse at bixense dot com Target Milestone: --- When piping gcc, colored output gets disabled because isatty returns false. But for many people this is the normal way of running gcc, as most build systems (e. g. ninja or Waf) and build servers (e. g. Drone or Jenkins) pipe it to print its output delayed. In these cases ANSI colors would still work though and therefore many people set -fdiagnostics-color=always (see https://github.com/KDE/extra-cmake-modules/commit/dc525a42ae70a68d67aa49d6453d4b6de4ecb561 for example). It would be nice, if there would be a better way to auto detect that case. An environment variable would be a good choice, as build tools, build servers or IDEs with ANSI escape code support can set it. The name CLICOLOR_FORCE was chosen, because it is already used by some tools and a unified naming for this would be nice. See https://bixense.com/clicolors/ (A flag like -fdiagnostics-color also has the disadvantage that changes trigger a complete rebuild in most build system although the flag doesn't influence the object code output.)
[Bug sanitizer/79993] [5/6/7 Regression] ICE in tree_to_uhwi, at tree.c:7344
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79993 Jakub Jelinek changed: What|Removed |Added CC||nils at os dot inf.tu-dresden.de --- Comment #7 from Jakub Jelinek --- *** Bug 80269 has been marked as a duplicate of this bug. ***
[Bug sanitizer/80269] ICE with compile time constant sized array when using address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80269 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jakub Jelinek --- With -std=c++11 the assumption that this is compile time constant sized array is bogus, std::max is constexpr only in -std=c++14 and later. It doesn't matter if your variable is const, it is still initialized at runtime, so char array[LIM] is a VLA and this ICEs because of the PR79993. *** This bug has been marked as a duplicate of bug 79993 ***
[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #3 from Jakub Jelinek --- Perhaps we then need some helper function partly similar to cxx_eval_array_ref, that would for an object (or address of it?) and some uhwi index attempt to return some byte from the object, and then if the middle-end folding doesn't yield anything, handle these builtins by using that helper in a loop to grab bytes from one or two input strings, then perform the needed action on them as if we have open-coded those routines in trivial C loops. As even constexpr char foo (int x) { char a[] = { 'a', 'b', 'c', 'd', '\0' }; char *b = &a[0]; return ((unsigned char *)b)[x]; } constexpr char a = foo (0); is rejected, I think we can't use the existing routines here though, we want to be able to access bytes of anything initialized.
[Bug c++/77277] -fdiagnostics-color=always disabled on _WIN32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77277 Jan Niklas Hasse changed: What|Removed |Added CC||jhasse at bixense dot com --- Comment #2 from Jan Niklas Hasse --- Maybe this patch can simply be upstreamed? https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gcc/0017-diagnostic-color.patch I've been using GCC on Window with it for a few months and it works fine :)
[Bug middle-end/80270] ICE in extract_bit_field_1 at gcc/expmed.c:1798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80270 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-31 Component|tree-optimization |middle-end Ever confirmed|0 |1 Known to fail||4.8.5, 6.3.1, 7.0.1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug tree-optimization/80218] [6 Regression] tree-call-cdce does not update block frequencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80218 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from rsandifo at gcc dot gnu.org --- Fixed on trunk and GCC 6 branch.
[Bug tree-optimization/80218] [6 Regression] tree-call-cdce does not update block frequencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80218 --- Comment #4 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Fri Mar 31 11:51:32 2017 New Revision: 246614 URL: https://gcc.gnu.org/viewcvs?rev=246614&root=gcc&view=rev Log: PR80218: Call CDCE fails to update the block profile tree-call-cdce.c was updating the edge probabilities and counts but it wasn't updating the corresponding block information. Among other things, this tricked the register allocator into thinking that the libm call was relatively hot and that it wasn't worth assigning call-clobbered registers to values that were live across the call. With correct frequency information, the RA instead keeps x in the first argument register and spills it only around the call. Although the problem has been around for a long time, it became more acute (and would only trigger for the first function in the testcase) after r230488. Until that patch, the code was specific to calls that had no lhs, but that we still had to keep for their effect on errno. After the patch we also used the code for calls with an lhs, provided that the hardware could calculate the lhs directly. gcc/ PR tree-optimization/80218 * tree-call-cdce.c (shrink_wrap_one_built_in_call_with_conds): Update block frequencies and counts. gcc/testsuite/ PR tree-optimization/80218 * gcc.dg/pr80218.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr80218.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-call-cdce.c
[Bug tree-optimization/80270] New: ICE in extract_bit_field_1 at gcc/expmed.c:1798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80270 Bug ID: 80270 Summary: ICE in extract_bit_field_1 at gcc/expmed.c:1798 Product: gcc Version: 4.8.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: aivchenk at gmail dot com Target Milestone: --- > cat struct_hard_reg.c #include typedef int v8 __attribute__((vector_size(8))); struct S1 { v8 s1f; }; struct S2 { struct S1 s2f1; v8 s2f2; }; void fn1() { int __trans_tmp_2, i = 3; register struct S2 b asm("xmm0"); __trans_tmp_2 = b.s2f1.s1f[i]; printf("%d", __trans_tmp_2); } > gcc ./struct_hard_reg.c -O1 ./new_bug.c: In function ‘fn1’: ./new_bug.c:17:3: internal compiler error: Segmentation fault printf("%d", __trans_tmp_2); ^~~ 0xe92cda crash_signal ../../gcc/gcc/toplev.c:337 0xa3284a extract_bit_field_1 ../../gcc/gcc/expmed.c:1798 0xa32e01 extract_bit_field(rtx_def*, unsigned long, unsigned long, int, rtx_def*, machine_mode, machine_mode, bool) ../../gcc/gcc/expmed.c:1932 0xa63501 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:10702 0xa5821f expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:8072 0xa5f27e expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:9775 0xa5821f expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:8072 0x8d448f expand_normal ../../gcc/gcc/expr.h:282 0x8d647d precompute_register_parameters ../../gcc/gcc/calls.c:956
[Bug sanitizer/80269] ICE with compile time constant sized array when using address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80269 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-31 Ever confirmed|0 |1 Known to fail||6.3.1, 7.0.1 --- Comment #1 from Richard Biener --- Confirmed on trunk/branch. Works with c++14 (detail of std::max?).
[Bug middle-end/26461] liveness of thread local references across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461 --- Comment #16 from Richard Biener --- Implementing a switch that assumes that function calls (what about async events??) can switch threads to the effect that the location of TLS variables change would be a challenge. Basically you have to implement sth that prevents assumptions of a variables location inside a function, not only its value. That's currently done nowhere and I don't know how to model such kind of dependency. So I don't think it's easy to model. It might be possible to put in place more strict constraints to avoid the issue, like instructing the compiler that it can't ever take the address of a __tls object. But then array accesses are modeled as &A + index in the language so I can't see how this would work reliably. You'd have to expose __tls'ness by lowering that very early, not only during RTL expansion. That is, place TLS base reg loads and do accesses via them. Then make sure calls clobber that base reg load. So put all TLS data into sth like a static frame where you'd have a global variable pointing to that. I expect this to be not-fun(TM) for performance.
[Bug target/78002] gcc.target/aarch64/stack-checking.c ICEs with -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78002 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #6 from Eric Botcazou --- Created attachment 41095 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41095&action=edit Tentative fix Tested in LP64 mode, needs to be tested in ILP32 mode.
[Bug middle-end/26461] liveness of thread local references across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461 --- Comment #15 from torvald at gcc dot gnu.org --- From a ISO C/C++ conformance perspective, this is not a bug: * Pre-C11/C++11, threading was basically undefined. * Starting with C11 and C++11, "threads of execution" (as they're called in C++11 and more recent, often abbreviated in the standard as "threads") are the lowest level of how execution is modelled. They are defined as single flows of control. Nothing is promised about any resources that may be used to implement threads of execution (e.g., similar to the "execution context" notion mentioned in comment #10). * Thread-specific state is bound to a particular thread of execution (e.g., regarding lifetime). A thread of execution accessing a __thread variable accesses the thread-specific state of this thread of execution in the abstract machine. (Of course, one can still access other threads's thread-specific state through pointers initially provided by those threads.) * Only the standards' mechanisms can create threads of execution. There is nothing in these standards that would break up the concept of a single flow of control (ie, that what "looks" like a single flow of control in a program is actually not always the same thread of execution when executed). (Also note that fork/join parallelism is not a counter-example to this.) That said, I can see that this doesn't match nicely with the fact that we have things like swapcontext elsewhere. Do we have any data on what the performance impact where if the compiler would assume that function calls to functions it cannot analyze could switch the thread of execution. Data for several architectures and different TLS models would be helpful. Coming back to C++, currently I think there is only one Technical Specification (TS) that allows breaking up a single flow of control: .then() in the Concurrency TS (whose specification is certainly not ready for the standard). Maybe the Networking TS has something similar, but I can't remember right now. There are a few proposals that either allow it (Task Blocks, targeting Parallelism TS version 2) or require it for good performance ("stackful" coroutines). The "stackless" coroutines in the upcoming Coroutines TS are not really affected by thread-specific state; it's not the coroutines code that would potentially switch threads, but any runtime that would supply a particular Awaitable implementation that then may switch threads (e.g., if using .then()). The Coroutines does not specify any actual runtime. However, I don't think the existence of some C++ proposals that may switch threads necessarily means that the compiler would have to take this into account when those proposals should become part of the standard. The other way this could play out is that the standard simply makes using thread-specific state undefined for those threads of execution that can use these proposals. Overall, I think it may be useful to experiment with a command line switch or something like that, primarily to assess how big the performance degradation would be caused by having the compiler assume that threads can switch on function calls. (In reply to Jakub Jelinek from comment #14) > Even if we have an option that avoids CSE of TLS addresses across function > calls (or attribute for specific function), what would you expect to happen > when user takes address of TLS variables himself: > __thread int a; > void > foo () > { > int *p = &a; > *p = 10; > bar (); // Changes threads > *p += 10; > } I think that p would point to the initial thread's TLS, even after bar(). The user would be wrong to assume that it still is the initial thread's object "a" after having called bar().
[Bug c++/80267] [7 Regression] Compiling aborts when template/auto/lambda occur in some way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80267 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r242422.
[Bug rtl-optimization/70703] [6/7 regression] Regression in register usage on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70703 --- Comment #10 from Jakub Jelinek --- Created attachment 41094 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41094&action=edit gcc7-pr70703-widen.patch The widening_mult change. We get tiny bit better code with it with the #c0 testcase: - movl$6700417, %ecx - movl%ecx, %eax + movl$6700417, %edx + movl%edx, %eax mull4(%esp) - movl%edx, %ecx - movl%ecx, %eax + movl%edx, %eax but still not ideal. On the other side, we regress on -m64: unsigned long foo (unsigned long x) { return ((__uint128_t) x * 0x663d811234567ULL) >> 64; } - movabsq $1798629511873895, %rax - mulq%rdi + movq%rdi, %rax + movabsq $1798629511873895, %rdx + mulq%rdx Another option is to deal with this at combine time, I see on the unpatched compiler: Failed to match this instruction: (set (reg:SI 95) (subreg:SI (mult:DI (zero_extend:DI (mem/c:SI (reg/f:SI 16 argp) [1 x+0 S4 A32])) (const_int 6700417 [0x663d81])) 4)) Maybe we could add some define_insn_and_split that would deal with this and make sure the constant is forced into a register (if the constant has depending on all upper bits zero or set) and transform it into the highpart insns? Though, I'm worried about the regression above we got with the TImode highpart.
[Bug libstdc++/69853] An inheriting constructor of the class that inherited std::tuple isn't called correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69853 --- Comment #4 from Takatoshi Kondo --- Thank you for the comment. I understand. I use perfect forwarding in this case.
[Bug sanitizer/80269] New: ICE with compile time constant sized array when using address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80269 Bug ID: 80269 Summary: ICE with compile time constant sized array when using address sanitizer Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: nils at os dot inf.tu-dresden.de CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- Created attachment 41093 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41093&action=edit Preprocessed test file I experience an internal compiler error when assigning to an array with constant size, given by an expression, and building with C++11 and address sanitizers. Here is a minimal example: #include #include const int LIM = std::max(10, 12); int main() { char array[LIM] = ""; printf("%s\n", array); return 0; } And compiling with: g++ -std=c++11 -fsanitize=address test.cc The result is: test.cc:10:1: internal compiler error: in tree_to_uhwi, at tree.h:4044 } ^ 0xae594f tree_to_uhwi(tree_node const*) ../../gcc/gcc/tree.h:4044 0xae594f asan_add_global ../../gcc/gcc/asan.c:2269 0xae59b2 add_string_csts(constant_descriptor_tree**, asan_add_string_csts_data*) ../../gcc/gcc/asan.c:2483 0xae5e2a void hash_table::traverse_noresize(asan_add_string_csts_data*) ../../gcc/gcc/hash-table.h:950 0xae5e2a void hash_table::traverse(asan_add_string_csts_data*) ../../gcc/gcc/hash-table.h:972 0xae5e2a asan_finish_file() ../../gcc/gcc/asan.c:2555 My system is: $ uname -a Linux erwin 4.9.5 #1 SMP Mon Jan 23 14:42:51 CET 2017 x86_64 GNU/Linux $ g++ -v Using built-in specs. COLLECT_GCC=/usr/local/gcc/host-x86_64/6/bin/g++ COLLECT_LTO_WRAPPER=/usr/local/gcc/host-x86_64/6/libexec/gcc/x86_64-pc-linux-gnu/6.3.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gcc/host-x86_64/6 --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,fortran,go,java,lto,objc --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 --with-abi=m64 --enable-multilib --with-tune=generic : (reconfigured) ../gcc/configure --prefix=/usr/local/gcc/host-x86_64/6 --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,fortran,go,java,lto,objc --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 --with-abi=m64 --enable-multilib --with-tune=generic Thread model: posix gcc version 6.3.1 20170326 (GCC) I've attached the preprocessor output, just in case.
[Bug rtl-optimization/70703] [6/7 regression] Regression in register usage on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70703 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Vlad, any thoughts on this? I'll try to deal with this in the widening_mul pass too, that pass converts: _1 = (long long unsigned int) x_4(D); - _2 = _1 * 6700417; + _2 = x_4(D) w* 6700417; _3 = _2 >> 32; _5 = (unsigned int) _3; but as the only user cares about the high part of the widened result, we could convert it into: _1 = (long long unsigned int) x_4(D); _2 = _1 * 6700417; _3 = _2 >> 32; - _5 = (unsigned int) _3; + _5 = x_4(D) h* 6700417; There is nothing that would attempt match.pd foldings after this.
[Bug tree-optimization/79224] [7 Regression] Large C-Ray slowdown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224 --- Comment #11 from Richard Biener --- I still see inlining differences (comparing to GCC 6). The profile looks like 33.18% c-ray-f-7 c-ray-f-7 [.] shade 28.18% c-ray-f-6 c-ray-f-6 [.] shade 11.50% c-ray-f-7 c-ray-f-7 [.] ray_sphere 9.32% c-ray-f-6 c-ray-f-6 [.] trace 7.40% c-ray-f-7 c-ray-f-7 [.] render 7.26% c-ray-f-6 c-ray-f-6 [.] render GCC 6: Inlining ray_sphere.constprop to shade with frequency 10 Inlining ray_sphere to trace with frequency 6169 Inlining get_sample_pos to get_primary_ray with frequency 1000 Inlining trace.constprop to render with frequency 10 Inlining ray_sphere to render with frequency 10 Inlining get_msec.part.0 to get_msec with frequency 390 GCC 7: Inlining get_sample_pos to get_primary_ray with frequency 1000 Inlining ray_sphere.constprop to shade with frequency 36274 Inlining trace to shade with frequency 505 Inlining ray_sphere to trace with frequency 3059 Inlining trace.constprop to render with frequency 10 Inlining get_primary_ray to render with frequency 10 Inlining get_sample_pos to render with frequency 10 Inlining ray_sphere to render with frequency 10 so the difference is that with GCC 6 we inline ray_shpere to trace (and that not into shade) while with GCC 7 we inline trace into shade but before inlining ray_sphere into trace. We know that for good performance inlining ray_sphere is critical and for some reason that's still not prioritized on trunk. Of course it's just a benchmark and using -fwhole-program fixes it on trunk (to faster than GCC 6 w/o -fwhole-program, GCC 6 with -fwhole-program actually regresses...).
[Bug middle-end/79989] [7 Regression][CHKP] ICE in assign_temp, at function.c:968
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79989 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79390 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug testsuite/78529] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529 Richard Biener changed: What|Removed |Added Target Milestone|7.0 |--- Summary|[7 Regression] |gcc.c-torture/execute/built |gcc.c-torture/execute/built |ins/strcat-chk.c failed |ins/strcat-chk.c failed |with lto/O2 |with lto/O2 | --- Comment #35 from Richard Biener --- And not really a regression thus. Either INVALID or leave it open as testsuite enhancement.
[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60818 --- Comment #20 from Arseny Solokha --- (In reply to Alan Modra from comment #19) > Yes, r246294 powerpc64le-linux-gcc -O1 -misel ICEs on the last testcase. An > earlier compiler I had laying around, 7.0.0 20160616, does not. Here's a simplified version, then (-misel -Os): int lx (int oi, int mb) { return (oi < mb) < (mb < oi); } Note that this snippet as well as one from comment 17 both have comparison patterns similar to those from snippets in comment 3 and comment 4.
[Bug rtl-optimization/77499] [7/8 Regression] Regression after code-hoisting, due to combine pass failing to evaluate known value range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499 Richard Biener changed: What|Removed |Added Target||arm-none-eabi Target Milestone|7.0 |8.0 Summary|[7 Regression] Regression |[7/8 Regression] Regression |after code-hoisting, due to |after code-hoisting, due to |combine pass failing to |combine pass failing to |evaluate known value range |evaluate known value range --- Comment #15 from Richard Biener --- There's no simple fix here, defering to GCC 8.
[Bug middle-end/63184] [5/6/7/8 Regression] Fails to simplify comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63184 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|5.5 |8.0 Summary|[5/6/7 Regression] Fails to |[5/6/7/8 Regression] Fails |simplify comparison |to simplify comparison
[Bug tree-optimization/71361] [7/8 Regression] Changes in ivopts caused perf regression on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71361 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|7.0 |8.0 Summary|[7 Regression] Changes in |[7/8 Regression] Changes in |ivopts caused perf |ivopts caused perf |regression on x86 |regression on x86
[Bug c++/80267] [7 Regression] Compiling aborts when template/auto/lambda occur in some way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80267 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf --- trippels@gcc75 ~ % cat bug.ii template void a() { int b; auto &c = b; [&] { c; [&] { c; }; }; } void d() { a(); } trippels@gcc75 ~ % g++ -c bug.ii bug.ii: In instantiation of ‘a() [with = int]’: bug.ii:6:7: required from ‘struct a():: [with = int]::’ bug.ii:6:5: required from ‘a():: [with = int]’ bug.ii:4:5: required from ‘struct a() [with = int]::’ bug.ii:4:3: required from ‘void a() [with = int]’ bug.ii:9:19: required from here bug.ii:6:11: internal compiler error: in tsubst_copy, at cp/pt.c:14609
[Bug tree-optimization/49498] [5/6/7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning (predicate analysis bugs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 --- Comment #28 from Richard Biener --- (In reply to Jeffrey A. Law from comment #27) > Must. Read. dg-comments in testcase. More. Carefully. > > > This was actually fixed a couple years ago with some pass ordering changes. > The testsuite hack mentioned in c#12 is no longer needed. Hmm, note the report states it worked on x86_64/i586/arm anyway and only some other archs were broken. Did you verify any of those? Iff it's really fixed we should remove the testcase workaround (enable DOM again). A quick check on avr doesn't reproduce the issue when re-enabling DOM.
[Bug tree-optimization/80248] sparse access to Array of structures does not vectorize using gathers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80248 --- Comment #2 from vincenzo Innocente --- side note: the difference is timing between "aos2" and "soa" seems to be fully accounted by the integer multiplication "3*k[i]".
[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #2 from Richard Biener --- I think you need to handle some of the builtin folding in the C++ FE.
[Bug c++/80267] [7 Regression] Compiling aborts when template/auto/lambda occur in some way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80267 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |7.0
[Bug target/80266] ICE in store_pairsi condition with -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80266 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|7.0 |---