[Bug c++/77542] __attribute__((warn_unused_result)) ignored on function template

[afenkart at gmail dot com]

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

--- Comment #2 from afenkart at gmail dot com ---
(In reply to Andrew Pinski from comment #1)
> Do you have a full example which shows the issue?
> In your case does ReturnValue  have a copy constructor?
> If so this is a dup of bug 38172.  Note C++17 defines [[nodiscard]] which
> should be used here instead really but it is only implemented in GCC 7.


It doesn't seem a duplicate of 38172, since the compiler emits a warning when
returning (non-trivial) struct. See attached example.

[Bug c++/77542] __attribute__((warn_unused_result)) ignored on function template

[afenkart at gmail dot com]

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

--- Comment #3 from afenkart at gmail dot com ---
Created attachment 39608
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39608&action=edit
excerpt of code showing problem

[Bug c++/77563] [5/6/7 Regression] explicit constructor breaks narrowing conversion overload resolution

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-13
  Known to work||4.5.4
Summary|explicit constructor breaks |[5/6/7 Regression] explicit
   |narrowing conversion|constructor breaks
   |overload resolution |narrowing conversion
   ||overload resolution
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.2.0, 7.0

--- Comment #2 from Jonathan Wakely  ---
4.5.4 got this right:

ex.cc: In function ‘int main()’:
ex.cc:15:7: error: conversion from ‘long int’ to ‘A’ is ambiguous
ex.cc:6:3: note: candidates are: A::A(uint32_t)
ex.cc:5:3: note: A::A(int32_t)

Since GCC 4.6 the error has been misleading, and since GCC 6 it's
accepts-invalid.

[Bug lto/77511] internal compiler error: in get_ptr_info

[zheltonozhskiy at gmail dot com]

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

--- Comment #3 from Evgenii Zheltonozhskii  ---
The files are too big so here is link:
https://www.dropbox.com/sh/dz1zeh5dgn3tmxw/AAAOcPmn59O166uqieYmLYMca?dl=0

Using built-in specs.
COLLECT_GCC=C:\PROGRA~1\MINGW-~1\X86_64~1.0-P\mingw64\bin\gcc.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-6.2.0/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysroot=/c/mingw620/x86_64-620-posix-seh-rt_v5-rev0/mingw64
--enable-shared --enable-static --disable-multilib
--enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes
--enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto
--enable-graphite --enable-checking=release --enable-fully-dynamic-string
--enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes
--disable-isl-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug
--enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls
--disable-werror --disable-symvers --with-gnu-as --with-gnu-ld
--with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/c/mingw620/prerequisites/x86_64-w64-mingw32-static
--with-mpfr=/c/mingw620/prerequisites/x86_64-w64-mingw32-static
--with-mpc=/c/mingw620/prerequisites/x86_64-w64-mingw32-static
--with-isl=/c/mingw620/prerequisites/x86_64-w64-mingw32-static
--with-pkgversion='x86_64-posix-seh-rev0, Built by MinGW-W64 project'
--with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-I/c/mingw620/x86_64-620-posix-seh-rt_v5-rev0/mingw64/opt/include
-I/c/mingw620/prerequisites/x86_64-zlib-static/include
-I/c/mingw620/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2
-pipe -I/c/mingw620/x86_64-620-posix-seh-rt_v5-rev0/mingw64/opt/include
-I/c/mingw620/prerequisites/x86_64-zlib-static/include
-I/c/mingw620/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS=
LDFLAGS='-pipe -L/c/mingw620/x86_64-620-posix-seh-rt_v5-rev0/mingw64/opt/lib
-L/c/mingw620/prerequisites/x86_64-zlib-static/lib
-L/c/mingw620/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 6.2.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 
COLLECT_GCC_OPTIONS='-I'
'C:/Users/eabes/Downloads/skypeopensource2-4870457f725b332ec52d6d72e688c9beddbdd87b/skypeopensource2-4870457f725b332ec52d6d72e688c9beddbdd87b/include'
'-std=c11' '-O3' '-fstrict-aliasing' '-flto' '-fno-fat-lto-objects'
'-fomit-frame-pointer' '-march=native' '-w' '-save-temps' '-v' '-o'
'CMakeFiles\crypto.dir\md5.c.obj' '-c'

C:/PROGRA~1/MINGW-~1/X86_64~1.0-P/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/6.2.0/cc1.exe
-E -quiet -v -I
C:/Users/eabes/Downloads/skypeopensource2-4870457f725b332ec52d6d72e688c9beddbdd87b/skypeopensource2-4870457f725b332ec52d6d72e688c9beddbdd87b/include
-iprefix
C:/PROGRA~1/MINGW-~1/X86_64~1.0-P/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/
-D_REENTRANT
C:\Users\eabes\Downloads\skypeopensource2-4870457f725b332ec52d6d72e688c9beddbdd87b\skypeopensource2-4870457f725b332ec52d6d72e688c9beddbdd87b\crypto\md5.c
-march=broadwell -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16
-msahf -mmovbe -mno-aes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma
-mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt
-mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr
-mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf
-mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq
-mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-clwb
-mno-pcommit -mno-mwaitx -mno-clzero -mno-pku --param l1-cache-size=32 --param
l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=broadwell -std=c11 -w
-fstrict-aliasing -flto -fno-fat-lto-objects -fomit-frame-pointer -O3
-fpch-preprocess -o md5.i

[Bug c++/77563] [5/6/7 Regression] explicit constructor breaks narrowing conversion overload resolution

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Reduced:

struct A {
  A(int) {}
  A(unsigned) {}  // Comment to make it work

  explicit A(long) {}  // Comment to make it work
};

void f(A) { }

int main() {
  f(2);
  f(3l);
}

[Bug middle-end/77475] unnecessary or misleading context in reporting command line problems

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 13 08:45:36 2016
New Revision: 240107

URL: https://gcc.gnu.org/viewcvs?rev=240107&root=gcc&view=rev
Log:
PR middle-end/77475
* opts.h (candidates_list_and_hint): Declare.
* opts-common.c (candidates_list_and_hint): New function.
(cmdline_handle_error): Use it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/opts-common.c
trunk/gcc/opts.h

[Bug c++/77563] [5/6/7 Regression] explicit constructor breaks narrowing conversion overload resolution

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |5.5

--- Comment #4 from Jakub Jelinek  ---
The 4.5 -> 4.6 difference appeared in r159332:

./cc1plus.159325 -quiet -std=c++0x pr77563.C
pr77563.C: In function ‘int main()’:
pr77563.C:12:7: error: conversion from ‘long int’ to ‘A’ is ambiguous
pr77563.C:3:3: note: candidates are: A::A(unsigned int)
pr77563.C:2:3: note: A::A(int)
./cc1plus.159332 -quiet -std=c++0x pr77563.C
pr77563.C: In function ‘int main()’:
pr77563.C:12:7: error: converting to ‘A’ from initializer list would use
explicit constructor ‘A::A(long int)’

then r229283 started to ICE on it instead, and finally r236395 fixed the ICE,
but emitted a note without corresponding error/warning:

./cc1plus.236395 -quiet -std=c++0x pr77563.C
pr77563.C: In function ‘int main()’:
pr77563.C:8:6: note:   initializing argument 1 of ‘void f(A)’
 void f(A) { }
  ^

[Bug rtl-optimization/77499] [7 Regression] Regression after code-hoisting, due to combine pass failing to evaluate known value range

[avieira at gcc dot gnu.org]

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kugan at gcc dot gnu.org

--- Comment #12 from avieira at gcc dot gnu.org ---
I heard Kugan was working on getting rid of superfluous zero_extends. Adding
him to the watch list.

@Kugan: Could your work help this case? And when do you plan to have it
submitted?

[Bug c++/77554] ICE on valid C++11 code with variadic template function: tree check: expected class ‘expression’, have ‘type’ (integer_type) in tree_operand_check, at tree.h:3524

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This seems to ICE all the way back to something in between r122750 and
r122800, where the former would reject it because of unimplemented variadic
template support or so and the latter already has:
pr77554.C:3: internal compiler error: tree check: expected class ‘expression’,
have ‘type’ (integer_type) in unify_pack_expansion, at cp/pt.c:11845
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
and even latest trunk emits the same thing, just with backtrace etc.

[Bug c++/77575] Bogus error when alias template yielding a reference type used as template template argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-13
 Ever confirmed|0   |1

[Bug target/70557] uint64_t zeroing on 32-bit hardware

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

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

--- Comment #7 from Andreas Schwab  ---
When compiling for m68k the compiler already generates the latter.

[Bug c++/77549] [7 Regression] ICE on invalid C++ code that references undeclared variable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  In the names chain, there can be not just decls and
error_mark_nodes, but also TREE_LIST (either for decls appearing from using, or
for OVERLOADs), and for such wrapped OVERLOADs we need to look through them too
to be able to look at DECL_NAME.

[Bug middle-end/77574] Wrong if condition in predict.c

[mliska at suse dot cz]

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

--- Comment #1 from Martin Liška  ---
On 09/13/2016 12:30 AM, bernd.edlinger at hotmail dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77574
> 
> Bug ID: 77574
>Summary: Wrong if condition in predict.c
>Product: gcc
>Version: 7.0
> Status: UNCONFIRMED
>   Severity: normal
>   Priority: P3
>  Component: middle-end
>   Assignee: unassigned at gcc dot gnu.org
>   Reporter: bernd.edlinger at hotmail dot de
>   Target Milestone: ---
> 
> Hi,
> 
> an experimental version of my -Wint-in-bool-context patch
> found this apparently wrong code in predict.c
> 
> ../../gcc-trunk/gcc/predict.c: In function 'void force_edge_cold(edge, bool)':
> ../../gcc-trunk/gcc/predict.c:3726:36: error: ?: using integer constants in
> boolean context [-Werror=int-in-bool-context]
>if (e->probability <= impossible ? PROB_VERY_UNLIKELY : 0
>~^~~~
>&& (!impossible || !e->count))
>~ 
> 
> 
> I think it is meant this way:
>if (e->probability <= (impossible ? PROB_VERY_UNLIKELY : 0)
>&& (!impossible || !e->count))
> 

Hello Bernd.

Thanks for the PR, as well the suggested patch. The patch works for me,
I'm going to test it and submit to mailing list. Please ping me if you're
accidentally doing the same?

Thanks,
Martin

[Bug c++/77548] ICE on invalid C++ code with overloaded functions: in instantiate_type, at cp/class.c:8270

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
In r147630 this has been rejected with:
pr77548.C: In member function ‘int S::f(int)’:
pr77548.C:6: error: could not convert ‘((S*)this)->S::f’ to ‘bool’
r147702 already ICEs, so likely r147638 or r147677 introduced the ICE.

The current trunk rejects it again with:
pr77548.C: In member function ‘int S::f(int)’:
pr77548.C:4:31: error: cannot resolve overloaded function ‘f’ based on
conversion to type ‘bool’
   int f (int)  { return f ? : 1; }
   ^
will bisect when that happened later.

clang++ emits:
pr77548.C:4:25: error: reference to non-static member function must be called;
did you mean to call it with no arguments?
  int f (int)  { return f ? : 1; }
^
 ()
pr77548.C:4:7: note: possible target for call
  int f (int)  { return f ? : 1; }
  ^
pr77548.C:3:7: note: possible target for call
  int f (void) { return 0; }
  ^
1 error generated.

[Bug tree-optimization/77514] [6/7 Regression] ICE in VN_INFO_GET, at tree-ssa-sccvn.c:406 w/ -O2 (and above)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/77511] internal compiler error: in get_ptr_info

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
  Component|lto |tree-optimization
   Host||x86_64-w64-mingw32

--- Comment #4 from Richard Biener  ---
Not clear what pass is doing the get_ptr_info without a backtrace.

[Bug c++/77522] ICE on invalid code C++14 code: in tsubst_decl, at cp/pt.c:12447

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|5.5 |---

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-13
 Ever confirmed|0   |1

[Bug c++/77542] __attribute__((warn_unused_result)) ignored on function template

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug tree-optimization/77544] [6/7 Regression] segfault at -O0 - infinite loop in simplification

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|[Regression 6/7] segfault   |[6/7 Regression] segfault
   |at -O0 - infinite loop in   |at -O0 - infinite loop in
   |simplification  |simplification

--- Comment #4 from Richard Biener  ---
Yes, that's somewhat unavoidable (unfortunately -- I've seen it from
optimization at least).

[Bug c++/77548] ICE on invalid C++ code with overloaded functions: in instantiate_type, at cp/class.c:8270

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|5.5 |---

[Bug tree-optimization/77544] [6/7 Regression] segfault at -O0 - infinite loop in simplification

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Started with r233216.

[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
The patch should at least work (loads are similarly affected).  At some point
we want some infrastructure in the middle-end to chose a better fallback (as
Andrew says, if possible we can use the alias-set of the containing aggregate
for example).

[Bug c++/77554] ICE on valid C++11 code with variadic template function: tree check: expected class ‘expression’, have ‘type’ (integer_type) in tree_operand_check, at tree.h:3524

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|5.5 |---

[Bug middle-end/77574] Wrong if condition in predict.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-13
 Ever confirmed|0   |1

[Bug middle-end/77568] [7 regression] CSE/PRE/Hoisting blocks common instruction contractions

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Note that all "bad" transforms can be done by users on the source level
already.  So the _only_ proper solution is to handle the situation in the
passes that now refuse to do an important optimization (like combine).

[Bug c++/77578] New: Compiler crashes with segmentation fault

[tomas.oberhuber at fjfi dot cvut.cz]

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

Bug ID: 77578
   Summary: Compiler crashes with segmentation fault
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tomas.oberhuber at fjfi dot cvut.cz
  Target Milestone: ---

When compiling the attached file main.cpp as

g++ main.cpp -fopenmp

I get the following 

main.cpp: In static member function ‘static void GridTraverser
>::processEntities(GridTraverser >::CoordinatesType,
GridTraverser >::CoordinatesType)’:
main.cpp:28:56: internal compiler error: Segmentation fault
  entity.getCoordinates().y() <= end.y();
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccqklNTb.out file, please attach this to
your bugreport.
ERROR: Cannot create report: [Errno 17] File exists:
'/var/crash/_usr_lib_gcc_x86_64-linux-gnu_4.8_cc1plus.1000.crash'

It happens on gcc 5.4.0ubuntu~16.04.2 and also on older gcc
4.8.5ubuntu~14.04.1.

Tomas Oberhuber.

[Bug c++/77578] Compiler crashes with segmentation fault

[tomas.oberhuber at fjfi dot cvut.cz]

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

--- Comment #1 from Tomas Oberhuber  ---
Created attachment 39610
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39610&action=edit
main.cpp

[Bug rtl-optimization/77541] [7 Regression] wrong code with 512bit vectors of int128 @ -O1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r239511, though as said before, it is likely a LRA bug rather than
backend bug.

[Bug c++/77578] [5 Regression] Compiler crashes with segmentation fault

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.2.1, 7.0
   Keywords||ice-on-invalid-code
   Last reconfirmed||2016-09-13
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Compiler crashes with   |[5 Regression] Compiler
   |segmentation fault  |crashes with segmentation
   ||fault
  Known to fail||5.4.1

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed on 5.4.1.
On trunk and 6 we get a normal error:
ice.cpp: In static member function ‘static void GridTraverser
>::processEntities(GridTraverser >::CoordinatesType,
GridTraverser >::CoordinatesType)’:
ice.cpp:29:24: error: expected ‘)’ before ‘.’ token
  entity.getCoordinates().y()++ )


On 5.4.1 the ICE backtrace is:
ice.cpp:28:56: internal compiler error: Segmentation fault
  entity.getCoordinates().y() <= end.y();
^
0xca159f crash_signal
$SRC/gcc/toplev.c:383
0x6dc1e2 cp_parser_omp_for_loop
$SRC/gcc/cp/parser.c:30616
0x6fd575 cp_parser_omp_for
$SRC/gcc/cp/parser.c:30861
0x70b88f cp_parser_omp_parallel
$SRC/gcc/cp/parser.c:31040
0x6de5c5 cp_parser_omp_construct
$SRC/gcc/cp/parser.c:32597
0x6e189a cp_parser_pragma
$SRC/gcc/cp/parser.c:33141
0x70526c cp_parser_statement
$SRC/gcc/cp/parser.c:9808
0x705e4e cp_parser_statement_seq_opt
$SRC/gcc/cp/parser.c:10115
0x705f96 cp_parser_compound_statement
$SRC/gcc/cp/parser.c:10069
0x70524d cp_parser_statement
$SRC/gcc/cp/parser.c:9797
0x705e4e cp_parser_statement_seq_opt
$SRC/gcc/cp/parser.c:10115
0x705f96 cp_parser_compound_statement
$SRC/gcc/cp/parser.c:10069
0x706203 cp_parser_function_body
$SRC/gcc/cp/parser.c:19229
0x706203 cp_parser_ctor_initializer_opt_and_function_body
$SRC/gcc/cp/parser.c:19265
0x7070e0 cp_parser_function_definition_after_declarator
$SRC/gcc/cp/parser.c:23525
0x70a7d0 cp_parser_late_parsing_for_member
$SRC/gcc/cp/parser.c:24244
0x6e3034 cp_parser_class_specifier_1
$SRC/gcc/cp/parser.c:20078
0x6e3034 cp_parser_class_specifier
$SRC/gcc/cp/parser.c:20108
0x6e3034 cp_parser_type_specifier
$SRC/gcc/cp/parser.c:14727
0x6f6ec9 cp_parser_decl_specifier_seq
$SRC/gcc/cp/parser.c:11958
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++/77578] [5 Regression] ICE in cp_parser_omp_for_loop (cp/parser.c:29404)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
 CC||marxin at gcc dot gnu.org
  Known to work|6.2.1, 7.0  |
   Target Milestone|--- |5.5
Summary|[5 Regression] Compiler |[5 Regression] ICE in
   |crashes with segmentation   |cp_parser_omp_for_loop
   |fault   |(cp/parser.c:29404)
  Known to fail|5.4.1   |

--- Comment #3 from Martin Liška  ---
Confirmed, the ICE started with 4.7.0, as was fixed by r228777, thus GCC 6.x+
works fine.

[Bug middle-end/77568] [7 regression] CSE/PRE/Hoisting blocks common instruction contractions

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Richard Biener from comment #6)
> Note that all "bad" transforms can be done by users on the source level
> already.  So the _only_ proper solution is to handle the situation in the
> passes that now refuse to do an important optimization (like combine).

For an example take:
float f(float x, float y, float z, int a)
{
   float t = y * z;
   if (a > 100)
 x += t;
   else
 x -= t;
   return x;
}

Note we are able to optimize the follow (use -O2) to use fmadds:
float f(float x, float y, float z, int a)
{
   float t = y * z;
   x += t;
   x -= t;
   return x;
}

 CUT 
and it is optimized in the widening_mul pass (which includes the FMA
optimization pass).

[Bug middle-end/77574] Wrong if condition in predict.c

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger  ---
(In reply to Martin Liška from comment #1)
> Hello Bernd.
> 
> Thanks for the PR, as well the suggested patch. The patch works for me,
> I'm going to test it and submit to mailing list. Please ping me if you're
> accidentally doing the same?
> 
> Thanks,
> Martin

You are welcome.

I need to work a bit more on the warning patch,
so any help with fixing the fall-out would be appreciated.


Thanks
Bernd.

[Bug middle-end/77568] [7 regression] CSE/PRE/Hoisting blocks common instruction contractions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||FIXME

--- Comment #8 from Andrew Pinski  ---
The code in tree-ssa-math-opts.c has the following comment in it:
  /* For now restrict this operations to single basic blocks.  In theory
 we would want to support sinking the multiplication in
 m = a*b;
 if ()
   ma = m + c;
 else
   d = m;
 to form a fma in the then block and sink the multiplication to the
 else block.  */
  if (gimple_bb (use_stmt) != gimple_bb (mul_stmt))
return false;

[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance

[bernd.edlinger at hotmail dot de]

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

--- Comment #16 from Bernd Edlinger  ---
(In reply to Richard Biener from comment #15)
> The patch should at least work (loads are similarly affected).  At some
> point we want some infrastructure in the middle-end to chose a better
> fallback (as Andrew says, if possible we can use the alias-set of the
> containing aggregate for example).

Good.  Then I go ahead and look for a way how to fix all of the different
load and store code path.  If the whole group does not agree in the
alias_set I would fall back to ptr_type_node, I think if I put that
code in an extra function it can be changed later to the alias-set
of the containing aggregate.

[Bug c/77531] __attribute__((alloc_size(1,2))) could also warn on multiplication overflow

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
I guess the question is
1) in which pass to do this (during expansion of calls?); for SSA_NAMEs it
could perhaps use get_range_info and warn if it would always overflow (i.e. if
the minimum of arg1's range * minimum of arg2's range overflows)
2) agree on types the computation happens in; tree-object-size.c right now
casts the arguments regardless of type to sizetype, so size_t at the source
level; so, shall we do such casts and perform multiplication in size_t, or in
some other type (e.g. if both arguments are int, in int, etc.; what to do if
the arguments have different type)?

[Bug target/77579] New: Missed multiple add (int) for CSEd case

[pinskia at gcc dot gnu.org]

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

Bug ID: 77579
   Summary: Missed multiple add (int) for CSEd case
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

Take:
float g(float);
void f(float x, float y, float z, float *s)
{
   float t = y * z;
   s[0] = t+x;
   s[1] = x - t;
}


--- CUT ---
This works at -O2.  Now if you change float to int (-Dfloat=int), we don't get
madd/msub but if we disable either stores, we do get them.

This might be solved by changing "madd" to "fma4" (and making sure
the correct order of the operands).  Obviously I have not tried it yet and
might not have time any time soon.

[Bug lto/77576] gcc-ar doesn't work if all options are read from file

[likan_999.student at sina dot com]

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

--- Comment #2 from likan_999.student at sina dot com ---
Andrew, do you how I can tell whether plugin has been picked by successfully?
Also, if I use ar, do I need to pass it some flag, e.g. --plugin=something, or
it will just work if it is used normally, e.g. ar rcsD some.a some.o ?

[Bug target/77579] Missed multiple add (int) for CSEd case

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Just so there is no confussion on the testcase here it is without need the -D
option:
void f(int x, int y, int z, int *s)
{
   int t = y * z;
   s[0] = t + x;
   s[1] = x - t;
}

[Bug middle-end/77568] [7 regression] CSE/PRE/Hoisting blocks common instruction contractions

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
Note the integer testcase (-Dfloat=int) for the first testcase here has more
issues than the float case (since there is no fma opcode being defined for
aarch64) but that is being tracked as bug 77579.

[Bug target/77526] [7 Regression] ICE: in verify_dominators, at dominance.c:1039 with -mstringop-strategy=byte_loop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-13
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug lto/77576] gcc-ar doesn't work if all options are read from file

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to likan_999.student from comment #2)
> Andrew, do you how I can tell whether plugin has been picked by
> successfully? Also, if I use ar, do I need to pass it some flag, e.g.
> --plugin=something, or it will just work if it is used normally, e.g. ar
> rcsD some.a some.o ?

If you install the lto plugin in the correct plugins directory (I can't
remember off hand where it is located, you can use strace to see which
directories are being search).  And yes you don't need any options pass to ar,
objdump, nm, etc.
You can use strace to see if the plugin is being located correctly.

[Bug middle-end/77580] New: Improve devirtualization

[wdijkstr at arm dot com]

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

Bug ID: 77580
   Summary: Improve devirtualization
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wdijkstr at arm dot com
  Target Milestone: ---

A commonly used benchmark contains a hot loop which calls one of 2 virtual
functions via a static variable which is set just before. A reduced example is:

int f1(int x) { return x + 1; }
int f2(int x) { return x + 2; }

static int (*virt)(int);

int f(int *p, int n, int x)
{
  int i;
  if (x > 10)
virt = f1;
  else
virt = f2;
  for (i = 0; i < n; i++)
p[i] = virt (i);
}

This is obviously very stupid code, however GCC could do better. virt is not
address-taken, neither f1 nor f2 make a call, so virt is effectively a local
variable. So the loop could be transformed to p[i] = (x > 10) ? f1 (i) : f2
(i); to enable inlining after which the if can be lifted:

int f_opt(int *p, int n, int x)
{
  int i;
  if (x > 10)
virt = f1;
  else
virt = f2;
  if (x > 10)
for (i = 0; i < n; i++)
  p[i] = f1 (i);
  else
for (i = 0; i < n; i++)
  p[i] = f2 (i);
}

[Bug middle-end/77580] Improve devirtualization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-13
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
To some extend this is loop versioning.  There is another bug where we don't
need the versioning and GCC does not devirtualization the loop but I can't find
it right now; this bug should depend on that bug.

Anyways confirmed.

[Bug tree-optimization/77580] Improve devirtualization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|middle-end  |tree-optimization
   Severity|normal  |enhancement

[Bug c/77531] __attribute__((alloc_size(1,2))) could also warn on multiplication overflow

[crrodriguez at opensuse dot org]

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

--- Comment #2 from Cristian Rodríguez  ---
(In reply to Jakub Jelinek from comment #1)
> I guess the question is
> 1) in which pass to do this (during expansion of calls?); for SSA_NAMEs it
> could perhaps use get_range_info and warn if it would always overflow (i.e.
> if the minimum of arg1's range * minimum of arg2's range overflows)

At whichever stage the compiler is able to catch more mistakes I guess.

> 2) agree on types the computation happens in; tree-object-size.c right now
> casts the arguments regardless of type to sizetype, so size_t at the source
> level;

So, in theory you have to preserve this behaviour for backward compatibility
right ?

 so, shall we do such casts and perform multiplication in size_t, or
> in some other type (e.g. if both arguments are int, in int, etc.; what to do
> if the arguments have different type)?

Yes.however I think the compiler could emit a warning if arguments are not
size_t. ("attribute alloc_size expects function argument %d to be size_t but
$type given..") after all allocation sizes are of that type according to the C
standard..

[Bug target/77571] __clear_cache is broken on arm64 for big.little where the cache line sizes are different between cores

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #4 from James Greenhalgh  ---
(In reply to Bernhard Urban from comment #0)
> This patch introduces a problem:
> https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00076.html and should be at
> least reverted.
> 
> See https://github.com/mono/mono/pull/3549 and
> http://www.mono-project.com/news/2016/09/12/arm64-icache/
> 
> There is also some work going on to fix this on kernel level:
> https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00076.html

Neither reverting the patch, nor any of the other suggestions in this report
(other than hardcoding the size to 4) would remove the potential race condition
between reading the size of the cache line and being migrated to a CPU with a
smaller cache line size.

The proposed Linux kernel workaround (
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1227904.html ) will
remove the need for a change to GCC in a Linux environment - the value will
read as the minimum required for the system. The Kernel is also best placed to
enable the workaround only for those systems which require it.

Handling this in user-space is extremely fragile, and will penalize a large
number of systems. Such a workaround would require serious thought as to how it
was designed and implemented, and which subtargets it was enabled for.

To my mind, the only appropriate place to implement a workaround is the kernel.

[Bug c++/77427] [6/7 Regression] ice when canonical types differ for identical types

[vries at gcc dot gnu.org]

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

--- Comment #11 from Tom de Vries  ---
Author: vries
Date: Tue Sep 13 15:56:03 2016
New Revision: 240112

URL: https://gcc.gnu.org/viewcvs?rev=240112&root=gcc&view=rev
Log:
Don't treat array as builtin type in set_underlying_type

2016-09-13  Jason Merrill  
Tom de Vries  

PR c++/77427
* c-common.c (set_underlying_type): Don't treat array as builtin type.

* g++.dg/pr77427.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr77427.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/68212] Loop unroller breaks basic block frequencies

[pthaugen at gcc dot gnu.org]

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

--- Comment #2 from Pat Haugen  ---
Author: pthaugen
Date: Tue Sep 13 15:58:52 2016
New Revision: 240113

URL: https://gcc.gnu.org/viewcvs?rev=240113&root=gcc&view=rev
Log:
PR tree-optimization/77536
PR rtl-optimization/68212
* config/rs6000/rs6000.md (div->recip splitter): Remove
optimize_insn_for_speed_p condition.


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

[Bug tree-optimization/77536] Vectorizer not maintaining relationship of relative block frequencies in absence of real profile data

[pthaugen at gcc dot gnu.org]

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

--- Comment #1 from Pat Haugen  ---
Author: pthaugen
Date: Tue Sep 13 15:58:52 2016
New Revision: 240113

URL: https://gcc.gnu.org/viewcvs?rev=240113&root=gcc&view=rev
Log:
PR tree-optimization/77536
PR rtl-optimization/68212
* config/rs6000/rs6000.md (div->recip splitter): Remove
optimize_insn_for_speed_p condition.


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

[Bug c++/77427] [6/7 Regression] ice when canonical types differ for identical types

[vries at gcc dot gnu.org]

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

--- Comment #12 from Tom de Vries  ---
Author: vries
Date: Tue Sep 13 16:05:20 2016
New Revision: 240114

URL: https://gcc.gnu.org/viewcvs?rev=240114&root=gcc&view=rev
Log:
backport "Don't treat array as builtin type in set_underlying_type"

2016-09-13  Tom de Vries  

backport from trunk:
2016-09-13  Jason Merrill  
Tom de Vries  

PR c++/77427
* c-common.c (set_underlying_type): Don't treat array as builtin type.

* g++.dg/pr77427.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/pr77427.C
Modified:
branches/gcc-6-branch/gcc/c-family/ChangeLog
branches/gcc-6-branch/gcc/c-family/c-common.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/77427] [6/7 Regression] ice when canonical types differ for identical types

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #13 from Tom de Vries  ---
Patch and test-case committed and backported to 6 branch.

Marking resolved-fixed.

[Bug tree-optimization/77511] internal compiler error: in get_ptr_info

[zheltonozhskiy at gmail dot com]

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

--- Comment #5 from Evgenii Zheltonozhskii  ---
So what should I do to get one?

[Bug tree-optimization/77511] internal compiler error: in get_ptr_info

[zheltonozhskiy at gmail dot com]

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

--- Comment #6 from Evgenii Zheltonozhskii  ---
I've added I've added a build log in build_log.txt in the upper link. Maybe
it'll be useful

[Bug sanitizer/77567] ASAN: Bugus error "alloc-dealloc-mismatch (malloc vs operator delete [])" with C++17's over-aligned types

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-13
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
(In reply to Tobias Burnus from comment #0)
> In my understanding, the following is valid C++17:
> 
> #include 
> 
> int main() {
>   char *c = new(std::align_val_t(512), std::nothrow) char[1024];
>   delete[] c;
>   return 0;
> }

According to Jason, this is not valid C++17, because it violates
[new.delete.array]/13:
"Requires: If the alignment parameter is not present, ptr shall have been
returned by an allocation function without an alignment parameter. If present,
the alignment argument shall equal the alignment argument passed to the
allocation function that returned ptr."

That said, we want to instrument it in libsanitizer, let me attach 2 patches
for discussions.

[Bug sanitizer/77567] ASAN: Bugus error "alloc-dealloc-mismatch (malloc vs operator delete [])" with C++17's over-aligned types

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 39611
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39611&action=edit
pr77567-1.patch

This (version for current compiler-rt, for gcc it needs a one-liner tweak in
the // See line - different URL) seems to work fine in my limited testing and
passed bootstrap/regtest, but isn't able to diagnose bug like you have in your
testcase.

[Bug sanitizer/77567] ASAN: Bugus error "alloc-dealloc-mismatch (malloc vs operator delete [])" with C++17's over-aligned types

[jakub at gcc dot gnu.org]

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

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

Slightly larger patch, which attempts to diagnose that, but fails to do so,
because asan_allocator.cc only has:
  u32 alloc_type: 2;
and we now need 3 bits instead of just 2.
Dmitry, is there any possibility to free one bit for this in ChunkHeader?

[Bug fortran/77420] [5/6/7 Regression] gfortran and equivalence produces internal compiler error

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Sep 13 17:00:29 2016
New Revision: 240118

URL: https://gcc.gnu.org/viewcvs?rev=240118&root=gcc&view=rev
Log:
2016-09-13  Steven G. Kargl  

PR fortran/77420
* module.c (load_equiv):  Revert revision 240063.

2016-09-13  Steven G. Kargl  

PR fortran/77420
* gfortran.dg/pr77420.f90: Revert revision 240063 by removing test.

Removed:
trunk/gcc/testsuite/gfortran.dg/pr77420.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/77581] New: ICE: instantiate_template_1, cp/pt.c:17391

[jeanmichael.celerier at gmail dot com]

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

Bug ID: 77581
   Summary: ICE:  instantiate_template_1, cp/pt.c:17391
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeanmichael.celerier at gmail dot com
  Target Milestone: ---

Created attachment 39613
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39613&action=edit
CPP source file that exhibits the bug

ICE with g++ (GCC) 6.2.1 20160830

[Bug c++/77553] [6/7 Regression] wrong code with post-increment operator in constexpr

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 13 17:10:39 2016
New Revision: 240119

URL: https://gcc.gnu.org/viewcvs?rev=240119&root=gcc&view=rev
Log:
PR c++/77553
* constexpr.c (cxx_fold_pointer_plus_expression): New function.
(cxx_eval_binary_expression): Use it for POINTER_PLUS_EXPR.
(cxx_eval_pointer_plus_expression): Remove.
(cxx_eval_constant_expression) : Don't
call cxx_eval_pointer_plus_expression.

* g++.dg/cpp1y/constexpr-77553.C: New test.

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

[Bug other/67179] failed to build gcc on RHEL 6.2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-13
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Can you provide the full log?  Because I don't see how the specs file will ever
be used here.  That is unless gcc has passed -B. itself.

[Bug bootstrap/67197] GCC_FINAL causes bootstrap failure on AIX

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Has this been fixed?  if so please close it.

[Bug debug/67163] g2 generates incorrect decl_line

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
*** Bug 67162 has been marked as a duplicate of this bug. ***

[Bug debug/67162] g2 generates incorrect decl_line

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
.

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

[Bug other/67165] please enable libbacktrace to work with compressed debug sections

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Severity|normal  |enhancement

[Bug bootstrap/67128] Makefile.in, libcc1 and --enable-shared

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
You either need --with-pic or not do what you are trying to do.

[Bug sanitizer/63627] thread sanitizer does not instrument __atomic_test_and_set or __atomic_clear

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 68260.

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

[Bug libstdc++/77582] Improve std::string::clear performace

[xiyou.wangcong at gmail dot com]

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

--- Comment #1 from Cong Wang  ---
Created attachment 39614
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39614&action=edit
A possible patch

This patch improves it by using _S_empty_rep directly when
_GLIBCXX_FULLY_DYNAMIC_STRING is not enabled.

[Bug libstdc++/77582] Improve std::string::clear performace

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Patches goto gcc-patches@ and libstdc++@.  Note !_GLIBCXX_USE_CXX11_ABI is most
likely not going to be used for 90% of applications.  It is only needed if you
are linking between old binaries and using the new compiler.

[Bug sanitizer/68260] false positive with tsan

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rogero at howzatt dot 
demon.co.uk

--- Comment #8 from Andrew Pinski  ---
*** Bug 63627 has been marked as a duplicate of this bug. ***

[Bug libstdc++/77582] New: Improve std::string::clear performace

[xiyou.wangcong at gmail dot com]

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

Bug ID: 77582
   Summary: Improve std::string::clear performace
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xiyou.wangcong at gmail dot com
  Target Milestone: ---

In !_GLIBCXX_USE_CXX11_ABI implementation, string::clear() calls _M_mutate(),
which could allocate memory as we do COW. This hurts performance when
string::clear() is on the hot path.

[Bug libstdc++/77582] Improve std::string::clear performace

[xiyou.wangcong at gmail dot com]

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

--- Comment #3 from Cong Wang  ---
Hi, Andrew

I just posted it:
https://gcc.gnu.org/ml/libstdc++/2016-09/msg00051.html

Please review.

I caught this when using Google protobuf on Fedora 21, _M_mutate() is shown in
perf top profile, inlined into clear(). AFAIK, only !_GLIBCXX_USE_CXX11_ABI
impl uses _M_mutate().

Thanks.

[Bug fortran/77532] ICE in check_dtio_interface1, at fortran/interface.c:4622

[gerhard.steinmetz.fort...@t-online.de]

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #5 from Gerhard Steinmetz  
---

Thank you very much for working on these issues.
Additional tests with an improved version from 20160911
revealed a few other errors, as bespoken attached hereto :


$ cat za1.f90
module m
   type t
   end type
   interface write(formatted)
  module procedure s
   end interface
contains
   subroutine s(dtv,unit,iotype,vlist,extra,iostat,iomsg)
  class(t), intent(in) :: dtv
  integer, intent(in) :: unit
  character(len=*), intent(in) :: iotype
  integer, intent(in) :: vlist(:)
  integer, intent(out) :: iostat
  character(len=*), intent(inout) :: iomsg
   end
end


$ cat za2.f90
module m
   type t
   end type
   interface read(formatted)
  module procedure s
   end interface
contains
   subroutine s(dtv,unit,iotype,vlist,iostat,iomsg,extra)
  class(t), intent(inout) :: dtv
  integer, intent(in) :: unit
  character(len=*), intent(in) :: iotype
  integer, intent(in) :: vlist(:)
  integer, intent(out) :: iostat
  character(len=*), intent(inout) :: iomsg
   end
end


$ cat za3.f90
module m
   type t
   end type
   interface read(formatted)
  module procedure s
   end interface
contains
   subroutine s(dtv,extra,unit,iotype,vlist,iostat,iomsg)
  class(t), intent(inout) :: dtv
  integer, intent(in) :: unit
  character(len=*), intent(in) :: iotype
  integer, intent(in) :: vlist(:)
  integer, intent(out) :: iostat
  character(len=*), intent(inout) :: iomsg
   end
end


$ gfortran-7-20160911 za1.f90
za1.f90:8:43:

subroutine s(dtv,unit,iotype,vlist,extra,iostat,iomsg)
   1
Error: DTIO dummy argument at (1) must be of type INTEGER
za1.f90:8:50:

subroutine s(dtv,unit,iotype,vlist,extra,iostat,iomsg)
  1
Error: DTIO dummy argument at (1) must be of type CHARACTER
f951: internal compiler error: in check_dtio_interface1, at
fortran/interface.c:4707
0x692c19 check_dtio_interface1
../../gcc/fortran/interface.c:4707
0x69a348 gfc_check_dtio_interfaces(gfc_symbol*)
../../gcc/fortran/interface.c:4747
0x70c86b do_traverse_symtree
../../gcc/fortran/symbol.c:3939
0x6f65c0 resolve_types
../../gcc/fortran/resolve.c:15658
0x6f1d9c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15730
0x6dd3a4 gfc_parse_file()
../../gcc/fortran/parse.c:6056
0x71f5f2 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198


---


$ cat zb1.f90
module m
   type t
   end type
   interface write(unformatted)
  module procedure s
   end interface
contains
   subroutine s(*)
   end
end


$ gfortran-7-20160911 zb1.f90
f951: internal compiler error: Segmentation fault
0xc2154f crash_signal
../../gcc/toplev.c:336
0x692c73 check_dtio_interface1
../../gcc/fortran/interface.c:4633
0x69a348 gfc_check_dtio_interfaces(gfc_symbol*)
../../gcc/fortran/interface.c:4747
0x70c86b do_traverse_symtree
../../gcc/fortran/symbol.c:3939
0x6f65c0 resolve_types
../../gcc/fortran/resolve.c:15658
0x6f1d9c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15730
0x6dd3a4 gfc_parse_file()
../../gcc/fortran/parse.c:6056
0x71f5f2 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198


---


$ cat zc1.f90
module m
   type t
   contains
  procedure :: s
  generic :: write(unformatted) => s
   end type
contains
   subroutine s(dtv, *)
  class(t), intent(out) :: dtv
   end
end


$ gfortran-7-20160911 zc1.f90
zc1.f90:8:19:

subroutine s(dtv, *)
   1
Error: DTIO dummy argument at (1) must have intent IN
f951: internal compiler error: Segmentation fault
0xc2154f crash_signal
../../gcc/toplev.c:336
0x69290d check_dtio_arg_TKR_intent
../../gcc/fortran/interface.c:4561
0x692b4a check_dtio_interface1
../../gcc/fortran/interface.c:4676
0x69a303 gfc_check_dtio_interfaces(gfc_symbol*)
../../gcc/fortran/interface.c:4735
0x70c86b do_traverse_symtree
../../gcc/fortran/symbol.c:3939
0x6f65c0 resolve_types
../../gcc/fortran/resolve.c:15658
0x6f1d9c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15730
0x6dd3a4 gfc_parse_file()
../../gcc/fortran/parse.c:6056
0x71f5f2 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198


---


$ cat zd1.f90
module m
   type t
  character(len=20) :: name
  integer(4) :: age
   contains
  procedure :: pruf
  generic :: read(unformatted) => pruf
   end type
contains
   subroutine pruf (dtv,unit,iostat,iomsg)
  class(t), intent(inout) :: dtv
  integer, intent(in) :: unit
  

[Bug fortran/77583] New: ICE in pp_quoted_string, at pretty-print.c:966

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77583
   Summary: ICE in pp_quoted_string, at pretty-print.c:966
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

A naming conflict between dummy-arg and internal subroutine/function.
Invalid code, and gcc configured with --enable-checking=yes.


$ cat z1.f90
pure subroutine sub(s)
contains
   pure subroutine s
   end
end


$ gfortran-7-20160911 z1.f90
z1.f90:3:20:

pure subroutine s
1
Error: internal procedure 's' at (1) conflicts with DUMMY argument
'
in pp_quoted_string, at pretty-print.c:966
0x13a5ee0 pp_quoted_string
../../gcc/pretty-print.c:966
0x13a695b pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:595
0x139a6a0 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:941
0x689248 gfc_error_now(char const*, ...)
../../gcc/fortran/error.c:1177
0x70af46 check_conflict
../../gcc/fortran/symbol.c:479
0x5dce0c copy_prefix
../../gcc/fortran/decl.c:4994
0x67e6de gfc_match_subroutine()
../../gcc/fortran/decl.c:6411
0x6d6781 decode_statement
../../gcc/fortran/parse.c:379
0x6d8444 next_free
../../gcc/fortran/parse.c:1143
0x6d8444 next_statement
../../gcc/fortran/parse.c:1376
0x6dbba4 parse_contained
../../gcc/fortran/parse.c:5337
0x6dbad6 parse_progunit
../../gcc/fortran/parse.c:5560
0x6dd134 gfc_parse_file()
../../gcc/fortran/parse.c:6005
0x71f5f2 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/77583] ICE in pp_quoted_string, at pretty-print.c:966

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---

With official releases (configured with --enable-checking=release) :


$ gfortran-6 z1.f90
z1.f90:3:20:

pure subroutine s
1
Error: internal procedure 's' at (1) conflicts with DUMMY argument
'
(null):0: confused by earlier errors, bailing out


$ gfortran-5 z1.f90
z1.f90:3:20:

pure subroutine s
1
Error: internal procedure 's' at (1) conflicts with DUMMY argument
z1.f90:3:20: Error: internal procedure '' at (1) conflicts with DUMMY argument
# no ICE


$ gfortran-4.9 z1.f90
z1.f90: In function 's':
z1.f90:1:0: internal compiler error: in make_decl_rtl, at varasm.c:1221
 pure subroutine sub(s)
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

---


More variants :


$ cat z2.f90
recursive subroutine sub(s)
contains
   recursive subroutine s
   end
end


$ cat z3.f90
elemental subroutine sub(s)
contains
   elemental subroutine s
   end
end


$ cat z4.f90
pure elemental subroutine sub(s)
contains
   pure elemental subroutine s
   end
end


$ cat z5.f90
pure subroutine sub(s)
contains
   elemental subroutine s
   end
end


$ cat z6.f90
elemental function f(s)
   real, intent(in) :: s
contains
   pure subroutine s
   end
end


# ...

[Bug tree-optimization/77454] [7 Regression] IMM ERROR w/ -O2 and above

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 13 19:19:33 2016
New Revision: 240120

URL: https://gcc.gnu.org/viewcvs?rev=240120&root=gcc&view=rev
Log:
PR tree-optimization/77454
* tree-ssa-dom.c (optimize_stmt): Set modified flag on stmt after
changing GIMPLE_COND.  Move update_stmt_if_modified call after this.
Formatting fix.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr77454.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dom.c

[Bug fortran/77584] New: Unclassifiable statement error with procedure pointer using template named "structure_"

[abensonca at gmail dot com]

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

Bug ID: 77584
   Summary: Unclassifiable statement error with procedure pointer
using template named "structure_"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

In gfortran 7.0.0 (r240119) the following causes an error on compilation:

module bug
  abstract interface
 double precision function structure_()
 end function structure_
  end interface
contains
  double precision function a()
procedure(structure_), pointer :: b
  end function a
end module bug

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 7.0.0 20160913 (experimental) (GCC) 

$ gfortran -c tmp.F90 -o tmp.o
tmp.F90:8:4:

 procedure(structure_), pointer :: b
1
Error: Unclassifiable statement at (1)


The problem seems to occur only if the interface name begins with "structure",
so my guess is that this part of the name if being interpreted as a STRUCTURE
statement.

[Bug target/70713] msp430 interrupt attribute prevents overriding weak symbols

[dj at gcc dot gnu.org]

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

--- Comment #3 from dj at gcc dot gnu.org  ---
Author: dj
Date: Tue Sep 13 20:06:47 2016
New Revision: 240123

URL: https://gcc.gnu.org/viewcvs?rev=240123&root=gcc&view=rev
Log:
2016-09-13  Joe Seymour  

gcc/
PR target/70713
* config/msp430/msp430.c (msp430_start_function): Emit an error
if a function is both weak and specifies an interrupt number.

gcc/testsuite/
PR target/70713
* gcc.target/msp430/function-attributes-1.c: New test.
* gcc.target/msp430/function-attributes-2.c: New test.
* gcc.target/msp430/function-attributes-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/msp430/function-attributes-1.c
trunk/gcc/testsuite/gcc.target/msp430/function-attributes-2.c
trunk/gcc/testsuite/gcc.target/msp430/function-attributes-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/msp430/msp430.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/77583] ICE in pp_quoted_string, at pretty-print.c:966

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-13
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Manuel López-Ibáñez  ---
check_conflict is sometimes called with name = NULL and that is passed to %qs
causing a crash.

[Bug c++/77581] [6/7 Regression] ICE: instantiate_template_1, cp/pt.c:17391

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||5.4.0
   Keywords||ice-on-invalid-code
   Last reconfirmed||2016-09-13
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE:|[6/7 Regression] ICE:
   |instantiate_template_1, |instantiate_template_1,
   |cp/pt.c:17391   |cp/pt.c:17391
   Target Milestone|--- |6.3
  Known to fail||6.1.0

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug sanitizer/77567] ASAN: Bugus error "alloc-dealloc-mismatch (malloc vs operator delete [])" with C++17's over-aligned types

[kcc at gcc dot gnu.org]

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

--- Comment #6 from Kostya Serebryany  ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 39612 [details]
> pr77567-2.patch
> 
> Slightly larger patch, which attempts to diagnose that, but fails to do so,
> because asan_allocator.cc only has:
>   u32 alloc_type: 2;
> and we now need 3 bits instead of just 2.
> Dmitry, is there any possibility to free one bit for this in ChunkHeader?

There are no bits left. 
But do we need these new states here? 
Can't we reuse the from_memalign field? 

Also, please remember that we can not accept patches from this buganizer --
they need to go via http://llvm.org/docs/Phabricator.html

[Bug rtl-optimization/77289] [7 Regression] ICE in extract_constrain_insn, at recog.c:2212 on powerpc64

[edlinger at gcc dot gnu.org]

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

--- Comment #9 from Bernd Edlinger  ---
Author: edlinger
Date: Tue Sep 13 21:25:04 2016
New Revision: 240124

URL: https://gcc.gnu.org/viewcvs?rev=240124&root=gcc&view=rev
Log:
2016-09-13  Bernd Edlinger  

PR rtl-optimization/77289
* lra-constraints.c (get_final_hard_regno): Removed.
(get_hard_regno): Add new parameter final_p.
(get_reg_class): Directly call lra_get_elimination_hard_regno.
(operands_match_p): Adjust call to get_hard_regno.
(uses_hard_regs_p): Likewise.
(process_alt_operands): Likewise.

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

[Bug bootstrap/67197] GCC_FINAL causes bootstrap failure on AIX

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
The patch was reverted, but we don't know why it caused problems.

[Bug c++/77585] New: g++ incorrectly decides that member function is called without object in generic lambda

[neil.attn at ya dot ru]

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

Bug ID: 77585
   Summary: g++ incorrectly decides that member function is called
without object in generic lambda
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neil.attn at ya dot ru
  Target Milestone: ---

I think I've found a bug regarding generic lambdas in g++. Clang accepts code.
$ cat gcc_maybe_bug.cc 
#include 
#include 
#include 

template 
struct Base
{
using value_type = T;

void func(T v)
{
std::cout << v << a << '\n';
}

T a{5};
};

template 
struct Derived : T
{
using typename T::value_type;

// here's the bug, maybe?
void do_something()
{
// Call member function of the base class. Everything's fine.
T::func(arr[0]);

// Everything is fine here also:
auto lambda = [this](auto a) { T::func(a); };
lambda(arr[1]);

// Everything's fine here, too. Non-generic lambda.
std::for_each(std::begin(arr), std::end(arr), [this](int a) {
T::func(a); });

// Here's the error: g++ thinks, that T::func(a) is a call
without object, even
// though "this" is explicitly captured. Same as above, but
generic lambda.
std::for_each(std::begin(arr), std::end(arr), [this](auto a) {
T::func(a); });
}

value_type arr[16]{};
};

int main()
{
Derived> o;
o.do_something();
return 0;
}
$ g++ -std=c++14 -Wall -Wextra -pedantic gcc_maybe_bug.cc 
gcc_maybe_bug.cc: In instantiation of
‘Derived::do_something():: [with auto:2 = int; T =
Base]’:
/usr/include/c++/6.1.1/bits/stl_algo.h:3769:5:   required from ‘_Funct
std::for_each(_IIter, _IIter, _Funct) [with _IIter = int*; _Funct =
Derived::do_something() [with T = Base]::]’
gcc_maybe_bug.cc:38:30:   required from ‘void Derived::do_something() [with
T = Base]’
gcc_maybe_bug.cc:47:24:   required from here
gcc_maybe_bug.cc:38:87: error: cannot call member function ‘void
Base::func(T) [with T = int]’ without object
 std::for_each(std::begin(arr), std::end(arr), [this](auto a) {
T::func(a); });

$ g++ --version
g++ (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ clang++ -std=c++14 -Wall -Wextra -pedantic gcc_maybe_bug.cc

[Bug rtl-optimization/77499] [7 Regression] Regression after code-hoisting, due to combine pass failing to evaluate known value range

[kugan at gcc dot gnu.org]

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

--- Comment #13 from kugan at gcc dot gnu.org ---
(In reply to avieira from comment #12)
> I heard Kugan was working on getting rid of superfluous zero_extends. Adding
> him to the watch list.
> 
> @Kugan: Could your work help this case? And when do you plan to have it
> submitted?

Thanks for the testcase.
With my type promotion pass, I am getting:
cmp r1, r2
ble .L10
-   push{r4, r5, r6, r7}
-   ldr r7, .L14
+   push{r4, r5, r6, lr}
+   ldr r5, .L14
movwr6, #45345
 .L4:
-   smull   r5, r4, r7, r1
+   smull   lr, r4, r5, r1
lsrsr0, r0, #1
sub r4, r4, r1, asr #31
-   eor r5, r0, r6
add r4, r4, r4, lsl #1
cmp r1, r4
sub r1, r1, r3
it  ne
-   uxthne  r0, r5
+   eorne   r0, r0, r6
cmp r2, r1
blt .L4
-   pop {r4, r5, r6, r7}
-   bx  lr
+   uxthr0, r0
+   pop {r4, r5, r6, pc}
 .L10:
+   uxthr0, r0
bx  lr
 .L15:
.align  2
 .L14:
.word   1431655766
.size   foo, .-foo

Even though, extension is removed from loop, it has an extra uxth. I have some
cases like this to look at before I post the patch again. I am afraid, I will
not be able to do it during this stage1.

[Bug fortran/77532] ICE in check_dtio_interface1, at fortran/interface.c:4622

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #5)
> Thank you very much for working on these issues.
> Additional tests with an improved version from 20160911
> revealed a few other errors, as bespoken attached hereto :
> 
> 
> $ cat za1.f90
> module m
>type t
>end type
>interface write(formatted)
>   module procedure s
>end interface
> contains
>subroutine s(dtv,unit,iotype,vlist,extra,iostat,iomsg)
>   class(t), intent(in) :: dtv
>   integer, intent(in) :: unit
>   character(len=*), intent(in) :: iotype
>   integer, intent(in) :: vlist(:)
>   integer, intent(out) :: iostat
>   character(len=*), intent(inout) :: iomsg
>end
> end
> 
> 
> $ cat za2.f90
> module m
>type t
>end type
>interface read(formatted)
>   module procedure s
>end interface
> contains
>subroutine s(dtv,unit,iotype,vlist,iostat,iomsg,extra)
>   class(t), intent(inout) :: dtv
>   integer, intent(in) :: unit
>   character(len=*), intent(in) :: iotype
>   integer, intent(in) :: vlist(:)
>   integer, intent(out) :: iostat
>   character(len=*), intent(inout) :: iomsg
>end
> end
> 
> 
> $ cat za3.f90
> module m
>type t
>end type
>interface read(formatted)
>   module procedure s
>end interface
> contains
>subroutine s(dtv,extra,unit,iotype,vlist,iostat,iomsg)
>   class(t), intent(inout) :: dtv
>   integer, intent(in) :: unit
>   character(len=*), intent(in) :: iotype
>   integer, intent(in) :: vlist(:)
>   integer, intent(out) :: iostat
>   character(len=*), intent(inout) :: iomsg
>end
> end
> 
> 
> $ gfortran-7-20160911 za1.f90
> za1.f90:8:43:
> 
> subroutine s(dtv,unit,iotype,vlist,extra,iostat,iomsg)
>1
> Error: DTIO dummy argument at (1) must be of type INTEGER
> za1.f90:8:50:
> 
> subroutine s(dtv,unit,iotype,vlist,extra,iostat,iomsg)
>   1
> Error: DTIO dummy argument at (1) must be of type CHARACTER
> f951: internal compiler error: in check_dtio_interface1, at
> fortran/interface.c:4707

troutmask:sgk[218] svn diff interface.c
Index: interface.c
===
--- interface.c (revision 240119)
+++ interface.c (working copy)
@@ -4704,7 +4704,7 @@ check_dtio_interface1 (gfc_symbol *deriv
 0, intent);
  break;
default:
- gcc_unreachable ();
+ gfc_internal_error ("check_dtio_interface1: invalid argument");
}
 }
   derived->attr.has_dtio_procs = 1;

[Bug fortran/77532] ICE in check_dtio_interface1, at fortran/interface.c:4622

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---

> $ cat zc1.f90
> module m
>type t
>contains
>   procedure :: s
>   generic :: write(unformatted) => s
>end type
> contains
>subroutine s(dtv, *)
>   class(t), intent(out) :: dtv
>end
> end
> 
> 
> $ gfortran-7-20160911 zc1.f90
> zc1.f90:8:19:
> 
> subroutine s(dtv, *)
>1
> Error: DTIO dummy argument at (1) must have intent IN
> f951: internal compiler error: Segmentation fault
> 0xc2154f crash_signal
> ../../gcc/toplev.c:336
> 0x69290d check_dtio_arg_TKR_intent
> ../../gcc/fortran/interface.c:4561
> 0x692b4a check_dtio_interface1
> ../../gcc/fortran/interface.c:4676
> 0x69a303 gfc_check_dtio_interfaces(gfc_symbol*)
> ../../gcc/fortran/interface.c:4735
> 0x70c86b do_traverse_symtree
> ../../gcc/fortran/symbol.c:3939
> 0x6f65c0 resolve_types
> ../../gcc/fortran/resolve.c:15658
> 0x6f1d9c gfc_resolve(gfc_namespace*)
> ../../gcc/fortran/resolve.c:15730
> 0x6dd3a4 gfc_parse_file()
> ../../gcc/fortran/parse.c:6056
> 0x71f5f2 gfc_be_parse_file
> ../../gcc/fortran/f95-lang.c:198
> 
troutmask:sgk[232] svn diff interface.c |more
Index: interface.c
===
--- interface.c (revision 240119)
+++ interface.c (working copy)
@@ -4558,6 +4558,9 @@ static void
 check_dtio_arg_TKR_intent (gfc_symbol *fsym, bool typebound, bt type,
   int kind, int rank, sym_intent intent)
 {
+  if (!fsym)
+return;
+
   if (fsym->ts.type != type)
 {
   gfc_error ("DTIO dummy argument at %L must be of type %s",
@@ -4584,7 +4587,6 @@ check_dtio_arg_TKR_intent (gfc_symbol *f
   if (fsym->attr.intent != intent)
 gfc_error ("DTIO dummy argument at %L must have intent %s",
   &fsym->declared_at, gfc_code2string (intents, (int)intent));
-  return;
 }