[Bug rtl-optimization/21182] [5/6/7 Regression] gcc can use registers but uses stack instead

[law at redhat dot com]

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

--- Comment #24 from Jeffrey A. Law  ---
Do we happen to have easy access to the pressure at the various program points?
 Dumping that with the points might prove fruitful in both the search for
potential over-aggressive optimizations and to guide Bernd's work to schedule
statements better at the gimple/rtl boundary.

[Bug libstdc++/61582] C++11 regex memory corruption

[timshen at gcc dot gnu.org]

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

--- Comment #21 from Tim Shen  ---
(In reply to Pádraig Brady from comment #20)
> Any status update on this. GCC7 is looming...
> Thanks.

Unfortunately I haven't get a chance to work on this. I plan to put up a
one-line tweak on the internal state limit to make the library throwing an
exception, instead of crash. That's probably a strict improvement.

[Bug libstdc++/61582] C++11 regex memory corruption

[P at draigBrady dot com]

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

Pádraig Brady  changed:

   What|Removed |Added

 CC||P at draigBrady dot com

--- Comment #20 from Pádraig Brady  ---
Any status update on this. GCC7 is looming...
Thanks.

[Bug target/79462] sh: Stack smashing detected when building __ashrdi3 in libgcc

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
Here's the configuration command for hosting on ppc64le:

CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mcpu=power8 -mtune=power8' \
CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mcpu=power8 -mtune=power8 ' \
CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \
AR_FOR_TARGET=/usr/bin/sh-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/sh-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/sh-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/sh-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/sh-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/sh-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/sh-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/sh-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/sh-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/sh-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/sh-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
configure --bindir=/usr/bin --build=ppc64le-redhat-linux-gnu
--datadir=/usr/share --disable-decimal-float --disable-dependency-tracking
--disable-gold --disable-libgcj --disable-libgomp --disable-libmpx
--disable-libquadmath --disable-libssp --disable-libunwind-exceptions
--disable-shared --disable-silent-rules --disable-sjlj-exceptions
--disable-threads --with-ld=/usr/bin/sh-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-unique-object --enable-initfini-array
--enable-languages=c,c++ --enable-linker-build-id --enable-lto --enable-nls
--enable-obsolete --enable-plugin --enable-secureplt --enable-targets=all
--exec-prefix=/usr --host=ppc64le-redhat-linux-gnu --includedir=/usr/include
--infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var
--mandir=/usr/share/man --prefix=/usr --program-prefix=sh-linux-gnu-
--sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc
--target=sh-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-gcc-major-version-only --with-isl --with-newlib
--with-plugin-ld=/usr/bin/sh-linux-gnu-ld
--with-sysroot=/usr/sh-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers
--with-multilib-list=m1,m2,m2e,m2a,m2a-single,m4,m4-single,m4-single-only,m4-nofpu
--with-linker-hash-style=gnu

Other arches would be similar.

The gcc-7 version in question would be:

%global DATE 20170209
%global SVNREV 245310

The binutils in 2.27 cross-compiled for sh.

[Bug sanitizer/79341] Many Asan tests fail on s390

[jakub at gcc dot gnu.org]

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

--- Comment #44 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb 10 23:34:49 2017
New Revision: 245350

URL: https://gcc.gnu.org/viewcvs?rev=245350=gcc=rev
Log:
PR sanitizer/79341
* configure.tgt (s390*-*-linux*): Don't disable libsanitizer on
s390-linux 31-bit.
* sanitizer_common/sanitizer_internal_defs.h: Cherry-pick upstream
r294793.
* sanitizer_common/sanitizer_common_interceptors.inc: Cherry-pick
upstream r294790.
* sanitizer_common/sanitizer_linux_s390.cc: Cherry-pick upstream
r294799.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/configure.tgt
trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc
trunk/libsanitizer/sanitizer_common/sanitizer_internal_defs.h
trunk/libsanitizer/sanitizer_common/sanitizer_linux_s390.cc

[Bug target/79462] New: sh: Stack smashing detected when building __ashrdi3 in libgcc

[dhowells at redhat dot com]

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

Bug ID: 79462
   Summary: sh: Stack smashing detected when building __ashrdi3 in
libgcc
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Stack smashing is detected on some host arches (i686, ppc64, for example, but
not x86_64) when building libgcc for an sh-target cross compiler:

/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/xgcc
-B/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/
-B/usr/sh-linux-gnu/bin/ -B/usr/sh-linux-gnu/lib/ -isystem
/usr/sh-linux-gnu/include -isystem /usr/sh-linux-gnu/sys-include-g -O2
-Wall -fexceptions -m2 -O2  -g -O2 -Wall -fexceptions -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fpic -DNO_FPSCR_VALUES -w -Wno-sync-nand -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -fpic -DNO_FPSCR_VALUES
-w -Wno-sync-nand -I. -I. -I../../.././gcc
-I../../../../gcc-7.0.1-20170209/libgcc
-I../../../../gcc-7.0.1-20170209/libgcc/.
-I../../../../gcc-7.0.1-20170209/libgcc/../gcc
-I../../../../gcc-7.0.1-20170209/libgcc/../include  -DHAVE_CC_TLS  -o
_ashrdi3.o -MT _ashrdi3.o -MD -MP -MF _ashrdi3.dep -DL_ashrdi3 -c
../../../../gcc-7.0.1-20170209/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
*** stack smashing detected ***:
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1 terminated
=== Backtrace: =
/lib64/libc.so.6(+0x969b8)[0x3fff947069b8]
/lib64/libc.so.6(__fortify_fail+0x54)[0x3fff947d2fc4]
/lib64/libc.so.6(__stack_chk_fail+0x20)[0x3fff947d2f60]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z14gen_cbranchdi4P7rtx_defS0_S0_S0_+0xd4)[0x10b904c4]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z23emit_cmp_and_jump_insnsP7rtx_defS0_8rtx_codeS0_12machine_modeiS0_i+0x170)[0x105e4b70]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z23do_compare_rtx_and_jumpP7rtx_defS0_8rtx_codei12machine_modeS0_P14rtx_code_labelS4_i+0x214)[0x102ff1a4]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x105ed30c]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z12expand_binop12machine_mode9optab_tagP7rtx_defS2_S2_i13optab_methods+0x1d54)[0x105ec814]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z12expand_binop12machine_mode9optab_tagP7rtx_defS2_S2_i13optab_methods+0x5b8)[0x105eb078]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x1039e220]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z18expand_expr_real_2P12separate_opsP7rtx_def12machine_mode15expand_modifier+0x3aa8)[0x103ca268]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z18expand_expr_real_1P9tree_nodeP7rtx_def12machine_mode15expand_modifierPS2_b+0x2f54)[0x103b6d14]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x103c5f7c]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z17expand_assignmentP9tree_nodeS0_b+0x5b8)[0x103c2e68]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x102743e0]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x10276178]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x1027ca08]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z16execute_one_passP8opt_pass+0x334)[0x10611e54]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x10612e04]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z17execute_pass_listP8functionP8opt_pass+0x38)[0x10612ea8]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_ZN11cgraph_node6expandEv+0x170)[0x102b85d0]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x102ba0e4]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_ZN12symbol_table25finalize_compilation_unitEv+0x1ec)[0x102bc61c]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x1071e04c]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_ZN6toplev4mainEiPPc+0xfcc)[0x101199ec]
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(main+0x54)[0x1011bb34]
/lib64/libc.so.6(+0x22b20)[0x3fff94692b20]
/lib64/libc.so.6(__libc_start_main+0xb8)[0x3fff94692d18]
=== Memory map: 
1000-1110 r-xp  fc:05 9181442   
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/gcc/cc1
1110-1113 r--p 010f fc:05 9181442   
/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/gcc/cc1
1113-1114 rw-p 0112 fc:05 9181442   

[Bug target/79404] [7 Regression] h8300: ICE at gcc/ira.c:5541 whilst building libgcc

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Target Milestone|--- |7.0
Summary|h8300: ICE at   |[7 Regression] h8300: ICE
   |gcc/ira.c:5541 whilst   |at gcc/ira.c:5541 whilst
   |building libgcc |building libgcc

[Bug target/79451] [7 Regression] ICE in expand_expr_real_2, at expr.c:9021 w/ -O3 -floop-nest-optimize

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com

[Bug c++/79461] New: [C++1z] ICE when capturing a variable in a lambda in a constexpr constructor

[hafnermorris at gmail dot com]

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

Bug ID: 79461
   Summary: [C++1z] ICE when capturing a variable in a lambda in a
constexpr constructor
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hafnermorris at gmail dot com
  Target Milestone: ---

Created attachment 40717
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40717=edit
Minimal example code

The following example causes a segmentation fault in gcc 5, 6 and the current
trunk:

struct S {
  constexpr S(int i) {
auto f = [i]{};
  }
};
int main() {}

on Compiler Explorer: https://godbolt.org/g/wlhJ5O

Compiled both with -std=c++14 and -std=c++1z, on a x86-64 Linux machine.

[Bug target/79295] [7 regression] gcc.target/powerpc/bcd-3.c fails starting with r244942

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug c++/79452] Provide builtin to detect compile-time execution

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

 CC||eric at efcs dot ca

--- Comment #7 from Eric Fiselier  ---
There are definitely opportunities for ODR violations here, or at least
something like them. Consider the following case:

template 
constexpr bool foo(T) {
  if constexpr(__ctfe__)
return true;
  else
return false
}

static_assert(foo(0));
auto runtime = foo(0);

Both calls instantiate foo with the same template arguments, so they should
seemingly both get the same instantiation with the w/e value of `__ctfe__` was
when the implicit instantiations occurred. Therefore one of the two calls to
foo() will return the wrong answer.

This problem is made ever worse if `__builtin_constant_expression` allows you
to generate non-dependent compile-time expressions based on the function
arguments.

One solution would be to consider the instantiation of `foo` to be value
dependent on a "implicit template parameter" representing `__ctfe__`.

[Bug c/79460] New: gcc fails to optimise out a simple additive loop for seemingly arbitrary numbers of iterations

[drraph at gmail dot com]

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

Bug ID: 79460
   Summary: gcc fails to optimise out a simple additive loop for
seemingly arbitrary numbers of iterations
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drraph at gmail dot com
  Target Milestone: ---

Consider:

float f(float x[]) {
  float p = 1.0;
  for (int i = 0; i < 202; i++)
p += 1;
  return p;
}

and

float f(float x[]) {
  float p = 1.0;
  for (int i = 0; i < 200; i++)
p += 1;
  return p;
}

both compiled in gcc 7 (20170210 snapshot) with  -Ofast .

In the former case (the 202 case) you get:

f:
movss   xmm0, DWORD PTR .LC0[rip]
ret
.LC0:
.long   1128988672



In the latter case (the 200 case) you get:


f:
movaps  xmm0, XMMWORD PTR .LC0[rip]
xor eax, eax
movaps  xmm3, XMMWORD PTR .LC1[rip]
movaps  xmm2, XMMWORD PTR .LC2[rip]
.L2:
movaps  xmm1, xmm0
add eax, 1
cmp eax, 50
addps   xmm0, xmm3
addps   xmm1, xmm2
jne .L2
shufps  xmm1, xmm1, 255
movaps  xmm0, xmm1
ret
.LC0:
.long   1065353216
.long   1073741824
.long   1077936128
.long   1082130432
.LC1:
.long   1082130432
.long   1082130432
.long   1082130432
.long   1082130432
.LC2:
.long   1065353216
.long   1065353216
.long   1065353216
.long   1065353216

There are a lot of other pairs of consecutive even numbered limits where one
optimizes well and the other doesn't. For example 194 and 196.

[Bug ada/60403] [5/6/7 Regression] fatal error, system.ads not formatted correctly

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from John David Anglin  ---
Not an issue on hpux11.

[Bug target/79295] [7 regression] gcc.target/powerpc/bcd-3.c fails starting with r244942

[acsawdey at gcc dot gnu.org]

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

--- Comment #4 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Fri Feb 10 21:07:36 2017
New Revision: 245345

URL: https://gcc.gnu.org/viewcvs?rev=245345=gcc=rev
Log:
2017-02-10  Aaron Sawdey  

PR target/79295
* config/rs6000/altivec.md (bcd): Fix constraints.

Applying patch suggested by Meissner.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/altivec.md

[Bug c++/79457] [5/6 Regression] Segmentation fault in templated decltype evaluation

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb 10 20:58:31 2017
New Revision: 245344

URL: https://gcc.gnu.org/viewcvs?rev=245344=gcc=rev
Log:
PR c++/79457
* g++.dg/cpp0x/pr79457.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr79457.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c/79459] New: Please add enable_if and diagnose_if attributes (from clang)

[felix-gcc at fefe dot de]

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

Bug ID: 79459
   Summary: Please add enable_if and diagnose_if attributes (from
clang)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix-gcc at fefe dot de
  Target Milestone: ---

clang supports several advanced __attribute__ cases that gcc does not, and two
strike me as particularly useful: enable_if and diagnose_if. You can find the
documentation on those here:

https://clang.llvm.org/docs/AttributeReference.html#diagnose-if
https://clang.llvm.org/docs/AttributeReference.html#enable-if

Basically, diagnose_if allows to add custom warning messages, think of it as a
superset of the nonnull attribute. This could be a great tool to improve code
quality, if applied to an API from a library.

enable_if is much more complex and probably a lot harder to implement. It
allows to have a special case version of a library function and use the
attribute to tell the compiler to call it if the compiler knows the special
case is true. For example, one could have a special memset version that does
not need to do alignment handling if the compiler can tell that the destination
buffer is 16 byte aligned.

[Bug c++/79457] [5/6 Regression] Segmentation fault in templated decltype evaluation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-10
 CC||jakub at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
Version|7.0 |6.3.1
   Target Milestone|--- |5.5
Summary|Segmentation fault in   |[5/6 Regression]
   |templated decltype  |Segmentation fault in
   |evaluation  |templated decltype
   ||evaluation
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Started with r181131, fixed with r244833 on the trunk (PR71710 fix).

[Bug c++/77790] [5/6/7 Regression] ICE on valid C++14 code when compiling with "-std=c++11": in push_access_scope, at cp/pt.c:227

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |error-recovery
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #5 from Jason Merrill  ---
It's error-recovery.

[Bug c++/78908] [6/7 Regression] template instantiation with bit-field type

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Fri Feb 10 20:43:33 2017
New Revision: 245343

URL: https://gcc.gnu.org/viewcvs?rev=245343=gcc=rev
Log:
PR c++/78908 - template ops and bitfields

* tree.c (build_min_non_dep): Use unlowered_expr_type.

Added:
trunk/gcc/testsuite/g++.dg/template/bitfield3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c

[Bug rtl-optimization/21182] [5/6/7 Regression] gcc can use registers but uses stack instead

[vmakarov at gcc dot gnu.org]

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

--- Comment #23 from Vladimir Makarov  ---
(In reply to Jeffrey A. Law from comment #22)
> Vlad -- I was thinking more in the sense of whether or not IRA is presented
> with something reasonable (ie, can be colored) vs unreasonable (can not be
> colored).
> 
> The former is clearly possible with this source, but we well could be making
> the graph uncolorable with some of the early tree optimizations -- I
> certainly saw enough cprop/forwprop/dom transformations to give me concern
> that what we're presenting to IRA isn't colorable.

IRA can print the register pressure.  If it is bigger than the number of
available hard regs,  the graph cannot be colored for sure.  For -UNAIL_REGS
and -O3 I see the pressure 10 (and 7 available hard regs).  So it is not
colorable.

If the pressure is less or the same number it is really hard to define manually
non-trivial graph colorability.  It is even harder to evaluate the minimal
number of spill pseudos manually.  But we can evaluate the lower bound.

  To achieve register pressure 7 we need to spill at least 3 pseudos.   As the
pseudos should be defined and used, it means at least 6 stack memory
references.  It is more than 3 reported for the older GCC versions.  My
conclusion is that the optimizations before became more aggressive and they are
at least partially responsible for worse results.

So I believe, Jeff, your suspicions about the previous optimizations have a
ground.

[Bug c++/79458] New: attributes on constructor between class name and parameter list not accepted

[jplejacq at quoininc dot com]

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

Bug ID: 79458
   Summary: attributes on constructor between class name and
parameter list not accepted
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jplejacq at quoininc dot com
  Target Milestone: ---

Compiling the following with -std='c++1z' -W'all' -W'extra':

class test {
  test  [[gnu::nonnull]] (char * arg);
};

test::test(char * arg) {
}

results in the following errors:

!!error: candidates are: constexpr test::test(test&&)
x86-64 gcc 7 (snapshot)!!error: constexpr test::test(const test&)
x86-64 gcc 7 (snapshot)!!error: constexpr test::test()
3
  test  [[gnu::nonnull]] (char * arg);
x86-64 gcc 7 (snapshot)!!error: expected unqualified-id before 'char'
x86-64 gcc 7 (snapshot)!!error: expected ')' before 'char'


https://godbolt.org/g/sgdgNy

[Bug c++/78897] [6/7 Regression] ICE: in output_constructor_regular_field, at varasm.c:5019

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Fri Feb 10 20:08:39 2017
New Revision: 245342

URL: https://gcc.gnu.org/viewcvs?rev=245342=gcc=rev
Log:
PR c++/78897 - constexpr union

* constexpr.c (cxx_eval_store_expression): A store to a union member
erases a previous store to another member.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/constexpr-union1.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/constexpr.c

[Bug c++/78897] [6/7 Regression] ICE: in output_constructor_regular_field, at varasm.c:5019

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/79457] Segmentation fault in templated decltype evaluation

[teemu at hecknology dot net]

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

--- Comment #2 from Teemu Piippo  ---
Created attachment 40716
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40716=edit
Minimal example that does not crash

[Bug c++/79457] Segmentation fault in templated decltype evaluation

[teemu at hecknology dot net]

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

--- Comment #1 from Teemu Piippo  ---
If the "S" declaration is removed and the decltype(...) moved into the return
type of Foo::boo(), GCC does not crash and builds the example properly.

[Bug c++/79457] New: Segmentation fault in templated decltype evaluation

[teemu at hecknology dot net]

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

Bug ID: 79457
   Summary: Segmentation fault in templated decltype evaluation
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: teemu at hecknology dot net
  Target Milestone: ---

Created attachment 40715
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40715=edit
Minimal example

GCC crashes compiling the attached source file. Clang builds the code in
question properly.

[ teemu@apotheosis ~/crash ]$ /usr/lib/gcc-snapshot/bin/g++ bug.cpp -std=c++11
-save-temps
bug.cpp: In substitution of 'template template using S =
decltype (((Foo*)(void)0)->Foo::goo[R()]) [with R = R; T = T]':
bug.cpp:13:5:   required from here
bug.cpp:7:21: internal compiler error: in lookup_member, at cp/search.c:1256
  using S = decltype(goo[R()]);
 ^~~

Version information (of gcc-snapshot; the example also crashes just the same in
default distribution-provided g++ 6.2.0):

[ teemu@apotheosis ~/crash ]$ /usr/lib/gcc-snapshot/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/lib/gcc-snapshot/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
20161006-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --program-prefix= --enable-shared
--enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --enable-objc-gc --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=yes
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.0.0 20161006 (experimental) [trunk revision 240826] (Ubuntu
20161006-1ubuntu1)
[ teemu@apotheosis ~/crash ]$ uname -a
Linux apotheosis 4.8.0-37-generic #39-Ubuntu SMP Thu Jan 26 02:27:07 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux
[ teemu@apotheosis ~/crash ]$ cat /etc/issue
Ubuntu 16.10 \n \l

[Bug c++/78908] [6/7 Regression] template instantiation with bit-field type

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords|lto |ice-on-valid-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
Summary|[6/7 Regression] lto1:  |[6/7 Regression] template
   |internal compiler error: in |instantiation with
   |lto_read_decls, at  |bit-field type
   |lto/lto.c:1814  |

[Bug rtl-optimization/21182] [5/6/7 Regression] gcc can use registers but uses stack instead

[law at redhat dot com]

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

--- Comment #22 from Jeffrey A. Law  ---
Vlad -- I was thinking more in the sense of whether or not IRA is presented
with something reasonable (ie, can be colored) vs unreasonable (can not be
colored).

The former is clearly possible with this source, but we well could be making
the graph uncolorable with some of the early tree optimizations -- I certainly
saw enough cprop/forwprop/dom transformations to give me concern that what
we're presenting to IRA isn't colorable.

[Bug tree-optimization/79347] [7 regression] vect_do_peeling is messing up profile

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
Testing a patch, will send for review soon if no failures.

[Bug target/70799] STV pass does not convert DImode shifts

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #8 from Uroš Bizjak  ---
Created attachment 40714
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40714=edit
Patch to handle variable DImode shifts

This patch converts variable DImode shifts to vector insns.

[Bug c++/77790] [5/6/7 Regression] ICE on valid C++14 code when compiling with "-std=c++11": in push_access_scope, at cp/pt.c:227

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
Prior to r185768 GCC in C++ 11 mode rejected auto functions without trailing
return type.  With r185768 GCC would accept it with a warning (enabled by
default).  r207055 changed the pedantic warning into an error.  In light of
this, should this bug be viewed as ice-on-invalid-code (error-recovery)?  Or is
it ice-on-valid because it broke in GCC 5 where the code was accepted in C++ 11
mode with just a warning?

[Bug c++/79345] [6/7 Regression] passing yet-uninitialized member as argument to base class constructor should warn (-Wunitialized)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Jason Merrill  ---
Compiling with -fno-lifetime-dse brings back the warning, so it seems that the
-Wuninitialized code is improperly treating the clobber as initialization.

[Bug c++/78897] [6/7 Regression] ICE: in output_constructor_regular_field, at varasm.c:5019

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Feb 10 18:50:30 2017
New Revision: 245341

URL: https://gcc.gnu.org/viewcvs?rev=245341=gcc=rev
Log:
PR c++/78897 - constexpr union

* constexpr.c (cxx_eval_store_expression): A store to a union member
erases a previous store to another member.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-union1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug c++/79104] [DR 696] wrong semantics for odr-use of constant variable from lambda

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Priority|P1  |P3
 Status|ASSIGNED|NEW
Summary|[7 Regression] ambiguity|[DR 696] wrong semantics
   |calling std::begin on a |for odr-use of constant
   |local constexpr array of|variable from lambda
   |structs |

--- Comment #4 from Jason Merrill  ---
The handling of this testcase went from wrong-code to rejects-valid, so I don't
think it qualifies as a regression.  The issue here is that we don't implement
DR 696 properly; we should capture a, but instead replace it with its initial
value.  Given that, r240819 changed this to be correctly rejected; a temporary
should not bind to a non-const reference.

Here's a simpler testcase to illustrate our non-conformance on DR 696:

void f ()
{
  const int i = 42;

  [&]() {
  // OK, captures i
  };
}

[Bug c++/56973] [DR 696] crash when capturing variables in nested lambdas

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
Summary|crash when capturing|[DR 696] crash when
   |variables in nested lambdas |capturing variables in
   ||nested lambdas

--- Comment #4 from Jason Merrill  ---
G++ still implements an early proposal for DR 696, whereby a reference to a
constant automatic variable from a lambda is replaced by the value of the
variable rather than implying a capture.  We need to properly implement DR 696
such that odr-use implies a capture.

[Bug c++/79104] [7 Regression] ambiguity calling std::begin on a local constexpr array of structs

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug c++/79401] [7 Regression] Protected inheriting ctor

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Jason Merrill  ---
Fixed.

[Bug c++/71285] [7 regression] spurious 'insufficient contextual information' for member access on fold expression

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/71285] [7 regression] spurious 'insufficient contextual information' for member access on fold expression

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Fri Feb 10 18:24:36 2017
New Revision: 245340

URL: https://gcc.gnu.org/viewcvs?rev=245340=gcc=rev
Log:
PR c++/71285 - member of fold-expression

* semantics.c (finish_unary_fold_expr)
(finish_binary_fold_expr): Use null type for fold-expressions.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/fold9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c

[Bug c++/71285] [7 regression] spurious 'insufficient contextual information' for member access on fold expression

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug c++/79401] [7 Regression] Protected inheriting ctor

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Fri Feb 10 18:01:27 2017
New Revision: 245339

URL: https://gcc.gnu.org/viewcvs?rev=245339=gcc=rev
Log:
PR c++/79401 - protected inherited constructor

* call.c (enforce_access): For inheriting constructor, find a base
binfo in the path we already have.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor25.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug middle-end/79448] unhelpful -Wformat-truncation=2 INT_MAX warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |ASSIGNED
Summary|unhelpful   |unhelpful
   |-Wformat-truncation=2   |-Wformat-truncation=2
   |warning |INT_MAX warning

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
  https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00730.html

[Bug c++/78897] [6/7 Regression] ICE: in output_constructor_regular_field, at varasm.c:5019

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug sanitizer/79341] Many Asan tests fail on s390

[jakub at gcc dot gnu.org]

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

--- Comment #43 from Jakub Jelinek  ---
Ah, so, if I build with -O0, I always get the expected errors.
If I build with -O2 -mcpu=z9-109, I also get them, but with -O2 -mcpu=z10 or
-O2 -mcpu=zEC12 I don't.
Does _Decimal32 on s390{,x} behave similarly to float/double on i387, that
computations and comparisons can be performed in bigger precision than their
types?
--- gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-8.c.jj 2015-10-29
09:14:30.0 +0100
+++ gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-8.c2017-02-10
18:09:47.767251774 +0100
@@ -8,7 +8,7 @@
 #define TEST(type1, type2) \
   if (type1##_MIN) \
 {  \
-  type2 min = type1##_MIN; \
+  volatile type2 min = type1##_MIN;\
   type2 add = -1.0;\
   while (1)\
{   \
@@ -28,7 +28,7 @@
   volatile type1 tem3 = cvt_##type1##_##type2 (-1.0f); \
 }  \
   {\
-type2 max = type1##_MAX;   \
+volatile type2 max = type1##_MAX;  \
 type2 add = 1.0;   \
 while (1)  \
   {\

seems to be a workaround, the test primarily cares about the actual
conversions, not how those values are reached, so it isn't against the intent
of the test.

[Bug c++/79401] [7 Regression] Protected inheriting ctor

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug tree-optimization/66612] [6/7/8 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[segher at gcc dot gnu.org]

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

--- Comment #15 from Segher Boessenkool  ---
Author: segher
Date: Fri Feb 10 16:58:14 2017
New Revision: 245337

URL: https://gcc.gnu.org/viewcvs?rev=245337=gcc=rev
Log:
testsuite, rs6000: Don't xfail 32-bit (PR66612)

-m32 works fine, only 64-bit still fails.


gcc/testsuite/
PR tree-optimization/66612
* gcc.target/powerpc/20050830-1.c: Don't xfail on 32-bit.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/20050830-1.c

[Bug sanitizer/79341] Many Asan tests fail on s390

[vogt at linux dot vnet.ibm.com]

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

--- Comment #42 from Dominik Vogt  ---
With glibc-2.18 and the various patches, the following tets fail:

-m31:
 * deep-stack-uaf-1.C

-m64:
 * null-deref-1.c
 * deep-stack-uaf-1.C
 * overflow-vec-1.c
 * overflow-vec-2.c
 * float-cast-overflow-10.c

I.e. the same as with glibc-2.23.  At least this part of the problems is
solved.

[Bug c++/79350] "explicit" deduction guides don't work

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #2 from Jason Merrill  ---
Fixed.

[Bug sanitizer/79341] Many Asan tests fail on s390

[vogt at linux dot vnet.ibm.com]

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

--- Comment #41 from Dominik Vogt  ---
> The first loop loops until add is -1.00E+12, at which point for the
> first time tem is -9.223373E+18 and thus different from -9.223372E+18, and
> -9.223373E+18 should not be representable in signed long.
> Do you perhaps use HW dfp rather than software emulation?

Well, just what the test driver used:

 ... -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects 
-fsanitize=float-cast-overflow -fsanitize-recover=float-cast-overflow
-DUSE_INT128 -DUSE_DFP -DBROKEN_DECIMAL_INT128  -lm   -m64 ...

When the comparison is done in main, the values "min" and "tem" have 64-Bit
precision.  The actual comparison is

  if (tem.0_1 != -9223372036854775808)

Which is true because that value doesn't fit in a _Decimal32.  The if body is
executed, and "tem" is converted to 32 bit format and stored in %f0.  Gdb says
that the converted value is exactly the same as the value of "min", and that
seems to be the cause of the test failure.

In assembly:
ste %f2,160(%r15) < store "tem" on stack
le  %f2,160(%r15) < load "tem" from stack
ldetr   %f2,%f2,0 < convert "short" dfp value to "long"
cdtr%f2,%f4   < compare with "min"
je  .L33
le  %f0,160(%r15) < reload "tem"
brasl   %r14,cvt_sl_d32

This must look differently for you.  Now, why does the test fail for me but not
for you?

[Bug c++/79301] With -Werror=pedantic outside C++17 mode, __has_cpp_attribute(fallthrough) is nonzero but [[fallthrough]] fails

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 40713
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40713=edit
gcc7-pr79301.patch

If that is what we want, I think this untested patch should implement it.

[Bug c++/79184] [7 Regression] -Wint-in-bool-context triggered erroneously in template parameter

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Marek Polacek  ---
Fixed.

[Bug c++/79435] [7 Regression] ICE on invalid C++ code (with member access into an incomplete type) on x86_64-linux-gnu: Segmentation fault

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/79184] [7 Regression] -Wint-in-bool-context triggered erroneously in template parameter

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Fri Feb 10 16:33:45 2017
New Revision: 245335

URL: https://gcc.gnu.org/viewcvs?rev=245335=gcc=rev
Log:
PR c++/79184
* cvt.c (ocp_convert): Add a sentinel against -Wint-in-bool-context
if warnings shouldn't be given.

* g++.dg/warn/Wint-in-bool-context-1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wint-in-bool-context-1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/79435] [7 Regression] ICE on invalid C++ code (with member access into an incomplete type) on x86_64-linux-gnu: Segmentation fault

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Fri Feb 10 16:32:19 2017
New Revision: 245334

URL: https://gcc.gnu.org/viewcvs?rev=245334=gcc=rev
Log:
PR c++/79435
* pt.c (type_dependent_expression_p): Check if the expression type
is null.

* g++.dg/cpp1y/pr79435.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr79435.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug target/79131] [7 Regression] ICE: in extract_constrain_insn, at recog.c:2213, big-endian ARM

[krebbel at gcc dot gnu.org]

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

--- Comment #15 from Andreas Krebbel  ---
(In reply to Richard Earnshaw from comment #14)
> I think you should open a new bug report.  This one has been closed (and the
> ICE has been fixed), so this is a new issue.

I've opened #79456

[Bug rtl-optimization/79456] [7 regression] Extra instruction emitted after LRA patch

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Target||s390x-ibm-linux
   Priority|P3  |P2
   Host||s390x-ibm-linux
  Build||s390x-ibm-linux

[Bug rtl-optimization/79456] New: [7 regression] Extra instruction emitted after LRA patch

[krebbel at gcc dot gnu.org]

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

Bug ID: 79456
   Summary: [7 regression] Extra instruction emitted after LRA
patch
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

The zvector/vec-cmp-1.c testcase currently fails on s390x.

Starting with that patch we see worse code being generated for:

int __attribute__((noinline,noclone))
all_eq_double (double __attribute__((vector_size(16))) a,
   double __attribute__((vector_size(16))) b)
{
 return __builtin_s390_vec_all_eq (a, b);
}

gcc -O3 -march=z13
before:
vfcedbs %v0,%v24,%v26
lhi %r2,1
lochine %r2,0
lgfr%r2,%r2
br  %r14
after:
vfcedbs %v0,%v24,%v26
lhi %r2,1
lr  %r1,%r2
lochine %r1,0
lgfr%r2,%r1
br  %r14

Note: ideally it should be more like:
vfcedbs %v0,%v24,%v26
lghi %r2,1
locghine %r2,0
br %r14
... but that's a different topic.

The same problem can be reproduced also with vector types:

long foo (long a, long b)   
{
return a > b;
}

old (r244941):

cgr %r2,%r3
lghi%r2,1
locghinh%r2,0
br  %r14

after (r244942):

cgr %r2,%r3
lghi%r1,1
locghinh%r1,0
lgr %r2,%r1
br  %r14

[Bug c++/79301] With -Werror=pedantic outside C++17 mode, __has_cpp_attribute(fallthrough) is nonzero but [[fallthrough]] fails

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Jason Merrill from comment #7)
> (In reply to Jakub Jelinek from comment #4)
> > That said, I think e.g. for maybe_unused or nodiscard attributes we don't
> > complain with -pedantic about those attributes used in C++14 code, so either
> > we should do that as well, or we shouldn't do that for fallthrough either.
> > Jason?
> 
> We certainly don't want to both have __has_cpp_attribute(fallthrough)
> non-zero and also complain about its usage.  My inclination would be to
> remove the diagnostic.

Also for deprecated attribute and C++11?
  else if (is_attribute_p ("deprecated", attr_id))
{
  if (cxx_dialect == cxx11)
pedwarn (token->location, OPT_Wpedantic,
 "% is a C++14 feature;"
 " use %");
  TREE_PURPOSE (TREE_PURPOSE (attribute)) = get_identifier ("gnu");
}
  /* C++17 fallthrough attribute is equivalent to GNU's.  */
  else if (is_attribute_p ("fallthrough", attr_id))
{
  if (cxx_dialect < cxx1z)
pedwarn (token->location, OPT_Wpedantic,
 "% is a C++17 feature;"
 " use %");
  TREE_PURPOSE (TREE_PURPOSE (attribute)) = get_identifier ("gnu");
}
Even for that one can test #if __has_cpp_attribute(deprecated) and
[[deprecated]] still won't work if -std=c++11 -pedantic-errors.

[Bug testsuite/79455] New: c-c++-common/tsan/race_on_mutex.c fails on powerpcle starting with r244854 (where it was activated)

[seurer at gcc dot gnu.org]

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

Bug ID: 79455
   Summary: c-c++-common/tsan/race_on_mutex.c fails on powerpcle
starting with r244854 (where it was activated)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---


r244854 | jakub | 2017-01-24 02:19:37 -0600 (Tue, 24 Jan 2017) | 2 lines

* configure.tgt: Enable tsan and lsan on powerpc64{,le}-*-linux*.


When run on powerpcle the output is the same as on x86 except for one section,
the one with memset.

On x86 this part is:
  Previous write of size 1 at 0x00601300 by thread T1:
#0 pthread_mutex_init
/home/seurer/gcc/gcc-test/libsanitizer/tsan/tsan_interceptors.cc:1117
(libtsan.so.0+0x0002c1ee)
#1 Thread1
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/tsan/race_on_mutex.c:12
(race_on_mutex.exe+0x00400bf8)

And on power it is:
  Previous write of size 8 at 0x10011600 by thread T1:
#0 memset
/home/seurer/gcc/gcc-test/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:558
(libtsan.so.0+0x000360f4)
#1 pthread_mutex_init  (libpthread.so.0+0xb61c)
#2 Thread1
/home/seurer/gcc/gcc-test/gcc/testsuite/c-c++-common/tsan/race_on_mutex.c:12
(race_on_mutex.exe+0x1cb4)

It fails when run as a test because it doesn't quite match the expected pattern

/* { dg-output "  Previous write of size 1 at .* by thread T1:(\n|\r\n|\r)" }
*/
/* { dg-output "#0 pthread_mutex_init .* (.)*" } */
/* { dg-output "#1 Thread1.* .*(race_on_mutex.c:12|\\?{2}:0) .*" } */

>From poking around in the test case and the tsan code it looks like the test is
detecting what it should and the difference in output is mostly "cosmetic".

[Bug rtl-optimization/21182] [5/6/7 Regression] gcc can use registers but uses stack instead

[vmakarov at gcc dot gnu.org]

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

--- Comment #21 from Vladimir Makarov  ---
(In reply to Jeffrey A. Law from comment #20)
>
> Anyway, just some thoughts.  We're still not at a point where we really know
> if IRA is being presented with something that isn't actually colorable or if
> IRA is just doing a poor job.

IRA was introduced in GCC4.4.  That time, the numbers were ok.  So I don't
think something is missed in IRA.  It is not a deleted regmove pass (and new
threaded coloring in RA which substituted it) too as it was done for GCC4.9. 
Either it is a different input code to IRA (more aggressive optimizations
before RA) or some big changes in IRA after initial introducing it.  Although I
always checked new RA optimizations on SPEC2000/SPEC2006, this particular code
could be worsened such new changes.

The biggest change (several K lines patch) in IRA in this time span was a new
coloring scheme for irregular register files (an approach analogous to
https://pdfs.semanticscholar.org/1072/2533ba1d88f53ce6635865d5230b9802246f.pdf)
.  As I remember it gave 1% improvement for SPEC2000.  May be it is a culprit.

I any case I don't think i386 is important these days to spent much time on the
PR.

[Bug target/79131] [7 Regression] ICE: in extract_constrain_insn, at recog.c:2213, big-endian ARM

[rearnsha at gcc dot gnu.org]

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

--- Comment #14 from Richard Earnshaw  ---
(In reply to Andreas Krebbel from comment #12)

> Starting with that patch we see worse code being generated for:
> 
> int __attribute__((noinline,noclone))
> all_eq_double (double __attribute__((vector_size(16))) a,
>double __attribute__((vector_size(16))) b)
> {
>  return __builtin_s390_vec_all_eq (a, b);
> }
> 
> gcc -O3 -march=z13
> before:
> vfcedbs %v0,%v24,%v26
> lhi %r2,1
> lochine %r2,0
> lgfr%r2,%r2
> br  %r14
> after:
> vfcedbs %v0,%v24,%v26
> lhi %r2,1
> lr  %r1,%r2
> lochine %r1,0
> lgfr%r2,%r1
> br  %r14
> 
> Note: ideally it should be more like:
> vfcedbs %v0,%v24,%v26
> lghi %r2,1
> locghine %r2,0
> br %r14
> ... but that's a different topic:


I think you should open a new bug report.  This one has been closed (and the
ICE has been fixed), so this is a new issue.

[Bug sanitizer/79341] Many Asan tests fail on s390

[jakub at gcc dot gnu.org]

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

--- Comment #40 from Jakub Jelinek  ---
(In reply to Dominik Vogt from comment #38)
> (And if it does generate messages, does it take the if or the else bodies? 
> For me it's the if-bodies.)

/home/jakub/gcc/obj/gcc/xgcc -B/home/jakub/gcc/obj/gcc/ fco.c
-B/home/jakub/gcc/obj/s390x-ibm-linux-gnu/./libsanitizer/
-B/home/jakub/gcc/obj/s390x-ibm-linux-gnu/32/libsanitizer/ubsan/
-L/home/jakub/gcc/obj/s390x-ibm-linux-gnu/32/libsanitizer/ubsan/.libs
-fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -Wno-psabi
-fsanitize=float-cast-overflow -fsanitize-recover=float-cast-overflow -lm -o
./fco.exe -g -m31
[jakub@devel4 testsuite]$
LD_LIBRARY_PATH=/home/jakub/gcc/obj/s390x-ibm-linux-gnu/32/libsanitizer/ubsan/.libs:/home/jakub/gcc/obj/s390x-ibm-linux-gnu/32/libgcc/32/
./fco.exe
fco.c:4:3: runtime error: value  is outside the range of representable
values of type 'long int'
fco.c:9:3: runtime error: value  is outside the range of representable
values of type 'long long int'

What do you mean by if bodies?  (-0x7fffL - 1L) is non-zero, so
obviously the else bodies aren't reached.
The first loop loops until add is -1.00E+12, at which point for the first
time tem is -9.223373E+18 and thus different from -9.223372E+18, and
-9.223373E+18 should not be representable in signed long.
Do you perhaps use HW dfp rather than software emulation?

In *.optimized dump I see:
  x.0_8 = x_7(D);
  _1 = x.0_8 u<= -9.223373E+18;
  _2 = x.0_8 u>= 9.223373E+18;
  _3 = _1 | _2;
  if (_3 != 0)
goto ; [0.00%]
  else
goto ; [0.00%]

   [0.00%]:
  _4 = VIEW_CONVERT_EXPR(x.0_8);
  _5 = (unsigned long) _4;
  __builtin___ubsan_handle_float_cast_overflow (&*.Lubsan_data0, _5);

   [0.00%]:
  _11 = (long int) x.0_8;

 [0.00%]:
  return _11;
which looks also correct to me.

[Bug target/79131] [7 Regression] ICE: in extract_constrain_insn, at recog.c:2213, big-endian ARM

[vogt at linux dot vnet.ibm.com]

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

--- Comment #13 from Dominik Vogt  ---
Same without vectors:

long foo (long a, long b)   
{
return a > b;
}

=>

cgr %r2,%r3
lghi%r1,1
locghinh%r1,0
lgr %r2,%r1
br  %r14

[Bug target/79131] [7 Regression] ICE: in extract_constrain_insn, at recog.c:2213, big-endian ARM

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu.org

--- Comment #12 from Andreas Krebbel  ---
(In reply to Vladimir Makarov from comment #3)
> Author: vmakarov
> Date: Thu Jan 26 17:08:12 2017
> New Revision: 244942
> 
> URL: https://gcc.gnu.org/viewcvs?rev=244942=gcc=rev
> Log:
> 2017-01-26  Vladimir Makarov  
> 
>   PR target/79131
>   * lra-assigns.c (setup_live_pseudos_and_spill_after_risky): Take
>   endianess for subregs into account.
>   * lra-constraints.c (lra_constraints): Do risky transformations
>   always on the first iteration.
>   * lra-lives.c (check_pseudos_live_through_calls): Add arg
>   last_call_used_reg_set.
>   (process_bb_lives): Define and use last_call_used_reg_set.
>   * lra.c (lra): Always continue after lra_constraints on the first
>   iteration.
> 
> 2017-01-26  Vladimir Makarov  
> 
>   PR target/79131
>   * gcc.target/arm/pr79131.c: New.

Starting with that patch we see worse code being generated for:

int __attribute__((noinline,noclone))
all_eq_double (double __attribute__((vector_size(16))) a,
   double __attribute__((vector_size(16))) b)
{
 return __builtin_s390_vec_all_eq (a, b);
}

gcc -O3 -march=z13
before:
vfcedbs %v0,%v24,%v26
lhi %r2,1
lochine %r2,0
lgfr%r2,%r2
br  %r14
after:
vfcedbs %v0,%v24,%v26
lhi %r2,1
lr  %r1,%r2
lochine %r1,0
lgfr%r2,%r1
br  %r14

Note: ideally it should be more like:
vfcedbs %v0,%v24,%v26
lghi %r2,1
locghine %r2,0
br %r14
... but that's a different topic:

[Bug sanitizer/79341] Many Asan tests fail on s390

[jakub at gcc dot gnu.org]

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

--- Comment #39 from Jakub Jelinek  ---
For overflow-vec-*.c moved this to PR79454.

[Bug middle-end/79454] [7 Regression] c-c++-common/ubsan/overflow-vec-*.c FAILs on some 64-bit BE targets

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 40712
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40712=edit
gcc7-pr79454.patch

Untested fix.  The problem was if the vector type had non-BLKmode, but not
vector mode, like e.g. for the 16xchar vector TImode, we actually performed the
addition to get the result in TImode rather than in V16QImode (not really
supported), or saving the result inside of the loop from each separate
comparison.

[Bug middle-end/79454] [7 Regression] c-c++-common/ubsan/overflow-vec-*.c FAILs on some 64-bit BE targets

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-02-10
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This is actually a regression, while in gcc 6 we for
-fsanitize=signed-integer-overflow ignored vector arithmetics (thus wouldn't
signal possible overflows), at least we computed the correct values, but now we
properly signal the overflow, but compute wrong values.

[Bug middle-end/79454] New: [7 Regression] c-c++-common/ubsan/overflow-vec-*.c FAILs on some 64-bit BE targets

[jakub at gcc dot gnu.org]

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

Bug ID: 79454
   Summary: [7 Regression] c-c++-common/ubsan/overflow-vec-*.c
FAILs on some 64-bit BE targets
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

c-c++-common/ubsan/overflow-vec-1.c
and
c-c++-common/ubsan/overflow-vec-2.c
tests on big endian powerpc64-linux and s390x-linux.

[Bug testsuite/79356] XPASS in attr-alloc_size-11.c

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|segher at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #6 from Segher Boessenkool  ---
Patch withdrawn.

[Bug sanitizer/79341] Many Asan tests fail on s390

[vogt at linux dot vnet.ibm.com]

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

--- Comment #38 from Dominik Vogt  ---
(And if it does generate messages, does it take the if or the else bodies?  For
me it's the if-bodies.)

[Bug sanitizer/79341] Many Asan tests fail on s390

[jakub at gcc dot gnu.org]

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

--- Comment #37 from Jakub Jelinek  ---
The overflow-vec-1.c and vec-2.c on -m64 fail also on ppc64{,le}.
Minimum failing testcase is:
#define SCHAR_MAX __SCHAR_MAX__
#define SCHAR_MIN (-__SCHAR_MAX__ - 1)
typedef signed char VC __attribute__((vector_size (16)));
void __attribute__((noinline,noclone))
checkvc (VC i, VC j)
{
  if (__builtin_memcmp (, , sizeof (VC)))
__builtin_abort ();
}
int
main (void)
{
  /* Check that for a vector operation, only the first element with UB is
reported.  */
  volatile VC a = (VC) { 0, SCHAR_MAX - 2, SCHAR_MAX - 2, 3, 2, 3, 4, 5,  0, 7,
 1,  2,  3, 4,  SCHAR_MAX - 13, SCHAR_MAX };
  volatile VC b = (VC) { 5, 2, 1, 5, 0, 1, 2, 7,  8, 9,
 10, 11, 6, -2, 13, 0 };
  volatile VC k = b + a;
  checkvc (k, (VC) { 5, SCHAR_MAX, SCHAR_MAX - 1, 8, 2, 4, 6, 12, 8,
16, 11, 13, 9, 2,  SCHAR_MAX,  SCHAR_MAX });
  return 0;
}
Looking into that now.

[Bug sanitizer/79341] Many Asan tests fail on s390

[vogt at linux dot vnet.ibm.com]

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

--- Comment #36 from Dominik Vogt  ---
Created attachment 40711
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40711=edit
Reduced test for float-cast-overflow-10.c

Test for the float-cast-overflow-10.c failure.

This snippet should detect that _Decimal32 doesn't fit in a signed 64-bit
integer (either signed long or signed long long).  Test uses "-m64 -O2
-fsanitize=float-cast-overflow -fsanitize-recover=float-cast-overflow".

If you compile and execute this preprocessed file, does ubsan generate messages
or not?

[Bug translation/79453] New: Translator unfriendly string in avr_pgm_check_var_decl

[fmarchal at perso dot be]

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

Bug ID: 79453
   Summary: Translator unfriendly string in avr_pgm_check_var_decl
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fmarchal at perso dot be
  Target Milestone: ---

In gcc/config/avr/avr.c, at line, 9831 (inside avr_pgm_check_var_decl()), one
can find this error message:

error ("pointer targeting address space %qs must be const"
   " in %s %q+D",
 avr_addrspace[as].name, reason, node);

The "reason" variable contains an untranslated text such as "variable",
"function parameter", "return type of function", and so on. Building a string
out of fragments doesn't play well at all with translations.

I'm afraid every reason should have its own error message.

[Bug c++/79345] [6/7 Regression] passing yet-uninitialized member as argument to base class constructor should warn (-Wunitialized)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |6.4

[Bug fortran/79426] [5/6/7 Regression] fortran - internal compiler error: in fold_convert_loc, at fold-const.c:2251

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |5.5

[Bug c++/41727] [7 Regression] inner template specialization on non-type arg template causes ICE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug sanitizer/79341] Many Asan tests fail on s390

[jakub at gcc dot gnu.org]

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

--- Comment #35 from Jakub Jelinek  ---
I've filed https://reviews.llvm.org/D29824 and https://reviews.llvm.org/D29825
upstream.

[Bug c++/79452] Provide builtin to detect compile-time execution

[gonzalobg88 at gmail dot com]

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

--- Comment #6 from gnzlbg  ---
> I wasn't replying to the part about function aliases, I was replying to the 
> part about having the built-in work even when used in a non-constexpr 
> function. It sounds like what you're suggesting would depend on optimisation 
> levels, rather than on the unambiguous semantics of whether something is 
> actually a constant-expression or not as defined by the C++ language. Maybe I 
> misunderstood what you mean by "some block inside that function is evaluated 
> by the constant expression evaluator". 

I actually meant that, but yes, you are 100% correct, that would definetely
lead to ODR issues. Thanks for pointing this out, I guess that the builtin
should, as you say, only be usable in constant expressions (as defined by C++).

> What about __builtin_constant_expression.

FWIW I went with __ctfe for the built-in because there is prior-art in D. It
has a built-in named __ctfe (compile-time function evaluation) that does what
is being proposed here, see: http://dlang.org/spec/function.html

The only important thing is that the built-in does not resemble anything that
we might ever want to standardize to avoid collisions. I would rather wait for
an agreement on the semantics before bike-shedding the name, but:

- __ctfe
- __builtin_constant_expression
- reciclying __builtin_constant_p() without any expression,
__builtin_constant_p(expr) already exists in gcc and detects whether expr
returns a value known at compile-time.

There are multiple candidates, I actually don't really care much for the name
as long as it is sufficiently self explanatory. 

I'd rather decide which approach is worth pursuing, and which semantics should
the builtin have, so that somebody can submit a patch with chances of getting
merged. We can always bike-shed the name of the builtin or attribute at the
last minute and just change it.

[Bug fortran/79446] Passing internal procedure as argument causes segfault at runtime

[townsend at astro dot wisc.edu]

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

--- Comment #2 from Rich Townsend  ---
(In reply to Dominique d'Humieres from comment #1)
> > Also, I don't experience the segfault on other Linux distros
> > (e.g., Gentoo/3.16.5) or Mac OS.
> 
> Confirmed on x86_64-apple-darwin16, even using an instrumented gfortran and
> -fsanitize=address,undefined.
> 
> What is the output of gfortran -v?

Using built-in specs.
COLLECT_GCC=/var/lib/condor/execute/slot1/dir_727203/mesasdk/bin/gfortran.exec
COLLECT_LTO_WRAPPER=/var/lib/condor/execute/slot1/dir_727203/mesasdk/bin/../libexec/gcc/x86_64-pc-linux-gnu/5.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/lib/condor/execute/slot1/dir_460062/mesasdk-src/gcc/configure CC=gcc
--build=x86_64-pc-linux-gnu
--prefix=/var/lib/condor/execute/slot1/dir_460062/mesasdk
--with-gmp=/var/lib/condor/execute/slot1/dir_460062/mesasdk
--with-mpfr=/var/lib/condor/execute/slot1/dir_460062/mesasdk
--with-mpc=/var/lib/condor/execute/slot1/dir_460062/mesasdk
--enable-languages=c,c++,fortran --disable-multilib --disable-nls
--disable-libsanitizer --enable-clocale=generic
Thread model: posix
gcc version 5.3.1 20160216 (GCC) 

Also, this is svn 245289.

[Bug sanitizer/79341] Many Asan tests fail on s390

[vogt at linux dot vnet.ibm.com]

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

--- Comment #34 from Dominik Vogt  ---
(In reply to Jakub Jelinek from comment #33)
> (In reply to Dominik Vogt from comment #32)
> > On a machine with
> >  * glibc-2.23
> 
> :(; I was hoping you could test #c24 patch against glibc 2.18

I'll eventually do that, but the colleagues wanted to be nice and replaced 2.18
on the machine with 2.23, so I have to look for an alternative first.

> I can't reproduce float-cast-overflow-10.c.

I'll try your patch and take a look at float-cast-overflow-10.c.

[Bug c++/79452] Provide builtin to detect compile-time execution

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
What about __builtin_constant_expression.

[Bug c++/71737] [5/6 Regression] ICE following 2x pack expansion in non-pack with template alias

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
Summary|[5/6/7 Regression] ICE  |[5/6 Regression] ICE
   |following 2x pack expansion |following 2x pack expansion
   |in non-pack with template   |in non-pack with template
   |alias   |alias

--- Comment #11 from Paolo Carlini  ---
This one should be fine. Fixed again in trunk.

[Bug c++/79452] Provide builtin to detect compile-time execution

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to gnzlbg from comment #2)
>   if constexpr() {  // Error: expression missing in if condition

Oh, I didn't realise you meant without an expression. Yeah that doesn't work.

> > That sounds like a recipe for ODR violations.
> 
> Could you elaborate on why? Since the `constexpr_alias` will only be called
> during compile-time evaluation, it will never collide with the "run-time"
> alias (which is inline, since constexpr implies inline). Note that
> `foo_constexpr` is a completely different function than `foo`, so these two
> never collide either.

I wasn't replying to the part about function aliases, I was replying to the
part about having the built-in work even when used in a non-constexpr function.
It sounds like what you're suggesting would depend on optimisation levels,
rather than on the unambiguous semantics of whether something is actually a
constant-expression or not as defined by the C++ language. Maybe I
misunderstood what you mean by "some block inside that function is evaluated by
the constant expression evaluator". If you simply mean when the built-in
appears as part of a constant-expression that's fine.

[Bug c++/71737] [5/6/7 Regression] ICE following 2x pack expansion in non-pack with template alias

[paolo at gcc dot gnu.org]

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

--- Comment #10 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Feb 10 13:14:05 2017
New Revision: 245327

URL: https://gcc.gnu.org/viewcvs?rev=245327=gcc=rev
Log:
/cp
2017-02-10  Paolo Carlini  

PR c++/71737
* pt.c (tsubst_decl): Don't try to preserve a typedef that names
an error_mark_node as type.

/testsuite
2017-02-10  Paolo Carlini  

PR c++/71737
* g++.dg/cpp0x/pr71737.C: New.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/pr71737.C

[Bug sanitizer/79341] Many Asan tests fail on s390

[jakub at gcc dot gnu.org]

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

--- Comment #33 from Jakub Jelinek  ---
(In reply to Dominik Vogt from comment #32)
> On a machine with
>  * glibc-2.23

:(; I was hoping you could test #c24 patch against glibc 2.18

>  * kernel 4.4.0 + patch for the CVE
>  * CVE environment variable set to allow running the Asan tests

Yeah, that is a workaround if you have known fixed kernel.

Most of the issues can be fixed with:

--- libsanitizer/configure.tgt.jj   2017-01-31 14:49:14.0 +0100
+++ libsanitizer/configure.tgt  2017-02-10 13:29:44.571294678 +0100
@@ -40,9 +40,6 @@ case "${target}" in
   sparc*-*-linux*)
;;
   s390*-*-linux*)
-   if test x$ac_cv_sizeof_void_p = x4; then
-   UNSUPPORTED=1
-   fi
;;
   arm*-*-linux*)
;;
--- libsanitizer/sanitizer_common/sanitizer_internal_defs.h.jj  2016-11-09
15:22:41.0 +0100
+++ libsanitizer/sanitizer_common/sanitizer_internal_defs.h 2017-02-10
13:29:28.359506264 +0100
@@ -287,7 +287,12 @@ void NORETURN CheckFailed(const char *fi
 enum LinkerInitialized { LINKER_INITIALIZED = 0 };

 #if !defined(_MSC_VER) || defined(__clang__)
-# define GET_CALLER_PC() (uptr)__builtin_return_address(0)
+# if SANITIZER_S390_31
+#  define GET_CALLER_PC() \
+  (uptr)__builtin_extract_return_addr(__builtin_return_address(0))
+# else
+#  define GET_CALLER_PC() (uptr)__builtin_return_address(0)
+# endif
 # define GET_CURRENT_FRAME() (uptr)__builtin_frame_address(0)
 inline void Trap() {
   __builtin_trap();

With this, the only FAILs I'm seeing on asan.exp and ubsan.exp are (various opt
levels):
-m64 only:
FAIL: c-c++-common/ubsan/overflow-vec-1.c
FAIL: c-c++-common/ubsan/overflow-vec-2.c
both -m64 and -m31:
FAIL: g++.dg/asan/deep-stack-uaf-1.C

I can't reproduce float-cast-overflow-10.c.

[Bug middle-end/79396] [7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O2

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
The preprocessed source doesn't ICE for me neither.

[Bug c++/79452] Provide builtin to detect compile-time execution

[gonzalobg88 at gmail dot com]

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

--- Comment #3 from gnzlbg  ---
I guess I should have written, "How does this feature make ODR violations more
common than the inline keyword?". Which new perils does it introduce?

[Bug c++/79435] [7 Regression] ICE on invalid C++ code (with member access into an incomplete type) on x86_64-linux-gnu: Segmentation fault

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
I think the fix is to make type_dependent_expression_p a bit more robust:

--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -23818,6 +23818,7 @@ type_dependent_expression_p (tree expression)
  we couldn't determine its length in cp_complete_array_type because
  it is dependent.  */
   if (VAR_P (expression)
+  && TREE_TYPE (expression) != NULL_TREE
   && TREE_CODE (TREE_TYPE (expression)) == ARRAY_TYPE
   && !TYPE_DOMAIN (TREE_TYPE (expression))
   && DECL_INITIAL (expression))


Will test.

[Bug c++/79452] Provide builtin to detect compile-time execution

[gonzalobg88 at gmail dot com]

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

--- Comment #2 from gnzlbg  ---
> It's already in C++17 and supported by GCC.

The following program is ill-formed in C++17:

int main() {

  if constexpr() {  // Error: expression missing in if condition
return 1;
  }

  return 0;
}

> That sounds like a recipe for ODR violations.

Could you elaborate on why? Since the `constexpr_alias` will only be called
during compile-time evaluation, it will never collide with the "run-time" alias
(which is inline, since constexpr implies inline). Note that `foo_constexpr` is
a completely different function than `foo`, so these two never collide either.

[Bug c++/79452] Provide builtin to detect compile-time execution

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/79452] Provide builtin to detect compile-time execution

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to gnzlbg from comment #0)
> Implementation as a builtin is preferred, because it is possible that "if
> constexpr() { }" syntax will be proposed for standardization.

It's already in C++17 and supported by GCC.

> I'd rather have this built-in always work. That is, even if its invoked
> inside a non-constexpr function, it might still be that some block inside
> that function is evaluated by the constant expression evaluator of the C++
> compiler. The built-in should detect this case properly.

That sounds like a recipe for ODR violations.

[Bug c++/79452] New: Provide builtin to detect compile-time execution

[gonzalobg88 at gmail dot com]

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

Bug ID: 79452
   Summary: Provide builtin to detect compile-time execution
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gonzalobg88 at gmail dot com
  Target Milestone: ---

The run-time performance of constexpr functions is often sub-optimal, because
the optimal algorithm cannot be expressed within the capabilities of C++'s
constexpr feature, and never will be (in the worst case, the optimal run-time
implementation will require inline assembly, which cannot ever be standardized
nor made constexpr). 

It would be very useful to have a builtin that allows detecting compile-time
execution of the current function/block/scope like this:

if constexpr(__ctfe) {
  // the outer scope is being executed at compile-time
} else {
  // the outer scope will be executed at run-time
}

Implementation as a builtin is preferred, because it is possible that "if
constexpr() { }" syntax will be proposed for standardization.

I'd rather have this built-in always work. That is, even if its invoked inside
a non-constexpr function, it might still be that some block inside that
function is evaluated by the constant expression evaluator of the C++ compiler.
The built-in should detect this case properly.

There is an alternative proposal, using a function attribute
[[constexpr_alias(constexpr_fn_decl)]]:

constexpr int foo_constexpr();

[[constexpr_alias(foo_constexpr)]]
int foo();

that will replace a call to foo by a call to foo_constexpr whenever foo is
called during constant expression evaluation. 

Both features are isomorphic, and enable the same new kind of programs to be
written. Only one of them should be implemented. It is still not clear which.

[Bug c++/79184] [7 Regression] -Wint-in-bool-context triggered erroneously in template parameter

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
I suppose we'll have to use something like

--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -798,7 +798,15 @@ ocp_convert (tree type, tree expr, int convtype, int
flags,
 to the underlying type first.  */
  if (SCOPED_ENUM_P (intype) && (convtype & CONV_STATIC))
e = build_nop (ENUM_UNDERLYING_TYPE (intype), e);
- return cp_truthvalue_conversion (e);
+ if (complain & tf_warning)
+   return cp_truthvalue_conversion (e);
+ else
+   {
+ /* Prevent bogus -Wint-in-bool-context warnings coming
+from c_common_truthvalue_conversion down the line.  */
+ warning_sentinel w (warn_int_in_bool_context);
+ return cp_truthvalue_conversion (e);
+   }
}

   converted = convert_to_integer_maybe_fold (type, e, dofold);

(that makes g++ not warn at all on the test from Comment 2)

[Bug libstdc++/60936] [5/6/7 Regression] Binary code bloat with std::string

[meisenmann....@fh-salzburg.ac.at]

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

--- Comment #28 from Markus Eisenmann  ---
Hi!

@Jonathan:
Do you have any plans to backport/migrate these changes to the GCC 5 and/or 6
branch, to be provided/included on a next release?

An "official" fix would be much better (C++-development on embedded targets),
than waiting for (stable) GCC 7 or maintain a personal patched variant or
work-around.

Best regards from Salzburg,
Markus

[Bug rtl-optimization/79388] [6/7 Regression] wrong code with -O -fno-tree-coalesce-vars

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
--- gcc/combine.c.jj2017-01-30 09:31:48.0 +0100
+++ gcc/combine.c   2017-02-10 12:16:18.507855160 +0100
@@ -14288,6 +14288,11 @@ distribute_notes (rtx notes, rtx_insn *f
NULL_RTX, NULL_RTX, NULL_RTX);
  distribute_links (LOG_LINKS (tem_insn));

+ unsigned int regno = REGNO (XEXP (note, 0));
+ reg_stat_type *rsp = _stat[regno];
+ if (rsp->last_set == tem_insn)
+   record_value_for_reg (XEXP (note, 0), NULL,
NULL_RTX);
+
  SET_INSN_DELETED (tem_insn);
  if (tem_insn == i2)
i2 = NULL;

fixes both testcases by making sure that if we delete the instruction that is
still considered to be the setter of the last value, we also invalidate what
we've remembered for it.  No idea whether this is the right spot or right way
to invalidate that though.  Segher?

[Bug testsuite/79356] XPASS in attr-alloc_size-11.c

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|s390x-*-*, powerpc*-*-*,|s390x-*-*, powerpc*-*-*,
   |ia64-*-*, aarch64-*-*   |ia64-*-*, aarch64-*-*,
   ||sparc*-*-*
 CC||ro at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #5 from Rainer Orth  ---
Also on SPARC as mentioned in PR tree-optimization/78775.

[Bug rtl-optimization/79388] [6/7 Regression] wrong code with -O -fno-tree-coalesce-vars

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Another testcase from the other PR (-O):
unsigned int
foo (unsigned char x, unsigned long long y)
{
  do
{
  x &= !y;
  x %= 24;
}
  while (x < y);
  return x + y;
}

int
main (void)
{
  unsigned int x = foo (1, 0);
  if (x != 1)
__builtin_abort ();
  return 0;
}

[Bug rtl-optimization/79388] [6/7 Regression] wrong code with -O -fno-tree-coalesce-vars

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
*** Bug 79450 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/79450] [5/6/7 Regression] wrong code with loop at -O1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jakub Jelinek  ---
IMNSHO this is a dup of PR79388.  The problem is again that get_last_value is
called on (reg/v:QI 96 [ x ]) and reg_stat[96].last_set is (note 22 21 24 3
NOTE_INSN_DELETED) and (const_int 0 [0]) which is wrong, because pseudo 96 has
been set multiple times, once indeed to something that would be always zero,
but all that has been removed when the whole something = something % 24
operation consisting of various shifts, additions and subtraction has been
optimized into something.

*** This bug has been marked as a duplicate of bug 79388 ***

[Bug sanitizer/79341] Many Asan tests fail on s390

[vogt at linux dot vnet.ibm.com]

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

--- Comment #32 from Dominik Vogt  ---
On a machine with
 * glibc-2.23
 * kernel 4.4.0 + patch for the CVE
 * CVE environment variable set to allow running the Asan tests
 * patch from comment 24 applied

=>

In addition to the FAILs you've listed here:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01814.html

(same test failing with different options listed only once)

Running target unix/-m31 
FAIL: c-c++-common/asan/memcmp-1.c   -O0  output pattern test, is
=
FAIL: c-c++-common/asan/misalign-1.c   -O2  output pattern test, is
= 
FAIL: c-c++-common/asan/misalign-2.c   -O2  output pattern test, is
= 
FAIL: c-c++-common/asan/strlen-overflow-1.c   -O0  output pattern test, is
= 
FAIL: c-c++-common/asan/strncpy-overflow-1.c   -O0  output pattern test, is
= 
...
Running target unix/-m64 
FAIL: c-c++-common/asan/null-deref-1.c   -O2  output pattern test, is
ASAN:DEADLYSIGNAL 
...
FAIL: c-c++-common/ubsan/float-cast-overflow-10.c   -O2  output pattern test,
is c-c++-common/ubsan/float-cast-overflow-7.h:147:1: runtime error: value
 is outside the range of representable values of \
type 'signed char' 
...
=== g++ tests === 


Running target unix/-m31 
FAIL: c-c++-common/asan/memcmp-1.c   -O0  output pattern test, is
= 
FAIL: c-c++-common/asan/misalign-1.c   -O2  output pattern test, is
= 
FAIL: c-c++-common/asan/misalign-2.c   -O2  output pattern test, is
= 
FAIL: c-c++-common/asan/strlen-overflow-1.c   -O0  output pattern test, is
= 
FAIL: g++.dg/asan/deep-tail-call-1.C   -O0  output pattern test, is
= 
...
Running target unix/-m64 
FAIL: c-c++-common/ubsan/float-cast-overflow-10.c   -O2  output pattern test,
is c-c++-common/ubsan/float-cast-overflow-7.h:147:1: runtime error: value
 is outside the range of representable values of \
type 'signed char' 

--

So, actually two more problems?

1) *san is not disabled with -m31 as it should(?)
2) ubsan/float-cast-overflow-10.c