[Bug c++/70447] delete operator not called when destructor throws.

[programmerjake at gmail dot com]

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

programmerjake at gmail dot com changed:

   What|Removed |Added

 CC||programmerjake at gmail dot com

--- Comment #1 from programmerjake at gmail dot com ---
the test case should print:
destructor
operator delete
catch

It works fine on clang.

[Bug c++/70447] New: delete operator not called when destructor throws.

[programmerjake at gmail dot com]

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

Bug ID: 70447
   Summary: delete operator not called when destructor throws.
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: programmerjake at gmail dot com
  Target Milestone: ---

Created attachment 38126
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38126=edit
test source

[Bug target/63890] [4.9/5/6 regression] Compiling trivial program with -O -p leads to misaligned stack

[law at gcc dot gnu.org]

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

--- Comment #30 from Jeffrey A. Law  ---
Author: law
Date: Wed Mar 30 03:57:30 2016
New Revision: 234545

URL: https://gcc.gnu.org/viewcvs?rev=234545=gcc=rev
Log:
PR target/63890
* config/i386/i386.h (ACCUMULATE_OUTGOING_ARGS): Use when profiling
and TARGET_MACHO.

* tree-vrp.c (register_edge_assert_for_2): For NAME != CST1

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.h

[Bug c++/70446] g++: internal compiler error: Killed (program cc1plus), probably related to vectors

[ivanbili at gmail dot com]

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

--- Comment #4 from ivanbili at gmail dot com ---
The bug does NOT happen on my other computer with the following version of gcc:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-5-20160209/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 5.3.0 (GCC)

[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointer-checks

[thadula at ciena dot com]

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

--- Comment #8 from Hadula, Tomasz  ---
When I compile with devirtualization disabled (i.e. with -fno-devirtualize) the
null pointer check is where it was supposed to be.

Any clue why?

[Bug c++/36159] C++ compiler should issue a warning with missing new operator

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||b7.10110111 at gmail dot com

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

[Bug c++/70441] vector<__float128> crashes on two push_back calls with -mavx

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
This report is essentially a duplicate of bug 36159 (despite its Summary).  I
think we might as well close it as such and track the issue there.

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

[Bug target/70052] [5/6 Regression] ICE compiling _Decimal128 test case

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.4

--- Comment #9 from Alan Modra  ---
Fixed

[Bug c++/70446] g++: internal compiler error: Killed (program cc1plus), probably related to vectors

[ivanbili at gmail dot com]

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

--- Comment #3 from ivanbili at gmail dot com ---
Created attachment 38125
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38125=edit
Correct code that compiles with clang

[Bug bootstrap/70420] (Building GCC) mtune=native and internal compiler error at emit-rtl.c:1027

[xsetech at gmail dot com]

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

--- Comment #3 from Seth Junot  ---
The preprocessed *.i file is attached. It was located at 
[builddir]/x86_64-apple-darwin15.3.0/libquadmath/rem_pio2q.i

There was second file at x86_64-apple-darwin15.3.0/i386/libquadmath/rem_pio2q.i

From the output (below), we can see that -march and -mtune expand to:

-march=haswell -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16
-msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4
-mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm
-mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr
-mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf
-mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq
-mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-clwb
-mno-pcommit -mno-mwaitx --param l1-cache-size=32 --param l1-cache-line-size=64
--param l2-cache-size=3072 -mtune=haswell

The verbose stdout from the compilation is:

...
libtool: compile:  /Users/setech/Dev/GNU/GCC/gcc/build_report_gcc/./gcc/xgcc
-B/Users/setech/Dev/GNU/GCC/gcc/build_report_gcc/./gcc/
-B/home/setech/Local/usr/local/x86_64-apple-darwin15.3.0/bin/
-B/home/setech/Local/usr/local/x86_64-apple-darwin15.3.0/lib/ -isystem
/home/setech/Local/usr/local/x86_64-apple-darwin15.3.0/include -isystem
/home/setech/Local/usr/local/x86_64-apple-darwin15.3.0/sys-include
-DHAVE_CONFIG_H -I. -I../../../../libquadmath -I
../../../../libquadmath/../include -g -O2 -v -save-temps -march=native
-mtune=native -mfpmath=sse -m32 -MT math/rem_pio2q.lo -MD -MP -MF
math/.deps/rem_pio2q.Tpo -c ../../../../libquadmath/math/rem_pio2q.c
Reading specs from /Users/setech/Dev/GNU/GCC/gcc/build_report_gcc/./gcc/specs
COLLECT_GCC=/Users/setech/Dev/GNU/GCC/gcc/build_report_gcc/./gcc/xgcc
Target: x86_64-apple-darwin15.3.0
Configured with: ../configure --prefix=/home/setech/Local/usr/local/
--with-mpc=/home/setech/Local/usr/local/
--with-gmp=/home/setech/Local/usr/local/
--with-mpfr=/home/setech/Local/usr/local/
--with-isl=/home/setech/Local/usr/local/ --enable-languages=c,c++
--program-prefix=sj-
Thread model: posix
gcc version 5.3.0 (GCC)
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.11.3' '-B'
'/Users/setech/Dev/GNU/GCC/gcc/build_report_gcc/./gcc/' '-B'
'/home/setech/Local/usr/local/x86_64-apple-darwin15.3.0/bin/' '-B'
'/home/setech/Local/usr/local/x86_64-apple-darwin15.3.0/lib/' '-isystem'
'/home/setech/Local/usr/local/x86_64-apple-darwin15.3.0/include' '-isystem'
'/home/setech/Local/usr/local/x86_64-apple-darwin15.3.0/sys-include' '-D'
'HAVE_CONFIG_H' '-I' '.' '-I' '../../../../libquadmath' '-I'
'../../../../libquadmath/../include' '-g' '-O2' '-v' '-save-temps'
'-march=native' '-mtune=native' '-mfpmath=sse' '-m32' '-MT' 'math/rem_pio2q.lo'
'-MD' '-MP' '-MF' 'math/.deps/rem_pio2q.Tpo' '-c'
 /Users/setech/Dev/GNU/GCC/gcc/build_report_gcc/./gcc/cc1 -E -quiet -v -I . -I
../../../../libquadmath -I ../../../../libquadmath/../include -imultilib i386
-iprefix
/Users/setech/Dev/GNU/GCC/gcc-5.3.0/build_report_gcc/gcc/../lib/gcc/x86_64-apple-darwin15.3.0/5.3.0/
-isystem /Users/setech/Dev/GNU/GCC/gcc/build_report_gcc/./gcc/include -isystem
/Users/setech/Dev/GNU/GCC/gcc/build_report_gcc/./gcc/include-fixed -MD
rem_pio2q.d -MF math/.deps/rem_pio2q.Tpo -MP -MT math/rem_pio2q.lo
-D__DYNAMIC__ -D HAVE_CONFIG_H -isystem
/home/setech/Local/usr/local/x86_64-apple-darwin15.3.0/include -isystem
/home/setech/Local/usr/local/x86_64-apple-darwin15.3.0/sys-include
../../../../libquadmath/math/rem_pio2q.c -march=haswell -mmmx -mno-3dnow -msse
-msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul
-mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx
-mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase
-mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f
-mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt
-mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl
-mno-avx512ifma -mno-avx512vbmi -mno-clwb -mno-pcommit -mno-mwaitx --param
l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=3072
-mtune=haswell -fPIC -feliminate-unused-debug-symbols
-mmacosx-version-min=10.11.3 -mfpmath=sse -m32 -g -fworking-directory -O2
-fpch-preprocess -o rem_pio2q.i
ignoring nonexistent directory
"/home/setech/Local/usr/local/x86_64-apple-darwin15.3.0/include"
ignoring nonexistent directory
"/home/setech/Local/usr/local/x86_64-apple-darwin15.3.0/sys-include"
ignoring nonexistent directory
"/Users/setech/Dev/GNU/GCC/gcc-5.3.0/build_report_gcc/gcc/../lib/gcc/x86_64-apple-darwin15.3.0/5.3.0/include"
ignoring nonexistent directory
"/Users/setech/Dev/GNU/GCC/gcc-5.3.0/build_report_gcc/gcc/../lib/gcc/x86_64-apple-darwin15.3.0/5.3.0/include-fixed"
ignoring nonexistent directory

[Bug bootstrap/70420] (Building GCC) mtune=native and internal compiler error at emit-rtl.c:1027

[xsetech at gmail dot com]

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

--- Comment #2 from Seth Junot  ---
Created attachment 38124
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38124=edit
Preprocessed file during libquadmath compilation

[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"

[ppalka at gcc dot gnu.org]

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

--- Comment #39 from Patrick Palka  ---
(In reply to Domani Hannes from comment #37)
> With the new patch there is still a warning with this example:
> === 8< ===
> int f(void);
> 
> int test(void)
> {
>   int baz[4];
>   int q = 0;
>   int d, i, j, sum;
> 
>   for (i = 0; i < 2; i++)
>   {
> d = f();
> 
> if (d == 3)
> {
>   baz[q] = d;
>   q++;
>   if (q == 4) break;
> }
>   }
> 
>   sum = 0;
>   for (i = 0; i < q; i++)
>   {
> for (j = i + 1; j < q; j++)
> {
>   sum += baz[j];
> }
>   }
> 
>   return (sum);
> }
> === >8 ===
> $ gcc -O3 -Wall -S q.c
> q.c: In function 'test':
> q.c:27:17: warning: array subscript is above array bounds [-Warray-bounds]
>sum += baz[j];
>  ^

Thanks, I'll check it out.  Seems to be a regression from 4.7 as well.

[Bug c++/70446] g++: internal compiler error: Killed (program cc1plus), probably related to vectors

[ivanbili at gmail dot com]

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

--- Comment #2 from ivanbili at gmail dot com ---
If looks like commenting

#include // std::sort

out makes the compiler not crash.

[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"

[ppalka at gcc dot gnu.org]

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

--- Comment #38 from Patrick Palka  ---
Author: ppalka
Date: Wed Mar 30 00:55:00 2016
New Revision: 234544

URL: https://gcc.gnu.org/viewcvs?rev=234544=gcc=rev
Log:
PR tree-optimization/59124 (bogus -Warray-bounds warning)

gcc/ChangeLog:

PR tree-optimization/59124
* tree-vrp.c (register_edge_assert_for_2): For NAME != CST1
where NAME = A +- CST2 add the assertion A != (CST1 -+ CST2).

gcc/testsuite/ChangeLog:

PR tree-optimization/59124
* gcc.dg/Warray-bounds-19.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/Warray-bounds-19.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug c++/70446] g++: internal compiler error: Killed (program cc1plus), probably related to vectors

[ivanbili at gmail dot com]

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

--- Comment #1 from ivanbili at gmail dot com ---
Also happens if I fix the errors. I.e. replace

 vector[i].ratio = (float)values[i]/weights[i];
 vector[i].weight = weights[i];

with:

 helper[i].ratio = (float)values[i]/weights[i];
 helper[i].weight = weights[i];

[Bug c++/70446] New: g++: internal compiler error: Killed (program cc1plus), probably related to vectors

[ivanbili at gmail dot com]

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

Bug ID: 70446
   Summary: g++: internal compiler error: Killed (program
cc1plus), probably related to vectors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ivanbili at gmail dot com
  Target Milestone: ---

Created attachment 38123
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38123=edit
causes internal compiler error

When I try to compile the attached file, I get the following output:

:~/algs1$ g++ -pipe -O2 -std=c++11 -save-temps fractional_knapsack.cpp
g++: warning: -pipe ignored because -save-temps specified
fractional_knapsack.cpp: In function 'int main()':
fractional_knapsack.cpp:31:12: error: missing template arguments before '['
token
  vector[i].ratio = (float)values[i]/weights[i];
^
fractional_knapsack.cpp:32:12: error: missing template arguments before '['
token
  vector[i].weight = weights[i];
^
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Here is the version of gcc:

:~/algs1$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9.2-10ubuntu13' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--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-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--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=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13)

[Bug target/70052] [5/6 Regression] ICE compiling _Decimal128 test case

[amodra at gcc dot gnu.org]

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

--- Comment #8 from Alan Modra  ---
Author: amodra
Date: Wed Mar 30 00:36:36 2016
New Revision: 234543

URL: https://gcc.gnu.org/viewcvs?rev=234543=gcc=rev
Log:
[RS6000] PR70052, ICE compiling _Decimal128 test case

gcc/
PR target/70052
* config/rs6000/constraints.md (j): Simplify.
* config/rs6000/predicates.md (easy_fp_constant): Exclude
decimal float 0.D.
* config/rs6000/rs6000.md (zero_fp): New mode_attr.
(mov_hardfloat, mov_hardfloat32, mov_hardfloat64,
 mov_64bit_dm, mov_32bit): Use zero_fp in place of j
in all constraint alternatives.
(movtd_64bit_nodm): Delete "j" constraint alternative.
gcc/testsuite/
* gcc.dg/dfp/pr70052.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/dfp/pr70052.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/constraints.md
branches/gcc-5-branch/gcc/config/rs6000/predicates.md
branches/gcc-5-branch/gcc/config/rs6000/rs6000.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

[kugan at gcc dot gnu.org]

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

--- Comment #14 from kugan at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #13)
> The change to the assignment of p_22 is made by forwprop1.
> 
> It does create a situation where p_2 is live outside the loop and hides the
> CSE opportunity, which may be the cause of the more significant differences
> at expansion time.

Indeed. This is what I see: 

gcc 5 branch with  -O2 t2.c  -S -Os -marm  -mcpu=arm966e-s 96 Bytes
trunk with -O2 t2.c  -c -Os -marm  -mcpu=arm966e-s  112 Bytes
trunk with -O2 t2.c  -c -Os -marm   108 Bytes
trunk with -O2 t2.c  -c -Os -marm  -mcpu=arm966e-s  -fno-tree-forwprop 96 Bytes
trunk with -O2 t2.c  -c -Os -marm  -mcpu=arm966e-s and Jakub's changes in c# 5
- 100 Bytes

[Bug c++/70445] New: Incorrect C++ member alignment

[hjl.tools at gmail dot com]

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

Bug ID: 70445
   Summary: Incorrect C++ member alignment
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-ivb-1 gcc]$ cat /tmp/a.ii 
typedef struct xxx 
{
  unsigned long long a1;
  unsigned long long a2;
  unsigned long long a3;
  unsigned long long a4;
} xxx;

typedef struct Foo
{
  xxx foo;
} Foo;

extern xxx b;
Foo y;

void
foo (void)
{
  b = y.foo;
}
[hjl@gnu-ivb-1 gcc]$ ./xgcc -B./ -S -O2 -da /tmp/a.ii 
[hjl@gnu-ivb-1 gcc]$ cp /tmp/a.ii /tmp/c.i
[hjl@gnu-ivb-1 gcc]$ ./xgcc -B./ -S -O2 -da /tmp/c.i 
[hjl@gnu-ivb-1 gcc]$ grep A128 c.i.213r.expand
[hjl@gnu-ivb-1 gcc]$ grep A128 a.ii.213r.expand
(mem/c:DI (reg/f:DI 96) [1 y.foo+16 S8 A128])) /tmp/a.ii:20 -1
  ^ Where dos it come from?
(mem/c:DI (reg/f:DI 96) [1 y.foo+16 S8 A128])) /tmp/a.ii:20 -1
[hjl@gnu-ivb-1 gcc]$

[Bug c++/70444] New: Optimizer removes expression template

[g++bug at oxyware dot com]

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

Bug ID: 70444
   Summary: Optimizer removes expression template
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g++bug at oxyware dot com
  Target Milestone: ---

The code below crashes with a SIGSEGV when compiled with g++ 5.3.1 and
optimization turned on.  Gdb shows that the variable v4 has been optimized out
and is a null pointer.  The code runs correctly with no optimization, -O, -Os
or -O1, but crashes with -O2 or -O3.

The bug appears to be present in previous versions of g++ back to 4.7.0 (the
earliest I can test as the code uses C++11).

The code runs correctly with clang++, with or without optimisation.

Correct functionality
$ g++ -std=c++11 % && ./a.out
$ echo $?
33

Incorrect
$ g++ -std=c++11 -O2 % && ./a.out
Segmentation fault (core dumped)

Correct
$ clang++ -std=c++11 -O3 exprtmpl.cpp && ./a.out
$ echo $?
33

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-default-libstdcxx-abi=gcc4-compatible --with-isl
--enable-libmpx --enable-gnu-indirect-function --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)

$ clang++ -v
clang version 3.5.0 (tags/RELEASE_350/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/5.3.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/5.3.1
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/5.3.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64


(Platform is 64-bit Fedora 22 on x86_64, using the distribution's version of
g++)


//-
#include 

template 
struct Expression {
Expression(const Left & l, const Right & r) : left(l), right(r) {}
float operator[](unsigned int index) const {
return Op::apply(left[index], right[index]);
}
const Left & left;
const Right & right;
};

struct plus {
static float apply(float l, float r) { return l + r; }
};

template 
Expression operator+(const Left & l, const Right & r)
{
return Expression(l, r);
}

int main()
{
std::vector v1{2, 3.4, 5};
std::vector v2{3, 5.0, 4};
std::vector v3{4, 6.0, 1};
auto v4 = v1 + v2 + v3;
float total = 0;
for (auto i = 0u; i != v1.size(); ++i)
total += v4[i];
return total;
}
//-

[Bug c/70436] [4.9/5/6 Regression] -Wparentheses missing ambiguous else warning

[joseph at codesourcery dot com]

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

--- Comment #10 from joseph at codesourcery dot com  ---
I'd consider it a bug that the existing -Wparentheses warning for 
ambiguous "else" doesn't warn in this case.  As with the existing warning, 
that warning is only appropriate when there is in fact ambiguity (thus, 
not if there were two more "else" clauses in this example so that every 
"if" had one and there was no ambiguity), though the indentation could 
still be misleading without such ambiguity.  I think the existing warning, 
controlled by the existing option (or any new option that's a subset of 
-Wparentheses and enabled by it), should apply to all cases where the 
syntax for statements permits multiple parses differing in which "if" an 
"else" is associated with, and the rule associating it with the nearest 
has to be applied to select between those alternatives.

(Obviously global state as in the prototype is not a correct part of any 
sensible implementation of such a warning, as you need to keep track of 
arbitrarily many nested states for "if" statements currently being 
parsed.)

[Bug other/70428] -fdebug-prefix-map did not support to remap sources with relative path

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
I don't think -fdebug-prefix-map is meant to cover this case; you're meant 
to use it with paths in the form in which they appear in debug info, which 
means passing such an option with the pwd (and options with absolute -I 
paths etc.), not an option with a combination of the pwd and a path passed 
to the compiler.

[Bug lto/70283] [6 regression] bogus vtable mismatch warnings

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

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

[Bug target/70442] [6 Regression] gcc ICE at -O2 and above on valid code on x86_64-linux-gnu in "extract_insn"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-29
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|gcc ICE at -O2 and above on |[6 Regression] gcc ICE at
   |valid code on   |-O2 and above on valid code
   |x86_64-linux-gnu in |on x86_64-linux-gnu in
   |"extract_insn"  |"extract_insn"
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r228231.

[Bug jit/70443] New: gccjit fails to build with in-tree dependencies

[hp at tmm dot cx]

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

Bug ID: 70443
   Summary: gccjit fails to build with in-tree dependencies
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: hp at tmm dot cx
  Target Milestone: ---

When trying to build gccjit with in-tree dependencies (fetched with
contrib/download_prerequisites) linking will fail as the in-tree dependencies
are built without -fPIC.

/usr/bin/ld: /home/hp/src/gcc-jit/./mpc/src/.libs/libmpc.a(acos.o): relocation
R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared
object; recompile with -fPIC

shared libraries should probably be built when --with-host-shared is enabled.

[Bug tree-optimization/70442] New: gcc ICE at -O2 and above on valid code on x86_64-linux-gnu in "extract_insn"

[helloqirun at gmail dot com]

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

Bug ID: 70442
   Summary: gcc ICE at -O2 and above on valid code on
x86_64-linux-gnu in "extract_insn"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following valid code causes an ICE when compiled with the current gcc trunk
at -O2 and above on x86_64-linux-gnu in both 32-bit mode only.

It should be a 6 regression.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160329 (experimental) [trunk revision 234517] (GCC) 


$ gcc-trunk -m32 -O2 abc.c
abc.c: In function ‘fn1’:
abc.c:11:1: error: unrecognizable insn:
 }
 ^
(insn 17 16 27 2 (set (subreg:V2DI (reg/v:DI 92 [ b ]) 0)
(reg/v:DI 87 [ b ])) abc.c:9 -1
 (expr_list:REG_DEAD (reg/v:DI 87 [ b ])
(nil)))
abc.c:11:1: internal compiler error: in extract_insn, at recog.c:2287
0xaf5528 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0xaf5559 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:116
0xac2721 extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2287
0x1276dbe decompose_multiword_subregs
../../gcc/gcc/lower-subreg.c:1465
0x127803d execute
../../gcc/gcc/lower-subreg.c:1735
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.



$ cat abc.c
char a, c;
void fn1() {
  long long b;
  long m;
  int d;
  switch (d)
  case 5:
  b = a;
  b ^= m;
  c = b >> b;
}

[Bug lto/70289] [openacc] ICE in input_varpool_node

[cesar at gcc dot gnu.org]

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

--- Comment #4 from cesar at gcc dot gnu.org ---
Created attachment 38122
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38122=edit
c test case

This test cases is failing for a couple of reasons. First, the reduction
variable doesn't have a data clause associated with it. Usually that isn't a
problem, like it would be in c with stack-based storage, but fortran uses
static allocation by default for local variables. Consequently, that static
reduction variable resides in a different lto partition from the offloaded
function. And that causes assertion failure in input_varpool_node. 

I'm not sure if we should create a static copy of that variable on the
accelerator. My inclination would be to teach the gimplifier to add an
present_or_copy clause for each reduction variable listed in a parallel
directive. The OpenACC spec is vague on what it means by "original variable",
but one could argue that it's the variable that resides on the host.

The c test case reproduces the fortran problem in c using a static int
reduction variable. A global reduction variable that is not associated with any
data clauses will also fail in a similar fashion.

[Bug c++/70441] vector<__float128> crashes on two push_back calls with -mavx

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
C++ does not support dynamic allocation of over-aligned types (usually SIMD
vectors, but also __float128 on x86 for instance). C++17 will partially support
it (operator new), but still not fix the std::vector case, which has to wait
until C++20 (assuming someone actually does the work of writing and pushing a
proposal) :-(

Well, actually, you can always write your own allocator which provides properly
aligned memory.

[Bug c++/70441] New: vector<__float128> crashes on two push_back calls with -mavx

[b7.10110111 at gmail dot com]

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

Bug ID: 70441
   Summary: vector<__float128> crashes on two push_back calls with
-mavx
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b7.10110111 at gmail dot com
  Target Milestone: ---

The following simple program reproduces the bug:


#include 

int main()
{
std::vector<__float128> tests;
tests.push_back(0);
tests.push_back(0);
}


I compiled it with this command line:

g++ test.cpp -o test -g -mavx

On attempt to run it reliably crashes on `vmovaps XMMWORD PTR [eax],xmm2`
instruction, where eax==0x804fa38, i.e. not aligned on 16-byte boundary. The
calling code is the second push_back(). Here's the full backtrace:

0x08048d30 in __gnu_cxx::new_allocator<__float128>::construct (this=0xd444,
__p=0x804fa38, __val=@0xd460: ) at
/opt/gcc-5.2/include/c++/5.2.0/ext/new_allocator.h:130
130   { ::new((void *)__p) _Tp(__val); }
(gdb) bt
#0  0x08048d30 in __gnu_cxx::new_allocator<__float128>::construct
(this=0xd444, __p=0x804fa38, __val=@0xd460: )
at /opt/gcc-5.2/include/c++/5.2.0/ext/new_allocator.h:130
#1  0x080489bd in __gnu_cxx::__alloc_traits
>::construct<__float128> (__a=..., __p=0x804fa38, __arg=@0xd460: )
at /opt/gcc-5.2/include/c++/5.2.0/ext/alloc_traits.h:189
#2  0x08048ae1 in std::vector<__float128, std::allocator<__float128>
>::_M_insert_aux (this=0xd444, __position=,
__x=@0xd460: )
at /opt/gcc-5.2/include/c++/5.2.0/bits/vector.tcc:361
#3  0x080488e9 in std::vector<__float128, std::allocator<__float128>
>::push_back (this=0xd444, __x=@0xd460: ) at
/opt/gcc-5.2/include/c++/5.2.0/bits/stl_vector.h:925
#4  0x080487c2 in main () at test.cpp:7

[Bug lto/70283] [6 regression] bogus vtable mismatch warnings

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
Author: hubicka
Date: Tue Mar 29 19:37:55 2016
New Revision: 234532

URL: https://gcc.gnu.org/viewcvs?rev=234532=gcc=rev
Log:

PR ipa/70283
* ipa-devirt.c (methods_equal_p): New function.
(compare_virtual_tables): Use it.
* cgraph.h (symbol_table::symbol_suffix_separator): Declare.
* cgraphclones.c (clone_function_name_1): Use
symbol_table::symbol_suffix_separator.
* coverage.c (build_var): Likewise.
* symtab.c (symbol_table::symbol_suffix_separator): New.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.h
trunk/gcc/cgraphclones.c
trunk/gcc/coverage.c
trunk/gcc/ipa-devirt.c
trunk/gcc/symtab.c

[Bug tree-optimization/70405] [6 Regression] -fcompare-debug failure with -mavx512f

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/70429] Wrong code with -O1.

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Fixed for 6+ so far.

[Bug bootstrap/70422] [6 regression] Bootstrap comparison failure

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
Created attachment 38121
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38121=edit
patch on top of the original patch

(In reply to Richard Biener from comment #9)
> Presumably the C++ FE should have set DECL_IGNORED_P on the fname decl.

Yep, that works.  Patch attached; bootstrapped + regchecked on powerpc64-linux.
It also corrects some regexps in one of the new testcases.

[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"

[ssbssa at yahoo dot de]

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

--- Comment #37 from Domani Hannes  ---
With the new patch there is still a warning with this example:
=== 8< ===
int f(void);

int test(void)
{
  int baz[4];
  int q = 0;
  int d, i, j, sum;

  for (i = 0; i < 2; i++)
  {
d = f();

if (d == 3)
{
  baz[q] = d;
  q++;
  if (q == 4) break;
}
  }

  sum = 0;
  for (i = 0; i < q; i++)
  {
for (j = i + 1; j < q; j++)
{
  sum += baz[j];
}
  }

  return (sum);
}
=== >8 ===
$ gcc -O3 -Wall -S q.c
q.c: In function 'test':
q.c:27:17: warning: array subscript is above array bounds [-Warray-bounds]
   sum += baz[j];
 ^

[Bug rtl-optimization/70429] Wrong code with -O1.

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 29 18:49:00 2016
New Revision: 234531

URL: https://gcc.gnu.org/viewcvs?rev=234531=gcc=rev
Log:
PR rtl-optimization/70429
* combine.c (simplify_shift_const_1): For ASHIFTRT don't optimize
(cst1 >> count) >> cst2 into (cst1 >> cst2) >> count if
mode != result_mode.

* gcc.c-torture/execute/pr70429.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr70429.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/70353] [5 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[5/6 regression] ICE on |[5 regression] ICE on
   |__PRETTY_FUNCTION__ in a|__PRETTY_FUNCTION__ in a
   |constexpr function  |constexpr function

--- Comment #18 from Jason Merrill  ---
Fixed again for 6.

[Bug c++/70353] [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function

[jason at gcc dot gnu.org]

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

--- Comment #17 from Jason Merrill  ---
Author: jason
Date: Tue Mar 29 18:40:02 2016
New Revision: 234530

URL: https://gcc.gnu.org/viewcvs?rev=234530=gcc=rev
Log:
PR c++/70353

gcc/
* tree-inline.c (remap_decls): Don't add_local_decl if
cfun is null.
gcc/cp/
* decl.c (make_rtl_for_nonlocal_decl): Don't defer local statics
in constexpr functions.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-__func__2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/tree-inline.c

[Bug c++/68475] [4.9/5/6 Regression] ICE: in merge_exception_specifiers, at cp/typeck2.c:2115 with -fno-exceptions on invalid code

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c/70436] [4.9/5/6 Regression] -Wparentheses missing ambiguous else warning

[bernds at gcc dot gnu.org]

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

--- Comment #9 from Bernd Schmidt  ---
I suspect what broke it was git revision 0375a27521885.

[Bug c++/69487] Unexpected VLA initialization of char[] from ""

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #4 from Martin Sebor  ---
As mentioned in the duplicate bug 70440, this problem affects all versions of
GCC that accept a string initializer for a character VLA.

[Bug c++/16994] [meta-bug] VLA and C++

[msebor at gcc dot gnu.org]

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

Bug 70440 Summary: SEGV initializing a VLA with a smaller string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70440

   What|Removed |Added

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

[Bug c++/69487] Unexpected VLA initialization of char[] from ""

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

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

[Bug c++/70440] SEGV initializing a VLA with a smaller string

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Turns out there already is a report of this problem: bug 69487.

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

[Bug c++/70440] New: SEGV initializing a VLA with a smaller string

[msebor at gcc dot gnu.org]

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

Bug ID: 70440
   Summary: SEGV initializing a VLA with a smaller string
   Product: gcc
   Version: 6.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: ---

The following program crashes with a SEGV when compiled without optimization
with the current trunk as well as 5.1.0 and 4.9.3.

The program is rejected by 4.5.3 with error: variable-sized object ‘a’ may not
be initialized so the bug could be viewed as a regression.

The assembly and the tree dump show that the problem is caused by GCC emitting
a call to memcpy() to initialize the large VLA from the empty string.

$ cat v.c && /build/gcc-trunk-bootstrap/gcc/xgcc -B
/build/gcc-trunk-bootstrap/gcc -DN=2413 -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout -g -xc++ v.c && gdb -batch -q -ex r -ex bt
-ex up -ex 'disas g' -ex 'p/x ' -ex 'p/x $rsi' -ex 'p/x $rdi' -ex 'p $rdx'
./a.out
void __attribute__ ((noclone, noinline)) f (void *p) { }

void __attribute__ ((noclone, noinline)) g (int n)
{
char a [n] = "";
f (a);
}

int main ()
{
g (N);
}

v.c: In function ‘void f(void*)’:
v.c:1:51: warning: unused parameter ‘p’ [-Wunused-parameter]
 void __attribute__ ((noclone, noinline)) f (void *p) { }
   ^
v.c: In function ‘void g(int)’:
v.c:5:14: warning: ISO C++ forbids variable length array ‘a’ [-Wvla]
 char a [n] = "";
  ^

;; Function void f(void*) (_Z1fPv, funcdef_no=0, decl_uid=2253, cgraph_uid=0,
symbol_order=0)

__attribute__((noinline, noclone))
void f(void*) (void * p)
{
  :
  GIMPLE_NOP
  return;

}



;; Function void g(int) (_Z1gi, funcdef_no=1, decl_uid=2256, cgraph_uid=1,
symbol_order=1)

__attribute__((noinline, noclone))
void g(int) (int n)
{
  char a[0:D.2264] [value-expr: *a.0];
  void * saved_stack.2;
  char[0:D.2264] * a.1;
  char[0:D.2264] * a.0;
  sizetype D.2276;
  sizetype D.2275;
  bitsizetype D.2274;
  bitsizetype D.2273;
  sizetype D.2272;
  sizetype D.2271;
  sizetype D.2270;
  sizetype D.2269;
  bitsizetype D.2268;
  bitsizetype D.2267;
  sizetype D.2266;
  sizetype D.2265;
  sizetype D.2264;
  ssizetype D.2263;
  ssizetype D.2262;
  void * saved_stack.2_3;
  ssizetype _5;
  ssizetype _6;
  sizetype _8;
  sizetype _9;
  bitsizetype _10;
  bitsizetype _11;
  sizetype _12;
  sizetype _13;
  sizetype _14;
  sizetype _15;
  bitsizetype _16;
  bitsizetype _17;
  sizetype _18;
  sizetype _19;
  char[0:D.2264] * a.1_23;

  :
  saved_stack.2_3 = __builtin_stack_save ();
  _5 = (ssizetype) n_4(D);
  _6 = _5 + -1;
  _7 = (sizetype) _6;
  _8 = (sizetype) _6;
  _9 = _8 + 1;
  _10 = (bitsizetype) _9;
  _11 = _10 * 8;
  _12 = (sizetype) _6;
  _13 = _12 + 1;
  _14 = (sizetype) _6;
  _15 = _14 + 1;
  _16 = (bitsizetype) _15;
  _17 = _16 * 8;
  _18 = (sizetype) _6;
  _19 = _18 + 1;
  a.0_21 = __builtin_alloca_with_align (_19, 8);
  __builtin_memcpy (a.0_21, "", _13);
  a.1_23 = a.0_21;
  f (a.1_23);
  __builtin_stack_restore (saved_stack.2_3);
  return;

}



;; Function int main() (main, funcdef_no=2, decl_uid=2259, cgraph_uid=2,
symbol_order=2)

int main() ()
{
  int D.2280;
  int _3;

  :
  g (2413);
  _3 = 0;

:
  return _3;

}



Program received signal SIGSEGV, Segmentation fault.
0x77b63bd6 in __memcpy_avx_unaligned () from /lib64/libc.so.6
#0  0x77b63bd6 in __memcpy_avx_unaligned () from /lib64/libc.so.6
#1  0x004005da in g (n=2413) at v.c:5
#2  0x004005fe in main () at v.c:11
#1  0x004005da in g (n=2413) at v.c:5
5   char a [n] = "";
Dump of assembler code for function g(int):
   0x00400551 <+0>: push   %rbp
   0x00400552 <+1>: mov%rsp,%rbp
   0x00400555 <+4>: push   %rbx
   0x00400556 <+5>: sub$0x28,%rsp
   0x0040055a <+9>: mov%edi,-0x24(%rbp)
   0x0040055d <+12>:mov%rsp,%rax
   0x00400560 <+15>:mov%rax,%rbx
   0x00400563 <+18>:mov-0x24(%rbp),%eax
   0x00400566 <+21>:cltq   
   0x00400568 <+23>:sub$0x1,%rax
   0x0040056c <+27>:mov%rax,-0x18(%rbp)
   0x00400570 <+31>:mov%rax,%rdx
   0x00400573 <+34>:add$0x1,%rdx
   0x00400577 <+38>:mov%rdx,%r10
   0x0040057a <+41>:mov$0x0,%r11d
   0x00400580 <+47>:mov%rax,%rdx
   0x00400583 <+50>:lea0x1(%rdx),%rcx
   0x00400587 <+54>:mov%rax,%rdx
   0x0040058a <+57>:add$0x1,%rdx
   0x0040058e <+61>:mov%rdx,%r8
   0x00400591 <+64>:mov$0x0,%r9d
   0x00400597 <+70>:lea0x1(%rax),%rdx
   0x0040059b <+74>:mov$0x10,%eax
   0x004005a0 <+79>:sub$0x1,%rax
   

[Bug c/70436] [4.9/5/6 Regression] -Wparentheses missing ambiguous else warning

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
Summary|-Wmisleading-indentation|[4.9/5/6 Regression]
   |missing warning |-Wparentheses missing
   ||ambiguous else warning

--- Comment #8 from Bernd Schmidt  ---
This should be part of -Wparentheses, where we already have dangling else
warnings (called "ambiguous else"). Earlier versions of gcc warned for this
case.

[Bug target/70439] New: Incorrect DRAP check in ix86_expand_epilogue

[hjl.tools at gmail dot com]

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

Bug ID: 70439
   Summary: Incorrect DRAP check in ix86_expand_epilogue
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: x86

ix86_expand_epilogue has

/* eh_return epilogues need %ecx added to the stack pointer.  */
  if (style == 2)
{   
  rtx sa = EH_RETURN_STACKADJ_RTX;
  rtx_insn *insn;

  /* Stack align doesn't work with eh_return.  */
  gcc_assert (!stack_realign_drap);
  /* Neither does regparm nested functions.  */
  gcc_assert (!ix86_static_chain_on_stack);

EH_RETURN_STACKADJ_RTX is defined to %ecx, which conflicts with DRAP
which also uses %ecx.  When stack_realign_drap is true, ix86_get_drap_rtx
emits DRAP register. But ix86_finalize_stack_realign_flags may set
crtl->stack_realign_needed to false later.  When we get ix86_expand_epilogue,
stack_realign_drap is false, but DRAP is actually used, which leads to wrong
code.

[Bug tree-optimization/70405] [6 Regression] -fcompare-debug failure with -mavx512f

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 29 17:33:52 2016
New Revision: 234529

URL: https://gcc.gnu.org/viewcvs?rev=234529=gcc=rev
Log:
PR tree-optimization/70405
* ssa-iterators.h (num_imm_uses): Add missing braces.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr70405.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ssa-iterators.h
trunk/gcc/testsuite/ChangeLog

[Bug c++/70438] result type of vector operations

[mjh at edg dot com]

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

--- Comment #2 from Mike Herrick  ---
I think that's fine -- a note in the documentation to that effect (describing
what an "opaque" vector type is and what operations are allowed on it) should
suffice.

Thanks.

[Bug c++/70438] result type of vector operations

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
The result of a comparison is an "opaque" vector type, which can be converted
much more freely than a regular vector type, in case the guessed return type
doesn't exactly match the user's choice (it quickly decays to a regular vector
type). So this is kind of done on purpose. It could make sense to restrict this
a bit though. If you have some good rules to suggest... I don't know how much
user code relies on it.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

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

--- Comment #24 from Jerry DeLisle  ---
Dominiq, I have tested as much as I can with several variations of values of
the float and all looks good. I am ready to approve your patch when you are.

[Bug fortran/70397] [5/6 Regression] ice while allocating ultimate polymorphic

[vehre at gcc dot gnu.org]

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Waiting one week for any new regressions introduced by this patch.

[Bug fortran/70397] [5/6 Regression] ice while allocating ultimate polymorphic

[vehre at gcc dot gnu.org]

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

--- Comment #4 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Tue Mar 29 16:54:24 2016
New Revision: 234528

URL: https://gcc.gnu.org/viewcvs?rev=234528=gcc=rev
Log:
gcc/fortran/ChangeLog:

2016-03-29  Andre Vehreschild  

PR fortran/70397
* trans-expr.c (gfc_class_len_or_zero_get): Add function to return a
constant zero tree, when the class to get the _len component from is
not unlimited polymorphic.
(gfc_copy_class_to_class): Use the new function.
* trans.h: Added interface of new function gfc_class_len_or_zero_get.

gcc/testsuite/ChangeLog:

2016-03-29  Andre Vehreschild  

PR fortran/70397
* gfortran.dg/unlimited_polymorphic_25.f90: New test.
* gfortran.dg/unlimited_polymorphic_26.f90: New test.



Added:
trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_25.f90
trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_26.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/68695] [6 Regression] Performance regression related to ssa patch / ifcvt

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

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

[Bug target/69890] FAIL: gcc.target/i386/chkp-* on x86_64-apple-darwin15

[ienkovich at gcc dot gnu.org]

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

--- Comment #4 from Ilya Enkovich  ---
(In reply to Dominique d'Humieres from comment #3)
> --- ../_clean/gcc/testsuite/gcc.target/i386/chkp-strlen-1.c   2016-01-20
> 19:08:43.0 +0100
> +++ gcc/testsuite/gcc.target/i386/chkp-strlen-1.c 2016-03-29
> 17:25:30.0 +0200
> @@ -1,6 +1,6 @@
>  /* { dg-do compile { target { ! x32 } } } */
>  /* { dg-options "-fcheck-pointer-bounds -mmpx -O2 -fdump-tree-strlen" } */
> -/* { dg-final { scan-tree-dump "memcpy.chkp" "strlen" } } */
> +/* { dg-final { scan-tree-dump "memcpy(_chk)?.chkp" "strlen" } } */
>  
>  #include "string.h"
>  
> ?
> 
> Now 
> 
> grep memcpy chkp-stropt-1.c.097t.chkpopt 
> 
> gives
>   __builtin___memcpy_chk.chkp (buf1_2(D), __chkp_bounds_of_buf1_7(D),
> buf2_4(D), __chkp_bounds_of_buf2_8(D), len_5(D), 18446744073709551615);
> 
> What should I do for that?

Well, tests were not supposed to check object_sizes pass capabilities.  But
allowing misoptimized code means we don't test functionality we wanted to test.
 I think these tests may use __builtin_* versions of string functions to make
tests independent from headers.

[Bug rtl-optimization/68695] [6 Regression] Performance regression related to ssa patch / ifcvt

[vmakarov at gcc dot gnu.org]

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

--- Comment #25 from Vladimir Makarov  ---
Author: vmakarov
Date: Tue Mar 29 16:20:39 2016
New Revision: 234527

URL: https://gcc.gnu.org/viewcvs?rev=234527=gcc=rev
Log:
2016-03-29  Vladimir Makarov  

PR rtl-optimization/68695
* ira-color.c (allocno_copy_cost_saving): New.
(improve_allocation): Use it.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-color.c

[Bug target/70359] [6 Regression] Code size increase for ARM compared to gcc-5.3.0

[law at redhat dot com]

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

--- Comment #13 from Jeffrey A. Law  ---
The change to the assignment of p_22 is made by forwprop1.

It does create a situation where p_2 is live outside the loop and hides the CSE
opportunity, which may be the cause of the more significant differences at
expansion time.

[Bug c++/70438] New: result type of vector operations

[mjh at edg dot com]

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

Bug ID: 70438
   Summary: result type of vector operations
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjh at edg dot com
  Target Milestone: ---

The documentation for Vector Extensions says that the relational operations and
logical operations return vectors of the same width and number of elements as
the operands, but with signed integral element type.

In the following example, operations are performed on a vector of floats and an
attempt is made to to assign the result to the same vector, expecting an error,
but no errors are diagnosed.  Errors are, however, given when an incompatible
vector type is assigned directly:

typedef float v4sf __attribute__ ((vector_size (16)));
typedef int v4si __attribute__ ((vector_size (16)));
int main() {
  v4sf c = {1.0,0.0,1.0,0.0};
  v4si x;
  /* These assignments are allowed (but shouldn't be?): */
  c = !c;
  c = c && c;
  c = c || c;
  c = c == c;
  c = c != c;
  c = c >= c;
  c = c <= c;
  c = c < c;
  c = c > c;
#if NEG
  /* These assignments are not allowed: */
  c = x;
  c = (v4si){1};
#endif
  return 0;
}

I would expect all of these to elicit an error.  Am I missing something or is
this a bug?

[Bug target/69890] FAIL: gcc.target/i386/chkp-* on x86_64-apple-darwin15

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> The problem is that some string functions are defined as inline functions
> using *_chk function variants.  object_sizes pass transforms *_chk call
> into original function call in a regular case but not for CHKP wrappers. 
> Thus CHKP wrappers need to be supported in object_sizes pass to make these
> tests pass on Darwin.

As in 

--- ../_clean/gcc/testsuite/gcc.target/i386/chkp-strlen-1.c 2016-01-20
19:08:43.0 +0100
+++ gcc/testsuite/gcc.target/i386/chkp-strlen-1.c   2016-03-29
17:25:30.0 +0200
@@ -1,6 +1,6 @@
 /* { dg-do compile { target { ! x32 } } } */
 /* { dg-options "-fcheck-pointer-bounds -mmpx -O2 -fdump-tree-strlen" } */
-/* { dg-final { scan-tree-dump "memcpy.chkp" "strlen" } } */
+/* { dg-final { scan-tree-dump "memcpy(_chk)?.chkp" "strlen" } } */

 #include "string.h"

?

Now 

grep memcpy chkp-stropt-1.c.097t.chkpopt 

gives
  __builtin___memcpy_chk.chkp (buf1_2(D), __chkp_bounds_of_buf1_7(D),
buf2_4(D), __chkp_bounds_of_buf2_8(D), len_5(D), 18446744073709551615);

What should I do for that?

[Bug preprocessor/69391] [5/6 Regression] Incorrect __LINE__ expansion with -ftrack-macro-expansion=0 on g++5.2

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

[Bug target/70355] [5/6 Regression] ICE: in simplify_subreg_concatn, at lower-subreg.c:617 with -funroll-loops -mavx512f

[rth at gcc dot gnu.org]

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

--- Comment #3 from Richard Henderson  ---
Author: rth
Date: Tue Mar 29 15:19:00 2016
New Revision: 234524

URL: https://gcc.gnu.org/viewcvs?rev=234524=gcc=rev
Log:
PR middle-end/70355

  * lower-subreg.c (simplify_subreg_concatn): Reject paradoxical subregs.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr70355.c
trunk/gcc/testsuite/gcc.target/i386/pr70355.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lower-subreg.c

[Bug libstdc++/70437] New: [6 Regression] Instantiation loop with pair and is_constructible

[jason at gcc dot gnu.org]

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

Bug ID: 70437
   Summary: [6 Regression] Instantiation loop with pair and
is_constructible
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
  Target Milestone: ---

Reduced from https://github.com/openscad/openscad/issues/1575

#include 

template  struct B;

template  struct A
{
  A(A&&) = default;
  A(const B &);
};

template  struct B
{
  std::pair a;
  B(B&&) = default;
};

bool b = std::is_move_constructible::value;

This seems similar to bug 65760.

[Bug target/70355] [5 Regression] ICE: in simplify_subreg_concatn, at lower-subreg.c:617 with -funroll-loops -mavx512f

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
Summary|[5/6 Regression] ICE: in|[5 Regression] ICE: in
   |simplify_subreg_concatn, at |simplify_subreg_concatn, at
   |lower-subreg.c:617 with |lower-subreg.c:617 with
   |-funroll-loops -mavx512f|-funroll-loops -mavx512f

--- Comment #4 from Richard Henderson  ---
Fixed for gcc6.

[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3

[olegendo at gcc dot gnu.org]

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

--- Comment #18 from Oleg Endo  ---
(In reply to Oleg Endo from comment #17)
> 
> I'm now testing this patch on sh-elf...

The GCC testsuite results look OK.  However, CSiBE shows

  sum:  3342539 -> 3351695+9156 / +0.273924 %

which is not so nice.  For example, in bzip2/blocksort, the increase seems to
be caused mainly by things like:

before  after
mov #92,r0  mov r15,r0
sub r7,r6   add #64,r0
mov.l   @(r0,r15),r5sub r7,r6
mov.l   @(28,r0),r5

[Bug c/70436] -Wmisleading-indentation missing warning

[ppalka at gcc dot gnu.org]

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

--- Comment #7 from Patrick Palka  ---
BTW according to a working implementation of this -Wdangling-else warning (not
the above broken one I prematurely posted), the only suspicious use of dangling
else (i.e. a use in which the indentation is off*) in gcc's c++ source files is

  /home/patrick/code/gcc/gcc/ssa-iterators.h:454:3: note: dangling else

*: by indentation being off I mean that the column of the dangling else is not
the same as the column of the innermost if

[Bug c++/55914] [C++11] Pack expansion fails in lambda expressions

[jaak at ristioja dot ee]

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

Jaak Ristioja  changed:

   What|Removed |Added

 CC||jaak at ristioja dot ee

--- Comment #9 from Jaak Ristioja  ---
(In reply to Balakrishnan B from comment #8)
> Is this bug fixed in 4.8.3? I don't find here
> 
> Known to work:4.9.0
> Known to fail:4.7.2, 4.8.0

Apparently this is was not backported to the 4.8 series, as 4.8.5 still fails
with the simplified example in comment #3.

[Bug c++/68724] [4.9/5/6 Regression] ice in unify, at cp/pt.c:19902

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
One can turn it into the syntactically correct:
template 
  struct integral_constant {
  };

  struct X : integral_constant < bool, true >{
  };

template 
struct integral_constant < bool, __is_enum(_Tp)> {
};

but still get the ICE when unify meets an unexpected TRAIT_EXPR.

[Bug target/69890] FAIL: gcc.target/i386/chkp-* on x86_64-apple-darwin15

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org

--- Comment #2 from Ilya Enkovich  ---
The problem is that some string functions are defined as inline functions using
*_chk function variants.  object_sizes pass transforms *_chk call into original
function call in a regular case but not for CHKP wrappers.  Thus CHKP wrappers
need to be supported in object_sizes pass to make these tests pass on Darwin.

[Bug testsuite/64177] Various cilk+ testsuite failures

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|NEW |UNCONFIRMED
   Assignee|tschwinge at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org
 Ever confirmed|1   |0

--- Comment #4 from Thomas Schwinge  ---
(In reply to iverbin from comment #2)
> Actually, only 3 tests require 2+ workers (they fail with export
> CILK_NWORKERS=1):
> FAIL: c-c++-common/cilk-plus/CK/spawning_arg.c
> FAIL: c-c++-common/cilk-plus/CK/steal_check.c
> FAIL: g++.dg/cilk-plus/CK/catch_exc.cc

In r234523, I just fixed these three test cases.

> It's unclear what happens with others. Maybe it's a bug in libcilkrts.

Jakub, can you still reproduce the other issues?  Anyway, unassigning myself.

[Bug testsuite/64177] Various cilk+ testsuite failures

[tschwinge at gcc dot gnu.org]

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

--- Comment #3 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue Mar 29 14:39:33 2016
New Revision: 234523

URL: https://gcc.gnu.org/viewcvs?rev=234523=gcc=rev
Log:
[PR testsuite/64177] Audit Cilk Plus tests for CILK_NWORKERS=1

PR testsuite/64177
gcc/testsuite/
* c-c++-common/cilk-plus/CK/spawning_arg.c (main): Call
__cilkrts_set_param to set two workers.
* c-c++-common/cilk-plus/CK/steal_check.c (main): Likewise.
* g++.dg/cilk-plus/CK/catch_exc.cc (main): Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/spawning_arg.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/steal_check.c
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/catch_exc.cc

[Bug testsuite/64177] Various cilk+ testsuite failures

[iverbin at gcc dot gnu.org]

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

--- Comment #2 from iverbin at gcc dot gnu.org ---
Actually, only 3 tests require 2+ workers (they fail with export
CILK_NWORKERS=1):
FAIL: c-c++-common/cilk-plus/CK/spawning_arg.c
FAIL: c-c++-common/cilk-plus/CK/steal_check.c
FAIL: g++.dg/cilk-plus/CK/catch_exc.cc

It's unclear what happens with others. Maybe it's a bug in libcilkrts.

[Bug testsuite/64177] Various cilk+ testsuite failures

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-29
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug middle-end/70434] [5/6 Regression] adding an extraneous cast to vector type results in inferior code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 234517)
+++ gcc/c-family/c-common.c (working copy)
@@ -12456,46 +12456,11 @@ convert_vector_to_pointer_for_subscript
 || tree_to_uhwi (index) >= TYPE_VECTOR_SUBPARTS (type))
   warning_at (loc, OPT_Warray_bounds, "index value is out of bound");

-  if (ret)
-   {
- tree tmp = create_tmp_var_raw (type);
- DECL_SOURCE_LOCATION (tmp) = loc;
- *vecp = c_save_expr (*vecp);
- if (TREE_CODE (*vecp) == C_MAYBE_CONST_EXPR)
-   {
- bool non_const = C_MAYBE_CONST_EXPR_NON_CONST (*vecp);
- *vecp = C_MAYBE_CONST_EXPR_EXPR (*vecp);
- *vecp
-   = c_wrap_maybe_const (build4 (TARGET_EXPR, type, tmp,
- *vecp, NULL_TREE, NULL_TREE),
- non_const);
-   }
- else
-   *vecp = build4 (TARGET_EXPR, type, tmp, *vecp,
-   NULL_TREE, NULL_TREE);
- SET_EXPR_LOCATION (*vecp, loc);
- c_common_mark_addressable_vec (tmp);
-   }
-  else
-   c_common_mark_addressable_vec (*vecp);
-  type = build_qualified_type (TREE_TYPE (type), TYPE_QUALS (type));
-  type1 = build_pointer_type (TREE_TYPE (*vecp));
-  bool ref_all = TYPE_REF_CAN_ALIAS_ALL (type1);
-  if (!ref_all
- && !DECL_P (*vecp))
-   {
- /* If the original vector isn't declared may_alias and it
-isn't a bare vector look if the subscripting would
-alias the vector we subscript, and if not, force ref-all.  */
- alias_set_type vecset = get_alias_set (*vecp);
- alias_set_type sset = get_alias_set (type);
- if (!alias_sets_must_conflict_p (sset, vecset)
- && !alias_set_subset_of (sset, vecset))
-   ref_all = true;
-   }
-  type = build_pointer_type_for_mode (type, ptr_mode, ref_all);
-  *vecp = build1 (ADDR_EXPR, type1, *vecp);
-  *vecp = convert (type, *vecp);
+  *vecp = build1 (VIEW_CONVERT_EXPR,
+ build_array_type_nelts (TREE_TYPE (type),
+ TYPE_VECTOR_SUBPARTS (type)),
+ *vecp);
+  c_common_mark_addressable_vec (*vecp);
 }
   return ret;
 }


but note we fail to re-write v into SSA and thus generated code is worse
(but the same for both cases).  .optimized has

bar4 (int x, v4si v)
{
  int _2;
  int _3;
  int _4;
  int _7;

  :
  _2 = VIEW_CONVERT_EXPR(v)[0];
  _3 = VIEW_CONVERT_EXPR(v)[1];
  _4 = _2 ^ _3;
  VIEW_CONVERT_EXPR(v)[0] = _4;
  _7 = VIEW_CONVERT_EXPR(v)[x_6(D)];
  return _7;

where you can see we miss foldings for V_C_E(x)[CST] into
BIT_FIELD_REFs.  It at least avoids taking the address of 'v'.
With a BIT_FIELD_INSERT we could re-write 'v' into SSA.

[Bug c/70436] -Wmisleading-indentation missing warning

[ppalka at gcc dot gnu.org]

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

--- Comment #6 from Patrick Palka  ---
Turns out the prototype is pretty broken :P

[Bug target/67591] ARM v8 Thumb IT blocks deprecated

[jiwang at gcc dot gnu.org]

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

--- Comment #2 from Jiong Wang  ---
*** Bug 69256 has been marked as a duplicate of this bug. ***

[Bug target/69256] Need to get rid of "Warning: IT blocks containing 32-bit Thumb instructions are deprecated in ARMv8"

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

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

--- Comment #2 from Jiong Wang  ---
duplicate pr67591

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

[Bug c++/70393] [5/6 Regression] Miscompilation: missing constructor call for static object

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

[edlinger at gcc dot gnu.org]

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

Bernd Edlinger  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #27 from Bernd Edlinger  ---
Unfortunately this patch was dismissed, see:

https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01502.html

We will update the download_prerequisite for gcc-7 to
use the "latest" available versions, that is generally
agreed upon.

Therefore I have to set this bug to wont-fix.

[Bug middle-end/70434] [5/6 Regression] adding an extraneous cast to vector type results in inferior code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
This started with my PR63764 fix (r217909).
The thing is, when parsing the vector indexing, we still don't know if it is
going to be used as a lvalue or rvalue (and we need to diagnose such uses).

[Bug target/69614] [4.9/5 Regression] wrong code with -Os -fno-expensive-optimizations -fschedule-insns -mtpcs-leaf-frame -fira-algorithm=priority @ armv7a

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #26 from ktkachov at gcc dot gnu.org ---
Fixed then.

[Bug middle-end/70434] [5/6 Regression] adding an extraneous cast to vector type results in inferior code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

--- Comment #3 from Richard Biener  ---
In the end this is because of the unfortunate way we handle vector indexing
(I think we have similar PRs elsewhere where I pasted patches to address this).

The common convert_vector_to_pointer_for_subscript is the culprit here where
we should instead simply convert the vector to an array via a
VIEW_CONVERT_EXPR.

[Bug target/69875] [4.9/5 Regression] Wrong barrier placement for 64-bit atomic loads on arm

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Fixed on all branches.

[Bug target/69875] [4.9/5 Regression] Wrong barrier placement for 64-bit atomic loads on arm

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Mar 29 13:32:37 2016
New Revision: 234522

URL: https://gcc.gnu.org/viewcvs?rev=234522=gcc=rev
Log:
[ARM][4.9 Backport] PR target/69875 Fix atomic_loaddi expansion

PR target/69875
* config/arm/arm.h (TARGET_HAVE_LPAE): Define.
* config/arm/unspecs.md (VUNSPEC_LDRD_ATOMIC): New value.
* config/arm/sync.md (arm_atomic_loaddi2_ldrd): New pattern.
(atomic_loaddi_1): Delete.
(atomic_loaddi): Rewrite expander using the above changes.

* gcc.target/arm/atomic_loaddi_acquire.x: New file.
* gcc.target/arm/atomic_loaddi_relaxed.x: Likewise.
* gcc.target/arm/atomic_loaddi_seq_cst.x: Likewise.
* gcc.target/arm/atomic_loaddi_1.c: New test.
* gcc.target/arm/atomic_loaddi_2.c: Likewise.
* gcc.target/arm/atomic_loaddi_3.c: Likewise.
* gcc.target/arm/atomic_loaddi_4.c: Likewise.
* gcc.target/arm/atomic_loaddi_5.c: Likewise.
* gcc.target/arm/atomic_loaddi_6.c: Likewise.
* gcc.target/arm/atomic_loaddi_7.c: Likewise.
* gcc.target/arm/atomic_loaddi_8.c: Likewise.
* gcc.target/arm/atomic_loaddi_9.c: Likewise.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_1.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_2.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_3.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_4.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_5.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_6.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_9.c
   
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_acquire.x
   
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_relaxed.x
   
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_seq_cst.x
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/arm/arm.h
branches/gcc-4_9-branch/gcc/config/arm/sync.md
branches/gcc-4_9-branch/gcc/config/arm/unspecs.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c/70436] -Wmisleading-indentation missing warning

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Thanks.  I could take care of the C FE side ;).  But let's strike this in the
next stage1.

[Bug middle-end/70434] [5/6 Regression] adding an extraneous cast to vector type results in inferior code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-29
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
The issue starts in the FE:

;; Function foo4 (null)
;; enabled by -tree-original


{
  *(int *)  = *(int *)  ^ *((int *)  + 4);
  return *((int *) _EXPR (v)>> + (sizetype) ((long unsigned int) x * 4));
}


;; Function bar4 (null)
;; enabled by -tree-original


{
  *(int *)  = *(int *)  ^ *((int *)  + 4);
  return *((int *)  + (sizetype) ((long unsigned int) x * 4));
}


notice the extra address-taken temporary D.2617.  We end up with

bar4 (int x, v4si v)
{
  int _2;
  int _3;
  int _4;
  long unsigned int _7;
  long unsigned int _8;
  int * _9;
  int _10;

  :
  _2 = BIT_FIELD_REF ;
  _3 = BIT_FIELD_REF ;
  _4 = _2 ^ _3;
  BIT_FIELD_REF  = _4;
  _7 = (long unsigned int) x_6(D);
  _8 = _7 * 4;
  _9 =  + _8;
  _10 = *_9;
  return _10;

vs.

foo4 (int x, v4si v)
{
  vector(4) int D.2617;
  int _2;
  int _3;
  int _4;
  vector(4) int v.1_6;
  long unsigned int _9;
  long unsigned int _10;
  int * _11;
  int _12;

  :
  _2 = BIT_FIELD_REF ;
  _3 = BIT_FIELD_REF ;
  _4 = _2 ^ _3;
  BIT_FIELD_REF  = _4;
  v.1_6 = v;
  D.2617 = v.1_6;
  _9 = (long unsigned int) x_8(D);
  _10 = _9 * 4;
  _11 =  + _10;
  _12 = *_11;
  return _12;

[Bug target/69875] [4.9/5 Regression] Wrong barrier placement for 64-bit atomic loads on arm

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Mar 29 13:28:34 2016
New Revision: 234521

URL: https://gcc.gnu.org/viewcvs?rev=234521=gcc=rev
Log:
[ARM][5 Backport] PR target/69875 Fix atomic_loaddi expansion

PR target/69875
* config/arm/arm.h (TARGET_HAVE_LPAE): Define.
* config/arm/unspecs.md (VUNSPEC_LDRD_ATOMIC): New value.
* config/arm/sync.md (arm_atomic_loaddi2_ldrd): New pattern.
(atomic_loaddi_1): Delete.
(atomic_loaddi): Rewrite expander using the above changes.

* gcc.target/arm/atomic_loaddi_acquire.x: New file.
* gcc.target/arm/atomic_loaddi_relaxed.x: Likewise.
* gcc.target/arm/atomic_loaddi_seq_cst.x: Likewise.
* gcc.target/arm/atomic_loaddi_1.c: New test.
* gcc.target/arm/atomic_loaddi_2.c: Likewise.
* gcc.target/arm/atomic_loaddi_3.c: Likewise.
* gcc.target/arm/atomic_loaddi_4.c: Likewise.
* gcc.target/arm/atomic_loaddi_5.c: Likewise.
* gcc.target/arm/atomic_loaddi_6.c: Likewise.
* gcc.target/arm/atomic_loaddi_7.c: Likewise.
* gcc.target/arm/atomic_loaddi_8.c: Likewise.
* gcc.target/arm/atomic_loaddi_9.c: Likewise.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_2.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_3.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_4.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_5.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_6.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_7.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_8.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_9.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_acquire.x
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_relaxed.x
branches/gcc-5-branch/gcc/testsuite/gcc.target/arm/atomic_loaddi_seq_cst.x
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/arm/arm.h
branches/gcc-5-branch/gcc/config/arm/sync.md
branches/gcc-5-branch/gcc/config/arm/unspecs.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c/70436] -Wmisleading-indentation missing warning

[ppalka at gcc dot gnu.org]

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

--- Comment #4 from Patrick Palka  ---
Here's a prototype that seems to do the job.  Whenever we see an unbraced if,
increment the counter.  Whenever we see a compound statement, reset the
counter.  Whenever we see an else, warn if counter > 1 and then decrement the
counter.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 2f80856..3ad7196 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -10738,6 +10738,8 @@ cp_parser_expression_statement (cp_parser* parser, tree
in_statement_expr)

Returns a tree representing the statement.  */

+static int num_unbraced_if_statements;
+
 static tree
 cp_parser_compound_statement (cp_parser *parser, tree in_statement_expr,
  int bcs_flags, bool function_body)
@@ -10747,6 +10749,7 @@ cp_parser_compound_statement (cp_parser *parser, tree
in_statement_expr,
   /* Consume the `{'.  */
   if (!cp_parser_require (parser, CPP_OPEN_BRACE, RT_OPEN_BRACE))
 return error_mark_node;
+  num_unbraced_if_statements = 0;
   if (DECL_DECLARED_CONSTEXPR_P (current_function_decl)
   && !function_body && cxx_dialect < cxx14)
 pedwarn (input_location, OPT_Wpedantic,
@@ -10874,6 +10877,7 @@ cp_parser_selection_statement (cp_parser* parser, bool
*if_p,
bool nested_if;
unsigned char in_statement;

+   num_unbraced_if_statements++;
/* Add the condition.  */
finish_if_stmt_cond (condition, statement);

@@ -10898,6 +10902,9 @@ cp_parser_selection_statement (cp_parser* parser, bool
*if_p,
  = get_token_indent_info (cp_lexer_peek_token
(parser->lexer));
/* Consume the `else' keyword.  */
cp_lexer_consume_token (parser->lexer);
+   if (num_unbraced_if_statements > 1)
+ warning_at (input_location, 0, "dangling else");
+   num_unbraced_if_statements--;
if (warn_duplicated_cond)
  {
if (cp_lexer_next_token_is_keyword (parser->lexer,
@@ -11953,6 +11960,7 @@ cp_parser_already_scoped_statement (cp_parser* parser,
 }
   else
 {
+  num_unbraced_if_statements = 0;
   /* Avoid calling cp_parser_compound_statement, so that we
 don't create a new scope.  Do everything else by hand.  */
   cp_parser_require (parser, CPP_OPEN_BRACE, RT_OPEN_BRACE);

[Bug c/70436] -Wmisleading-indentation missing warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-29
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Marek Polacek  ---
FWIW, I also think we should add -Wdangling-else rather than wiring this into
-Wmisleading-indentation.

Confirmed in any case.

[Bug c/70436] -Wmisleading-indentation missing warning

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
This may be tricky to support in -Wmisleading-indentation without introducing
false-positives because we only have the last 3 tokens to work with and don't
know about the location or existence of the topmost if(). 

It should be easy to implement a separate -Wdangling-else warning though that
keeps track of the number of unbraced if()s and warns when encountering an else
with >= 2 unbraced if()s.

[Bug bootstrap/70422] [6 regression] Bootstrap comparison failure

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Presumably the C++ FE should have set DECL_IGNORED_P on the fname decl.

[Bug c/70436] -Wmisleading-indentation missing warning

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Note clang warns here:
pr70405-3.c:11:3: warning: add explicit braces to avoid dangling else
[-Wdangling-else]
  else
  ^
and it warns regardless of the indentation.

[Bug c/70436] New: -Wmisleading-indentation missing warning

[jakub at gcc dot gnu.org]

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

Bug ID: 70436
   Summary: -Wmisleading-indentation missing warning
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

In PR70405 I've run into something we should IMNSHO definitely warn about:

void bar (int, int);

void
foo (int x, int y, int z)
{
  int i;
  if (x)
for (i = 0; i < 64; i++)
  if (y)
bar (1, i);
  else
for (i = 0; i < 64; i++)
  if (z)
bar (2, i);
}

but -W -Wall is quiet on this.  Here the else is indented as the code was meant
to work, but is actually parsed as
  if (x)
for (i = 0; i < 64; i++)
  if (u)
bar (1, i);
  else
for (i = 0; i < 64; i++)
  if (z)
bar (2, i);

[Bug fortran/70397] [5/6 Regression] ice while allocating ultimate polymorphic

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #3 from vehre at gcc dot gnu.org ---
Waiting for review of patch for trunk.

[Bug tree-optimization/70405] [6 Regression] -fcompare-debug failure with -mavx512f

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 38120
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38120=edit
gcc6-pr70405.patch

Untested fix.

[Bug c/70407] alignment of array elements is greater than element size

[dxin at usc dot edu]

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

--- Comment #2 from Dehuan Xin  ---
(In reply to Richard Biener from comment #1)
> Confirmed as a documentation issue.  Note that
> 
> typedef struct S_ { short f[3] __attribute((aligned(8))); } S;
> 
> works (and increases sizeof (S_)).

So for a struct, aligning the first field of it is effectively aligning the
struct.

But that seems a variable attribute rather than type attribute, a very
different usage. (as is documented here
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes).

And for 

typedef int more_aligned_int __attribute__ ((aligned (8)));

it's still an issue.

[Bug c/70418] VM structure type specifier in list of parameter declarations within nested function definition ices.

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Even r104500 ICEs.  But gcc34 compiles it fine:

$ gcc34 q.c -c
q.c: In function `main':
q.c:4: warning: structure defined inside parms
q.c:4: warning: anonymous struct declared inside parameter list
q.c:4: warning: its scope is only this definition or declaration, which is
probably not what you want

[Bug c/70418] VM structure type specifier in list of parameter declarations within nested function definition ices.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-29
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Marek Polacek  ---
Confirmed.  Looks similar to PR60085.

[Bug c++/70435] New: section attribute of a function template is not honored.

[kukyakya at gmail dot com]

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

Bug ID: 70435
   Summary: section attribute of a function template is not
honored.
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kukyakya at gmail dot com
  Target Milestone: ---

namespace /* anonymous */
{
  [[gnu::section(".mysection")]]
  void regular_func() { }

  template 
  [[gnu::section(".mysection")]]
  void template_func() { }
} // namespace /* anonymous */

void (*ptr1)() = _func;
void (*ptr2)() = _func;


In the code above the section attribute is given to both of the regular
function and the function template, but the templated function is not placed in
.mysection but .text.

$ g++ -std=c++14 a.cpp -c && objdump -t a.o | grep -E "regular|template"
 l F .mysection 0007
_ZN12_GLOBAL__N_112regular_funcEv
 l F .text  0007
_ZN12_GLOBAL__N_113template_funcIiEEvv
~/temp/c++/function_template_section $ 


I also tried it with clang and clang put the function into .mysection as I
expected.


$ clang++ -std=c++14 a.cpp -c && objdump -t a.o | grep -E "regular|template"
 l F .mysection 0006
_ZN12_GLOBAL__N_112regular_funcEv
0010 l F .mysection 0006
_ZN12_GLOBAL__N_113template_funcIiEEvv

[Bug middle-end/70424] [4.9/5 Regression] Pointer derived from integer gets reduced alignment

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug middle-end/70424] [4.9/5 Regression] Pointer derived from integer gets reduced alignment

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.8.5, 6.0
Summary|[4.9/5/6 Regression]|[4.9/5 Regression] Pointer
   |Pointer derived from|derived from integer gets
   |integer gets reduced|reduced alignment
   |alignment   |

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

[Bug middle-end/70424] [4.9/5/6 Regression] Pointer derived from integer gets reduced alignment

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Mar 29 12:36:39 2016
New Revision: 234517

URL: https://gcc.gnu.org/viewcvs?rev=234517=gcc=rev
Log:
2016-03-29  Richard Biener  

PR middle-end/70424
* ipa-prop.c (ipa_compute_jump_functions_for_edge): Always
use alignment returned by get_pointer_alignment_1 if it is
bigger than BITS_PER_UNIT.
* builtins.c (get_pointer_alignment_1): Do not return true
for alignment extracted from SSA info.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/ipa-prop.c