[Bug tree-optimization/67618] malloc+memset optimization breaks code

[roc at ocallahan dot org]

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

--- Comment #14 from roc at ocallahan dot org  ---
Argh, I see this was already mentioned, sorry for the noise.

[Bug tree-optimization/67618] malloc+memset optimization breaks code

[roc at ocallahan dot org]

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

roc at ocallahan dot org  changed:

   What|Removed |Added

 CC||roc at ocallahan dot org

--- Comment #13 from roc at ocallahan dot org  ---
Here's one case where this optimization really is invalid: when you're
compiling an implementation of calloc() :-(.

[Bug tree-optimization/63748] [4.9 Regression] wrong may be used uninitialized warning (abnormal edges)

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|4.9.4   |5.0

--- Comment #12 from Alan Modra  ---
Doesn't seem worth backporting now

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[amodra at gmail dot com]

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

Bug 63748 Summary: [4.9 Regression] wrong may be used uninitialized warning 
(abnormal edges)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63748

   What|Removed |Added

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

[Bug tree-optimization/71328] [7 Regression] ice in verify_jump_thread

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
*** Bug 71341 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/71341] [7 Regression] ICE at -O2 and -O3 in 32-bit and 64-bit modes on x86_64-linux-gnu (Segmentation fault, duplicate_thread_path)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
Same root cause as 71328.

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

[Bug tree-optimization/71328] [7 Regression] ice in verify_jump_thread

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Should be fixed on the trunk.

[Bug tree-optimization/71328] [7 Regression] ice in verify_jump_thread

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Fri Jun  3 05:20:16 2016
New Revision: 237052

URL: https://gcc.gnu.org/viewcvs?rev=237052&root=gcc&view=rev
Log:
PR tree-optimization/71328
* tree-ssa-threadupdate.c (duplicate_thread_path): Fix off-by-one
error when checking for a jump back onto the copied path.  */

PR tree-optimization/71328
* gcc.c-torture/compile/pr71328.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr71328.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadupdate.c

[Bug c++/71378] A compilable file fails to compile when ASAN options are specified

[asankau at millenniumit dot com]

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

--- Comment #3 from asankau at millenniumit dot com ---
Hi,
Is there a workaround to this problem ? (I mean is there anything that I can do
to the source code of FGConfig.cpp to get rid of this error.)

[Bug fortran/52393] I/O: "READ format" statement with parenthesed default-char-expr

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #13 from Jerry DeLisle  ---
Fixed on trunk and closing

[Bug fortran/52393] I/O: "READ format" statement with parenthesed default-char-expr

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Jun  3 01:25:31 2016
New Revision: 237051

URL: https://gcc.gnu.org/viewcvs?rev=237051&root=gcc&view=rev
Log:
2016-06-02  Jerry DeLisle  

PR fortran/52393
* gfortran.dg/fmt_read_3.f90: Fix typo.
* gfortran.dg/fmt_read_4.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_read_4.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/fmt_read_3.f90

[Bug c/71392] SEGV calling integer overflow built-ins with a null pointer

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00236.html

[Bug target/71390] PowerPC GCC should warn if use does -mcpu=, and an old assembler was used

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-02
 Ever confirmed|0   |1

--- Comment #1 from Bill Schmidt  ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957 is an example of a recent
issue of this nature.

[Bug target/71395] New: PowerPC vec_init of 4 SFmode values could be improved on Power8

[meissner at gcc dot gnu.org]

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

Bug ID: 71395
   Summary: PowerPC vec_init of 4 SFmode values could be improved
on Power8
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

The code for combining 4 SFmode values into a V4SFmode could be improved in
GCC.

For example:

#include 

vector combine (float a, float b, float c, float d)
{
  return (vector float) { a, b, c, d };
}

Generates:

.file   "foo.c"
.section".text"
.align 2
.p2align 4,,15
.globl merge
.section".opd","aw"
.align 3
merge:
.quad   .L.merge,.TOC.@tocbase,0
.previous
.type   merge, @function
.L.merge:
addis 9,2,.LC0@toc@ha
xxpermdi 34,2,1,0
xxpermdi 32,4,3,0
addi 9,9,.LC0@toc@l
xvcvdpsp 32,32
xvcvdpsp 34,34
lxvd2x 33,0,9
xxpermdi 33,33,33,2
vperm 2,0,2,1
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size   merge,.-.L.merge
.section.rodata.cst16,"aM",@progbits,16
.align 4
.LC0:
.byte   31
.byte   30
.byte   29
.byte   28
.byte   23
.byte   22
.byte   21
.byte   20
.byte   15
.byte   14
.byte   13
.byte   12
.byte   7
.byte   6
.byte   5
.byte   4

If you build the 2 V2DF temporaries differently, you could use the VMRGEW and
VMRGOW instructions to do the final combination instead of loading up a permute
mask and doing a VPERM instruction.

[Bug c++/71394] New: -Werror=conversion-null identifies incorrect data member of member initializer list

[mitchjcarlson at gmail dot com]

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

Bug ID: 71394
   Summary: -Werror=conversion-null identifies incorrect data
member of member initializer list
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mitchjcarlson at gmail dot com
  Target Milestone: ---

Created attachment 38632
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38632&action=edit
preprocessed file

In the below example, we can see that the error message produced from the
compiler incorrectly identifies a data member which is in violation of our
Werror. The current error message is misleading.

#include 

struct ErrorConversionNullBug
{
ErrorConversionNullBug()
: n(NULL)
, c('c')
{}
unsigned int n;
const char c;
};

int main()
{
ErrorConversionNullBug bug;
}

$ /opt/gcc/4.8.2/bin/g++48 -v -save-temps -Werror=conversion-null -o main
main.cpp
Using built-in specs.
COLLECT_GCC=/opt/gcc/4.8.2/bin/g++48
COLLECT_LTO_WRAPPER=/opt/gcc/4.8.2/libexec/gcc/i686-pc-linux-gnu/4.8.2/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/opt/gcc/4.8.2 --enable-languages=c,c++
--program-suffix=48 --with-as=/opt/binutils/2.24/bin/as24
--with-ld=/opt/binutils/2.24/bin/ld24
Thread model: posix
gcc version 4.8.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Werror=conversion-null' '-o' 'main'
'-shared-libgcc' '-mtune=generic' '-march=pentiumpro'
 /opt/gcc/4.8.2/libexec/gcc/i686-pc-linux-gnu/4.8.2/cc1plus -E -quiet -v
-D_GNU_SOURCE main.cpp -mtune=generic -march=pentiumpro -Werror=conversion-null
-fpch-preprocess -o main.ii
ignoring nonexistent directory
"/opt/gcc/4.8.2/lib/gcc/i686-pc-linux-gnu/4.8.2/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/gcc/4.8.2/lib/gcc/i686-pc-linux-gnu/4.8.2/../../../../include/c++/4.8.2

/opt/gcc/4.8.2/lib/gcc/i686-pc-linux-gnu/4.8.2/../../../../include/c++/4.8.2/i686-pc-linux-gnu

/opt/gcc/4.8.2/lib/gcc/i686-pc-linux-gnu/4.8.2/../../../../include/c++/4.8.2/backward
 /opt/gcc/4.8.2/lib/gcc/i686-pc-linux-gnu/4.8.2/include
 /usr/local/include
 /opt/gcc/4.8.2/include
 /opt/gcc/4.8.2/lib/gcc/i686-pc-linux-gnu/4.8.2/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Werror=conversion-null' '-o' 'main'
'-shared-libgcc' '-mtune=generic' '-march=pentiumpro'
 /opt/gcc/4.8.2/libexec/gcc/i686-pc-linux-gnu/4.8.2/cc1plus -fpreprocessed
main.ii -quiet -dumpbase main.cpp -mtune=generic -march=pentiumpro -auxbase
main -Werror=conversion-null -version -o main.s
GNU C++ (GCC) version 4.8.2 (i686-pc-linux-gnu)
compiled by GNU C version 4.8.2, GMP version 5.1.1, MPFR version 3.1.1,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.8.2 (i686-pc-linux-gnu)
compiled by GNU C version 4.8.2, GMP version 5.1.1, MPFR version 3.1.1,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 966073129663909613ddef5561ea5ee6
main.cpp: In constructor 'ErrorConversionNullBug::ErrorConversionNullBug()':
main.cpp:7:16: error: converting to non-pointer type 'unsigned int' from NULL
[-Werror=conversion-null]
 , c('c')
^
cc1plus: some warnings being treated as errors

$ lscpu
Architecture:  i686
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):0
Vendor ID: GenuineIntel
CPU family:6
Model: 63
Stepping:  2
CPU MHz:   2600.007
BogoMIPS:  5199.24
Virtualization:VT-x

$ cat /proc/version
Linux version 2.6.32-573.8.1.el6.x86_64 (mockbu...@c6b8.bsys.dev.centos.org)
(gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) ) #1 SMP Tue Nov 10
18:01:38 UTC 2015

[Bug c++/71393] [6.1 Regression] Compilation hang

[terra at gnome dot org]

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

--- Comment #3 from M Welinder  ---
Bug 70847 claims "virtual" is necessary, so that is probably unrelated.
This bug is "virtual"-free.

[Bug c/71392] SEGV calling integer overflow built-ins with a null pointer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-02
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
The root cause of this is that the built-ins are declared without the non-null
attribute (analogous to, for example, __builtin_strlen).  With the attribute
added, GCC issues a warning when it sees an invocation of one like the one in
comment #0:

zzz.cpp:3:67: warning: null argument where non-null required (argument 3)
[-Wnonnull]
   __builtin_printf ("%i\n", __builtin_sadd_overflow (1, 2, (int*)0));
   ^

Since I'm working in this area let me put together a complete patch.

[Bug c++/71393] [6.1 Regression] Compilation hang

[sirl at gcc dot gnu.org]

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

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #2 from Franz Sirl  ---
Looks like a duplicate of bug 70847 or bug 71330?

[Bug c++/71377] SFINAE expression compiles, but it should not because of 14.5.5p8

[michele.caini at gmail dot com]

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

--- Comment #2 from Michele Caini  ---
Right, got it.
Actually it's more like a complex way of writing a static assert.
Should it be considered a bug anyway? I mean, it's correct for GCC to accept it
or it should reject the code?
I'm not skilled enough to say how the standard applies in this case, I'm sorry.

[Bug c++/71393] [6.1 Regression] Compilation hang

[terra at gnome dot org]

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

--- Comment #1 from M Welinder  ---
Created attachment 38631
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38631&action=edit
Preprocessed version of MyClass.C

[Bug c++/71393] New: [6.1 Regression] Compilation hang

[terra at gnome dot org]

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

Bug ID: 71393
   Summary: [6.1 Regression] Compilation hang
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org
  Target Milestone: ---

Created attachment 38630
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38630&action=edit
MyClass.C

g++ -fsanitize=undefined -Wall -c -g -O2 MyClass.C
[hangs]

This didn't happen in 5.3


Using built-in specs.
COLLECT_GCC=/usr/local/products/gcc/6.1.0/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/products/gcc/6.1.0/lib/gcc/x86_64-suse-linux/6.1.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../../gcc-6.1.0/configure --enable-languages=c,c++,fortran
--enable-targets=x86_64-suse-linux,i686-suse-linux
--prefix=/usr/local/products/gcc/6.1.0 --with-gnu-as
--with-as=/usr/local/products/gcc/binutils-2.26/bin/as --with-gnu-ld
--with-ld=/usr/local/products/gcc/binutils-2.26/bin/ld.bfd
--with-gmp=/usr/local/products/gcc/gmp-6.1.0
--with-mpfr=/usr/local/products/gcc/mpfr-3.1.4
--with-mpc=/usr/local/products/gcc/mpc-1.0.3 --enable-threads=posix
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=pool
x86_64-suse-linux
Thread model: posix
gcc version 6.1.0 (GCC)

[Bug c/71392] New: SEGV calling integer overflow built-ins with a null pointer

[msebor at gcc dot gnu.org]

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

Bug ID: 71392
   Summary: SEGV calling integer overflow built-ins with a null
pointer
   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: ---

All versions of GCC that support the built-ins for Integer Arithmetic with
Overflow Checking allow callers to pass a null constant pointer as the last
argument.  As one might expect, a program that evaluates the call then crashes
due to the write.  The built-ins should detect when the argument is a null
constant pointer and reject the call.

$ cat zzz.cpp && ~/bin/gcc-5.1.0/bin/gcc -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout zzz.cpp && ./a.out
int main ()
{
  __builtin_printf ("%i\n", __builtin_sadd_overflow (1, 2, (int*)0));
}

;; Function int main() (main, funcdef_no=0, decl_uid=2324, cgraph_uid=0,
symbol_order=0)

int main() ()
{
  int D.2332;
  int D.2331;
  int D.2330;
  int D.2329;
  complex int D.2328;
  int * D.2327;
  int * _1;
  complex int _2;
  int _3;
  int _6;
  int _7;
  int _9;

  :
  _1 = 0B;
  _2 = __complex__ (3, 0);
  _3 = REALPART_EXPR <_2>;
  *_1 = _3;
  _6 = IMAGPART_EXPR <_2>;
  _7 = _6 & 1;
  __builtin_printf ("%i\n", _7);
  _9 = 0;

:
  return _9;

}


Segmentation fault (core dumped)

[Bug fortran/70350] [5 Regression] ICE with -fcheck=all and array initialization

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #9 from Paul Thomas  ---
I have backported the fix from trunk/6-branch. I didn't add a testcase since
The probability of any further changes causing a regression is zero.

Thanks for the report. I am sorry that this has caused some inconvenience.
However, as a volunteer, sometimes life outside gfortran intervenes, as it did
here.

Paul

[Bug fortran/70350] [5 Regression] ICE with -fcheck=all and array initialization

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
Author: pault
Date: Thu Jun  2 17:44:59 2016
New Revision: 237043

URL: https://gcc.gnu.org/viewcvs?rev=237043&root=gcc&view=rev
Log:
2016-06-02  Paul Thomas  

PR fortran/70350
Backport from trunk.
* trans-expr.c (gfc_trans_assignment_1): Exclude initialization
assignments from check on assignment of scalars to unassigned
arrays and correct wrong code within the corresponding block.

Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-expr.c

[Bug rtl-optimization/59511] [4.9 Regression] FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa with -mtune=corei7

[peter at cordes dot ca]

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

--- Comment #7 from Peter Cordes  ---
I'm seeing the same symptom, affecting gcc4.9 through 5.3.  Not present in 6.1.

IDK if the cause is the same.

(code from an improvement to the horizontal_add functions in Agner Fog's vector
class library)

#include 
int hsum16_gccmovdqa (__m128i const a) {
__m128i lo= _mm_cvtepi16_epi32(a); // sign-extended
a0, a1, a2, a3
__m128i hi= _mm_unpackhi_epi64(a,a); // gcc4.9 through 5.3
wastes a movdqa on this
hi= _mm_cvtepi16_epi32(hi);
__m128i sum1  = _mm_add_epi32(lo,hi);  // add
sign-extended upper / lower halves
//return horizontal_add(sum1);  // manually inlined.
// Shortening the code below can avoid the movdqa
__m128i shuf  = _mm_shuffle_epi32(sum1, 0xEE);
__m128i sum2  = _mm_add_epi32(shuf,sum1);  // 2 sums
shuf  = _mm_shufflelo_epi16(sum2, 0xEE);
__m128i sum4  = _mm_add_epi32(shuf,sum2);
return  _mm_cvtsi128_si32(sum4);   // 32 bit sum
}

gcc4.9 through gcc5.3 output (-O3 -mtune=generic -msse4.1):

movdqa  %xmm0, %xmm1
pmovsxwd%xmm0, %xmm2
punpckhqdq  %xmm0, %xmm1
pmovsxwd%xmm1, %xmm0
paddd   %xmm2, %xmm0
...

gcc6.1 output:

pmovsxwd%xmm0, %xmm1
punpckhqdq  %xmm0, %xmm0
pmovsxwd%xmm0, %xmm0
paddd   %xmm0, %xmm1
...



In a more complicated case, when inlining this code or not, there's actually a
difference between gcc 4.9 and 5.x: gcc5 has the extra movdqa in more cases. 
See my attachment, copied from https://godbolt.org/g/e8iQsj

[Bug rtl-optimization/59511] [4.9 Regression] FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa with -mtune=corei7

[peter at cordes dot ca]

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

Peter Cordes  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #6 from Peter Cordes  ---
Created attachment 38629
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38629&action=edit
extra-movdqa-with-gcc5-not-4.9.cpp

[Bug c/71362] Wrong position for "error: size of unnamed array is negative"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-02
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/71391] New: error on aggregate initialization with side-effects in a constexpr function

[msebor at gcc dot gnu.org]

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

Bug ID: 71391
   Summary: error on aggregate initialization with side-effects in
a constexpr function
   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: ---

All versions of GCC reject the following valid C++ 14 program.  (Clang and EDG
accept it as expected.)

$ cat zzz.cpp && /home/msebor/build/gcc-6-branch/gcc/xgcc -B
/home/msebor/build/gcc-6-branch/gcc -S -Wall -Wextra -Wpedantic zzz.cpp 
struct S { int a, b; };

constexpr S f ()
{
  int x = 0;
  S z = { 0, ++x }; 
  return z;
}

constexpr S s = f ();

static_assert (s.a + 1 == s.b, "");
zzz.cpp:12:1: error: non-constant condition for static assertion
 static_assert (s.a + 1 == s.b, "");
 ^
zzz.cpp:12:1: error: the value of ‘s’ is not usable in a constant expression
zzz.cpp:10:13: note: ‘s’ used in its own initializer
 constexpr S s = f ();
 ^

[Bug target/71390] PowerPC GCC should warn if use does -mcpu=, and an old assembler was used

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org

[Bug target/71390] New: PowerPC GCC should warn if use does -mcpu=, and an old assembler was used

[meissner at gcc dot gnu.org]

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

Bug ID: 71390
   Summary: PowerPC GCC should warn if use does -mcpu=, and
an old assembler was used
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

When you configure a PowerPC compiler with an old assembler, it configures the
compiler so it does not generate the new instructions.  In these cases, the
compiler should issue a warning if you use a -mcpu= and the assembler does
not support .

[Bug c++/71372] [6/7 Regression] C++ FE drops TREE_THIS_VOLATILE in cp_fold on all tcc_reference trees

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jun  2 16:43:04 2016
New Revision: 237042

URL: https://gcc.gnu.org/viewcvs?rev=237042&root=gcc&view=rev
Log:
PR c++/71372
* cp-gimplify.c (cp_fold): For INDIRECT_REF, if the folded expression
is INDIRECT_REF or MEM_REF, copy over TREE_READONLY, TREE_SIDE_EFFECTS
and TREE_THIS_VOLATILE flags.  For ARRAY_REF and ARRAY_RANGE_REF, copy
over TREE_READONLY, TREE_SIDE_EFFECTS and TREE_THIS_VOLATILE flags
to the newly built tree.

* c-c++-common/pr71372.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/pr71372.c
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/cp-gimplify.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/71372] [6/7 Regression] C++ FE drops TREE_THIS_VOLATILE in cp_fold on all tcc_reference trees

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jun  2 16:36:04 2016
New Revision: 237041

URL: https://gcc.gnu.org/viewcvs?rev=237041&root=gcc&view=rev
Log:
PR c++/71372
* cp-gimplify.c (cp_fold): For INDIRECT_REF, if the folded expression
is INDIRECT_REF or MEM_REF, copy over TREE_READONLY, TREE_SIDE_EFFECTS
and TREE_THIS_VOLATILE flags.  For ARRAY_REF and ARRAY_RANGE_REF, copy
over TREE_READONLY, TREE_SIDE_EFFECTS and TREE_THIS_VOLATILE flags
to the newly built tree.

* c-c++-common/pr71372.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr71372.c
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/71377] SFINAE expression compiles, but it should not because of 14.5.5p8

[schaub.johannes at googlemail dot com]

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

Johannes Schaub  changed:

   What|Removed |Added

 CC||schaub.johannes@googlemail.
   ||com

--- Comment #1 from Johannes Schaub  ---
GCC should also diagnose the use of `S` at instantiation time, right?
`S<2, 1>` is always going to be ill-formed, given that the type of the third
argument is ill-formed for N=M+1=2. 

This is not SFINAE.

[Bug c++/71388] [6/7 regression] wrong code, DSE removes memset in TBB allocate_scheduler (causes run-time crashes)

[david.abdurachmanov at gmail dot com]

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

--- Comment #7 from David Abdurachmanov  
---
Just for reference (if someone reads this PR):
https://gcc.gnu.org/ml/gcc/2016-02/msg00205.html

It contains a reference to C++ standard.

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
OK, I've traced this down to its sordid origins.  The problem arises when the
test case is run on a machine using an old target assembler.  If the assembler
doesn't support POWER8 instructions, this causes TARGET_P8_VECTOR to be
disabled.  If TARGET_P8_VECTOR is disabled, TARGET_P9_VECTOR is likewise
disabled, which means that the P9-specific built-ins are not tied to the
built-in overload table.

So even though these tests are compile-only, the configuration test that
determines the assembler isn't up to speed causes these tests to fail.  I'll
have to add a dg-require-effective-target to fix this.

[Bug c++/71388] [6/7 regression] wrong code, DSE removes memset in TBB allocate_scheduler (causes run-time crashes)

[david.abdurachmanov at gmail dot com]

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

--- Comment #6 from David Abdurachmanov  
---
Agreed. As usual, thanks for verifying this. Will cook and send a patch to TBB.

[Bug middle-end/71387] [6/7 Regression] ICE in emit_move_insn, at expr.c:3418 with -Og

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-06-02
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug c++/71388] [6/7 regression] wrong code, DSE removes memset in TBB allocate_scheduler (causes run-time crashes)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
You can use -flifetime-dse=1 or -fno-lifetime-dse to work around this, but
better fix TBB, this really isn't valid C++.

[Bug c++/71388] [6/7 regression] wrong code, DSE removes memset in TBB allocate_scheduler (causes run-time crashes)

[sch...@linux-m68k.org]

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

--- Comment #4 from Andreas Schwab  ---
You should initialize the object in the constructor.

[Bug target/71389] New: ICE on trunk gcc on ivybridge target (df_refs_verify)

[anton.mitrokhin at phystech dot edu]

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

Bug ID: 71389
   Summary: ICE on trunk gcc on ivybridge target (df_refs_verify)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton.mitrokhin at phystech dot edu
  Target Milestone: ---

Created attachment 38627
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38627&action=edit
Reproducer

Reproducer:
>  g++ -std=c++11 -O3 -march=ivybridge -o out.o -c crash.cpp

Output:
crash.cpp: In function 'void fn1()':
crash.cpp:23:1: internal compiler error: in df_refs_verify, at df-scan.c:4033
 }
 ^
0x9b0f62 df_refs_verify
/export/users/gnutester/stability/svn/trunk/gcc/df-scan.c:4033
0x9b6a16 df_insn_refs_verify
/export/users/gnutester/stability/svn/trunk/gcc/df-scan.c:4115
0x9b6fb3 df_bb_verify
/export/users/gnutester/stability/svn/trunk/gcc/df-scan.c:4142
0x9ba5f7 df_scan_verify()
/export/users/gnutester/stability/svn/trunk/gcc/df-scan.c:4274
0x9a5384 df_verify()
/export/users/gnutester/stability/svn/trunk/gcc/df-core.c:1831
0x9a5384 df_analyze_1
/export/users/gnutester/stability/svn/trunk/gcc/df-core.c:1217
0xba613e ira
/export/users/gnutester/stability/svn/trunk/gcc/ira.c:5137
0xba613e execute
/export/users/gnutester/stability/svn/trunk/gcc/ira.c:5525
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

> gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/export/users/amitrokh/gcc_trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /export/users/gnutester/stability/svn/trunk/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --with-pkgversion=Revision=237011/svn-rev:237016/
--prefix=/export/users/gnutester/stability/work/trunk/64/install
--enable-languages=c,c++,fortran,java,lto
Thread model: posix
gcc version 7.0.0 20160601 (experimental) (Revision=237011/svn-rev:237016/)

[Bug c++/71388] [6/7 regression] wrong code, DSE removes memset in TBB allocate_scheduler (causes run-time crashes)

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Gcc considers the memset as being dead as nothing validly can assume anything
about the memory after the inplacement new.

[Bug c++/71388] [6/7 regression] wrong code, DSE removes memset in TBB allocate_scheduler (causes run-time crashes)

[david.abdurachmanov at gmail dot com]

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

--- Comment #2 from David Abdurachmanov  
---
Doesn't std::memset apply here? They allocate storage, set it to 0x0 and then
place construct the object.

At first look I wouldn't expect GCC to remove std::memset.

[Bug c++/71388] [6/7 regression] wrong code, DSE removes memset in TBB allocate_scheduler (causes run-time crashes)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
This is not a gcc bug. After a placement new, what the values were in that
memory is undefined.

[Bug c++/71388] New: [6/7 regression] wrong code, DSE removes memset in TBB allocate_scheduler (causes run-time crashes)

[david.abdurachmanov at gmail dot com]

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

Bug ID: 71388
   Summary: [6/7 regression] wrong code, DSE removes memset in TBB
allocate_scheduler (causes run-time crashes)
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com
  Target Milestone: ---

Created attachment 38626
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38626&action=edit
pre-processed file

We found this crashing one of our test cases in GCC 6.1.1 port of our software.
Looks like wrong code in Intel TBB.

TBB version: tbb44_20151115oss (also affects newer versions)
First bad commit: 8a36d0ec201ef1511b372523f72a763b836107b0 or r222135
Last good commit: 8b2942f7c961ee83bb0ff605129165ecdf6ac8f6 or r222134

Potentially wrongly compiled code is from src/tbb/custom_scheduler.h

111 public:
112 static generic_scheduler* allocate_scheduler( market& m ) {
113 void* p = NFS_Allocate(1, sizeof(scheduler_type), NULL);
114 std::memset(p, 0, sizeof(scheduler_type));
115 scheduler_type* s = new( p ) scheduler_type( m );
116 s->assert_task_pool_valid();
117 ITT_SYNC_CREATE(s, SyncType_Scheduler, SyncObj_TaskPoolSpinning);
118 return s;
119 }

>From our developer: What is happening is a class instance is being created with
placement new where the address is reused from a thread which has gone away.
However, (at least) one of the member data of the newly created object is non-0
and it is that non-0 value which ultimately leads to the crash.

Object size here is 408 bytes. A call to memset is not generated and don't seem
to be inlined also.

Can be cured if TTB is compiled with CXXFLAGS='-fno-builtin-memset' which will
force GCC to generate a call to memset.

Below you can find examples of
tbb::internal::custom_scheduler::allocate_scheduler(tbb::internal::market&)
symbol with good and bad GCC revision.

Note that in bad revision we lost: rep stos %rax,%es:(%rdi)

Attaching pre-processed scheduler.ii (not a minimal test case), compiled as:
g++ -o scheduler.o -c -g -O2 -m64 -mrtm -fPIC scheduler.ii

### GOOD ###

00023df0
::allocate_scheduler(tbb::internal::market&)>:
   23df0:   55  push   %rbp
   23df1:   53  push   %rbx
   23df2:   31 d2   xor%edx,%edx
   23df4:   48 89 fdmov%rdi,%rbp
   23df7:   be 98 01 00 00  mov$0x198,%esi
   23dfc:   bf 01 00 00 00  mov$0x1,%edi
   23e01:   48 83 ec 08 sub$0x8,%rsp
   23e05:   e8 96 9a fe ff  callq  d8a0

   23e0a:   48 8d 78 08 lea0x8(%rax),%rdi
   23e0e:   48 89 c1mov%rax,%rcx
   23e11:   48 89 c3mov%rax,%rbx
   23e14:   48 c7 00 00 00 00 00movq   $0x0,(%rax)
   23e1b:   48 c7 80 90 01 00 00movq   $0x0,0x190(%rax)
   23e22:   00 00 00 00
   23e26:   31 c0   xor%eax,%eax
   23e28:   48 83 e7 f8 and$0xfff8,%rdi
   23e2c:   48 89 eemov%rbp,%rsi
   23e2f:   48 29 f9sub%rdi,%rcx
   23e32:   81 c1 98 01 00 00   add$0x198,%ecx
   23e38:   c1 e9 03shr$0x3,%ecx
   23e3b:   f3 48 abrep stos %rax,%es:(%rdi)
   23e3e:   48 89 dfmov%rbx,%rdi
   23e41:   e8 5a e4 ff ff  callq  222a0

   23e46:   48 8d 05 13 1c 21 00lea0x211c13(%rip),%rax#
235a60 >
   23e4d:   48 83 c0 10 add$0x10,%rax
   23e51:   48 89 03mov%rax,(%rbx)
   23e54:   48 8d 05 35 2b 21 00lea0x212b35(%rip),%rax#
236990 <__itt_sync_create_ptr__3_0>
   23e5b:   48 8b 00mov(%rax),%rax
   23e5e:   48 85 c0test   %rax,%rax
   23e61:   74 1e   je 23e81
::allocate_scheduler(tbb::internal::market&)+0x91>
   23e63:   48 8d 15 fe 25 21 00lea0x2125fe(%rip),%rdx#
236468 
   23e6a:   48 8d 35 2f 26 21 00lea0x21262f(%rip),%rsi#
2364a0 
   23e71:   b9 02 00 00 00  mov$0x2,%ecx
   23e76:   48 89 dfmov%rbx,%rdi
   23e79:   48 8b 12mov(%rdx),%rdx
   23e7c:   48 8b 36mov(%rsi),%rsi
   23e7f:   ff d0   callq  *%rax
   23e81:   48 83 c4 08 add$0x8,%rsp
   23e85:   48 89 d8mov%rbx,%rax
   23e88:   5b  pop%rbx
   23e89:   5d  pop%rbp
   23e8a:   c3  retq
   23e8b:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)

##

[Bug middle-end/71387] [6/7 Regression] ICE in emit_move_insn, at expr.c:3418 with -Og

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

  Known to work||5.3.1
   Target Milestone|--- |7.0
  Known to fail||6.1.1, 7.0

[Bug c++/71378] A compilable file fails to compile when ASAN options are specified

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Reduced test-case:

$ cat tc.ii
class A {
public:
  int GetLen();
};
class B {
  A s_MDSPartIDStr;
  void FillLoadPartitionInfo();
};
void B::FillLoadPartitionInfo() { char a[s_MDSPartIDStr.GetLen()] = ""; }

$ (gdb) p debug_tree(decl)
 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x768855e8
precision 8 min  max 
pointer_to_this >
sizes-gimplified BLK
size 
unsigned ignored TI file
/home/marxin/Programming/testcases/PR71378/tc.ii line 9 col 40
size 
unit size 
align 128 context  chain >
unit size 
unsigned ignored DI file
/home/marxin/Programming/testcases/PR71378/tc.ii line 9 col 40
size 
unit size 
align 64 context  chain >
align 8 symtab 0 alias set -1 structural equality
domain 
sizes-gimplified type_6 DI size 
unit size 
align 64 symtab 0 alias set -1 structural equality precision 64 min
 max >
pointer_to_this >
readonly addressable asm_written static ignored in-constant-pool BLK file
(null) line 0 col 0 size  unit size 
align 256 initial >

Problem is that unit size of the VAR_DECL is not an integer constant.

[Bug c++/71378] A compilable file fails to compile when ASAN options are specified

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug middle-end/71387] [6/7 Regression] ICE in emit_move_insn, at expr.c:3418 with -Og

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
class EPoint {
 public:
  inline EPoint();
  inline EPoint( const EPoint &p );
};
class EPointIteratorBase {
 public:
  explicit EPointIteratorBase( unsigned long size )
  : m_index(0), m_sourceIsPrimitive(true)
{ }
  EPoint m_actPoint;
  unsigned long m_index;
  int m_sourceIsPrimitive;
};
class EProperties { };
class EPrimitive {
 protected:
  explicit EPrimitive( const EProperties* inProps ) { }
};
class ERectangleBase : public EPrimitive
{
 public:
  ERectangleBase( const EProperties* inProps ) : EPrimitive( inProps ) { }
  virtual EPoint getLowerRight() const = 0;
  virtual EPoint getLowerLeft() const = 0;
};
class EPointIteratorRectangleBase : public EPointIteratorBase
{
  inline void _setPoint();
  EPointIteratorRectangleBase( const ERectangleBase *rectBase );
  const ERectangleBase *m_rectBase;
};
inline void EPointIteratorRectangleBase::_setPoint() {
  if( m_index == 0 )
   m_actPoint = m_rectBase->getLowerLeft();
  else
m_actPoint = m_rectBase->getLowerRight();
}
EPointIteratorRectangleBase::EPointIteratorRectangleBase( const ERectangleBase
*rectBase )
: EPointIteratorBase( 4 )
{
  _setPoint();
}

[Bug middle-end/71387] New: [6/7 Regression] ICE in emit_move_insn, at expr.c:3418 with -Og

[burnus at gcc dot gnu.org]

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

Bug ID: 71387
   Summary: [6/7 Regression] ICE in emit_move_insn, at expr.c:3418
with -Og
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

The attached program fails with -Og as follows; using -O0, -O1, -O2 works.

(It fails likewise with GCC 7 (cf. below) and GCC 6 but works with GCC 5 [all
branch builds of today on x86-64-gnu-linux].)

$ g++ -Og test9a.ii -w
test9a.ii: In constructor
‘EPointIteratorRectangleBase::EPointIteratorRectangleBase(const
ERectangleBase*)’:
test9a.ii:37:43: internal compiler error: in emit_move_insn, at expr.c:3418
 m_actPoint = m_rectBase->getLowerRight();
  ~^~
0xa864e7 emit_move_insn(rtx_def*, rtx_def*)
../../gcc/expr.c:3417
0xa8d9bd store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../gcc/expr.c:5450
0xa8f0d0 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5042

[Bug c++/71386] New: Wrong code on c++14 (GCC trunk)

[anton.mitrokhin at phystech dot edu]

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

Bug ID: 71386
   Summary: Wrong code on c++14 (GCC trunk)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton.mitrokhin at phystech dot edu
  Target Milestone: ---

Created attachment 38625
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38625&action=edit
Reproducer

It looks like gcc emits wrong code with 14th standard features (or I may be
wrong). The reproducer concatenates two lists, but the last three elements
always end up to be zero on -O3, and on -O0 the last two elements a getting
trashed. Compiling with latest clang works fine.

Reproducer:
1. -O0:
> g++ -std=c++14 -O0 crash.cpp -o out
> ./out
> 3 2 1 0 -1490624600 32600

2. -O3:
> g++ -std=c++14 -O3 crash.cpp -o out
> ./out
> 3 2 1 0 0 0

3. clang:
> clang++ -fsanitize=undefined -fsanitize=memory -Wall -O3 crash.cpp -std=c++14 
> -o out
> ./out
> 1 2 3 1 2 3

> gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/export/users/amitrokh/gcc_trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /export/users/gnutester/stability/svn/trunk/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --with-pkgversion=Revision=237011/svn-rev:237016/
--prefix=/export/users/gnutester/stability/work/trunk/64/install
--enable-languages=c,c++,fortran,java,lto
Thread model: posix
gcc version 7.0.0 20160601 (experimental) (Revision=237011/svn-rev:237016/)

[Bug c++/71385] New: Internal compiler error when using concept as placeholder

[srarnold at web dot de]

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

Bug ID: 71385
   Summary: Internal compiler error when using concept as
placeholder
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: srarnold at web dot de
  Target Milestone: ---

Created attachment 38624
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38624&action=edit
preprocessed source file

g++-6 -fconcepts main.cpp

generated the following error message under openSUSE Leap and also Ubuntu
16.06:

g++-6: internal compiler error: Segmentation fault (program cc1plus)

[Bug tree-optimization/71383] Misoptimized branch with inline assembly code.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Honza made IPA reference work with IPA REFs which obviously do not exist for
this kind of may-uses/defs.

[Bug tree-optimization/71383] Misoptimized branch with inline assembly code.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-02
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Strictly speaking your asm should be incorrect as GCC does not consider
it to use/clobber "local" global memory.

That manifests itself in IPA reference computing that bar is not accessing
'a' and thus we can optimize the load across the call.

So, kind-of confirmed.

[Bug c++/71384] New: Global constructors (init_array) emitted for trivial initialisation depending on source code ordering

[niels at penneman dot org]

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

Bug ID: 71384
   Summary: Global constructors (init_array) emitted for trivial
initialisation depending on source code ordering
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: niels at penneman dot org
  Target Milestone: ---

GCC versions 4.7.2/5.3.0/5.3.1 are emitting a global constructor (to the
.init_array section) for the following piece of trivial code:

===

struct X
{
  constexpr X(int a);
  const int m_a;
};
X x(999);
inline constexpr X::X(int a):m_a(a) {}

===

Swapping the last two lines, i.e. placing the constructor implementation before
the declaration of 'x', causes 'x' to be emitted to the '.data' section with
value 999 instead. The latter is desirable as the generate binary is far
smaller and does not require global constructors.

How to reproduce:

g++ -std=c++11 -c -save-temps=obj global-constructor.cxx

Occurs regardless of whether you specify -O0, -O1, -O2, -O3. In a complete
program, -flto cannot resolve this. The issue occurs on both x86_64 and ARM, so
not in the backend. Also occurs with -std=c++14 and -std=c++17 on GCC 5.3.x.

Compiler versions used:

$ g++ -###
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-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 20160406 (Red Hat 5.3.1-6) (GCC)

$ ${CROSS_COMPILE}g++ -###
Using built-in specs.
COLLECT_GCC=/home/niels/workspace/toolchains/build/arm-none-eabi/output/bin/arm-none-eabi-g++
COLLECT_LTO_WRAPPER=/home/niels/workspace/toolchains/build/arm-none-eabi/output/libexec/gcc/arm-none-eabi/5.3.0/lto-wrapper
Target: arm-none-eabi
Configured with:
/home/niels/workspace/toolchains/build/arm-none-eabi/work/src/gcc-5.3.0/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=arm-none-eabi
--prefix=/home/niels/workspace/toolchains/build/arm-none-eabi/output
--with-local-prefix=/home/niels/workspace/toolchains/build/arm-none-eabi/output/arm-none-eabi/sysroot
--with-sysroot=/home/niels/workspace/toolchains/build/arm-none-eabi/output/arm-none-eabi/sysroot
--with-newlib --enable-threads=no --disable-shared --with-float=soft
--with-pkgversion='crosstool-NG crosstool-ng-1.22.0-134-ge1d494a'
--enable-__cxa_atexit --disable-libgomp --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libquadmath-support
--with-gmp=/home/niels/workspace/toolchains/build/arm-none-eabi/work/arm-none-eabi/buildtools
--with-mpfr=/home/niels/workspace/toolchains/build/arm-none-eabi/work/arm-none-eabi/buildtools
--with-mpc=/home/niels/workspace/toolchains/build/arm-none-eabi/work/arm-none-eabi/buildtools
--with-isl=/home/niels/workspace/toolchains/build/arm-none-eabi/work/arm-none-eabi/buildtools
--enable-lto --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++ -lm'
--enable-target-optspace --disable-nls --disable-multilib
--enable-languages=c,c++
Thread model: single
gcc version 5.3.0 (crosstool-NG crosstool-ng-1.22.0-134-ge1d494a)

$ ${CROSS_COMPILE}g++ -###
Using built-in specs.
COLLECT_GCC=/opt/OSELAS.Toolchain-2012.12.1/arm-v5te-linux-gnueabi/gcc-4.7.2-glibc-2.16.0-binutils-2.22-kernel-3.6-sanitized/bin/arm-v5te-linux-gnueabi-g++
COLLECT_LTO_WRAPPER=/opt/OSELAS.Toolchain-2012.12.1/arm-v5te-linux-gnueabi/gcc-4.7.2-glibc-2.16.0-binutils-2.22-kernel-3.6-sanitized/bin/../libexec/gcc/arm-v5te-linux-gnueabi/4.7.2/lto-wrapper
Target: arm-v5te-linux-gnueabi
Configured with:
/home/mol/dude/tmp/OSELAS.Toolchain-2012.12.1/platform-arm-v5te-linux-gnueabi-gcc-4.7.2-glibc-2.16.0-binutils-2.22-kernel-3.6-sanitized/build-cross/gcc-4.7.2/configure
--build=x86_64-host-linux-gnu --host=x86_64-host-linux-gnu
--target=arm-v5te-linux-gnueabi
--with-sysroot=/home/mol/dude/tmp/OSELAS.Toolchain-2012.12.1/inst/opt/OSELAS.Toolchain-2012.12.1/arm-v5te-linux-gnueabi/gcc-4.7.2-glibc-2.16.0-binutils-2.22-kernel-3.6-sanitized/sysroot-arm-v5te-linux-gnueabi
--disable-multilib --with-float=soft --with-fpu=vfp --with-cpu=arm926ej-s
--enable-__cxa_atexit --disable-sjlj-exceptions --disable-nls
--disable-decimal-float --disable-fixed-point --disable-win32-registry
--enable-symvers

[Bug rtl-optimization/71295] [7 Regression] internal compiler error: in subreg_get_info, at rtlanal.c:3673 on arm

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Jun  2 12:26:42 2016
New Revision: 237034

URL: https://gcc.gnu.org/viewcvs?rev=237034&root=gcc&view=rev
Log:
[rtlanal] Fix rtl-optimization/71295

PR rtl-optimization/71295
* rtlanal.c (subreg_get_info): If taking a subreg at the requested
offset would go over the size of the inner mode reject it.

* gcc.c-torture/compile/pr71295.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr71295.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/rtlanal.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71383] New: Misoptimized branch with inline assembly code.

[bmei at broadcom dot com]

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

Bug ID: 71383
   Summary: Misoptimized branch with inline assembly code.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bmei at broadcom dot com
  Target Milestone: ---

For the following example:

include 
static int a, b;

static void bar()
{
  asm volatile ("" : : : "memory");
}
void foo ()
{
  a = 0;
  bar ();
  if (a == 0)
printf ("HERE\n");
}

If compiles with:
~/work/install-x86/bin/gcc  tst.c -O2 -S -fno-inline

The conditional printf becomes unconditional. if (a==0) is optimized away.
foo:
.LFB1:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
xorl%eax, %eax
movl$0, a(%rip)
callbar
movl$.LC0, %edi
addq$8, %rsp
.cfi_def_cfa_offset 8
jmp puts
.cfi_endproc

However, if we compile with
~/work/install-x86/bin/gcc  tst.c -O2 -S and allow inlining, gcc produces
correct code. 

foo:
.LFB12:
.cfi_startproc
movl$0, a(%rip)
movla(%rip), %eax
testl   %eax, %eax
je  .L4
rep; ret
.p2align 4,,10
.p2align 3
.L4:
movl$.LC0, %edi
jmp puts

I guess it goes wrong in some of IPA passes.

My compiler is GCC: (GNU) 7.0.0 20160602 (experimental) [trunk revision 14336].
I can also reproduce this issue on our port of gcc 6.1.

[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows

[ismail at i10z dot com]

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

İsmail Dönmez  changed:

   What|Removed |Added

 CC||ismail at i10z dot com

--- Comment #8 from İsmail Dönmez  ---
We can reproduce this with openSUSE mingw-w64 toolchain and we don't use 
--with-gxx-include-dir :

Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-c++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-w64-mingw32/6.1.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin
--includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib64
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--build=x86_64-suse-linux-gnu --host=x86_64-suse-linux-gnu
--target=x86_64-w64-mingw32 --with-gnu-as --with-gnu-ld --verbose
--without-newlib --disable-multilib --disable-plugin --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-version-specific-runtime-libs
--with-sysroot=/usr/x86_64-w64-mingw32/sys-root
--enable-languages=c,c++,fortran,objc,obj-c++ --without-x
--enable-hash-synchronization --enable-fully-dynamic-string --enable-libgomp
--enable-linker-build-id
Thread model: win32
gcc version 6.1.0 (GCC)

Didn't try to disable "--enable-version-specific-runtime-libs" because we
actually need it.

[Bug rtl-optimization/71374] [5/6/7 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: in extract_constrain_insn, at recog.c:2190

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords||ra
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-06-02
 CC||vmakarov at gcc dot gnu.org
  Component|target  |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
This is register allocator failure, as evident from even more simplified
testcase:

int a, b, c;
extern inline void fn1 (void *p1, void *p2)
{ 
  __asm__ ("#": "=&c" (a), "=&D" (b), "=&S" (c): "r" (p2), "2" (p2));
}


LRA gets following RTX:

(insn 10 4 7 2 (parallel [
(set (reg:SI 89)
(asm_operands:SI ("#") ("=&c") 0 [
(reg/v/f:DI 88 [ p2 ])
(reg/v/f:DI 88 [ p2 ])
]
 [
(asm_input:DI ("r") t.c:4)
(asm_input:DI ("2") t.c:4)
]
 [] t.c:4))
(set (reg:SI 90)
(asm_operands:SI ("#") ("=&D") 1 [
(reg/v/f:DI 88 [ p2 ])
(reg/v/f:DI 88 [ p2 ])
]
 [
(asm_input:DI ("r") t.c:4)
(asm_input:DI ("2") t.c:4)
]
 [] t.c:4))
(set (reg:SI 91)
(asm_operands:SI ("#") ("=&S") 2 [
(reg/v/f:DI 88 [ p2 ])
(reg/v/f:DI 88 [ p2 ])
]
 [
(asm_input:DI ("r") t.c:4)
(asm_input:DI ("2") t.c:4)
]
 [] t.c:4))
(clobber (reg:CCFP 18 fpsr))
(clobber (reg:CC 17 flags))
]) t.c:4 -1
 (expr_list:REG_DEAD (reg/v/f:DI 88 [ p2 ])
(expr_list:REG_UNUSED (reg:CCFP 18 fpsr)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)

Please note how asm input is tied through p2 variable. LRA ties "2" matching
constraint with "=&D" earlyclobber output constraint (BTW: matching
earlyclobber output is allowed), but it can't resolve tie through p2. This
results in:

(insn 10 4 15 2 (parallel [
(set (reg:SI 2 cx [89])
(asm_operands:SI ("#") ("=&c") 0 [
(reg/v/f:DI 4 si [orig:88 p2 ] [88])
(reg/v/f:DI 4 si [orig:88 p2 ] [88])
]
 [
(asm_input:DI ("r") t.c:4)
(asm_input:DI ("2") t.c:4)
]
 [] t.c:4))
(set (reg:SI 5 di [90])
(asm_operands:SI ("#") ("=&D") 1 [
(reg/v/f:DI 4 si [orig:88 p2 ] [88])
(reg/v/f:DI 4 si [orig:88 p2 ] [88])
]
 [
(asm_input:DI ("r") t.c:4)
(asm_input:DI ("2") t.c:4)
]
 [] t.c:4))
(set (reg:SI 4 si [orig:88 p2 ] [88])
(asm_operands:SI ("#") ("=&S") 2 [
(reg/v/f:DI 4 si [orig:88 p2 ] [88])
(reg/v/f:DI 4 si [orig:88 p2 ] [88])
]
 [
(asm_input:DI ("r") t.c:4)
(asm_input:DI ("2") t.c:4)
]
 [] t.c:4))
(clobber (reg:CCFP 18 fpsr))
(clobber (reg:CC 17 flags))
]) t.c:4 -1
 (nil))

which results in reg SI allocated to asm input 0. This violates earlyclobber
requirement that "this operand may not lie in a register that is read by the
instruction or as part of any memory address" with output operand 2, which is
also reg SI.

LRA should copy asm input 0 to an appropriate class temporary reg in the above
case.

Confirmed as rtl-optimization problem.

[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section

[senthil.thecoder at gmail dot com]

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

--- Comment #12 from Senthil Kumar Selvaraj  
---
Yes, tiny also has .rodata in .data

I'd totally missed PR 63323, so just removing the target hook and turning on
JUMP_TABLES_IN_TEXT_SECTION does the trick, like you said. Wrote a basic test
to make sure jumptables get generated and used correctly, and that worked too.

[Bug c++/70972] [6 Regression] Inheriting constructors taking parameters by value should move them, not copy

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #8 from Paolo Carlini  ---
Fixed in the branch too.

[Bug c++/70972] [6 Regression] Inheriting constructors taking parameters by value should move them, not copy

[paolo at gcc dot gnu.org]

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

--- Comment #7 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Jun  2 11:30:44 2016
New Revision: 237032

URL: https://gcc.gnu.org/viewcvs?rev=237032&root=gcc&view=rev
Log:
/cp
2016-06-02  Paolo Carlini  

PR c++/70972
* method.c (forward_parm): Use cp_build_reference_type.

/testsuite
2016-06-02  Paolo Carlini  

PR c++/70972
* g++.dg/cpp0x/inh-ctor20.C: New.
* g++.dg/cpp0x/inh-ctor21.C: Likewise.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/inh-ctor20.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/inh-ctor21.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/method.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/71382] New: Unary plus doesn't works with pointers to instantiations of function templates

[roman.perepelitsa at gmail dot com]

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

Bug ID: 71382
   Summary: Unary plus doesn't works with pointers to
instantiations of function templates
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roman.perepelitsa at gmail dot com
  Target Milestone: ---

This compiles:

  void F();
  void G() { +(&F); }

This doesn't:

  template  void F();
  void G() { +(&F); }

error: wrong type argument to unary plus

Expected behaviour: both examples compile.

[Bug c/71381] New: C/C++ OpenACC cache directive rejects valid syntax

[tschwinge at gcc dot gnu.org]

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

Bug ID: 71381
   Summary: C/C++ OpenACC cache directive rejects valid syntax
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: openacc, rejects-valid
  Severity: normal
  Priority: P3
 Component: c
  Assignee: tschwinge at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

[Bug libstdc++/71298] changes to libstdc++ breaks windows builds

[lh_mouse at 126 dot com]

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

lh_mouse  changed:

   What|Removed |Added

 CC||lh_mouse at 126 dot com

--- Comment #1 from lh_mouse  ---
It might be a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936 .

And see some discussion here:
https://github.com/Alexpux/MINGW-packages/pull/1437

[Bug tree-optimization/71379] [7 regression] Bootstrap fail on S/390 32 bit starting with r236831

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug tree-optimization/64946] [AArch64] gcc.target/aarch64/vect-abs-compile.c - "abs" vectorization fails for char/short types

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  ---
On Thu, 2 Jun 2016, shiva0217 at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946
> 
> Shiva Chen  changed:
> 
>What|Removed |Added
> 
>  CC||shiva0217 at gmail dot com
> 
> --- Comment #12 from Shiva Chen  ---
> It seems that the patch was dropped according to 
> https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00610.html.
> 
> Could we use TYPE_OVERFLOW_UNDEFINED to guard the transformation
> like other place in gcc did ?

You can use TYPE_OVERFLOW_WRAPS to guard it.

> Any thoughts?

Elsewhere I suggested to introduce a ABSU_EXPR (or overload ABS_EXPR)
to make the result unsigned and thus effectively make ABSU_EXPR (INT_MIN)
well-defined via doing the transform

  ABS_EXPR (x) -> (typeof x) ABSU_EXPR (x)

which you then can narrow.

Other than that only making signed types >= int have undefined overflow
may be appealling as well.

[Bug c++/71378] A compilable file fails to compile when ASAN options are specified

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2016-6-2
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Confirmed on trunk, I've been reducing the test-case.

[Bug tree-optimization/71380] [7 Regression] internal compiler error: in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2498

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||6.1.0
   Target Milestone|--- |7.0
  Known to fail||7.0

[Bug tree-optimization/71380] New: [7 Regression] internal compiler error: in copy_cond_phi_nodes, at graphite-isl-ast-to-gimple.c:2498

[ktkachov at gcc dot gnu.org]

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

Bug ID: 71380
   Summary: [7 Regression] internal compiler error: in
copy_cond_phi_nodes, at
graphite-isl-ast-to-gimple.c:2498
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

GCC trunk at r237026 ICEs on the testcase:

int *a;
int b, c, d, e, g;
char f;

void fn1() {
  for (; c;) {
b = 0;
for (; b <= 2; b++) {
  unsigned **h = (unsigned **) &a[b];
  *h = (g && (e = d)) != f++;
}
  }
}

on aarch64 with -Ofast -floop-interchange.

mycrash.c: In function 'fn1':
mycrash.c:10:10: warning: assignment makes pointer from integer without a cast
[-Wint-conversion]
   *h = (g && (e = d)) != f++;
  ^
mycrash.c:5:6: internal compiler error: in copy_cond_phi_nodes, at
graphite-isl-ast-to-gimple.c:2498
 void fn1() {
  ^~~
0x10a45c5 translate_isl_ast_to_gimple::copy_cond_phi_nodes(basic_block_def*,
basic_block_def*, vec)
$SRC/gcc/graphite-isl-ast-to-gimple.c:2498
0x10a5030
translate_isl_ast_to_gimple::copy_bb_and_scalar_dependences(basic_block_def*,
edge_def*, vec)
$SRC/gcc/graphite-isl-ast-to-gimple.c:2787
0x10a57ed
translate_isl_ast_to_gimple::translate_isl_ast_node_user(isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:936
0x10a599d translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:1040
0x10a5eb4 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:965
0x10a59b3 translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:1044
0x10a60d6 translate_isl_ast_to_gimple::translate_isl_ast_node_if(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:1004
0x10a598a translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:1037
0x10a5eb4 translate_isl_ast_to_gimple::translate_isl_ast_node_block(loop*,
isl_ast_node*, edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:965
0x10a59b3 translate_isl_ast_to_gimple::translate_isl_ast(loop*, isl_ast_node*,
edge_def*, std::map,
std::allocator > >&)
$SRC/gcc/graphite-isl-ast-to-gimple.c:1044
0x10a6467 graphite_regenerate_ast_isl(scop*)
$SRC/gcc/graphite-isl-ast-to-gimple.c:3184
0x109db70 graphite_transform_loops()
$SRC/gcc/graphite.c:329
0x109dcd4 graphite_transforms
$SRC/gcc/graphite.c:356
0x109dcd4 execute
$SRC/gcc/graphite.c:433
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


This doesn't occur on the GCC 6 branch for me

[Bug c++/71372] [6/7 Regression] C++ FE drops TREE_THIS_VOLATILE in cp_fold on all tcc_reference trees

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Created attachment 38623
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38623&action=edit
gcc7-pr71372.patch

Patch I'm going to bootstrap/regtest.

[Bug tree-optimization/71379] New: [7 regression] Bootstrap fail on S/390 32 bit starting with r236831

[krebbel at gcc dot gnu.org]

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

Bug ID: 71379
   Summary: [7 regression] Bootstrap fail on S/390 32 bit starting
with r236831
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

S/390 32 bit bootstrap appears to fail in stage 2 starting with r236831:

In file included from /home/andreas/clean/../gcc/gcc/config/s390/s390.c:41:0:
/home/andreas/clean/../gcc/gcc/recog.h: In function 'rtx_def*
s390_expand_builtin(tree, rtx, rtx, machine_mode, int)':
/home/andreas/clean/../gcc/gcc/recog.h:306:136: error: 'op[5]' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
   rtx_insn * operator () (rtx a0, rtx a1, rtx a2, rtx a3, rtx a4, rtx a5, rtx
a6) const { return ((f7)func) (a0, a1, a2, a3, a4, a5, a6); }

^
/home/andreas/clean/../gcc/gcc/config/s390/s390.c:799:7: note: 'op[5]' was
declared here
   rtx op[MAX_ARGS], pat;
   ^~

Probably related or even duplicates of PR71335 or PR71316.

Unfortunately there was another commit causing a bootstrap fail in that
timeframe which needs to be reverted first: r236826. That commit got reverted
with r236850 anyway.

[Bug target/70830] [6/7 Regression] ARM interrupt attribute: push/pop do not support {reglist}^

[ktkachov at gcc dot gnu.org]

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Jun  2 08:54:15 2016
New Revision: 237027

URL: https://gcc.gnu.org/viewcvs?rev=237027&root=gcc&view=rev
Log:
Fix fallout from: [ARM] PR target/70830: Avoid POP-{reglist}^ when returning
from interrupt handlers

PR target/70830
* config/arm/arm.c (arm_output_multireg_pop): Guard "pop" on update.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c

[Bug tree-optimization/64946] [AArch64] gcc.target/aarch64/vect-abs-compile.c - "abs" vectorization fails for char/short types

[shiva0217 at gmail dot com]

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

Shiva Chen  changed:

   What|Removed |Added

 CC||shiva0217 at gmail dot com

--- Comment #12 from Shiva Chen  ---
It seems that the patch was dropped according to 
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00610.html.

Could we use TYPE_OVERFLOW_UNDEFINED to guard the transformation
like other place in gcc did ?

Any thoughts?

[Bug c++/71372] [6/7 Regression] C++ FE drops TREE_THIS_VOLATILE in cp_fold on all tcc_reference trees

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
On the C++ cp_fold side, I think
--- cp-gimplify.c.jj1   2016-05-26 10:38:01.0 +0200
+++ cp-gimplify.c   2016-06-02 10:21:33.903655321 +0200
@@ -2035,7 +2035,16 @@ cp_fold (tree x)
  if (op0 == error_mark_node)
x = error_mark_node;
  else
-   x = fold_build1_loc (loc, code, TREE_TYPE (x), op0);
+   {
+ x = fold_build1_loc (loc, code, TREE_TYPE (x), op0);
+ if (code == INDIRECT_REF
+ && (INDIRECT_REF_P (x) || TREE_CODE (x) == MEM_REF))
+   {
+ TREE_READONLY (x) = TREE_READONLY (org_x);
+ TREE_SIDE_EFFECTS (x) = TREE_SIDE_EFFECTS (org_x);
+ TREE_THIS_VOLATILE (x) = TREE_THIS_VOLATILE (org_x);
+   }
+   }
}
   else
x = fold (x);
@@ -2312,7 +2321,12 @@ cp_fold (tree x)
  || op3 == error_mark_node)
x = error_mark_node;
  else
-   x = build4_loc (loc, code, TREE_TYPE (x), op0, op1, op2, op3);
+   {
+ x = build4_loc (loc, code, TREE_TYPE (x), op0, op1, op2, op3);
+ TREE_READONLY (x) = TREE_READONLY (org_x);
+ TREE_SIDE_EFFECTS (x) = TREE_SIDE_EFFECTS (org_x);
+ TREE_THIS_VOLATILE (x) = TREE_THIS_VOLATILE (org_x);
+   }
}

   x = fold (x);

could be enough, at least I don't see folding of any other *_REF right now.
In the C FE, I wonder if fold or fold_build1_loc can turn INDIRECT_REF into
MEM_REF, if yes, then it would be wrong.  Also for COMPONENT_REF the C FE
doesn't copy TREE_SIDE_EFFECTS bit, that might be incorrect if it copies
TREE_THIS_VOLATILE?
And, for C++ I'm missing e.g. any kind of folding of COMPONENT_REF, that is
really strange.  In fold_builtin_arith_overflow, I guess we also fail to add
TREE_THIS_VOLATILE/TREE_SIDE_EFFECTS if the pointer points to volatile type.
Plus fold...

[Bug tree-optimization/71261] [7 Regression] Trunk GCC hangs on knl and broadwell targets

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/71374] [5/6/7 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: in extract_constrain_insn, at recog.c:2190

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
  Component|ipa |target
   Target Milestone|--- |5.4
Summary|ICE on valid code at -O1|[5/6/7 Regression] ICE on
   |and above on|valid code at -O1 and above
   |x86_64-linux-gnu: in|on x86_64-linux-gnu: in
   |extract_constrain_insn, at  |extract_constrain_insn, at
   |recog.c:2190|recog.c:2190

[Bug c++/71372] [6/7 Regression] C++ FE drops TREE_THIS_VOLATILE in cp_fold on all tcc_reference trees

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Thu, 2 Jun 2016, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71372
> 
> --- Comment #9 from Jakub Jelinek  ---
> (In reply to rguent...@suse.de from comment #8)
> > On Thu, 2 Jun 2016, rguenther at suse dot de wrote:
> > Actually it's not a bug of those but of the callers (given fold_binary
> > doesn't get to see that flag).
> 
> Exactly.
> > 
> > > > see just
> > > >   switch (TREE_CODE_LENGTH (code))
> > > > {
> > > > case 1:
> > > >   op0 = TREE_OPERAND (t, 0);
> > > >   tem = fold_unary_loc (loc, code, type, op0);
> > > >   return tem ? tem : expr;
> > > > case 2:
> > > >   op0 = TREE_OPERAND (t, 0);
> > > >   op1 = TREE_OPERAND (t, 1);
> > > >   tem = fold_binary_loc (loc, code, type, op0, op1);
> > > >   return tem ? tem : expr;
> > > > case 3:
> > > >   op0 = TREE_OPERAND (t, 0);
> > > >   op1 = TREE_OPERAND (t, 1);
> > > >   op2 = TREE_OPERAND (t, 2);
> > > >   tem = fold_ternary_loc (loc, code, type, op0, op1, op2);
> > > >   return tem ? tem : expr;
> > > > without really trying to preserve anything.
> > 
> > This would need to do the fixup in case of tcc_reference codes.  
> > Fortunately fold () calls are rare.
> 
> Well, both C and C++ FEs now call them pretty much on everything.  So 
> certainly
> not rare.

(something to fix)

Well.  So we need to fixup things in fold () - that part is latent
everywhere then.  But the actual issue for the testcaseis in cp_fold.

[Bug c++/71372] [6/7 Regression] C++ FE drops TREE_THIS_VOLATILE in cp_fold on all tcc_reference trees

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #8)
> On Thu, 2 Jun 2016, rguenther at suse dot de wrote:
> Actually it's not a bug of those but of the callers (given fold_binary
> doesn't get to see that flag).

Exactly.
> 
> > > see just
> > >   switch (TREE_CODE_LENGTH (code))
> > > {
> > > case 1:
> > >   op0 = TREE_OPERAND (t, 0);
> > >   tem = fold_unary_loc (loc, code, type, op0);
> > >   return tem ? tem : expr;
> > > case 2:
> > >   op0 = TREE_OPERAND (t, 0);
> > >   op1 = TREE_OPERAND (t, 1);
> > >   tem = fold_binary_loc (loc, code, type, op0, op1);
> > >   return tem ? tem : expr;
> > > case 3:
> > >   op0 = TREE_OPERAND (t, 0);
> > >   op1 = TREE_OPERAND (t, 1);
> > >   op2 = TREE_OPERAND (t, 2);
> > >   tem = fold_ternary_loc (loc, code, type, op0, op1, op2);
> > >   return tem ? tem : expr;
> > > without really trying to preserve anything.
> 
> This would need to do the fixup in case of tcc_reference codes.  
> Fortunately fold () calls are rare.

Well, both C and C++ FEs now call them pretty much on everything.  So certainly
not rare.

[Bug c++/71372] [6/7 Regression] C++ FE drops TREE_THIS_VOLATILE in cp_fold on all tcc_reference trees

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Thu, 2 Jun 2016, rguenther at suse dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71372
> 
> --- Comment #7 from rguenther at suse dot de  ---
> On Wed, 1 Jun 2016, jakub at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71372
> > 
> > Jakub Jelinek  changed:
> > 
> >What|Removed |Added
> > 
> >  CC||jakub at gcc dot gnu.org
> > 
> > --- Comment #6 from Jakub Jelinek  --- Isn't 
> > this generally a problem of the whole folder, not just cp_fold? I mean, 
> > if you have say MEM[&MEM[p, CST1], CST2] and the outer MEM_REF has e.g. 
> > TREE_THIS_VOLATILE, TREE_THIS_NOTRAP, TREE_SIDE_EFFECTS, TREE_READONLY, 
> > TREE_CONSTANT set on it, and you call fold on it, then I don't see what 
> > would preserve those bits (not sure if all of them are applicable). I 
> 
> True, but that's a bug of that specific folder then.

Actually it's not a bug of those but of the callers (given fold_binary
doesn't get to see that flag).

> > see just
> >   switch (TREE_CODE_LENGTH (code))
> > {
> > case 1:
> >   op0 = TREE_OPERAND (t, 0);
> >   tem = fold_unary_loc (loc, code, type, op0);
> >   return tem ? tem : expr;
> > case 2:
> >   op0 = TREE_OPERAND (t, 0);
> >   op1 = TREE_OPERAND (t, 1);
> >   tem = fold_binary_loc (loc, code, type, op0, op1);
> >   return tem ? tem : expr;
> > case 3:
> >   op0 = TREE_OPERAND (t, 0);
> >   op1 = TREE_OPERAND (t, 1);
> >   op2 = TREE_OPERAND (t, 2);
> >   tem = fold_ternary_loc (loc, code, type, op0, op1, op2);
> >   return tem ? tem : expr;
> > without really trying to preserve anything.

This would need to do the fixup in case of tcc_reference codes.  
Fortunately fold () calls are rare.

[Bug c++/71372] [6/7 Regression] C++ FE drops TREE_THIS_VOLATILE in cp_fold on all tcc_reference trees

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Wed, 1 Jun 2016, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71372
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #6 from Jakub Jelinek  --- Isn't 
> this generally a problem of the whole folder, not just cp_fold? I mean, 
> if you have say MEM[&MEM[p, CST1], CST2] and the outer MEM_REF has e.g. 
> TREE_THIS_VOLATILE, TREE_THIS_NOTRAP, TREE_SIDE_EFFECTS, TREE_READONLY, 
> TREE_CONSTANT set on it, and you call fold on it, then I don't see what 
> would preserve those bits (not sure if all of them are applicable). I 

True, but that's a bug of that specific folder then.

> see just
>   switch (TREE_CODE_LENGTH (code))
> {
> case 1:
>   op0 = TREE_OPERAND (t, 0);
>   tem = fold_unary_loc (loc, code, type, op0);
>   return tem ? tem : expr;
> case 2:
>   op0 = TREE_OPERAND (t, 0);
>   op1 = TREE_OPERAND (t, 1);
>   tem = fold_binary_loc (loc, code, type, op0, op1);
>   return tem ? tem : expr;
> case 3:
>   op0 = TREE_OPERAND (t, 0);
>   op1 = TREE_OPERAND (t, 1);
>   op2 = TREE_OPERAND (t, 2);
>   tem = fold_ternary_loc (loc, code, type, op0, op1, op2);
>   return tem ? tem : expr;
> without really trying to preserve anything.  Similarly to this cp_fold has
> similar problem, c_fully_fold* will work more often than cp_fold, because it
> always goes through build instead of fold_build*, followed by copying over of
> TREE_THIS_VOLATILE and various other flags, and only then calls fold on the
> whole result, so just for the tem != NULL cases above can drop the flags, but
> in cp_fold it always calls fold_build* without copying flags over.
> 
> Now, the question is, if what we should do here and cp_fold is not fold at all
> for TREE_THIS_VOLATILE (in cp_fold then just build and copy over flags), or
> fold, check if the result of the folding is still e.g. tcc_reference, and just
> set the flag on the result if it has been set before.

Definitely set the flag on the result if it has been set before.  Not
fold the dereference itself as well I guess.

Note the

case MEM_REF:
  /* MEM[&MEM[p, CST1], CST2] -> MEM[p, CST1 + CST2].  */
  if (TREE_CODE (arg0) == ADDR_EXPR
  && TREE_CODE (TREE_OPERAND (arg0, 0)) == MEM_REF)
{
  tree iref = TREE_OPERAND (arg0, 0);
  return fold_build2 (MEM_REF, type,
  TREE_OPERAND (iref, 0),
  int_const_binop (PLUS_EXPR, arg1,
   TREE_OPERAND (iref, 1)));
}

foldings that miss the volatile is a canonicalization one, turning
invalid MEM_REFs into valid ones.  I'll fix those up.  They also
miss to copy TREE_THIS_NOTRAP, etc. - see tree-ssa-forwprop.c who
does this correctly for example.