[Bug c++/77339] New: ICE on invalid C++ code on x86_64-linux-gnu: in cp_parser_type_name, at cp/parser.c:16532

[su at cs dot ucdavis.edu]

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

Bug ID: 77339
   Summary: ICE on invalid C++ code on x86_64-linux-gnu: in
cp_parser_type_name, at cp/parser.c:16532
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

It affects 4.8.x and later, and is a regression from 4.7.x.


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160822 (experimental) [trunk revision 239655] (GCC) 
$ 
$ g++-trunk -c small.cpp
small.cpp:3:25: internal compiler error: in cp_parser_type_name, at
cp/parser.c:16532
 template < typename X > A < X >::a;
 ^~~
0x7a94ec cp_parser_type_name
../../gcc-source-trunk/gcc/cp/parser.c:16532
0x797f89 cp_parser_type_name
../../gcc-source-trunk/gcc/cp/parser.c:16482
0x797f89 cp_parser_simple_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:16396
0x793e71 cp_parser_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:16049
0x7a8d33 cp_parser_decl_specifier_seq
../../gcc-source-trunk/gcc/cp/parser.c:12889
0x7b7d15 cp_parser_single_declaration
../../gcc-source-trunk/gcc/cp/parser.c:25934
0x7b808c cp_parser_template_declaration_after_parameters
../../gcc-source-trunk/gcc/cp/parser.c:25630
0x7b8aa1 cp_parser_explicit_template_declaration
../../gcc-source-trunk/gcc/cp/parser.c:25861
0x7b8aa1 cp_parser_template_declaration_after_export
../../gcc-source-trunk/gcc/cp/parser.c:25879
0x7c00e9 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12209
0x7beb34 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12139
0x7bee78 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4356
0x7bee78 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:37671
0x92c462 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1073
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


---


template < typename > using A = int;

//OK: template < typename X > A < X > a; 
template < typename X > A < X >::a;

[Bug lto/77305] [7 Regression] -fdump-tree-all and -flto causes ICE

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue Aug 23 07:21:36 2016
New Revision: 239683

URL: https://gcc.gnu.org/viewcvs?rev=239683&root=gcc&view=rev
Log:
2016-08-23  Richard Biener  

PR middle-end/77305
* statistics.c (statistics_counter_event): Robustify against
NULL current_pass.

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

[Bug middle-end/27336] delete null checks in callers to nonnull functions

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Tue Aug 23 07:23:19 2016
New Revision: 239684

URL: https://gcc.gnu.org/viewcvs?rev=239684&root=gcc&view=rev
Log:
2016-08-23  Richard Biener  

PR tree-optimization/27336
* tree-vrp.c (infer_value_range): Handle stmts that can throw
by looking for a non-EH edge.
(process_assert_insertions_for): Likewise.

* c-c++-common/pr27336.c: New testcase.

Added:
trunk/gcc/testsuite/c-c++-common/pr27336.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug middle-end/27336] delete null checks in callers to nonnull functions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug lto/77305] [7 Regression] -fdump-tree-all and -flto causes ICE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/50818] va_list is filled incorrectly in functions with ms_abi attribute on amd64

[steven.shi at intel dot com]

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

--- Comment #9 from Steven Shi  ---
GCC6.10 lto fails to support below MS ABI buildin of va list, but GCC5 works.
This is a regression bug for GCC6. I suspect current GCC trunk also has this
regression bug.
  __builtin_ms_va_list ap;
  __builtin_ms_va_start (ap, n);
  __builtin_ms_va_end (ap);

Below is my testcase:
$cat test2.c

#include 

int
__attribute__((ms_abi))
foo (int n, ...)
{
  __builtin_ms_va_list ap;
  int sum = 0;

  __builtin_ms_va_start (ap, n);

  while (n--) {
sum += __builtin_va_arg (ap, int);
printf("sum = %d\n", sum);
  }
  __builtin_ms_va_end (ap);

  return sum;
}

int main ()
{
  int res = foo (10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

  if (res != 55)
__builtin_abort ();

  return 0;
}
$ gcc --version
gcc (GCC) 6.1.0

$ gcc -flto -Os test2.c
$ ./a.out
Segmentation fault (core dumped)

$ gcc-5 -flto -Os test2.c
$ ./a.out
sum = 1
sum = 3
sum = 6
sum = 10
sum = 15
sum = 21
sum = 28
sum = 36
sum = 45
sum = 55

[Bug c++/77340] New: Invalid (Stack Smashing) Code Generated In Simple Cases With Debug-Mode Vectors

[ian at geometrian dot com]

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

Bug ID: 77340
   Summary: Invalid (Stack Smashing) Code Generated In Simple
Cases With Debug-Mode Vectors
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at geometrian dot com
  Target Milestone: ---

Simple test case:

//func.hpp
#define _GLIBCXX_DEBUG
#include 
std::vector func();

//func.cpp
#include "func.hpp"
std::vector func() { return std::vector(); }

//main.cpp
#include  //Necessary to cause error
#include "func.hpp"
int main(int /*argc*/, char* /*argv*/[]) {
func(); return 0;
}

Compile with "g++ *.cpp" and run ("./a.out").  Produces:

*** stack smashing detected ***: ./a.out terminated
Aborted (core dumped)

[Bug c/77341] New: GCC6 va_list MS ABI buildin regression bug

[steven.shi at intel dot com]

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

Bug ID: 77341
   Summary: GCC6 va_list MS ABI buildin regression bug
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steven.shi at intel dot com
  Target Milestone: ---

GCC6.10 lto fails to support below MS ABI buildin of va list, but GCC5 works.
This is a regression bug for GCC6. I suspect current GCC trunk also has this
regression bug.
  __builtin_ms_va_list ap;
  __builtin_ms_va_start (ap, n);
  __builtin_ms_va_end (ap);

Below is my testcase:
$cat test2.c

#include 

int
__attribute__((ms_abi))
foo (int n, ...)
{
  __builtin_ms_va_list ap;
  int sum = 0;

  __builtin_ms_va_start (ap, n);

  while (n--) {
sum += __builtin_va_arg (ap, int);
printf("sum = %d\n", sum);
  }
  __builtin_ms_va_end (ap);

  return sum;
}

int main ()
{
  int res = foo (10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

  if (res != 55)
__builtin_abort ();

  return 0;
}
$ gcc --version
gcc (GCC) 6.1.0

$ gcc -flto -Os test2.c
$ ./a.out
Segmentation fault (core dumped)

$ gcc-5 -flto -Os test2.c
$ ./a.out
sum = 1
sum = 3
sum = 6
sum = 10
sum = 15
sum = 21
sum = 28
sum = 36
sum = 45
sum = 55

BTW, I've raised this issue in below bug comments:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50818

[Bug c++/77340] Invalid (Stack Smashing) Code Generated In Simple Cases With Debug-Mode Vectors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Not a bug. Debug mode changes the ABI of types, so you need to recompile
anything that passes those types between translation units. This is documented
at https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_using.html

[Bug c++/77340] Invalid (Stack Smashing) Code Generated In Simple Cases With Debug-Mode Vectors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Oh sorry, I misread the code. Both cpp files do use _GLIBCXX_DEBUG, let me
check what's happening here.

[Bug c++/77340] Invalid (Stack Smashing) Code Generated In Simple Cases With Debug-Mode Vectors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Ah no, as I thought ... main.cpp includes a standard library header before
_GLIBCXX_DEBUG is defined, and defining it after that is too late.

You need to define _GLIBCXX_DEBUG on the command line, or before including any
other headers.

[Bug libstdc++/77342] New: Use abi_tag on Debug Mode namespace

[redi at gcc dot gnu.org]

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

Bug ID: 77342
   Summary: Use abi_tag on Debug Mode namespace
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

The libstdc++ Debug Mode changes the ABI of various types, requiring all
affected code to be recompiled. If some function is not recompiled, and the
debug mode type doesn't appear in its mangled name, then you get undefined
behaviour, typically resulting in runtime crashes, e.g. PR 77340.

If we used the abi_tag attribute on the inline namespace used for Debug Mode
components then it would turn run-time crashes into linker errors, or at least
warnings when a data member of a class changes size.

e.g. with:

  // Inline namespace for debug mode.
# ifdef _GLIBCXX_DEBUG
  inline namespace __debug __attribute__((__abi_tag__("__debug"))) { }
# endif

the code in PR 77340 fails to link:

/tmp/cccmvLXH.o: In function `main':
/tmp/main.cpp:4: undefined reference to `func()'
collect2: error: ld returned 1 exit status

[Bug debug/77343] New: ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1596

[rguenth at gcc dot gnu.org]

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

Bug ID: 77343
   Summary: ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1596
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-*-*

Reduced from some kernel crypto code.

static int 
crypto_cbc_decrypt_inplace(int bsize)
{
  unsigned char last_iv[bsize];
}

when compiled with -mno-sse -mpreferred-stack-boundary=3 -ffixed-rbp:

> gcc-6 -ffixed-rbp cbc.3.i -S   -mno-sse  -mpreferred-stack-boundary=3
cbc.3.i: In function 'crypto_cbc_decrypt_inplace':
cbc.3.i:5:1: internal compiler error: in dwarf2out_frame_debug_expr, at
dwarf2cfi.c:1596
 }
 ^
0x9ccaff dwarf2out_frame_debug_expr
/space/rguenther/src/svn/trunk/gcc/dwarf2cfi.c:1594
0x9cdc39 dwarf2out_frame_debug
/space/rguenther/src/svn/trunk/gcc/dwarf2cfi.c:2089
0x9ce79f scan_insn_after
/space/rguenther/src/svn/trunk/gcc/dwarf2cfi.c:2415
0x9ced75 scan_trace
/space/rguenther/src/svn/trunk/gcc/dwarf2cfi.c:2572
0x9cee8c create_cfi_notes
/space/rguenther/src/svn/trunk/gcc/dwarf2cfi.c:2611
0x9cf9ad execute_dwarf2_frame
/space/rguenther/src/svn/trunk/gcc/dwarf2cfi.c:2974

The assert is

  /* Saving a register in a register.  */
  gcc_assert (!fixed_regs [REGNO (dest)]
  /* For the SPARC and its register window.  */
  || (dwf_regno (src) == DWARF_FRAME_RETURN_COLUMN));

not sure why it is present.  When removing it we generate the following code
which makes this wrong-code(?) because we use %rbp even though the user
specified it as fixed.  OTOH docs for -ffixed- say "except perhaps as a stack
pointer, frame pointer or in some other fixed role" which means the assert
above is over-zealous?

crypto_cbc_decrypt_inplace:
.LFB0:
.cfi_startproc
leaq8(%rsp), %r10
.cfi_def_cfa 10, 0
andq$-16, %rsp
pushq   -8(%r10)
pushq   %rbp
.cfi_escape 0x10,0x6,0x2,0x76,0
movq%rsp, %rbp
pushq   %r10
.cfi_escape 0xf,0x3,0x76,0x78,0x6
subq$40, %rsp
movl%edi, -36(%rbp)
movq%rsp, %rax
movq%rax, %rcx
movl-36(%rbp), %eax
movslq  %eax, %rdx
subq$1, %rdx
movq%rdx, -24(%rbp)
movslq  %eax, %rdx
movq%rdx, %r10
movl$0, %r11d
movslq  %eax, %rdx
movq%rdx, %r8
movl$0, %r9d
cltq
movl$8, %edx
subq$1, %rdx
addq%rdx, %rax
movl$8, %esi
movl$0, %edx
divq%rsi
imulq   $8, %rax, %rax
subq%rax, %rsp
movq%rsp, %rax
addq$0, %rax
movq%rax, -32(%rbp)
movq%rcx, %rsp
nop
movq-8(%rbp), %r10
.cfi_def_cfa 10, 0
leave
leaq-8(%r10), %rsp
.cfi_def_cfa 7, 8
ret
.cfi_endproc

[Bug fortran/49636] [F03] ASSOCIATE construct confused with slightly complicated case

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||neil.n.carlson at gmail dot com

--- Comment #10 from Dominique d'Humieres  ---
*** Bug 77310 has been marked as a duplicate of this bug. ***

[Bug fortran/77310] ICE on SELECT CASE with associate name

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Dominique d'Humieres  ---
> I think it is a duplicate of pr70705 and pr49636.

Confirmed by Paul on IRC. Closing as DUPLICATE.

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

[Bug c/77323] Bad "defaults to 'int'" warning for unsupported types

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-23
 Ever confirmed|0   |1

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

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Try -fno-lifetime-dse and/or -fno-delete-null-pointer-checks.

[Bug libstdc++/77334] [5/6/7 Regression] Cannot move assign std::map with non-copyable and non-movable mapped_type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

[Bug c++/77337] [7 regression][c++1z] use before deduction of 'auto'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c++/77339] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: in cp_parser_type_name, at cp/parser.c:16532

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
  Known to work||4.7.4
   Target Milestone|--- |5.5
Summary|ICE on invalid C++ code on  |[5/6/7 Regression] ICE on
   |x86_64-linux-gnu: in|invalid C++ code on
   |cp_parser_type_name, at |x86_64-linux-gnu: in
   |cp/parser.c:16532   |cp_parser_type_name, at
   ||cp/parser.c:16532

[Bug c++/77338] [7 Regression] ICE on invalid C++11 code on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Target Milestone|--- |7.0
Summary|ICE on invalid C++11 code   |[7 Regression] ICE on
   |on x86_64-linux-gnu:|invalid C++11 code on
   |Segmentation fault  |x86_64-linux-gnu:
   ||Segmentation fault

[Bug target/77341] GCC6 va_list MS ABI buildin regression bug

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
 Target||x86_64-*-*, i?86-*-*
  Component|c   |target
 Depends on||50818

--- Comment #1 from Richard Biener  ---
I believe we have a duplicate for this.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50818
[Bug 50818] va_list is filled incorrectly in functions with ms_abi attribute on
amd64

[Bug target/77341] GCC6 va_list MS ABI buildin regression bug

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Found it.

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

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||steven.shi at intel dot com

--- Comment #15 from Richard Biener  ---
*** Bug 77341 has been marked as a duplicate of this bug. ***

[Bug libstdc++/60936] [5/6/7 Regression] Binary code bloat with std::string

[d.v.a at ngs dot ru]

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

--- Comment #20 from __vic  ---
Patch attachment 38319 solves the problem for GCC 6.2 as well

[Bug c++/69470] [concepts] bogus constrained member class template redeclared with different access

[darko.veberic at ijs dot si]

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

Darko Veberic  changed:

   What|Removed |Added

 CC||darko.veberic at ijs dot si

--- Comment #2 from Darko Veberic  ---
i get the same also with gcc 5.2.1:

In file included from ./utl/String.h:5:0,
 from ./utl/TimeSeries.h:4,
 from ./mu/EventIO.h:4,
 from mu/EventIO.Dict.h:34,
 from mu/EventIO.Dict.cc:17:
/usr/include/c++/5/sstream:300:7: error: ‘struct
std::__cxx11::basic_stringbuf<_CharT, _Traits, _Alloc>::__xfer_bufptrs’
redeclared with different access
   struct __xfer_bufptrs
   ^

[Bug libstdc++/71771] DR 685 applied incorrectly

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Tue Aug 23 10:13:26 2016
New Revision: 239691

URL: https://gcc.gnu.org/viewcvs?rev=239691&root=gcc&view=rev
Log:
Implement resolution of LWG DR 685 precisely

PR libstdc++/71771
* include/bits/stl_iterator.h
(operator-(reverse_iterator, reverse_iterator): Only
define for C++98 mode.
(operator-(move_iterator, move_iterator): Don't define.
* testsuite/24_iterators/headers/iterator/synopsis.cc: Use
-std=gnu++98.
* testsuite/24_iterators/headers/iterator/synopsis_c++11.cc: New test.
* testsuite/24_iterators/headers/iterator/synopsis_c++14.cc: New test.
* testsuite/24_iterators/headers/iterator/synopsis_c++17.cc: New test.
* testsuite/24_iterators/move_iterator/greedy_ops.cc: Don't test
difference operator.
* testsuite/24_iterators/reverse_iterator/greedy_ops.cc: Only test
difference operator for C++98.
* testsuite/24_iterators/reverse_iterator/71771.cc: New test.

Added:
   
trunk/libstdc++-v3/testsuite/24_iterators/headers/iterator/synopsis_c++11.cc
   
trunk/libstdc++-v3/testsuite/24_iterators/headers/iterator/synopsis_c++14.cc
  - copied, changed from r239690,
trunk/libstdc++-v3/testsuite/24_iterators/reverse_iterator/greedy_ops.cc
   
trunk/libstdc++-v3/testsuite/24_iterators/headers/iterator/synopsis_c++17.cc
trunk/libstdc++-v3/testsuite/24_iterators/reverse_iterator/71771.cc
  - copied, changed from r239690,
trunk/libstdc++-v3/testsuite/24_iterators/reverse_iterator/greedy_ops.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_iterator.h
trunk/libstdc++-v3/testsuite/24_iterators/headers/iterator/synopsis.cc
trunk/libstdc++-v3/testsuite/24_iterators/move_iterator/greedy_ops.cc
trunk/libstdc++-v3/testsuite/24_iterators/reverse_iterator/greedy_ops.cc

[Bug c/77332] ICE when building gcc 6.2 (with gcc 6.1.0)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-08-23
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I can't reproduce it.  It seems to happen in stage2 (-g -gtoggle) and I'm past
that trying to reproduce (also that's the only stage where checking code is
run).

Can you attach preprocessed source for the failing command source?

[Bug debug/63238] DWARF does not represent _Alignas

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org

--- Comment #1 from Mark Wielaard  ---
The formal standard request is:
http://www.dwarfstd.org/ShowIssue.php?issue=140528.1

Prototype patch for an earlier iteration (using DW_TAG_aligned_type instead of
DW_AT_alignment attribute) for GCC is here:
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00667.html
Corresponding GDB patch is here:
https://sourceware.org/ml/gdb-patches/2014-07/msg00199.html

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[steven.shi at intel dot com]

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

--- Comment #16 from Steven Shi  ---
How to checkout the 6.3 code from GCC trunk? I hope to verify this fix on Uefi
firmware GCC LTO build.

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
(In reply to Steven Shi from comment #16)
> How to checkout the 6.3 code from GCC trunk? I hope to verify this fix on
> Uefi firmware GCC LTO build.

The patch is not checked in as I believe the fundamental issue is not solved
in a sensible way.

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[vries at gcc dot gnu.org]

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

--- Comment #18 from vries at gcc dot gnu.org ---
Created attachment 39484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39484&action=edit
Tentative patch using attributes ms_abi/sysv_abi

not build or regression tested yet, but at least makes test-case pass.

[Bug fortran/77344] New: Internal Compiler Error with arch knl

[matthew.thompson at nasa dot gov]

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

Bug ID: 77344
   Summary: Internal Compiler Error with arch knl
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthew.thompson at nasa dot gov
  Target Milestone: ---

Created attachment 39485
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39485&action=edit
Tarball with offending code and GNUmakefile

I have a code that when it is compiled with -march=knl -mtune=knl, causes an
ICE (see output below). It doesn't ICE out with, say -march=haswell
-mtune=intel.


This is with GCC 6.1.0, I haven't tried 6.2.0 yet, but I'll try and get that
built today.

I have to attach a tarball because the offending code depends on other codes to
compile. To test the fault, just run "make". This code does *not* make an
executable as I included just the files necessary to throw the ICE.

(444) $ gfortran -O3 -march=knl -mtune=knl -funroll-loops
-ffixed-line-length-132 -fno-range-check -fPIC -ffpe-trap=zero,overflow
-fbacktrace -falign-commons -save-temps -v -c sorad.F90
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-6.1.0/configure
--prefix=/ford1/local/gcc/gcc-6.1.0-rhel6 --disable-multilib
Thread model: posix
gcc version 6.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-O3' '-march=knl' '-mtune=knl' '-funroll-loops'
'-ffixed-line-length-132' '-fno-range-check' '-fPIC' '-ffpe-trap=zero,overflow'
'-fbacktrace' '-falign-commons' '-save-temps' '-v' '-c'
 /ford1/local/gcc/gcc-6.1.0-rhel6/libexec/gcc/x86_64-pc-linux-gnu/6.1.0/f951
sorad.F90 -cpp=sorad.f90 -quiet -v sorad.F90 -quiet -dumpbase sorad.F90
-march=knl -mtune=knl -auxbase sorad -O3 -version -funroll-loops
-ffixed-line-length-132 -fno-range-check -fPIC -ffpe-trap=zero,overflow
-fbacktrace -falign-commons -fintrinsic-modules-path
/ford1/local/gcc/gcc-6.1.0-rhel6/lib/gcc/x86_64-pc-linux-gnu/6.1.0/finclude -o
sorad.s
GNU Fortran (GCC) version 6.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.1.0, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/ford1/local/gcc/gcc-6.1.0-rhel6/lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /ford1/local/gcc/gcc-6.1.0-rhel6/lib/gcc/x86_64-pc-linux-gnu/6.1.0/finclude
 /ford1/local/gcc/gcc-6.1.0-rhel6/lib/gcc/x86_64-pc-linux-gnu/6.1.0/include
 /usr/local/include
 /ford1/local/gcc/gcc-6.1.0-rhel6/include

/ford1/local/gcc/gcc-6.1.0-rhel6/lib/gcc/x86_64-pc-linux-gnu/6.1.0/include-fixed
 /usr/include
End of search list.
GNU Fortran2008 (GCC) version 6.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.1.0, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
sorad.F90:126:0:

subroutine sorad (m,np,nb,cosz_dev,pl_dev,ta_dev,wa_dev,oa_dev,co2,&

internal compiler error: in ix86_fp_cmp_code_to_pcmp_immediate, at
config/i386/i386.c:23042
0xd06b6b ix86_fp_cmp_code_to_pcmp_immediate
../../gcc-6.1.0/gcc/config/i386/i386.c:23042
0xd06b6b ix86_cmp_code_to_pcmp_immediate
../../gcc-6.1.0/gcc/config/i386/i386.c:23053
0xd06b6b ix86_expand_mask_vec_cmp(rtx_def**)
../../gcc-6.1.0/gcc/config/i386/i386.c:23065
0xe999a5 gen_vec_cmpv16sfhi(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
../../gcc-6.1.0/gcc/config/i386/sse.md:2851
0x9cfc88 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
../../gcc-6.1.0/gcc/optabs.c:7032
0x9cfc88 expand_insn(insn_code, unsigned int, expand_operand*)
../../gcc-6.1.0/gcc/optabs.c:7063
0x9d0605 expand_vec_cmp_expr(tree_node*, tree_node*, rtx_def*)
../../gcc-6.1.0/gcc/optabs.c:5673
0x83e788 do_store_flag
../../gcc-6.1.0/gcc/expr.c:11146
0x83e788 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc-6.1.0/gcc/expr.c:9067
0x82ef8a expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-6.1.0/gcc/expr.c:9577
0x836ca0 expand_expr
../../gcc-6.1.0/gcc/expr.h:256
0x836ca0 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
../../gcc-6.1.0/gcc/expr.c:7563
0x83b85e expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc-6.1.0/gcc/expr.c:9368
0x82ef8a expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-6.1.0/gcc/expr.c:9577
0x9d0124 expand_normal
../../gcc-6.1.0/gcc/expr.h:262
0x9d0124 expand_vec_cond_mask_expr(tree_node*, tree_node*, tree_node*,
tree_node*, rtx_def*)
../../gcc-6.1.0/gcc/optabs.

[Bug target/77345] New: [7 Regression] Segmentation fault w/ -misel -O1 (and above)

[asolokha at gmx dot com]

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

Bug ID: 77345
   Summary: [7 Regression] Segmentation fault w/ -misel -O1 (and
above)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu*

gcc-7.0.0-alpha20160821 and some earlier snapshots (at least back to
7.0.0-alpha20160731) ICE when compiling the following snippet for 32-bit BE
powerpc target w/ -misel -O1 (and above):

int
tk (long long int vu)
{
  int ar = (vu != 0);
  return (ar + ((ar != 0) ? vu : ar)) || ar;
}

% powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20160821 -misel -O1 -c j0w1vfcr.c 
powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20160821: internal compiler error:
Segmentation fault (program cc1)

gdb fails to produce a usable backtrace because of seemingly corrupted stack
(?).

This one is for powerpc-e300c3-linux-gnu:

(gdb) where
#0  0x02aaab354241 in simplify_const_binary_operation (code=PLUS,
mode=SImode, op0=0x3ffee299c60, op1=0x3fff7097018)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20160821/work/gcc-7-20160821/gcc/simplify-rtx.c:3815
Backtrace stopped: Cannot access memory at address 0x3fffbffef30

And the next one is for powerpc-e500v2-linux-gnuspe:

(gdb) where
#0  0x02aaabc67f0a in reg_nonzero_bits_for_combine (x=0x3fff703b5b8,
mode=CCmode, known_x=0x0, known_mode=VOIDmode, known_ret=0, 
nonzero=0x3fffc50)
at
/var/tmp/portage/cross-powerpc-e500v2-linux-gnuspe/gcc-7.0.0_alpha20160731/work/gcc-7-20160731/gcc/combine.c:9857
Backtrace stopped: Cannot access memory at address 0x3fffbffefe8

[Bug libstdc++/60936] [5/6/7 Regression] Binary code bloat with std::string

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  ---
Yes, but it removes functionality, and we don't want to do that
unconditionally.

[Bug libstdc++/71771] DR 685 applied incorrectly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Fixed on trunk by removing the non-standard overloads.

[Bug libstdc++/60936] [5/6/7 Regression] Binary code bloat with std::string

[d.v.a at ngs dot ru]

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

--- Comment #22 from __vic  ---
Of course. It's comment for people like me who needs solution right now
(actually since 2014...)

[Bug c++/77338] [7 Regression] ICE on invalid C++11 code on x86_64-linux-gnu: Segmentation fault

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I can't reproduce:

$ ./cc1plus -quiet q.C
q.C:3:51: error: no match for call to ‘(S) (S&)’
 template < typename > auto f (S s)->decltype (s (s));
   ^
q.C:3:51: error: no match for call to ‘(S) (S&)’

[Bug c++/77339] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: in cp_parser_type_name, at cp/parser.c:16532

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug target/77346] New: [7 Regression] ICE in push_reload, at reload.c:1350

[asolokha at gmx dot com]

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

Bug ID: 77346
   Summary: [7 Regression] ICE in push_reload, at reload.c:1350
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu*

gcc-7.0.0-alpha20160821 snapshots fails to compile the following snippet w/
-mno-lra -Os:

int qd, mc, t0;
long long int o1, rr, iw, sv;

void
hx (int c9)
{
  int *dt = &qd;

  while (qd != 0)
for (rr = 2; rr < 6; ++rr)
  {
qd = t0;
if (dt != 0)
  {
mc = c9;
iw = &qd;
while (o1 < 0)
  {
dt = &t0;
++o1;
  }
  }
sv = 0;
  }
}

% powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20160821 -mno-lra -Os -c -w
buwdtjav.c 
buwdtjav.c: In function 'hx':
buwdtjav.c:25:1: internal compiler error: in push_reload, at reload.c:1350

[Bug c++/77339] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: in cp_parser_type_name, at cp/parser.c:16532

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
I'm pretty sure this started with r181118:

commit 370478b178a3bdf01988c16782c90add8aea26aa
Author: dodji 
Date:   Mon Nov 7 21:28:50 2011 +

PR c++/45114 - Support C++11 alias-declaration

[Bug c++/77339] [5/6/7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: in cp_parser_type_name, at cp/parser.c:16532

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
clang++ says
w.C:4:25: error: type 'A' (aka 'int') cannot be used prior to '::' because
it has no members
template < typename X > A < X >::a;
^
w.C:1:23: note: type alias template 'A' declared here
template < typename > using A = int;
  ^
1 error generated.

[Bug c/77332] ICE when building gcc 6.2 (with gcc 6.1.0)

[gcc.hall at gmail dot com]

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

--- Comment #2 from Jeremy  ---
(In reply to Richard Biener from comment #1)
> I can't reproduce it.  It seems to happen in stage2 (-g -gtoggle) and I'm
> past that trying to reproduce (also that's the only stage where checking
> code is run).
> 
> Can you attach preprocessed source for the failing command source?

No I cant, sorry.
I suspect this may be environmental.
I tried again and it failed somewhere else.  I tried a third time on a
different disk and the build completed fine.  I tried a fourth time on the
original disk and it worked fine too.  So I cant reproduce it any more.  I have
built gcc many times on many machines and don't normally have any trouble.

[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres  ---
> Author: jakub
> Date: Fri Aug 19 15:30:33 2016
> New Revision: 239620
> ...

Is it fixed?

[Bug libstdc++/71771] DR 685 applied incorrectly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.5
  Known to fail||5.4.0, 6.2.0

--- Comment #10 from Jonathan Wakely  ---
Fixed for 5.5 and 6.3 by constraining the non-standard overload.

I forgot to put the PR number in the changelog, the commits are r239696 for
gcc-5 and r239694 for gcc-6.

[Bug fortran/72798] Module (.mod) file changes even when interface does not

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Without a test showing the problem I'll close this PR as INVALID.

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

[webrown.cpp at gmail dot com]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #3 from Eric Gallager  ---
I think a better fixit would be to suggest using strcat or strncat or strlcat
or something, since that actually appends to the string like the programmer
probably intended to do. Abusing array indexing like that just looks wrong.

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-23
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #9 from ktkachov at gcc dot gnu.org ---
Note that the fpu option plays a role here as well

When I compile with -O3 -S -mfloat-abi=hard -march=armv7-a -mthumb
-mtune=cortex-a8 -mfpu=neon

I get:
sha512_block_data_order:
@ args = 0, pretend = 0, frame = 2384
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, r5, r6, r7, r8, r9, r10, fp, lr}
subwsp, sp, #2388
subsr4, r2, #1


whereas if you leave out the -mfpu you get the default which is probably 'vfp'
if you didn't configure gcc with an explicit --with-fpu. This is usually not a
good fit for recent targets.
With -mfpu=vfp I get the terrible:
sha512_block_data_order:
@ args = 0, pretend = 0, frame = 3568
@ frame_needed = 0, uses_anonymous_args = 0
push{r4, r5, r6, r7, r8, r9, r10, fp, lr}
subwsp, sp, #3572
subsr4, r2, #1

That said, I bet there's still room for improvement

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[steven.shi at intel dot com]

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

--- Comment #19 from Steven Shi  ---
(In reply to vries from comment #18)
> Created attachment 39484 [details]
> Tentative patch using attributes ms_abi/sysv_abi
> 
> not build or regression tested yet, but at least makes test-case pass.

Vries,
I tried apply your patch on latest gcc trunk, build and install the new gcc7,
it still cannot work. Below is my test case.

$ gcc --version
gcc (GCC) 7.0.0 20160823 (experimental)

$ cat test2.c
#include 

int
__attribute__((ms_abi))
foo (int n, ...)
{
  __builtin_ms_va_list ap;
  int sum = 0;

  __builtin_ms_va_start (ap, n);

  while (n--) {
sum += __builtin_va_arg (ap, int);
printf("sum = %d\n", sum);
  }
  __builtin_ms_va_end (ap);

  return sum;
}

int main ()
{
  int res = foo (10, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

  if (res != 55)
__builtin_abort ();

  return 0;
}

$ gcc -flto -Os test2.c
$ ./a.out
Segmentation fault (core dumped)

But GCC5 works.
$ gcc-5 -flto -Os test2.c
$ ./a.out
sum = 1
sum = 3
sum = 6
sum = 10
sum = 15
sum = 21
sum = 28
sum = 36
sum = 45
sum = 55

[Bug c++/77347] New: [6 Regression] Incorrect auto deduction failure in template class member function

[lhyatt at gmail dot com]

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

Bug ID: 77347
   Summary: [6 Regression] Incorrect auto deduction failure in
template class member function
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lhyatt at gmail dot com
  Target Milestone: ---

The following valid test case fails to compile starting with gcc 6:

t.cpp
===
template auto f() {return 0U;}
template
struct B {
unsigned g() {
auto i = 0U, j = f();
return i+j;
}
};
auto i = B<>{}.g();
===

$ g++ -std=c++14 -c t.cpp
t.cpp: In member function 'unsigned int B<  >::g()':
t.cpp:5:9: error: inconsistent deduction for 'auto': 'unsigned int' and then
'auto'
 auto i = 0U, j = f();
 ^~~~
===

here is output of g++ -v:
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-6.2.0/configure --prefix=/usr/local/gcc-6.2.0
--with-tune=native
Thread model: posix
gcc version 6.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=native' '-march=x86-64'
 /usr/local/gcc-6.2.0/libexec/gcc/x86_64-pc-linux-gnu/6.2.0/cc1plus -quiet -v
-imultiarch x86_64-linux-gnu -D_GNU_SOURCE t.cpp --param l1-cache-size=32
--param l1-cache-line-size=64 --param l2-cache-size=20480 -mtune=sandybridge
-quiet -dumpbase t.cpp -march=x86-64 -auxbase t -version -o /tmp/ccXuYkVf.s
GNU C++14 (GCC) version 6.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.2.0, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/gcc-6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/gcc-6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/../../../../include/c++/6.2.0

/usr/local/gcc-6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/../../../../include/c++/6.2.0/x86_64-pc-linux-gnu

/usr/local/gcc-6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/../../../../include/c++/6.2.0/backward
 /usr/local/gcc-6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/include
 /usr/local/include
 /usr/local/gcc-6.2.0/include
 /usr/local/gcc-6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++14 (GCC) version 6.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.2.0, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 0e0cf061fe2036427948ceefe0c946f5
===

The issue seems to require that both the global function f and the class B in
which the member function g() lives should be templates.

The issue is still present on the current mainline, it started with r231349:

b34f7e66cb96f137d5283d6285ffa1d333756e52 is the first bad commit
commit b34f7e66cb96f137d5283d6285ffa1d333756e52
Author: jason 
Date:   Mon Dec 7 04:34:43 2015 +

PR c++/68597, fix auto9.C and auto-neg1.C with -std=c++1z.

* decl.c (check_tag_decl): Use ds_type_spec in auto diagnostic.
* typeck.c (check_return_expr): Check for inconsistent deduction.
* parser.c (class type_id_in_expr_sentinel): New.
(cp_parser_primary_expression) [RID_VA_ARG]: Use it.
(cp_parser_new_expression): Use it.
(cp_parser_trait_expr): Use it.
(cp_parser_type_id_1): Complain about auto if in_type_id_in_expr_p.
(cp_parser_default_type_template_argument): Check for auto.
(cp_parser_type_id_list): Likewise.
(cp_parser_simple_type_specifier): Allow auto parms if flag_concepts.
* pt.c (do_auto_deduction): Handle erroneous type.

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

Thanks...

-lewis

[Bug testsuite/69620] gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times optimized fails for powerpc64-linux-gnu

[tiago.brusamarello at datacom dot ind.br]

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

--- Comment #2 from Tiago Brusamarello  ---
(In reply to Andrew Pinski from comment #1)
> Does this fail on 5.4.0?  4.9.4 was the last release of 4.9

We've tested it so far on GCC version 5.3 for PPC64 platforms. In this case the
test result is UNSUPPORTED.

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[vries at gcc dot gnu.org]

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

--- Comment #20 from vries at gcc dot gnu.org ---
(In reply to Steven Shi from comment #19)
> (In reply to vries from comment #18)
> > Created attachment 39484 [details]
> > Tentative patch using attributes ms_abi/sysv_abi
> > 
> > not build or regression tested yet, but at least makes test-case pass.
> 
> Vries,
> I tried apply your patch on latest gcc trunk, build and install the new
> gcc7, it still cannot work. 

I can reproduce the failure with your testcase. The failure disappears when I
apply the patch and rebuild. So, I can't reproduce your observation.

> Below is my test case.

Please next time refer to the PR rather than copy/pasting.

[Bug libstdc++/77334] [5/6/7 Regression] Cannot move assign std::map with non-copyable and non-movable mapped_type

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Tue Aug 23 13:15:12 2016
New Revision: 239698

URL: https://gcc.gnu.org/viewcvs?rev=239698&root=gcc&view=rev
Log:
libstdc++/77334 move assign RB trees of non-copyable types

PR libstdc++/77334
* include/bits/stl_tree.h (_Rb_tree::_M_move_assign): New functions.
(_Rb_tree::operator=(_Rb_tree&&)): Dispatch to _M_move_assign.
* testsuite/23_containers/map/77334.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/23_containers/map/77334.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_tree.h

[Bug target/77330] __float128 segfaults on 32-bit x86 due to 8-byte malloc alignment

[mikulas at artax dot karlin.mff.cuni.cz]

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

--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz ---
Glibc doesn't support types __float128 and decimal float. Only GCC does.

Glibc can't be responsible for decisions made by the GCC developers. Glibc has
been aliging allocated memory on 8 bytes on 32-bit architectures since ever. It
was GCC decision to introduce these new types and it was GCC decision that
these types have 16-byte alignment. GCC could have defined them as 16-byte
values with 8-byte alignment.

When copying general data structures, GCC understand that the memory may be
aligned only on 8 bytes and uses MOVLPS / MOVHPS instructions instead of
MOVAPS. But with __float128, _Decimal128 and SSE vectors, it mistakenly
believes that they are 16-byte aligned.

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[steven.shi at intel dot com]

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

--- Comment #21 from Steven Shi  ---
Vries,
Sorry, my bad. I didn't apply your patch completely. Yes, your patch works.
And with your patch, my UEFU firmware gcc lto build pass and boot successfully.
Hope we could check in a formal fix ASAP, because the lto build is Uefi
firmware GCC default build now. This regression bug block us to adopt new
version GCC on Uefi firmware. Thanks!

[Bug target/77330] __float128 segfaults on 32-bit x86 due to 8-byte malloc alignment

[mikulas at artax dot karlin.mff.cuni.cz]

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

--- Comment #3 from mikulas at artax dot karlin.mff.cuni.cz ---
BTW. gcc thinks that with -m32, allocated memory is aligned to 4 bytes and with
-m64 and -mx32, allocated memory is aligned to 16 bytes. You can try to compile
this program into assembler and see if the malloc call is optimized away. On
-m32, it gets optimized away with the constant "3" and it won't get optimized
away with "7" or more.

#include 
#include 

int main(void)
{
void *p = malloc(123);
printf("%d\n", (int)p & 3);
return 0;
}

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener  ---
(In reply to vries from comment #18)
> Created attachment 39484 [details]
> Tentative patch using attributes ms_abi/sysv_abi
> 
> not build or regression tested yet, but at least makes test-case pass.

LGTM.

[Bug other/61460] Demangler crash (GDB PR 17043)

[sbergman at redhat dot com]

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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #1 from Stephan Bergmann  ---
Experienced a similar c++filt SIGSEV (due to recursive stack overflow) now with
the symbol

_ZNK6clover6detail11basic_rangeINS_13adaptor_rangeIZNS_6kernel6launchERNS_13command_queueERKSt6vectorImSaImEESA_SA_EUlmE_JRS8_EEENS0_16iterator_adaptorISB_JN9__gnu_cxx17__normal_iteratorIPmS8_ESJ_EcvT_IS6_IPjSaISN_EEvEEv

(also while debugging a process involving libMesaOpenCL; on Fedora 24).  Bug
70909 presumably discusses the root cause of these crashes.

[Bug c++/70909] Libiberty Demangler segfaults (4)

[sbergman at redhat dot com]

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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #1 from Stephan Bergmann  ---
(In reply to Marcel Böhme from comment #0)
> This specific stack overflow has not been reported but with a bit of
> searching it seems to be linked to the open bugs PR61460, PR68700, PR67738,
> PR68383, PR70517, PR61805, PR62279, and the meta bug PR67264. The prepared
> patch addresses all of these.

Is that patch available anywhere?

[Bug target/72851] [6 Regression] memory hog with -O3 on s390x-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Tue Aug 23 13:49:00 2016
New Revision: 239699

URL: https://gcc.gnu.org/viewcvs?rev=239699&root=gcc&view=rev
Log:
2016-08-23  Richard Biener  

Backport from mainline
2016-08-16  Richard Biener  

PR tree-optimization/76783
* tree-ssa-propagate.c (ssa_prop_init): Use RPO order.  Clear
BB visited flags at start.

* gcc.dg/pr76783.c: New testcase.
* gcc.dg/tree-ssa/pr69270-2.c: Adjust.

2016-08-12  Richard Biener  

PR tree-optimization/72851
* tree-ssa-propagate.c: Include cfganal.h.  Rewrite block and stmt
worklists to use bitmaps indexed in execution order.
(executable_blocks, cfg_blocks_num, cfg_blocks_tail, cfg_blocks_head,
bb_in_list, interesting_ssa_edges, varying_ssa_edges): Remove.
(cfg_blocks): Make a bitmap.
(bb_to_cfg_order, cfg_order_to_bb, ssa_edge_worklist, uid_to_stmt):
New globals.
(cfg_blocks_empty_p): Adjust.
(cfg_blocks_add): Likewise.
(cfg_blocks_get): Likewise.
(add_ssa_edge): Likewise.
(add_control_edge): Likewise.
(simulate_stmt): Likewise.
(process_ssa_edge_worklist): Likewise.
(simulate_block): Likewise.
(ssa_prop_init): Compute PRE order and stmt UIDs.
(ssa_prop_fini): Adjust.
(ssa_propagate): Adjust.

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

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr76783.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr72851.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.dg/tree-ssa/pr69270-2.c
branches/gcc-6-branch/gcc/tree-ssa-propagate.c

[Bug tree-optimization/76783] [7 Regression] wrong code with conditional vector assignment @ -Og

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Aug 23 13:49:00 2016
New Revision: 239699

URL: https://gcc.gnu.org/viewcvs?rev=239699&root=gcc&view=rev
Log:
2016-08-23  Richard Biener  

Backport from mainline
2016-08-16  Richard Biener  

PR tree-optimization/76783
* tree-ssa-propagate.c (ssa_prop_init): Use RPO order.  Clear
BB visited flags at start.

* gcc.dg/pr76783.c: New testcase.
* gcc.dg/tree-ssa/pr69270-2.c: Adjust.

2016-08-12  Richard Biener  

PR tree-optimization/72851
* tree-ssa-propagate.c: Include cfganal.h.  Rewrite block and stmt
worklists to use bitmaps indexed in execution order.
(executable_blocks, cfg_blocks_num, cfg_blocks_tail, cfg_blocks_head,
bb_in_list, interesting_ssa_edges, varying_ssa_edges): Remove.
(cfg_blocks): Make a bitmap.
(bb_to_cfg_order, cfg_order_to_bb, ssa_edge_worklist, uid_to_stmt):
New globals.
(cfg_blocks_empty_p): Adjust.
(cfg_blocks_add): Likewise.
(cfg_blocks_get): Likewise.
(add_ssa_edge): Likewise.
(add_control_edge): Likewise.
(simulate_stmt): Likewise.
(process_ssa_edge_worklist): Likewise.
(simulate_block): Likewise.
(ssa_prop_init): Compute PRE order and stmt UIDs.
(ssa_prop_fini): Adjust.
(ssa_propagate): Adjust.

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

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr76783.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr72851.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.dg/tree-ssa/pr69270-2.c
branches/gcc-6-branch/gcc/tree-ssa-propagate.c

[Bug target/72851] [6 Regression] memory hog with -O3 on s390x-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.2.1
 Resolution|--- |FIXED

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

[Bug c++/77347] [6/7 Regression] Incorrect auto deduction failure in template class member function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.3
Summary|[6 Regression] Incorrect|[6/7 Regression] Incorrect
   |auto deduction failure in   |auto deduction failure in
   |template class member   |template class member
   |function|function

[Bug target/77346] [7 Regression] ICE in push_reload, at reload.c:1350

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug target/77345] [7 Regression] Segmentation fault w/ -misel -O1 (and above)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug tree-optimization/77286] [7 Regression] ICE in fold_convert_loc, at fold-const.c:2248 building 435.gromacs

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Tue Aug 23 13:58:19 2016
New Revision: 239700

URL: https://gcc.gnu.org/viewcvs?rev=239700&root=gcc&view=rev
Log:
2016-08-23  Richard Biener  

PR tree-optimization/77286
* tree-vect-loop.c (vect_analyze_loop_form_1): Do not modify
the CFG here.
(vect_transform_loop): Split exit edges of loop and scalar
loop if required and at the appropriate time.

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

[Bug target/77348] New: -march=skylake still not working because config.gcc

[dflater at nist dot gov]

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

Bug ID: 77348
   Summary: -march=skylake still not working because config.gcc
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dflater at nist dot gov
  Target Milestone: ---

Created attachment 39486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39486&action=edit
patch for config.gcc to add skylake

Problem existed in 6.1.0 release and persists in 6.2.0 release.
Cannot configure for -march=skylake because it's missing in config.gcc.
Patch attached.

[Bug c++/70909] Libiberty Demangler segfaults (4)

[boehme.marcel at gmail dot com]

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

--- Comment #2 from Marcel Böhme  ---
Here: https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00105.html
Pending review.

[Bug target/77348] --with-arch=skylake still not working because config.gcc

[dflater at nist dot gov]

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

David Flater  changed:

   What|Removed |Added

 CC||dflater at nist dot gov

--- Comment #1 from David Flater  ---
Correction, cannot configure --with-arch=skyake.

[Bug libstdc++/77334] [5/6/7 Regression] Cannot move assign std::map with non-copyable and non-movable mapped_type

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue Aug 23 14:20:50 2016
New Revision: 239701

URL: https://gcc.gnu.org/viewcvs?rev=239701&root=gcc&view=rev
Log:
libstdc++/77334 move assign RB trees of non-copyable types

PR libstdc++/77334
* include/bits/stl_tree.h (_Rb_tree::_M_move_assign): New functions.
(_Rb_tree::operator=(_Rb_tree&&)): Dispatch to _M_move_assign.
Include _Compare in noexcept.
* testsuite/23_containers/map/77334.cc: New test.

Added:
branches/gcc-5-branch/libstdc++-v3/testsuite/23_containers/map/77334.cc
Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/bits/stl_tree.h

[Bug libstdc++/77334] [5/6/7 Regression] Cannot move assign std::map with non-copyable and non-movable mapped_type

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue Aug 23 14:21:16 2016
New Revision: 239702

URL: https://gcc.gnu.org/viewcvs?rev=239702&root=gcc&view=rev
Log:
libstdc++/77334 move assign RB trees of non-copyable types

PR libstdc++/77334
* include/bits/stl_tree.h (_Rb_tree::_M_move_assign): New functions.
(_Rb_tree::operator=(_Rb_tree&&)): Dispatch to _M_move_assign.
* testsuite/23_containers/map/77334.cc: New test.

Added:
branches/gcc-6-branch/libstdc++-v3/testsuite/23_containers/map/77334.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/bits/stl_tree.h

[Bug libstdc++/77334] [5/6/7 Regression] Cannot move assign std::map with non-copyable and non-movable mapped_type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed for 5.5, 6.3 and 7.

[Bug target/77349] New: AIX DWARF debugging offset in 64 bit mode

[dje at gcc dot gnu.org]

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

Bug ID: 77349
   Summary: AIX DWARF debugging offset in 64 bit mode
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

The AIX assembler implicitly inserts the length information at the beginning of
DWARF debugging sections.  In 64 bit mode, it also implicitly inserts the 64
bit DWARF extension escape sequence. This requires that GCC emit 64 bit offsets
to match the directive emitted by the assembler.

[Bug target/77349] AIX DWARF debugging offset in 64 bit mode

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

   Keywords||wrong-debug
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-08-23
   Assignee|unassigned at gcc dot gnu.org  |dje at gcc dot gnu.org
   Target Milestone|--- |5.5
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug rtl-optimization/69847] Spec 2006 403.gcc slows down with -mlra vs. reload on PowerPC

[wdijkstr at arm dot com]

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

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #27 from Wilco  ---
On AArch64 this patch improves codesize slightly and perf results are within
noise. Typical changes are like:

1)
 mov x1, x2
 mov w2, 96
 ldr x1, [x1, 8]
  --->>
 ldr x1, [x2, 8]
 mov w2, 96

2)
 addx0, x0, :lo12:board
 movx26, x0
--->>>
 addx26, x0, :lo12:board

so basically avoiding redundant moves which is always good.

[Bug middle-end/61409] [5/6/7 regression] -Wmaybe-uninitialized false-positive with -O2

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #18 from Aldy Hernandez  ---
(In reply to Jeffrey A. Law from comment #16)
> AFAICT tree-ssa-uninit won't look at the predicate associated with an
> undefined PHI argument and test it against the predicate for the actual use.
> 
> ie, given this PHI from the testcase:
> 
> ;;   basic block 6, loop depth 0
> ;;pred:   9
> ;;5
>   # ptr_1 = PHI 
> 
> We want to look at the control dependent path that leads to the edge (9,5). 
> For this test, that edge is control dependent on bb2:

Jeff, do you mean edge(9,6) throughout?  Because I don't see any flow of
control from 9->5.

[Bug target/69789] g++ -O2 is removing tests against a variable that can be changed

[tmark at isc dot org]

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

--- Comment #8 from Thomas Markwalder  ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Thomas Markwalder from comment #5)
> > A bit more digging reveals that in the logic expression which fails:
> > 
> > {{{
> > // Check if we need to run the operation again.
> > if (ec == boost::asio::error::would_block
> > || ec == boost::asio::error::try_again)
> >   return false;
> > }}}
> > 
> > The value for error_category:m_cat differs between the implicitly created
> > instances for would_block and try_again.
> 
> Do you mean that error_code(boost::asio::error::would_block) !=
> error_code(boost::asio::error::try_again) ?
> 
> I don't see how that's possible, since in the optimized GIMPLE dump they
> both use the same constructor, which isn't inlined. The two enums have the
> same value, and the constructor will call the same asio::make_error_code()
> overload that sets the category to boost::system_category().
> 
>  
> boost::system::error_code::error_code
> (&D.94931, 11, 0B);
>   cleanup.88 = 1;
>   D.165192 = boost::system::operator== (ec, &D.94931);
>   if (D.165192 != 0) goto ; else goto ;
>   :
>  
> boost::system::error_code::error_code
> (&D.94932, 11, 0B);
>   cleanup.89 = 1;
>   D.165197 = boost::system::operator== (ec, &D.94932);
>   if (D.165197 != 0) goto ; else goto ;
>   :
>   iftmp.87 = 1;
>   goto ;
>   :
>   iftmp.87 = 0;
>   :
>   retval.86 = iftmp.87;
> 
> 
> So what exactly are you seeing? What digging have you done? Stepped through
> with the debugger?
> 
> The most likely explanation seems to be that ec.category() !=
> boost::system::system_category() and so the comparisons are always false.
> 
> 
> > If one splits the if into two separate if statements,  the values for m_cat
> > are the same.  This looks a like the behavior described under "Static
> > Variables in Inline Functions" described here:
> > 
> > http://processors.wiki.ti.com/index.php/C++_Inlining_Issues
> 
> This function has nothing to do with static variables.

Hello Jonathan:

It has been some months since I looked at this so let me try to recap. 
I did do a great deal of stepping through with the debugger as well as
instrumented the Boost code with couts in various places.  The basic issue
seems to be that when you build Boost such that BOOST_ERROR_CODE_HEADER_ONLY is 
defined, then the following function in /system/detail/error_code.ipp
is declared as inline:

  : 
# ifdef BOOST_ERROR_CODE_HEADER_ONLY
#   define BOOST_SYSTEM_LINKAGE inline
# else
#   define BOOST_SYSTEM_LINKAGE BOOST_SYSTEM_DECL
# endif

BOOST_SYSTEM_LINKAGE const error_category & system_category()
BOOST_SYSTEM_NOEXCEPT
{
  static const system_error_category  system_category_const;
  return system_category_const;
}
  :

Apparently some combination of boost includes along with our own, and building
with optimization, we end up with more than once instance of this function
each with its own value for the static variable, system_error_category.  Thus
the value returned by invoking system_category() depends upon which instance
is invoked. The result is the aforementioned if-clause:

// Check if we need to run the operation again.
if (ec == boost::asio::error::would_block
|| ec == boost::asio::error::try_again)
  return false;

not evaluating to true even though it should. I confirmed with the debugger
that  ec.m_cat does not reliably equal would_block.m_cat or try_again.m_cat.
If you split the clause into two separate statements it works reliably:

// Check if we need to run the operation again.
if (ec == boost::asio::error::would_block)
  return false;

// Check if we need to run the operation again.
if (ec == boost::asio::error::try_again)
  return false;

Not necessarily meaningful, but noteworthy, and of course, I can't use that
as a solution as that's within the boost code.

If one compiles without optimization or one builds with Boost system library 
rather than with BOOST_ERROR_CODE_HEADER_ONLY defined, the issue disappears.
I did try to replicate it with only boost code and could not do so.  I think
there is some corner case we are hitting in permits there to be more than
one static instance of system_error_category.

[Bug c++/77338] [7 Regression] ICE on invalid C++11 code on x86_64-linux-gnu: Segmentation fault

[su at cs dot ucdavis.edu]

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

--- Comment #2 from Zhendong Su  ---
(In reply to Marek Polacek from comment #1)
> I can't reproduce:
> 
> $ ./cc1plus -quiet q.C
> q.C:3:51: error: no match for call to ‘(S) (S&)’
>  template < typename > auto f (S s)->decltype (s (s));
>^
> q.C:3:51: error: no match for call to ‘(S) (S&)’

Marek, I still see the ICE with r239693: 

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160823 (experimental) [trunk revision 239693] (GCC) 
$ 
$ g++-trunk -c small.cpp
small.cpp:3:51: internal compiler error: Segmentation fault
 template < typename > auto f (S s)->decltype (s (s));
   ^
0xdd6b2f crash_signal
../../gcc-source-trunk/gcc/toplev.c:335
0x749d4b tree_check
../../gcc-source-trunk/gcc/tree.h:3025
0x749d4b is_really_empty_class(tree_node*)
../../gcc-source-trunk/gcc/cp/class.c:8447
0x8b7822 cxx_eval_constant_expression
../../gcc-source-trunk/gcc/cp/constexpr.c:3750
0x8bdb99 cxx_eval_outermost_constant_expr
../../gcc-source-trunk/gcc/cp/constexpr.c:4390
0x8c10ee fold_non_dependent_expr(tree_node*)
../../gcc-source-trunk/gcc/cp/constexpr.c:4669
0x6c98d4 build_non_dependent_expr(tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:23818
0x821b40 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc-source-trunk/gcc/cp/semantics.c:2329
0x798770 cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6937
0x79992d cp_parser_decltype_expr
../../gcc-source-trunk/gcc/cp/parser.c:13266
0x79992d cp_parser_decltype
../../gcc-source-trunk/gcc/cp/parser.c:13367
0x797be7 cp_parser_simple_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:16258
0x793e61 cp_parser_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:16049
0x7963d2 cp_parser_type_specifier_seq
../../gcc-source-trunk/gcc/cp/parser.c:20184
0x7a0ab2 cp_parser_type_id_1
../../gcc-source-trunk/gcc/cp/parser.c:20046
0x7a0276 cp_parser_trailing_type_id
../../gcc-source-trunk/gcc/cp/parser.c:20118
0x7a0276 cp_parser_late_return_type_opt
../../gcc-source-trunk/gcc/cp/parser.c:19958
0x7a0276 cp_parser_direct_declarator
../../gcc-source-trunk/gcc/cp/parser.c:19147
0x7a0276 cp_parser_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18967
0x7b6025 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18512
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$

[Bug middle-end/61409] [5/6/7 regression] -Wmaybe-uninitialized false-positive with -O2

[aldyh at gcc dot gnu.org]

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

--- Comment #19 from Aldy Hernandez  ---
Also, unless I'm missing something, in Jeff's analysis, I see no reference to
j, which plays a pivotal role.

In the testcase in comment 14, we can see that the guard for ptr_14 is actually
[i && j==0]:

if (i)
  {
if (j)
  return; /* bar(); */
ptr = init();
  }

...because on j != 0, we exit, which is what the .uninit dump is suggesting
with:

[AFTER NORMALIZATION -- [DEF]:
ptr_14 = PHI 
is guarded by :

 (.NOT.) j_20(D) != 0 (.AND.) i_17(D) != 0

Meanwhile, the use we are warning on is [i != 0]:

[AFTER NORMALIZATION -- [USE]:
rw = ptr_14;
is guarded by :

i_17(D) != 0

So the problem is that while the guard for the DEF is [i != 0 && j == 0], the
guard for the USE is only [i != 0].  Uninit should somehow be aware that if PTR
was set, then  j==0, because otherwise we would've exited the function.

You can see that .uninit is expecting the use to be guarded by [i != 0 && j ==
0], by adding "&& !j" to the guard and silencing the warning:

   if (i && !j)
{
  rw=ptr;
}

[Bug middle-end/61409] [5/6/7 regression] -Wmaybe-uninitialized false-positive with -O2

[aldyh at gcc dot gnu.org]

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

--- Comment #21 from Aldy Hernandez  ---
Created attachment 39487
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39487&action=edit
even more^2 reduced testcase

Smaller testcase without any structure nonsense and even less variables.

[Bug target/68972] g++.dg/cpp1y/vla-initlist1.C test case fails on powerpc64le

[seurer at linux dot vnet.ibm.com]

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

--- Comment #6 from Bill Seurer  ---
This test started passing today.  I am not sure which update fixed it, though.

[Bug middle-end/61409] [5/6/7 regression] -Wmaybe-uninitialized false-positive with -O2

[aldyh at gcc dot gnu.org]

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

--- Comment #20 from Aldy Hernandez  ---
If anyone is interested, here is an even smaller testcase:

int *rw;
int line_height;
int pixel_width;
int text_cols;
int width1, width2, width3;

void *pointer;

void f (int i, int j)
{
  void *ptr;
  if (i)
{
  if (j)
return;
  ptr = pointer;
}
  pixel_width = 1234 + width1 + 2 * width2 + 2 * width3;
  *rw = text_cols + line_height;
  if (i)
rw=ptr;
}

[Bug target/77330] __float128 segfaults on 32-bit x86 due to 8-byte malloc alignment

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
When there isn't whole-implementation, including library, support for the 
types as "basic types" (see the resolution to DR#445), you need to 
consider them as some other kind of type, analogous to vector types, for 
which you need to use aligned_alloc (or posix_memalign etc.) just as with 
vector types (if you'd used __m512 in place of __float128, for example).  
But I say that unlike vector types, _Decimal128 and _Float128 *should* be 
considered basic types, and so glibc, supporting being used together with 
libdfp, *should* have the malloc alignment increased accordingly and this 
should be considered a glibc bug (which is no longer hard to fix thanks to 
the work done to fix malloc alignment on powerpc32).

It's always the case that however you construct a pointer to a type, it's 
your responsibility to ensure that it's appropriately aligned for that 
type, which means 16-byte-aligned for a structure containing __float128; 
it's not GCC's responsibility to second-guess whether your code really 
ensures that.  If there are 16-byte-aligned basic types, malloc is an 
appropriate means of ensuring that and it's a malloc bug not to provide 
such alignment.  When 16-byte-alignment is not a fundamental alignment 
requirement, malloc is not an appropriate means and using malloc there is 
a bug in the program using malloc for such an allocation.

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[wdijkstr at arm dot com]

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

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #10 from Wilco  ---
The register allocator doesn't correctly track liferanges for SETs with a
subreg and this can cause terrible spilling indeed.

Also why aren't DI mode values split into native SI registers on 32-bit
targets? Using DI mode registers means the register allocator has a much harder
problem to solve as it can only use even/odd register pairs (and must allocate
both registers even if one is dead).

[Bug c++/72775] [6/7 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:677

[mbertello at feralinteractive dot com]

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

Matteo Bertello  changed:

   What|Removed |Added

 CC||mbertello@feralinteractive.
   ||com

--- Comment #10 from Matteo Bertello  ---
Just had the same internal compiler error on a different piece of code, using
GCC 6.1.1 on Fedora 24.
Might be useful to investigate the cause.


#include 

void func(int i);

int main(int argc, char* argv[])
{
int val = 0;
auto thread = std::thread([&, =val]() { func(val); });
}

$ gcc main.cpp
main.cpp: In lambda function:
main.cpp:8:51: internal compiler error: in finish_expr_stmt, at
cp/semantics.c:677
  auto thread = std::thread([&, =val]() { func(val); });
   ^

[Bug middle-end/55496] False positive -Werror=uninitialized

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
Without a reduced testcase, it is impossible to know what the problem is.

[Bug c/77323] Bad "defaults to 'int'" warning for unsupported types

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
I think I've got a fix.

[Bug middle-end/61112] Simple example triggers false-positive -Wmaybe-uninitialized warning

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org
  Known to work||6.1.0
 Blocks||24639

--- Comment #3 from Manuel López-Ibáñez  ---
This appears fixed in 6.1, but it would be good to add the testcase to the
testsuite before closing it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug middle-end/60488] missing uninitialized warning (address taken, VOP)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-23
 Blocks||24639
Summary|missing |missing uninitialized
   |-Wmaybe-uninitialized on a  |warning (address taken,
   |conditional with goto   |VOP)
 Ever confirmed|0   |1

--- Comment #3 from Manuel López-Ibáñez  ---
I don't think the goto has anything to do with it, but there are several bugs
about taking the address of a variable breaking any obvious uninitialized
warnings.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug libstdc++/77334] [5/6/7 Regression] Cannot move assign std::map with non-copyable and non-movable mapped_type

[inadgob at yahoo dot com]

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

--- Comment #5 from bogdan  ---
From now on, "fast" shall have a new degree of comparison beyond the
superlative, spelled "jw-fast" (alternative spelling when appearing in text on
gcc.gnu.org: "redi-fast"). 

Cheers!

[Bug middle-end/65182] -Wuninitialized fails when pointer to variable later passed to function

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Blocks||24639

--- Comment #5 from Manuel López-Ibáñez  ---
This is fixed, but it would be good to add the testcase to the testsuite.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug middle-end/61428] wrong "maybe-uninitialized" (jump threading? predicate analysis?)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org
Version|unknown |5.0
 Blocks||24639
Summary|"maybe-uninitialized" is|wrong "maybe-uninitialized"
   |broken in all current   |(jump threading? predicate
   |versions (4.7-5)|analysis?)

--- Comment #2 from Manuel López-Ibáñez  ---
Unreduced testcase. Possibly jump threading or predicate analysis


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug middle-end/72781] -Wuninitialized false positives in OpenMP code

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  ---
Fixed?

[Bug middle-end/52602] false compilation warning of uninitialized variable

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Manuel López-Ibáñez  ---
No testcase forthcoming.

[Bug middle-end/70736] false positive uninitialized warning

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Richard Biener from comment #1)
> No longer warns with GCC 6, confirmed for GCC 5.  Didn't warn with GCC 4.8.

So it is regression for 5?

We could also close it and add the testcase to trunk.

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[vries at gcc dot gnu.org]

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

--- Comment #23 from Tom de Vries  ---
(In reply to Richard Biener from comment #22)
> (In reply to vries from comment #18)
> > Created attachment 39484 [details]
> > Tentative patch using attributes ms_abi/sysv_abi
> > 
> > not build or regression tested yet, but at least makes test-case pass.
> 
> LGTM.

Just realized, there's a potential problem with the patch and
sysv_va_list_type_node. sysv_va_list_type_node is an array type (array with
length 1 and a struct as element type).

grokdeclarator (in c-decl.c, see comment 'A parameter declared as an array of T
is really a pointer to T') converts that type into a pointer to array element
type (as explained in more detail in build_va_arg) and drops the attributes.

Perhaps we should mark the underlying element type with the attribute (as
well/instead? I'm not sure yet).

[Bug fortran/69860] ICE on missing end apostrophe with character(kind=4)

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

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

--- Comment #11 from Gerhard Steinmetz  
---
And with "kind=4" instead of "kind=1", i.e. with testfile z1.f90 ?


for n in `seq 1 1000`
do
   gfortran-7-20160821 -O2 -mavx -c z1.f90
done > list 2>&1

grep 'internal compiler' list | wc
9465676   47300


I can also confirm that ICEs are gone for z2.f90 ("kind=1").

[Bug fortran/70853] ICE on pointing to null, in gfc_add_block_to_block, at fortran/trans.c:1599

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

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

--- Comment #3 from Gerhard Steinmetz  
---
Another testcase :


$ cat z7.f90
program p
   integer, parameter :: m = 2, n = 3
   real, target :: a(m*n)
   real, pointer :: z(:,:) => null()
   z(1:m,1:n) => null()
end


$ gfortran-7-20160821 z7.f90
z7.f90:5:0:

z(1:m,1:n) => null()

internal compiler error: tree check: did not expect class 'type', have 'type'
(integer_type) in append_to_statement_list, at tree-iterator.c:92
0xead267 tree_not_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.c:9842
0xcab3ff non_type_check(tree_node*, char const*, int, char const*)
../../gcc/tree.h:3202
0xcab3ff append_to_statement_list(tree_node*, tree_node**)
../../gcc/tree-iterator.c:92
0x71f050 add_expr_to_chain
../../gcc/fortran/trans.c:1564
0x7213dd gfc_add_expr_to_block(stmtblock_t*, tree_node*)
../../gcc/fortran/trans.c:1577
0x7213dd gfc_add_block_to_block(stmtblock_t*, stmtblock_t*)
../../gcc/fortran/trans.c:1599
0x768486 gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8023
0x71fafa trans_code
../../gcc/fortran/trans.c:1695
0x74e708 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6204
0x6da360 translate_all_program_units
../../gcc/fortran/parse.c:5916
0x6da360 gfc_parse_file()
../../gcc/fortran/parse.c:6122
0x71c602 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/68567] ICE on using wrong defined arrays (different cases/messages)

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

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

--- Comment #5 from Gerhard Steinmetz  
---
> We must be using drastically different compilers.
No, I've simply forgotten to include a subcatalog with testfiles zz*.
Sorry for my blotchiness. The patch looks good and works.

[Bug fortran/77350] New: ICE in truthvalue_conversion, at fortran/convert.c:65

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

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

Bug ID: 77350
   Summary: ICE in truthvalue_conversion, at fortran/convert.c:65
   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: ---

For versions down to at least 4.8, with invalid code :


$ cat z1.f90
function f() result(g)
contains
   logical function g()
   end
end


$ gfortran-7-20160821 z1.f90
z1.f90:4:0:

end

internal compiler error: in truthvalue_conversion, at fortran/convert.c:65
0x711933 truthvalue_conversion
../../gcc/fortran/convert.c:65
0x711933 convert(tree_node*, tree_node*)
../../gcc/fortran/convert.c:98
0x742ac7 gfc_generate_return()
../../gcc/fortran/trans-decl.c:5893
0x74e7fb gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6288
0x6da360 translate_all_program_units
../../gcc/fortran/parse.c:5916
0x6da360 gfc_parse_file()
../../gcc/fortran/parse.c:6122
0x71c602 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198