[Bug target/80160] [7 regression] operand has impossible constraints

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80160
Bug 80160 depends on bug 80148, which changed state.

Bug 80148 Summary: [7 Regression] operand has impossible constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80148

   What|Removed |Added

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

[Bug target/80148] [7 Regression] operand has impossible constraints

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #7 from Jeffrey A. Law  ---
Fixed by Vlad's commit on the trunk.

[Bug rtl-optimization/80159] [7 regression] gcc takes very long time with -Os

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #5 from Jeffrey A. Law  ---
Fixed by Bernd's patch on the trunk.

[Bug target/80160] [7 regression] operand has impossible constraints

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #8 from Jeffrey A. Law  ---
Fixed by Bernd's patch on the trunk.

[Bug c++/70974] armv8-a+crc does not define __ARM_ACLE

[dmick at redhat dot com]

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

Dan Mick  changed:

   What|Removed |Added

 CC||dmick at redhat dot com

--- Comment #1 from Dan Mick  ---
Me too, on both these versions:  Centos 7.3.1611:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-redhat-linux/4.8.5/lto-wrapper
Target: aarch64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,lto --enable-plugin
--enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-aarch64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-aarch64-redhat-linux/cloog-install
--enable-gnu-indirect-function --build=aarch64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) 


and Ubuntu Xenial:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/5/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-arm64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-arm64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-arm64
--with-arch-directory=aarch64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror
--enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu
--target=aarch64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4)

[Bug tree-optimization/80181] New: [7 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:505

[asolokha at gmx dot com]

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

Bug ID: 80181
   Summary: [7 Regression] ICE in set_lattice_value, at
tree-ssa-ccp.c:505
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-7.0.0-alpha20170319 snapshot ICEs when compiling the following snippet w/
-O2 (-Os, -O3, -Ofast):

int
nr (void)
{
}

void
it (int dl)
{
  int vp = 0;

  for (;;)
{
  dl = vp ^ nr ();
  dl ^= vp;
  vp = 1;
}
}

% gcc-7.0.0-alpha20170319 -O2 -w -c btw2qvlq.c 
btw2qvlq.c: In function 'it':
btw2qvlq.c:17:1: internal compiler error: in set_lattice_value, at
tree-ssa-ccp.c:505
 }
 ^

[Bug target/80160] [7 regression] operand has impossible constraints

[bernds at gcc dot gnu.org]

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

--- Comment #7 from Bernd Schmidt  ---
Author: bernds
Date: Sat Mar 25 01:12:04 2017
New Revision: 246473

URL: https://gcc.gnu.org/viewcvs?rev=246473=gcc=rev
Log:
PR rtl-optimization/80160
PR rtl-optimization/80159
* lra-assigns.c (must_not_spill_p): Tighten new test to also take
reg_alternate_class into account.

* gcc.target/i386/pr80160.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr80160.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/80159] [7 regression] gcc takes very long time with -Os

[bernds at gcc dot gnu.org]

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

--- Comment #4 from Bernd Schmidt  ---
Author: bernds
Date: Sat Mar 25 01:12:04 2017
New Revision: 246473

URL: https://gcc.gnu.org/viewcvs?rev=246473=gcc=rev
Log:
PR rtl-optimization/80160
PR rtl-optimization/80159
* lra-assigns.c (must_not_spill_p): Tighten new test to also take
reg_alternate_class into account.

* gcc.target/i386/pr80160.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr80160.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c
trunk/gcc/testsuite/ChangeLog

[Bug c/80180] New: Incorrect codegen from rdseed intrinsic use

[teisenbe at google dot com]

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

Bug ID: 80180
   Summary: Incorrect codegen from rdseed intrinsic use
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: teisenbe at google dot com
  Target Milestone: ---

Created attachment 41051
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41051=edit
Preprocessed source file

When the attached source is compiled, the resulting assembly improperly handles
the success bit (CF) for rdseed.  The instruction immediately following "rdseed
%rax" is "testl %r8d, r8d" which clears CF.  The debug information does
identify the "setc" that should follow rdseed, but it is no where near the
rdseed instruction.

gcc -v output:
Using built-in specs.
COLLECT_GCC=./prebuilt/downloads/x86_64-elf-6.2.0-Linux-x86_64/bin/x86_64-elf-gcc
COLLECT_LTO_WRAPPER=/home/teisenbe/src/magenta/magenta/prebuilt/downloads/x86_64-elf-6.2.0-Linux-x86_64/bin/../libexec/gcc/x86_64-elf/6.2.0/lto-wrapper
Target: x86_64-elf
Configured with: ../gcc-6.2.0/configure --with-included-gettext
--target=x86_64-elf
--prefix=/home/phosek/fuchsia/third_party/gcc_none_toolchains/x86_64-elf-6.2.0-Linux-x86_64
--enable-languages=c,c++ --disable-werror --enable-initfini-array
Thread model: single
gcc version 6.2.0 (GCC) 

Command used to generate:
./prebuilt/downloads/x86_64-elf-6.2.0-Linux-x86_64/bin/x86_64-elf-gcc -O2  -g
-finline -include ./build-magenta-pc-x86-64/config-global.h -Wall -Wextra
-Wno-multichar -Werror -Wno-error=deprecated-declarations -Wno-unused-parameter
-Wno-unused-function -Wno-unused-label -Werror=return-type -fno-common
-Wno-nonnull-compare -fasynchronous-unwind-tables -ffunction-sections
-fdata-sections -fno-pic -ffreestanding -include
./build-magenta-pc-x86-64/config-kernel.h -Wformat=2 -Wformat-signedness
-fno-omit-frame-pointer -falign-jumps=1 -falign-loops=1 -falign-functions=4
-msoft-float -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -mno-avx -mno-avx2
-mno-80387 -mno-fp-ret-in-387 -mcmodel=kernel -mno-red-zone -mskip-rax-setup  
-mrdseed --include ./build-magenta-pc-x86-64/dev/intel_rng/config-module.h
--std=c11 -Werror-implicit-function-declaration -Wstrict-prototypes
-Wwrite-strings  -Wmissing-prototypes   -Isystem/public -Isystem/private
-I./build-magenta-pc-x86-64/gen/include -I./build-magenta-pc-x86-64
-Ikernel/include -Isystem/include -Ithird_party/include
-Ikernel/target/pc-x86/include -Ikernel/platform/pc/include
-Ikernel/arch/x86/include -Ikernel/top/include -Ikernel/kernel/include
-Ikernel/app/include -Ikernel/app/stringtests/include
-Ikernel/app/tests/include -Ikernel/dev/include -Ikernel/dev/intel_rng/include
-Ikernel/dev/interrupt/include -Ikernel/dev/pcie/include
-Isystem/ulib/bitmap/include -Ikernel/lib/bitmap/include
-Ikernel/lib/cbuf/include -Ikernel/lib/debugcommands/include
-Ikernel/lib/debuglog/include -Ikernel/lib/fixed_point/include
-Ikernel/lib/gfxconsole/include -Ikernel/lib/ktrace/include
-Ikernel/lib/mtrace/include -Ikernel/lib/pow2_range_allocator/include
-Ikernel/lib/syscalls/include -Ikernel/lib/userboot/include
-Ikernel/lib/version/include -Ikernel/platform/include -Ikernel/target/include
-Ithird_party/lib/acpica/source/include -Ithird_party/lib/acpica/include
-Ikernel/dev/hw_rng/include -Ikernel/kernel/vm/include
-Ikernel/lib/console/include -Ikernel/lib/crypto/include
-Ikernel/lib/debug/include -Ikernel/lib/font/include -Ikernel/lib/gfx/include
-Ikernel/lib/header_tests/include -Ikernel/lib/heap/include
-Ikernel/lib/heap/include -Ikernel/lib/libc/include
-Ikernel/lib/magenta/include -Ikernel/lib/mxtl/include
-Isystem/ulib/mxtl/include -Ikernel/lib/mxtl/include
-Isystem/ulib/region-alloc/include -Ikernel/lib/region-alloc/include
-Ikernel/lib/unittest/include -Ikernel/lib/user_copy/include
-Ikernel/lib/vdso/include -Ithird_party/lib/safeint/source/include
-Ithird_party/lib/safeint/include -Ikernel/dev/udisplay/include
-Ikernel/lib/dpc/include -Ikernel/lib/heap/cmpctmalloc/include
-Ikernel/lib/io/include -Ithird_party/ulib/cryptolib/include
-Ithird_party/lib/cryptolib/include -Ithird_party/ulib/qrcodegen/include
-Ithird_party/lib/qrcodegen/include -c kernel/dev/intel_rng/intel-rng.c -MD -MP
-MT build-magenta-pc-x86-64/dev/intel_rng/kernel/dev/intel_rng/intel-rng.c.o
-MF build-magenta-pc-x86-64/dev/intel_rng/kernel/dev/intel_rng/intel-rng.c.d -o
build-magenta-pc-x86-64/dev/intel_rng/kernel/dev/intel_rng/intel-rng.c.o
--save-temps

Compiler console output: None

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[bernd.edlinger at hotmail dot de]

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

--- Comment #48 from Bernd Edlinger  ---
(In reply to Jonathan Wakely from comment #47)
> (In reply to Bernd Edlinger from comment #46)
> > Yes, it seems, the __attribute__((may_alias)) does not propagate from
> > structure members to enclosing structure:
> 
> What enclosing structure? You're apparently agreeing with me, but saying
> something different. In the real code, and the example above, _there_ _is_
> _no_ _enclosing_ _structure_. I understand that it doesn't propagate to
> enclosing structures, that's fine. But if a type X has the attribute then it
> doesn't need to propagate anywhere, it should affect X. But it doesn't fix
> the original bug that started all this.

I think I agree with you, that is surprising that the may_alias
does not do what we need.
I think the enclosing structure is:

class function_base
{
public:
  function_base() : vtable(0) { }
[...]
public:
  detail::function::vtable_base* get_vtable() const {
return reinterpret_cast(
 reinterpret_cast(vtable) &
~static_cast(0x01));
  }

  bool has_trivial_copy_and_destroy() const {
return reinterpret_cast(vtable) & 0x01;
  }

  detail::function::vtable_base* vtable;
  mutable detail::function::function_buffer functor;
};

well, in fact even further down the class hierarchy.
the offending statement is:
this->functor = f.functor;

I think, if a functor may in general alias to anything,
it is possible that the outer object does not alias.
Does that make sense?

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

--- Comment #21 from Michael Meissner  ---
The backport to GCC 6 also succeeded with no regressions on a little endian
power8 system.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[redi at gcc dot gnu.org]

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

--- Comment #47 from Jonathan Wakely  ---
(In reply to Bernd Edlinger from comment #46)
> Yes, it seems, the __attribute__((may_alias)) does not propagate from
> structure members to enclosing structure:

What enclosing structure? You're apparently agreeing with me, but saying
something different. In the real code, and the example above, _there_ _is_ _no_
_enclosing_ _structure_. I understand that it doesn't propagate to enclosing
structures, that's fine. But if a type X has the attribute then it doesn't need
to propagate anywhere, it should affect X. But it doesn't fix the original bug
that started all this.

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

  Attachment #41035|0   |1
is obsolete||

--- Comment #20 from Michael Meissner  ---
Created attachment 41050
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41050=edit
Proposed patch to fix the problem (rework)

This patch reworks the original patch I submitted, to try and make it less
hacky.  It separates the bswap insns where there is hardware support into
separate read, write, and register swap instructions. This is because the
register allocators will try to push the bswap value in a register to the stack
and do the load based swap with reverse bytes.  Reload fumbles in certain
conditions.  LRA generates working code, but the store and the load with byte
reverse from the same location, can slow things down compared to the operation
on registers.

I only did this optimization where we had the hardware support (i.e. bswap for
HImode all of the time, bswap for SImode all of the time, and bswap for DImode
if we are executing 64-bit instructions and the machine has LDBRX/STDBRX --
power7 and newer/cell ppc).

I have done bootstrap builds on a little endian power8 system, on a big endian
power8 system, and a big endian power7 system (both 32/64-bit support on this
last system).  There were no regressions.

I am building the patches applied to gcc 6 right now.  The patches apply
cleanly to gcc 6.  I suspect it will also build on gcc 5.

I built spec 2006 benchmarks with the compiler.  There are 12 benchmarks that
generate one or more load/store with byte swap instructions (perlbench, gcc,
gamess, milc, zeusmp, calculix, h264ref, tonto, omnetpp, wrf, sphinx3,
xalancbmk).

I compared the instructions generated.  10 of the benchmarks generated the same
instructions.

Milc generated 1 less load with byte swap instruction and 1 more store with
byte swap instruction.

Sphinx3 generated 6 less load with byte swap instructions and 6 more store with
byte swap instructions.

So I count this as the same level of byte swapping is being generated.

[Bug c++/80179] ICE initializing a static local object with flexible array member in verify_ctor_sanity, at cp/constexpr.c:2641

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||6.3.0, 7.0

--- Comment #1 from Martin Sebor  ---
In C the test case isn't strictly conforming because it uses a non-constant
initializer for a static object (for which it's rejected by GCC), and because C
doesn't allow initializing objects with flexible array members.

In C++ where such initializers are allowed it is meant to be accepted by G++
which also supports static initialization of flexible array members as an
extension.

[Bug target/80102] [7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #3 from Segher Boessenkool  ---
This needs -mcpu=power8 to fail.

[Bug rtl-optimization/80112] [5/6 Regression] ICE in doloop_condition_get at loop-doloop.c:158

[zhroma at ispras dot ru]

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

Roman Zhuykov  changed:

   What|Removed |Added

 CC||zhroma at ispras dot ru

--- Comment #5 from Roman Zhuykov  ---
Created attachment 41049
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41049=edit
maybe more proper fix

6 years ago I was solving issue with same code lines and with Richard
Sandiford's help found a bit better solution, it was even approved, but
unfortunately we forgot to commit it. Discussion links:
https://gcc.gnu.org/ml/gcc-patches/2011-07/msg01803.html
https://gcc.gnu.org/ml/gcc-patches/2011-09/msg02049.html
https://gcc.gnu.org/ml/gcc-patches/2012-02/msg00479.html

Maybe it's better to apply that old patch?

PS. All my modulo-sched improvements described here together
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01647.html

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[bernd.edlinger at hotmail dot de]

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

--- Comment #46 from Bernd Edlinger  ---
(In reply to Jonathan Wakely from comment #45)
> (In reply to rguent...@suse.de from comment #32)
> > So you need to place may-alias at a point to make the following
> > stmt safe:
> > 
> > >   c = *p;
> > 
> > which means placing it on B, not only on the union (p is a B).
> > 
> > Thus do
> > 
> > struct B
> > {
> >   int x;
> >   union U
> > {
> >   int a;
> >   char b[sizeof (float)];
> > } u;
> >   int y;
> > } __attribute__((may_alias));
> 
> In the real code there is no B, there is just the union, and it is assigned
> directly, so it's more like:
> 
> union function_buffer_members {
>   void* p;
>   void(*fp)();
> };
> 
> union function_buffer {
>   function_buffer_members members;
>   char data[sizeof(function_buffer_members)];
> };
> 
> struct function_base {
>   mutable function_buffer functor;
> };
> 
> struct function : function_base {
>   void func(const function& f) {
> this->functor = f.functor;
>   }
> };
> 
> So it should only be necessary to put __attribute__((may_alias)) on union
> function_buffer, right? That doesn't fix the problem though.

Yes, it seems, the __attribute__((may_alias)) does not propagate from
structure members to enclosing structure:

If B has the may_alias, but it is a member of C
then the test case fails again:

inline void* operator new(__SIZE_TYPE__, void *p) { return p; }
struct A { A (float x) : f (x) {} float f; };
struct B
{
  int x;
  union U
  {
int a;
char b[sizeof (float)];
  } u;
  int y;
} __attribute__((may_alias));

struct C
{
  struct B b;
};

__attribute__((noinline, noclone)) void
bar (B , B )
{
  if (x.x != 0 || x.y != 3 || y.x != 0 || y.y != 3)
__builtin_abort ();
  float f;
  __builtin_memcpy (, x.u.b, sizeof (float));
  if (f != 3.5f)
__builtin_abort ();
  __builtin_memcpy (, y.u.b, sizeof (float));
  if (f != 3.5f)
__builtin_abort ();
}

__attribute__((noinline, noclone))
C *
baz (C )
{
  return 
}

__attribute__((noinline, noclone)) void
foo (float x)
{
  C b { 0, {}, 3 }, c;
  C *p = baz (b);
  new (b.b.u.b) A (x);
  c.b = p->b;
  bar (p->b, c.b);
}

int
main ()
{
  foo (3.5f);
}

[Bug c++/80179] New: ICE initializing a static local object with flexible array member in verify_ctor_sanity, at cp/constexpr.c:2641

[msebor at gcc dot gnu.org]

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

Bug ID: 80179
   Summary: ICE initializing a static local object with flexible
array member in verify_ctor_sanity, at
cp/constexpr.c:2641
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Prior to r231665 the test case below (reduced from the one for bug 69912
(flexary15.C) was rejected with the error:

t.C: In function ‘void bar(const char*)’:
t.C:8:38: error: too many initializers for ‘const char* [0]’
   static const S t = { 1, { a, "b" } };
  ^

With r231665, GCC fails with an ICE:

$ cat y.C && gcc -S -Wall -Wextra -Wpedantic y.C
struct S {
  int n;
  const char *a[];
};

void bar (const char *a)
{
  static const S t = { 1, { a, "b" } };
}

y.C:3:17: warning: ISO C++ forbids flexible array member ‘a’ [-Wpedantic]
   const char *a[];
 ^
y.C: In function ‘void bar(const char*)’:
y.C:8:38: warning: initialization of a flexible array member [-Wpedantic]
   static const S t = { 1, { a, "b" } };
  ^
y.C:8:38: internal compiler error: in verify_ctor_sanity, at
cp/constexpr.c:2641
0xaa9e05 verify_ctor_sanity
/src/gcc/git/gcc/cp/constexpr.c:2640
0xaaa042 cxx_eval_bare_aggregate
/src/gcc/git/gcc/cp/constexpr.c:2670
0xab12e0 cxx_eval_constant_expression
/src/gcc/git/gcc/cp/constexpr.c:4346
0xaaa190 cxx_eval_bare_aggregate
/src/gcc/git/gcc/cp/constexpr.c:2688
0xab12e0 cxx_eval_constant_expression
/src/gcc/git/gcc/cp/constexpr.c:4346
0xab275e cxx_eval_outermost_constant_expr
/src/gcc/git/gcc/cp/constexpr.c:4634
0xab3832 maybe_constant_init(tree_node*, tree_node*)
/src/gcc/git/gcc/cp/constexpr.c:4956
0x8b3e82 store_init_value(tree_node*, tree_node*, vec**, int)
/src/gcc/git/gcc/cp/typeck2.c:825
0x7f4aad check_initializer
/src/gcc/git/gcc/cp/decl.c:6365
0x7f808c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/src/gcc/git/gcc/cp/decl.c:7037
0x942597 cp_parser_init_declarator
/src/gcc/git/gcc/cp/parser.c:19384
0x9366d8 cp_parser_simple_declaration
/src/gcc/git/gcc/cp/parser.c:12781
0x936250 cp_parser_block_declaration
/src/gcc/git/gcc/cp/parser.c:12599
0x9356ce cp_parser_declaration_statement
/src/gcc/git/gcc/cp/parser.c:12208
0x931e5c cp_parser_statement
/src/gcc/git/gcc/cp/parser.c:10695
0x932a71 cp_parser_statement_seq_opt
/src/gcc/git/gcc/cp/parser.c:11027
0x93296e cp_parser_compound_statement
/src/gcc/git/gcc/cp/parser.c:10981
0x946555 cp_parser_function_body
/src/gcc/git/gcc/cp/parser.c:21430
0x94671c cp_parser_ctor_initializer_opt_and_function_body
/src/gcc/git/gcc/cp/parser.c:21466
0x94fabf cp_parser_function_definition_after_declarator
/src/gcc/git/gcc/cp/parser.c:26254
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/79904] ICE in annotate_constant_pool_refs, at config/s390/s390.c:7909

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 24 21:43:08 2017
New Revision: 246468

URL: https://gcc.gnu.org/viewcvs?rev=246468=gcc=rev
Log:
PR sanitizer/79904
* gcc.dg/ubsan/pr79904-2.c: Add -Wno-psabi to dg-options.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ubsan/pr79904-2.c

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[redi at gcc dot gnu.org]

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

--- Comment #45 from Jonathan Wakely  ---
(In reply to rguent...@suse.de from comment #32)
> So you need to place may-alias at a point to make the following
> stmt safe:
> 
> >   c = *p;
> 
> which means placing it on B, not only on the union (p is a B).
> 
> Thus do
> 
> struct B
> {
>   int x;
>   union U
> {
>   int a;
>   char b[sizeof (float)];
> } u;
>   int y;
> } __attribute__((may_alias));

In the real code there is no B, there is just the union, and it is assigned
directly, so it's more like:

union function_buffer_members {
  void* p;
  void(*fp)();
};

union function_buffer {
  function_buffer_members members;
  char data[sizeof(function_buffer_members)];
};

struct function_base {
  mutable function_buffer functor;
};

struct function : function_base {
  void func(const function& f) {
this->functor = f.functor;
  }
};

So it should only be necessary to put __attribute__((may_alias)) on union
function_buffer, right? That doesn't fix the problem though.

[Bug translation/80055] do not mark internal compiler error messages for i18n

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
(In reply to Frederic Marchal from comment #2)
> I suggest instead that internal messages be identified as such. Some other
> messages begin with "Internal error". I would favor that solution for
> messages not meant to the end user.

Would this prefix be for the benefit of the user, or for translator?  (or
both?)

I believe that everywhere we're using internal_error, the diagnostics machinery
will add "internal compiler error: " as a prefix when the message is emitted to
the user, and I believe this prefix is translated.

[Bug debug/51358] incorrect/missing location for function arg, -O0, without VTA

[woodard at redhat dot com]

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

--- Comment #13 from Ben Woodard  ---
This adds some additional complexity to a feature request in
https://sourceware.org/bugzilla/show_bug.cgi?id=19949. It would be helpful it
were resolved.

[Bug c++/80176] [5/6/7 Regression] cannot bind reference to static member function using object access expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-24
 CC||msebor at gcc dot gnu.org
  Known to work||4.3.0
 Ever confirmed|0   |1
  Known to fail||4.4.3, 4.5.3, 4.8.3, 4.9.3,
   ||5.3.0, 6.2.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection suggests r143446 in GCC 4.4.0 as the breaking change.

[Bug c/41809] escaping address of packed field should trigger warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #6 from Martin Sebor  ---
*** Bug 54032 has been marked as a duplicate of this bug. ***

[Bug c/54032] The C compiler does not warn about casts to more aligned types

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Martin Sebor  ---
Agreed, thanks.

Note that GCC does not warn on this code on STRICT_ALIGNMENT targets (such as
arm-linux-gnueabi.)

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

[Bug sanitizer/80168] [5/6/7 Regression] ICE in make_decl_rtl, at varasm.c:1311 w/ VLA and -fsanitize=address

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|accepts-invalid |

--- Comment #5 from Martin Sebor  ---
Just a small clarification: The VLA typedef in the test case is valid, but its
use to define a member of a struct is strictly not conforming.  It's accepted
by GCC as an extension and diagnosed by -Wpedantic.  I've adjusted the Keywords
accordingly.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[jason at gcc dot gnu.org]

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

--- Comment #44 from Jason Merrill  ---
Created attachment 41048
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41048=edit
trial patch

Does this fix the issue?  I don't have an ARM setup handy for testing.

[Bug target/80102] [7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/80102] [7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
Summary|ICE in  |[7 Regression] ICE in
   |maybe_record_trace_start,   |maybe_record_trace_start,
   |at dwarf2cfi.c:2330 |at dwarf2cfi.c:2330

--- Comment #2 from Jakub Jelinek  ---
Started with r239866.

[Bug ipa/79776] [7 Regression] ICE on valid code in insert_vi_for_tree, at tree-ssa-structalias.c:2807

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  ---
The second time insert_vi_for_tree is called on the same decl, it is
from is from associate_varinfo_to_alias (itself called from
call_for_symbol_thunks_and_aliases), which is looking at a
(speculatively) inlined thunk:

  (gdb) p node->thunk.thunk_p
  $26 = true
  (gdb) p node->global.inlined_to 
  $27 = 
  (gdb) p node->callers->speculative
  $30 = 1  

While I feel sympathetic for any user of
call_for_symbol_thunks_and_aliases which does not expect to be handed
such a beast, I am not sure if they can ignore it.  The problem is
that this inlining apparently has not been performed on the gimple
level yet and so looking at caller's body will not give you the
correct idea about the situation.  invoking "call debug_function(
node->callers->caller->decl, 0)" in gdb confirms this but I do not
want to be pasting this here.  Moreover, there is already no edge from
the thunk caller to the original callee, so anybody ignoring the
inlined thunk is going to miss that "call" altogether.

So I'd lean against changing call_for_symbol_thunks_and_aliases.
OTOH, if I understand associate_varinfo_to_alias well, I think that
ignoring nodes with node->global.inlined_to set there seems like a
reasonable (though untested) fix:

diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index c043e5ec3a6..06be189e1d1 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -7616,7 +7616,8 @@ static bool
 associate_varinfo_to_alias (struct cgraph_node *node, void *data)
 {
   if ((node->alias || node->thunk.thunk_p)
-  && node->analyzed)
+  && node->analyzed
+  && !node->global.inlined_to)
 insert_vi_for_tree (node->decl, (varinfo_t)data);
   return false;
 }

[Bug c++/66639] declare __func__ , __FUNCTION__ & __PRETTY_FUNCTION__ as constexpr

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2017-03-24
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #9 from Martin Sebor  ---
In my mind this request morphed into one for some way to get the value of the
three symbols in constexpr contexts, which is what the patch committed in
r235845 does (actually it makes it possible for just the first two symbols).

But you're right, in hindsight, as the more comprehensive test case below
shows, the implemented solution doesn't really resolve the request for __func__
et al. being declared constexpr regardless of the context.  Let me reopen it.

$ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C
constexpr int foo ()
{
  static_assert (0 == __builtin_strcmp (__func__, "foo"), "#1");
  static_assert (0 == __builtin_strcmp (__FUNCTION__, "foo"), "#2");
  static_assert (0 == __builtin_strcmp (__PRETTY_FUNCTION__, "constexpr int
foo()"), "#3");

  return 1;
}

static_assert (foo (), "#4");

void bar ()
{
  static_assert (0 == __builtin_strcmp (__func__, "bar"), "#5");
  static_assert (0 == __builtin_strcmp (__FUNCTION__, "bar"), "#6");
  static_assert (0 == __builtin_strcmp (__PRETTY_FUNCTION__, "void bar()"),
"#7");
}

t.C: In function ‘void bar()’:
t.C:14:3: error: non-constant condition for static assertion
   static_assert (0 == __builtin_strcmp (__func__, "bar"), "#5");
   ^
t.C:14:40: error: ‘__builtin_strcmp(((const char*)(& __func__)), ((const
char*)"bar"))’ is not a constant expression
   static_assert (0 == __builtin_strcmp (__func__, "bar"), "#5");
   ~^
t.C:15:3: error: non-constant condition for static assertion
   static_assert (0 == __builtin_strcmp (__FUNCTION__, "bar"), "#6");
   ^
t.C:15:40: error: ‘__builtin_strcmp(((const char*)(& __FUNCTION__)), ((const
char*)"bar"))’ is not a constant expression
   static_assert (0 == __builtin_strcmp (__FUNCTION__, "bar"), "#6");
   ~^
t.C:16:3: error: non-constant condition for static assertion
   static_assert (0 == __builtin_strcmp (__PRETTY_FUNCTION__, "void bar()"),
"#7");
   ^
t.C:16:40: error: ‘__builtin_strcmp(((const char*)(& __PRETTY_FUNCTION__)),
((const char*)"void bar()"))’ is not a constant expression
   static_assert (0 == __builtin_strcmp (__PRETTY_FUNCTION__, "void bar()"),
"#7");
   ~^~~

[Bug middle-end/80161] const argument hidden from AVX intrinsics due to OpenMP outlining

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Jeff Hammond from comment #5)
> Thanks for the comments.  Indeed, I made all the changes to the containing
> project to compile in C++ and the problem went away.  I will likely just
> switch to the preprocessor solution for now.

Or you could use enum { scale = 1 }; instead of const int scale = 1;
That ought to work with both C and C++.

> For posterity, I found that Clang has the same issue, whereas ICC (Intel)
> does not.
> 
> Feel free to close this as WONTFIX/INVALID unless you think it should remain
> open to motivate the OpenMP IPA changes in GCC 8+.

Yeah, I'd keep this open for GCC 8+, we do want to implement the IPA changes
there.

[Bug c++/66477] [constexpr] accepts-invalid with constexpr member call on non-constant reference

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #2 from TC  ---
Seems to have something to do with reference-type parameters.

  struct a { constexpr int size() const { return 3; } };
  constexpr bool g(a&) { return true;}
  void f(a ) { 
static_assert(r.size() == 3, "error"); // accepted
static_assert(g(r), "");   // likewise
a& rr = r;
static_assert(g(rr), "");  // rejected
static_assert(rr.size()==3, "");   // likewise
  }

[Bug middle-end/80161] const argument hidden from AVX intrinsics due to OpenMP outlining

[jeff.science at gmail dot com]

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

--- Comment #5 from Jeff Hammond  ---
Thanks for the comments.  Indeed, I made all the changes to the containing
project to compile in C++ and the problem went away.  I will likely just switch
to the preprocessor solution for now.

For posterity, I found that Clang has the same issue, whereas ICC (Intel) does
not.

Feel free to close this as WONTFIX/INVALID unless you think it should remain
open to motivate the OpenMP IPA changes in GCC 8+.

[Bug preprocessor/78569] "internal compiler error: in get_substring_ranges_for_loc" processing sprintf buffer overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #8 from Martin Sebor  ---
*** Bug 78836 has been marked as a duplicate of this bug. ***

[Bug preprocessor/78836] ICE in get_source_location_for_substring, at input.c:1461

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Martin Sebor  ---
The ICE went away shortly after I opened this report, after I made further
changes to my code.  I've been meaning to resolve this bug a few times but for
some reason could never find it.  Let me do that now.  The stack trace in bug
78569 looks pretty close so I'll make it a dupe of it.  Thanks for the ping!

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

[Bug target/80148] [7 Regression] operand has impossible constraints

[vmakarov at gcc dot gnu.org]

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

--- Comment #6 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Mar 24 18:47:38 2017
New Revision: 246467

URL: https://gcc.gnu.org/viewcvs?rev=246467=gcc=rev
Log:
2017-03-24  Vladimir Makarov  

PR target/80148
* lra-assigns.c (assign_by_spills): Add spilled non-reload pseudos
to consider in curr_insn_transform.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c

[Bug c++/78308] Hiding of member function templates introduced by using-decl

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
A rejects-valid case:

struct C {
template void f();
};

struct D : C {
template void f();
using C::f;
};

int main(){
D().f<0>();
}

GCC rejects as ambiguous, Clang accepts as it only considers the template
one.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[bernd.edlinger at hotmail dot de]

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

--- Comment #43 from Bernd Edlinger  ---
Would something like this also work?

  union function_buffer
  {
[...]
mutable char data;

function_buffer() {}
function_buffer(const function_buffer )
{
   __builtin_memcpy(this, , sizeof(*this));
}
function_buffer& operator = (const function_buffer )
{
   __builtin_memcpy(this, , sizeof(*this));
   return *this;
}
  };

[Bug tree-optimization/32306] [5/6/7 Regression] redundant && || not eliminated

[jakub at gcc dot gnu.org]

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

--- Comment #34 from Jakub Jelinek  ---
So, could we in SCCVN recognize similarly to maybe_optimize_range_tests
inter-bb && and || tests at the end stored through PHI into an SSA_NAME without
side-effects in between and handle it (hash it and compare) as if it was
actually using && or || (or & and | ?)?

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[meissner at linux dot vnet.ibm.com]

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

--- Comment #19 from Michael Meissner  ---
On Tue, Mar 21, 2017 at 09:00:37PM +, brenohl at br dot ibm.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543
> 
> --- Comment #16 from Breno Leitao  ---
> If it helps, the problem is reproducible on some other packages as well. Here
> is another example:
> 
> https://nopaste.linux-dev.org/?1122124

Note, the source is not complete.  Please attach the file as a text file to
this bug report.

[Bug c++/80178] New: Class with implicitly deleted copy and move constructors usees wrong argument passing ABI

[redi at gcc dot gnu.org]

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

Bug ID: 80178
   Summary: Class with implicitly deleted copy and move
constructors usees wrong argument passing ABI
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Keywords: ABI
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

We pass this in a register, but I think the ABI says it should be an invisible
reference, because both the copy ctor and move ctor are deleted.

struct A {
  A();
  A =(A &);
  void *p;
};
void foo(A);
void bar() {
  foo({});
}

In this example they're implicitly defined as deleted because of the
user-provided move assignment operator, but the result is the same whether
implicitly or explicitly deleted.

EDG passes this by invisible reference. Clang passes by value, but that's
acknowledged to be a bug.

[Bug c++/80177] New: wrong fixit hint for misspelled static_assert: __cpp_static_assert

[msebor at gcc dot gnu.org]

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

Bug ID: 80177
   Summary: wrong fixit hint for misspelled static_assert:
__cpp_static_assert
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In the ill-formed test case below GCC suggests to replace the misspelled
static_assert with the __cpp_static_assert feature test macro rather than with
the static_assert keyword.  Using the feature test macro here would be
incorrect  to the hint should suggest the latter.

(I wonder if there is a way to have the  algorithm prefer non-reserved names
over reserved ones.  Also, it would be nice, though I suspect difficult, if the
algorithm could prefer names with the right type.  E.g., prefer a function over
a literal where a the misspelled name looks like it's being used as a
function.)

$ cat a.C && gcc -S -Wall -Wextra -Wpedantic a.C
void f ()
{
  static_assertion (1 == 0, "1 == 0");
}
a.C: In function ‘void f()’:
a.C:3:3: error: ‘static_assertion’ was not declared in this scope
   static_assertion (1 == 0, "1 == 0");
   ^~~~
a.C:3:3: note: suggested alternative: ‘__cpp_static_assert’
   static_assertion (1 == 0, "1 == 0");
   ^~~~
   __cpp_static_assert

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[redi at gcc dot gnu.org]

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

--- Comment #42 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #14)
> Seems to be
> 
> void move_assign(function10& f)
> {
>   if ( == this)
> return;
> 
>   { try {
> if (!f.empty()) {
>   this->vtable = f.vtable;
>   if (this->has_trivial_copy_and_destroy())
> this->functor = f.functor;
> ^^^
> 
> for the aggregate copy but lineno info looks confused for the aliasing store.

Changing this aggregate copy to:

__builtin_memcpy(>functor, , sizeof(f.functor));

fixes the crash on armv7hl.

No amount of may_alias attributes on the definition of the union
detail::function::function_buffer type helped.

[Bug c/78732] Wrong description for Wendif-labels

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-24
 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Correct: warn_endif_labels is used by:
  libcpp/directives.c: do_else
  libcpp/directives.c: do_endif
which they use it to guard calls to check_eol_endif_labels.

It's not used by do_elif.

doc/cppwarnopts.texi gets this right:

> Do not warn whenever an @code{#else} or an @code{#endif} are followed by text.
> This sometimes happens in older programs with code of the form

[Bug preprocessor/78836] ICE in get_source_location_for_substring, at input.c:1461

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Are you still seeing these issues?

Possibly a dup of one (or more) of:
  PR preprocessor/79210
  PR preprocessor/78811
  PR preprocessor/78569

[Bug fortran/80174] [meta-bug] Fortran lto issues

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-24
 Ever confirmed|0   |1

[Bug tree-optimization/80153] ivopt generate wrong code

[amker at gcc dot gnu.org]

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

--- Comment #7 from amker at gcc dot gnu.org ---
Case gcc.dg/tree-ssa/reassoc-19 failed, the ivopt dump before change is:

   [15.00%]:
  goto ; [100.00%]

   [85.00%]:
  _1 = (sizetype) element_8(D);
  _2 = -_1;
  _12 = (unsigned long) element_8(D);
  _11 = -_12;
  _13 = rite_3 + _11;
  rite_9 = _13;
  bar (left_7(D), rite_9, element_8(D));

   [100.00%]:
  # rite_3 = PHI 
  if (rite_3 >= left_7(D))
goto ; [85.00%]
  else
goto ; [15.00%]

   [15.00%]:
  return;

But changed to below after change:
   [15.00%]:
  goto ; [100.00%]

   [85.00%]:
  _1 = (sizetype) element_8(D);
  _2 = -_1;
  _12 = (unsigned long) rite_3;
  _11 = (unsigned long) element_8(D);
  _13 = _12 - _11;
  _14 = (char *) _13;
  rite_9 = _14;
  bar (left_7(D), rite_9, element_8(D));

   [100.00%]:
  # rite_3 = PHI 
  if (rite_3 >= left_7(D))
goto ; [85.00%]
  else
goto ; [15.00%]

   [15.00%]:
  return;

I  don't think this is real regression here, assembly code is the same.  The
additional type conversion is introduced by get_computation_aff.  Though we
have 
utype: char *
ctype: char *
var->typed.type: char *
The function still computes the expression in uutype:
  uutype = unsigned_type_for (utype);
which is unsigned long here.

Actually, given the computation sequence:

  if (common_type != uutype)
aff_combination_convert (aff, uutype);

  aff_combination_scale (_aff, rat);
  aff_combination_add (aff, _aff);

I think type conversion is needed.  Of course, get_computation_aff should not
introduce unnecessary uutype conversion.

[Bug c/54032] The C compiler does not warn about casts to more aligned types

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
This could probably also be marked as a duplicate of bug 41809 (like bug 79918
was) since that one is older and it looks like the same issue.

[Bug c++/80176] New: [5/6/7 Regression] cannot bind reference to static member function using object access expression

[redi at gcc dot gnu.org]

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

Bug ID: 80176
   Summary: [5/6/7 Regression] cannot bind reference to static
member function using object access expression
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: tkoeppe at google dot com
  Target Milestone: ---

struct X { static void foo(); } x;
void ()() = x.foo;

f.cc:2:17: error: invalid initialization of non-const reference of type ‘void
(&)()’ from an rvalue of type ‘void()’
 void ()() = x.foo;
   ~~^~~

This was accepted by 4.3, but rejected since 4.4.0

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[jason at gcc dot gnu.org]

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

--- Comment #41 from Jason Merrill  ---
(In reply to Richard Biener from comment #38)
> Simplified testcase for discussion (is not "miscompiled"):
> 
> struct S {
>   union { int i; } u;
> };
> 
> int main()
> {
>   S s;
>   new () float (2.0);
>   S q = s;
>   if (*reinterpret_cast() != 2.0)
> abort ();
> }
> 
> so you say q = s is valid because the object representation of the union
> is copied.  I say after storing 2.0 to s.u.i the access 's' in q = s is
> invalid as you are accessing the stored value (a float) via a glvalue of
> inappropriate type.

I say what's wrong with this testcase is that storing a float in an int field
is undefined.

[Bug target/80175] New: rs6000 target should have a strlensi pattern that works for recent powerpc processors

[acsawdey at gcc dot gnu.org]

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

Bug ID: 80175
   Summary: rs6000 target should have a strlensi pattern that
works for recent powerpc processors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: acsawdey at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64*-*-*

The existing define_expand for strlensi uses dlmzb which is only on the
405/440/464/476 processors. It would be nice to generate a reasonable inline
sequence to do strlen on recent processors, maybe power7 and up.

[Bug c/41809] escaping address of packed field should trigger warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||meisenmann.lba@fh-salzburg.
   ||ac.at

--- Comment #5 from Martin Sebor  ---
*** Bug 79918 has been marked as a duplicate of this bug. ***

[Bug c/79918] Feature request: Warning about (may potential) misaligned address-reference

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Yes, it does look like a request for the same feature.  I think it can be
resolved as a duplicate of it.  Thanks.

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

[Bug sanitizer/80168] [5/6/7 Regression] ICE in make_decl_rtl, at varasm.c:1311 w/ VLA and -fsanitize=address

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  Various comments e.g. in get_bit_range assert that
DECL_BIT_FIELD_REPRESENTATIVE in a VLA structure is guaranteed by construction
to have the same DECL_FIELD_OFFSET, so even when during low gimple they are not
the same, we should be able to use the 3rd COMPONENT_REF arguments from the
original field and the DECL_FIELD_BIT_OFFSET difference should give the actual
start differences between the field and its representative.

[Bug sanitizer/80168] [5/6/7 Regression] ICE in make_decl_rtl, at varasm.c:1311 w/ VLA and -fsanitize=address

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #1)
> I'm not sure this is valid given 'a' is global.

It is valid, VLA size is just an integral expression, and a is a valid
expression.  The size is computed at the point where the VLA is declared (we
remember there the size in some temporary if we need it later).

[Bug libstdc++/80172] Segfault when using a constructed intializer list of tuple(int, variant) created through template pack expansion

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I don't think this is valid code, that's not how std::initializer_list works.
It's not a magic array that owns its contents, it's just a pointer to some
external array and a length. In your functions the array is a local variable
inside the function, and you return a dangling initializer_list object that
refers to the local array.

If you return std::array it works fine.

[Bug sanitizer/80168] [5/6/7 Regression] ICE in make_decl_rtl, at varasm.c:1311 w/ VLA and -fsanitize=address

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-24
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r202949.

[Bug fortran/80174] New: [meta-bug] Fortran lto issues

[tkoenig at gcc dot gnu.org]

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

Bug ID: 80174
   Summary: [meta-bug] Fortran lto issues
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

A meta-bug to collect Fortran and libfortran LTO issues.

[Bug c++/66639] declare __func__ , __FUNCTION__ & __PRETTY_FUNCTION__ as constexpr

[dragondreamer at live dot com]

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

D  changed:

   What|Removed |Added

 CC||dragondreamer at live dot com

--- Comment #8 from D  ---
This bug is not still yet for __PRETTY_FUNCTION__. The sample code below does
not compile even with GCC 7 (however, works fine in Clang).

//

constexpr bool str_equal(const char* s1, const char* s2) noexcept
{
   return !*s1 && !*s2 ? true
: !*s1 ? false
: !*s2 ? false
: *s1 == *s2 ? str_equal(s1 + 1, s2 + 1)
: false;
}

int main()
{
static_assert(str_equal(__PRETTY_FUNCTION__, "int main()"), "test");
}


//



: In function 'int main()':
:12:5: error: non-constant condition for static assertion
 static_assert(str_equal(__PRETTY_FUNCTION__, "int main()"), "test");
 ^
:12:28:   in constexpr expansion of 'str_equal(((const char*)(&
__PRETTY_FUNCTION__)), ((const char*)"int main()"))'
:12:5: error: the value of '__PRETTY_FUNCTION__' is not usable in a
constant expression
:12:29: note: '__PRETTY_FUNCTION__' was not declared 'constexpr'
 static_assert(str_equal(__PRETTY_FUNCTION__, "int main()"), "test");
 ^~~
Compiler exited with result code 1

[Bug libstdc++/80165] Constexpr tuple of variant doesn't work

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-24
 CC||trippels at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Ville said on IRC that this issue unfortunately cannot be fix for gcc-7.
It will have to wait 'till gcc-8.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle  ---
Another issue:

In the case with file I/O if the child procedure consumes the EOR character,
upon return, the parent is also wanting to complete the EOR the check for EOR
and hits EOF.

Lets see what I get from c.l.f

[Bug sanitizer/80166] SANITIZER_INTERCEPT_GETGROUPS modifies list when size is 0 Out-of-bounds write

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

URL||https://reviews.llvm.org/D3
   ||1332

--- Comment #3 from Martin Liška  ---
Just created LLVM review for that.

[Bug rtl-optimization/80112] [5/6 Regression] ICE in doloop_condition_get at loop-doloop.c:158

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE in   |[5/6 Regression] ICE in
   |doloop_condition_get at |doloop_condition_get at
   |loop-doloop.c:158   |loop-doloop.c:158

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/77339] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: in cp_parser_type_name, at cp/parser.c:16532

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Mar 24 14:40:13 2017
New Revision: 246462

URL: https://gcc.gnu.org/viewcvs?rev=246462=gcc=rev
Log:
PR c++/77339 - ICE with invalid use of alias template.

* pt.c (lookup_template_class_1): Don't try to enter the scope of an
alias template.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-58.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[bernd.edlinger at hotmail dot de]

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

--- Comment #40 from Bernd Edlinger  ---
Yikes, I need an assignement operator:

  B(const B )
  {
__builtin_memcpy(this, , sizeof(B));
  }
  B& operator = (const B )
  {
 __builtin_memcpy(this, , sizeof(B));
 return *this;
  }

now it seems to work...

[Bug tree-optimization/80171] [5/6/7 Regression] ICE (Segmentation fault) with optimization

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
Created attachment 41046
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41046=edit
Somewhat reduced testcase

I've attached a testcase that is accepted by clang. GCC ICEs without
-fpermissive.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[bernd.edlinger at hotmail dot de]

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

--- Comment #39 from Bernd Edlinger  ---
one thing I do not understand is this:

if I do this in Jakub's test case:

  new (b.u.b) A (x);
  //c = *p;
  __builtin_memcpy(, p, sizeof(B));
  bar (*p, c);

the mis-compilation goes away,
if I add this to Jakub's test case:

struct B
{
  int x;
  union U
  {
int a;
char b[sizeof (float)];
  } u;
  int y;
  B() {}
  B(int xx, U uu, int yy):x(xx), u(uu), y(yy) {}
  B(B )
  {
__asm("":::"memory");
__builtin_memcpy(this, , sizeof(B));
__asm("":::"memory");
  }
};

The mis-compilation gets not fixed.
Why?

[Bug c++/80119] [6/7 Regression] -Wmaybe-uninitialized wrongly flags the body of a short-circuited if-clause

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/80119] [6/7 Regression] -Wmaybe-uninitialized wrongly flags the body of a short-circuited if-clause

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Fri Mar 24 14:22:01 2017
New Revision: 246461

URL: https://gcc.gnu.org/viewcvs?rev=246461=gcc=rev
Log:
PR c++/80119
* cp-gimplify.c (cp_fold): Strip CLEANUP_POINT_EXPR if the expression
doesn't have side effects.

* g++.dg/warn/Wuninitialized-9.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wuninitialized-9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c/79918] Feature request: Warning about (may potential) misaligned address-reference

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
Is this the same as the issue in bug 41809?

[Bug rtl-optimization/80173] New: ICE in store_bit_field_1, at expmed.c:787

[aivchenk at gmail dot com]

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

Bug ID: 80173
   Summary: ICE in store_bit_field_1, at expmed.c:787
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aivchenk at gmail dot com
  Target Milestone: ---

> cat ../struct_asm.c 
/* { dg-do compile } */

typedef int v8 __attribute__ ((vector_size(8)));

struct U {
  v8 a;
  v8 b;
};

int
foo (int i)
{
  register struct U u asm ("xmm0") = {{-1, 0}, {-1, 0}};
  return u.b[i];
}
> gcc ../struct_asm.c   
>
../struct_asm.c: In function ‘foo’:
../struct_asm.c:13:21: internal compiler error: in store_bit_field_1, at
expmed.c:787
   register struct U u asm ("xmm0") = {{-1, 0}, {-1, 0}};

[Bug middle-end/80023] missing diagnostic on aligned_alloc with invalid alignment

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #1 from Eric Gallager  ---
I would like to see this diagnostic please; "confirmed"

[Bug target/79904] ICE in annotate_constant_pool_refs, at config/s390/s390.c:7909

[krebbel at gcc dot gnu.org]

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

--- Comment #7 from Andreas Krebbel  ---
Author: krebbel
Date: Fri Mar 24 13:52:30 2017
New Revision: 246443

URL: https://gcc.gnu.org/viewcvs?rev=246443=gcc=rev
Log:
S/390: PR79904: Disallow reg + sym_ref literal pool addresses.

We accept reg + sym_ref as valid address if sym_ref is a literal pool
reference knowing that it will be rewritten as r13 + reg + offset.
However, annotate_constant_pool_refs was never able to handle that.

With the patch only single sym_refs are accepted.

Regression tested on s390x.

2017-03-24  Andreas Krebbel  

PR target/79904
* config/s390/s390.c (s390_decompose_address): Reject reg +
sym_ref literal pool references.

gcc/testsuite/ChangeLog:

2017-03-24  Andreas Krebbel  

* gcc.dg/ubsan/pr79904-2.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/ubsan/pr79904-2.c
Modified:
trunk/gcc/config/s390/s390.c
trunk/gcc/testsuite/ChangeLog

[Bug target/79893] ICE in s390_adjust_builtin_arglist in gcc/config/s390/s390-c.c:679

[krebbel at gcc dot gnu.org]

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

--- Comment #4 from Andreas Krebbel  ---
Author: krebbel
Date: Fri Mar 24 13:51:32 2017
New Revision: 246442

URL: https://gcc.gnu.org/viewcvs?rev=246442=gcc=rev
Log:
S/390: PR79893: Add diagnostics vec_load_bndry builtin.

The boundary argument of the vec_load_bndry builtin needs to be
rewritten.  At that point it must be constant already.  The current
diagnostics in s390_expand_builtins is too late for this.  The patch
adds an additional check for that builtin which will be triggered
already during preprocessing.

Regression tested on s390x.

gcc/testsuite/ChangeLog:

2017-03-24  Andreas Krebbel  

PR target/79893
* gcc.target/s390/zvector/pr79893.c: New test.

gcc/ChangeLog:

2017-03-24  Andreas Krebbel  

PR target/79893
* config/s390/s390-c.c (s390_adjust_builtin_arglist): Issue an
error if the boundary argument is not constant.


Added:
trunk/gcc/testsuite/gcc.target/s390/zvector/pr79893.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390-c.c
trunk/gcc/testsuite/ChangeLog

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[rguenth at gcc dot gnu.org]

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

--- Comment #38 from Richard Biener  ---
Simplified testcase for discussion (is not "miscompiled"):

struct S {
  union { int i; } u;
};

int main()
{
  S s;
  new () float (2.0);
  S q = s;
  if (*reinterpret_cast() != 2.0)
abort ();
}

so you say q = s is valid because the object representation of the union
is copied.  I say after storing 2.0 to s.u.i the access 's' in q = s is
invalid as you are accessing the stored value (a float) via a glvalue of
inappropriate type.

[Bug rtl-optimization/80112] [5/6/7 Regression] ICE in doloop_condition_get at loop-doloop.c:158

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 24 13:37:01 2017
New Revision: 246441

URL: https://gcc.gnu.org/viewcvs?rev=246441=gcc=rev
Log:
PR rtl-optimization/80112
* loop-doloop.c (doloop_condition_get): Don't check condition
if cmp isn't SET with IF_THEN_ELSE src.

* gcc.dg/pr80112.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr80112.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/loop-doloop.c
trunk/gcc/testsuite/ChangeLog

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[rguenther at suse dot de]

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

--- Comment #37 from rguenther at suse dot de  ---
On Fri, 24 Mar 2017, jason at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
> 
> --- Comment #36 from Jason Merrill  ---
> (In reply to Richard Biener from comment #34)
> > C++14 12.8/16 says
> > 
> > "The implicitly-defined copy/move constructor for a union X copies the
> > object representation (3.9) of X."
> > 
> > 3.9/4 says
> > 
> > "The object representation of an object of type T is the sequence of N
> > unsigned char objects...  For trivially copyable types, the value
> > representation is a set of bits in the object representation that determines
> > a value,..."
> > 
> > this suggests that the copying should work but the C++ FE may not simply
> > elide the copy construction by emitting
> > 
> >   c = *p;
> > 
> > because that does _not_ implement memcpy semantics for the union member.
> 
> Nothing in the standard makes memcpy magic; 3.9/3 says,
> 
> For any trivially copyable type T, if two pointers to T point to distinct T
> objects obj1 and obj2, where neither obj1 nor obj2 is a base-class subobject,
> if the underlying bytes (4.4) making up obj1 are copied into obj2, obj2 shall
> subsequently hold the same value as obj1.
> 
> It just talks about copying the underlying bytes, not necessarily using memcpy
> to do so.  And a copy of a B is a memberwise copy, which implies copying the U
> member, which as you quote means copying the object representation, which is
> the underlying bytes.

Yes.  But then the act of copying, the

  c = *p;

stmt needs to still follow 3.10/10, *p is not a valid glvalue to access
the object live in p->u.b which is of type A.

[Bug ipa/79776] [7 Regression] ICE on valid code in insert_vi_for_tree, at tree-ssa-structalias.c:2807

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
First list of nodes with same decl bypassing

  /* Nodes without a body are not interesting.  Especially do not
 visit clones at this point for now - we get duplicate decls
 there for inline clones at least.  */
  if (!node->has_gimple_body_p () || node->global.inlined_to)
continue;

  if (node->ultimate_alias_target () != node)
continue;

_ZThn8_N1C2fnEPKciPi/3 (virtual E C::_ZThn8_N1C2fnEPKciPi(const char*, int,
int*)) @0x76a375c0
  Type: function definition analyzed
  Visibility: externally_visible public virtual artificial
  previous sharing asm name: 21
  Address is taken.
  Availability: available
  First run: 0
  Function flags: body
  Called by: 
  Calls: _ZN1C2fnEPKciPi/23 (inlined) (1.00 per call) (can throw external) 

_ZN1C2fnEPKciPi/1 (virtual E C::fn(const char*, int, int*)) @0x76a372e0
  Type: function definition analyzed
  Visibility: externally_visible public virtual
  previous sharing asm name: 32
  Address is taken.
  Availability: available
  First run: 0
  Function flags: body indirect_call_target
  Called by: 

where the latter is 'node' (the ultimate alias target).  The former is
only reached through another alias chain, originating from

_ZN1C2fnEPKciPi/1 (virtual E C::fn(const char*, int, int*)) @0x76a372e0
  Type: function definition analyzed
  Visibility: externally_visible public virtual
  previous sharing asm name: 32
  Address is taken.
  Referring: *.LTHUNK0/2 (alias)_ZTV1C/4 (addr)_ZThn8_N1C2fnEPKciPi/3 (addr)
  Availability: available
  First run: 0
  Function flags: body indirect_call_target
  Called by: 

so it somehow walks itself with call_for_symbol_thunks_and_aliases but also
the decl it uses is used for an unrelated thunks-and-aliases chain.

I'm lost (cgraph bug?!)

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[jason at gcc dot gnu.org]

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

--- Comment #36 from Jason Merrill  ---
(In reply to Richard Biener from comment #34)
> C++14 12.8/16 says
> 
> "The implicitly-defined copy/move constructor for a union X copies the
> object representation (3.9) of X."
> 
> 3.9/4 says
> 
> "The object representation of an object of type T is the sequence of N
> unsigned char objects...  For trivially copyable types, the value
> representation is a set of bits in the object representation that determines
> a value,..."
> 
> this suggests that the copying should work but the C++ FE may not simply
> elide the copy construction by emitting
> 
>   c = *p;
> 
> because that does _not_ implement memcpy semantics for the union member.

Nothing in the standard makes memcpy magic; 3.9/3 says,

For any trivially copyable type T, if two pointers to T point to distinct T
objects obj1 and obj2, where neither obj1 nor obj2 is a base-class subobject,
if the underlying bytes (4.4) making up obj1 are copied into obj2, obj2 shall
subsequently hold the same value as obj1.

It just talks about copying the underlying bytes, not necessarily using memcpy
to do so.  And a copy of a B is a memberwise copy, which implies copying the U
member, which as you quote means copying the object representation, which is
the underlying bytes.

[Bug target/80160] [7 regression] operand has impossible constraints

[arnd at linaro dot org]

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

--- Comment #6 from Arnd Bergmann  ---
I've run into a four other files in the kernel sources that show this bug. I've
confirmed that the patch in comment 4 addresses all of them.

[Bug middle-end/80163] ICE on hopefully valid code

[jakub at gcc dot gnu.org]

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

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

Untested patch to reject the sign-extension to int128.

[Bug libstdc++/80172] New: Segfault when using a constructed intializer list of tuple(int, variant) created through template pack expansion

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

Bug ID: 80172
   Summary: Segfault when using a constructed intializer list of
tuple(int, variant) created through template pack
expansion
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

Created attachment 41044
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41044=edit
example source code that triggers segfault

Hi gcc-team,

the attached source code compiles, but will terminate with a segfault when
executed.

> g++-7 -std=gnu++1z -Wall -Wextra 
> bug_gcc_tuple_of_variant_in_pack_expansion.cpp
> ./a.out
0. 4
1. 5
2. 1
A
N
-
0. A
1. N
2. -
zsh: segmentation fault (core dumped)  ./a.out

best regards
marehr

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
Author: rguenth
Date: Fri Mar 24 12:34:19 2017
New Revision: 246439

URL: https://gcc.gnu.org/viewcvs?rev=246439=gcc=rev
Log:
2017-03-24  Bill Schmidt  

PR tree-optimization/80158
* gimple-ssa-strength-reduction.c (replace_mult_candidate): When
replacing a candidate statement, also replace it for the
candidate's alternate interpretation.
(replace_rhs_if_not_dup): Likewise.
(replace_one_candidate): Likewise.

* gfortran.fortran-torture/compile/pr80158.f: New file.

Added:
trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr80158.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #18 from Richard Biener  ---
Fixed.

[Bug sanitizer/80166] SANITIZER_INTERCEPT_GETGROUPS modifies list when size is 0 Out-of-bounds write

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Another problem is that for a negative number, returned value is -1 (error).
And thus libsanitizer crashes:

==7910==ERROR: AddressSanitizer: negative-size-param: (size=-4)
#0 0x7ff25bcd6a00 in __interceptor_getgroups
(/usr/lib64/libasan.so.3+0x50a00)
#1 0x4009fb in main /home/marxin/Programming/testcases/pr80166.c:9
#2 0x7ff25b901540 in __libc_start_main (/lib64/libc.so.6+0x20540)
#3 0x400899 in _start
(/home/marxin/Programming/testcases/get_group+0x400899)

[Bug tree-optimization/80167] [6 Regression] ICE in translate_isl_ast_to_gimple::is_valid_rename at gcc/graphite-isl-ast-to-gimple.c:1139

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
  Known to work||7.0.1
Summary|[6/7 Regression] ICE in |[6 Regression] ICE in
   |translate_isl_ast_to_gimple |translate_isl_ast_to_gimple
   |::is_valid_rename at|::is_valid_rename at
   |gcc/graphite-isl-ast-to-gim |gcc/graphite-isl-ast-to-gim
   |ple.c:1139  |ple.c:1139

--- Comment #2 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/80167] [6 Regression] ICE in translate_isl_ast_to_gimple::is_valid_rename at gcc/graphite-isl-ast-to-gimple.c:1139

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Fri Mar 24 12:16:43 2017
New Revision: 246438

URL: https://gcc.gnu.org/viewcvs?rev=246438=gcc=rev
Log:
2017-03-24  Richard Biener  

PR tree-optimization/80167
* graphite-isl-ast-to-gimple.c
(translate_isl_ast_to_gimple::is_valid_rename): Handle default-defs
properly.
(translate_isl_ast_to_gimple::get_rename): Likewise.

* gcc.dg/graphite/pr80167.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr80167.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/80171] [5/6/7 Regression] ICE (Segmentation fault) with optimization

[D.Bahadir at GMX dot de]

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

--- Comment #6 from Deniz Bahadir  ---
(In reply to Richard Biener from comment #3)
> 
> Simple fix (further reduced testcase appreciated)

CReduce originally created a radically reduced test-case which however was no
valid C++ anymore. (My check script was not specific enough.) It always failed
and should probably become another bug-report.


Radically reduced invalid C++ test-case:


namespace mpl_
}
namespace boost namespace mpl using namespace mpl_
}
}
namespace mpl_ template  struct integral_c;
}
namespace boost template  struct mpl::integral_c {


However, I was able to adjust it slightly. (I am not sure if this is really
valid C++14 code.)


Radically reduced (valid?) C++ test-case:
-

namespace mpl_ {}
namespace boost { namespace mpl { using namespace mpl_; } }
namespace mpl_ { template  struct integral_c; }
namespace boost { template  struct mpl::integral_c {}; }


Both fail like this:


The error:
--

LANG=C /usr/bin/g++-6  -fpermissive -m64 -D_GLIBCXX_USE_CXX11_ABI=1 -std=c++14
-O0 -DNDEBUG -fPIC -c -w smalltestcase.i -o /dev/null
g++-6: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/80163] ICE on hopefully valid code

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #2)
> Clang rejects the test-case written in C:
> 
> clang pr80163.c  -c
> pr80163.c:9:25: error: initializer element is not a compile-time constant
>   static __int128_t d = (long) & - (long) &
> ^~~
> 1 error generated.
> 
> However accepts in C++:
> 
> clang++ pr80163.cpp  -c
> [no output]

We aren't talking about C++, that can construct those dynamically at runtime if
they aren't constructible at compile time.

[Bug tree-optimization/80171] [5/6/7 Regression] ICE (Segmentation fault) with optimization

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
(In reply to Deniz Bahadir from comment #4)
> Created attachment 41043 [details]
> Non-reduced test-case which fails with -O2 and -O3.

Thanks. This is good enough. I will try to reduce it further, but
this is a Boost testcase, so chances for a nice small testcase are low.

[Bug tree-optimization/80171] [5/6/7 Regression] ICE (Segmentation fault) with optimization

[D.Bahadir at GMX dot de]

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

--- Comment #4 from Deniz Bahadir  ---
Created attachment 41043
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41043=edit
Non-reduced test-case which fails with -O2 and -O3.

This was the original test-case which did not fail with "-O1" but with "-O2"
and "-O3".(The original production-code, however, only failed with "-O3". I am
not sure, if I am able to provide it.)

The error:
--

LANG=C /usr/bin/g++-6  -fpermissive -m64 -D_GLIBCXX_USE_CXX11_ABI=1 -std=c++14
-O3 -DNDEBUG -fPIC -c -w testcase.orig.i -o /dev/null
testcase.orig.i: In function 'void padis::isislistener::test()':
testcase.orig.i:67462:6: internal compiler error: Segmentation fault
 void test()
  ^~~~
0xad48ef crash_signal
../../src/gcc/toplev.c:333
0xde8f98 generic_simplify_VIEW_CONVERT_EXPR
/build/gcc-6-_9B9T1/gcc-6-6.2.0/build/gcc/generic-match.c:7580
0xde8f98 generic_simplify(unsigned int, tree_code, tree_node*, tree_node*)
/build/gcc-6-_9B9T1/gcc-6-6.2.0/build/gcc/generic-match.c:9055
0x89a9cb fold_unary_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../src/gcc/fold-const.c:7704
0x8cd81c fold_ctor_reference(tree_node*, tree_node*, unsigned long, unsigned
long, tree_node*)
../../src/gcc/gimple-fold.c:5508
0x8cdafa fold_array_ctor_reference
../../src/gcc/gimple-fold.c:5415
0x8cdafa fold_ctor_reference(tree_node*, tree_node*, unsigned long, unsigned
long, tree_node*)
../../src/gcc/gimple-fold.c:5533
0xc1056f fully_constant_vn_reference_p(vn_reference_s*)
../../src/gcc/tree-ssa-sccvn.c:1372
0xc1357b vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool)
../../src/gcc/tree-ssa-sccvn.c:2261
0xc164a9 visit_reference_op_load
../../src/gcc/tree-ssa-sccvn.c:3362
0xc164a9 visit_use
../../src/gcc/tree-ssa-sccvn.c:3755
0xc184b5 process_scc
../../src/gcc/tree-ssa-sccvn.c:3975
0xc184b5 extract_and_process_scc_for_name
../../src/gcc/tree-ssa-sccvn.c:4062
0xc184b5 DFS
../../src/gcc/tree-ssa-sccvn.c:4114
0xc18d17 sccvn_dom_walker::before_dom_children(basic_block_def*)
../../src/gcc/tree-ssa-sccvn.c:4596
0x1059e02 dom_walker::walk(basic_block_def*)
../../src/gcc/domwalk.c:265
0xc19b02 run_scc_vn(vn_lookup_kind)
../../src/gcc/tree-ssa-sccvn.c:4707
0xbf2d24 execute
../../src/gcc/tree-ssa-pre.c:4910
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug sanitizer/80166] SANITIZER_INTERCEPT_GETGROUPS modifies list when size is 0 Out-of-bounds write

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-24
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, problem is in libsanitizer. I'll report that to libsanitizer and
suggest patch for that.

[Bug middle-end/80163] ICE on hopefully valid code

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Clang rejects the test-case written in C:

clang pr80163.c  -c
pr80163.c:9:25: error: initializer element is not a compile-time constant
  static __int128_t d = (long) & - (long) &
^~~
1 error generated.

However accepts in C++:

clang++ pr80163.cpp  -c
[no output]

[Bug middle-end/80163] ICE on hopefully valid code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

There are multiple issues, I'm just attaching an untested fix for a related bug
where if the inner type of the conversion is unsigned, we still use
SIGN_EXTEND.

Are you sure clang accepts it?  The versions I've tried reject it.
And ICC just silently miscompiles it.  Make that e.g.
void bar (void);

__int128_t *
foo (void)
{
a:
  bar ();
b:;
  static __int128_t d = (long) & - (long) &
  return 
}
so that it doesn't optimize away and you'll see it emits 
d.3:
.quad   .L_2TAG_PACKET_0 - .L_2TAG_PACKET_1
.space 8, 0x00  # pad
which isn't sign-extended, but zero-extended.  There are no relocations that
can achieve that though, so I think we need to reject this testcase.

[Bug tree-optimization/80171] [5/6/7 Regression] ICE (Segmentation fault) with optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
On trunk:

#1  0x0173ef58 in generic_simplify_VIEW_CONVERT_EXPR (loc=0, 
code=VIEW_CONVERT_EXPR, type=, 
op0=) at generic-match.c:9836
9836if ((0 && useless_type_conversion_p (type, TREE_TYPE
(captures[0]))) || (1 && type == TREE_TYPE (captures[0])))
(gdb) p captures[0]
$1 = (tree_node *) 0x0

#4  0x00e05840 in fold_ctor_reference (
type=, 
ctor=, offset=0, size=64, 
from_decl=)
at /space/rguenther/src/svn/gcc-7-branch/gcc/gimple-fold.c:6242
6242  ret = fold_unary (VIEW_CONVERT_EXPR, type, ret);
(gdb) p ret
$2 = 


Simple fix (further reduced testcase appreciated)

Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c   (revision 246437)
+++ gcc/gimple-fold.c   (working copy)
@@ -6239,9 +6239,12 @@ fold_ctor_reference (tree type, tree cto
   && !compare_tree_int (TYPE_SIZE (TREE_TYPE (ctor)), size))
 {
   ret = canonicalize_constructor_val (unshare_expr (ctor), from_decl);
-  ret = fold_unary (VIEW_CONVERT_EXPR, type, ret);
   if (ret)
-   STRIP_USELESS_TYPE_CONVERSION (ret);
+   {
+ ret = fold_unary (VIEW_CONVERT_EXPR, type, ret);
+ if (ret)
+   STRIP_USELESS_TYPE_CONVERSION (ret);
+   }
   return ret;
 }
   /* For constants and byte-aligned/sized reads try to go through

[Bug sanitizer/80168] [5/6/7 Regression] ICE in make_decl_rtl, at varasm.c:1311 w/ VLA and -fsanitize=address

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 CC||jsm28 at gcc dot gnu.org
   Target Milestone|--- |5.5

--- Comment #1 from Richard Biener  ---
I'm not sure this is valid given 'a' is global.

[Bug tree-optimization/80171] [5/6/7 Regression] ICE (Segmentation fault) with optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-24
  Component|c++ |tree-optimization
  Known to work||4.8.5
   Target Milestone|--- |5.5
Summary|ICE (Segmentation fault)|[5/6/7 Regression] ICE
   |with optimization   |(Segmentation fault) with
   ||optimization
 Ever confirmed|0   |1
  Known to fail||4.9.4, 5.4.1, 6.3.1, 7.0.1

--- Comment #2 from Richard Biener  ---
Confirmed with the reduced testcase, ICEs since GCC 4.9.

[Bug tree-optimization/80122] __builtin_va_arg_pack() and __builtin_va_arg_pack_len() does not work correctly

[rpirrera at aitek dot it]

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

--- Comment #8 from rpirrera at aitek dot it ---
OK we have applied the patch onto the 5.4.0 version of GCC and it is working
correctly.

Thank you for your support!

[Bug c++/80171] ICE (Segmentation fault) with optimization

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Could you please also attach the compressed non-reduced testcase?