[Bug c++/71092] [6/7 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1449; only with -Os

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-13
 CC||trippels at gcc dot gnu.org
Summary|internal compiler error: in |[6/7 Regression] ICE: in
   |cxx_eval_call_expression,   |cxx_eval_call_expression,
   |at cp/constexpr.c:1449; |at cp/constexpr.c:1449;
   |only with -Os   |only with -Os
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
markus@x4 tmp % cat prep.cpp
template  struct A { using type = _Default; };
template  typename>
using __detected_or = A<_Default>;
template  class _Op>
using __detected_or_t = typename __detected_or<_Default, _Op>::type;
template  struct B { typedef _Tp value_type; };
struct C {
  template  using __pointer = typename _Tp::pointer;
};
template  struct J : C {
  using pointer = __detected_or_t;
};
template  void _Construct(_T1 *) { new _T1; }
struct D {
  template 
  static _ForwardIterator __uninit_default_n(_ForwardIterator p1, _Size) {
_Construct(p1);
  }
};
template 
void __uninitialized_default_n(_ForwardIterator p1, _Size) {
  D::__uninit_default_n(p1, 0);
}
template 
void __uninitialized_default_n_a(_ForwardIterator p1, _Size, _Tp) {
  __uninitialized_default_n(p1, 0);
}
template  struct __shared_ptr {
  constexpr __shared_ptr() : _M_ptr(), _M_refcount() {}
  int _M_ptr;
  int _M_refcount;
};
template  struct F {
  typedef _Alloc _Tp_alloc_type;
  struct G {
typename J<_Tp_alloc_type>::pointer _M_start;
G(_Tp_alloc_type);
  };
  F(int, _Alloc p2) : _M_impl(p2) {}
  G _M_impl;
};
template > struct K : F<_Alloc> {
  typedef _Alloc allocator_type;
  K(int, allocator_type p2 = allocator_type()) : F<_Alloc>(0, p2) {
__uninitialized_default_n_a(this->_M_impl._M_start, 0, 0);
  }
};
struct H {
  H();
  struct I {
__shared_ptr trigger[1];
  };
  __shared_ptr resetTrigger_;
  K states_;
  __shared_ptr triggerManager_;
};
__shared_ptr a;
H::H() : states_(0), triggerManager_(a) {}

markus@x4 tmp % g++ -c prep.cpp -Os
prep.cpp: In constructor ‘constexpr H::I::I()’:
prep.cpp:50:10:   in constexpr expansion of ‘__shared_ptr()’
prep.cpp:50:10: internal compiler error: in cxx_eval_call_expression, at
cp/constexpr.c:1449
   struct I {
  ^
0x863b2d cxx_eval_call_expression
../../gcc/gcc/cp/constexpr.c:1449
0x864863 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:3557
0x86a51b cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:4135
0x86d371 maybe_constant_init(tree_node*, tree_node*)
../../gcc/gcc/cp/constexpr.c:4453
0x7b1664 build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int)
../../gcc/gcc/cp/init.c:4177
0x84872d cp_gimplify_expr(tree_node**, gimple**, gimple**)
../../gcc/gcc/cp/cp-gimplify.c:592
0xaf51b2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10210
0xafa7b6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:5699
0xaf72b6 gimplify_cleanup_point_expr
../../gcc/gcc/gimplify.c:5475
0xaf72b6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10666
0xafa7b6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:5699
0xafca85 gimplify_bind_expr
../../gcc/gcc/gimplify.c:1154
0xaf71d8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10500
0xafa7b6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:5699
0xafd6b9 gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:11480
0xafdd46 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:11636
0x978a97 cgraph_node::analyze()
../../gcc/gcc/cgraphunit.c:625
0x97be23 analyze_functions
../../gcc/gcc/cgraphunit.c:1086
0x97cb08 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2543

[Bug c++/58541] [c++11] Bogus "error: redeclaration ... differs in ‘constexpr’"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-13
 CC||msebor at gcc dot gnu.org
 Blocks||55004
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  There is no requirement that the namespace-scope definition of a
static constexpr class member say its constexpr.  Today's trunk (7.0) fails
with the following error.  All supported versions of GCC fail to compile the
test case.  If I'm reading the logs right, the error was introduced in r166013.

$ cat xx.cpp && gcc -S -Wall -Wextra -Wpedantic -o/dev/null -std=c++11 xx.cpp
struct X {
  static constexpr const char x[] = "x";
};

const char X::x[];

xx.cpp:5:17: error: ‘constexpr’ needed for in-class initialization of static
data member ‘const char X::x [2]’ of non-integral type [-fpermissive]
 const char X::x[];
 ^


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug c++/52966] ill-formed template constexpr functions are accepted?

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
The test case is valid because function two doesn't violate any of the
requirements on constexpr functions.  In particular, there is no requirement
that a constexpr function definition must not refer to symbols or make calls to
functions that are not declared constexpr.  Such a requirement only applies
when a constexpr function is invoked in a context where a /core constant
expression/ is required.  An invocation of the constexpr function in such a
context is not a core constant expression.

[Bug other/71094] New: Documentation: -fivopts is enabled at all levels

[nightstrike at gmail dot com]

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

Bug ID: 71094
   Summary: Documentation: -fivopts is enabled at all levels
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

The -fivopts option appears to be enabled at all optimization levels, including
-O0 and -Os, but the documentation does not reflect this, either in the
description of the option or in the list of options included in individual -O
levels.

[Bug fortran/71047] [7 Regression] Allocatable component of INTENT(OUT) dummy not set correctly

[fritzoreese at gmail dot com]

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

--- Comment #4 from Fritz Reese  ---
See https://gcc.gnu.org/ml/fortran/2016-05/msg00032.html for the fix.

[Bug c++/61105] [constexpr] accepts-invalid with new-expression in constant expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail|6.0 |6.1.0, 7.0

--- Comment #6 from Martin Sebor  ---
With my patch for bug 60760 GCC rejects the original test case:

$ cat xx.cpp && /build/gcc-60760/gcc/xgcc -B /build/gcc-60760/gcc -S -Wall
-Wextra -Wpedantic -o/dev/null xx.cpp
using size_t = decltype (sizeof (0));
constexpr void *operator new (size_t, int*) noexcept { return nullptr; }
constexpr int *p = new (nullptr) int;
xx.cpp:3:34: error: invalid conversion involving a null pointer
 constexpr int *p = new (nullptr) int;
  ^~~

But the patch doesn't fix the underlying problem that GCC accepts a placement
new expression in a constexpr function.  It's evident from the fact that the
following modified test case that avoids using the null pointer is still
accepted:

$ cat xx.cpp && /build/gcc-60760/gcc/xgcc -B /build/gcc-60760/gcc -S -Wall
-Wextra -Wpedantic -o/dev/null xx.cpp
constexpr void *operator new (__SIZE_TYPE__, void *p) noexcept { return p; }

constexpr int f ()
{
  int i = 0;
  int *p = new () int (1);
  return *p;
}

constexpr int i = f ();
$

[Bug c++/71093] New: use of pseudo-destructor accepted in constant expression

[msebor at gcc dot gnu.org]

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

Bug ID: 71093
   Summary: use of pseudo-destructor accepted in constant
expression
   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: ---

Among the list of expressions that are not core constant expressions and thus
are not usable in constexpr contexts is the call to a pseudo-destructor such as
in the following (invalid) test case.  The test case is silently accepted by
all versions of GCC when it should be rejected.

$ cat xx.cpp && gcc -S -Wall -Wextra -Wpedantic -o/dev/null xx.cpp
constexpr int f (const int *p)
{
  typedef int T;
  p->~T ();
  return *p;
}

constexpr int i = 0;
constexpr int j = f ();

[Bug c++/70248] constexpr initialization with unspecified equality expression accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail|6.0 |6.1.0

--- Comment #2 from Martin Sebor  ---
Below is another example, one that even elicits a warning where GCC points out
the unspecified behavior:

$ cat xx.cpp && gcc -S -Wall -Wextra -Wpedantic -o/dev/null xx.cpp
constexpr int b = "" == "";
xx.cpp:1:25: warning: comparison with string literal results in unspecified
behavior [-Waddress]
 constexpr int b = "" == "";
 ^~

[Bug c++/60760] arithmetic on null pointers should not be allowed in constant expressions

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
Patch resubmitted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00935.html

[Bug sanitizer/69840] two ASAN help nits

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Then we have to agree that this code breaks GNU output style.  Or it breaks
LLVM output style.  It is one or the other, I rather see a way to do this
dynamically of breaking up the lines (this was done in the past for GCC's
diagnostic so it definitely can be done).

[Bug sanitizer/69840] two ASAN help nits

[kcc at gcc dot gnu.org]

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

--- Comment #3 from Kostya Serebryany  ---
You don't :) 
The agreement between the teams was that the code in gcc is a verbatim copy of
upstream. (Well, there was a single-line difference at some point)
If you break this assumption, the next merge will undo your change.
Or the next merge will become impossible.

[Bug c++/71092] internal compiler error: in cxx_eval_call_expression, at cp/constexpr.c:1449; only with -Os

[bugz at 0x83 dot eu]

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

--- Comment #1 from Lukas K.  ---
Created attachment 38480
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38480=edit
preprocessed source (had to gzip because of file size limit)

[Bug c++/71092] New: internal compiler error: in cxx_eval_call_expression, at cp/constexpr.c:1449; only with -Os

[bugz at 0x83 dot eu]

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

Bug ID: 71092
   Summary: internal compiler error: in cxx_eval_call_expression,
at cp/constexpr.c:1449; only with -Os
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugz at 0x83 dot eu
  Target Milestone: ---

When compiling the MSP430 debug stack http://www.ti.com/tool/mspds with GCC
6.1.1, I got this error message:

DLL430_v3/src/TI/DLL430/EM/Sequencer/Sequencer430.h: In constructor
‘TI::DLL430::Sequencer430::State::State()’:
DLL430_v3/src/TI/DLL430/EM/Sequencer/Sequencer430.h:60:11:   in constexpr
expansion of ‘std::shared_ptr()’
DLL430_v3/src/TI/DLL430/EM/Sequencer/Sequencer430.h:60:11: internal compiler
error: in cxx_eval_call_expression, at cp/constexpr.c:1449
   State() { std::fill_n(nextState, NUM_TRANSITIONS, 0); }
   ^
Please submit a full bug report,
with preprocessed source if appropriate.

To reproduce, compile the attached file with
g++ -c prep.cpp  -Os

With optimisation levels different from -Os, the file compiles just fine, as it
does with GCC 5.3.0.

Sorry for not being able to provide a more concise test case, but I haven't yet
been able to isolate the issue.

[Bug c++/71091] constexpr reference bound to a null pointer dereference accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-12
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
This is fixed by my patch for bug 60760 (to be resubmitted for 7.0).

[Bug c++/71091] New: constexpr reference bound to a null pointer dereference accepted

[msebor at gcc dot gnu.org]

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

Bug ID: 71091
   Summary: constexpr reference bound to a null pointer
dereference accepted
   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 released versions of GCC fail to reject definitions of constexpr variables
initialized by dereferencing a null pointer, creating a dangling reference. 
The initialization is invalid and should be rejected.

$ cat xx.cpp && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wall -Wextra -Wpedantic -o/dev/null xx.cpp
constexpr int *p = 0;
constexpr int  = *p;
static_assert ( != 0, "");
xx.cpp:3:19: warning: the compiler can assume that the address of ‘r’ will
never be NULL [-Waddress]
 static_assert ( != 0, "");
~~~^~~~
xx.cpp:3:1: error: static assertion failed
 static_assert ( != 0, "");
 ^

[Bug c++/70774] constexpr function with reference parameter gives reinterpret_cast from integer to pointer error

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
The test case is invalid because a constexpr expression cannot make use of
reinterpret_cast (which is what the C-style cast in the definition of the PORTX
macro is equivalent to).  That GCC 4.8.2 accepts it is a bug in that version of
the compiler.  It was fixed in r197209 (to resolve bug 56728).

[Bug target/61599] [x86_64] With -mcmodel=medium, extern global arrays without size are not treated conservatively.

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #3)

> Reopened, it looks that some sections are not handled correctly.
Following patch fixes the failure:

Index: i386.c
===
--- i386.c  (revision 236182)
+++ i386.c  (working copy)
@@ -15475,7 +15475,7 @@ legitimize_pic_address (rtx orig, rtx reg)
  new_rtx = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, addr), UNSPEC_PCREL);
  new_rtx = gen_rtx_CONST (Pmode, new_rtx);
}
-  else if (TARGET_64BIT && ix86_cmodel != CM_LARGE_PIC)
+  else if (TARGET_64BIT && ix86_cmodel == CM_SMALL_PIC)
{
  new_rtx = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, addr),
UNSPEC_GOTPCREL);

[Bug tree-optimization/71050] [7 regression] test case gcc.target/powerpc/lhs-1.c fails starting with r236066

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
No, please go ahead, I couldn't find an easy way out.  The generic
code is hell-bent on using a subreg of the DF reg.

The backend won't necessarily use any nop here btw, but the testcase
should be pretty stable with just checking for any nop, it is small
enough generated code.  Might want to add a comment saying exactly
what it tries to test (i.e., there should be enough nops to force the
load into a different issue group than the store is in).

[Bug c++/67965] gcc (incorrectly) requires template keyword in non-dependent expression

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-12
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libstdc++/71090] #include cannot locate math.h

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
This is not a GCC bug you are changing the search directory paths what do you
expect to happen?

Note Mozilla had a similar bug which is being fixed there.

[Bug libstdc++/71090] #include cannot locate math.h

[mcguire at crsr dot net]

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

--- Comment #3 from Tommy McGuire  ---
Pony bug 797: https://github.com/ponylang/ponyc/issues/797

[Bug libstdc++/71090] #include cannot locate math.h

[mcguire at crsr dot net]

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

--- Comment #1 from Tommy McGuire  ---
This may be related to Bug #70936
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936).

[Bug libstdc++/71090] #include cannot locate math.h

[mcguire at crsr dot net]

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

--- Comment #2 from Tommy McGuire  ---
Created attachment 38479
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38479=edit
Preprocessed source file

[Bug libstdc++/71090] New: #include cannot locate math.h

[mcguire at crsr dot net]

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

Bug ID: 71090
   Summary: #include  cannot locate math.h
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mcguire at crsr dot net
  Target Milestone: ---

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

Using the gcc 6.1.1-1 package from Arch Linux, the attached program math.cc
fails to compile with the following error when compiled with the given command
line:

$ gcc -v --save-temps -o math math.cc -isystem /usr/include
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/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 --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 6.1.1 20160501 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'math' '-isystem' '/usr/include'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/cc1plus -E -quiet -v -D_GNU_SOURCE
-isystem /usr/include math.cc -mtune=generic -march=x86-64 -fpch-preprocess -o
math.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1

/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../include/c++/6.1.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include-fixed
End of search list.
In file included from math.cc:1:0:
/usr/include/c++/6.1.1/cmath:45:23: fatal error: math.h: No such file or
directory
 #include_next 
   ^
compilation terminated. 

The original problem was discovered while compiling the Pony language compiler,
which uses LLVM and uses -isystem to put the location of the LLVM headers at
the start of the bracket search path.

[Bug lto/71089] [7 Regression] Failed to build 483.xalancbmk in SPEC CPU 2006

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #1 from Igor Zamyatin  ---
May be related to PR71015

[Bug tree-optimization/70884] [6/7 regression] 2nd SRA pass confused by load from constant pool

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

--- Comment #3 from Eric Botcazou  ---
*** Bug 70919 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/70919] [6/7 Regression] wrong code at -O1 on x86_64-linux-gnu in 32-bit mode

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ebotcazou at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #4 from Eric Botcazou  ---
Obviously.

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

[Bug tree-optimization/70919] [6/7 Regression] wrong code at -O1 on x86_64-linux-gnu in 32-bit mode

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
I suspect this is a dup of bug 70884.

[Bug tree-optimization/70919] [6/7 Regression] wrong code at -O1 on x86_64-linux-gnu in 32-bit mode

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
The problem is that late SRA replaces scalar loads from constant pool
by replacements but fails to add their initializations to the
beginning of the function.

The reason for the omission is that
initialize_constant_pool_replacements only adds those for variables in
should_scalarize_away_bitmap but that bitmap was intended only as a
hint for total scalarization and a variable does not end up there if
only scalars are read from it.

Removing that condition fixes the bug.  In fact, even the
cannot_scalarize_away_bitmap seems wrong to me for the very same reason.

[Bug fortran/67497] data.c sanitizer runtime error: null pointer passed as argument 2, which is declared to never be null

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
Still in trunk:

../../gcc7/gcc/fortran/data.c:191:32: runtime error: null pointer passed as
argument 2, which is declared to never be null

here:

memcpy ([start], rvalue->value.character.string, len * sizeof
(gfc_char_t));

Probably len==0 and preponing an if(len) should do the trick

[Bug rtl-optimization/70904] ICE: Max. number of generated reload insns per insn is achieved (90) with -fno-split-wide-types @ aarch64

[jiwang at gcc dot gnu.org]

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

--- Comment #4 from Jiong Wang  ---
Author: jiwang
Date: Thu May 12 17:00:52 2016
New Revision: 236181

URL: https://gcc.gnu.org/viewcvs?rev=236181=gcc=rev
Log:
[LRA] PR70904, relax the restriction on subreg reload for wide mode 

2016-05-12  Jiong Wang  

gcc/
  PR rtl-optimization/70904
  * lra-constraint.c (process_addr_reg): Relax the restriction on
  subreg reload for wide mode.


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

[Bug c++/70869] [6/7 Regression] internal compiler error: Segmentation fault on array of pointer to function members

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

  Attachment #38472|0   |1
is obsolete||

--- Comment #15 from Kai Tietz  ---
Created attachment 38477
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38477=edit
updated patch

Updated patch.  If approved feel free to commit.  I am currently not able to
commit to repository due I need to recover my key-files ... and didn't found
time

[Bug fortran/70739] VALUE attribute interpretation in a non-interoperable procedure

[zmi007 at gmail dot com]

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

--- Comment #2 from zmi  ---
This was also my wish but I couldn't find it too and assume now as an Intel's
interpretation of standard. Would be interesting to see if such interpretation
confirmed by another vendors (I don't have access to actual compilers from
Cray, IBM etc.)

[Bug fortran/70598] Fortran OpenACC host_data construct ICE

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||patch
 CC||tschwinge at gcc dot gnu.org
   Target Milestone|7.0 |6.2

--- Comment #3 from Thomas Schwinge  ---
In
,
Chung-Lin has now posted a patch (pending review) that should make the OpenACC
host_data construct usable in GCC Fortran.  (Problem discussed in

before.)

[Bug c/70756] Wrong column number shown for "error: invalid use of flexible array member"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Should be better now.

[Bug tree-optimization/71050] [7 regression] test case gcc.target/powerpc/lhs-1.c fails starting with r236066

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from Bill Schmidt  ---
Great, thanks, Pat!  Let's hold off for now, as Segher is checking out some
ideas.

[Bug c/70756] Wrong column number shown for "error: invalid use of flexible array member"

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Thu May 12 15:28:08 2016
New Revision: 236180

URL: https://gcc.gnu.org/viewcvs?rev=236180=gcc=rev
Log:
PR c/70756
* c-common.c (pointer_int_sum): Call size_in_bytes_loc instead of
size_in_bytes and pass LOC to it.

* c-decl.c (build_compound_literal): Pass LOC down to
c_incomplete_type_error.
* c-tree.h (require_complete_type): Adjust declaration.
(c_incomplete_type_error): Likewise.
* c-typeck.c (require_complete_type): Add location parameter, pass it
down to c_incomplete_type_error.
(c_incomplete_type_error): Add location parameter, pass it down to
error_at.
(build_component_ref): Pass location down to c_incomplete_type_error.
(default_conversion): Pass location down to require_complete_type.
(build_array_ref): Likewise.
(build_function_call_vec): Likewise.
(convert_arguments): Likewise.
(build_unary_op): Likewise.
(build_c_cast): Likewise.
(build_modify_expr): Likewise.
(convert_for_assignment): Likewise.
(c_finish_omp_clauses): Likewise.

* call.c (build_new_op_1): Pass LOC to cp_build_modify_expr.
* cp-tree.h (cp_build_modify_expr): Update declaration.
(cxx_incomplete_type_error, cxx_incomplete_type_diagnostic): New inline
overloads.
* cp-ubsan.c (cp_ubsan_dfs_initialize_vtbl_ptrs): Pass INPUT_LOCATION
to
cp_build_modify_expr.
* decl2.c (set_guard): Likewise.
(handle_tls_init): Likewise.
* init.c (perform_member_init): Likewise.
(expand_virtual_init): Likewise.
(build_new_1): Likewise.
(build_vec_delete_1): Likewise.
(get_temp_regvar): Likewise.
(build_vec_init): Likewise.
* method.c (do_build_copy_assign): Likewise.
(assignable_expr): Likewise.
* semantics.c (finish_omp_for): Likewise.
* typeck.c (cp_build_binary_op): Pass LOCATION to pointer_diff and
cp_pointer_int_sum.
(cp_pointer_int_sum): Add location parameter.  Pass it down to
pointer_int_sum.
(pointer_diff): Add location parameter.  Use it.
(build_modify_expr): Pass location down to cp_build_modify_expr.
(cp_build_modify_expr): Add location parameter.  Use it.
(build_x_modify_expr): Pass location down to cp_build_modify_expr.
* typeck2.c (cxx_incomplete_type_diagnostic,
cxx_incomplete_type_error): Add location parameter.

* langhooks-def.h (lhd_incomplete_type_error): Adjust declaration.
* langhooks.c (lhd_incomplete_type_error): Add location parameter.
* langhooks.h (incomplete_type_error): Likewise.
* tree.c (size_in_bytes_loc): Renamed from size_in_bytes.  Add location
parameter, pass it down to incomplete_type_error.
* tree.h (size_in_bytes): New inline overload.
(size_in_bytes_loc): Renamed from size_in_bytes.

* c-c++-common/pr70756-2.c: New test.
* c-c++-common/pr70756.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/pr70756-2.c
trunk/gcc/testsuite/c-c++-common/pr70756.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/c/c-tree.h
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/cp-ubsan.c
trunk/gcc/cp/decl2.c
trunk/gcc/cp/init.c
trunk/gcc/cp/method.c
trunk/gcc/cp/semantics.c
trunk/gcc/cp/typeck.c
trunk/gcc/cp/typeck2.c
trunk/gcc/langhooks-def.h
trunk/gcc/langhooks.c
trunk/gcc/langhooks.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug c++/60760] arithmetic on null pointers should not be allowed in constant expressions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
  Known to fail|5.0, 6.0|5.3.0, 6.1.0

--- Comment #7 from Martin Sebor  ---
This part of the patch wasn't accepted for 6.1.0.  I'll resubmit it for 7.0.

[Bug tree-optimization/71050] [7 regression] test case gcc.target/powerpc/lhs-1.c fails starting with r236066

[pthaugen at gcc dot gnu.org]

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

--- Comment #9 from Pat Haugen  ---
(In reply to Bill Schmidt from comment #8)
> The test is verifying that we force some nops in between a store and load
> when we know they alias, to mitigate the cost of the stall while the load
> tries to get the data out of the store queue.  The extra code here gets in
> the way of that, solving the problem another way.  Pat, any thoughts on
> whether the test can be rewritten some other way to force the nop insertion?

Sure, I can easily modify the testcase to just verify there is at least 1 'nop'
insn generated. Richi's patch made us go from 3 nops to 2 since an extra stfd
occurred between the store/load causing the LHS.

[Bug libstdc++/70722] include_next in cmath skips user-defined wrapper

[guido at trentalancia dot net]

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

guido at trentalancia dot net changed:

   What|Removed |Added

 CC||guido at trentalancia dot net

--- Comment #5 from guido at trentalancia dot net ---
I am also hitting the problem reported as a duplicate of this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70872

Unfortunately, the patch suggested in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70722#c2 does not work for me.

If this is invalid as a gcc bug, then perhaps it can be opened as a bug in
firefox?!?

[Bug bootstrap/71071] [7 regression] ICE --enable-checking=fold : fold check: original tree changed by fold

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #9 from Marek Polacek  ---
CCing Richi if he has any idea how to solve this.  (I'm willing to take this
bug then.)

[Bug tree-optimization/69848] poor vectorization of a loop from SPEC2006 464.h264ref

[amker at gcc dot gnu.org]

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

--- Comment #8 from amker at gcc dot gnu.org ---
(In reply to amker from comment #7)
> (In reply to Jim Wilson from comment #6)
> > Testing the vcond_mask* patch with make check gave 6 regressions for both
> > armhf and aarch64.
> > 
> > FAIL: gcc.dg/vect/pr65947-10.c (internal compiler error)
> > FAIL: gcc.dg/vect/pr65947-10.c (test for excess errors)
> > FAIL: gcc.dg/vect/pr65947-10.c scan-tree-dump-times vect "LOOP VECTORIZED" 2
> > FAIL: gcc.dg/vect/pr65947-10.c -flto -ffat-lto-objects (internal compiler
> > error)
> > FAIL: gcc.dg/vect/pr65947-10.c -flto -ffat-lto-objects (test for excess
> > errors)
> > FAIL: gcc.dg/vect/pr65947-10.c -flto -ffat-lto-objects  scan-tree-dump-times
> > vec
> > t "LOOP VECTORIZED" 2
> > 
> > The problem here looks like a flaw in the vcond* patterns.  They support int
> > and fp compare operands, but only int selection operands.  E.g. for 
> >   (A op B ? X : Y)
> > A and B can be either int or fp, but X and Y can only be int.  Adding the
> > vcond_mask* patterns apparently causes gcc to call vcond* in ways it didn't
> > before, and that exposes the problem.
> > 
> > The x86 port is the only port with vcond and vcond_mask patterns, and it
> > supports all four combinations if int/fp compare/select operands, so it
> > appears that aarch64 should also.
> > 
> > I will need time to figure out how to fix the vcond* problems before I can
> > formally submit the vcond_mask* patch.
> 
> Hi Jim,
> We have a patch which supports all vcond/vcondu patterns (AArch64 yet)
> including missing ones.  The patch also introduces vec_cmp_mask
> because it re-implements vcond/vcondu using these two patterns.  It will be
> ready for review shortly, but this issue itself needs vectorizer fix I think.

Hmm, supporting vcond_mask can save one cmlt instruction because it's
introduced in expand_vec_cond_expr when the input op0 is not a comparison.

Propagating _20 to both VEC_COND_EXPR in below can same the "not" and "cmlt"
instructions:

  _20 = vect__1.6_8 == { 0, 0, 0, 0 };
  vect_c_2.8_16 = VEC_COND_EXPR <_20, { 0, 0, 0, 0 }, vect_c_2.7_13>;
  _21 = VEC_COND_EXPR <_20, ivtmp_17, _19>;

[Bug bootstrap/71071] [7 regression] ICE --enable-checking=fold : fold check: original tree changed by fold

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
And the place where we change the alias set?  Since r236117 we call
get_alias_set when building the ref in make_bit_field_ref, and that's what
changes the alias set of "a".

[Bug target/71080] Segfault in ix86_in_large_data_p with -fpic -mcmodel={medium, large}

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
The obvious patch (returning false for exp == NULL_TREE in
ix86_in_large_data_p) fixes the testcase above and survived
x86_64-pc-linux-gnu bootstrap.  A second make check with -mcmodel=medium
is running right now.

Rainer

[Bug bootstrap/71071] [7 regression] ICE --enable-checking=fold : fold check: original tree changed by fold

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
So, we're trying to fold the "a.dumped != 0" condition.  "a.dumped" is a
COMPONENT_REF with VAR_DECL "a", and while folding we change the alias set of
the VAR_DECL "a" from -1 to 1, so the fold checksum is upset.

[Bug lto/71089] New: [7 Regression] Failed to build 483.xalancbmk in SPEC CPU 2006

[hjl.tools at gmail dot com]

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

Bug ID: 71089
   Summary: [7 Regression] Failed to build 483.xalancbmk in SPEC
CPU 2006
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: hubicka at ucw dot cz
  Target Milestone: ---

On x86-64, r236012 caused:

g++  -O2 -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin 
-DSPEC_CPU_LP64AIXPlatformUtils.o CSetDefs.o BinHTTPURLInputStream.o
Win32PlatformUtils.o Win32MsgLoader.o Win32TransService.o Win32TransService2.o
WinSockNetAccessor.o SunCCDefs.o SolarisPlatformUtils.o GCCDefs.o
LinuxPlatformUtils.o MIPSproDefs.o IRIXPlatformUtils.o HPCCDefs.o
HPPlatformUtils.o WFXMLScanner.o ASCIIRangeFactory.o AbstractDOMParser.o
AbstractNumericFacetValidator.o AbstractNumericValidator.o
AbstractStringValidator.o AllContentModel.o AnySimpleTypeDatatypeValidator.o
AnyURIDatatypeValidator.o AttrImpl.o AttrMapImpl.o AttrNSImpl.o BMPattern.o
Base64.o Base64BinaryDatatypeValidator.o BinFileInputStream.o
BinFileOutputStream.o BinInputStream.o BinMemInputStream.o BinMemOutputStream.o
BinOutputStream.o BitSet.o BlockRangeFactory.o BooleanDatatypeValidator.o
CDATASectionImpl.o CMAny.o CMBinaryOp.o CMUnaryOp.o CharToken.o
CharacterDataImpl.o ChildNode.o ClosureToken.o CommentImpl.o ComplexTypeInfo.o
ConcatToken.o ConditionToken.o ContentLeafNameTypeVector.o ContentSpecNode.o
DFAContentModel.o DGXMLScanner.o DOMAttrImpl.o DOMAttrMapImpl.o DOMAttrNSImpl.o
DOMBuilderImpl.o DOMCDATASectionImpl.o DOMCharacterDataImpl.o DOMChildNode.o
DOMCommentImpl.o DOMConfigurationImpl.o DOMDeepNodeListImpl.o
DOMDocumentFragmentImpl.o DOMDocumentImpl.o DOMDocumentTypeImpl.o
DOMElementImpl.o DOMElementNSImpl.o DOMEntityImpl.o DOMEntityReferenceImpl.o
DOMErrorImpl.o DOMException.o DOMImplementationImpl.o
DOMImplementationRegistry.o DOMLocatorImpl.o DOMNamedNodeMapImpl.o
DOMNodeIDMap.o DOMNodeImpl.o DOMNodeIteratorImpl.o DOMNodeListImpl.o
DOMNodeVector.o DOMNormalizer.o DOMNotationImpl.o DOMParentNode.o DOMParser.o
DOMProcessingInstructionImpl.o DOMRangeException.o DOMRangeImpl.o DOMString.o
DOMStringPool.o DOMTextImpl.o DOMTreeWalkerImpl.o DOMTypeInfoImpl.o
DOMWriterImpl.o DOMXPathException.o DOM_Attr.o DOM_CDATASection.o
DOM_CharacterData.o DOM_Comment.o DOM_DOMException.o DOM_DOMImplementation.o
DOM_Document.o DOM_DocumentFragment.o DOM_DocumentType.o DOM_Element.o
DOM_Entity.o DOM_EntityReference.o DOM_NamedNodeMap.o DOM_Node.o
DOM_NodeFilter.o DOM_NodeIterator.o DOM_NodeList.o DOM_Notation.o
DOM_ProcessingInstruction.o DOM_Range.o DOM_RangeException.o DOM_Text.o
DOM_TreeWalker.o DOM_XMLDecl.o DStringPool.o DTDAttDef.o DTDAttDefList.o
DTDElementDecl.o DTDEntityDecl.o DTDGrammar.o DTDScanner.o DTDValidator.o
DatatypeValidator.o DatatypeValidatorFactory.o DateDatatypeValidator.o
DateTimeDatatypeValidator.o DateTimeValidator.o DayDatatypeValidator.o
DecimalDatatypeValidator.o DeepNodeListImpl.o DefaultPanicHandler.o
DocumentFragmentImpl.o DocumentImpl.o DocumentTypeImpl.o DomMemDebug.o
DoubleDatatypeValidator.o Dummy.o DurationDatatypeValidator.o
ENTITYDatatypeValidator.o ElemStack.o ElementDefinitionImpl.o ElementImpl.o
ElementNSImpl.o EncodingValidator.o EntityImpl.o EntityReferenceImpl.o
FieldActivator.o FieldValueMap.o FloatDatatypeValidator.o
GeneralAttributeCheck.o Grammar.o GrammarResolver.o HashPtr.o HashXMLCh.o
HeaderDummy.o HexBin.o HexBinaryDatatypeValidator.o IC_Field.o IC_Key.o
IC_KeyRef.o IC_Selector.o IC_Unique.o IDDatatypeValidator.o
IDREFDatatypeValidator.o IGXMLScanner.o IGXMLScanner2.o IconvTransService.o
IdentityConstraint.o InMemMsgLoader.o InputSource.o KVStringPair.o
ListDatatypeValidator.o LocalFileFormatTarget.o LocalFileInputSource.o Match.o
MemBufFormatTarget.o MemBufInputSource.o MemoryManagerArrayImpl.o
MemoryManagerImpl.o MixedContentModel.o ModifierToken.o
MonthDatatypeValidator.o MonthDayDatatypeValidator.o Mutexes.o
NCNameDatatypeValidator.o NOTATIONDatatypeValidator.o NameDatatypeValidator.o
NamedNodeMapImpl.o NamespaceScope.o NodeIDMap.o NodeImpl.o NodeIteratorImpl.o
NodeListImpl.o NodeVector.o NotationImpl.o Op.o OpFactory.o PSVIAttribute.o
PSVIAttributeList.o PSVIElement.o PSVIItem.o PanicHandler.o ParenToken.o
ParentNode.o ParserForXMLSchema.o PlatformUtils.o ProcessingInstructionImpl.o
QName.o QNameDatatypeValidator.o RangeFactory.o RangeImpl.o RangeToken.o
RangeTokenMap.o ReaderMgr.o RefCountedImpl.o RegularExpression.o RegxParser.o
RegxUtil.o SAX2XMLReaderImpl.o SAXException.o SAXParseException.o SAXParser.o
SGXMLScanner.o SchemaAttDef.o SchemaAttDefList.o SchemaElementDecl.o
SchemaGrammar.o SchemaInfo.o SchemaSymbols.o SchemaValidator.o
SimpleContentModel.o StdInInputSource.o StdOutFormatTarget.o
StringDatatypeValidator.o StringPool.o StringToken.o
SubstitutionGroupComparator.o 

[Bug tree-optimization/71050] [7 regression] test case gcc.target/powerpc/lhs-1.c fails starting with r236066

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Even this test case isn't truly horrible for real-world code (it looks nastier
than it is, as stack stores tend to have minimal real cost).  This is an issue
only on "older" processors; it's just that a lot of those older processors,
particularly POWER7, are still in use.  With POWER8 and later, direct moves
between GPR and FPR register files make this worthwhile.

I don't know that we need to do anything to fix this right now, other than to
try to find some other way to test what this test case is trying to verify (the
new code made this impossible).  Is your change done at all opt levels?  I'm
not sure whether this test would work at lower opt, anyway.

The test is verifying that we force some nops in between a store and load when
we know they alias, to mitigate the cost of the stall while the load tries to
get the data out of the store queue.  The extra code here gets in the way of
that, solving the problem another way.  Pat, any thoughts on whether the test
can be rewritten some other way to force the nop insertion?

Long term, having a way to ask the back end if a particular subreg is a good or
bad idea seems useful, as this probably comes up in a number of contexts.  I
don't have any stellar ideas about how to do that yet (other than Yet Another
Target Hook Not Everyone Implements).  It doesn't fit in our usual cost-model
query structure.

[Bug sanitizer/69840] two ASAN help nits

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Well, it looks llvm folk are not convinced about the behavior:
http://reviews.llvm.org/D17566

Do we want to do it in the GCC anyway or not?

Martin

[Bug tree-optimization/71006] [6 Regression] ICE: verify_gimple failed (error: type mismatch in conditional expression) w/ -O1 -ftree-loop-vectorize

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #8 from Ilya Enkovich  ---
Fixed

[Bug hsa/70857] [6/7 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
This bug is a consequence of false sharing of a RESULT_DECL between
the CPU-intended OpenMP outlined function and the HSA-intended
outlined (kernel) one.  How come -fopenacc is necessary to trigger it,
I don't know but the following patch fixes it.  I need to bring my
various branches up to speed for proper testing before I send it to
the mailing list.

diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index c9600fb..a11f44b 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -13681,6 +13681,9 @@ grid_expand_target_grid_body (struct omp_region
*target)
   tree new_parm_decl = copy_node (DECL_ARGUMENTS (kern_fndecl));
   DECL_CONTEXT (new_parm_decl) = kern_fndecl;
   DECL_ARGUMENTS (kern_fndecl) = new_parm_decl;
+  gcc_assert (VOID_TYPE_P (TREE_TYPE (DECL_RESULT (kern_fndecl;
+  DECL_RESULT (kern_fndecl) = copy_node (DECL_RESULT (kern_fndecl));
+  DECL_CONTEXT (DECL_RESULT (kern_fndecl)) = kern_fndecl;
   struct function *kern_cfun = DECL_STRUCT_FUNCTION (kern_fndecl);
   kern_cfun->curr_properties = cfun->curr_properties;

[Bug libstdc++/71081] experimental/memory_resource/1.cc run for targets without atomics

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu May 12 14:08:45 2016
New Revision: 236177

URL: https://gcc.gnu.org/viewcvs?rev=236177=gcc=rev
Log:
Add dg-require-atomic-builtins to test

PR libstdc++/71081
* testsuite/experimental/memory_resource/1.cc: Require atomics.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/experimental/memory_resource/1.cc

[Bug libstdc++/71081] experimental/memory_resource/1.cc run for targets without atomics

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #1 from Jonathan Wakely  ---
Added.

[Bug tree-optimization/71006] [6 Regression] ICE: verify_gimple failed (error: type mismatch in conditional expression) w/ -O1 -ftree-loop-vectorize

[ienkovich at gcc dot gnu.org]

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

--- Comment #7 from Ilya Enkovich  ---
Author: ienkovich
Date: Thu May 12 14:07:13 2016
New Revision: 236176

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

Backport from mainline r236171.
2016-05-12  Ilya Enkovich  

PR tree-optimization/71006
* tree-vect-loop.c (vect_determine_vectorization_factor): Don't
consider COND_EXPR as a mask producer.

gcc/testsuite/

Backport from mainline r236171.
2016-05-12  Ilya Enkovich  

PR tree-optimization/71006
* gcc.dg/pr71006.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr71006.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-vect-loop.c

[Bug fortran/70856] [6/7 Regression] ICE with -fopenacc in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2952

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org,
   ||vries at gcc dot gnu.org

--- Comment #3 from Thomas Schwinge  ---
I had a cursory look at that one.  Differently from PR70857, the ICE triggers
here the second time that pass_ipa_pta is run (all_late_ipa_passes), and not
the first one (which is only active if "-fopenacc" is in effect; Tom CCed for
your information anyway).  This is "fixed" ;-) by reverting the r233734 changes
for PR69951 "[Bug tree-optimization/69951] wrong code at -O1 and above on
x86_64-linux-gnu":

2016-02-26  Richard Biener  

PR tree-optimization/69551
* tree-ssa-structalias.c (get_constraint_for_ssa_var): When
looking through aliases adjust DECL_PT_UID to refer to the
ultimate alias target.

--- gcc/tree-ssa-structalias.c
+++ gcc/tree-ssa-structalias.c
@@ -2943,6 +2943,14 @@ get_constraint_for_ssa_var (tree t, vec
*results, bool address_p)
   if (node && node->alias && node->analyzed)
{
  node = node->ultimate_alias_target ();
+ /* Canonicalize the PT uid of all aliases to the ultimate target.
+???  Hopefully the set of aliases can't change in a way that
+changes the ultimate alias target.  */
+ gcc_assert ((! DECL_PT_UID_SET_P (node->decl)
+  || DECL_PT_UID (node->decl) == DECL_UID
(node->decl))
+ && (! DECL_PT_UID_SET_P (t)
+ || DECL_PT_UID (t) == DECL_UID (node->decl)));
+ DECL_PT_UID (t) = DECL_UID (node->decl);
  t = node->decl;
}
 }

(gdb) call node->debug()
A.4.3435/10 (A.4) @0x76a7f800
  Type: variable definition analyzed
  Visibility: prevailing_def_ironly artificial
  References: 
  Referring: A.1.3429/6 (alias)MAIN__/0 (read)
  Availability: available
  Varpool flags: initialized used-by-single-function read-only
const-value-known
(gdb) call debug_tree(node->decl)
 
unit size 
align 32 symtab 0 alias set 9 canonical type 0x768e6540
precision 32
pointer_to_this >
type_2 DI
size 
unit size 
align 32 symtab 0 alias set 9 canonical type 0x76a91b28
domain 
DI size  unit size 
align 64 symtab 0 alias set -1 canonical type 0x76a91540
precision 64 min  max >
pointer_to_this >
readonly constant static ignored DI file ../pr70856-z1.f90 line 3 col 0
size  unit size 
align 64 context  initial >
(gdb) call debug_tree(t)
 
unit size 
align 32 symtab 0 alias set 9 canonical type 0x768e6540
precision 32
pointer_to_this >
type_2 DI
size 
unit size 
align 32 symtab 0 alias set 9 canonical type 0x76a911f8
domain 
DI size  unit size 
align 64 symtab 0 alias set -1 canonical type 0x76a91540
precision 64 min  max >
pointer_to_this >
readonly constant static ignored DI file ../pr70856-z1.f90 line 2 col 0
size  unit size 
align 64 context >

[Bug bootstrap/71071] [7 regression] ICE --enable-checking=fold : fold check: original tree changed by fold

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Did we forget to unshare_expr somewhere?

[Bug bootstrap/71071] [7 regression] ICE --enable-checking=fold : fold check: original tree changed by fold

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
struct
{
  unsigned dumped:1;
} a;
void
fn1 ()
{
  if (a.dumped)
;
}

[Bug tree-optimization/71050] [7 regression] test case gcc.target/powerpc/lhs-1.c fails starting with r236066

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Apart from this testcase do you see any negative impact in real-world code?
That said, the positive impact on real-world code will likely be detecting
some more byte-shuffling code plus lowpart-subregs plus vector extracts.

Like some cases in PR42587 can now be handled by teaching the bswap pass
of BIT_FIELD_REF.

typedef unsigned char u8;
typedef unsigned int u32;
union __anonunion
{
  u32 value;
  u8 bytes[4];
};
u32
acpi_ut_dword_byte_swap (u32 value)
{
  union __anonunion in;
  in.value = value;
  return (in.bytes[0] << 8) | in.bytes[1]) << 8) | in.bytes[2]) << 8) |
in.bytes[3];
}

becomes

  :
  _19 = (int) value_12(D);
  _20 = _19 << 8;
  _2 = _20 & 65535;
  _15 = BIT_FIELD_REF ;
  _3 = (int) _15;
  _4 = _2 | _3;
  _5 = _4 << 8;
  _16 = BIT_FIELD_REF ;
  _6 = (int) _16;
  _7 = _5 | _6;
  _8 = _7 << 8;
  _17 = BIT_FIELD_REF ;
  _9 = (int) _17;
  _10 = _8 | _9;
  _13 = (u32) _10;
  return _13;

[Bug bootstrap/71071] [7 regression] ICE --enable-checking=fold : fold check: original tree changed by fold

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Created attachment 38476
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38476=edit
libgcov-driver.i

$ ./cc1 -quiet libgcov-driver.i
/home/marek/src/gcc/libgcc/libgcov-driver.c: In function ‘__gcov_dump_one’:
/home/marek/src/gcc/libgcc/libgcov-driver.c:855:3: internal compiler error:
fold check: original tree changed by fold
   if (root->dumped)
   ^~
0x9c37dc fold_check_failed
/home/marek/src/gcc/gcc/fold-const.c:12099
0x9c4aff fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/marek/src/gcc/gcc/fold-const.c:12359
0x123df44 generic_simplify_186
/home/marek/x/trunk/gcc/generic-match.c:6903
0x128a166 generic_simplify_NE_EXPR
/home/marek/x/trunk/gcc/generic-match.c:27430
0x1290e7d generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/marek/x/trunk/gcc/generic-match.c:29656
0x9b422e fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/marek/src/gcc/gcc/fold-const.c:9265
0x9c4a3f fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/marek/src/gcc/gcc/fold-const.c:12348
0x745d3d c_fully_fold_internal
/home/marek/src/gcc/gcc/c/c-fold.c:305
0x7470bb c_fully_fold(tree_node*, bool, bool*)
/home/marek/src/gcc/gcc/c/c-fold.c:90
0x7179ca c_parser_condition
/home/marek/src/gcc/gcc/c/c-parser.c:5314
0x717a47 c_parser_paren_condition
/home/marek/src/gcc/gcc/c/c-parser.c:5331
0x730b13 c_parser_if_statement
/home/marek/src/gcc/gcc/c/c-parser.c:5493
0x730b13 c_parser_statement_after_labels
/home/marek/src/gcc/gcc/c/c-parser.c:5138
0x732615 c_parser_compound_statement_nostart
/home/marek/src/gcc/gcc/c/c-parser.c:4858
0x732a5e c_parser_compound_statement
/home/marek/src/gcc/gcc/c/c-parser.c:4693
0x72e6a9 c_parser_declaration_or_fndef
/home/marek/src/gcc/gcc/c/c-parser.c:2105
0x73a4bd c_parser_external_declaration
/home/marek/src/gcc/gcc/c/c-parser.c:1549
0x73ad99 c_parser_translation_unit
/home/marek/src/gcc/gcc/c/c-parser.c:1430
0x73ad99 c_parse_file()
/home/marek/src/gcc/gcc/c/c-parser.c:17915
0x79d702 c_common_parse_file()
/home/marek/src/gcc/gcc/c-family/c-opts.c:1064
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/71059] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu in "vn_nary_op_insert_into"

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu May 12 13:46:26 2016
New Revision: 236175

URL: https://gcc.gnu.org/viewcvs?rev=236175=gcc=rev
Log:
2016-05-12  Richard Biener  

PR tree-optimization/71059
* tree-ssa-pre.c (phi_translate_1): Fully fold translated
nary before looking up or entering the expression into the VN
hashes.
* tree-ssa-sccvn.c (vn_nary_build_or_lookup): Fix comment typo.
Make sure to re-use NARYs without result as inserted by
phi-translation.

* gcc.dg/torture/pr71059.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr71059.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c
trunk/gcc/tree-ssa-sccvn.c

[Bug hsa/70857] [6/7 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openacc
 CC||tschwinge at gcc dot gnu.org,
   ||vries at gcc dot gnu.org

--- Comment #3 from Thomas Schwinge  ---
I had a cursory look at this.  The ICE with
gcc/testsuite/gfortran.dg/gomp/gridify-1.f90 occurs for "-fopenacc -fopenmp
-O1", and disappears for "-fno-openacc", or alternatively to that, also
disappears if "hsa" offloading is disabled using the "-foffload" option. 
Backtrace:

#1  0x00da4d7c in insert_vi_for_tree (t=0x768d7258,
vi=vi@entry=0x20b8d40) at [...]/source-gcc/gcc/tree-ssa-structalias.c:2821
#2  0x00da9edb in create_function_info_for (decl=0x76a8ed20,
name=0x76a946c0 "vector_square_._omp_fn.0", 
add_id=add_id@entry=false, nonlocal_p=nonlocal_p@entry=false) at
[...]/source-gcc/gcc/tree-ssa-structalias.c:5686
#3  0x00daf7c9 in ipa_pta_execute () at
[...]/source-gcc/gcc/tree-ssa-structalias.c:7703
#4  0x00db0a62 in (anonymous namespace)::pass_ipa_pta::execute
(this=0x1fa35e0) at [...]/source-gcc/gcc/tree-ssa-structalias.c:8041
#5  0x00afdd3d in execute_one_pass (pass=pass@entry=0x1fa35e0) at
[...]/source-gcc/gcc/passes.c:2344
#6  0x00afeac2 in execute_ipa_pass_list (pass=0x1fa35e0) at
[...]/source-gcc/gcc/passes.c:2774
#7  0x00afeaee in execute_ipa_pass_list (pass=0x1fa3580) at
[...]/source-gcc/gcc/passes.c:2786
#8  0x007e3805 in ipa_passes () at
[...]/source-gcc/gcc/cgraphunit.c:2266
#9  symbol_table::compile (this=this@entry=0x768d10a8) at
[...]/source-gcc/gcc/cgraphunit.c:2405
#10 0x007e5b9a in symbol_table::finalize_compilation_unit
(this=0x768d10a8) at [...]/source-gcc/gcc/cgraphunit.c:2565
#11 0x00bc3a8a in compile_file () at
[...]/source-gcc/gcc/toplev.c:488
#12 0x005fd99d in do_compile () at
[...]/source-gcc/gcc/toplev.c:1987
#13 toplev::main (this=this@entry=0x7fffcd60, argc=argc@entry=27,
argv=argv@entry=0x7fffce68) at [...]/source-gcc/gcc/toplev.c:2095
#14 0x005ff4d7 in main (argc=27, argv=0x7fffce68) at
[...]/source-gcc/gcc/main.c:39

This is the first pass_ipa_pta, run within pass_ipa_oacc, if "-fopenacc" is in
effect.  (That is required for OpenACC kernels processing; Tom CCed for your
information.)

(gdb) break insert_vi_for_tree
Breakpoint 4 at 0xd94660: file [...]/source-gcc/gcc/tree-ssa-structalias.c,
line 2817.
(gdb) c
Continuing.
Breakpoint 4, insert_vi_for_tree (t=0x76aa50e0, vi=0x2091340)
Breakpoint 4, insert_vi_for_tree (t=0x768d7258, vi=0x2091430)
Breakpoint 4, insert_vi_for_tree (t=0x76a7f680, vi=0x2091480)
Breakpoint 4, insert_vi_for_tree (t=0x76a8ee00, vi=0x20914d0)
Breakpoint 4, insert_vi_for_tree (t=0x768d72d0, vi=0x20915c0)
Breakpoint 4, insert_vi_for_tree (t=0x76a7f500, vi=0x2091610)
Breakpoint 4, insert_vi_for_tree (t=0x76a8ed20, vi=0x2091660)
Breakpoint 4, insert_vi_for_tree (t=0x768d7258, vi=0x2091750)

That is, unexpectedly, the same "t" that we've already seen in the second hit
of that breakpoint, and thus the second gcc_assert will trigger:

/* Map from trees to variable infos.  */
static hash_map *vi_for_tree;
[...]
/* Insert ID as the variable id for tree T in the vi_for_tree map.  */

static void
insert_vi_for_tree (tree t, varinfo_t vi)
{
  gcc_assert (vi);
  gcc_assert (!vi_for_tree->put (t, vi));
}

(gdb) call debug_tree(t)
 >
ignored VOID file
source-gcc/gcc/testsuite/gfortran.dg/gomp/gridify-1.f90 line 7 col 0
align 8 context >

[Bug tree-optimization/71084] [7 Regression] ICE in compute_dominance_frontiers_1 (cfganal.c:1302)

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to Ilya Enkovich from comment #5)
> (In reply to Richard Biener from comment #3)
> > fwprop_init calcuates dominator info so it's likely df that runs cfg-cleanup
> > and doesn't expect it to wreck dominator info.
> > 
> > Probably rightfully so.
> 
> So should we improve cse_cfg_altered  computation taking cfg_cleanup calls
> into account or free dominance info in cfg_cleanup instead?

The former.

[Bug tree-optimization/71059] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu in "vn_nary_op_insert_into"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/71062] [7 regression] r235622 and restrict pointers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/29756] SSE intrinsics hard to use without redundant temporaries appearing

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
So I have it down to a x86 combine issue:

;; v_28 = BIT_FIELD_INSERT ;

(insn 7 6 8 (set (reg:SF 116)
(vec_select:SF (reg/v:V4SF 115 [ v ])
(parallel [
(const_int 0 [0])
]))) t.c:5 -1
 (nil))

(insn 8 7 9 (set (reg:V4SF 117)
(reg/v:V4SF 109 [ v ])) t.c:11 -1
 (nil))

(insn 9 8 10 (set (reg:V4SF 117)
(vec_merge:V4SF (vec_duplicate:V4SF (reg:SF 116))
(reg:V4SF 117)
(const_int 1 [0x1]))) t.c:11 -1
 (nil))

(insn 10 9 0 (set (reg/v:V4SF 110 [ v ])
(reg:V4SF 117)) t.c:11 -1
 (nil))

that's from what vec_set_optab produces

;; _29 = __builtin_ia32_shufps (v_28, v_28, 0);

(insn 11 10 12 (set (reg:V4SF 119)
(reg/v:V4SF 110 [ v ])) t.c:12 -1
 (nil))

(insn 12 11 13 (set (reg:V4SF 120)
(reg/v:V4SF 110 [ v ])) t.c:12 -1
 (nil))

(insn 13 12 14 (set (reg:V4SF 118)
(vec_select:V4SF (vec_concat:V8SF (reg:V4SF 119)
(reg:V4SF 120))
(parallel [
(const_int 0 [0])
(const_int 0 [0])
(const_int 4 [0x4])
(const_int 4 [0x4])
]))) t.c:12 -1
 (nil))

(insn 14 13 0 (set (reg:V4SF 111 [ _29 ])
(reg:V4SF 118)) t.c:12 -1
 (nil))

and that's the shuffle.  And after combine we have

(insn 7 4 53 2 (set (reg:SF 116)
(vec_select:SF (reg/v:V4SF 115 [ v ])
(parallel [
(const_int 0 [0])
]))) t.c:5 2423 {*vec_extractv4sf_0}
 (nil))
(insn 9 53 13 2 (set (reg:V4SF 117 [ v ])
(vec_merge:V4SF (vec_duplicate:V4SF (reg:SF 116))
(const_vector:V4SF [
(const_double:SF 0.0 [0x0.0p+0])
(const_double:SF 0.0 [0x0.0p+0])
(const_double:SF 0.0 [0x0.0p+0])
(const_double:SF 0.0 [0x0.0p+0])
])
(const_int 1 [0x1]))) t.c:11 2420 {vec_setv4sf_0}
 (expr_list:REG_DEAD (reg:SF 116)
(nil)))
(insn 13 9 15 2 (set (reg:V4SF 118)
(vec_select:V4SF (vec_concat:V8SF (reg:V4SF 117 [ v ])
(reg:V4SF 117 [ v ]))
(parallel [
(const_int 0 [0])
(const_int 0 [0])
(const_int 4 [0x4])
(const_int 4 [0x4])
]))) t.c:12 2405 {sse_shufps_v4sf}
 (expr_list:REG_DEAD (reg:V4SF 117 [ v ])
(nil)))

which combine doesn't manage to get down to

(insn 9 4 13 2 (set (reg:V4SF 104)
(vec_select:V4SF (vec_concat:V8SF (reg/v:V4SF 103 [ v ])
(reg/v:V4SF 103 [ v ]))
(parallel [
(const_int 0 [0])
(const_int 0 [0])
(const_int 4 [0x4])
(const_int 4 [0x4])
]))) t.c:18 2405 {sse_shufps_v4sf}
 (nil))



The testcase was the following.

#include 

template  inline float component(__v4sf v)
{
  return (reinterpret_cast())[N];
}

inline __v4sf fill(float f)
{
  __v4sf v;
  *(reinterpret_cast())=f;
  return ((__m128) __builtin_ia32_shufps ((__v4sf)(v), (__v4sf)(v), 0));
}

template  inline __v4sf component_fill(__v4sf v)
{
  return ((__m128) __builtin_ia32_shufps ((__v4sf)(v), (__v4sf)(v), 
  N) << 6) | ((N) << 4) | ((N) << 2) | (N);
}

__v4sf transform_bad(__v4sf m[4],__v4sf v)
{
  return m[0]*fill(component<0>(v))
  +m[1]*fill(component<1>(v))
  +m[2]*fill(component<2>(v))
  +m[3]*fill(component<3>(v));
}

__v4sf transform_good(__v4sf m[4],__v4sf v)
{
  return m[0]*component_fill<0>(v)
  +m[1]*component_fill<1>(v)
  +m[2]*component_fill<2>(v)
  +m[3]*component_fill<3>(v);
}

[Bug tree-optimization/71050] [7 regression] test case gcc.target/powerpc/lhs-1.c fails starting with r236066

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
Yes, I see your point -- even if you query the RTX cost of the subreg, we're
just going to tell you it's one insn since the true expense doesn't show up
until reload.  Seems like some invention will be required.

[Bug middle-end/44382] Slow integer multiply

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #13 from Bill Schmidt  ---
Fixed, then.

[Bug target/71088] New: [i386, AVX-512, Perf] vpermi2ps instead of vpermps emitted

[iverbin at gcc dot gnu.org]

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

Bug ID: 71088
   Summary: [i386, AVX-512, Perf] vpermi2ps instead of vpermps
emitted
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iverbin at gcc dot gnu.org
CC: ienkovich at gcc dot gnu.org, izamyatin at gmail dot com,
kyukhin at gcc dot gnu.org, ubizjak at gmail dot com
  Target Milestone: ---

Testcase:

float foo (float *arr1, float *arr2, float *max_x, int M, float s)
{
  float *res = new float[M];

  for (int i = M - 1; i >= 0; i--)
for (int j = 0; j <= i; j++)
  {
float x = arr1[j] * arr2[i - j] + s;
res[j] = x > max_x[j] ? x : max_x[j];
  }

  return res[0];
}

To reproduce:

$ g++ -S test.cpp -Ofast -funroll-loops -march=knl

GCC emits vpermi2ps instruction to rearrange elements of arr2 backwards,
however
this instruction writes the result into the index register, therefore there are
additional movs before each vpermi2ps to restore indexes [1].
Also there are some weird movs after each vpermi2ps [2].  It's not clear why
the
result from vpermi2ps isn't passed directly to vfmadd132ps.

.L1:
vmovups   (%r11), %zmm9
vmovdqa64 %zmm2, %zmm1  # [1]
vpermi2ps %zmm9, %zmm9, %zmm1
vmovdqa64 %zmm2, %zmm16 # [1]
vmovaps   %zmm1, %zmm10 # [2]
vmovdqa64 %zmm2, %zmm1  # [1]
vmovups   -64(%r11), %zmm12
vfmadd132ps   (%rax,%r9), %zmm3, %zmm10
vpermi2ps %zmm12, %zmm12, %zmm1
vmaxps(%rcx,%r9), %zmm10, %zmm11
vmovaps   %zmm1, %zmm13 # [2]
vmovdqa64 %zmm2, %zmm1  # [1]
vmovups   -128(%r11), %zmm15
vfmadd132ps   64(%rax,%r9), %zmm3, %zmm13
vmovups   -192(%r11), %zmm6
vpermi2ps %zmm15, %zmm15, %zmm1
vpermi2ps %zmm6, %zmm6, %zmm16
vmovaps   %zmm1, %zmm4  # [2]
vmovaps   %zmm16, %zmm7 # [2]
vmaxps64(%rcx,%r9), %zmm13, %zmm14
vfmadd132ps   128(%rax,%r9), %zmm3, %zmm4
vfmadd132ps   192(%rax,%r9), %zmm3, %zmm7
vmaxps128(%rcx,%r9), %zmm4, %zmm5
leal  4(%r15), %r15d
vmaxps192(%rcx,%r9), %zmm7, %zmm8
cmpl  %esi, %r15d
vmovups   %zmm11, (%r8,%r9)
leaq  -256(%r11), %r11
vmovups   %zmm14, 64(%r8,%r9)
vmovups   %zmm5, 128(%r8,%r9)
vmovups   %zmm8, 192(%r8,%r9)
leaq  256(%r9), %r9
jb.L1

Instead of this, vpermps can be used.  It doesn't overwrite the index register,
what allows to get rid of 8 movs in this loop:

.L2:
lea   (,%r12,4), %r10
negq  %r10
addq  %rbx, %r10
vpermps   -64(%r10), %zmm3, %zmm4
vpermps   -128(%r10), %zmm3, %zmm6
vpermps   -192(%r10), %zmm3, %zmm8
vpermps   -256(%r10), %zmm3, %zmm10
vfmadd132ps   (%r11,%r12,4), %zmm2, %zmm4
vfmadd132ps   64(%r11,%r12,4), %zmm2, %zmm6
vfmadd132ps   128(%r11,%r12,4), %zmm2, %zmm8
vfmadd132ps   192(%r11,%r12,4), %zmm2, %zmm10
vmaxps(%r13,%r12,4), %zmm4, %zmm5
vmovups   %zmm5, (%rdi,%r12,4)
vmaxps64(%r13,%r12,4), %zmm6, %zmm7
vmovups   %zmm7, 64(%rdi,%r12,4)
vmaxps128(%r13,%r12,4), %zmm8, %zmm9
vmovups   %zmm9, 128(%rdi,%r12,4)
vmaxps192(%r13,%r12,4), %zmm10, %zmm11
vmovups   %zmm11, 192(%rdi,%r12,4)
addq  $64, %r12
cmpq  %rax, %r12
jb.L2

[Bug bootstrap/71071] [7 regression] ICE --enable-checking=fold : fold check: original tree changed by fold

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
commit 6fcaaf9b931078f979a0282d396e78647ea37999
Author: rguenth 
Date:   Wed May 11 10:24:11 2016 +

2016-05-11  Richard Biener  

PR middle-end/71002
* alias.c (reference_alias_ptr_type): Preserve alias-set zero
if the langhook insists on it.
* fold-const.c (make_bit_field_ref): Add arg for the original
reference and preserve its alias-set.
(decode_field_reference): Take exp by reference and adjust it
to the original memory reference.
(optimize_bit_field_compare): Adjust callers.
(fold_truth_andor_1): Likewise.
* gimplify.c (gimplify_expr): Adjust in-SSA form test.

* g++.dg/torture/pr71002.C: New testcase.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@236117
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug bootstrap/71071] [7 regression] ICE --enable-checking=fold : fold check: original tree changed by fold

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
I'm bisecting this.

[Bug tree-optimization/71084] [7 Regression] ICE in compute_dominance_frontiers_1 (cfganal.c:1302)

[ienkovich at gcc dot gnu.org]

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

--- Comment #5 from Ilya Enkovich  ---
(In reply to Richard Biener from comment #3)
> fwprop_init calcuates dominator info so it's likely df that runs cfg-cleanup
> and doesn't expect it to wreck dominator info.
> 
> Probably rightfully so.

So should we improve cse_cfg_altered  computation taking cfg_cleanup calls into
account or free dominance info in cfg_cleanup instead?

[Bug debug/70935] [6 Regression] ICE: verify_ssa failed (error: definition in block 9 does not dominate use in block 12) w/ -O3 -g

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #8 from Ilya Enkovich  ---
Fixed

[Bug middle-end/71062] [7 regression] r235622 and restrict pointers

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu May 12 13:05:13 2016
New Revision: 236174

URL: https://gcc.gnu.org/viewcvs?rev=236174=gcc=rev
Log:
2016-05-12  Richard Biener  

PR tree-optimization/71062
* tree-ssa-alias.h (struct pt_solution): Add vars_contains_restrict
field.
* tree-ssa-structalias.c (set_uids_in_ptset): Set
vars_contains_restrict
if the var is a restrict tag.
* tree-ssa-alias.c (ptrs_compare_unequal): If vars_contains_restrict
do not disambiguate pointers against it.
(dump_points_to_solution): Re-structure and adjust for new
vars_contains_restrict flag.
* gimple-pretty-print.c (pp_points_to_solution): Likewise.

* gcc.dg/torture/pr71062.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr71062.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-pretty-print.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-alias.h
trunk/gcc/tree-ssa-structalias.c

[Bug debug/70935] [6 Regression] ICE: verify_ssa failed (error: definition in block 9 does not dominate use in block 12) w/ -O3 -g

[asolokha at gmx dot com]

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

--- Comment #7 from Arseny Solokha  ---
Can this PR be closed as RESOLVED FIXED now, or are there still parts missing?

[Bug tree-optimization/71084] [7 Regression] ICE in compute_dominance_frontiers_1 (cfganal.c:1302)

[ienkovich at gcc dot gnu.org]

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

--- Comment #4 from Ilya Enkovich  ---
This is still CSE invalidating dominance info.  Calls to cleanup_cfg don't
affect cse_cfg_altered.  If I replace cfg_cleanup calls with

cse_cfg_altered |= cleanup_cfg (..)

then testcase passes.

[Bug tree-optimization/69232] floop-unroll-and-jam, at graphite_transform_loops with isl

[nickpapior at gmail dot com]

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

Nick  changed:

   What|Removed |Added

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

--- Comment #2 from Nick  ---
Fixed (works in 6.1.0)

[Bug fortran/69741] Bad error in formal with array scalar loop counters

[nickpapior at gmail dot com]

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

Nick  changed:

   What|Removed |Added

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

--- Comment #9 from Nick  ---
The error message has been updated and the bug is not part of the fortran
specification.

[Bug bootstrap/71071] [7 regression] ICE --enable-checking=fold : fold check: original tree changed by fold

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

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

[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 #6 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu May 12 12:47:03 2016
New Revision: 236173

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

Backport from mainline
2016-05-12  Kyrylo Tkachov  

PR target/70830
* config/arm/arm.c (arm_output_multireg_pop): Avoid POP instruction
when popping the PC and within an interrupt handler routine.
Add missing tab to output of "ldmfd".
(output_return_instruction): Output LDMFD with SP update rather
than POP when returning from interrupt handler.

* gcc.target/arm/interrupt-1.c: Change dg-compile to dg-assemble.
Add -save-temps to dg-options.
Scan for ldmfd rather than pop instruction.
* gcc.target/arm/interrupt-2.c: Likewise.
* gcc.target/arm/pr70830.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/arm/pr70830.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/arm/arm.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.target/arm/interrupt-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/arm/interrupt-2.c

[Bug fortran/71087] New: scipy amos crash

[nickpapior at gmail dot com]

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

Bug ID: 71087
   Summary: scipy amos crash
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickpapior at gmail dot com
  Target Milestone: ---

Created attachment 38475
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38475=edit
Source code trigging bug

- Compiling amos/zunhj.f in scipy package crashes with:

zunhj.f:1:0:

   SUBROUTINE ZUNHJ(ZR, ZI, FNU, IPMTR, TOL, PHIR, PHII, ARGR, ARGI,

internal compiler error: Illegal instruction
0xa64def crash_signal
../../gcc/toplev.c:333
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


- This bug happens whenever -OX, for X>=1 is in effect.

- This returns no errors:

gfortran -fsanitize=undefined -c zunhj.f

- Here is the output of the detailed excerpt:
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix <>/gcc/6.1.0 --with-gmp=<>/gmp/6.1.0
--with-mpfr=<>/mpfr/3.1.4 --with-mpc=<>/mpc/1.0.3 --with-isl=<>/isl/0.16.1
--enable-lto --enable-threads
--enable-stage1-languages=c,c++,fortran,go,objc,obj-c++
--with-multilib-list=m64
Thread model: posix
gcc version 6.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-c' '-mtune=generic'
'-march=x86-64'
 <>/gcc/6.1.0/libexec/gcc/x86_64-pc-linux-gnu/6.1.0/f951 zunhj.f -ffixed-form
-quiet -dumpbase zunhj.f -mtune=generic -march=x86-64 -auxbase zunhj -O1
-version -fintrinsic-modules-path
<>/gcc/6.1.0/lib/gcc/x86_64-pc-linux-gnu/6.1.0/finclude -o zunhj.s
GNU Fortran (GCC) version 6.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 6.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
zunhj.f:1:0:

   SUBROUTINE ZUNHJ(ZR, ZI, FNU, IPMTR, TOL, PHIR, PHII, ARGR, ARGI,

internal compiler error: Illegal instruction
0xa64def crash_signal
../../gcc/toplev.c:333
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


- uname -a returns
Linux <> 2.6.32-573.22.1.el6.x86_64 #1 SMP Tue Mar 22 17:15:28 CDT 2016 x86_64
x86_64 x86_64 GNU/Linux


- As a bonus information. This source code has been in scipy since Aug. 2007
with no change since. It successfully compiles using 5.[1-3].0 and 4.8.3 and
4.9.[1-3] (tested in my build).

[Bug tree-optimization/71084] [7 Regression] ICE in compute_dominance_frontiers_1 (cfganal.c:1302)

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
fwprop_init calcuates dominator info so it's likely df that runs cfg-cleanup
and doesn't expect it to wreck dominator info.

Probably rightfully so.

[Bug fortran/71085] ICE with some intrinsic functions specifying array function result dimension

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-12
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed on trunk.

> ./f951 -quiet t.f90
t.f90:1:0:

 print *, f()

internal compiler error: Segmentation fault
0xf03530 crash_signal
/space/rguenther/src/svn/trunk/gcc/toplev.c:333
0x8cd83c gfc_apply_interface_mapping_to_expr
/space/rguenther/src/svn/trunk/gcc/fortran/trans-expr.c:4255
0x8cd7b6 gfc_apply_interface_mapping_to_expr
/space/rguenther/src/svn/trunk/gcc/fortran/trans-expr.c:4245
0x8cd969 gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*,
gfc_expr*)
/space/rguenther/src/svn/trunk/gcc/fortran/trans-expr.c:4291
0x887f92 gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*,
gfc_array_spec*)
...

[Bug inline-asm/71086] New: miscompiled inline-asm + alternative constraints + __builtin_expect + always_inline

[mirq-gccboogs at rere dot qmqm.pl]

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

Bug ID: 71086
   Summary: miscompiled inline-asm + alternative constraints +
__builtin_expect + always_inline
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mirq-gccboogs at rere dot qmqm.pl
  Target Milestone: ---

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

The attached code get's miscompiled when -DNO_EXPECT is not passed. With
__builtin_expect used, the operand to inline asm in inc_overflow() get's
replaced with uninitialized stack entry. This happens only with exact
combination of: -O1, inline-asm has multiple alternative constraints,
__builtin_expect is used in inc_overflow(), there are other not-optimized-out
variables on stack.

gcc versions 4.9.2 (-10 Debian) and 4.9.3 (-13ubuntu2) miscompile, gcc 5.3.1
generates correct code.

--- good: g++ -O1 -S -DNO_EXCEPT bug_inline.cc -o -
+++ bad:  g++ -O1 -S bug_inline.cc -o -
@@ -5,55 +5,49 @@
 _Z6test_smj:
 .LFB2: 
.cfi_startproc
-   pushq   %rbp
-   .cfi_def_cfa_offset 16
-   .cfi_offset 6, -16
pushq   %rbx
-   .cfi_def_cfa_offset 24
-   .cfi_offset 3, -24
-   subq$40, %rsp
+   .cfi_def_cfa_offset 16
+   .cfi_offset 3, -16
+   subq$48, %rsp
.cfi_def_cfa_offset 64
-   movq%rdi, %rbp
+   movq%rdi, 8(%rsp)
movq%fs:40, %rax
-   movq%rax, 24(%rsp)
+   movq%rax, 40(%rsp)
xorl%eax, %eax
cmpl$10, %esi
jbe .L2
movl%esi, %ebx
-   leaq8(%rsp), %rdi
+   leaq24(%rsp), %rdi
call_Z3xdoRm
-.L5:
-   movq%rbp, %rdi
+.L4:
 #APP
 # 18 "bug_inline.cpp" 1
-   add %rbx, %rdi
+   add %rbx, 32(%rsp)<--- 32(%rsp) is not initialized, but
should be with 'v' (saved at 8(%rsp), or in %rbp in good code)
setc %sil
 # 0 "" 2
 #NO_APP
testb   %sil, %sil
-   movq$-1, %rax
-   cmovne  %rax, %rdi
-   movq%rdi, 16(%rsp)
-   leaq16(%rsp), %rdi
+   je  .L3
+   movq$-1, 32(%rsp)
+.L3:
+   leaq32(%rsp), %rdi
call_Z3xdoRm
-   movq8(%rsp), %rax
-   movq24(%rsp), %rdx
+   movq24(%rsp), %rax
+   movq40(%rsp), %rdx
xorq%fs:40, %rdx
-   je  .L6
-   jmp .L7
+   je  .L5
+   jmp .L6
 .L2:
-   leaq8(%rsp), %rdi
+   leaq24(%rsp), %rdi
call_Z3xdoRm
movl$4294967295, %ebx
-   jmp .L5
-.L7:
-   call__stack_chk_fail
+   jmp .L4
 .L6:
-   addq$40, %rsp
-   .cfi_def_cfa_offset 24
-   popq%rbx
+   call__stack_chk_fail
+.L5:
+   addq$48, %rsp
.cfi_def_cfa_offset 16
-   popq%rbp
+   popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc

# Debian 4.9.2
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.9.real
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='Debian 4.9.2-10'
--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 --with-arch-32=i586 --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 (Debian 4.9.2-10) 

# Ubuntu 4.9.3
$ g++-4.9 -v
Using built-in specs.
COLLECT_GCC=g++-4.9
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.3-13ubuntu2'
--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 

[Bug testsuite/71021] [libatomic testsuite] Test program compilation fail (missing -pthread flag)

[nsz at gcc dot gnu.org]

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

--- Comment #4 from nsz at gcc dot gnu.org ---
this might be a different issue, but then i'm not sure how you made the gcc
build to use the alternate glibc path.

can you attach the libatomic/testsuite/Makefile (with the CC etc variables
set)?

i think the atomic tests should work without -pthread and i think libgomp just
happens to pass because -fopenmp implies -pthread.

[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Patch posted at:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00634.html
and Richards' reply at:
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00388.html

There's more digging to do in how we asses whether a function escapes the
translation unit.

I'm not currently working on this.

[Bug tree-optimization/71084] [7 Regression] ICE in compute_dominance_frontiers_1 (cfganal.c:1302)

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Started with r236114:

commit bfa8ea12839b8c5781aa16733ee3578ff95789ca
Author: ienkovich 
Date:   Wed May 11 09:33:13 2016 +

gcc/

PR middle-end/70807
* cfgrtl.h (delete_insn_and_edges): Now return bool.
* cfgrtl.c (delete_insn_and_edges): Likewise.
* config/i386/i386.c (convert_scalars_to_vector): Remove
redundant code.
* cse.c (cse_insn): Compute cse_cfg_altered.
(delete_trivially_dead_insns): Likewise.
(cse_cc_succs): Likewise.
(rest_of_handle_cse): Free dominance info if required.
(rest_of_handle_cse2): Likewise.
(rest_of_handle_cse_after_global_opts): Likewise.

gcc/testsuite/

PR middle-end/70807
* gcc.dg/pr70807.c: New test.

[Bug tree-optimization/71006] [6/7 Regression] ICE: verify_gimple failed (error: type mismatch in conditional expression) w/ -O1 -ftree-loop-vectorize

[chengniansun at gmail dot com]

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

--- Comment #6 from Chengnian Sun  ---
(In reply to Ilya Enkovich from comment #4)
> (In reply to Chengnian Sun from comment #3)
> > Hi, 
> > 
> > Can you help check whether the following test case is a duplicate? Thanks. 
> 
> This is definitely a separate issue.

Thank you. It has been reported at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71079.

[Bug tree-optimization/71084] [7 Regression] ICE in compute_dominance_frontiers_1 (cfganal.c:1302)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug tree-optimization/71084] [7 Regression] ICE in compute_dominance_frontiers_1 (cfganal.c:1302)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/71006] [6/7 Regression] ICE: verify_gimple failed (error: type mismatch in conditional expression) w/ -O1 -ftree-loop-vectorize

[ienkovich at gcc dot gnu.org]

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

--- Comment #5 from Ilya Enkovich  ---
Author: ienkovich
Date: Thu May 12 11:27:49 2016
New Revision: 236171

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

PR tree-optimization/71006
* tree-vect-loop.c (vect_determine_vectorization_factor): Don't
consider COND_EXPR as a mask producer.

gcc/testsuite/

PR tree-optimization/71006
* gcc.dg/pr71006.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr71006.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug fortran/71085] New: ICE with some intrinsic functions specifying array function result dimension

[vladimir.fuka at gmail dot com]

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

Bug ID: 71085
   Summary: ICE with some intrinsic functions specifying array
function result dimension
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.fuka at gmail dot com
  Target Milestone: ---

print *, f()

contains

  function f()
integer :: f(iargc()*10)
  end

end


ICE's with gcc version 5.3.1 20160412


   print *, f()
 1
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Also ICE's with nint(rand()), irand(), nint(second()).

It does not crash with itime() and nint(secnd()).

[Bug tree-optimization/71084] New: [7 Regression] ICE in compute_dominance_frontiers_1 (cfganal.c:1302)

[marxin at gcc dot gnu.org]

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

Bug ID: 71084
   Summary: [7 Regression] ICE in compute_dominance_frontiers_1
(cfganal.c:1302)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Hi.

Current trunk produces ICE for the following code snippet:

enum {
  GIMP_RGB_IMAGE,
  GIMP_RGBA_IMAGE,
  GIMP_GRAY_IMAGE,
  GIMP_GRAYA_IMAGE,
  GIMP_INDEXED_IMAGE
} run_i;
run_height;
fn1() {
  int type, width;
  if (_setjmp())
switch (type) {
case GIMP_RGB_IMAGE:
  babl_format();
case GIMP_RGBA_IMAGE:
case GIMP_GRAY_IMAGE:
  babl_format();
case GIMP_GRAYA_IMAGE:
case GIMP_INDEXED_IMAGE:
  gimp_drawable_get_format();
}
  for (; run_height;)
for (; run_i < fn1; ++run_i)
  for (; width;)
;
}

$ gcc tc.i -O2 -c

tc.i:26:1: internal compiler error: Segmentation fault
 }
 ^
0xa41fcf crash_signal
../../gcc/toplev.c:333
0x6fecf5 compute_dominance_frontiers_1
../../gcc/cfganal.c:1302
0x6fecf5 compute_dominance_frontiers(bitmap_head*)
../../gcc/cfganal.c:1319
0x75b47d df_md_local_compute
../../gcc/df-problems.c:4543
0x753ca1 df_analyze_problem(dataflow*, bitmap_head*, int*, int)
../../gcc/df-core.c:1174
0x753dcc df_analyze_1
../../gcc/df-core.c:1229
0xf9d2f4 build_single_def_use_links
../../gcc/fwprop.c:283
0xf9d2f4 fwprop_init
../../gcc/fwprop.c:1423
0xf9d835 fwprop_addr
../../gcc/fwprop.c:1529
0xf9d835 execute
../../gcc/fwprop.c:1572

Thanks,
Martin

[Bug c/70756] Wrong column number shown for "error: invalid use of flexible array member"

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Patch: .

[Bug c/49859] gcc could warn about statements between "switch" and first "case"

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
C FE patch: .

[Bug tree-optimization/71083] [4.9/5/6 Regression] Unaligned bit-field address when predictive commoning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.7.4
   Target Milestone|--- |4.9.4
Summary|Unaligned bit-field address |[4.9/5/6 Regression]
   |when predictive commoning   |Unaligned bit-field address
   ||when predictive commoning
  Known to fail||4.8.5

--- Comment #3 from Richard Biener  ---
Broken since GCC 4.8, GCC 4.7 doesn't apply predictive commoning here.

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |7.0

--- Comment #43 from Marek Polacek  ---
I'll be experimenting with this.

[Bug tree-optimization/71083] Unaligned bit-field address when predictive commoning

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Conservative patch:

Index: gcc/tree-predcom.c
===
--- gcc/tree-predcom.c  (revision 236159)
+++ gcc/tree-predcom.c  (working copy)
@@ -1391,9 +1395,10 @@ ref_at_iteration (data_reference_p dr, i
   && DECL_BIT_FIELD (TREE_OPERAND (DR_REF (dr), 1)))
 {
   tree field = TREE_OPERAND (DR_REF (dr), 1);
+  tree type = build_aligned_type (DECL_BIT_FIELD_TYPE (field),
+ BITS_PER_UNIT);
   return build3 (BIT_FIELD_REF, TREE_TYPE (DR_REF (dr)),
-build2 (MEM_REF, DECL_BIT_FIELD_TYPE (field),
-addr, alias_ptr),
+build2 (MEM_REF, type, addr, alias_ptr),
 DECL_SIZE (field), bitsize_zero_node);
 }
   else


better for archs where unaligned matters for code-gen would be to
base the ref off DECL_BIT_FIELD_REPRESENTATIVE (though that doesn't
seem to have meaningful alignment either in this case).

[Bug driver/71063] ICE: Segmentation fault with --help="^"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug driver/71063] ICE: Segmentation fault with --help="^"

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Thu May 12 10:59:11 2016
New Revision: 236170

URL: https://gcc.gnu.org/viewcvs?rev=236170=gcc=rev
Log:
PR driver/71063
* opts.c (common_handle_option): Detect missing argument for --help^.

* gcc.dg/opts-7.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/opts-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/opts.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71083] Unaligned bit-field address when predictive commoning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-12
  Component|c   |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed also on x86_64 (where it is harmless of course):

;; _19 = BIT_FIELD_REF ;

(insn 10 9 11 (set (reg:DI 99)
(zero_extend:DI (mem:QI (plus:DI (reg/v/f:DI 98 [ chain ])
(const_int 1 [0x1])) [1 MEM[(struct lock_chain
*)chain_11(D) + 1B]+0 S1 A32]))) -1
 (nil))