[Bug debug/68904] DWARF for class ios_base says it's a declaration

[chihin.ko at oracle dot com]

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

--- Comment #4 from chihin ko  ---
(In reply to Andrew Pinski from comment #1)
> Can you try:
> -fno-eliminate-unused-debug-types
> 
> I bet the full type debug info is going to be emitted in a different TU
> which is why GCC is not emitting it here.
> 
> 
> Also look at the debug info inside libstdc++.so/libstdc++.a to see if the
> full debug info is emitted there.

The problem is for class "ios_base", the attribute 
DW_AT_declaration   yes(1)
should not be there, because the full definition of the class is here:

< 2><0xb0f9>  DW_TAG_class_type
DW_AT_name "ios_base"
DW_AT_declaration  yes(1)  <=== should not have
this
DW_AT_sibling  <0xb4ab>
< 3><0xb103>DW_TAG_enumeration_type
  DW_AT_name "event"
  DW_AT_byte_size0x0004
  DW_AT_decl_file0x0025
/pkg/gnu/include/c++/4.9.3/bits/ios_base
.h
  DW_AT_decl_line0x01a3
  DW_AT_sibling  <0xb123>
< 4><0xb110>  DW_TAG_enumerator
DW_AT_name "erase_event"
DW_AT_const_value  0x

[Bug c++/68905] New: __is_trivially_copyable returns True for volatile class types.

[eric at efcs dot ca]

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

Bug ID: 68905
   Summary: __is_trivially_copyable returns True for volatile
class types.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

Created attachment 37034
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37034=edit
reproducer.cpp

The __is_trivially_copyable builtin returns true for volatile qualified
trivially copyable class types. However the current C++ draft says:

3.9[basic.types] p9 says:
> Cv-unqualified scalar types, trivially copyable class types (Clause 9),
> arrays of such types, and non-volatile const-qualified versions of these 
> types (3.9.3) are collectively called trivially copyable types.

I believe it should return false for any volatile qualified type.

[Bug inline-asm/59155] ICE: in reg_overlap_mentioned_p, at rtlanal.c:1473

[bernd.edlinger at hotmail dot de]

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

--- Comment #5 from Bernd Edlinger  ---
Oh no! The X constraint allows just everything.

and combine combines everything that is OK for
check_asm_operands.  But reg_overlap_mentioned_p
is not expecting anything that complicated.

How about:

Index: common.md
===
--- common.md   (revision 231598)
+++ common.md   (working copy)
@@ -92,4 +92,5 @@

 (define_constraint "X"
   "Matches anything."
-  (match_test "true"))
+  (match_test "CONSTANT_P (op) || MEM_P (op) ||
+  REG_P (op) || SUBREG_P (op) || GET_CODE (op) == SCRATCH"))


This should be safe.

[Bug c/68906] New: ICE at -O3 on x86_64-linux-gnu: verify_ssa failed

[chengniansun at gmail dot com]

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

Bug ID: 68906
   Summary: ICE at -O3 on x86_64-linux-gnu: verify_ssa failed
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes. 


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

$: 
$: gcc-trunk -c -g -O3 -m32 small.c 
small.c: In function ‘fn1’:
small.c:4:5: error: definition in block 6 does not dominate use in block 7
 int fn1() {
 ^~~

for SSA_NAME: e_14 in statement:
# DEBUG f => e_14
small.c:4:5: internal compiler error: verify_ssa failed
0xce6fe2 verify_ssa(bool, bool)
../../gcc-trunk/gcc/tree-ssa.c:1039
0xa1f9dd execute_function_todo
../../gcc-trunk/gcc/passes.c:1965
0xa2027b execute_todo
../../gcc-trunk/gcc/passes.c:2010
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$: 
$: gcc-trunk -c -g -O3 -m64 small.c 
small.c: In function ‘fn1’:
small.c:4:5: error: definition in block 6 does not dominate use in block 7
 int fn1() {
 ^~~

for SSA_NAME: e_14 in statement:
# DEBUG f => e_14
small.c:4:5: internal compiler error: verify_ssa failed
0xce6fe2 verify_ssa(bool, bool)
../../gcc-trunk/gcc/tree-ssa.c:1039
0xa1f9dd execute_function_todo
../../gcc-trunk/gcc/passes.c:1965
0xa2027b execute_todo
../../gcc-trunk/gcc/passes.c:2010
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$: 
$:
$: cat small.c
int a;
volatile int b;
short c, d;
int fn1() {
  int e;
  for (;;) {
a = 3;
if (c)
  continue;
e = 0;
for (; e > -30; e--)
  if (b) {
int f = e;
return d;
  }
  }
}

[Bug c/68868] atomic_init emits an unnecessary fence

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
On Sat, 12 Dec 2015, msebor at gcc dot gnu.org wrote:

> +  __typeof__ (VALUE) __tmp = (VALUE); \

Using typeof like this is incorrect; it results in multiple evaluation if 
VALUE has a variably modified type.  You have to use __auto_type in such a 
case, as elsewhere in stdatomic.h.

[Bug c/68868] atomic_init emits an unnecessary fence

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
A working patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01449.html

[Bug testsuite/68629] FAIL: c-c++-common/attr-simd-3.c

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from Thomas Preud'homme  ---
Hi Christophe,

Could you paste the output of arm linux when compiling the testcase in cilkplus
effective target with -fcilkplus?

[Bug rtl-optimization/66248] subreg truncation not hoisted from loop

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

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

--- Comment #1 from Steve Ellcey  ---
The truncate can not be moved out of the loop because that would affect the
overflow behaviour of ret.  I.e. we need to truncate ret on each iteration of
the loop because doing the truncation may affect the value of ret used in the
addition during the next iteration of the loop.  This is not the same as
doing one truncation at the end in cases where ret overflows the maximum value
of a short type.

[Bug middle-end/68870] [6 Regression] ICE on valid code at -O1, -O2 and -O3 on x86_64-linux-gnu

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  ---
I'd say that changing genmatch (or any code) to know about the freelist is a
horrid hack and just papering over the problem.

I haven't put this case under a debugger, but presumably we've got a reference
to a released SSA_NAME in the IL, right?  Presumably in some code that isn't
trivially proved unreachable?

[Bug c++/68890] New: [5.3 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2113

[ostash at ostash dot kiev.ua]

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

Bug ID: 68890
   Summary: [5.3 Regression] ICE in verify_ctor_sanity, at
cp/constexpr.c:2113
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ostash at ostash dot kiev.ua
  Target Milestone: ---

Following minimal case:

#include 

template 
class FixedVector : protected std::array
{
public:
  typedef typename std::array base;
  typedef uint8_t internal_size_type;

  constexpr FixedVector()
  : base()
  , size_(0u)
  {}

private:
  internal_size_type size_;
};

template 
class ptr
{
public:
  typedef T element_type;
  constexpr ptr(T* p = nullptr) noexcept : px_(p) {}

private:
  T* px_;
};

class ForwardDeclaredClass;

void func()
{
  FixedVector var;
}


gives me:

constexpr-ICE.cpp: In function 'void func()':
constexpr-ICE.cpp:34:45:   in constexpr expansion of 'var.FixedVector::FixedVector()'
constexpr-ICE.cpp:12:13:   in constexpr expansion of
'((FixedVector*)this)->FixedVector::.std::array::array()'
constexpr-ICE.cpp:34:45: internal compiler error: in verify_ctor_sanity, at
cp/constexpr.c:2113
   FixedVector var;
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

on GCC 5.3.0 release:

Using built-in specs.
COLLECT_GCC=bin/g++
COLLECT_LTO_WRAPPER=/login/sg220044/53/bin/../libexec/gcc/x86_64-pc-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-5.3.0/configure --enable-bootstrap
--enable-checking=release --enable-clocale=gnu --enable-__cxa_atexit
--disable-fixed-point --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-initfini-array --enable-languages=c,c++ --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch --enable-libstdcxx-time
--enable-libstdcxx-threads --disable-libquadmath --disable-libquadmath-support
--enable-linux-futex --enable-lto --disable-multiarch --disable-multilib
--disable-nls --enable-plugin --enable-secureplt --disable-sjlj-exceptions
--enable-threads=posix --enable-tls --enable-vtable-verify --disable-werror
--with-build-config=bootstrap-lto --with-default-libstdcxx-abi=gcc4-compatible
--with-diagnostics-color=auto --with-gnu-as --with-gnu-ld
--with-linker-hash-style=gnu --with-system-zlib --host=x86_64-pc-linux-gnu
--build=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--prefix=/atse_git/ostash/tc5
Thread model: posix
gcc version 5.3.0 (GCC)


Same code compiles silently with July snapshot:

Using built-in specs.
COLLECT_GCC=/login/sg220044/storage/tc5/bin/g++
COLLECT_LTO_WRAPPER=/atse_git/ostash/tc5/libexec/gcc/x86_64-pc-linux-gnu/5.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-5-20150728/configure --enable-bootstrap
--enable-checking=release --enable-clocale=gnu --enable-__cxa_atexit
--disable-fixed-point --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-initfini-array --enable-languages=c,c++ --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch --enable-libstdcxx-time
--enable-libstdcxx-threads --disable-libquadmath --disable-libquadmath-support
--enable-linux-futex --enable-lto --disable-multiarch --disable-multilib
--disable-nls --enable-plugin --enable-secureplt --disable-sjlj-exceptions
--enable-threads=posix --enable-tls --enable-vtable-verify --disable-werror
--with-build-config=bootstrap-lto --with-default-libstdcxx-abi=gcc4-compatible
--with-diagnostics-color=auto --with-gnu-as --with-gnu-ld
--with-linker-hash-style=gnu --with-system-zlib --host=x86_64-pc-linux-gnu
--build=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--prefix=/atse_git/ostash/tc5
Thread model: posix
gcc version 5.2.1 20150728 (GCC)

[Bug tree-optimization/68417] [6 Regression] Missed vectorization opportunity when setting struct field

[afomin.mailbox at gmail dot com]

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

Alexander Fomin  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #8 from Alexander Fomin  ---
Thanks!

[Bug ipa/68857] [6 regression] FAIL: gcc.target/i386/mpx/vararg-8-nov.c -O3 -g (internal compiler error)

[ienkovich at gcc dot gnu.org]

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

--- Comment #2 from Ilya Enkovich  ---
Here is a smaller reproducer:

__builtin_va_list a;
void foo (int *p1, ...)
{
  __builtin_va_start(a, p1);
}
void test() { foo(0); }

[Bug tree-optimization/68775] [6 Regression] spec2006 test case 465.tonto fails with the gcc 6.0 fortran compiler

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Ok, it became latent only.  Testing the following fix:

Index: gcc/tree-vect-slp.c
===
--- gcc/tree-vect-slp.c (revision 230855)
+++ gcc/tree-vect-slp.c (working copy)
@@ -1078,6 +1078,20 @@ vect_build_slp_tree (vec_info *vinfo,
   tem, npermutes, _tree_size,
   max_tree_size))
{
+ /* ... so if successful we can apply the operand swapping
+to the GIMPLE IL.  This is necessary because for example
+vect_get_slp_defs uses operand indexes and thus expects
+canonical operand order.  This is also necessary even
+if we end up building the operand from scalars as
+we'll continue to process swapped operand two.  */
+ for (j = 0; j < group_size; ++j)
+   if (!matches[j])
+ {
+   gimple *stmt = SLP_TREE_SCALAR_STMTS (*node)[j];
+   swap_ssa_operands (stmt, gimple_assign_rhs1_ptr (stmt),
+  gimple_assign_rhs2_ptr (stmt));
+ }
+
  /* If we have all children of child built up from scalars then
 just throw that away and build it up this node from scalars. 
*/
  if (!SLP_TREE_CHILDREN (child).is_empty ())
@@ -1107,17 +1121,6 @@ vect_build_slp_tree (vec_info *vinfo,
}
}

- /* ... so if successful we can apply the operand swapping
-to the GIMPLE IL.  This is necessary because for example
-vect_get_slp_defs uses operand indexes and thus expects
-canonical operand order.  */
- for (j = 0; j < group_size; ++j)
-   if (!matches[j])
- {
-   gimple *stmt = SLP_TREE_SCALAR_STMTS (*node)[j];
-   swap_ssa_operands (stmt, gimple_assign_rhs1_ptr (stmt),
-  gimple_assign_rhs2_ptr (stmt));
- }
  oprnd_info->def_stmts = vNULL;
  SLP_TREE_CHILDREN (*node).quick_push (child);
  continue;

[Bug c++/68891] New: must use a typedef to declare a conversion to 'double (&)[3]'

[mathieu.malaterre at gmail dot com]

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

Bug ID: 68891
   Summary: must use a typedef to declare a conversion to 'double
(&)[3]'
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mathieu.malaterre at gmail dot com
  Target Milestone: ---

Per my understanding of C++ standard section §12.3.2, the following piece of
code should not compile:

$ cat c.cxx
#include 
struct V
{
  ( double ())[3] {
return v;
  }
  double v[3];
};

static void Print( const double ()[3] )
{
  std::cout << a[0] << "," << a[1] << "," << a[2] << std::endl;
}

int main()
{
  V v = {0,1,2};
  Print( v );
  return 0;
}

Seems to be valid c++ for gcc 5.2.1:

$ g++ -Wall -W -pedantic c.cxx && ./a.out 
0,1,2

The only accepted syntax should be using a `typedef` keyword:

  typedef double (_ref)[3];
  operator array_ref () { return v; }

[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|UNRESOLVED/FAIL:|[6 Regression]
   |gcc.dg/lto/attr-weakref-1   |UNRESOLVED/FAIL:
   |-O2 -flto   |gcc.dg/lto/attr-weakref-1
   ||-O2 -flto

[Bug target/68841] [6 Regression] gcc.c-torture/execute/pr59358.c FAILs with custom compiler flags

[ktkachov at gcc dot gnu.org]

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
I suspect that more aggressive if-conversion is exposing a bug in another RTL
pass. If-conversion creates:
(insn 22 21 73 7 (set (reg:CCGC 17 flags)
(compare:CCGC (reg/v:SI 88 [ i ])
(const_int 3 [0x3]))) file.c:19 7 {*cmpsi_1}
 (nil))
(insn 73 22 74 7 (parallel [
(set (reg:SI 94)
(ashift:SI (reg/v:SI 88 [ i ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) zdenek.c:20 525 {*ashlsi3_1}
 (nil))
(insn 74 73 75 7 (set (reg/v:SI 93 [ k ])
(eq:SI (reg:CCGC 17 flags)
(const_int 0 [0]))) file.c:20 626 {*setcc_si_1_movzbl}
 (nil))
(insn 75 74 76 7 (set (reg:SI 95)
(plus:SI (ashift:SI (reg/v:SI 93 [ k ])
(const_int 2 [0x2]))
(const_int 8 [0x8]))) file.c:20 212 {*leasi}
 (nil))
(insn 76 75 77 7 (set (reg:CCGC 17 flags)
(compare:CCGC (reg/v:SI 88 [ i ])
(const_int 4 [0x4]))) file.c:20 7 {*cmpsi_1}
 (nil))
(insn 77 76 33 7 (set (reg/v:SI 87 [ k ])
(if_then_else:SI (lt (reg:CCGC 17 flags)
(const_int 0 [0]))
(reg:SI 95)
(reg:SI 94))) file.c:20 966 {*movsicc_noc}
 (nil))

but during lr_shrinkage the first compare in insn 22 is deemed dead code and
eliminated:
(insn 73 21 74 7 (parallel [
(set (reg:SI 94)
(ashift:SI (reg/v:SI 88 [ i ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) file.c:20 525 {*ashlsi3_1}
 (nil))
(insn 74 73 75 7 (set (reg/v:SI 93 [ k ])
(eq:SI (reg:CCGC 17 flags)
(const_int 0 [0]))) file.c:20 626 {*setcc_si_1_movzbl}
 (expr_list:REG_DEAD (reg:CCGC 17 flags)
(nil)))
(insn 75 74 76 7 (set (reg:SI 95)
(plus:SI (ashift:SI (reg/v:SI 93 [ k ])
(const_int 2 [0x2]))
(const_int 8 [0x8]))) file.c:20 212 {*leasi}
 (expr_list:REG_DEAD (reg/v:SI 93 [ k ])
(nil)))
(insn 76 75 77 7 (set (reg:CCGC 17 flags)
(compare:CCGC (reg/v:SI 88 [ i ])
(const_int 4 [0x4]))) zdenek.c:20 7 {*cmpsi_1}
 (nil))
(insn 77 76 33 7 (set (reg/v:SI 87 [ k ])
(if_then_else:SI (lt (reg:CCGC 17 flags)
(const_int 0 [0]))
(reg:SI 95)
(reg:SI 94))) file.c:20 966 {*movsicc_noc}
 (expr_list:REG_DEAD (reg:SI 95)
(expr_list:REG_DEAD (reg:SI 94)
(expr_list:REG_DEAD (reg:CCGC 17 flags)
(nil)

However, the result of the comparison had a use in insn 74.
I'll dig deeper, but I'm not very familiar with that part of the code, so any
insight would be appreciated.

[Bug libstdc++/68880] [4.9 Regression][Bisected to r202992] std::operator< overload ignored when using std::lower_bound

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
For future reference, [4.9 Regression] means a regression in gcc 4.9 compared
to previous versions. What you meant is [5/6 Regression], and you should have
put 4.9.4 (or another version) in the "Known to work" field.

It doesn't matter here though, because as stated above this is undefined
behaviour not a regression (IMHO refusing to compile this code is a nice side
effect of François's change).

[Bug c++/68890] [5/6 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2113

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with:

commit 6cded08567ecae0ecce4a85500df28b06eca1102
Author: jason 
Date:   Fri Oct 23 20:57:05 2015 +

PR c++/67813
* constexpr.c (cxx_eval_store_expression): Always use *valp if
set.

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

[Bug ipa/68857] [6 regression] FAIL: gcc.target/i386/mpx/vararg-8-nov.c -O3 -g (internal compiler error)

[ienkovich at gcc dot gnu.org]

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

--- Comment #3 from Ilya Enkovich  ---
IPA CP redirects edges for all callers including instrumentation thunks. 
Instrumentation thunks are always supposed to call their original nodes and
therefore should be skipped.

[Bug target/68885] [6 Regression] FAIL: gcc.target/i386/mpx/memmove-1.c -O3 -g (internal compiler error)

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #1 from Ilya Enkovich  ---
There are several MPX tests failing with the same error.

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

[Bug ipa/68857] [6 regression] FAIL: gcc.target/i386/mpx/vararg-8-nov.c -O3 -g (internal compiler error)

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #1 from Ilya Enkovich  ---
*** Bug 68885 has been marked as a duplicate of this bug. ***

[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Markus Trippelsdorf  ---
Fortunately I cannot reproduce the issue anymore.
Closing.

[Bug fortran/68887] [6 regression] gfortran.dg/coarray/event_[12].f90 -fcoarray=lib -O2 -lcaf_single -latomic fails

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-14
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
On x86_64-apple-darwin15 valgrind complains as in comment 0 for
gfortran.dg/coarray/event_1.f90, but for the reduced test I only get

==73989== Conditional jump or move depends on uninitialised value(s)
==73989==at 0x1125A: MAIN__ (in ./a.out)
==73989==by 0x133AB: main (in ./a.out)

[Bug libstdc++/68880] [4.9 Regression][Bisected to r202992] std::operator< overload ignored when using std::lower_bound

[david.ward at ll dot mit.edu]

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

--- Comment #5 from David Ward  ---
Jonathan, the behavior changed between 4.8 and 4.9. Testing with the 4.9
release showed the new behavior as well. I showed the output from the latest
release to demonstrate that the behavior still exists and hadn't changed back
since 4.9 (and also checked this with SVN trunk).

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

--- Comment #32 from Joshua Kinard  ---
(In reply to Richard Biener from comment #30)
> Any status update?  Does bootstrap work on trunk (with --disable-checking)?

Okay, here's updates from the MIPS angle on a few configurations:

MIPS-IV, Big-endian, N32, glibc (mips64-unknown-linux-gnu):
Still fails with either --disable-checking or --enable-checking=release.  Same
problem as before:

build/genmatch --gimple
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/match.pd \
> tmp-gimple-match.c
/bin/bash: line 1: 16563 Segmentation fault  build/genmatch --gimple
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/match.pd >
tmp-gimple-match.c
Makefile:2325: recipe for target 's-match' failed
make[3]: *** [s-match] Error 139
make[3]: *** Waiting for unfinished jobs

Can't test O32/glibc at present due to accidentally mangling my old O32 rootfs.
 Might get something up and working again at some point, but I *highly* suspect
the problem only exists in N32 (unknown about N64).  See below for why.

---

MIPS-IV, Big-endian, O32, uclibc (mips-unknown-linux-uclibc):
--disable-checking appears to produce an ICE in an O32/uclibc rootfs.  I assume
you'll want a fresh bug opened on this:
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/../libcpp/include  \
-o build/genoutput.o
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/genoutput.c
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/genautomata.c: In
function 'void form_regexp(regexp_t)':
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/genautomata.c:6867:1:
internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2318
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Makefile:2451: recipe for target 'build/genautomata.o' failed
make[3]: *** [build/genautomata.o] Error 1
make[3]: *** Waiting for unfinished jobs

I'll have to re-create the above scenario to do so, as I'm running a few
different experiments w/ uclibc at the moment, so I need to make sure it really
is --disable-checking causing the problem there and I'll run the bug through
our (Gentoo's) toolchain team first before opening a PR here.

---

Now, same O32/uclibc rootfs, --enable-checking=release, gcc-5.3.0 works fine
(so far).  This is why I suspect the N32 case is broken only.  I don't know how
good N32 support in uclibc is, so I can't test that configuration to verify.

So to tackle the N32 issue, are there any additional tricks you want me to try
to get, say, a static copy of genmatch built w/ debugging symbols and then step
through it in GDB to see what may be triggering the segfault?  I didn't try
removing the 'gcc_checking_assert', as suggested in earlier comments.

N32 does affect the reported size of several datatypes, so that may be the
source of the issue on MIPS.

[Bug c/68187] Poor error message from -Wmisleading-indentation on glibc's ../stdlib/strtol_l.c

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #1 from Bernd Edlinger  ---
Hi, I have another similar misleading warning in openssl-1.0.1p:


HREADS -D_REENTRANT -O3 -fomit-frame-pointer -Wall   -c -o eng_lib.o eng_lib.c
eng_lib.c: In Funktion »engine_free_util«:
eng_lib.c:120:9: Warnung: statement is indented as if it were guarded by...
[-Wmisleading-indentation]
 if (i > 0)
 ^~

eng_lib.c:117:5: Anmerkung: ...this »else« clause, but it is not
 else
 ^~~~


in crypto/engine/eng_lib.c:

int engine_free_util(ENGINE *e, int locked)
{
int i;

if (e == NULL) {
ENGINEerr(ENGINE_F_ENGINE_FREE_UTIL, ERR_R_PASSED_NULL_PARAMETER);
return 0;
}
if (locked)
i = CRYPTO_add(>struct_ref, -1, CRYPTO_LOCK_ENGINE);
else
i = --e->struct_ref;
engine_ref_debug(e, 0, -1)
if (i > 0)
return 1;
#ifdef REF_CHECK
if (i < 0) {
fprintf(stderr, "ENGINE_free, bad structural reference count\n");
abort();
}

[Bug ipa/68857] [6 regression] FAIL: gcc.target/i386/mpx/vararg-8-nov.c -O3 -g (internal compiler error)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/68890] [5/6 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2113

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug c/68833] [6 Regression] -Werror=format issues an error now

[sirl at gcc dot gnu.org]

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

--- Comment #4 from Franz Sirl  ---
The fix in Comment 3 works fine for me. No testsuite regressions and also the
application where I spotted this compiles/warns as expected now.

[Bug fortran/68893] New: [Coarray] Wrong result with -fcoarray=single and EVENTS

[burnus at gcc dot gnu.org]

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

Bug ID: 68893
   Summary: [Coarray] Wrong result with -fcoarray=single and
EVENTS
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

The following program prints (with -fcoarray=single) "Value has been set", but
it should not print anything as the event variable has not been set.

It works with -fcoarray=lib.


program atomic
  use iso_fortran_env
  implicit none
  type(event_type) :: event_value_has_been_set[*]
  integer :: cnt
  if (this_image() == 1) then
call event_query (event_value_has_been_set, cnt)
if (cnt > 0) write(*,*) "Value has been set"
  elseif (this_image() == 2) then
event post (event_value_has_been_set[1])
  end if
end program atomic

[Bug tree-optimization/68894] New: Recognition min/max pattern with multiple arguments.

[ysrumyan at gmail dot com]

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

Bug ID: 68894
   Summary: Recognition min/max pattern with multiple arguments.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com
  Target Milestone: ---

Analyzing one important benchmark (rgb to cmyk conversion) we found out that
MIN pattern is not recognized for more than 2 arguments. I attached simple
reproducer which exhibit the issue - explicit use of multiple 

[Bug fortran/68889] New: Fortran/DWARF: Possible bug in the handling of DW_AT_associated

[burnus at gcc dot gnu.org]

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

Bug ID: 68889
   Summary: Fortran/DWARF: Possible bug in the handling of
DW_AT_associated
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

See description at https://sourceware.org/ml/gdb-patches/2015-12/msg00245.html

Possibly related: PR 59438

Quote from that email (Andrew Burgess, [PATCH 0/2] Problems with
gdb.mi/mi-vla-fortran.exp):


In the test we have gdb stop at vla.f90:35, which looks like this:

pvla2 => vla2   ! pvla2-not-associated

Before this point, the pvla2 pointer variable is not associated, and
so, something like:

l = associated(pvla2)

Would return false.  In order to determine if pvla2 is associated gdb
makes use of the DWARF DW_AT_associated property which is an attribute
of the DWARF type corresponding to pvla2.

The DW_AT_associated property for the type of pvla2 is this (newlines
added by me for clarity):

DW_AT_associated  : 4 byte block: 97 6 30 2e\
(DW_OP_push_object_address; \
 DW_OP_deref; DW_OP_lit0; \
 DW_OP_ne)

So, take the address of the object (in this case the address is on the
stack), and use that to load an address sized block from memory, and
if that loaded block is not zero, then the the variable (pvla2) is
associated.

The problem is that gfortran does not initialise the block of memory
that the object address points to until the first time that pvla2 is
accessed.  Before that time the contents of the memory are undefined,
and if gdb accesses them we will see undefined behaviour.

I've confirmed that above behaviour by using the '-fdump-tree-all'
option to gfortran, then examining the pseudo-C code that is dumped.

>From a compiler / code correctness point of view this behaviour is
perfectly understandable, and for performance, this is probably a win,
the problem (as I see it) is that a promise has been made in the
DWARF, which is not being honoured in the code.  I think gfortran
either needs more complex DWARF, or to initialise the memory block for
associatable variables earlier on.

Given the above mistake, what follows is just undefined behaviour
kicking in; gdb reads the uninitialised memory, which happens to be
non-zero, so it believes pvla2 is associated, it then tries to figure
out what it's associated with, and reads yet more uninitialised memory.

[Bug ipa/66616] [4.9/5/6 regression] fipa-cp-clone ignores thunk

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  ---
Author: jamborm
Date: Mon Dec 14 09:33:12 2015
New Revision: 231607

URL: https://gcc.gnu.org/viewcvs?rev=231607=gcc=rev
Log:
[PR 66616] Check for thunks when adding extra constants to clones

2015-12-14  Martin Jambor  

PR ipa/66616
* ipa-cp.c (propagate_constants_accross_call): Move thuk check...
(call_passes_through_thunk_p): ...here.
(find_more_scalar_values_for_callers_subset): Perform thunk checks
like propagate_constants_accross_call does.

testsuite/
* g++.dg/ipa/pr66616.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr66616.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/68878] [6 Regression] 471.omnetpp in SPEC CPU 2006 is miscompiled with LTO

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug tree-optimization/68866] [4.9 Regression] ICE in set_lattice_value, at tree-ssa-cpp.c:490

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug tree-optimization/68862] [6 Regression] g++.dg/torture/pr59163.C FAILs with -flive-range-shrinkage

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug tree-optimization/68861] [6 regression] FAIL: libgomp.fortran/vla8.f90 -O3 -g execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug tree-optimization/68866] [4.9 Regression] ICE in set_lattice_value, at tree-ssa-cpp.c:490

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-14
  Component|c   |tree-optimization
  Known to work||4.3.6, 5.1.0
   Target Milestone|--- |4.9.4
Summary|ICE in set_lattice_value,   |[4.9 Regression] ICE in
   |at tree-ssa-cpp.c:490   |set_lattice_value, at
   ||tree-ssa-cpp.c:490
 Ever confirmed|0   |1
  Known to fail||4.6.4, 4.7.3, 4.8.5, 4.9.3

--- Comment #1 from Richard Biener  ---
Confirmed, fixed in GCC 5.

[Bug debug/68860] [6 regression] FAIL: gcc.dg/guality/pr36728-1.c -O3 -g line 16 arg1 == 1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/68841] [6 Regression] gcc.c-torture/execute/pr59358.c FAILs with custom compiler flags

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
The testcase built with -fno-live-range-shrinkage works ok.

[Bug tree-optimization/68892] [6 Regression] Excessive dead loads produced by BB vectorization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-14
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

[Bug tree-optimization/68892] New: [6 Regression] Excessive dead loads produced by BB vectorization

[rguenth at gcc dot gnu.org]

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

Bug ID: 68892
   Summary: [6 Regression] Excessive dead loads produced by BB
vectorization
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

double a[1024][1024];
double b[1024];

void foo(void)
{
  b[0] = a[0][0];
  b[1] = a[1][0];
  b[2] = a[2][0];
  b[3] = a[3][0];
}

is vectorized using

t.c:10:1: note: Load permutation 0 1024 2048 3072
t.c:10:1: note: Final SLP tree for instance:
t.c:10:1: note: node
t.c:10:1: note: stmt 0 b[0] = _2;
t.c:10:1: note: stmt 1 b[1] = _4;
t.c:10:1: note: stmt 2 b[2] = _6;
t.c:10:1: note: stmt 3 b[3] = _8;
t.c:10:1: note: node
t.c:10:1: note: stmt 0 _2 = a[0][0];
t.c:10:1: note: stmt 1 _4 = a[1][0];
t.c:10:1: note: stmt 2 _6 = a[2][0];
t.c:10:1: note: stmt 3 _8 = a[3][0];

where our "stupid" load permutation support first loads all vectors of
the group (of size 3073) and then permutes it, using only 4 vectors of it.
For vectors with more than two elements the "need more than two vectors"
part of load permutation support "fixes" this but for two elements nothing
prevents this stupidity (it's all dead code but IVOPTs for example can take
ages processing the dead loads)

  :
  _2 = a[0][0];
  _4 = a[1][0];
  _6 = a[2][0];
  vect__2.5_10 = MEM[(double *)];
  _11 = [0][0] + 16;
  vect__2.6_12 = MEM[(double *)_11];
  _13 = _11 + 16;
  vect__2.7_14 = MEM[(double *)_13];
  _15 = _13 + 16;
  vect__2.8_16 = MEM[(double *)_15];
...
  _3079 = _3077 + 16;
  vect__2.1540_3080 = MEM[(double *)_3079];
  _3081 = _3079 + 16;
  vect__2.1541_3082 = MEM[(double *)_3081];
  _3083 = _3081 + 18446744073709551608;
  vect__2.1542_3084 = VEC_PERM_EXPR ;
  vect__2.1543_3085 = VEC_PERM_EXPR ;
  _8 = a[3][0];
  MEM[(double *)] = vect__2.1542_3084;
  _3087 = [0] + 16;
  MEM[(double *)_3087] = vect__2.1543_3085;
  return;

[Bug ipa/68851] [6 Regression] ICE: in set_comdat_group, at ipa-comdats.c:213

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Thanks Markus for reduction of the test-case.

For the minimized test, the constrop clone has properly unset a comdat group.
Comdat group for the node:

_ZNK1G20isFormControlElementEv.constprop.0/10 () @0x76a2f170
  Type: function definition analyzed
  Visibility:
  previous sharing asm name: 11
  References: 
  Referring: 
  Clone of _ZNK1G20isFormControlElementEv/1
  Availability: local
  First run: 0
  Function flags: local icf_merged nonfreeing_fn
  Called by: _ZThn8_NK1G20isFormControlElementEv/3 (1.00 per call) (can throw
external) 
  Calls: 

is set here:
#0  ipa_comdats () at ../../gcc/ipa-comdats.c:367
#1  0x013fcc93 in (anonymous namespace)::pass_ipa_comdats::execute
(this=0x21abfc0) at ../../gcc/ipa-comdats.c:412
#2  0x00c43564 in execute_one_pass (pass=pass@entry=0x21abfc0) at
../../gcc/passes.c:2336
#3  0x00c44252 in execute_ipa_pass_list (pass=0x21abfc0) at
../../gcc/passes.c:2756
#4  0x0095d33a in ipa_passes () at ../../gcc/cgraphunit.c:2300
#5  symbol_table::compile (this=this@entry=0x768d10a8) at
../../gcc/cgraphunit.c:2386
#6  0x0095fe68 in compile (this=0x768d10a8) at
../../gcc/cgraphunit.c:2520
#7  symbol_table::finalize_compilation_unit (this=0x768d10a8) at
../../gcc/cgraphunit.c:2546
#8  0x00d0b6e0 in compile_file () at ../../gcc/toplev.c:489
#9  0x006023d1 in do_compile () at ../../gcc/toplev.c:1977
#10 toplev::main (this=this@entry=0x7fffdb80, argc=argc@entry=13,
argv=argv@entry=0x7fffdc88) at ../../gcc/toplev.c:2084
#11 0x006045c7 in main (argc=13, argv=0x7fffdc88) at
../../gcc/main.c:39

As I mentioned, the assert is triggered for a node we create clone of
(_ZNK1G20isFormControlElementEv/1), which has the comdat group
already set (by FE). I'm wondering, when creating a clone of a thunk, whether
cgraph_node::thunk should not be duplicated?

Martin

[Bug tree-optimization/68894] Recognition min/max pattern with multiple arguments.

[ysrumyan at gmail dot com]

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

--- Comment #1 from Yuri Rumyantsev  ---
Created attachment 37026
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37026=edit
test-case to reproduce

It is sufficient to compile it with -O3 option to see the difference in
produced assembly.

[Bug tree-optimization/68861] [6 regression] FAIL: libgomp.fortran/vla8.f90 -O3 -g execution test

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Jeffrey A. Law  ---
This is starting to look like a latent but in the SLP vectorizer.   Sadly, I
cherry picked the latest SLP changes from Richi, but they don't help.

In .cunroll (for my strangely reduced testcase) we have the following key
statements:

So the first hint that makes this easier to understand is x_33 will always be
zero.  It's hidden from the compiler, but knowing makes it easier to follow.
  _13 = x_33 * 25;
  _10 = _13 + 5;
  _65 = _13 + 6;
  _149 = _13 + 7;
  _164 = 2;
  _162 = _10 + _164;
  *f_26[_169] = _162; //   *f_26[_169] = 7
  _132 = _1 + 12;
  *f_26[_132] = _162; //   *f_26[_132] = 7
  _135 = _1 + 13;
  _165 = _65 + _164;
  *f_26[_135] = _165; //   *f_26[_135] = 8
  _141 = _1 + 14;
  *f_26[_141] = _165; //   *f_26[_141] = 8
  _139 = _1 + 15;
  _146 = _164 + _149;
  *f_26[_139] = _146; //   *f_26[_139] = 9
  _179 = _1 + 16;
  *f_26[_179] = _146; //   *f[_26][_179] = 9


Then another batch (skipping some of the array index calculations)

  r.49_188 = 2;
  _136 = r.49_188 * 2;
  _137 = _10 + _136;
  *f_26[_133] = _137; //   *f_26[_133] = 9
  _145 = _129 + 12;
  *f_26[_145] = _137; //   *f_26[_145] = 9
  _163 = _129 + 13;
  _167 = _65 + _136;
  *f_26[_163] = _167; //   *f_26[_163] = 10
  _175 = _129 + 14;
  *f_26[_175] = _167; //   *f_26[_175] = 10
  _193 = _129 + 15;
  _197 = _136 + _149;
  *f_26[_193] = _197; //   *f_26[_193] = 11
  _205 = _129 + 16;
  *f_26[_205] = _197; //   *f_26[_205] = 11


Which is correct.  The SLP code is hairy, but the key bits from slp1 are
(remember that x_33 is always zero)

  vect_cst__201 = { 5, 5 };
  vect_cst__200 = { 6, 6 };
  vect_cst__199 = { 7, 7 };
  vect_cst__174 = { 25, 25 };
  vect_cst__171 = { 25, 25 };
  vect_cst__5 = {x_33, x_33};
  vect_cst__176 = {x_33, x_33};
  vect_cst__170 = {x_33, x_33};
  vect__13.88_192 = vect_cst__170 * vect_cst__174;  // { 0, 0 }
  vect__13.88_194 = vect_cst__176 * vect_cst__171;  // { 0, 0 }
  vect__13.88_196 = vect_cst__5 * vect_cst__52; // { 0, 0 }

  vect__10.89_204 = vect__13.88_192 + vect_cst__201;// { 5, 5 }
  _164 = 2;
  vect__10.89_206 = vect__13.88_194 + vect_cst__200;// { 6, 6 }
  vect__10.89_207 = vect__13.88_196 + vect_cst__199;// { 7, 7 }
  _13 = x_33 * 25;
  _149 = _13 + 7;
  vect_cst__208 = {_149, _149}; // { 7, 7 }
  vect_cst__209 = {_164, _164}; // { 2, 2 }
  vect_cst__11 = {_164, _164};  // { 2, 2 }
  vect__162.90_186 = vect__10.89_204 + vect_cst__11;// { 7, 7 }
  vect__162.90_185 = vect__10.89_206 + vect_cst__209;   // { 8, 8 }
  vect__162.90_156 = vect__10.89_207 + vect_cst__208;   // {14, 14 } WTF!

  vectp.92_155 = &*f_26[_169];
  MEM[(integer(kind=4) *)vectp.92_155] = vect__162.90_186;
  vectp.92_125 = vectp.92_155 + 8;
  MEM[(integer(kind=4) *)vectp.92_125] = vect__162.90_185;
  vectp.92_90 = vectp.92_125 + 8;
  MEM[(integer(kind=4) *)vectp.92_90] = vect__162.90_156;


Note how the last assignment stores vect__162.90_156, which is the wrong value.
 It should have been { 9, 9 }.

Te botch gets repeated in the next block of stores where we end up storing {
14, 14} instead of { 11, 11 } in the last store.

The bogus values obviously cause grief later.

Anyway, it's late.

[Bug fortran/68893] [Coarray] Wrong result with -fcoarray=single and EVENTS

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
event post ( event_value_has_been_set)
call event_query (event_value_has_been_set, cnt)

translates into:

  integer(kind=4) event_value_has_been_set;

  event_value_has_been_set = event_value_has_been_set + 1;
  cnt = event_value_has_been_set;

Expected: The static variable (must be a coarray and hence in static memory) is
initialized by 0.



Using an allocatable variable, the initialization works:

  type(event_type), allocatable :: event_value_has_been_set[:]
  allocate(event_value_has_been_set[*])

translates into

event_value_has_been_set.data = __builtin_malloc (4);
  ...
*event_value_has_been_set.data = 0;  //  0 initialization

*event_value_has_been_set.data = *event_value_has_been_set.data + 1;
cnt = *event_value_has_been_set.data;

[Bug middle-end/68852] [6 Regression] ICE in vect_is_simple_use (tree-vect-stmts.c:8750) using -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES

[alalaw01 at gcc dot gnu.org]

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

--- Comment #13 from alalaw01 at gcc dot gnu.org ---
Hmmm, I realize a "definite" codegen improvement was maybe a bad choice of
wording. A "substantial" (albeit uncertain!) improvement, may have been more
accurate...

However, yes it looks like we want that patch (indeed, it still helps even when
we up the cost of permute operations and drop the -fno-vect-cost-model) - so
thanks, Richard. We'll clean up the testisms in due course.

In the longer term, is the issue here, that we aren't comparing costs of SLP vs
load-lanes, right? We merely compare the cost of whichever of those
vectorization strategies we favour, permutes et al, vs leaving it in scalar
code?

[Bug target/68895] [ARM] ICE with target attributes

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-14
 Ever confirmed|0   |1

--- Comment #1 from chrbr at gcc dot gnu.org ---
This is related to the discussion we had recently with Kyril whereas we noticed
that simd types can be used with different TARGET_VECTOR_MODE_SUPPORTED_P  due
to the TARGET_NEON dependencies. Note that the discrepancy happens here for
parms but this is also complicated for global decl for which
set_current_function doesn't switch.
looking at it

[Bug c++/68897] New: No option to disable just "warning: enumeral and non-enumeral type in conditional expression"

[maxim.yegorushkin at gmail dot com]

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

Bug ID: 68897
   Summary: No option to disable just "warning: enumeral and
non-enumeral type in conditional expression"
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maxim.yegorushkin at gmail dot com
  Target Milestone: ---

The following code:

enum X { A };

unsigned foo(bool b) { return b ? A : 2u; }

int main(int ac, char**) {
return foo(ac > 1);
}

When compiled with `-Wall -Wextra -fdiagnostics-show-option` compiler options,
generates the following warning with g++-5.3:

unsigned foo(bool b) { return b ? A : 2u; }
^
warning: enumeral and non-enumeral type in conditional expression [-Wextra]

And the following warning with g++-4.9.2

unsigned foo(bool b) { return b ? A : 2u; }
^
warning: enumeral and non-enumeral type in conditional expression

There is no option to turn off only this particular warning without turning off
-Wextra.

[Bug tree-optimization/68775] [6 Regression] spec2006 test case 465.tonto fails with the gcc 6.0 fortran compiler

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Note that I can't reproduce the bogus dump with current trunk.

[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2015-12/msg01369.ht
   ||ml
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org
   Target Milestone|--- |6.0

--- Comment #10 from Rainer Orth  ---
Proposed patch.

[Bug middle-end/68870] [6 Regression] ICE on valid code at -O1, -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
The right (TM) fix:

Index: gcc/tree-cfgcleanup.c
===
--- gcc/tree-cfgcleanup.c   (revision 231617)
+++ gcc/tree-cfgcleanup.c   (working copy)
@@ -95,15 +95,9 @@ cleanup_control_expr_graph (basic_block
   switch (gimple_code (stmt))
{
case GIMPLE_COND:
- {
-   code_helper rcode;
-   tree ops[3] = {};
-   if (gimple_simplify (stmt, , ops, NULL, no_follow_ssa_edges,
-no_follow_ssa_edges)
-   && rcode == INTEGER_CST)
- val = ops[0];
-   break;
- }
+ val = const_binop (gimple_cond_code (stmt), boolean_type_node,
+gimple_cond_lhs (stmt), gimple_cond_rhs (stmt));
+ break;

case GIMPLE_SWITCH:
  val = gimple_switch_index (as_a  (stmt));

and the following shows the regressions:

Index: gcc/tree-cfgcleanup.c
===
--- gcc/tree-cfgcleanup.c   (revision 231617)
+++ gcc/tree-cfgcleanup.c   (working copy)
@@ -95,15 +95,18 @@ cleanup_control_expr_graph (basic_block
   switch (gimple_code (stmt))
{
case GIMPLE_COND:
- {
-   code_helper rcode;
-   tree ops[3] = {};
-   if (gimple_simplify (stmt, , ops, NULL, no_follow_ssa_edges,
-no_follow_ssa_edges)
-   && rcode == INTEGER_CST)
- val = ops[0];
-   break;
- }
+ val = const_binop (gimple_cond_code (stmt), boolean_type_node,
+gimple_cond_lhs (stmt), gimple_cond_rhs (stmt));
+ if (!val)
+   {
+ code_helper rcode;
+ tree ops[3] = {};
+ if (gimple_simplify (stmt, , ops, NULL,
no_follow_ssa_edges,
+  no_follow_ssa_edges)
+ && rcode == INTEGER_CST)
+   gcc_unreachable ();
+   }
+ break;

case GIMPLE_SWITCH:
  val = gimple_switch_index (as_a  (stmt));

[Bug debug/66688] [6 Regression] compare debug failure building Linux kernel on ppc64le

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Richard Biener from comment #5)
> > (In reply to Jakub Jelinek from comment #4)
> > > Created attachment 37027 [details]
> > > gcc6-pr66688.patch
> > > 
> > > I think this just went latent with those changes.  The problem I see is 
> > > that
> > > cleanup_control_flow_bb can be called before fixup_noreturn_call is
> > > performed, and in that case can either find a noreturn call at the end of 
> > > bb
> > > if -g0 or can't if the noreturn call is followed by some debug stmts.  
> > > This
> > > hunk fixes the case so that it is handled the same.
> > 
> > Hum, why not just s/gsi_last_bb/gsi_last_nondebug_bb/?
> 
> That is possible too, but IMHO you still want to remove the debug stmts at
> that point, removing fallthru edge while keeping noreturn call in the middle
> of bb is weird.

True...

> Plus there is the question what to do if the other stmt
> kinds the function is looking for are followed by debug stmts.  I'd strongly
> hope they aren't, so perhaps we can just assert in that case it is the last
> stmt.

Yes, I think for those it cannot happen.

[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Mon Dec 14 15:33:20 2015
New Revision: 231620

URL: https://gcc.gnu.org/viewcvs?rev=231620=gcc=rev
Log:
2015-12-10  Richard Biener  

PR tree-optimization/68707
PR tree-optimization/67323
* tree-vect-slp.c (vect_analyze_slp_instance): Drop SLP instances
if they can be vectorized using load/store-lane instructions.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug tree-optimization/67323] Use non-unit stride loads by preference when applicable

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Mon Dec 14 15:33:20 2015
New Revision: 231620

URL: https://gcc.gnu.org/viewcvs?rev=231620=gcc=rev
Log:
2015-12-10  Richard Biener  

PR tree-optimization/68707
PR tree-optimization/67323
* tree-vect-slp.c (vect_analyze_slp_instance): Drop SLP instances
if they can be vectorized using load/store-lane instructions.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Fri, 11 Dec 2015, alalaw01 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707
> 
> --- Comment #10 from alalaw01 at gcc dot gnu.org ---
> slp-perm-11.c: a 16-iteration loop gets unrolled *2, and now uses an st2, but
> no load_lanes, just a bunch of ldr's: 10 rather than the original 3(*2). 3 
> strs
> become 4 stp's (+st2). Doesn't look like an improvement!

I'll look at this case as I intended to make sure using load-lanes is
possible.  Hopefully reproduces with a cross ;)

[Bug target/68896] [ARM] target attribute ignored

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-14
 Ever confirmed|0   |1

--- Comment #1 from chrbr at gcc dot gnu.org ---
confirmed. 
ok without -mfpu=neon on the command line, although the #pragma should prevail

[Bug rtl-optimization/68898] ICE if rtl if-conversion is off.

[ysrumyan at gmail dot com]

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

--- Comment #2 from Yuri Rumyantsev  ---
Forgot to add stack trace:

Error: dominator of 6 status unknown
t2.f:41:0: internal compiler error: Segmentation fault
0xb4e62f crash_signal
/export/users/gnutester/stability/svn/trunk/gcc/toplev.c:334
0x376583567f ???
   
/home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7e7d0d verify_dominators(cdi_direction)
/export/users/gnutester/stability/svn/trunk/gcc/dominance.c:1033
0x7e7fa7 checking_verify_dominators
/export/users/gnutester/stability/svn/trunk/gcc/dominance.h:71
0x7e7fa7 calculate_dominance_info(cdi_direction)
/export/users/gnutester/stability/svn/trunk/gcc/dominance.c:664
0x9a178e ira
/export/users/gnutester/stability/svn/trunk/gcc/ira.c:5155
0x9a178e execute
/export/users/gnutester/stability/svn/trunk/gcc/ira.c:5511

[Bug target/68895] New: [ARM] ICE with target attributes

[clyon at gcc dot gnu.org]

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

Bug ID: 68895
   Summary: [ARM] ICE with target attributes
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: chrbr at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---
Target: arm

Hi,

While modifying some tests to update my testsuite cleanup proposal around
target attributes testing
(https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03356.html), I am facing an ICE.

I've modified attr-neon2.c like that:
==
/* { dg-do compile } */
/* { dg-require-effective-target arm_neon_ok } */
/* { dg-require-effective-target arm_fp_ok } */
/* { dg-options "-O2" } */
/* { dg-add-options arm_fp } */

/* Reset fpu to a value compatible with the next pragmas.  */
#pragma GCC target ("fpu=vfp")
#pragma GCC push_options

#pragma GCC target ("fpu=neon")
#include 

/* Check that pragma target is used.  */
int8x8_t
my (int8x8_t __a, int8x8_t __b)
{
  return __a + __b;
}

#pragma GCC pop_options

/* Check that command line option is restored.  */
int8x8_t
my1 (int8x8_t __a, int8x8_t __b)
{
  return __a + __b;
}

/* { dg-final { scan-assembler-times "\.fpu vfp" 1 } } */
/* { dg-final { scan-assembler-times "\.fpu neon" 1 } } */
/* { dg-final { scan-assembler "vadd" } } */
==

That is, I added:
#pragma GCC target ("fpu=vfp")
#pragma GCC push_options

at the beginning, and I replaced reset_options with pop_options.


I am now seeing:
spawn
/home/christophe.lyon/src/GCC/builds/gcc-fsf-arm-attribs/obj-arm-none-linux-gnueabihf/gcc3/gcc/xgcc
-B/home/christophe.lyon/src/GCC/builds/gcc-fsf-arm-attribs/obj-arm-none-linux-gnueabihf/gcc3/gcc/
/home/christophe.lyon/src/GCC/sources/gcc-fsf/arm-attribs/gcc/testsuite/gcc.target/arm/attr-neon2.c
-fno-diagnos\
tics-show-caret -fdiagnostics-color=never -O2 -ffat-lto-objects
-DSTACK_SIZE=16384 -S -o attr-neon2.s^M
/home/christophe.lyon/src/GCC/sources/gcc-fsf/arm-attribs/gcc/testsuite/gcc.target/arm/attr-neon2.c:
In function 'my':^M
/home/christophe.lyon/src/GCC/sources/gcc-fsf/arm-attribs/gcc/testsuite/gcc.target/arm/attr-neon2.c:16:1:
internal compiler error: in set_rtl, at cfgexpand.c:215^M
0x82badb set_rtl^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/arm-attribs/gcc/cfgexpand.c:209^M
0x82edc4 set_parm_rtl(tree_node*, rtx_def*)^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/arm-attribs/gcc/cfgexpand.c:1259^M
0x9ebe67 assign_parm_setup_reg^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/arm-attribs/gcc/function.c:3339^M
0x9ed675 assign_parms^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/arm-attribs/gcc/function.c:3766^M
0x9f17af expand_function_start(tree_node*)^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/arm-attribs/gcc/function.c:5200^M
0x83f0ce execute^M
   
/home/christophe.lyon/src/GCC/sources/gcc-fsf/arm-attribs/gcc/cfgexpand.c:6210^M
Please submit a full bug report,^M


My GCC was configured with: --target=arm-none-linux-gnueabihf --with-float=hard
--with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon

[Bug middle-end/68852] [6 Regression] ICE in vect_is_simple_use (tree-vect-stmts.c:8750) using -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Mon Dec 14 15:26:24 2015
New Revision: 231619

URL: https://gcc.gnu.org/viewcvs?rev=231619=gcc=rev
Log:
2015-12-14  Richard Biener  

PR tree-optimization/68852
* tree-vectorizer.h (struct _slp_tree): Add def_type member.
(SLP_TREE_DEF_TYPE): New accessor.
* tree-vect-stmts.c (vect_is_simple_use): Remove BB vectorization
hack.
* tree-vect-slp.c (vect_create_new_slp_node): Initialize
SLP_TREE_DEF_TYPE.
(vect_build_slp_tree): When a node is to be built up from scalars
do not push a NULL as child but instead set its def_type to
vect_external_def.
(vect_analyze_slp_cost_1): Check for child def-type instead
of NULL.
(vect_detect_hybrid_slp_stmts): Likewise.
(vect_bb_slp_scalar_cost): Likewise.
(vect_get_slp_defs): Likewise.
(vect_slp_analyze_node_operations): Likewise.  Before
processing node push the children def-types to the underlying
stmts vinfo and restore it afterwards.
(vect_schedule_slp_instance): Likewise.
(vect_slp_analyze_bb_1): Do not mark stmts not in SLP instances
as not vectorizable.

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

Added:
trunk/gcc/testsuite/g++.dg/torture/pr68852.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree-vectorizer.h

[Bug ipa/68851] [6 Regression] ICE: in set_comdat_group, at ipa-comdats.c:213

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

--- Comment #8 from Martin Jambor  ---
Mine. It seems that ipa-cp redirects one too many edges that it gathers using
collect_callers. I'm testing a fix.

[Bug rtl-optimization/68796] Make use of and-immediate+compare instructions more robust

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-14
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I'll try something out

[Bug rtl-optimization/68898] ICE if rtl if-conversion is off.

[ysrumyan at gmail dot com]

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

--- Comment #1 from Yuri Rumyantsev  ---
Created attachment 37028
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37028=edit
test-case to reproduce

Need to compile with -O2 -m32 -ffast-math options to reproduce. Note that
32-bit and -ffast-math flags are essential.

[Bug tree-optimization/68844] [6 regression] gcc.dg/tree-ssa/ssa-dom-thread-4.c fails since r228306

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Jeff, thanks very much for the detailed analysis!

Bill

[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
So explicit like

+  /* If the loads and stores can be handled with load/store-lane
+ instructions do not generate this SLP instance.  */
+  if (is_a  (vinfo)
+ && loads_permuted
+ && dr && vect_store_lanes_supported (vectype, group_size))
+   {
+ slp_tree load_node;
+ FOR_EACH_VEC_ELT (loads, i, load_node)
+   {
+ gimple *first_stmt = GROUP_FIRST_ELEMENT
+ (vinfo_for_stmt (SLP_TREE_SCALAR_STMTS (load_node)[0]));
+ stmt_vec_info stmt_vinfo = vinfo_for_stmt (first_stmt);
+ if (STMT_VINFO_STRIDED_P (stmt_vinfo)
+ || ! vect_load_lanes_supported
+(STMT_VINFO_VECTYPE (stmt_vinfo),
+ GROUP_SIZE (stmt_vinfo)))
+   break;

for example, keeping the SLP in the case one load is strided.

[Bug target/68896] New: [ARM] target attribute ignored

[clyon at gcc dot gnu.org]

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

Bug ID: 68896
   Summary: [ARM] target attribute ignored
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: chrbr at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---
Target: arm

Hi,

With a modified version of attr-neon3.c, it seems that the 1st target attribute
is ignored.

===
/* { dg-do compile } */
/* { dg-require-effective-target arm_crypto_ok } */
/* { dg-require-effective-target arm_fp_ok } */
/* { dg-options "-O2" } */
/* { dg-add-options arm_fp } */

/* Reset fpu to a value compatible with the next pragmas.  */
#pragma GCC target ("fpu=vfp")
#pragma GCC push_options

#include 

/* Check that neon is used.  */
int8x8_t __attribute__ ((target("fpu=neon")))
my (int8x8_t __a, int8x8_t __b)
{
  return __a + __b;
}

/* Check that crypto builtins are recognized.  */
poly128_t __attribute__ ((target("fpu=crypto-neon-fp-armv8")))
foo (poly128_t* ptr)
{
  return vldrq_p128 (ptr);
}

/* Check that default mode is restored.  */
int8x8_t
my1 (int8x8_t __a, int8x8_t __b)
{
  return __a + __b;
}

/* { dg-final { scan-assembler-times "\.fpu vfp" 1 } } */
/* { dg-final { scan-assembler-times "\.fpu neon" 1 } } */
/* { dg-final { scan-assembler-times "\.fpu crypto-neon-fp-armv8" 1 } } */
/* { dg-final { scan-assembler-times "vld1" 1 } } */
/* { dg-final { scan-assembler-times "vadd" 1} } */
==

Compiling with
/home/christophe.lyon/src/GCC/builds/gcc-fsf-arm-attribs/obj-arm-none-linux-gnueabihf/gcc3/gcc/xgcc
-B/home/christophe.lyon/src/GCC/builds/gcc-fsf-arm-attribs/obj-arm-none-linux-gnueabihf/gcc3/gcc/
/home/christophe.lyon/src/GCC/sources/gcc-fsf/arm-attribs/gcc/testsuite/gcc.target/arm/attr-neon3.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -ffat-lto-objects
-DSTACK_SIZE=16384 -S -o attr-neon3.s

GCC configured: --target=arm-none-linux-gnueabihf --with-float=hard
--with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon

Notice how the first function (my) is compiled with '.fpu vfp'

[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
(In reply to alalaw01 from comment #13)
> Hmmm, I realize a "definite" codegen improvement was maybe a bad choice of
> wording. A "substantial" (albeit uncertain!) improvement, may have been more
> accurate...
> 
> However, yes it looks like we want that patch (indeed, it still helps even
> when we up the cost of permute operations and drop the -fno-vect-cost-model)
> - so thanks, Richard. We'll clean up the testisms in due course.
> 
> In the longer term, is the issue here, that we aren't comparing costs of SLP
> vs load-lanes, right? We merely compare the cost of whichever of those
> vectorization strategies we favour, permutes et al, vs leaving it in scalar
> code?

Yes, at the moment cost comparison would be apples to oranges :(

Note the  commit was a revert - I accidentially committed the patch.

[Bug target/68865] [6 regression] gcc.dg/atomic/c11-atomic-exec-2.c fails since r231165

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #5 from Segher Boessenkool  ---
Fixed.

[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
(In reply to rguent...@suse.de from comment #12)
> On Fri, 11 Dec 2015, alalaw01 at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707
> > 
> > --- Comment #10 from alalaw01 at gcc dot gnu.org ---
> > slp-perm-11.c: a 16-iteration loop gets unrolled *2, and now uses an st2, 
> > but
> > no load_lanes, just a bunch of ldr's: 10 rather than the original 3(*2). 3 
> > strs
> > become 4 stp's (+st2). Doesn't look like an improvement!
> 
> I'll look at this case as I intended to make sure using load-lanes is
> possible.  Hopefully reproduces with a cross ;)

Ok, so the reason is the load is strided.  Interleaving will end up
loading individual elements while SLP will possibly load sub-vectors
at a time:

  vector(2) int _22;
  vector(2) int _24;
  vector(4) int vect_cst__26;
...
  :
  # ivtmp.19_16 = PHI 
  # ivtmp.22_6 = PHI 
  _10 = (void *) ivtmp.19_16;
  _22 = MEM[base: _10, offset: 0B];
  _24 = MEM[base: _10, index: _2, offset: 0B];
  vect_cst__26 = {_22, _24};
  vect__8.14_27 = VEC_PERM_EXPR ;
  _11 = (void *) ivtmp.22_6;
  MEM[base: _11, offset: 0B] = vect__8.14_27;
  ivtmp.19_17 = ivtmp.19_16 + _19;
  ivtmp.22_7 = ivtmp.22_6 + 16;
  if (ivtmp.22_7 != _15)
goto ;

loads two two element vectors and concats them (and the permutes them
accordingly of course).

I'd like to make the strided case explicit, either by not dumping the SLP
or by dumping the SLP anyway (ignoring the strided case which will remain
strided but possibly less efficient).

[Bug target/68879] PowerPC: SImode cstore optimisation produces bad code

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Author: segher
Date: Mon Dec 14 16:13:33 2015
New Revision: 231621

URL: https://gcc.gnu.org/viewcvs?rev=231621=gcc=rev
Log:
rs6000: Fix a mistake in cstore_si_as_di (PR68865, PR68879)

convert_move does not know how to zero-extend a constant integer to the
target mode -- simply because it does not know the source mode.  As a
result, 32-bit SImode with the high bit set would be effectively sign-
extended instead of zero-extended.

This patch fixes it.


PR target/68865
PR target/68879
* config/rs6000/rs6000.md (cstore_si_as_di): Force all operands
into registers.

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

[Bug target/68865] [6 regression] gcc.dg/atomic/c11-atomic-exec-2.c fails since r231165

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Author: segher
Date: Mon Dec 14 16:13:33 2015
New Revision: 231621

URL: https://gcc.gnu.org/viewcvs?rev=231621=gcc=rev
Log:
rs6000: Fix a mistake in cstore_si_as_di (PR68865, PR68879)

convert_move does not know how to zero-extend a constant integer to the
target mode -- simply because it does not know the source mode.  As a
result, 32-bit SImode with the high bit set would be effectively sign-
extended instead of zero-extended.

This patch fixes it.


PR target/68865
PR target/68879
* config/rs6000/rs6000.md (cstore_si_as_di): Force all operands
into registers.

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

[Bug rtl-optimization/68898] New: ICE if rtl if-conversion is off.

[ysrumyan at gmail dot com]

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

Bug ID: 68898
   Summary: ICE if rtl if-conversion is off.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com
  Target Milestone: ---

I tried to play with if-conversion flag and got ICE on all benchspec2 from
spec2000 suite. I attach simple Fortran reproducer. Note that
"-fno-if-conversion2" option does not lead to CF.

[Bug libstdc++/68863] Regular expressions: Backreferences don't work in negative lookahead

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Tim Shen  ---
Fixed in trunk, and backported to gcc 5 and gcc 4.9.

[Bug target/68908] inefficient code for an atomic preincrement on powerpc64le

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Interestingly, it does emit equally as efficient code as Clang for
__atomic_fetch_add:

void fetch_and_add (AI *ai)
{
__atomic_fetch_add (ai, 1, __ATOMIC_SEQ_CST);
}

i.e.,

fetch_and_add:
sync
.L2:
lwarx 9,0,3
addi 9,9,1
stwcx. 9,0,3
bne- 0,.L2
isync
blr

[Bug c/68907] New: bogus warning: right-hand operand of comma expression has no effect on an atomic_int preincrement

[msebor at gcc dot gnu.org]

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

Bug ID: 68907
   Summary: bogus warning: right-hand operand of comma expression
has no effect on an atomic_int preincrement
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC 5.1.0 and current trunk issue the following incorrect warning on the
preincrement of an _Atomic variable.

$ cat ~/tmp/t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wall
-Wextra -o/dev/null ~/tmp/t.c
$ cat ~/tmp/t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wall
-Wextra -o/dev/null ~/tmp/t.c
typedef _Atomic int AI;

extern AI ai;

void increment (void)
{
++ai;
}
/home/remote/msebor/tmp/t.c: In function ‘increment’:
/home/remote/msebor/tmp/t.c:7:5: warning: right-hand operand of comma
expression has no effect [-Wunused-value]
 ++ai;
 ^~~~

[Bug target/68908] New: inefficient code for an atomic preincrement on powerpc64le

[msebor at gcc dot gnu.org]

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

Bug ID: 68908
   Summary: inefficient code for an atomic preincrement on
powerpc64le
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC 6.0 for powerpc64le emits the following inefficient code for an atomic
increment.  (The bogus warning is the subject of bug 68907).

$ cat ~/tmp/t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O2 -S
-Wall -o/dev/stdout ~/tmp/t.c
typedef _Atomic int AI;

void increment (AI *ai)
{
++*ai;
}
.file   "t.c"
.machine power8
.abiversion 2
.section".toc","aw"
.section".text"
/home/remote/msebor/tmp/t.c: In function ‘increment’:
/home/remote/msebor/tmp/t.c:5:5: warning: right-hand operand of comma
expression has no effect [-Wunused-value]
 ++*ai;
 ^

.align 2
.p2align 4,,15
.globl increment
.type   increment, @function
increment:
sync
lwz 9,0(3)
cmpw 7,9,9
bne- 7,$+4
isync
extsw 9,9
stw 9,-16(1)
.p2align 4,,15
.L6:
lwz 8,-16(1)
addi 9,9,1
sync
.L2:
lwarx 10,0,3
cmpw 0,10,8
bne- 0,.L3
stwcx. 9,0,3
bne- 0,.L2
.L3:
isync
mfcr 9,128
rlwinm 9,9,3,1
beq 0,.L4
stw 10,-16(1)
.L4:
andi. 10,9,0x1
bnelr- 0
lwa 9,-16(1)
b .L6
.long 0
.byte 0,0,0,0,0,0,0,0
.size   increment,.-increment
.ident  "GCC: (GNU) 6.0.0 20151214 (experimental)"
.section.note.GNU-stack,"",@progbits


Clang 3.8 emits the expected:

increment:  # @increment
.Lfunc_begin0:
# BB#0: # %entry
li 4, 1
sync
.LBB0_1:# %entry
# =>This Inner Loop Header: Depth=1
lwarx 5, 0, 3
add 5, 4, 5
stwcx. 5, 0, 3
bne  0, .LBB0_1
# BB#2: # %entry
lwsync
blr

[Bug target/54663] microblaze-linux genchecksum failure: opening microblaze-c.o: No such file or directory

[eager at eagercon dot com]

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

--- Comment #5 from Michael Eager  ---
(In reply to vries from comment #4)
> A patch was committed for this PR. Can this PR be closed?

Yes.

[Bug target/47093] [meta-bug]: broken configurations

[vries at gcc dot gnu.org]

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

Bug 54663 Summary: microblaze-linux genchecksum failure: opening 
microblaze-c.o: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54663

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug target/54663] microblaze-linux genchecksum failure: opening microblaze-c.o: No such file or directory

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to Michael Eager from comment #5)
> (In reply to vries from comment #4)
> > A patch was committed for this PR. Can this PR be closed?
> 
> Yes.

[Bug rtl-optimization/63577] [4.9/5/6 Regression]: Huge compile time and memory usage with -O and not -fPIC

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
I cannot reproduce the problem with GCC 6, combine takes about 1%
time and little memory.  I do not know what changed.

[Bug c/68907] bogus warning: right-hand operand of comma expression has no effect on an atomic_int preincrement

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-15
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |5.4
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
I thought I had fixed something similar some time ago...

[Bug libstdc++/68863] Regular expressions: Backreferences don't work in negative lookahead

[timshen at gcc dot gnu.org]

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

--- Comment #2 from Tim Shen  ---
Author: timshen
Date: Tue Dec 15 04:50:29 2015
New Revision: 231641

URL: https://gcc.gnu.org/viewcvs?rev=231641=gcc=rev
Log:
PR libstdc++/68863
* include/bits/regex_executor.tcc (_Executor::_M_lookahead):
Copy the captured content for lookahead, so that the backreferences
inside can refer to them.
* testsuite/28_regex/algorithms/regex_match/ecma/char/68863.cc:
New testcase.

Added:
   
trunk/libstdc++-v3/testsuite/28_regex/algorithms/regex_match/ecma/char/68863.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/regex_executor.tcc

[Bug target/54663] microblaze-linux genchecksum failure: opening microblaze-c.o: No such file or directory

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #4 from vries at gcc dot gnu.org ---
A patch was committed for this PR. Can this PR be closed?

[Bug libstdc++/68863] Regular expressions: Backreferences don't work in negative lookahead

[timshen at gcc dot gnu.org]

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

--- Comment #4 from Tim Shen  ---
Author: timshen
Date: Tue Dec 15 05:59:01 2015
New Revision: 231643

URL: https://gcc.gnu.org/viewcvs?rev=231643=gcc=rev
Log:
Backport from mainline
2015-12-15  Tim Shen  

PR libstdc++/68863
* include/bits/regex_executor.tcc (_Executor::_M_lookahead):
Copy the captured content for lookahead, so that the backreferences
inside can refer to them.
* testsuite/28_regex/algorithms/regex_match/ecma/char/68863.cc:
New testcase.

Added:
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/28_regex/algorithms/regex_match/ecma/char/68863.cc
Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex_executor.tcc

[Bug fortran/68196] [4.9/5 Regression] ICE on function result with procedure pointer component

[damian at sourceryinstitute dot org]

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

--- Comment #8 from Damian Rouson  ---
I believe the example below is related to this bug report:

$ cat alloc-ptr-comp-func-result.f90 
  type  Bug
real, allocatable :: scalar
procedure(buggerInterface),pointer :: bugger 
  end type 
  interface
function buggerInterface(A) result(C)
  import Bug
  class(Bug) A
  type(Bug)  C
end function 
  end interface
end 

$ gfortran alloc-ptr-comp-func-result.f90 
gfortran: internal compiler error: Segmentation fault (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

$ gfortran --version
GNU Fortran (GCC) 6.0.0 20151214 (experimental)

[Bug c/68909] New: ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297

[chengniansun at gmail dot com]

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

Bug ID: 68909
   Summary: ICE on valid code at -O3 on x86_64-linux-gnu in
maybe_record_trace_start, at dwarf2cfi.c:2297
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.


$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151214 (experimental) [trunk revision 231607] (GCC) 
$: 
$: gcc-trunk -m32 -O3 small.c
small.c: In function ‘main’:
small.c:18:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2284
 }
 ^

0x789cf6 maybe_record_trace_start
../../gcc-trunk/gcc/dwarf2cfi.c:2284
0x78c450 scan_trace
../../gcc-trunk/gcc/dwarf2cfi.c:2462
0x78cc8a create_cfi_notes
../../gcc-trunk/gcc/dwarf2cfi.c:2616
0x78cc8a execute_dwarf2_frame
../../gcc-trunk/gcc/dwarf2cfi.c:2974
0x78cc8a execute
../../gcc-trunk/gcc/dwarf2cfi.c:3454
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$: gcc-trunk -m64 -O3 small.c
small.c: In function ‘main’:
small.c:18:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2284
 }
 ^

0x789cf6 maybe_record_trace_start
../../gcc-trunk/gcc/dwarf2cfi.c:2284
0x78c450 scan_trace
../../gcc-trunk/gcc/dwarf2cfi.c:2462
0x78cc8a create_cfi_notes
../../gcc-trunk/gcc/dwarf2cfi.c:2616
0x78cc8a execute_dwarf2_frame
../../gcc-trunk/gcc/dwarf2cfi.c:2974
0x78cc8a execute
../../gcc-trunk/gcc/dwarf2cfi.c:3454
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$: 
$: cat small.c
int printf(const char*, ...);
int a, b, c;
char d = 5;
int **e;
int main() {
  b = 6;
  for (; b; b--) {
c = 0;
for (; c <= 8; c++) {
  while (!d)
if (*e)
  break;
  d = 1;
}
  }
  printf("%d\n", a);
  return 0;
}
$:

[Bug c++/53223] [c++0x] auto&& and operator* don't mix inside templates

[ppalka at gcc dot gnu.org]

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

--- Comment #13 from Patrick Palka  ---
Author: ppalka
Date: Tue Dec 15 03:33:53 2015
New Revision: 231640

URL: https://gcc.gnu.org/viewcvs?rev=231640=gcc=rev
Log:
Fix PR c++/21802 (two-stage name lookup fails for operators)

gcc/cp/ChangeLog:

PR c++/21802
PR c++/53223
* cp-tree.h (cp_tree_code_length): Declare.
(build_min_non_dep_op_overload): Declare.
* tree.c (cp_tree_code_length): Define.
(build_min_non_dep_op_overload): Define.
(build_win_non_dep_call_vec): Copy the KOENIG_LOOKUP_P flag.
* typeck.c (build_x_indirect_ref): Use
build_min_non_dep_op_overload when the given expression
has been resolved to an operator overload.
(build_x_binary_op): Likewise.
(build_x_array_ref): Likewise.
(build_x_unary_op): Likewise.
(build_x_compound_expr): Likewise.
(build_x_modify_expr): Likewise.
* decl2.c (grok_array_decl): Likewise.
* call.c (build_new_op_1): If during template processing we
chose an operator overload that is a hidden friend function, set
the call's KOENIG_LOOKUP_P flag to 1.

gcc/testsuite/ChangeLog:

PR c++/21802
PR c++/53223
* g++.dg/cpp0x/pr53223.C: New test.
* g++.dg/lookup/pr21802.C: New test.
* g++.dg/lookup/two-stage4.C: Remove XFAIL.


Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr53223.C
trunk/gcc/testsuite/g++.dg/lookup/pr21802.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl2.c
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lookup/two-stage4.C

[Bug c++/21802] Two-stage name lookup fails for operators

[ppalka at gcc dot gnu.org]

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

--- Comment #6 from Patrick Palka  ---
Author: ppalka
Date: Tue Dec 15 03:33:53 2015
New Revision: 231640

URL: https://gcc.gnu.org/viewcvs?rev=231640=gcc=rev
Log:
Fix PR c++/21802 (two-stage name lookup fails for operators)

gcc/cp/ChangeLog:

PR c++/21802
PR c++/53223
* cp-tree.h (cp_tree_code_length): Declare.
(build_min_non_dep_op_overload): Declare.
* tree.c (cp_tree_code_length): Define.
(build_min_non_dep_op_overload): Define.
(build_win_non_dep_call_vec): Copy the KOENIG_LOOKUP_P flag.
* typeck.c (build_x_indirect_ref): Use
build_min_non_dep_op_overload when the given expression
has been resolved to an operator overload.
(build_x_binary_op): Likewise.
(build_x_array_ref): Likewise.
(build_x_unary_op): Likewise.
(build_x_compound_expr): Likewise.
(build_x_modify_expr): Likewise.
* decl2.c (grok_array_decl): Likewise.
* call.c (build_new_op_1): If during template processing we
chose an operator overload that is a hidden friend function, set
the call's KOENIG_LOOKUP_P flag to 1.

gcc/testsuite/ChangeLog:

PR c++/21802
PR c++/53223
* g++.dg/cpp0x/pr53223.C: New test.
* g++.dg/lookup/pr21802.C: New test.
* g++.dg/lookup/two-stage4.C: Remove XFAIL.


Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr53223.C
trunk/gcc/testsuite/g++.dg/lookup/pr21802.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl2.c
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lookup/two-stage4.C

[Bug libstdc++/68863] Regular expressions: Backreferences don't work in negative lookahead

[timshen at gcc dot gnu.org]

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

--- Comment #3 from Tim Shen  ---
Author: timshen
Date: Tue Dec 15 05:19:20 2015
New Revision: 231642

URL: https://gcc.gnu.org/viewcvs?rev=231642=gcc=rev
Log:
Backport from mainline
2015-12-15  Tim Shen  

PR libstdc++/68863
* include/bits/regex_executor.tcc (_Executor::_M_lookahead):
Copy the captured content for lookahead, so that the backreferences
inside can refer to them.
* testsuite/28_regex/algorithms/regex_match/ecma/char/68863.cc:
New testcase.

Added:
   
branches/gcc-5-branch/libstdc++-v3/testsuite/28_regex/algorithms/regex_match/ecma/char/68863.cc
Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/bits/regex_executor.tcc

[Bug middle-end/68870] [6 Regression] ICE on valid code at -O1, -O2 and -O3 on x86_64-linux-gnu

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On December 15, 2015 3:15:13 AM GMT+01:00, law at redhat dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68870
>
>--- Comment #6 from Jeffrey A. Law  ---
>I'd say that changing genmatch (or any code) to know about the freelist
>is a
>horrid hack and just papering over the problem.
>
>I haven't put this case under a debugger, but presumably we've got a
>reference
>to a released SSA_NAME in the IL, right? 

We have invalid SSA, a use not dominated by its def.  It happens to be in a
trivially dead region but CFG cleanup deleting the def first which is in
another trivially dead region and then folding the conditional is causing this.
Note the conditional happens to be folded before it is deleted as part of the
other trivial dead region.

So it's the old CFG cleanup ordering issue I tried to fix with the last rev.
But forgot that folding code...

 Presumably in some code that
>isn't
>trivially proved unreachable?

It actually is.

[Bug debug/66688] [6 Regression] compare debug failure building Linux kernel on ppc64le

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec 15 07:46:23 2015
New Revision: 231644

URL: https://gcc.gnu.org/viewcvs?rev=231644=gcc=rev
Log:
PR tree-optimization/66688
* tree-cfgcleanup.c (cleanup_control_flow_bb): Handle
noreturn call followed only by debug stmts by removing
the debug stmts and handling it the same as if the noreturn
call is the last stmt.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr66688.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfgcleanup.c

[Bug c/68907] bogus warning: right-hand operand of comma expression has no effect on an atomic_int preincrement

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
GCC 4.9 warns too.

[Bug debug/66688] [6 Regression] compare debug failure building Linux kernel on ppc64le

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This is no longer reproduceable starting with r231162.  With r231161, what I
can see is that during einline cfg cleanup makes different decisions, with -g
merges two basic blocks that are not merged with -g0.

[Bug fortran/45859] [Coarray, F2008, IR] Rejects valid actuals to coarray dummies

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #8 from Tobias Burnus  ---
FIXED in GCC 6

[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]

[burnus at gcc dot gnu.org]

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

Bug 45859 Summary: [Coarray, F2008, IR] Rejects valid actuals to coarray dummies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45859

   What|Removed |Added

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

[Bug fortran/39627] [meta-bug] Fortran 2008 support

[burnus at gcc dot gnu.org]

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

Bug 45859 Summary: [Coarray, F2008, IR] Rejects valid actuals to coarray dummies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45859

   What|Removed |Added

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

[Bug tree-optimization/67781] [5/6 Regression] wrong code generated on big-endian with -O1 -fexpensive-optimizations

[thopre01 at gcc dot gnu.org]

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

--- Comment #7 from Thomas Preud'homme  ---
The exact place where it goes wrong is in find_bswap_or_nop (not the _1 helper
function) in the following line:

  for (tmpn = n->n, rsize = 0; tmpn; tmpn >>= BITS_PER_MARKER, rsize++);

This code removes the most significant zero on little endian systems but the
least significant one on big endian ones, changing the value in n->n. It should
do some left shift but be careful of undefined behavior.

Actually, this makes me realize that we only remove the most significant zeros
but the least significant ones would be fine too if the base address is
adjusted.

[Bug tree-optimization/68492] [6 Regression] internal compiler error: in vect_is_simple_use, at tree-vect-stmts.c:8266

[rguenth at gcc dot gnu.org]

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

Bug 68775 Summary: [6 Regression] spec2006 test case 465.tonto fails with the 
gcc 6.0 fortran compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68775

   What|Removed |Added

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

[Bug tree-optimization/68775] [6 Regression] spec2006 test case 465.tonto fails with the gcc 6.0 fortran compiler

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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