[Bug c++/67354] [5/6 regression] internal compiler error: in add_to_same_comdat_group, at symtab.c:421

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |5.3

[Bug target/67351] Missed optimisation on 64-bit field compared to 32-bit

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-26
 Ever confirmed|0   |1

--- Comment #6 from Richard Biener  ---
Yes, << N >> N can be converted (but only for unsigned right shift or in VRP
with range information).  Convert the following fold-const.c code to match.pd:

  /* Transform (x >> c) << c into x & (-1<> c
 into x & ((unsigned)-1 >> c) for unsigned types.  */
  if (((code == LSHIFT_EXPR && TREE_CODE (arg0) == RSHIFT_EXPR)
   || (TYPE_UNSIGNED (type)
   && code == RSHIFT_EXPR && TREE_CODE (arg0) == LSHIFT_EXPR))
  && tree_fits_uhwi_p (arg1)
  && tree_to_uhwi (arg1) < prec
  && tree_fits_uhwi_p (TREE_OPERAND (arg0, 1))
  && tree_to_uhwi (TREE_OPERAND (arg0, 1)) < prec)
{ 
  HOST_WIDE_INT low0 = tree_to_uhwi (TREE_OPERAND (arg0, 1));
  HOST_WIDE_INT low1 = tree_to_uhwi (arg1);
  tree lshift;
  tree arg00;

  if (low0 == low1)
{ 
  arg00 = fold_convert_loc (loc, type, TREE_OPERAND (arg0, 0));

  lshift = build_minus_one_cst (type);
  lshift = const_binop (code, lshift, arg1);

  return fold_build2_loc (loc, BIT_AND_EXPR, type, arg00, lshift);
}
}

[Bug debug/67355] [5 Regression] ICE compiling LTP testcase, endless cselib recursion from var-tracking

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Hmm, I can't reproduce with my FSF 5.1 or 5.2 builds (release checking) but I
can reproduce with my current GCC 5 branch development build (checking
enabled):

> /abuild/rguenther/gcc5-g/gcc/cc1 -quiet -O2 -m32 -g atof01.i 
> -fstack-protector -funwind-tables -fasynchronous-unwind-tables
Segmentation fault

the above is on x86_64 with -m32 (original report was for native i?86).

[Bug debug/67355] [5 Regression] ICE compiling LTP testcase, endless cselib recursion from var-tracking

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
   Target Milestone|--- |5.3
Summary|[5 Regression] ICE  |[5 Regression] ICE
   |compiling LTP testcase  |compiling LTP testcase,
   ||endless cselib recursion
   ||from var-tracking

--- Comment #1 from Richard Biener  ---
Delta-reduced (w/ includes):

#include 
double pi;
FILE *temp;
static int checkbuf(char *, int, int);
int main(int argc, char *argv[])
{
  register int i, j;
  char buf[100];
  for (i = 0; i < 30; i++)
for (j = 0; j < 30; j++)
  {
sprintf(buf, "%*.*f", i, j, pi);
if (checkbuf(buf, i, j)) {
}
  }
}
static int checkbuf(char *str, int n1, int n2)
{
  register int bd;
  /* before decimal point */register int ad;
  /* after decimal point */ register int tw;
  /* total width */ register int dp;
  /* decimal point */   char *buf;
  bd = ad = dp = 0;
  while (*str && *str != '.') {
  bd++;
  str++;
  }
  if (*str == '.') {
  dp++;
  str++;
  if (*str) {
  while (*str) {
  ad++;
  str++;
  }
  }
  }
  tw = bd + dp + ad;
  if (tw < n1) {
  fprintf(temp, "\tWidth too small.\n");
  return (-1);
  }
  if (ad != n2) {
  fprintf(temp, "\tn1 = %d, n2 = %d, buf= '%s'\n", n1, n2, buf);
  }
  return (0);
}


Program received signal SIGSEGV, Segmentation fault.
0x008a1732 in rtx_equal_for_cselib_1 (x=0x7687c810, 
y=0x7687c7f8, memmode=VOIDmode)
at /space/rguenther/src/svn/gcc-5-branch/gcc/cselib.c:1022
1022  && targetm.commutative_p (x, UNKNOWN)
Missing separate debuginfos, use: zypper install
libgmp10-debuginfo-6.0.0-71.1.x86_64 libisl13-debuginfo-0.14-25.2.x86_64
libmpc3-debuginfo-1.0.2-38.2.x86_64 libmpfr4-debuginfo-3.1.2-3.1.2.x86_64
(gdb) bt
#0  0x008a1732 in rtx_equal_for_cselib_1 (x=0x7687c810, 
y=0x7687c7f8, memmode=VOIDmode)
at /space/rguenther/src/svn/gcc-5-branch/gcc/cselib.c:1022
#1  0x008a12bf in rtx_equal_for_cselib_1 (x=0x7687c810, 
y=0x235e920, memmode=VOIDmode)
at /space/rguenther/src/svn/gcc-5-branch/gcc/cselib.c:924
#2  0x008a17dd in rtx_equal_for_cselib_1 (x=0x7687c7f8, 
y=0x7687c810, memmode=VOIDmode)
at /space/rguenther/src/svn/gcc-5-branch/gcc/cselib.c:1026
#3  0x008a1206 in rtx_equal_for_cselib_1 (x=0x235e920, 
y=0x7687c810, memmode=VOIDmode)
at /space/rguenther/src/svn/gcc-5-branch/gcc/cselib.c:907
... (endless recursion)

entered via

#59 0x008a1206 in rtx_equal_for_cselib_1 (x=0x235e938, 
y=0x7687c978, memmode=VOIDmode)
at /space/rguenther/src/svn/gcc-5-branch/gcc/cselib.c:907
#60 0x008a5b82 in cselib_hasher::equal (v=0x2294170, 
x_arg=0x7fffbef0)
at /space/rguenther/src/svn/gcc-5-branch/gcc/cselib.c:150
#61 0x008a5d42 in hash_table::find_slot_with_hash (this=0x22d53e0, comparable=0x7fffbef0,
hash=13065, 
insert=INSERT)
at /space/rguenther/src/svn/gcc-5-branch/gcc/hash-table.h:999
#62 0x008a0761 in cselib_find_slot (mode=SImode, x=0x7687c978, 
hash=13065, insert=INSERT, memmode=VOIDmode)
at /space/rguenther/src/svn/gcc-5-branch/gcc/cselib.c:600
#63 0x008a3b5f in cselib_lookup_1 (x=0x7687c978, mode=SImode, 
create=1, memmode=VOIDmode)
at /space/rguenther/src/svn/gcc-5-branch/gcc/cselib.c:2082
#64 0x008a3c71 in cselib_lookup (x=0x7687c978, mode=SImode, 
create=1, memmode=VOIDmode)
at /space/rguenther/src/svn/gcc-5-branch/gcc/cselib.c:2125
#65 0x008a478f in cselib_add_permanent_equiv (elt=0x2328960, 
x=0x7687c978, insn=0x768196c0)
at /space/rguenther/src/svn/gcc-5-branch/gcc/cselib.c:2427
#66 0x01099612 in reverse_op (val=0x235e938, expr=0x7681a6a8, 
insn=0x768196c0)
at /space/rguenther/src/svn/gcc-5-branch/gcc/var-tracking.c:5846
#67 0x0109a4b6 in add_stores (loc=0x7687c960, expr=0x7681a6a8, 
cuip=0x7fffc250)
---Type  to continue, or q  to quit---
at /space/rguenther/src/svn/gcc-5-branch/gcc/var-tracking.c:6114
#68 0x00cfb3b0 in note_stores (x=0x7681a6a8, 
fun=0x1099617 , data=0x7fffc250)
at /space/rguenther/src/svn/gcc-5-branch/gcc/rtlanal.c:1652
#69 0x00cfb3f7 in note_stores (x=0x7680b680, 
fun=0x1099617 , data=0x7fffc250)
at /space/rguenther/src/svn/gcc-5-branch/gcc/rtlanal.c:1657
#70 0x0109c929 in add_with_sets (insn=0x768196c0, 
sets=0x7fffc350, n_sets=1)
at /space/rguenther/src/svn/gcc-5-branch/gcc/var-tracking.c:6559
#71 0x008a4cf6 in cselib_rec

[Bug debug/67355] [5 Regression] ICE compiling LTP testcase, endless cselib recursion from var-tracking

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #2 from Markus Trippelsdorf  ---
I cannot reproduce this issue.

[Bug debug/67355] New: [5 Regression] ICE compiling LTP testcase

[rguenth at gcc dot gnu.org]

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

Bug ID: 67355
   Summary: [5 Regression] ICE compiling LTP testcase
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

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

> gcc-5 -S -O2 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables 
> -fasynchronous-unwind-tables atof01.c -m32 -g -B /abuild/rguenther/gcc5-g/gcc 
> -v 
Reading specs from /abuild/rguenther/gcc5-g/gcc/specs
COLLECT_GCC=gcc-5
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada,go
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/5
--enable-ssp --disable-libssp --disable-libvtv --enable-libmpx --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--with-default-libstdcxx-abi=gcc4-compatible
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-5 --without-system-libunwind
--enable-multilib --with-arch-32=i586 --with-tune=generic
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 5.1.1 20150707 [gcc-5-branch revision 225501] (SUSE Linux) 
COLLECT_GCC_OPTIONS='-S' '-O2' '-D' '_FORTIFY_SOURCE=2' '-fstack-protector'
'-funwind-tables' '-fasynchronous-unwind-tables' '-m32' '-g' '-B'
'/abuild/rguenther/gcc5-g/gcc' '-v' '-mtune=generic' '-march=i586'
 /abuild/rguenther/gcc5-g/gcc/cc1 -quiet -v -imultilib 32 -isystem
/abuild/rguenther/gcc5-g/gcc/include -isystem
/abuild/rguenther/gcc5-g/gcc/include-fixed -D _FORTIFY_SOURCE=2 atof01.c -quiet
-dumpbase atof01.c -m32 -mtune=generic -march=i586 -auxbase atof01 -g -O2
-version -fstack-protector -funwind-tables -fasynchronous-unwind-tables -o
atof01.s
GNU C11 (GCC) version 5.2.1 20150826 [gcc-5-branch revision 226027]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.4 20150327 [gcc-4_8-branch revision
221722], GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/usr/local/lib64/gcc/x86_64-unknown-linux-gnu/5.2.1/include"
ignoring nonexistent directory
"/usr/local/lib64/gcc/x86_64-unknown-linux-gnu/5.2.1/include-fixed"
ignoring nonexistent directory
"/usr/local/lib64/../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /abuild/rguenther/gcc5-g/gcc/include
 /abuild/rguenther/gcc5-g/gcc/include-fixed
 /usr/local/include
 /usr/include
End of search list.
GNU C11 (GCC) version 5.2.1 20150826 [gcc-5-branch revision 226027]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.4 20150327 [gcc-4_8-branch revision
221722], GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: eb89c9d8d76c5ea91abc0b0f9363b11c
gcc-5: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/67354] [5/6 regression] internal compiler error: in add_to_same_comdat_group, at symtab.c:421

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-26
 CC||trippels at gcc dot gnu.org
Summary|internal compiler error: in |[5/6 regression] internal
   |add_to_same_comdat_group,   |compiler error: in
   |at symtab.c:421 |add_to_same_comdat_group,
   ||at symtab.c:421
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 tmp % cat gccbug.ii
class A
{
};
template 
void
make_shared ()
{
  _Tp ();
}

class B : virtual A
{
public:
  template  B () {}
};
auto f = make_shared;

markus@x4 tmp % g++ -c -Os -std=gnu++11 gccbug.ii
gccbug.ii: In instantiation of ‘B::B() [with  = {}]’:
gccbug.ii:8:3:   required from ‘void make_shared() [with _Tp = B]’
gccbug.ii:16:10:   required from here
gccbug.ii:14:32: internal compiler error: in add_to_same_comdat_group, at
symtab.c:402
   template  B () {}
^
0x8ea7b8 symtab_node::add_to_same_comdat_group(symtab_node*)
../../gcc/gcc/symtab.c:402
0x798fb7 maybe_thunk_body
../../gcc/gcc/cp/optimize.c:286
0x799dc4 maybe_clone_body(tree_node*)
../../gcc/gcc/cp/optimize.c:508
0x7696b3 expand_or_defer_fn_1(tree_node*)
../../gcc/gcc/cp/semantics.c:4101
0x7698e8 expand_or_defer_fn(tree_node*)
../../gcc/gcc/cp/semantics.c:4124
0x632be6 instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:21181
0x677cc9 instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:21275
0x6b9ea4 c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4534
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/67219] [6 Regression] Incorrect conversion warning

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #3 from Joost VandeVondele  
---
It also depends on which value is used for 'huge_4', for example no warning
like so:

function foo(bar)
   integer(8) :: foo
   integer(4), intent(in) :: bar
   ! integer(4), parameter  :: huge_4 = huge(0_4)
   integer(4), parameter  :: huge_4 = 2**30
   foo = (huge_4 - int(bar,kind=8))
end function

there is also no valgrind warning for f951 compiling the testcase.

[Bug c++/67354] New: internal compiler error: in add_to_same_comdat_group, at symtab.c:421

[bgreen0 at gmail dot com]

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

Bug ID: 67354
   Summary: internal compiler error: in add_to_same_comdat_group,
at symtab.c:421
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bgreen0 at gmail dot com
  Target Milestone: ---

Created attachment 36255
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36255&action=edit
preprocessor output

The attached preprocessed code generates an internal compiler error when
compiled with the -Os option.  Tested with g++ 5.1 and 5.2.

Preprocessed file attached.

Here is the command line out output:

$ g++ -v -save-temps -std=gnu++11 -Wall -Wextra -Os -c -o gccbug.o gccbug.cpp 
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-5.2.0/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --with-default-libstdcxx-abi=gcc4-compatible
Thread model: posix
gcc version 5.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu++11' '-Wall' '-Wextra' '-Os'
'-c' '-o' 'gccbug.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1plus -E -quiet -v -D_GNU_SOURCE
gccbug.cpp -mtune=generic -march=x86-64 -std=gnu++11 -Wall -Wextra -Os
-fpch-preprocess -o gccbug.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0

/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0/x86_64-unknown-linux-gnu

/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0/backward
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu++11' '-Wall' '-Wextra' '-Os'
'-c' '-o' 'gccbug.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1plus -fpreprocessed gccbug.ii
-quiet -dumpbase gccbug.cpp -mtune=generic -march=x86-64 -auxbase-strip
gccbug.o -Os -Wall -Wextra -std=gnu++11 -version -o gccbug.s
GNU C++11 (GCC) version 5.2.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version
3.1.3-p4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++11 (GCC) version 5.2.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version
3.1.3-p4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 18422b8e6e00646fd4f8fbf484d27148
gccbug.cpp: In instantiation of ‘Test::Test(Args&& ...) [with Args = {}]’:
/usr/include/c++/5.2.0/ext/new_allocator.h:120:4:   required from ‘void
__gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up = Test;
_Args = {}; _Tp = Test]’
/usr/include/c++/5.2.0/bits/alloc_traits.h:256:4:   required from ‘static
std::_Require::__construct_helper<_Tp,
_Args>::type> std::allocator_traits<_Alloc>::_S_construct(_Alloc&, _Tp*,
_Args&& ...) [with _Tp = Test; _Args = {}; _Alloc = std::allocator;
std::_Require::__construct_helper<_Tp,
_Args>::type> = void]’
/usr/include/c++/5.2.0/bits/alloc_traits.h:402:16:   required from ‘static
decltype (_S_construct(__a, __p,
(forward<_Args>)(std::allocator_traits::construct::__args)...))
std::allocator_traits<_Alloc>::construct(_Alloc&, _Tp*, _Args&& ...) [with _Tp
= Test; _Args = {}; _Alloc = std::allocator; decltype (_S_construct(__a,
__p, (forward<_Args>)(std::allocator_traits::construct::__args)...)) = ]’
/usr/include/c++/5.2.0/bits/shared_ptr_base.h:522:39:   required from
‘std::_Sp_counted_ptr_inplace<_Tp, _Alloc,
_Lp>::_Sp_counted_ptr_inplace(_Alloc, _Args&& ...) [with _Args = {}; _Tp =
Test; _Alloc = std::allocator; __gnu_cxx::_Lock_policy _Lp =
(__gnu_cxx::_Lock_policy)2u]’
/usr/include/c++/5.2.0/bits/shared_ptr_base.h:617:4:   required from
‘std::__shared_count<_Lp>::__shared_count(std::_Sp_make_shared_tag, _Tp*, const
_Alloc&, _Args&& ...) [with _Tp = Test; _Alloc = std::al

[Bug middle-end/63510] Wrong line number in Wstrict-overflow message

[gang.chen.5i5j at gmail dot com]

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

--- Comment #8 from Chen Gang  ---
For the latest gcc, it still has this issue, I shall try to fix it during these
days (hope can fix it within this month).

Thanks.

[Bug middle-end/67330] ICE handling weak attributes

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug middle-end/67330] ICE handling weak attributes

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Tue Aug 25 20:28:59 2015
New Revision: 227190

URL: https://gcc.gnu.org/viewcvs?rev=227190&root=gcc&view=rev
Log:
PR middle-end/67330
* varasm.c (declare_weak): Return after giving an error.

* c-common.c (handle_weak_attribute): Don't check whether the
visibility can be changed here.

* gcc.dg/weak/weak-18.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/weak/weak-18.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug libstdc++/60519] Debug mode should check comparators for irreflexivity

[fdumont at gcc dot gnu.org]

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

--- Comment #5 from François Dumont  ---
Author: fdumont
Date: Tue Aug 25 20:27:03 2015
New Revision: 227189

URL: https://gcc.gnu.org/viewcvs?rev=227189&root=gcc&view=rev
Log:
2015-08-24  François Dumont  

PR libstdc++/60519
* include/debug/formatter.h
(_Debug_msg_id::__msg_irreflexive_ordering):
New enum entry.
* include/debug/functions.h (_Irreflexive_checker): New.
(__is_irreflexive, __is_irreflexive_pred): New.
* include/debug/macros.h
(__glibcxx_check_irreflexive, __glibcxx_check_irreflexive_pred): New
macros.
(__glibcxx_check_irreflexive2, __glibcxx_check_irreflexive_pred2): New
macros limited to post-C++11 mode.
* include/debug/debug.h
(__glibcxx_requires_irreflexive, __glibcxx_requires_irreflexive_pred):
New macros, use latter.
(__glibcxx_requires_irreflexive2,
__glibcxx_requires_irreflexive_pred2):
Likewise.
* include/bits/stl_algo.h
(partial_sort_copy): Add irreflexive debug check.
(partial_sort_copy): Likewise.
(lower_bound): Likewise.
(upper_bound): Likewise.
(equal_range): Likewise.
(binary_search): Likewise.
(inplace_merge): Likewise.
(includes): Likewise.
(next_permutation): Likewise.
(prev_permutation): Likewise.
(is_sorted_until): Likewise.
(minmax_element): Likewise.
(partial_sort): Likewise.
(nth_element): Likewise.
(sort): Likewise.
(merge): Likewise.
(stable_sort): Likewise.
(set_union): Likewise.
(set_intersection): Likewise.
(set_difference): Likewise.
(set_symmetric_difference): Likewise.
(min_element): Likewise.
(max_element): Likewise.
* include/bits/stl_algobase.h
(lower_bound): Likewise.
(lexicographical_compare): Likewise.
* include/bits/stl_heap.h
(push_heap): Likewise.
(pop_heap): Likewise.
(make_heap): Likewise.
(sort_heap): Likewise.
(is_heap_until): Likewise.
* testsuite/25_algorithms/lexicographical_compare/debug/
irreflexive_neg.cc: New.
* testsuite/25_algorithms/lower_bound/debug/irreflexive.cc: New.
* testsuite/25_algorithms/partial_sort_copy/debug/irreflexive_neg.cc:
New.

Added:
trunk/libstdc++-v3/testsuite/25_algorithms/lexicographical_compare/debug/
   
trunk/libstdc++-v3/testsuite/25_algorithms/lexicographical_compare/debug/irreflexive_neg.cc
trunk/libstdc++-v3/testsuite/25_algorithms/lower_bound/debug/
trunk/libstdc++-v3/testsuite/25_algorithms/lower_bound/debug/irreflexive.cc
trunk/libstdc++-v3/testsuite/25_algorithms/partial_sort_copy/debug/
   
trunk/libstdc++-v3/testsuite/25_algorithms/partial_sort_copy/debug/irreflexive_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_algo.h
trunk/libstdc++-v3/include/bits/stl_algobase.h
trunk/libstdc++-v3/include/bits/stl_heap.h
trunk/libstdc++-v3/include/debug/debug.h
trunk/libstdc++-v3/include/debug/formatter.h
trunk/libstdc++-v3/include/debug/functions.h
trunk/libstdc++-v3/include/debug/macros.h
trunk/libstdc++-v3/src/c++11/debug.cc

[Bug target/67346] PowerPC: could not split insn

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #4 from Segher Boessenkool  ---
Fixed.  Thanks for the report, these csmith tests pick out things
nothing else does :-)

[Bug middle-end/67341] [ICE] libgo build failure: in mark_stmt_if_obviously_necessary, at tree-ssa-dce.c:278

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
Thanks.

[Bug middle-end/67341] [ICE] libgo build failure: in mark_stmt_if_obviously_necessary, at tree-ssa-dce.c:278

[gary at intrepid dot com]

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

--- Comment #3 from Gary Funck  ---
(In reply to Marek Polacek from comment #2)
> Gary, could you please try this again?  I'd hope this has really been fixed
> with my recentish Go patch.

Confirmed - fixed.

[Bug target/67344] PowerPC unrecognizable insn

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

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

[Bug target/67346] PowerPC: could not split insn

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Author: segher
Date: Tue Aug 25 19:35:15 2015
New Revision: 227183

URL: https://gcc.gnu.org/viewcvs?rev=227183&root=gcc&view=rev
Log:
rs6000: Fix PR67346

"*ior_mask" is a define_insn_and_split, so it shouldn't use
can_create_pseudo in its instruction condition, because IRA can then
create such an instruction, and the condition becomes false before
the insn is split.  Use a scratch instead.


2015-08-25  Segher Boessenkool  

PR target/67346
* config/rs6000/rs6000.md (*ior_mask): Use a match_scratch.

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

[Bug target/67344] PowerPC unrecognizable insn

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Author: segher
Date: Tue Aug 25 19:32:28 2015
New Revision: 227182

URL: https://gcc.gnu.org/viewcvs?rev=227182&root=gcc&view=rev
Log:
rs6000: Fix PR67344

The "*and3_imm_dot_shifted" pattern is a define_insn_and_split,
like most "dot" patterns: if its output is not assigned cr0 but some
other cr reg, it splits to a non-dot insn and a compare.

Unfortunately that non-dot insn will clobber cr0 as well.  We could
add another clobber (with "=X,x"), but then that second alternative
is never useful; instead, just remove that second alternative.


2015-08-25  Segher Boessenkool  

PR target/67344
* config/rs6000/rs6000.md (*and3_imm_dot_shifted): Change to
a define_insn, remove second alternative.

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

[Bug target/67353] [avr] Option-ize Warning "appears to be a misspelled signal / interrupt handler"

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-08-25
   Target Milestone|--- |6.0
 Ever confirmed|0   |1
   Severity|normal  |enhancement

[Bug target/67353] New: [avr] Option-ize Warning "appears to be a misspelled signal / interrupt handler"

[gjl at gcc dot gnu.org]

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

Bug ID: 67353
   Summary: [avr] Option-ize Warning "appears to be a misspelled
signal / interrupt handler"
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: target
  Assignee: gjl at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---
Target: avr

Add -W flag to control the mentioned warning or turn it into an error.

[Bug target/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Combine can handle most RTL expressions, although it sometimes
simplifies (or "simplifies") more than you want.

I think in this case what is already done in *add3_cc_overflow
will work well, but I do not know x86 CC modes terribly well.  You'll
need to experiment a bit to find something that works well in all
interesting cases.

[Bug target/67352] [avr] incorrect warning with -Waddr-space-convert and array in struct in __flash

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-08-25
 Ever confirmed|0   |1

[Bug target/67352] [avr] incorrect warning with -Waddr-space-convert and array in struct in __flash

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |6.0

[Bug target/67352] New: [avr] incorrect warning with -Waddr-space-convert and array in struct in __flash

[gjl at gcc dot gnu.org]

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

Bug ID: 67352
   Summary: [avr] incorrect warning with -Waddr-space-convert and
array in struct in __flash
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Keywords: addr-space, diagnostic
  Severity: normal
  Priority: P3
 Component: target
  Assignee: gjl at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---
Target: avr

== C source ==

typedef struct
{
char a, b[3];
} S;

const __flash char* get_b1 (const __flash S *s)
{
   return s->b;
}

extern const __flash S ab;

const __flash char* get_b2 (void)
{
   return ab.b;
}

== Command line ==

$ avr-gcc -mmcu=atmega8 main.c -Werror=addr-space-convert -fsyntax-only


== avr-gcc Output ==

main.c: In function 'get_b1':
main.c:8:4: error: conversion from address space 'generic' to address space
'__flash' [-Werror=addr-space-convert]

main.c: In function 'get_b2':
main.c:15:4: error: conversion from address space 'generic' to address space
'__flash' [-Werror=addr-space-convert]

[Bug target/67351] Missed optimisation on 64-bit field compared to 32-bit

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
Oh his patch only handled multiplies/divide and not shifts.  But it should be
easy to add them to match.pd to simplify this at the tree level.

[Bug target/67351] Missed optimisation on 64-bit field compared to 32-bit

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Uroš Bizjak from comment #2)
> > (In reply to Allan Jensen from comment #0)
> > 
> > > Gcc will expand and detect field setting on 32-bit integers, but for some
> > > reason miss the opportunity on 64-bit.
> > 
> > The immediates for 64bit logic insns are limited to sign-extended 32bit
> > values, so this probably limits combine to combine several insns into one.
> 
> One example is:
> 
> (insn 8 6 9 2 (parallel [
> (set (reg:DI 100)
> (lshiftrt:DI (reg/v:DI 98 [ a ])
> (const_int 48 [0x30])))
> (clobber (reg:CC 17 flags))
> ]) test.cpp:63 538 {*lshrdi3_1}
>  (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil)))
> (insn 9 8 10 2 (parallel [
> (set (reg:DI 101)
> (ashift:DI (reg:DI 100)
> (const_int 48 [0x30])))
> (clobber (reg:CC 17 flags))
> ]) test.cpp:63 504 {*ashldi3_1}
>  (expr_list:REG_DEAD (reg:DI 100)
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil
> 
> combine tries to:
> 
> Trying 8 -> 9:
> Failed to match this instruction:
> (parallel [
> (set (reg:DI 101)
> (and:DI (reg/v:DI 98 [ a ])
> (const_int -281474976710656 [0x])))
> (clobber (reg:CC 17 flags))
> ])
> 
> However, tree optimizers pass to expand the following sequence:
> 
>   a = giveMe64 ();
>   a$rgba_5 = MEM[(struct MyRgba64 *)&a];
>   _6 = a$rgba_5 >> 16;
>   _7 = a$rgba_5 >> 48;
>   _8 = _7 << 48;
>   _10 = _6 << 16;
>   _11 = _10 & 4294967295;
>   _13 = a$rgba_5 & 65535;
>   _15 = _13 | 264913582817280;
>   _16 = _8 | _15;
>   _14 = _11 | _16;
>   MEM[(struct MyRgba64 *)&D.2451] = _14;
>   return D.2451;
> 
> Richi, can these shifts be converted to equivalent masking in tree
> optimizers?


They should be or at least Naveen's patches should handle them.  There is an
open bug filed doing a >> N << N and one filed for a << N >> N already (I filed
it).

[Bug target/67351] Missed optimisation on 64-bit field compared to 32-bit

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org,
   ||ubizjak at gmail dot com

--- Comment #3 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #2)
> (In reply to Allan Jensen from comment #0)
> 
> > Gcc will expand and detect field setting on 32-bit integers, but for some
> > reason miss the opportunity on 64-bit.
> 
> The immediates for 64bit logic insns are limited to sign-extended 32bit
> values, so this probably limits combine to combine several insns into one.

One example is:

(insn 8 6 9 2 (parallel [
(set (reg:DI 100)
(lshiftrt:DI (reg/v:DI 98 [ a ])
(const_int 48 [0x30])))
(clobber (reg:CC 17 flags))
]) test.cpp:63 538 {*lshrdi3_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 9 8 10 2 (parallel [
(set (reg:DI 101)
(ashift:DI (reg:DI 100)
(const_int 48 [0x30])))
(clobber (reg:CC 17 flags))
]) test.cpp:63 504 {*ashldi3_1}
 (expr_list:REG_DEAD (reg:DI 100)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil

combine tries to:

Trying 8 -> 9:
Failed to match this instruction:
(parallel [
(set (reg:DI 101)
(and:DI (reg/v:DI 98 [ a ])
(const_int -281474976710656 [0x])))
(clobber (reg:CC 17 flags))
])

However, tree optimizers pass to expand the following sequence:

  a = giveMe64 ();
  a$rgba_5 = MEM[(struct MyRgba64 *)&a];
  _6 = a$rgba_5 >> 16;
  _7 = a$rgba_5 >> 48;
  _8 = _7 << 48;
  _10 = _6 << 16;
  _11 = _10 & 4294967295;
  _13 = a$rgba_5 & 65535;
  _15 = _13 | 264913582817280;
  _16 = _8 | _15;
  _14 = _11 | _16;
  MEM[(struct MyRgba64 *)&D.2451] = _14;
  return D.2451;

Richi, can these shifts be converted to equivalent masking in tree optimizers?

[Bug target/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64

[ubizjak at gmail dot com]

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

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

> Does this need to be an unspec at all?

Of course not. We are looking to replace unspecs with standard RTXes. Do you
have any recommendation on how we can represent this carry-setting insn to
satisfy combine?

[Bug middle-end/64544] ../../gcc-svn/gcc/cgraphunit.c:2183:1: internal compiler error: in check_probability, at basic-block.h:581

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Should be fixed.  If not, please reopen and be sure to add a preprocessed
source file.

[Bug target/67351] Missed optimisation on 64-bit field compared to 32-bit

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Allan Jensen from comment #0)

> Gcc will expand and detect field setting on 32-bit integers, but for some
> reason miss the opportunity on 64-bit.

The immediates for 64bit logic insns are limited to sign-extended 32bit values,
so this probably limits combine to combine several insns into one.

[Bug target/67296] [HSA] ICE in register allocator (assignment of this argument in a ctor)

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

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

--- Comment #2 from Michael Matz  ---
Fixed more completely than for PR 67272, so the fix for that one is superseded
as well.

[Bug target/67296] [HSA] ICE in register allocator (assignment of this argument in a ctor)

[matz at gcc dot gnu.org]

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

--- Comment #1 from Michael Matz  ---
Author: matz
Date: Tue Aug 25 16:02:38 2015
New Revision: 227176

URL: https://gcc.gnu.org/viewcvs?rev=227176&root=gcc&view=rev
Log:
PR target/67272
PR target/67296
* hsa.h (hsa_function_representation): Remove prologue member.
* hsa-dump.c (dump_hsa_cfun): Iterator over all BBs.
* hsa-gen.c (hsa_function_representation): Don't init prologue,
start with zero bbs.
(hsa_function_representation::get_shadow_reg): Use entry block,
not prologue member.
(hsa_init_data_for_cfun): Create hsa_bb for entry/exit blocks.
(hsa_deinit_data_for_cfun): Deallocate also for entry/exit blocks.
(gen_hsa_insns_for_kernel_call): Don't use UINT64_MAX, but
the built-in max value of the type.
(gen_function_def_parameters): Don't use prologue member, but
the hsa bb for entry bb.
(wrap_all_hsa_calls): Iterate over all BBs.
* hsa-regalloc.c (naive_process_phi): Revert 2015-08-19 change.
(naive_outof_ssa): Iterate over all BBs.
(dump_hsa_cfun_regalloc): Ditto.
(linear_scan_regalloc): Ditto.
(regalloc): Ditto.

Modified:
branches/hsa/gcc/ChangeLog.hsa
branches/hsa/gcc/hsa-dump.c
branches/hsa/gcc/hsa-gen.c
branches/hsa/gcc/hsa-regalloc.c
branches/hsa/gcc/hsa.h

[Bug target/67272] [HSA] register allocator expects that every register must be assigned

[matz at gcc dot gnu.org]

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

--- Comment #5 from Michael Matz  ---
Author: matz
Date: Tue Aug 25 16:02:38 2015
New Revision: 227176

URL: https://gcc.gnu.org/viewcvs?rev=227176&root=gcc&view=rev
Log:
PR target/67272
PR target/67296
* hsa.h (hsa_function_representation): Remove prologue member.
* hsa-dump.c (dump_hsa_cfun): Iterator over all BBs.
* hsa-gen.c (hsa_function_representation): Don't init prologue,
start with zero bbs.
(hsa_function_representation::get_shadow_reg): Use entry block,
not prologue member.
(hsa_init_data_for_cfun): Create hsa_bb for entry/exit blocks.
(hsa_deinit_data_for_cfun): Deallocate also for entry/exit blocks.
(gen_hsa_insns_for_kernel_call): Don't use UINT64_MAX, but
the built-in max value of the type.
(gen_function_def_parameters): Don't use prologue member, but
the hsa bb for entry bb.
(wrap_all_hsa_calls): Iterate over all BBs.
* hsa-regalloc.c (naive_process_phi): Revert 2015-08-19 change.
(naive_outof_ssa): Iterate over all BBs.
(dump_hsa_cfun_regalloc): Ditto.
(linear_scan_regalloc): Ditto.
(regalloc): Ditto.

Modified:
branches/hsa/gcc/ChangeLog.hsa
branches/hsa/gcc/hsa-dump.c
branches/hsa/gcc/hsa-gen.c
branches/hsa/gcc/hsa-regalloc.c
branches/hsa/gcc/hsa.h

[Bug middle-end/67351] New: Missed optimisation on 64-bit field compared to 32-bit

[linux at carewolf dot com]

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

Bug ID: 67351
   Summary: Missed optimisation on 64-bit field compared to 32-bit
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linux at carewolf dot com
  Target Milestone: ---

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

Gcc will expand and detect field setting on 32-bit integers, but for some
reason miss the opportunity on 64-bit.

This was discovered as gcc was inexplicably slower compared to clang on the
64-bit case but not when using 32bit.

[Bug middle-end/67351] Missed optimisation on 64-bit field compared to 32-bit

[linux at carewolf dot com]

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

--- Comment #1 from Allan Jensen  ---
Created attachment 36254
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36254&action=edit
Compiled test assembler

[Bug middle-end/67330] ICE handling weak attributes

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Let me see what others think.

[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
(In reply to Marek Polacek from comment #6)
> Hm, adding || (e2->flags & EDGE_IRREDUCIBLE_LOOP) doesn't work; the E2 edge
> doesn't have the EDGE_IRREDUCIBLE_LOOP flag, even if I recompute that flag
> via mark_irreducible_loops.  So maybe set LOOPS_NEED_FIXUP every time we
> remove an edge?

I did some measurements on a GCC regtest.  The edge removal was triggered
~13000 times, but for only ~4000 out of that was "loop_exit_edge_p
(bb->loop_father, e)" true -- setting LOOPS_NEED_FIXUP unconditionally would be
maybe too expensive thus.

[Bug tree-optimization/66372] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
This seems to be fixed now.

[Bug tree-optimization/67253] [6 Regression] ICE at -O3 on x86_64-linux-gnu (verify_gimple failed)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r222360.

[Bug tree-optimization/67328] range test rather than single bit test for code testing enum values

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Alan Modra  ---
Maybe adding #if ALT only confused the issue.  For -UALT -O1 on x86_64 I get

test_pic:
testb   $1, (%rdi)
je  .L1
addl$1, result(%rip)
.L1:
rep ret

test_exe:
movzbl  (%rdi), %eax
andl$3, %eax
cmpb$1, %al
ja  .L3
addl$1, result(%rip)
.L3:
rep ret

For test_exe I would like to see the following equivalent and better optimised
code.

test_exe:
testb   $2, (%rdi)
jne .L3
addl$1, result(%rip)
.L3:
rep ret

The optimisation to a bit test for test_pic happens in reassoc1, or at least
that's where the process starts.

[Bug libfortran/48511] Implement Steele-White algorithm for numeric output

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #14 from Francois-Xavier Coudert  ---
Seeing the PR track, it seems both Janne and Jerry are against reimplementing
Steele-White. I am too: unless we can show very good features or speed
improvement, we'd best do exactly what we do now, i.e. use the system's libc
(and possibly libquadmath). So I am closing this PR as WONTFIX.


In any case, if we wanted to have faster floating-point I/O, we should move to
something more modern than Steele-White. The current "state of the art" (as
implemented in new language runtimes, such as Julia, rust, modern javascript,
etc.) is to combine grisu3
(http://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf) with
dragon4 (Steele-White) as a fall-back for the cases where grisu3 doesn't round
exactly.

[Bug target/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #3 from Segher Boessenkool  ---
These things would normally be taken care of by combine, but
combine of course does not know what the UNSPEC_ADD_CARRY's mean.
Does this need to be an unspec at all?

[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Hm, adding || (e2->flags & EDGE_IRREDUCIBLE_LOOP) doesn't work; the E2 edge
doesn't have the EDGE_IRREDUCIBLE_LOOP flag, even if I recompute that flag via
mark_irreducible_loops.  So maybe set LOOPS_NEED_FIXUP every time we remove an
edge?

FTR, the CFG looks like

f ()
{
  int a.0_4;
  int a.0_7;

  :
  a.0_4 = a;
  if (a.0_4 == 0)
goto  (lbl);
  else
goto ;

lbl:

  :
  a.0_7 = a;
  if (a.0_7 != 0)
goto ;
  else
goto  (lbl);

  :
  a = 8;
  goto  (lbl);

}

so the 2 -> 4 and 2 -> 3 edges are multiple entries of a loop -- why aren't
they EDGE_IRREDUCIBLE_LOOP?

[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |mpolacek at gcc dot 
gnu.org

--- Comment #5 from Marek Polacek  ---
Taking this over for now.

[Bug middle-end/67341] [ICE] libgo build failure: in mark_stmt_if_obviously_necessary, at tree-ssa-dce.c:278

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-08-25
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Gary, could you please try this again?  I'd hope this has really been fixed
with my recentish Go patch.

[Bug rtl-optimization/10837] noreturn attribute causes no sibling calling optimization

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
(In reply to Richard Henderson from comment #2)
> Working as designed.
> (1) It often takes more insns to pop the stack frame than to make the call.
> (2) You get a proper backtrace from abort.
> (3) http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00180.html

Glibc has been using

ENTRY (__memmove_chk)
movl12(%esp), %eax
cmpl%eax, 16(%esp)
jb  __chk_fail
jmp memmove
END (__memmove_chk)

since 2004. #1 and #2 shouldn't be the reason not to optimize.  I
am using:

/* Due to
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837
   noreturn attribute disable tail call optimization.  Removes noreturn
   attribute to enable tail call optimization.  */
extern void *chk_fail (void) __asm__ ("__chk_fail") attribute_hidden;

to work around this.

[Bug target/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*
 Status|WAITING |NEW
  Component|inline-asm  |target

--- Comment #2 from Marc Glisse  ---
Self-contained:

typedef unsigned long long u64;
u64 testcarry(u64 a, u64 b, u64 c, u64 d)
{
  u64 result0, result1;
  __builtin_ia32_addcarryx_u64(__builtin_ia32_addcarryx_u64(0, a, c, &result0),
b, d, &result1);
  return result0 ^ result1;
}

[Bug tree-optimization/67306] Patterns ICEs when moved using "simplify and match"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/67306] Patterns ICEs when moved using "simplify and match"

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Aug 25 10:29:09 2015
New Revision: 227163

URL: https://gcc.gnu.org/viewcvs?rev=227163&root=gcc&view=rev
Log:
2015-08-25  Richard Biener  

PR middle-end/67306
* genmatch.c (expr::gen_transform): Verify the result of
builtin_decl_implicit.
(dt_simplify::gen_1): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/genmatch.c

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

[michael.collison at linaro dot org]

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

--- Comment #4 from Michael Collison  ---
Hi Richard,

No I do not have a fix now. Thanks for the info on the policy.

On 08/25/2015 03:05 AM, rguenther at suse dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67323
>
> --- Comment #3 from rguenther at suse dot de  ---
> On Tue, 25 Aug 2015, michael.collison at linaro dot org wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67323
>>
>> --- Comment #2 from Michael Collison  ---
>> Richard,
>>
>> Should I create a test case that fails until you resolve this in GCC 6?
> If you can provide one that I can check in together with a fix that
> would be nice.  Having it in the tree now and FAILing isn't according
> to our policies.
>
>> On 08/25/2015 02:14 AM, rguenth at gcc dot gnu.org wrote:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67323
>>>
>>> Richard Biener  changed:
>>>
>>>  What|Removed |Added
>>> 
>>>Status|UNCONFIRMED |ASSIGNED
>>>  Last reconfirmed||2015-08-25
>>>CC|richard.guenther at gmail dot com  |rguenth at gcc 
>>> dot gnu.org
>>>Depends on||66721
>>>  Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc 
>>> dot gnu.org
>>>Ever confirmed|0   |1
>>>
>>> --- Comment #1 from Richard Biener  ---
>>> Confirmed.  We go down the SLP path here because the vectorizer thinks that
>>> SLP is always cheaper than using interleaving (which generally is true
>>> if there were not targets which can do the load plus interleave with
>>> load-lanes ...).
>>>
>>> I think this may be a regression as well because I enhanced SLP to apply
>>> to way more cases.
>>>
>>> Note that my plan is to make the vectorizer consider both (well, not really,
>>> but this bug shows I maybe should try), SLP and non-SLP, and evaluate based
>>> on costs which route to go.
>>>
>>>
>>> Referenced Bugs:
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66721
>>> [Bug 66721] [6 regression] gcc.target/i386/pr61403.c FAILs
>>

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

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Tue, 25 Aug 2015, michael.collison at linaro dot org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67323
> 
> --- Comment #2 from Michael Collison  ---
> Richard,
> 
> Should I create a test case that fails until you resolve this in GCC 6?

If you can provide one that I can check in together with a fix that
would be nice.  Having it in the tree now and FAILing isn't according
to our policies.

> On 08/25/2015 02:14 AM, rguenth at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67323
> >
> > Richard Biener  changed:
> >
> > What|Removed |Added
> > 
> >   Status|UNCONFIRMED |ASSIGNED
> > Last reconfirmed||2015-08-25
> >   CC|richard.guenther at gmail dot com  |rguenth at gcc dot 
> > gnu.org
> >   Depends on||66721
> > Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
> > gnu.org
> >   Ever confirmed|0   |1
> >
> > --- Comment #1 from Richard Biener  ---
> > Confirmed.  We go down the SLP path here because the vectorizer thinks that
> > SLP is always cheaper than using interleaving (which generally is true
> > if there were not targets which can do the load plus interleave with
> > load-lanes ...).
> >
> > I think this may be a regression as well because I enhanced SLP to apply
> > to way more cases.
> >
> > Note that my plan is to make the vectorizer consider both (well, not really,
> > but this bug shows I maybe should try), SLP and non-SLP, and evaluate based
> > on costs which route to go.
> >
> >
> > Referenced Bugs:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66721
> > [Bug 66721] [6 regression] gcc.target/i386/pr61403.c FAILs
> 
>

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

[michael.collison at linaro dot org]

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

--- Comment #2 from Michael Collison  ---
Richard,

Should I create a test case that fails until you resolve this in GCC 6?

On 08/25/2015 02:14 AM, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67323
>
> Richard Biener  changed:
>
> What|Removed |Added
> 
>   Status|UNCONFIRMED |ASSIGNED
> Last reconfirmed||2015-08-25
>   CC|richard.guenther at gmail dot com  |rguenth at gcc dot 
> gnu.org
>   Depends on||66721
> Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
> gnu.org
>   Ever confirmed|0   |1
>
> --- Comment #1 from Richard Biener  ---
> Confirmed.  We go down the SLP path here because the vectorizer thinks that
> SLP is always cheaper than using interleaving (which generally is true
> if there were not targets which can do the load plus interleave with
> load-lanes ...).
>
> I think this may be a regression as well because I enhanced SLP to apply
> to way more cases.
>
> Note that my plan is to make the vectorizer consider both (well, not really,
> but this bug shows I maybe should try), SLP and non-SLP, and evaluate based
> on costs which route to go.
>
>
> Referenced Bugs:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66721
> [Bug 66721] [6 regression] gcc.target/i386/pr61403.c FAILs

[Bug c++/67345] -Woverloaded-virtual false negative: Does not warn on overloaded virtual function

[EisahLee at gmx dot de]

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

--- Comment #2 from EisahLee at gmx dot de ---
I see the hiding as a potential "design error", or however that is called: A
shortcoming of the way the methods were named.

Clang 4.5 does not warn until there is such a "bad" call.

Is there a compiler + flag combination that can provide such a warning?

[Bug tree-optimization/67326] [5/6 Regression] -ftree-loop-if-convert-stores does not vectorize conditional assignment (anymore)

[vekumar at gcc dot gnu.org]

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

vekumar at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vekumar at gcc dot gnu.org

--- Comment #2 from vekumar at gcc dot gnu.org ---
Hi Richard,

As a first step I am trying to allow if conversion to happen under
-ftree-loop-if-convert-stores for cases where we know it is already accessed
(read) outside unconditionally once and also the memory access is read and
write. 

 __attribute__((aligned(32))) float a[LEN]; void 
 test() { for (int i = 0; i < LEN; i++) {
if (a[i] > (float)0.) { //<== Already read here unconditionally 
 a[i] =3 ;  //<== if we now it is read and write memory access
we can allow if conversion.
} 

As you said the cases in PR we need to enhance if-conversion pass to do bounds
checking the array "a" accessing using values of i.

[Bug testsuite/67203] [6 regression] FAIL: g++.dg/tree-ssa/pr61034.C -std=gnu++11 scan-tree-dump-times fre2 "free" 10

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Bah, so this boils down to PUSH_ARGS_REVERSED and its affect on gimplification
and thus initial GIMPLE.  In this case PUSH_ARGS_REVERSED == 1 "wins".
(for the operator- calls code for b * c and c * d is emitted first)

So we could add an effective target push_args_reversed ... iff that's easy
enough to fill-in.  Or explicitely add target matches.  Or spend more
time on trying to analyze why order matters for SCCVN here (it's all about
->count CSE).

[Bug c++/67315] [4.9 Regression] Strange 'this' pointer behavior when calling virtual function with different optimization attributes.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
This is hard to bisect, because checking compilers ICE on it, which got fixed
only in r217737 (and introduced in r202187).

[Bug c++/67350] New: auto deduction error in variable template lambda

[norbert.pfeiler+gcc.gnu.org/bugzilla at gmail dot com]

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

Bug ID: 67350
   Summary: auto deduction error in variable template lambda
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: norbert.pfeiler+gcc.gnu.org/bugzilla at gmail dot com
  Target Milestone: ---

template
auto test = [](){
return T{};
};

int main() {
test();
}

error: use of 'test' before deduction of 'auto'

Clang 3.6.2 accepts…

I’m not exactly sure this code is valid, but i can’t find much about variable
templates and lambdas.

[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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-08-25
 CC|richard.guenther at gmail dot com  |rguenth at gcc dot 
gnu.org
 Depends on||66721
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  We go down the SLP path here because the vectorizer thinks that
SLP is always cheaper than using interleaving (which generally is true
if there were not targets which can do the load plus interleave with
load-lanes ...).

I think this may be a regression as well because I enhanced SLP to apply
to way more cases.

Note that my plan is to make the vectorizer consider both (well, not really,
but this bug shows I maybe should try), SLP and non-SLP, and evaluate based
on costs which route to go.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66721
[Bug 66721] [6 regression] gcc.target/i386/pr61403.c FAILs

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

[rguenther at suse dot de]

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

--- Comment #28 from rguenther at suse dot de  ---
On Tue, 25 Aug 2015, kumba at gentoo dot org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
> 
> --- Comment #27 from Joshua Kinard  ---
> (In reply to Richard Biener from comment #26)
> > Don't hold your breath.  Basically somebody who can reproduce it has to find
> > the root-cause and a fix.
> 
> 4.9.3 works, and the problem appears specific to genmatch with the '--gimple'
> argument.  I guess I can test to see if 5.0.0 is also affected, and then start
> diffing the genmatch.c files between working/non-working version to trace the
> problem down.  That will be quicker than git bisecting on these machines (old
> SGI machines).  Can't stay stuck on 4.9.x forever...

Can you also nail the issue down to using --disable-checking?  For the
powerpc case I think we run into a miscompile of stage2 and thus
genmatch.c is really only the trigger and wouldn't be the place for
a fix (well, maybe a workaround is fine for the GCC 5 branch here)

[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Note we already do

/* If we made a BB unconditionally exit a loop then this
   transform alters the set of BBs in the loop.  Schedule
   a fixup.  */
if (loop_exit_edge_p (bb->loop_father, e))
  loops_state_set (LOOPS_NEED_FIXUP);
remove_edge (e2);

thus this would need to add sth like || e2->flags & IRREDUCIBLE_LOOP

[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Yeah, though "somewhere" would be all the time if we and up removing an edge.
I've meant to see whether we can restrict it to "removed an edge with
IRREDUCIBLE_LOOP flag set, but then we'd have to compute that first and we
only do that for 'aggressive' aka CDDCE.

Didn't get around to play with that ;)  (note the ICE appears after CDDCE
only, but I would need to convince myself that regular DCE can't trigger
the same issue - I think it can't)

[Bug middle-end/66984] ICE: fold_binary changes type of operand, causing failure in verify_gimple_assign_binary

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #8 from Marek Polacek  ---
Assuming fixed then.

[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 #27 from Joshua Kinard  ---
(In reply to Richard Biener from comment #26)
> Don't hold your breath.  Basically somebody who can reproduce it has to find
> the root-cause and a fix.

4.9.3 works, and the problem appears specific to genmatch with the '--gimple'
argument.  I guess I can test to see if 5.0.0 is also affected, and then start
diffing the genmatch.c files between working/non-working version to trace the
problem down.  That will be quicker than git bisecting on these machines (old
SGI machines).  Can't stay stuck on 4.9.x forever...

[Bug middle-end/67005] [5/6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Still ICEs; probably it's just about adding loops_state_set (LOOPS_NEED_FIXUP);
somewhere into tree-ssa-dce.c?

[Bug c++/67315] [4.9 Regression] Strange 'this' pointer behavior when calling virtual function with different optimization attributes.

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
PR 54068 ?

[Bug debug/67293] Very large DW_AT_const_value produced

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #2)
> I'm fine with introducing some limit on the size of const values, with a
> param.
> As for the other question, I think you've answered that yourself,
> if the const ends up in the source, then that is supposedly because
> something needed its address.  At that point it is much better to be able to
> print that address in the debugger.
> If you want to stream DW_AT_const_value early and actually rewrite the DWARF
> during LTO later, rather than just reference unmodified DIEs from other
> DIEs, then you could if you end up having an address actually remove the
> DW_AT_const_value and replace it with DW_AT_location if possible.

A DWARF optimizer could do this indeed.  With the current laid out scheme
for LTO debug we will add a DW_AT_location late if the object is instantiated
thus the debugger will see both.  But I will have to pro-actively add
the DW_AT_const_value early in case the object doesn't get emitted - but
I definitely want to limit the size of the eventually pointless DWARF.

I can do the re-writing (remove DW_AT_const_value if we have a location)
for the non-LTO path though (and also try adding a DW_AT_const_value with
a larger size-cut-off if we don't).

[Bug middle-end/67298] [6 Regression] 254.gap in SPEC CPU 2000 is miscompiled

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-08-25
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Marek Polacek  ---
Probably INVALID then...

[Bug middle-end/67340] [6 Regression] ICE: in convert_move, at expr.c:279

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||hppa*-*-*
 CC||aoliva at gcc dot gnu.org
   Target Milestone|--- |6.0

[Bug c++/67318] [6 regression] Parsing error when using abbreviated integral type names in template parameter pack declaration

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug middle-end/67118] gcc and gfortran started crashing recently

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-08-25
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|blocker |normal

[Bug tree-optimization/67326] [5/6 Regression] -ftree-loop-if-convert-stores does not vectorize conditional assignment (anymore)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2015-08-25
 CC||rguenth at gcc dot gnu.org,
   ||venkataramanan.kumar at amd 
dot co
   ||m
 Ever confirmed|0   |1
Summary|[5.2/6.0 regression]|[5/6 Regression]
   |-ftree-loop-if-convert-stor |-ftree-loop-if-convert-stor
   |es does not vectorize   |es does not vectorize
   |conditional assignment  |conditional assignment
   |(anymore)   |(anymore)
   Target Milestone|--- |6.0
   Severity|normal  |enhancement

--- Comment #1 from Richard Biener  ---
This is because in condAssign1 v3 is not accessed always and thus we do not
know (ok, stupid ifcvt limitation) that v3[i] is not accessed out-of-bounds.
Previous to

2015-07-10  Richard Biener  

PR tree-optimization/66823
* tree-if-conv.c (memrefs_read_or_written_unconditionally): Fix
inverted predicate.

ifcvt's reasoning was "oh, "v3[i] is _not_ equal to v2[i] which is always
accessed, thus it's fine to access it always as well".  I fixed this bug
but did not try to enhance ifcvts idea of what operations can trap
(v3[i] is thought to eventually trap because we do not try to analyze
what values 'i' can have).

So in 4.9 and earlier this only works becuase of the above bug.  So, kind
of "confirmed", but it's really an enhancement request.  AFAIR Venkat is
working
in this area.

[Bug tree-optimization/67328] range test rather than single bit test for code testing enum values

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-08-25
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Note this is already fold-const.c:optimize_bit_field_compare at work.  With
-DALT (non-working code) we get

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


{
  if ((BIT_FIELD_REF <*info, 8, 0> & 3) + 254 <= 1)

and

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


{
  if ((SAVE_EXPR  & 3>) == 0 || (SAVE_EXPR
 & 3>) == 2)

from it.  Without -DALT

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


{
  if ((SAVE_EXPR  & 3>) == 3 || (SAVE_EXPR
 & 3>) == 1)

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


{
  if ((BIT_FIELD_REF <*info, 8, 0> & 3) <= 1)


I see more that a single bit test for both cases btw, mostly because we
need to mask the padding.  Not sure what optimal code you expect here.

[Bug tree-optimization/67312] [6 Regression] ICE: SIGSEGV in expand_expr_real_1 (expr.c:9561) with -ftree-coalesce-vars

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

--- Comment #1 from Richard Biener  ---
We shouldn't do coalesce-vars at -O0 I think.

[Bug c++/67313] [6 Regression] ICE: in vague_linkage_p, at cp/decl2.c:1878 with -fno-weak and variadic template

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/67315] [4.9 Regression] Strange 'this' pointer behavior when calling virtual function with different optimization attributes.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
I think this is a dup of the bug with the i386 backend issue of local calling
conventions and its interaction with optimization attributes ("optimize"
setting).
Somebody find it ... ;)

[Bug c++/67315] [4.9 Regression] Strange 'this' pointer behavior when calling virtual function with different optimization attributes.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug inline-asm/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-08-25
 Ever confirmed|0   |1

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|powerpc-darwin  |powerpc-darwin,
   ||mips64-linux-n32
 Status|WAITING |NEW

--- Comment #26 from Richard Biener  ---
Don't hold your breath.  Basically somebody who can reproduce it has to find
the root-cause and a fix.

[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
(In reply to Bill Schmidt from comment #20)
> We still don't vectorize the original code example on Power.  It appears
> that this is being disabled because of an alignment issue.  The data
> references are being rejected by:
> 
> product.f:9:0: note: can't force alignment of ref: REALPART_EXPR
> <*a.0_24[_50]>
> 
> and similar for the other three DRs.  This happens due to this code in
> vect_compute_data_ref_alignment:
> 
>   if (base_alignment < TYPE_ALIGN (vectype))
> {
>   /* Strip an inner MEM_REF to a bare decl if possible.  */
>   if (TREE_CODE (base) == MEM_REF
>   && integer_zerop (TREE_OPERAND (base, 1))
>   && TREE_CODE (TREE_OPERAND (base, 0)) == ADDR_EXPR)
> base = TREE_OPERAND (TREE_OPERAND (base, 0), 0);
> 
>   if (!vect_can_force_dr_alignment_p (base, TYPE_ALIGN (vectype)))
> {
>   if (dump_enabled_p ())
> {
>   dump_printf_loc (MSG_NOTE, vect_location,
>"can't force alignment of ref: ");
>   dump_generic_expr (MSG_NOTE, TDF_SLIM, ref);
>   dump_printf (MSG_NOTE, "\n");
> }
>   return true;
> }
> 
> Here TYPE_ALIGN (vectype) is 128 (Power vectors are normally aligned on a
> 128-bit value), and base_alignment is 64.  a.0 is defined as:
> 
> complex(kind=8) [0:D.1831] * restrict a.0;
> 
> In both ELFv1 and ELFv2 ABIs for Power, a complex type is defined to have
> the same alignment as the underlying type.  So "complex double" has 8-byte
> alignment.
> 
> On earlier versions of Power, the decision is fine, because unaligned
> accesses are expensive prior to POWER8.  With POWER8, though, an unaligned
> access will (most of the time) perform as well as an aligned access.  So
> ideally we would like to teach the vectorizer to allow vectorization here.
> 
> It seems like vect_supportable_dr_alignment ought to be considered as part
> of the SLP vectorization decision here, rather than just comparing the base
> alignment with the vector type alignment.  Adding a check for that allows
> things to get a little further, but we still don't vectorize the block.  (I
> haven't yet looked into why, but I assume more needs to be done downstream
> to handle this case.)
> 
> My understanding of the vectorizer is not yet very deep, so before going too
> far down the wrong path, I'd like your opinion on the best approach to
> fixing the problem.  Thanks!

I see it only failing due to cost issues (tried ppc64le and -mcpu=power8).
The unaligned loads cost 3 and we end up with

t.f90:8:0: note: Cost model analysis:
  Vector inside of loop cost: 40
  Vector prologue cost: 8
  Vector epilogue cost: 4
  Scalar iteration cost: 12
  Scalar outside cost: 6
  Vector outside cost: 12
  prologue iterations: 0
  epilogue iterations: 0
t.f90:8:0: note: cost model: the vector iteration cost = 40 divided by the
scalar iteration cost = 12 is greater or equal to the vectorization factor = 1.

Note that we are (still) not very good in estimating the SLP cost as we
account 4 vector loads here (because we essentially will end up with
4 different permutations used), so the "unaligned" part is accounted for
too much and likely the permutation cost as well.  Both are a limitation
of the SLP data structures and not easily fixable.  With
-fvect-cost-model=unlimited I see both loops vectorized.

> Bill

[Bug middle-end/67341] [ICE] libgo build failure: in mark_stmt_if_obviously_necessary, at tree-ssa-dce.c:278

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #1 from Mikhail Maltsev  ---
Probably a dup of PR67284. At least for me bootstrap passes even with -O3 (with
--enable-checking=yes, though) with r227145.

[Bug tree-optimization/67055] [5 Regression] Segmentation fault in fold_builtin_alloca_with_align in tree-ssa-ccp.c

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

Summary|[5/6 Regression]|[5 Regression] Segmentation
   |Segmentation fault in   |fault in
   |fold_builtin_alloca_with_al |fold_builtin_alloca_with_al
   |ign in tree-ssa-ccp.c   |ign in tree-ssa-ccp.c

--- Comment #13 from Markus Trippelsdorf  ---
Another testcase:

trippels@gcc2-power8 ~ % cat syn.i
struct list_head
{
  struct list_head *prev;
};
extern void __wait_rcu_gp (void*);
const int a = sizeof 0;
static inline __attribute__ ((always_inline no_instrument_function)) void
rcu_barrier_sched (void)
{
  struct list_head b[a];
  __wait_rcu_gp (b);
}

static inline __attribute__ ((always_inline no_instrument_function)) void
rcu_barrier (void)
{
  rcu_barrier_sched ();
}

struct
{
  void *wait;
} c[] = { rcu_barrier, rcu_barrier_sched };

trippels@gcc2-power8 ~ % /home/trippels/gcc_5/usr/local/bin/gcc -c -O2 syn.i
syn.i: In function ‘rcu_barrier_sched’:
syn.i:8:1: internal compiler error: Segmentation fault
 rcu_barrier_sched (void)
 ^
0x107e9053 crash_signal
../../gcc/gcc/toplev.c:383
0x10937a64 tree_check
../../gcc/gcc/tree.h:2850
0x10937a64 fold_builtin_alloca_with_align
../../gcc/gcc/tree-ssa-ccp.c:2067
0x10937a64 ccp_fold_stmt
../../gcc/gcc/tree-ssa-ccp.c:2172
0x109d85a3
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-propagate.c:1177
0x10dd228b dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:188
0x109d7993 substitute_and_fold(tree_node* (*)(tree_node*), bool
(*)(gimple_stmt_iterator*), bool)
../../gcc/gcc/tree-ssa-propagate.c:1272
0x1092f0eb ccp_finalize
../../gcc/gcc/tree-ssa-ccp.c:941
0x1092f0eb do_ssa_ccp
../../gcc/gcc/tree-ssa-ccp.c:2382
0x1092f0eb execute
../../gcc/gcc/tree-ssa-ccp.c:2414
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/67349] [5 regression] ICE on optimization

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #4 from Markus Trippelsdorf  ---
dup.

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

[Bug tree-optimization/67055] [5/6 Regression] Segmentation fault in fold_builtin_alloca_with_align in tree-ssa-ccp.c

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||ysato at users dot 
sourceforge.jp

--- Comment #12 from Markus Trippelsdorf  ---
*** Bug 67349 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/67349] [5 regression] ICE on optimization

[ysato at users dot sourceforge.jp]

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

--- Comment #3 from Yoshinori Sato  ---
I tested
gcc version 6.0.0 20150710 (experimental) (GCC)

I'll trying latest trunk.

Thanks,

[Bug tree-optimization/67349] [5 regression] ICE on optimization

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Target|h8300   |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-25
 CC||trippels at gcc dot gnu.org
  Component|target  |tree-optimization
Summary|ICE on optimization |[5 regression] ICE on
   ||optimization
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
Trunk and gcc-4.9 are fine.

trippels@gcc2-power8 ~ % cat syn.i
struct list_head
{
  struct list_head *prev;
};
extern void __wait_rcu_gp (void*);
const int a = sizeof 0;
static inline __attribute__ ((always_inline no_instrument_function)) void
rcu_barrier_sched (void)
{
  struct list_head b[a];
  __wait_rcu_gp (b);
}

static inline __attribute__ ((always_inline no_instrument_function)) void
rcu_barrier (void)
{
  rcu_barrier_sched ();
}

struct
{
  void *wait;
} c[] = { rcu_barrier, rcu_barrier_sched };

trippels@gcc2-power8 ~ % /home/trippels/gcc_5/usr/local/bin/gcc -c -O2 syn.i
syn.i: In function ‘rcu_barrier_sched’:
syn.i:8:1: internal compiler error: Segmentation fault
 rcu_barrier_sched (void)
 ^
0x107e9053 crash_signal
../../gcc/gcc/toplev.c:383
0x10937a64 tree_check
../../gcc/gcc/tree.h:2850
0x10937a64 fold_builtin_alloca_with_align
../../gcc/gcc/tree-ssa-ccp.c:2067
0x10937a64 ccp_fold_stmt
../../gcc/gcc/tree-ssa-ccp.c:2172
0x109d85a3
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-propagate.c:1177
0x10dd228b dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:188
0x109d7993 substitute_and_fold(tree_node* (*)(tree_node*), bool
(*)(gimple_stmt_iterator*), bool)
../../gcc/gcc/tree-ssa-propagate.c:1272
0x1092f0eb ccp_finalize
../../gcc/gcc/tree-ssa-ccp.c:941
0x1092f0eb do_ssa_ccp
../../gcc/gcc/tree-ssa-ccp.c:2382
0x1092f0eb execute
../../gcc/gcc/tree-ssa-ccp.c:2414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/67349] ICE on optimization

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #1 from Mikhail Maltsev  ---
I cannot reproduce this with current trunk (h8300 cross), but earlier revisions
(including 5.2 release) do crash even on x86_64. I suppose this is the same
bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67055#c9

Please provide the output of "h8300-unknown-linux-gcc -v".