[Bug middle-end/71473] [5/6/7 Regression] cilkplus sum reducer ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473 Jeffrey A. Law changed: What|Removed |Added Priority|P2 |P4 CC||law at redhat dot com --- Comment #10 from Jeffrey A. Law --- Cilk is likely to be deprecated. It certainly isn't a P1/P2 bug.
[Bug tree-optimization/79090] [7 regression] DSE wrongly removes store at variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79090 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jeffrey A. Law --- Fixed on the trunk.
[Bug tree-optimization/79090] [7 regression] DSE wrongly removes store at variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79090 --- Comment #3 from Jeffrey A. Law --- Author: law Date: Sun Jan 15 09:34:01 2017 New Revision: 244472 URL: https://gcc.gnu.org/viewcvs?rev=244472&root=gcc&view=rev Log: PR tree-optimization/79090 * tree-ssa-dse.c (valid_ao_ref_for_dse): Reject zero length and variable length stores. (compute_trims): Delete dead assignment to *trim_tail. (dse_dom_walker::dse_optimize_stmt): Optimize mem* calls with zero length. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-dse.c
[Bug c/47931] missing -Waddress warning for comparison with NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47931 --- Comment #9 from Christophe Lyon --- Indeed, I can now see it was fixed between r244372 and r244391, sorry for the noise (there was a delay in my validations).
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 --- Comment #1 from Nadav Har'El --- Technically speaking, std::atomic's default constructor is not marked "constexpr" (unlike the value-taking constructor), so I'm guessing that at the time that gcc makes the decision to have these guards, it doesn't yet know that this type will not need a constructor. I don't know why the standard decided that the default constructor should not be marked "constexpr", unlike the value-taking constructors.
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 --- Comment #2 from Jonathan Wakely --- (In reply to Nadav Har'El from comment #1) > I don't know why the standard decided that the default constructor should > not be marked "constexpr", unlike the value-taking constructors. Because the standard requires that the default constructor doesn't initialize the value, for compatibility with "atomic_int i;" in C which leaves it uninitialized. A constexpr constructor must not leave data uninitialized, so they can't be constexpr if they're C-compatible.
[Bug c++/79092] template: type ignored if value already instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79092 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-15 Ever confirmed|0 |1
[Bug libstdc++/78389] list::merge and list::sort are not exception safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78389 --- Comment #3 from ville at gcc dot gnu.org --- Author: ville Date: Sun Jan 15 16:11:46 2017 New Revision: 244474 URL: https://gcc.gnu.org/viewcvs?rev=244474&root=gcc&view=rev Log: Backport from mainline 2017-01-13 Ville Voutilainen PR libstdc++/78389 * include/bits/list.tcc (merge(list&&)): Adjust list sizes if the comparator throws. (merge(list&&, _StrictWeakOrdering)): Likewise. * testsuite/23_containers/list/operations/78389.cc: New. Added: branches/gcc-6-branch/libstdc++-v3/testsuite/23_containers/list/operations/78389.cc Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/include/bits/list.tcc
[Bug libstdc++/78389] list::merge and list::sort are not exception safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78389 --- Comment #4 from ville at gcc dot gnu.org --- Author: ville Date: Sun Jan 15 16:27:08 2017 New Revision: 244475 URL: https://gcc.gnu.org/viewcvs?rev=244475&root=gcc&view=rev Log: Backport from mainline 2017-01-13 Ville Voutilainen PR libstdc++/78389 * include/bits/list.tcc (merge(list&&)): Adjust list sizes if the comparator throws. (merge(list&&, _StrictWeakOrdering)): Likewise. * testsuite/23_containers/list/operations/78389.cc: New. Added: branches/gcc-5-branch/libstdc++-v3/testsuite/23_containers/list/operations/78389.cc Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/include/bits/list.tcc
[Bug libstdc++/78389] list::merge and list::sort are not exception safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78389 --- Comment #5 from Ville Voutilainen --- Fixed merge() on all active branches.
[Bug rtl-optimization/78751] [7 Regression] ICE in extract_insn, at recog.c:2311 (error: unrecognizable insn) w/ -Os -misel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78751 --- Comment #6 from Segher Boessenkool --- Author: segher Date: Sun Jan 15 17:03:55 2017 New Revision: 244476 URL: https://gcc.gnu.org/viewcvs?rev=244476&root=gcc&view=rev Log: ifcvt: Don't make invalid insns for a cond trap (PR78751) As shown in the PR, ifcvt will happily make invalid insns when given the chance. This patch teaches it some manners. PR rtl-optimization/78751 * ifcvt.c (find_cond_trap): If we generated a non-existing insn, give up. Modified: trunk/gcc/ChangeLog trunk/gcc/ifcvt.c
[Bug target/72749] [7 Regression] ICE: verify_flow_info failed (error: wrong amount of branch edges after conditional jump in bb 5) w/ -O2 -fsched2-use-superblocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72749 --- Comment #14 from Segher Boessenkool --- Author: segher Date: Sun Jan 15 17:06:00 2017 New Revision: 244477 URL: https://gcc.gnu.org/viewcvs?rev=244477&root=gcc&view=rev Log: Make rtl_split_edge work for jumps that fall through (PR72749) If a jump always falls through but that cannot be optimised away, like is the case with the PowerPC bdnz insn if its jump target is the same as the fallthrough, sched gets confused if it schedules some instructions from before that jump instruction to behind it: it splits the fallthrough branch, but the jump target isn't updated, and things fall apart as in the PR. This patch fixes it. The second patch fragment makes -fsched-verbose=N work for N>=4; the currently scheduled fragment can now contain a label. Everything else seems to work fine with that. PR target/72749 * cfgrtl.c (rtl_split_edge): Also patch jump insns that jump to the fallthrough. * haifa-sched.c (dump_insn_stream): Don't crash if there is a label in the currently scheduled RTL fragment. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgrtl.c trunk/gcc/haifa-sched.c
[Bug target/72749] [7 Regression] ICE: verify_flow_info failed (error: wrong amount of branch edges after conditional jump in bb 5) w/ -O2 -fsched2-use-superblocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72749 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Segher Boessenkool --- Fixed on trunk, doesn't seem to happen on 6, closing as fixed.
[Bug rtl-optimization/78751] [7 Regression] ICE in extract_insn, at recog.c:2311 (error: unrecognizable insn) w/ -Os -misel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78751 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Segher Boessenkool --- Fixed on trunk. No backport planned.
[Bug c++/79094] New: Pack explansion in using-declaration rejects an attempt to inherit a pack of constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79094
Bug ID: 79094
Summary: Pack explansion in using-declaration rejects an
attempt to inherit a pack of constructors
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Target Milestone: ---
template struct X : Args...
{
using Args::Args...;
};
int main()
{
struct A {A() = default; A(int) {}};
struct B {B() = default; B(double) {}};
X x1{42};
X x2{666.0};
}
Clang accepts the code. GCC rejects it:
prog.cc:3:21: error: parameter packs not expanded with '...':
using Args::Args...;
^~~
prog.cc:3:21: note: 'Args'
prog.cc: In function 'int main()':
prog.cc:10:18: warning: missing initializer for member 'X::' [-Wmissing-field-initializers]
X x1{42};
^
prog.cc:11:21: warning: missing initializer for member 'X::' [-Wmissing-field-initializers]
X x2{666.0};
^
[Bug c++/79095] New: [7 regression] spurious stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095
Bug ID: 79095
Summary: [7 regression] spurious stringop-overflow warning
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s...@li-snyder.org
Target Milestone: ---
hi -
gcc version 7.0.0 20170111 gives what appears to be a spurious warning
for this example when compiling with -O3 (tested on x86_64-pc-linux-gnu):
#include
void foo(std::vector &v);
void vtest()
{
std::vector v;
foo (v);
//if (v.size() > 0)
{
v.resize (v.size()-1);
}
}
$ gcc -c -O3 x.cc
In function ‘void vtest()’:
cc1plus: warning: ‘void* __builtin_memset(void*, int, long unsigned int)’:
specified size 18446744073709551612 exceeds maximum object size
9223372036854775807 [-Wstringop-overflow=]
cc1plus: warning: ‘void* __builtin_memset(void*, int, long unsigned int)’:
specified size 18446744073709551612 exceeds maximum object size
9223372036854775807 [-Wstringop-overflow=]
cc1plus: warning: ‘void* __builtin_memset(void*, int, long unsigned int)’:
specified size 18446744073709551612 exceeds maximum object size
9223372036854775807 [-Wstringop-overflow=]
The size reported is -4 as an unsigned, so the warning must be coming from
considering the possibility that v.size() is 0. But we really shouldn't
be warning unless it can be shown that foo() can leave the vector empty,
and in any case adding the explicit test on the vector size (shown commented
out) does not get rid of the warning.
[Bug fortran/68887] [6 regression] gfortran.dg/coarray/event_[12].f90 -fcoarray=lib -O2 -lcaf_single -latomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68887 Eric Botcazou changed: What|Removed |Added Summary|[6/7 regression]|[6 regression] |gfortran.dg/coarray/event_[ |gfortran.dg/coarray/event_[ |12].f90 -fcoarray=lib -O2 |12].f90 -fcoarray=lib -O2 |-lcaf_single -latomic fails |-lcaf_single -latomic fails --- Comment #13 from Eric Botcazou --- > The tests compiled with an instrumented revision r28 now succeeds. Could > you please test SPARC after revision r244407? Yes, the failures are gone on the mainline.
[Bug sanitizer/79096] New: address sanitizer and jni does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79096 Bug ID: 79096 Summary: address sanitizer and jni does not work Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: physiker at toast2 dot net 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 40521 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40521&action=edit example code address sanitizer and jni does not work I utilize the address sanitizer to detect errors in shared libraries. When I try to interface a shared library with java via jni the address sanitizer does no longer work. This has been working with gcc versions 5, 6 and earlier versions of gcc 7. While running the file make.sh (included in the attachment) the error message is: ==2099==ERROR: Interceptors are not working. This may be because AddressSanitizer is loaded too late (e.g. via dlopen). Please launch the executable with: DYLD_INSERT_LIBRARIES=/usr/local/lib/libasan.4.dylib "interceptors not installed" && 0./make.sh: line 7: 2099 Abort trap: 6 DYLD_INSERT_LIBRARIES=/usr/local/lib/libasan.4.dylib java Tasan Setting DYLD_INSERT_LIBRARIES as suggested (see the file make.sh) does not make a difference. gcc-7 -v Es werden eingebaute Spezifikationen verwendet. COLLECT_GCC=gcc-7 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/lto-wrapper Ziel: x86_64-apple-darwin15.6.0 Konfiguriert mit: ../gcc/configure --enable-languages=c,c++,fortran,lto --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib --program-suffix=-7 Thread-Modell: posix gcc-Version 7.0.0 20170114 (experimental) [trunk revision 244467] (GCC) java -version java version "1.8.0_112" Java(TM) SE Runtime Environment (build 1.8.0_112-b16) Java HotSpot(TM) 64-Bit Server VM (build 25.112-b16, mixed mode)
[Bug fortran/79097] New: coarray and pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79097 Bug ID: 79097 Summary: coarray and pointer component Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: physiker at toast2 dot net Target Milestone: --- Created attachment 40522 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40522&action=edit source code When the code coptr.f90 is compiled by a current version of gfortran and a current version of opencoarrays is utilized the resulting binary prints the output: cafrun -n 2 ./coptr 243769896 2 I expect the output: 1 2 caf -o coptr coptr.f90 -g -W -Wall LANG=C gfortran-7 --version GNU Fortran (GCC) 7.0.0 20170114 (experimental) [trunk revision 244467] Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. caf -v OpenCoarrays Coarray Fortran Compiler Wrapper (caf version 1.8.3) Copyright (C) 2015-2016 Sourcery, Inc. OpenCoarrays comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of OpenCoarrays under the terms of the BSD 3-Clause License. For more information about these matters, see the file named LICENSE.
[Bug bootstrap/79098] New: [7 Regression] Failure to bootstrap gcc for powerpc-e500v2-linux-gnuspe target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79098 Bug ID: 79098 Summary: [7 Regression] Failure to bootstrap gcc for powerpc-e500v2-linux-gnuspe target Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: powerpc-e500v2-linux-gnuspe When building gcc-7.0.0-20170115 snapshot for powerpc-e500v2-linux-gnuspe I now get the following: x86_64-pc-linux-gnu-g++ -fno-PIE -c -O2 -pipe -g -fPIC -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc -I/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/. -I/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/../include -I/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/../libcpp/include -I/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/../libdecnumber -I/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/../libdecnumber/dpd -I../libdecnumber -I/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/../libbacktrace -o rs6000.o -MT rs6000.o -MMD -MP -MF ./.deps/rs6000.TPo /var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/config/rs6000/rs6000.c /var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/config/rs6000/rs6000.c: In function bool rs6000_legitimate_combined_insn(rtx_insn*)': /var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/config/rs6000/rs6000.c:9115:5: error: duplicate case value case CODE_FOR_ctrdi_internal2: ^ /var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/config/rs6000/rs6000.c:9113:5: error: previously used here case CODE_FOR_ctrdi_internal1: ^ /var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/config/rs6000/rs6000.c:9117:5: error: duplicate case value case CODE_FOR_ctrdi_internal3: ^ /var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/config/rs6000/rs6000.c:9113:5: error: previously used here case CODE_FOR_ctrdi_internal1: ^ /var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/config/rs6000/rs6000.c:9119:5: error: duplicate case value case CODE_FOR_ctrdi_internal4: ^ /var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20170115/work/gcc-7-20170115/gcc/config/rs6000/rs6000.c:9113:5: error: previously used here case CODE_FOR_ctrdi_internal1: ^ make[2]: *** [Makefile:: rs6000.o] Error 1 It is likely caused by r244465. gcc for powerpc-e300c3-linux-gnu builds fine, though.
[Bug demangler/79099] New: Memory leak in cplus-dem.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79099 Bug ID: 79099 Summary: Memory leak in cplus-dem.c:2232 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: ppluzhnikov at google dot com Target Milestone: --- Discovered with LLVM libFuzzer (http://llvm.org/docs/LibFuzzer.html). Using current binutils trunk (libiberty is identical to r244484): valgrind --leak-check=full build/binutils/cxxfilt __ELztype_31__tp__H1f_H1f0U_F0U_Fv__F__ELztype_31__tp__H1f0U_FS (signed) __ELztype_31__tp__H1f_H1f0U_F0U_Fv__F__ELztype_31__tp<0>(void) ==24094== HEAP SUMMARY: ==24094== in use at exit: 9 bytes in 2 blocks ==24094== total heap usage: 33 allocs, 31 frees, 888 bytes allocated ==24094== ==24094== 9 (8 direct, 1 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 2 ==24094==at 0x40307C4: malloc (valgrind/coregrind/m_replacemalloc/vg_replace_malloc.c:270) ==24094==by 0x7D1157: xmalloc (/build/libiberty/../../libiberty/xmalloc.c:147) ==24094==by 0x7BD245: demangle_template (/build/libiberty/../../libiberty/cplus-dem.c:2232) ==24094==by 0x7C05E5: demangle_signature (/build/libiberty/../../libiberty/cplus-dem.c:1695) ==24094==by 0x7C0994: iterate_demangle_function (/build/libiberty/../../libiberty/cplus-dem.c:2747) ==24094==by 0x7C1598: internal_cplus_demangle (/build/libiberty/../../libiberty/cplus-dem.c:2975) ==24094==by 0x7BC491: cplus_demangle (/build/libiberty/../../libiberty/cplus-dem.c:922) ==24094==by 0x405643: demangle_it (/build/binutils/../../binutils/cxxfilt.c:62) ==24094==by 0x40525B: main (/build/binutils/../../binutils/cxxfilt.c:227) ==24094== ==24094== LEAK SUMMARY: ==24094==definitely lost: 8 bytes in 1 blocks ==24094==indirectly lost: 1 bytes in 1 blocks ==24094== possibly lost: 0 bytes in 0 blocks ==24094==still reachable: 0 bytes in 0 blocks ==24094== suppressed: 0 bytes in 0 blocks The same leak was definitely present as early as 2016/10/09. The version of binutils imported from head on 2016/06/09 does not appear to have this leak.
[Bug other/16996] [meta-bug] code size improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16996 Bug 16996 depends on bug 33315, which changed state. Bug 33315 Summary: stores not commoned by sinking https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315 What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |---
[Bug tree-optimization/33315] stores not commoned by sinking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315 Richard Biener changed: What|Removed |Added Status|RESOLVED|NEW Blocks||16996 Resolution|FIXED |--- --- Comment #9 from Richard Biener --- There are still two stores to a[0] and two to a[1]. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16996 [Bug 16996] [meta-bug] code size improvements
[Bug rtl-optimization/11832] Optimization of common stores in switch statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11832 Bug 11832 depends on bug 33315, which changed state. Bug 33315 Summary: stores not commoned by sinking https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315 What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |---
[Bug tree-optimization/33315] stores not commoned by sinking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #10 from Richard Biener ---
I've posted a patch for this in July (but it had fallout, as expected...). IL
after that fix:
test ()
{
int i;
[100.00%]:
i_8 = num;
MEM[(int *)&a] = 0;
MEM[(int *)&a + 4B] = 0;
MEM[(int *)&a + 8B] = 0;
return;
}
[Bug middle-end/63184] [5/6/7 Regression] Fails to simplify comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63184 Richard Biener changed: What|Removed |Added Keywords||TREE --- Comment #9 from Richard Biener --- Keep it open, it still is an issue in VN that I'd like to address.
[Bug bootstrap/79098] [7 Regression] Failure to bootstrap gcc for powerpc-e500v2-linux-gnuspe target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79098 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug sanitizer/79096] [7 Regression] address sanitizer and jni does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79096 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0 Summary|address sanitizer and jni |[7 Regression] address |does not work |sanitizer and jni does not ||work
[Bug c++/79095] [7 regression] spurious stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095 Richard Biener changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |7.0
[Bug translation/79093] Hard coded plural in builtins.c:3203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79093 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-16 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Thus confirmed.
[Bug c++/79091] [7 regression] ICE in write_unnamed_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79091 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-16 Known to work||6.2.0 Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug middle-end/79089] [7 Regression] error: incorrect sharing of tree nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79089 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Component|c |middle-end
[Bug tree-optimization/79088] [7 Regression] wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79088
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Version|unknown |7.0
--- Comment #2 from Richard Biener ---
So that's exactly the case I was questioning on the ML -- we have a path
crossing two loop headers but we only reset the niter info on the outer one.
IMHO resetting that on the inner is enough (at least for this testcase).
Note that we stop at the first crossed header because of the irredicible check
(the thread source is in an irreducible region which contains a loop nest of
depth 3).
Index: gcc/tree-ssa-threadupdate.c
===
--- gcc/tree-ssa-threadupdate.c (revision 244484)
+++ gcc/tree-ssa-threadupdate.c (working copy)
@@ -2110,7 +2110,8 @@ mark_threaded_blocks (bitmap threaded_bl
!= (dest->flags & BB_IRREDUCIBLE_LOOP));
if (crossed_headers > 1)
{
- vect_free_loop_info_assumptions (dest->loop_father);
+ vect_free_loop_info_assumptions
+ ((*path)[path->length () - 1]->e->dest->loop_father);
break;
}
}
fixes the testcase. Jeff?
