[Bug c++/69831] Issue with passing a reference_wrapper to a placeholder when using a pointer to member function in bind

[sniderdj at umich dot edu]

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

--- Comment #2 from sniderdj at umich dot edu ---
Created attachment 37697
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37697=edit
For convenience, the result of the compilation

[Bug target/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-16
 CC||amodra at gmail dot com
 Ever confirmed|0   |1

--- Comment #5 from Alan Modra  ---
Confirmed.  Can be seen on other powerpc targets with -mno-mfcrf -misel.

[Bug c++/69831] Issue with passing a reference_wrapper to a placeholder when using a pointer to member function in bind

[sniderdj at umich dot edu]

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

--- Comment #1 from sniderdj at umich dot edu ---
*** Bug 69830 has been marked as a duplicate of this bug. ***

[Bug c++/69831] New: Issue with passing a reference_wrapper to a placeholder when using a pointer to member function in bind

[sniderdj at umich dot edu]

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

Bug ID: 69831
   Summary: Issue with passing a reference_wrapper to a
placeholder when using a pointer to member function in
bind
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sniderdj at umich dot edu
  Target Milestone: ---

Created attachment 37696
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37696=edit
the preprocessed file

When passing in a reference_wrapper to the result of a call to bind called on a
pointer to member function, no overload is resolved, although when the
reference wrapper is given to bind initially, everything works as expected.

In this short case:

#include 
#include 
#include 

using namespace std;
using namespace std::placeholders;
struct foo { 
  foo(){}
  void func(int) {}
};
int main() {
  vector v;
  foo inst;
  reference_wrapper rw = inst;
  auto b1 = bind(::func, rw, 0); // okay
  b1();
  auto b2 = bind(::func, _1, 0); // bad
  b2(rw);
}

The first call to bind works fine, as expected, but on the last line, where the
second bind object is called with the reference_wrapper, the compiler rejects
all possible overloads, even though it appears as at least one should match.

command: gcc -v -save-temps -std=c++14 bug.cpp

the result of the command:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.3.0-3ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.0 20151204 (Ubuntu 5.3.0-3ubuntu1~14.04) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++14' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE bug.cpp -mtune=generic -march=x86-64 -std=c++14
-fpch-preprocess -fstack-protector -Wformat -Wformat-security -o bug.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/5"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/5
 /usr/include/x86_64-linux-gnu/c++/5
 /usr/include/c++/5/backward
 /usr/lib/gcc/x86_64-linux-gnu/5/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++14' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -fpreprocessed bug.ii -quiet -dumpbase
bug.cpp -mtune=generic -march=x86-64 -auxbase bug -std=c++14 -version
-fstack-protector -Wformat -Wformat-security -o bug.s
GNU C++14 (Ubuntu 5.3.0-3ubuntu1~14.04) version 5.3.0 20151204
(x86_64-linux-gnu)
compiled by GNU C version 5.3.0 20151204, GMP version 5.1.3, MPFR
version 3.1.3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Ubuntu 5.3.0-3ubuntu1~14.04) version 5.3.0 20151204
(x86_64-linux-gnu)
compiled by GNU C version 5.3.0 20151204, GMP version 5.1.3, MPFR
version 3.1.3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: bbf79e63f589fea28823afe8bbe74c79
bug.cpp: In function ‘int main()’:
bug.cpp:15:8: error: no match for call to ‘(std::_Bind, int)>) (std::reference_wrapper&)’
   b2(rw);
^
In file included from bug.cpp:1:0:
/usr/include/c++/5/functional:1129:2: note: candidate: template _Result 

[Bug c++/69830] Issue with passing a reference_wrapper to a placeholder when using a pointer to member function in bind

[sniderdj at umich dot edu]

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

sniderdj at umich dot edu changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #2 from sniderdj at umich dot edu ---


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

[Bug c++/69830] Issue with passing a reference_wrapper to a placeholder when using a pointer to member function in bind

[sniderdj at umich dot edu]

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

sniderdj at umich dot edu changed:

   What|Removed |Added

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

--- Comment #1 from sniderdj at umich dot edu ---
test case was not minimalist

[Bug c++/69830] New: Issue with passing a reference_wrapper to a placeholder when using a pointer to member function in bind

[sniderdj at umich dot edu]

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

Bug ID: 69830
   Summary: Issue with passing a reference_wrapper to a
placeholder when using a pointer to member function in
bind
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sniderdj at umich dot edu
  Target Milestone: ---

command: gcc -v -save-temps -std=c++14 bug.cpp

the result of the command:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.3.0-3ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.0 20151204 (Ubuntu 5.3.0-3ubuntu1~14.04) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++14' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE bug.cpp -mtune=generic -march=x86-64 -std=c++14
-fpch-preprocess -fstack-protector -Wformat -Wformat-security -o bug.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/5"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/5
 /usr/include/x86_64-linux-gnu/c++/5
 /usr/include/c++/5/backward
 /usr/lib/gcc/x86_64-linux-gnu/5/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++14' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -fpreprocessed bug.ii -quiet -dumpbase
bug.cpp -mtune=generic -march=x86-64 -auxbase bug -std=c++14 -version
-fstack-protector -Wformat -Wformat-security -o bug.s
GNU C++14 (Ubuntu 5.3.0-3ubuntu1~14.04) version 5.3.0 20151204
(x86_64-linux-gnu)
compiled by GNU C version 5.3.0 20151204, GMP version 5.1.3, MPFR
version 3.1.3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Ubuntu 5.3.0-3ubuntu1~14.04) version 5.3.0 20151204
(x86_64-linux-gnu)
compiled by GNU C version 5.3.0 20151204, GMP version 5.1.3, MPFR
version 3.1.3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: bbf79e63f589fea28823afe8bbe74c79
bug.cpp: In function ‘int main()’:
bug.cpp:18:8: error: no match for call to ‘(std::_Bind, int)>) (std::reference_wrapper&)’
   b2(rw);
^
In file included from bug.cpp:1:0:
/usr/include/c++/5/functional:1129:2: note: candidate: template _Result std::_Bind<_Functor(_Bound_args
...)>::operator()(_Args&& ...) [with _Args = {_Args ...}; _Result = _Result;
_Functor = std::_Mem_fn; _Bound_args =
{std::_Placeholder<1>, int}]
  operator()(_Args&&... __args)
  ^
/usr/include/c++/5/functional:1129:2: note:   template argument
deduction/substitution failed:
/usr/include/c++/5/functional:1125:38: error: call of ‘(std::_Mem_fn) (std::reference_wrapper&, int&)’ is ambiguous
  = decltype( std::declval<_Functor>()(
  ^
In file included from bug.cpp:1:0:
/usr/include/c++/5/functional:582:2: note: candidate:
std::_Mem_fn_base<_MemFunPtr, __is_mem_fn>::result_type
std::_Mem_fn_base<_MemFunPtr,
__is_mem_fn>::operator()(std::_Mem_fn_base<_MemFunPtr, __is_mem_fn>::_Class&,
_Args&& ...) const [with _Args = {int&}; _Req = void; _MemFunPtr = void
(foo::*)(int); bool __is_mem_fn = true; std::_Mem_fn_base<_MemFunPtr,

[Bug fortran/69456] Namelist value with trailing sign is ignored without error

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
From the Fortran 95 Standard regarding exponents.

The basic form may be followed by an exponent of one of
the following forms:
   (1) A sign followed by a digit-string
   (2) E followed by zero or more blanks, followed by a signed-digit-string
   (3) D followed by zero or more blanks, followed by a signed-digit-string

An exponent containing a D is processed identically to an exponent containing
an E.

Form (1) allows the following in the test case of this report:

r3=1+1"   ! Treated as 1e+1? Yes this is valid
r4=1-1"   ! Treated as 1e-1? Yes this is valid

That being clarified, the first two examples are invalid because the required
digit-string must contain at least one digit.

r1=1+"! BUG: wrong result: Agreed an error may be helpful
r2=1-"! BUG: wrong result: Agreed an error may be helpful

In fact the last two cases here do result in a "bad_real" in read_real,
however, it is being interpreted as a NULL value. I have further work to do. 
Keep in mind that it is users responsibility to use correct input data.

[Bug target/67458] x86: atomic store with memory_order_release doesn't order other stores

[yyc1992 at gmail dot com]

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

Yichao Yu  changed:

   What|Removed |Added

 CC||yyc1992 at gmail dot com

--- Comment #1 from Yichao Yu  ---
I've just hit this when I was expecting the stores to the non-atomic variables
to be optimized to before the atomic store. I have a slightly more
self-contained repro that can trigger an assertion on x64 when running
repeatedly

https://github.com/yuyichao/explore/commit/0b70ee0b14c5d20f0e98d8e0d0ebc5032bd12892

(I was going to report a bug with the code and discovered this report and I
realized that I happened to pick exactly the same variable names and
values)

[Bug ipa/69589] [6 Regression] ICE in initialize_node_lattices, at ipa-cp.c:971

[kugan.vivekanandarajah at linaro dot org]

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

--- Comment #14 from kugan.vivekanandarajah at linaro dot org ---
On 16/02/16 02:02, jamborm at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69589
>
> --- Comment #13 from Martin Jambor  ---
> (In reply to kugan from comment #11)
>> In remove_unreachable_nodes, just before ipa-cp, this node becomes local
>> (address taken is false and local.local = true). After that, when
>> ipa_propagate_frequency is run, which updates the frequency to zero. I think
>> we should check the frequency at this point in time and remove such nodes.
>
> If remove_unreachable_nodes keeps the node around for comdat reasons,
> we cannot remove it just because it has zero estimated frequency
> (unless remove_unreachable_nodes was wrong and should have removed the
> node itself).
>
> I think that remove_unreachable_nodes should either remove the node,
> or not set it to local (or set something like force_output or
> forced_by_abi, if it is some really weird case).
Thanks for the comment. It looks to me that it is already done.

  /* If any symbol in a comdat group is reachable, force
 all externally visible symbols in the same comdat
 group to be reachable as well.  Comdat-local symbols
 can be discarded if all uses were inlined.  */



The problem seems to be that, for the reduced test case, at the point 
when the node becomes local, frequency = 2. After 
ipa_propagate_frequency is run, frequency becomes zero. I dont think 
that this case is handled now.

Maybe we should change the removal pas as :

+  for (unsigned int i = 0; i < new_locals.length (); ++i)
+{
+  if (!new_locals[i]->frequency)
+   {
+ node = new_locals[i];
+ if (!node->aux)
+   {
+ if (file)
+   fprintf (file, " %s/%i", node->name (), node->order);
+ node->remove ();
+ changed = true;
+   }
+   }
+}

Thanks,
Kugan

[Bug other/69821] -fdebug-prefix-map doesn't affect gcc command line switches in DWARF DW_AT_producer.

[hongxu.jia at windriver dot com]

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

--- Comment #8 from hongxu jia  ---
(In reply to Jakub Jelinek from comment #7)
> It is not a regression and is user visible change, so I think changing it
> just in GCC 6 is sufficient.

Got it, thanks for pointing it out.
I will backport to our Yocto.

//Hongxu

[Bug fortran/69668] [4.9/5/6 Regression] Error reading namelist opened with DELIM='NONE'

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Feb 16 00:51:58 2016
New Revision: 233443

URL: https://gcc.gnu.org/viewcvs?rev=233443=gcc=rev
Log:
2016-02-15  Jerry DeLisle  

Backport from mainline
PR libgfortran/69668
* gfortran.dg/namelist_38.f90: Update test.
* gfortran.dg/namelist_84.f90: Update test.

Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/namelist_38.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/namelist_84.f90

[Bug fortran/69668] [4.9/5/6 Regression] Error reading namelist opened with DELIM='NONE'

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Feb 16 00:38:18 2016
New Revision: 233442

URL: https://gcc.gnu.org/viewcvs?rev=233442=gcc=rev
Log:
2016-02-15  Jerry DeLisle  

Backport from trunk
PR libgfortran/69651
PR libgfortran/69668
* io/list_read.c: Entire file trailing spaces removed.
(CASE_SEPARATORS): Remove '!'.
(is_separator): Add namelist mode as condition with '!'.
(push_char): Remove un-needed memset. (push_char4): Likewise and remove
'new' pointer. (eat_separator): Remove un-needed use of notify_std.
(read_logical): If '!' bang encountered when not in namelist mode got
bad_logical to give an error. (read_integer): Likewise reject '!'.
(read_character): Remove condition testing c = '!' which is now inside
the is_separator macro. Remove code related to DELIM_NONE.
(parse_real): Reject '!' unless in namelist mode. (read_complex):
Reject
'!' unless in namelist mode. (read_real): Likewise reject '!'.
* gfortran.dg/read_bang.f90: New test.
* gfortran.dg/read_bang4.f90: New test.
* gfortran.dg/namelist_87.f90: New test.
* gfortran.dg/namelist_88.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/namelist_87.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/namelist_88.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/read_bang.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/read_bang4.f90
Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/libgfortran/ChangeLog
branches/gcc-5-branch/libgfortran/io/list_read.c

[Bug libfortran/69651] [6 Regession] Usage of unitialized pointer io/list_read.c

[jvdelisle at gcc dot gnu.org]

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

--- Comment #13 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Feb 16 00:38:18 2016
New Revision: 233442

URL: https://gcc.gnu.org/viewcvs?rev=233442=gcc=rev
Log:
2016-02-15  Jerry DeLisle  

Backport from trunk
PR libgfortran/69651
PR libgfortran/69668
* io/list_read.c: Entire file trailing spaces removed.
(CASE_SEPARATORS): Remove '!'.
(is_separator): Add namelist mode as condition with '!'.
(push_char): Remove un-needed memset. (push_char4): Likewise and remove
'new' pointer. (eat_separator): Remove un-needed use of notify_std.
(read_logical): If '!' bang encountered when not in namelist mode got
bad_logical to give an error. (read_integer): Likewise reject '!'.
(read_character): Remove condition testing c = '!' which is now inside
the is_separator macro. Remove code related to DELIM_NONE.
(parse_real): Reject '!' unless in namelist mode. (read_complex):
Reject
'!' unless in namelist mode. (read_real): Likewise reject '!'.
* gfortran.dg/read_bang.f90: New test.
* gfortran.dg/read_bang4.f90: New test.
* gfortran.dg/namelist_87.f90: New test.
* gfortran.dg/namelist_88.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/namelist_87.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/namelist_88.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/read_bang.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/read_bang4.f90
Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/libgfortran/ChangeLog
branches/gcc-5-branch/libgfortran/io/list_read.c

[Bug target/68973] [6 regression] Internal compiler error on power for gcc/testsuite/g++.dg/pr67211.C

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #20 from Alan Modra  ---
Fixed

[Bug target/68973] [6 regression] Internal compiler error on power for gcc/testsuite/g++.dg/pr67211.C

[amodra at gcc dot gnu.org]

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

--- Comment #19 from Alan Modra  ---
Author: amodra
Date: Mon Feb 15 23:29:17 2016
New Revision: 233438

URL: https://gcc.gnu.org/viewcvs?rev=233438=gcc=rev
Log:
[RS6000] reload_vsx_from_gprsf splitter

This is PR68973 part 2, caused by the reload_vsx_from_gprsf splitter
emitting an invalid move.  The patch also fixes uses of TFmode, which
cannot now be assumed to be IBM double-double.

PR target/68973
* config/rs6000/rs6000.md (reload_vsx_from_gprsf): Rewrite splitter.
(p8_mtvsrd_df, p8_mtvsrd_sf): New.
(p8_mtvsrd_1, p8_mtvsrd_2): Delete.
(p8_mtvsrwz): New.
(p8_mtvsrwz_1, p8_mtvsrwz_2): Delete.
(p8_xxpermdi_): Take two DF inputs rather than one TF.
(p8_fmrgow_): Likewise.
(reload_vsx_from_gpr): Make clobber IF.  Adjust for above
changes.
(reload_fpr_from_gpr): Similarly. Use "d" for op0 constraint.
(reload_vsx_from_gprsf): Use p8_mtvsrd_sf rather than attempting
to use movdi_internal64.  Remove op0_di.
* config/rs6000/vsx.md (vsx_xscvspdpn_directmove): Make op1 SFmode.


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

[Bug c/62184] [C/C++] Extend -Wempty-body to 'while' loops

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||easyhack
   Severity|normal  |enhancement

--- Comment #5 from Manuel López-Ibáñez  ---
If we can warn precisely about misleading indentation, surely we can warn here
as well as clang does.

[Bug c/61864] -Wcovered-switch-default to identify "dead" default branch

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||manu at gcc dot gnu.org
   Target Milestone|5.4 |---
Summary|Feature Request,|-Wcovered-switch-default to
   |-Wcovered-switch-default to |identify "dead" default
   |identify "dead" default |branch
   |branch  |
   Severity|normal  |enhancement

--- Comment #8 from Manuel López-Ibáñez  ---
Non-regressions don't have a milestone.

[Bug c++/31573] -Wall-all to enable all warnings

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #8 from Manuel López-Ibáñez  ---
Marc, in reply to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313#c10

I see there may be value in a -Weverything flag for debugging (and to check if
something already warns for a specific testcase). I believe it will be useless
for users, but, hey, I'm happy if the description warns users profusely about
it, so we don't get a tsunami of reports complaining that "it warns too much".

Your proposed patch (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313#c5) is
probably a good start. It probably doesn't maximize warnings that take several
levels (like Wstrict-overflow=) or warnings that internally have several levels
(like Wmain).

You should only need to convince Joseph or Dodji.

[Bug c++/31573] -Wall-all to enable all warnings

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||david at doublewise dot net

--- Comment #7 from Manuel López-Ibáñez  ---
*** Bug 53313 has been marked as a duplicate of this bug. ***

[Bug other/53313] Add warning levels

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #14 from Manuel López-Ibáñez  ---
(In reply to David Stone from comment #8)
> I have changed my opinion on this and agree that warning levels are probably
> not the way to go. The two things from this that I do still want are
> 
> -Weverything-and-I-really-mean-it-this-time

Then, this is a dup.

> All warnings either warn for exactly one type of thing or they turn on other
> warnings that themselves can be individually turned on or off.

Unfortunately, fixing Wextra (PR7651), for example, is a tedious and long
process.

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

[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||easyhack

--- Comment #34 from Manuel López-Ibáñez  ---
This should be easy (apart from the option name bike-shedding)

[Bug libfortran/69651] [6 Regession] Usage of unitialized pointer io/list_read.c

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle  ---
Author: jvdelisle
Date: Mon Feb 15 22:31:13 2016
New Revision: 233436

URL: https://gcc.gnu.org/viewcvs?rev=233436=gcc=rev
Log:
2016-02-15  Jerry DeLisle  

PR libgfortran/69651
* io/list_read.c: Entire file trailing spaces removed.
(CASE_SEPARATORS): Remove '!'.
(is_separator): Add namelist mode as condition with '!'.
(push_char): Remove un-needed memset. (push_char4): Likewise and remove
'new' pointer. (eat_separator): Remove un-needed use of notify_std.
(read_logical): If '!' bang encountered when not in namelist mode got
bad_logical to give an error. (read_integer): Likewise reject '!'.
(read_character): Remove condition testing c = '!' which is now inside
the is_separator macro. (parse_real): Reject '!' unless in namelist
mode.
(read_complex): Reject '!' unless in namelist mode. (read_real):
Likewise
reject '!'.

PR libgfortran/69651
* gfortran.dg/read_bang.f90: New test.
* gfortran.dg/read_bang4.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/read_bang.f90
trunk/gcc/testsuite/gfortran.dg/read_bang4.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c

[Bug c++/69658] [6 Regression] Bogus "C99 designator outside aggregate initializer" error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/69658] [6 Regression] Bogus "C99 designator outside aggregate initializer" error

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Feb 15 22:05:12 2016
New Revision: 233435

URL: https://gcc.gnu.org/viewcvs?rev=233435=gcc=rev
Log:
PR c++/69658
* init.c (expand_default_init): Only call reshape_init
in the direct-initialization from an initializer list case.

* g++.dg/init/pr69658.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/init/pr69658.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/69797] [4.9/5 Regression] ICE on invalid code on x86_64-linux-gnu in operator[], at vec.h:714

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression] ICE on |[4.9/5 Regression] ICE on
   |invalid code on |invalid code on
   |x86_64-linux-gnu in |x86_64-linux-gnu in
   |operator[], at vec.h:714|operator[], at vec.h:714

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

[Bug c++/69797] [4.9/5/6 Regression] ICE on invalid code on x86_64-linux-gnu in operator[], at vec.h:714

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Feb 15 21:30:50 2016
New Revision: 233434

URL: https://gcc.gnu.org/viewcvs?rev=233434=gcc=rev
Log:
PR c++/69797
* c-common.c (sync_resolve_size): Diagnose too few arguments
even when params is non-NULL empty vector.

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

Added:
trunk/gcc/testsuite/c-c++-common/pr69797.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

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

[anlauf at gmx dot de]

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

--- Comment #7 from Harald Anlauf  ---
(In reply to Dominique d'Humieres from comment #6)
> > I think it should be clearer from the error message of _what is wrong_?
> 
> Agreed -> Updated the summary, set to NEW and enhancement.

A potential patch to generate an error message:

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 233428)
+++ gcc/fortran/resolve.c   (working copy)
@@ -9308,6 +9310,12 @@
  and stride. The FORALL index can not appear in start, end or stride.  */
   for (fa = code->ext.forall_iterator; fa; fa = fa->next)
 {
+  if (fa->var->ref && fa->var->ref->type == REF_ARRAY)
+   {
+ gfc_error ("FORALL index variable at %L must be scalar",
+>var->where);
+   }
+
   /* Check if any outer FORALL index name is the same as the current
 one.  */
   for (i = 0; i < nvar; i++)


Not sure if it is correct, if this is the best place, if error recovery
should be improved, and if people are happy with it.  With this patch,
the testcase produces:
pr69741.f90:5:10:

   forall (ii(1)=1:3 , ii(2)=1:2)
  1
Error: FORALL index variable at (1) must be scalar
pr69741.f90:5:21:

   forall (ii(1)=1:3 , ii(2)=1:2)
 1
Error: FORALL index variable at (1) must be scalar
pr69741.f90:5:21:

   forall (ii(1)=1:3 , ii(2)=1:2)
 1
Error: An outer FORALL construct already has an index with this name (1)
pr69741.f90:6:5:

  a(ii(1),ii(2)) = ii(1) * ii(2)
 1
Warning: The FORALL with index 'ii' is not used on the left side of the
assignment at (1) and so might cause multiple assignment to this object
pr69741.f90:6:5:

  a(ii(1),ii(2)) = ii(1) * ii(2)
 1
Warning: The FORALL with index 'ii' is not used on the left side of the
assignment at (1) and so might cause multiple assignment to this object

[Bug c++/69753] [6 Regression] bogus: expected primary-expression before ‘>’ token

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed.

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

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

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Mon Feb 15 21:16:10 2016
New Revision: 233433

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

* constexpr.c (verify_ctor_sanity): Remove CONSTRUCTOR_NELTS check.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-value5.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/constexpr.c

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

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Mon Feb 15 21:13:57 2016
New Revision: 233430

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

* constexpr.c (verify_ctor_sanity): Remove CONSTRUCTOR_NELTS check.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-value5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug c++/69753] [6 Regression] bogus: expected primary-expression before ‘>’ token

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Mon Feb 15 21:14:05 2016
New Revision: 233431

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

* search.c (any_dependent_bases_p): Split out...
* name-lookup.c (do_class_using_decl): ...from here.
* call.c (build_new_method_call_1): Don't complain about missing object
if there are dependent bases.  Tweak error.
* tree.c (non_static_member_function_p): Remove.
* pt.c (type_dependent_expression_p): A member template of a
dependent type is dependent.
* cp-tree.h: Adjust.

Added:
trunk/gcc/testsuite/g++.dg/lookup/member3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/search.c
trunk/gcc/cp/semantics.c
trunk/gcc/cp/tree.c

[Bug fortran/69829] [OOP] Case label overlaps for unlimited polymorphic select type

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||pault at gcc dot gnu.org

--- Comment #1 from Thomas Koenig  ---
Same error for 4.8.0, so probably not a regression.

[Bug c++/69826] problem with cilkplus pragma and preprocessor variable

[ycollette.nospam at free dot fr]

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

--- Comment #2 from collette  ---
The problem is that this code used to compile. And now, it doesn't.
It compiles fine with intel compiler (under Windows).

[Bug fortran/69829] New: [OOP] Case label overlaps for unlimited polymorphic select type

[tkoenig at gcc dot gnu.org]

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

Bug ID: 69829
   Summary: [OOP] Case label overlaps for unlimited polymorphic
select type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Test case by James Van Buskirk from c.l.f:

ig25@linux-fd1f:/tmp> /usr/bin/gfortran a.f90
a.f90:15.20:

type is(CS5SS)
1
a.f90:17.20:

type is(SQS3C)
2
Error: CASE label at (1) overlaps with CASE label at (2)
a.f90:26.7:

   use types
   1
Fatal Error: Can't open module file 'types.mod' for reading at (1): No such
file or directory
ig25@linux-fd1f:/tmp> cat a.f90
module types
   implicit none
   type CS5SS
  integer x
  real y
   end type CS5SS
   type SQS3C
  logical u
  character(7) v
   end type SQS3C
   contains
  subroutine sub(x)
 class(*), allocatable :: x
 select type(x)
type is(CS5SS)
   write(*,'(a)') 'TYPE IS CS5SS'
type is(SQS3C)
   write(*,'(a)') 'TYPE IS SQS3C'
class default
   write(*,'(a)') 'TYPE could not be determined'
 end select
  end subroutine sub
end module types

program test
   use types
   implicit none
   class(*), allocatable :: u1, u2

   allocate(u1,source = CS5SS(2,1.414))
   allocate(u2,source = SQS3C(.TRUE.,'Message'))
   call sub(u1)
   call sub(u2)
end program test

[Bug c++/69826] problem with cilkplus pragma and preprocessor variable

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
What does the CILK+ documentation say about the pragma and using macros.  I do
know that not all pragma want to process macros in them.

[Bug c/69828] result of shift operation has wrong type

[tom239 at gmail dot com]

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

--- Comment #2 from Tom Ace  ---
My apologies.  I read the language spec before posting but I didn't read
carefully enough.  I agree with your resolution of the report as invalid.

Thanks for the fast response.

[Bug driver/66293] Support -Weverything to enable all warnings

[jeanmichael.celerier at gmail dot com]

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

--- Comment #5 from Jean-Michaël Celerier  ---
> In my experience, options like -Weverything tend to be too noisy to be 
> generally useful for projects of non-trivial size.

It's always possible to run -Weverything -Wno-foo -Wno-bar to remove unwanted
warnings. It's a bit more work upfront, but will bring benefits at each
compiler update. Generally speaking, I'd say that there are more "useful" than
"useless" warnings, hence it's less work to disable the useless ones, than to
enable the useful ones.

[Bug target/69738] PowerPC built-in __builtin_addg6s should be enabled on 64-bit

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug c/69824] [4.9/5/6 Regression] internal compiler error in unshare_body

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #3 from Bernd Schmidt  ---
I'll look.

[Bug c/69828] result of shift operation has wrong type

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Let's look at the last one:
   i8_t i = (argc < 0) | 0x80;
   u8_t u = i;

   i16_t t = (i16_t)u;  << Not really there but useful otherwise.
   << This is a zero extend from u8 to i16 since u8 fits in i16 so
   t = 0x80;

   i32_t x32_c = t << 8;
   t is prompted to int due to normal C promotion rules.
   so t << 8 is the same as ((int)(0x80)) << 8 or
   0x8000 aka 32768

   printf("should be negative: %7d\n",x32_c);

So GCC is correct.

>The result of a shift operation should have the type of the left operand.

No, it should go though the standard C promotion rules.  The standard promotion
rules says if the size of the type is less than int promote to int.

[Bug c/69828] New: result of shift operation has wrong type

[tom239 at gmail dot com]

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

Bug ID: 69828
   Summary: result of shift operation has wrong type
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom239 at gmail dot com
  Target Milestone: ---

The result of a shift operation should have the type of the left operand.
That is not the case in a testcase below; the result of the third shift should
have a signed type and thus should be sign-extended before assignment to x32_c.

gcc -v returns:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.4-2ubuntu1~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.1) 

seen under Ubuntu 14.04.3 LTS.  uname -a returns:

Linux croce 3.13.0-77-generic #121-Ubuntu SMP Wed Jan 20 10:50:42 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux

sample compilation and execution:

> gcc signbug.c ; a.out
should be negative:  -32768
should be negative:  -32768
should be negative:   32768

complete testcase code  (.i output from gcc -save-temps):

# 1 "signbug.c"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "signbug.c"
extern int printf (const char *__restrict __format, ...);
typedef signed char i8_t;
typedef unsigned char u8_t;
typedef signed short int i16_t;
typedef signed int i32_t;
int main(int argc,const char** argv)
{
   i8_t i = (argc < 0) | 0x80;
   u8_t u = i;
   i16_t x16 = ((i16_t)u) << 8;
   i32_t x32_a = x16;
   i32_t x32_b = ((i16_t)i) << 8;
   i32_t x32_c = ((i16_t)u) << 8;
   printf("should be negative: %7d\n",x32_a);
   printf("should be negative: %7d\n",x32_b);
   printf("should be negative: %7d\n",x32_c);
   return 0;
}

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[josh at joshtriplett dot org]

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

--- Comment #24 from Josh Triplett  ---
Also, even the documentation seems unfortunate: "In C++ this is normally not an
error since const variables take the place of #defines in C++."

Why would C code not do this too?  The GCC documentation should not steer
people away from this practice in C, or imply that there's something wrong with
it.

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

[josh at joshtriplett dot org]

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

Josh Triplett  changed:

   What|Removed |Added

 CC||josh at joshtriplett dot org

--- Comment #23 from Josh Triplett  ---
(In reply to Mark Wielaard from comment #21)
> Although in C a static const is not really like a #define

Why not?  Many C projects try to avoid the preprocessor as much as possible.

> I suspect that
> there are cases where they are used as such in header files. If that is the
> major reason for why there are people opposed to the warning then what we
> could do is hide such (non-)usage of static const variables from header
> files behind -Wextra and only explicitly warn for static const variable
> defined (and then not used) in the main file.

Please don't attach this to -Wextra; instead, please consider making it a
-Wconst-unused-variable=2 or similar.  Otherwise, projects using static const
values in header files would get a massive pile of additional warnings,
typically all false positives.

In a main file, this makes sense and likely has relatively few false positives;
the most common false positive would involve defining something only used in
ifdef'd code, and even then tagging it with __attribute__((unused)) (Linux's
__maybe_unused) seems correct.

However, in a header file, any use of static const to define constants for a
project will almost certainly get this warning, unless every single user of
that header file (directly or indirectly) uses every constant (or unless the
header itself does).  Silently throwing away the unused constants seems like
the right thing to do there.

[Bug c++/69363] ICE when doing a pragma simd reduction with max

[iverbin at gcc dot gnu.org]

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

iverbin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||iverbin at gcc dot gnu.org

--- Comment #2 from iverbin at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #1)
> The bug is that cp_parser_cilk_simd_all_clauses and
> c_parser_cilk_simd_all_clauses calls c_finish_cilk_clauses rather than the
> OpenMP clauses finalization routines in each of the FEs, perhaps with some
> argument that would say it wants Cilk+ semantics instead of OpenMP.
> That way, it misses lots of important actions that need to be performed on
> the clauses.

Yep, this patch fixes original testcase and 23 fails in Cilk Plus Conformance
Suite v1.2.1  without new regressions.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 6f47edf..9e12a96 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -37621,7 +37621,7 @@ cp_parser_cilk_simd_all_clauses (cp_parser *parser,
cp_token *pragma_token)
   if (clauses == error_mark_node)
 return error_mark_node;
   else
-return c_finish_cilk_clauses (clauses);
+return finish_omp_clauses (clauses, false);
 }

 /* Main entry-point for parsing Cilk Plus <#pragma simd> for loops.  */

[Bug driver/66293] Support -Weverything to enable all warnings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
In my experience, options like -Weverything tend to be too noisy to be
generally useful for projects of non-trivial size.

At the same time, I would find an option like -Weverything quite useful when
debugging GCC's support for diagnostics.  I use -Wall -Wextra -Wpedantic but
there are some warnings that aren't enabled even with these three.  That said,
if -Weverything were to be provided, it wouldn't be able to enable every single
diagnostic because some are mutually exclusive (for example, the -Wabi=version
warnings for distinct ABI versions).  It also wouldn't be guaranteed to enable
diagnostics controlled by non-warning options.  But I wouldn't view these
limitations as reasons not to provide such a feature.  Many other popular
compilers  besides Clang provide it.  Below are examples of a few other
implementations that do:

EDG eccp has --remarks to enable informational diagnostics that are normally
disabled.
HP aCC has +w that if memory serves enables all warnings (including EDG
remarks, since aCC uses the EDG front end).
IBM XLC/C++ has -qinfo=all.
Intel ICC has a -diag-enable= option similar to XLC/C++ -qinfo= (ICC also uses
the EDG front end but has many more diagnostics).
Oracle CC has the -erroff=%none option that (IIRC) enables all warnings.
Microsoft Visual C++ has /Wall that's documented to enable all diagnostic.

[Bug target/69827] [5 Regression] sincos not done

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Target||x86_64-unknown-cygwin
  Component|tree-optimization   |target

--- Comment #2 from Thomas Koenig  ---
Also works for me on Linux.

Hmm... what I find strange is that sincos is called from
__builtin_sincos anyway.

So, looks like a target issue.

[Bug tree-optimization/69820] [6 Regression] Test miscompiled with -O3 option

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 37695
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37695=edit
gcc6-pr69820-2.patch

Untested fix for the wrong-code issue.  For conversion from bool/_Bool/unsigned
:1 we have pattern recognizer for it, which is essential for correct behavior
(otherwise we get all ones instead of 1 for true), but the various widening
pattern recognizers aren't prepared to deal with those.

[Bug tree-optimization/69776] [4.9/5 Regression] Wrong optimization with aliasing

[ch3root at openwall dot com]

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

--- Comment #8 from Alexander Cherepanov  ---
--- Comment #4 from Richard Biener  ---
> Actually the middle-end memory model makes this valid and FREs redundant store
> elimination breaks it.

And function boundaries are not an obstacle for validity? I guess so (as 
gcc devs expressed such views several times in the past, in various 
contexts) but I'm not sure because DR 236 states otherwise. Initial 
testcase was prepared not to trigger DR 236 and, thus, it's a bit more 
tricky than necessary.

--- Comment #7 from Richard Biener  ---
 > Fixed on trunk sofar.

While the reduced testcase seems to be fixed, the original testcase 
still fails for me. If a separate function is ok the following testcase 
should be easier to reason about:

extern void *malloc (__SIZE_TYPE__);
extern void abort (void);

__attribute__((noinline,noclone))
void f(int *qi, double *qd)
{
   int i = *qi;
   *qd = 0;
   *qi = i;
}

int main()
{
   int *p = malloc(sizeof(double));

   *p = 1;
   f(p, (double *)p);
   if (*p != 1)
 abort();
}

This bug report was really about optimization of the function f in the 
absence of additional info, e.g. when compiled in a separate TU. 
(noinline+noclone seem to be enough too.) All printfs in the original 
testcase are just to achieve the same outcome without explicit function. 
But maybe I accidentally triggered another gcc bug.

BTW your testcase in comment #5 is interesting because the 
implementation of the function foo seems to affect the optimization of 
the rest of the program, i.e. noinline+noclone provide only one-way 
isolation. Just last week I asked about it elsewhere and here it is. 
Thanks! :-)

[Bug tree-optimization/69827] [5 Regression] sincos not done

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Works fine for me. I think this must be a glibc issue.

[Bug tree-optimization/69827] New: [5 Regression] sincos not done

[tkoenig at gcc dot gnu.org]

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

Bug ID: 69827
   Summary: [5 Regression] sincos not done
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

The following code does not produce a call to sincos even with
-ffast-math -O3.

I think this should be happening since PR 30038, so am I tentatively
marking this as a regression.  Not sure about current trunk,
hope to be able to check soon.

$ cat foo.c
#include 

void foo(double t, double *x, double *y)
{
*y = sin(t);
*x = cos(t);
}

$ gcc -S -O3 -ffast-math foo.c

$ cat foo.s
.file   "foo.c"
.section.text.unlikely,"x"
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl  foo
.deffoo;.scl2;  .type   32; .endef
.seh_proc   foo
foo:
pushq   %rsi
.seh_pushreg%rsi
pushq   %rbx
.seh_pushreg%rbx
subq$56, %rsp
.seh_stackalloc 56
movaps  %xmm6, 32(%rsp)
.seh_savexmm%xmm6, 32
.seh_endprologue
movapd  %xmm0, %xmm6
movq%r8, %rsi
movq%rdx, %rbx
callsin
movsd   %xmm0, (%rsi)
movapd  %xmm6, %xmm0
callcos
nop
movaps  32(%rsp), %xmm6
movsd   %xmm0, (%rbx)
addq$56, %rsp
popq%rbx
popq%rsi
ret
.seh_endproc
.section.text.unlikely,"x"
.LCOLDE0:
.text
.LHOTE0:
.ident  "GCC: (GNU) 5.3.0"
.defsin;.scl2;  .type   32; .endef
.defcos;.scl2;  .type   32; .endef

This works as expected:

$ cat bar.c
void bar(double t, double *x, double *y)
{
__builtin_sincos(t, x, y);
*x = *x + 1.;
}

$ gcc -O3 -S bar.c

$ cat bar.s
.file   "bar.c"
.section.text.unlikely,"x"
.LCOLDB1:
.text
.LHOTB1:
.p2align 4,,15
.globl  bar
.defbar;.scl2;  .type   32; .endef
.seh_proc   bar
bar:
pushq   %rbx
.seh_pushreg%rbx
subq$32, %rsp
.seh_stackalloc 32
.seh_endprologue
movq%rdx, %rbx
callsincos
movsd   .LC0(%rip), %xmm0
addsd   (%rbx), %xmm0
movsd   %xmm0, (%rbx)
addq$32, %rsp
popq%rbx
ret
.seh_endproc
.section.text.unlikely,"x"
.LCOLDE1:
.text
.LHOTE1:
.section .rdata,"dr"
.align 8
.LC0:
.long   0
.long   1072693248
.ident  "GCC: (GNU) 5.3.0"
.defsincos; .scl2;  .type   32; .endef




$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-cygwin/5.3.0/lto-wrapper.exe
Target: x86_64-unknown-cygwin
Configured with: ../gcc-5.3.0/configure --enable-languages=c,c++,fortran,lto
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic --enable-languages=c,c++,fortran,lto
--enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp
--disable-libitm --enable-libquadmath --enable-libquadmath-support
--enable-libssp --disable-symvers --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
Thread model: posix
gcc version 5.3.0 (GCC)

[Bug c++/69534] [6 Regression] openjade is miscompiled

[kdudka at redhat dot com]

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

--- Comment #10 from Kamil Dudka  ---
It makes sense to me.  Thanks for the explanation!

[Bug driver/66293] Support -Weverything to enable all warnings

[jeanmichael.celerier at gmail dot com]

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

Jean-Michaël Celerier  changed:

   What|Removed |Added

 CC||jeanmichael.celerier@gmail.
   ||com

--- Comment #3 from Jean-Michaël Celerier  ---
As a Clang user, -Weverything allowed me to remove terrible bugs that would not
crop up with -Wall -Wextra -Wfew-other-common-warnings.

For instance GCC 6 brings in many new warnings it seems. Well, it is a pity to
have to go through the manual to find the new warnings and enable them by hand
(very few people will actually do this, while it could certainly make some bugs
appear. Maybe it could prevent the next Heartbleed ?).

[Bug tree-optimization/69820] [6 Regression] Test miscompiled with -O3 option

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
As for the wrong-code, we used to emit:
...
  vect_cst_.23_105 = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
  vect_cst_.24_106 = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 };
  vect_cst_.25_107 = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
...
  vect_patt_37.22_108 = VEC_COND_EXPR ;
  vect_patt_37.22_109 = VEC_COND_EXPR ;
...
  vect__35.26_110 = VIEW_CONVERT_EXPR(vect_patt_37.22_108);
  vect__35.26_111 = VIEW_CONVERT_EXPR(vect_patt_37.22_109);
but now we emit incorrect:
  vect_cst__103 = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
...
  mask__7.22_104 = vect__5.20_100 != vect_cst__103;
  mask__7.22_105 = vect__5.21_102 != vect_cst__103;
  vect__35.23_106 = VIEW_CONVERT_EXPR(mask__7.22_104);
  vect__35.23_107 = VIEW_CONVERT_EXPR(mask__7.22_105);
The reason why the latter is wrong is that for non-zero short values it yields
0x instead of 1.

[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour

[jiwang at gcc dot gnu.org]

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

--- Comment #8 from Jiong Wang  ---
(In reply to Jakub Jelinek from comment #7)
>   {
> try
>   {
> ...
> D.2689 = (sizetype) D.2477;
> D.2690 = D.2689 + 1;
> D.2691 = D.2690 * 4;
> D.2692 = __builtin_alloca_with_align (D.2691, 32);
> c = D.2692;
> 
> Accessing an automatic variable from the caller inside of target region is
> wrong, it should have been made firstprivate during gimplification, which
> would allow it to work.

This testcase failed on arm-linux-gnueabihf also. What I observed is the first
parameter of __builtin_alloca_with_align is not initialized in the last tree
pass target-6.C.210t.optimized which looks like a direct result of above
gimplification bug.

[Bug c/69798] ICE on invalid code on x86_64-linux-gnu in c_parser_braced_init, at c/c-parser.c:4338

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/65479] sanitizer stack trace missing frames past #0 on powerpc64

[joakim.tjernlund at infinera dot com]

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

Joakim Tjernlund  changed:

   What|Removed |Added

 CC||joakim.tjernlund at infinera 
dot c
   ||om

--- Comment #13 from Joakim Tjernlund  ---
with gcc 4.9.3 an powerpc32 I sometimes get backtraces like this:
=
==2899==ERROR: AddressSanitizer: heap-use-after-free on address 0xb400091c at
pc 0xb3800120 bp 0xbf86a270 sp 0xbf86a288
READ of size 4 at 0xb400091c thread T0
==2899==AddressSanitizer: while reporting a bug found another one.Ignoring.
#0 0xb380011c (+0x11c)
#1 0xfb2aa10 in __asan_report_error
(/usr/lib/gcc/powerpc-unknown-linux-gnu/4.9.3/libasan.so.1+0x65a10)
#2 0xfb2bac8 in __asan_report_load4
(/usr/lib/gcc/powerpc-unknown-linux-gnu/4.9.3/libasan.so.1+0x66ac8)
#3 0xf3c028c in Icn_unregisterIf
(/opt/appl/cuappl04a-r27a-160209jt2//lib/libiciif.so.1+0x4c28c)

0xb400091c is located 2204 bytes inside of 2208-byte region
[0xb480,0xb4000920)
freed by thread T0 here:
#0 0xf3b9ba0 in Icn_removeEntry
(/opt/appl/cuappl04a-r27a-160209jt2//lib/libiciif.so.1+0x45ba0)

previously allocated by thread T0 here:
#0 0xf3c0870 in Icn_registerIf
(/opt/appl/cuappl04a-r27a-160209jt2//lib/libiciif.so.1+0x4c870)

SUMMARY: AddressSanitizer: heap-use-after-free ??:0 ??
Shadow bytes around the buggy address:
  0x368000d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x368000e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x368000f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x36800100: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x36800110: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x36800120: fd fd fd[fd]fa fa fa fa fa fa fa fa fa fa fa fa
  0x36800130: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36800140: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x36800150: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x36800160: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x36800170: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Contiguous container OOB:fc
  ASan internal:   fe
==2899==ABORTING

This backtrace is incomplete, could this bug be the cause?

[Bug tree-optimization/69820] [6 Regression] Test miscompiled with -O3 option

[jakub at gcc dot gnu.org]

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

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

As for the ICE, the following patch works for me.  VI_512 iterator is only used
in the vcond* patterns, therefore it is desirable to change them all this way.

[Bug tree-optimization/69820] [6 Regression] Test miscompiled with -O3 option

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
C runtime testcase:
unsigned int a[100];
long long int b[100];
unsigned short c[100];

__attribute__((noinline, noclone)) void
foo (void)
{
  int i;
  for (i = 0; i < 100; ++i)
b[i] = a[i] * (c[i] * (_Bool) c[i]);
}

int
main ()
{
  int i;
  if (__SIZEOF_INT__ * __CHAR_BIT__ != 32)
return 0;
  for (i = 0; i < 100; ++i)
{
  a[i] = 3489456818U;
  b[i] = 0x1eadbeefbeefdeadLL;
  c[i] = 38364;
}
  foo ();
  for (i = 0; i < 100; ++i)
if (b[i] != 0xed446af8U)
  __builtin_abort ();
  return 0;
}

[Bug tree-optimization/69820] [6 Regression] Test miscompiled with -O3 option

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
knl ICE:

int a[100], b[100];
short c[100];
void fn1() {
  for (int i = 0; i < 100; ++i)
b[i] = a[i] * (bool)c[i];
}

[Bug fortran/40165] Excessive warnings for REAL DO loops

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #13 from Dominique d'Humieres  ---
> Any point to keep this PR opened?

No feedback, closing as WONTFIX.

[Bug ipa/69589] [6 Regression] ICE in initialize_node_lattices, at ipa-cp.c:971

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor  ---
(In reply to kugan from comment #11)
> In remove_unreachable_nodes, just before ipa-cp, this node becomes local
> (address taken is false and local.local = true). After that, when
> ipa_propagate_frequency is run, which updates the frequency to zero. I think
> we should check the frequency at this point in time and remove such nodes.

If remove_unreachable_nodes keeps the node around for comdat reasons,
we cannot remove it just because it has zero estimated frequency
(unless remove_unreachable_nodes was wrong and should have removed the
node itself).

I think that remove_unreachable_nodes should either remove the node,
or not set it to local (or set something like force_output or
forced_by_abi, if it is some really weird case).

[Bug tree-optimization/69820] [6 Regression] Test miscompiled with -O3 option

[vsevolod.livinskij at frtk dot ru]

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

--- Comment #4 from Vsevolod Livinskiy  ---
Test case also cause internal compiler error when it is compiled for knl.

> g++ -march=knl -O3 repr.cpp
repr.cpp: In function ‘void foo()’:
repr.cpp:23:45: internal compiler error: in ix86_expand_sse_cmp, at
config/i386/i386.c:22702
 out_1 [i] = in_1 [i] * (out_4 [i] * (bool)out_4 [i]);
 ^~~
0xd0461e ix86_expand_sse_cmp
   
/export/users/gnutester/stability/svn/trunk/gcc/config/i386/i386.c:22702
0xd37344 ix86_expand_int_vcond(rtx_def**)
   
/export/users/gnutester/stability/svn/trunk/gcc/config/i386/i386.c:23398
0xee89d9 gen_vconduv32hiv32hi(rtx_def*, rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*)
   
/export/users/gnutester/stability/svn/trunk/gcc/config/i386/sse.md:11065
0x9fdf58 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/export/users/gnutester/stability/svn/trunk/gcc/optabs.c:7015
0x9fdf58 expand_insn(insn_code, unsigned int, expand_operand*)
/export/users/gnutester/stability/svn/trunk/gcc/optabs.c:7046
0x9fe700 expand_vec_cond_expr(tree_node*, tree_node*, tree_node*, tree_node*,
rtx_def*)
/export/users/gnutester/stability/svn/trunk/gcc/optabs.c:5622
0x863bc9 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/export/users/gnutester/stability/svn/trunk/gcc/expr.c:9343
0x78035e expand_gimple_stmt_1
/export/users/gnutester/stability/svn/trunk/gcc/cfgexpand.c:3641
0x78035e expand_gimple_stmt
/export/users/gnutester/stability/svn/trunk/gcc/cfgexpand.c:3702
0x7816ff expand_gimple_basic_block
/export/users/gnutester/stability/svn/trunk/gcc/cfgexpand.c:5708
0x786606 execute
/export/users/gnutester/stability/svn/trunk/gcc/cfgexpand.c:6323

[Bug target/68191] s390x Linux Split Stacks support

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #4 from David Edelsohn  ---
All of the patches have landed and the feature has been implemented.

[Bug other/69821] -fdebug-prefix-map doesn't affect gcc command line switches in DWARF DW_AT_producer.

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
It is not a regression and is user visible change, so I think changing it just
in GCC 6 is sufficient.

[Bug other/69821] -fdebug-prefix-map doesn't affect gcc command line switches in DWARF DW_AT_producer.

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #6 from Bernd Schmidt  ---
Should we backport this to 5?

[Bug c++/69826] New: problem with cilkplus pragma and preprocessor variable

[ycollette.nospam at free dot fr]

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

Bug ID: 69826
   Summary: problem with cilkplus pragma and preprocessor variable
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ycollette.nospam at free dot fr
  Target Milestone: ---

For cilkplus, the pragma cilk grainsize doesn't seems to accept preprocessor
variables.

Here is a small example:

test.cpp

#include 

#define CILK_FOR_GRAINSIZE 128

void CoinAbcScatterUpdate(int number)
{
  int result = 0;

#pragma cilk grainsize=CILK_FOR_GRAINSIZE
  cilk_for(int j=0; j < number; j+=2) {
result+=j;
  }
}

The compilation:

$ g++ -c -fcilkplus test.cpp -o test.o

The Error message:

test.cpp: Dans la fonction ‘void CoinAbcScatterUpdate(int)’:
test.cpp:9:24: erreur: ‘CILK_FOR_GRAINSIZE’ was not declared in this scope
 #pragma cilk grainsize=CILK_FOR_GRAINSIZE
^
test.cpp:9:9: erreur: invalid grainsize for _Cilk_for
 #pragma cilk grainsize=CILK_FOR_GRAINSIZE
 ^

If I replace #define CILK_FOR_GRAINSIZE 128 by int CILK_FOR_GRAINSIZE = 128;
then the compilation went fine.

[Bug c/69796] [6 Regression] ICE on invalid code in useless_type_conversion_p, at gimple-expr.c:83

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #2 from prathamesh3492 at gcc dot gnu.org ---
Hi,
I believe this happens because of setting TREE_TYPE (decl) to error_mark_node
in c_parser_translation_unit():

FOR_EACH_VEC_ELT (incomplete_record_decls, i, decl)
if (DECL_SIZE (decl) == NULL_TREE && TREE_TYPE (decl) != error_mark_node)
  {
error ("storage size of %q+D isn%'t known", decl);
TREE_TYPE (decl) = error_mark_node;
  }

this fails at useless_type_conversion_p():
inner_type = TYPE_MAIN_VARIANT (inner_type)
because inner_type == error_mark_node

I wonder what should be the right fix ?
Should the loop not set TREE_TYPE (decl) to error_mark_node
or we return true from useless_type_conversion_p if either outer_type or
inner_type is error_mark_node ?
Both approaches prevent the ICE.
I suppose not setting TREE_TYPE (decl) to error_mark_node in
c_parser_translation_unit() would be better,
since this could again show up at a different place in middle-end ?

Thanks,
Prathamesh

[Bug c/69819] [4.9/5/6 Regression] ICE on invalid code on x86_64-linux-gnu in tree check: expected function_type or method_type, have array_type in function_args_iter_init, at tree.h:4536

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Looks like a bug in the C FE, thus mine.

[Bug libstdc++/69794] [5/6 Regression] std::regex_search match failure with regex object with flags grep|icase

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-15
 CC||jakub at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
fails.

[Bug tree-optimization/69811] [5/6 Regression] A gcc folding issue at -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
I don't think we should guarantee folding here at -O0, it is purely an
optimization.  A different thing is what happens with constexpr, but there it
doesn't seem to be a regression.

[Bug c/69824] [4.9/5/6 Regression] internal compiler error in unshare_body

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/69824] [4.9/5/6 Regression] internal compiler error in unshare_body

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

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

[Bug c/69825] False -Wdiv-by-zero warning when it should be short-circuited

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-15
 Ever confirmed|0   |1

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

[Bug c/69825] False -Wdiv-by-zero warning when it should be short-circuited

[dgilbert at redhat dot com]

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

--- Comment #1 from Dr. David Alan Gilbert  ---
Oops, forgot to mention; this is on fedora 23 x86-64.

[Bug c/69824] [4.9/5/6 Regression] internal compiler error in unshare_body

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Started with r186687 I think.

[Bug tree-optimization/69823] [6 Regression] internal compiler error: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:445

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug tree-optimization/69822] [6 Regression] internal compiler error: in get_rename, at graphite-isl-ast-to-gimple.c:1202

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug tree-optimization/69820] [6 Regression] Test miscompiled with -O3 option

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf  ---
Started with r230098.

[Bug c/69825] New: False -Wdiv-by-zero warning when it should be short-circuited

[dgilbert at redhat dot com]

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

Bug ID: 69825
   Summary: False -Wdiv-by-zero warning when it should be
short-circuited
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dgilbert at redhat dot com
  Target Milestone: ---

gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC) 

$ cat bug.c
void bug(void)
{
static unsigned int counter = 0;
static const unsigned int frequency = 0;

if (frequency && (!(counter % frequency))) {
}

counter++;
}


$ gcc bug.c -Wall -c -O2
bug.c: In function ‘bug’:
bug.c:6:33: warning: division by zero [-Wdiv-by-zero]
 if (frequency && (!(counter % frequency))) {
 ^


I'm told it also triggers on trunk, 4.6, 5.3 but not 4.8.5

[Bug testsuite/69586] [6 Regression] FAIL: gcc.dg/uninit-21.c for target defaulting to short enum

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
So first half of a patch is

Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c  (revision 233418)
+++ gcc/tree-vrp.c  (working copy)
@@ -5449,7 +5466,7 @@ register_edge_assert_for_2 (tree name, e
   cst2 = NULL_TREE;
   if (rhs_code == BIT_AND_EXPR
  || (CONVERT_EXPR_CODE_P (rhs_code)
- && TREE_CODE (TREE_TYPE (val)) == INTEGER_TYPE
+ && INTEGRAL_TYPE_P (TREE_TYPE (val))
  && TYPE_UNSIGNED (TREE_TYPE (val))
  && TYPE_PRECISION (TREE_TYPE (gimple_assign_rhs1 (def_stmt)))
 > prec))

but then BIT_AND handling in extract_range_from_binary_1 needs to be improved
for ~[0, 0] & [255, 255] as splitting into

  [-INT_MIN, -1] & 255 ^ [1, INT_MAX] & 255

can never yield a good answer.

I guess the issue is that we arrive with ~[0, 0] from the

  (unsigned char)_9 != 0

test in the first place which doesn't give us enough info to improve

  _9 & 255

[Bug c++/69797] [4.9/5/6 Regression] ICE on invalid code on x86_64-linux-gnu in operator[], at vec.h:714

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug c/69824] New: [4.9/5/6 Regression] internal compiler error in unshare_body

[mpolacek at gcc dot gnu.org]

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

Bug ID: 69824
   Summary: [4.9/5/6 Regression] internal compiler error in
unshare_body
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

int bar() { return foo(); }
void baz(int c[foo()]) { return; }

$ ./cc1 -quiet x.c
x.c: In function ‘bar’:
x.c:1:23: warning: implicit declaration of function ‘foo’
[-Wimplicit-function-declaration]
int bar() { return foo(); }
   ^~~
x.c: In function ‘baz’:
x.c:2:9: internal compiler error: Segmentation fault
void baz(int c[foo()]) { return; }
 ^~~
0xb1cd1f crash_signal
/home/marek/src/gcc/gcc/toplev.c:335
0x8bb931 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/marek/src/gcc/gcc/tree.h:3119
0x8bb931 unshare_body
/home/marek/src/gcc/gcc/gimplify.c:876
0x8bb9c8 unshare_body
/home/marek/src/gcc/gcc/gimplify.c:883
0x8c8e67 gimplify_body(tree_node*, bool)
/home/marek/src/gcc/gcc/gimplify.c:11278
0x8c9516 gimplify_function_tree(tree_node*)
/home/marek/src/gcc/gcc/gimplify.c:11450
0x74cd77 cgraph_node::analyze()
/home/marek/src/gcc/gcc/cgraphunit.c:625
0x74ffa5 analyze_functions
/home/marek/src/gcc/gcc/cgraphunit.c:1080
0x750d1c symbol_table::finalize_compilation_unit()
/home/marek/src/gcc/gcc/cgraphunit.c:2534
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/69796] [6 Regression] ICE on invalid code in useless_type_conversion_p, at gimple-expr.c:83

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-15
 CC||jakub at gcc dot gnu.org,
   ||prathamesh3492 at gcc dot 
gnu.org
 Ever confirmed|0   |1

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

[Bug tree-optimization/69595] [6 Regression] Bogus -Warray-bound warning due to missed optimization

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Feb 15 13:49:42 2016
New Revision: 233425

URL: https://gcc.gnu.org/viewcvs?rev=233425=gcc=rev
Log:
2016-02-15  Richard Biener  

PR tree-optimization/69595
* match.pd: Complete range test simplification to true.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd

[Bug testsuite/69586] [6 Regression] FAIL: gcc.dg/uninit-21.c for target defaulting to short enum

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #3 from Richard Biener  ---
So with -fshort-enums clnt_stat is unsigned QImode and we have before VRP/DOM

  :
  _9 = do_ypcall_tr ();
  result_10 = (clnt_stat) _9;
  if (result_10 != 0)
goto ;
  else
goto ;

  :
  _11 = _9 & 255;
  goto ;

  :
  _12 = __builtin_strdup ("foo");

  :
  # _13 = PHI <_11(3), 0(4)>
  # master_19 = PHI 
  if (_13 != 0)

where we expect to eventually jump-thread the _13 != 0 test.  VRP fails to
add asserts for _9 here because of another INTEGER_TYPE check.  Unfortunately
fixing that doesn't make us jump-thread this as we get

Visiting statement:
_21 = ASSERT_EXPR <_9, (unsigned int) _9 + 4294967295 <= 4294967294>;
Intersecting
  ~[0, 0]  EQUIVALENCES: { _9 } (1 elements)
and
  VARYING
to
  ~[0, 0]  EQUIVALENCES: { _9 } (1 elements)
Found new range for _21: ~[0, 0]
interesting_ssa_edges: adding SSA use in _11 = _21 & 255;
marking stmt to be not simulated again

Visiting statement:
_11 = _21 & 255;
Meeting
  [0, 255]
and
  [0, 255]
to
  [0, 255]
Intersecting
  [0, 255]
and
  [-INF, +INF]
to
  [0, 255]
Found new range for _11: [0, 255]

this is because BIT_AND_EXPR handling doesn't handle this case very well.

integer

  ~[0, 0] & 255

is done via [-INT_MIN, -1] & 255  ^  [1, INT_MAX] & 255

and [1, INT_MAX] & 255 results in [0, 255] instead of in [1, INT_MAX].

It may make sense to special-case that & 255 (zero-extend from smaller
precision).  Or BIT_AND with anti-ranges in general.

[Bug tree-optimization/69802] [4.9/5/6 Regression] gcc ICE at -O1 and above on valid code on x86_64-linux-gnu with “seg fault”

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug other/69821] -fdebug-prefix-map doesn't affect gcc command line switches in DWARF DW_AT_producer.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Indeed.  This has been fixed with r231835.

[Bug tree-optimization/69732] Vectorization runtime alias check due to failed dependence analysis

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|6.0 |---
Summary|[6 Regression] Missed   |Vectorization runtime alias
   |vectorization due to failed |check due to failed
   |dependence analysis |dependence analysis

[Bug c/69819] [4.9/5/6 Regression] ICE on invalid code on x86_64-linux-gnu in tree check: expected function_type or method_type, have array_type in function_args_iter_init, at tree.h:4536

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug c/69819] [4.9/5/6 Regression] ICE on invalid code on x86_64-linux-gnu in tree check: expected function_type or method_type, have array_type in function_args_iter_init, at tree.h:4536

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #3 from Richard Biener  ---
Surely not the former.  But

(gdb) p debug_tree (current_function_decl)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x7688f7e0
precision 32 min  max 
pointer_to_this >

is clearly bogus.

[Bug tree-optimization/69820] [6 Regression] Test miscompiled with -O3 option

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |6.0

[Bug target/69804] [5/6] ICE with -fsanitize=undefined -fcheck-pointer-bounds -mmpx

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org

--- Comment #2 from Ilya Enkovich  ---
PR65705 reports the same problem for -fsanitize=signed-integer-overflow and
-fsanitize=null.  And PR65044 reported it for -fsanitize=address.

[Bug other/69821] -fdebug-prefix-map doesn't affect gcc command line switches in DWARF DW_AT_producer.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
I think it makes sense to omit this by default.  In fact it is already in GCC
6.

  case OPT_fdebug_prefix_map_:
/* Ignore these.  */

[Bug tree-optimization/69822] [6 Regression] internal compiler error: in get_rename, at graphite-isl-ast-to-gimple.c:1202

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|aarch64 |aarch64, x86_64-*-*
   Priority|P4  |P3
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-15
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

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

[Bug tree-optimization/69719] [5 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Bug 69783 Summary: [6 Regression] Loop is not vectorized after r233212
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69783

   What|Removed |Added

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

[Bug tree-optimization/69783] [6 Regression] Loop is not vectorized after r233212

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/69823] [6 Regression] internal compiler error: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:445

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-15
   Target Milestone|--- |6.0
Summary|internal compiler error: in |[6 Regression] internal
   |create_pw_aff_from_tree, at |compiler error: in
   |graphite-sese-to-poly.c:445 |create_pw_aff_from_tree, at
   ||graphite-sese-to-poly.c:445
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Works with GCC 5.