[Bug tree-optimization/79088] [7 Regression] wrong code at -O2 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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?

[Bug middle-end/79089] [7 Regression] error: incorrect sharing of tree nodes

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79089

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
  Component|c   |middle-end

[Bug c++/79091] [7 regression] ICE in write_unnamed_type

[rguenth at gcc dot gnu.org]

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 translation/79093] Hard coded plural in builtins.c:3203

[rguenth at gcc dot gnu.org]

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++/79095] [7 regression] spurious stringop-overflow warning

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |7.0

[Bug sanitizer/79096] [7 Regression] address sanitizer and jni does not work

[rguenth at gcc dot gnu.org]

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 bootstrap/79098] [7 Regression] Failure to bootstrap gcc for powerpc-e500v2-linux-gnuspe target

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79098

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug middle-end/63184] [5/6/7 Regression] Fails to simplify comparison

[rguenth at gcc dot gnu.org]

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 tree-optimization/33315] stores not commoned by sinking

[rguenth at gcc dot gnu.org]

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 *)] = 0;
  MEM[(int *) + 4B] = 0;
  MEM[(int *) + 8B] = 0;
  return;

}

[Bug rtl-optimization/11832] Optimization of common stores in switch statements

[rguenth at gcc dot gnu.org]

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 other/16996] [meta-bug] code size improvements

[rguenth at gcc dot gnu.org]

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

[rguenth at gcc dot gnu.org]

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 demangler/79099] New: Memory leak in cplus-dem.c:2232

[ppluzhnikov at google dot com]

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 bootstrap/79098] New: [7 Regression] Failure to bootstrap gcc for powerpc-e500v2-linux-gnuspe target

[asolokha at gmx dot com]

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 fortran/79097] New: coarray and pointer component

[physiker at toast2 dot net]

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=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 sanitizer/79096] New: address sanitizer and jni does not work

[physiker at toast2 dot net]

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=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/68887] [6 regression] gfortran.dg/coarray/event_[12].f90 -fcoarray=lib -O2 -lcaf_single -latomic fails

[ebotcazou at gcc dot gnu.org]

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 c++/79095] New: [7 regression] spurious stringop-overflow warning

[s...@li-snyder.org]

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 );

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 c++/79094] New: Pack explansion in using-declaration rejects an attempt to inherit a pack of constructors

[ville.voutilainen at gmail dot com]

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 rtl-optimization/78751] [7 Regression] ICE in extract_insn, at recog.c:2311 (error: unrecognizable insn) w/ -Os -misel

[segher at gcc dot gnu.org]

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 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

[segher at gcc dot gnu.org]

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 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

[segher at gcc dot gnu.org]

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=gcc=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 rtl-optimization/78751] [7 Regression] ICE in extract_insn, at recog.c:2311 (error: unrecognizable insn) w/ -Os -misel

[segher at gcc dot gnu.org]

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=gcc=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 libstdc++/78389] list::merge and list::sort are not exception safe

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78389

--- Comment #5 from Ville Voutilainen  ---
Fixed merge() on all active branches.

[Bug libstdc++/78389] list::merge and list::sort are not exception safe

[ville at gcc dot gnu.org]

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=gcc=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

[ville at gcc dot gnu.org]

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=gcc=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 c++/79092] template: type ignored if value already instantiated

[redi at gcc dot gnu.org]

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 c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor

[redi at gcc dot gnu.org]

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++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor

[nyh at math dot technion.ac.il]

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/47931] missing -Waddress warning for comparison with NULL

[clyon at gcc dot gnu.org]

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 tree-optimization/79090] [7 regression] DSE wrongly removes store at variable offset

[law at gcc dot gnu.org]

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=gcc=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 tree-optimization/79090] [7 regression] DSE wrongly removes store at variable offset

[law at redhat dot com]

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 middle-end/71473] [5/6/7 Regression] cilkplus sum reducer ICE

[law at redhat dot com]

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.