[Bug target/77770] [5/6/7 Regression] Internal compiler error on source which compiles with earlier versions.

[zoltan at bendor dot com.au]

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

--- Comment #4 from Zoltan Kocsi  ---
Tested several gcc versions. 
Up to and including 4.8.5 everything seems to be OK, but 4.9.0 or above all
throw the error.

[Bug c++/77791] New: ICE on invalid C++11 code with redefined function parameter: tree check: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in cp_parser_lambda_declarator_opt

[su at cs dot ucdavis.edu]

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

Bug ID: 77791
   Summary: ICE on invalid C++11 code with redefined function
parameter: tree check: expected tree that contains
‘decl minimal’ structure, have ‘error_mark’ in
cp_parser_lambda_declarator_opt, at cp/parser.c:1011
   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 is regression from 6.2.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 20160928 (experimental) [trunk revision 240585] (GCC) 
$ 
$ g++-trunk -std=c++11 -c small.cpp
small.cpp:1:29: error: redefinition of ‘int i’
 auto a = [] (int i, int i = 0) {};
 ^
small.cpp:1:18: note: ‘int i’ previously declared here
 auto a = [] (int i, int i = 0) {};
  ^
small.cpp:1:29: internal compiler error: tree check: expected tree that
contains ‘decl minimal’ structure, have ‘error_mark’ in
cp_parser_lambda_declarator_opt, at cp/parser.c:10119
 auto a = [] (int i, int i = 0) {};
 ^
0x1090e44 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc-source-trunk/gcc/tree.c:9914
0x7b4612 contains_struct_check
../../gcc-source-trunk/gcc/tree.h:3145
0x7b4612 cp_parser_lambda_declarator_opt
../../gcc-source-trunk/gcc/cp/parser.c:10119
0x792a82 cp_parser_lambda_expression
../../gcc-source-trunk/gcc/cp/parser.c:9779
0x792a82 cp_parser_primary_expression
../../gcc-source-trunk/gcc/cp/parser.c:4966
0x79dbe6 cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6724
0x79c01c cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8019
0x7a5e57 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:8696
0x7a6455 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8798
0x7a6d40 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9086
0x7a717a cp_parser_constant_expression
../../gcc-source-trunk/gcc/cp/parser.c:9354
0x7a7904 cp_parser_initializer_clause
../../gcc-source-trunk/gcc/cp/parser.c:21048
0x7a929b cp_parser_initializer
../../gcc-source-trunk/gcc/cp/parser.c:20986
0x7bb3fc cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18851
0x7bbb39 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12567
0x7bbe71 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12435
0x7c3dd0 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12332
0x7c2914 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12211
0x7c2c58 cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4356
0x7c2c58 c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:37805
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.
$ 


-


auto a = [] (int i, int i = 0) {};

[Bug c++/77790] New: ICE on valid C++14 code when compiling with "-std=c++11": in push_access_scope, at cp/pt.c:227

[su at cs dot ucdavis.edu]

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

Bug ID: 77790
   Summary: ICE on valid C++14 code when compiling with
"-std=c++11": in push_access_scope, at cp/pt.c:227
   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 appears to be a regression from 4.8.x, and affects 4.9.x and later. 


$ 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 20160928 (experimental) [trunk revision 240585] (GCC)
$
$ g++-trunk -c -std=c++14 small.cpp
$
$ g++-trunk -c -std=c++11 small.cpp
small.cpp:3:42: error: ‘f’ function uses ‘auto’ type specifier without trailing
return type
   template < typename T > static auto f () { return 0; }
  ^
small.cpp:3:42: note: deduced return type only available with -std=c++14 or
-std=gnu++14
small.cpp:7:26: internal compiler error: in push_access_scope, at cp/pt.c:227
 auto a = A < int > {}.g ();
  ^
0x6c2c37 push_access_scope
../../gcc-source-trunk/gcc/cp/pt.c:226
0x71e343 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc-source-trunk/gcc/cp/pt.c:18004
0x67bfbb add_template_candidate_real
../../gcc-source-trunk/gcc/cp/call.c:3120
0x67ccec add_template_candidate
../../gcc-source-trunk/gcc/cp/call.c:3198
0x67ccec add_candidates
../../gcc-source-trunk/gcc/cp/call.c:5400
0x67d759 build_new_method_call_1
../../gcc-source-trunk/gcc/cp/call.c:8515
0x67d759 build_new_method_call(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, tree_node*, int, tree_node**, int)
../../gcc-source-trunk/gcc/cp/call.c:8714
0x79e483 cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6908
0x79c01c cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8019
0x7a5e57 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:8696
0x7a6455 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8798
0x7a6d40 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9086
0x7a717a cp_parser_constant_expression
../../gcc-source-trunk/gcc/cp/parser.c:9354
0x7a7904 cp_parser_initializer_clause
../../gcc-source-trunk/gcc/cp/parser.c:21048
0x7a929b cp_parser_initializer
../../gcc-source-trunk/gcc/cp/parser.c:20986
0x7bb3fc cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18851
0x7bbb39 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12567
0x7bbe71 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12435
0x7c3dd0 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12332
0x7c2914 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12211
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.
$


-


template < typename S > struct A
{ 
  template < typename T > static auto f () { return 0; }
  template < class U = decltype (f < S > ()) > int g () { return 0; }
};

auto a = A < int > {}.g ();

[Bug c/77789] New: MinGW option ./configure does not make

[Byron.Watkins at comcast dot net]

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

Bug ID: 77789
   Summary: MinGW option ./configure does not make
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Byron.Watkins at comcast dot net
  Target Milestone: ---

Created attachment 39722
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39722=edit
The ./configure and make logs

Hi,

I am trying to build gsl libraries for use with MinGW so that I can develop
wxWidgets applications in Code::Blocks that contain gsl's math.  I have
downloaded some beta versions; however, I did not keep track of which are beta
and which are release.

I have read that by using --build=x86_64-amd-mingw32 on ./configure's
command line I can obtain libraries suitable for my goal.  But this option (and
i686-amd-mingw32) fail to build.  I have tried several variations of --build,
--host, and --target containing these types and all fail seemingly the same.  I
have attached the configure.log and the stdout stream from make (make.log).

The gcc that I am using under MicroSoft's bash shell for Windows 10
education is the latest version, but as I said it might be the beta or the
release version.  I will also suggest that the gsl maintainers investigate
this; I expect that your group and their group might work together on this one.

Thank you,

Byron

[Bug bootstrap/77788] New: profiledbootstrap failures on powerpc64le

[msebor at gcc dot gnu.org]

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

Bug ID: 77788
   Summary: profiledbootstrap failures on powerpc64le
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Today's top of GCC trunk configured with
-enable-languages=all,c,c++,fortran,go,lto,objc,obj-c++ --no-recursion fails in
the feedback stage with (at least) the following errors:

/src/gcc/trunk/gcc/expmed.h: In function ‘void init_expmed()’:
/src/gcc/trunk/gcc/expmed.h:622:77: error: array subscript is above array
bounds [-Werror=array-bounds]
   return _target_expmed->x_mul_highpart_cost[speed][mode - MIN_MODE_INT];
   ~~^
/src/gcc/trunk/gcc/expmed.h:622:77: error: array subscript is above array
bounds [-Werror=array-bounds]
   return _target_expmed->x_mul_highpart_cost[speed][mode - MIN_MODE_INT];
   ~~^
...
/src/gcc/trunk/gcc/gimple-ssa-strength-reduction.c: In member function ‘virtual
edge_def* find_candidates_dom_walker::before_dom_children(basic_block)’:
/src/gcc/trunk/gcc/gimple-ssa-strength-reduction.c:1583:28: error: ‘c’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
   add_cand_for_stmt (gs, c);
^
/src/gcc/trunk/gcc/gimple-ssa-strength-reduction.c:1532:26: note: ‘c’ was
declared here
   slsr_cand_t base_cand, c, c2;
  ^
cc1plus: all warnings being treated as errors
make[3]: *** [expmed.o] Error 1
make[3]: *** Waiting for unfinished jobs
cc1plus: all warnings being treated as errors
make[3]: *** [gimple-ssa-strength-reduction.o] Error 1
rm cpp.pod fsf-funding.pod grmic.pod gcov.pod gc-analyze.pod gpl.pod gfdl.pod
gccgo.pod gfortran.pod gcc.pod gcj-dbtool.pod jcf-dump.pod gcj.pod
jv-convert.pod gcov-tool.pod gij.pod
make[3]: Leaving directory `/build/gcc-trunk/gcc'
make[2]: *** [all-stagefeedback-gcc] Error 2
make[2]: Leaving directory `/build/gcc-trunk'
make[1]: *** [stagefeedback-bubble] Error 2
make[1]: Leaving directory `/build/gcc-trunk'
make: *** [profiledbootstrap] Error 2
make: Leaving directory `/build/gcc-trunk'

[Bug fortran/71730] [5/6/7 Regression] ICE when character length specification uses an undefined variable

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Sep 29 00:18:44 2016
New Revision: 240608

URL: https://gcc.gnu.org/viewcvs?rev=240608=gcc=rev
Log:
2016-09-28  Steven G. Kargl  

backport from trunk
PR fortran/71730
* gfortran.dg/pr71730.f90: New test.
* gfortran.dg/bounds_check_strlen_2.f90: Fix invalid code.
* gfortran.dg/array_constructor_27.f03: Update dg-error message.
* gfortran.dg/array_constructor_26.f03: Ditto.

PR fortran/77612
* gfortran.dg/pr77612.f90: New test.

2016-09-28  Steven G. Kargl  

backport from trunk
PR fortran/71730
* decl.c (char_len_param_value): Check return value of
gfc_reduce_init_expr().

PR fortran/77612
* decl.c (char_len_param_value): Check parent namespace for 
seen_implicit_none.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr71730.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr77612.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/decl.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/array_constructor_26.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/array_constructor_27.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/bounds_check_strlen_2.f90

[Bug fortran/77612] [5/6 Regression] ICE on invalid character len in contained procedure

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Sep 29 00:18:44 2016
New Revision: 240608

URL: https://gcc.gnu.org/viewcvs?rev=240608=gcc=rev
Log:
2016-09-28  Steven G. Kargl  

backport from trunk
PR fortran/71730
* gfortran.dg/pr71730.f90: New test.
* gfortran.dg/bounds_check_strlen_2.f90: Fix invalid code.
* gfortran.dg/array_constructor_27.f03: Update dg-error message.
* gfortran.dg/array_constructor_26.f03: Ditto.

PR fortran/77612
* gfortran.dg/pr77612.f90: New test.

2016-09-28  Steven G. Kargl  

backport from trunk
PR fortran/71730
* decl.c (char_len_param_value): Check return value of
gfc_reduce_init_expr().

PR fortran/77612
* decl.c (char_len_param_value): Check parent namespace for 
seen_implicit_none.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr71730.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr77612.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/decl.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/array_constructor_26.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/array_constructor_27.f03
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/bounds_check_strlen_2.f90

[Bug c++/77787] segfault in mangle.c

[petschy at gmail dot com]

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

--- Comment #1 from petschy at gmail dot com ---
That last function in json.hpp was gutted:

//template
int foo(int div_)
{
ASSERT(div_ == 0);
return 0;
}

Removed the assertions from all the template functions, as this moved the crash
location upward, then section type conflicts started to appear. Commented out
the assertions from back to front until the point where the code compiled. Lots
of assertions remained that didn't cause trouble.

Now I have an assert() in a plain member function of a plain class. Then lots
of assertions in inline functions and static functions of fully specialized
class templates. At the end I have the foo fn as above.

If the template line is commented out, 'section type conflict' is the result,
no crash. If I comment out the assert in foo() or in the plain member, it
compiles. If both assertions are active, and I uncomment the //template line,
it crashes. Unfortunately, the test still can't reproduce the behaviour, though
I put in there a class, and a class template specialization, too.

It also turned out that function templates ignore the section attribute on the
static variable inside, gotcha. That's why I didn't get conflicts in the first
version of the test. Moreover, the 'inline' on the Helper::Get() function is
ignored, so the section of the static variable inside will not be flagged as
"aG" always, but as "a" or as "aG" depending on the inline status of the
outside function using the assert(). That's why I did get conflicts at all.

[Bug fortran/77694] ICE in optimize_binop_array_assignment, at fortran/frontend-passes.c:1080

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Sep 28 23:38:13 2016
New Revision: 240604

URL: https://gcc.gnu.org/viewcvs?rev=240604=gcc=rev
Log:
2016-09-28  Steven G. Kargl  

backport from trunk
PR fortran/77694
* frontend-passes.c (optimize_binop_array_assignment): Check pointer
for NULL.

2016-09-28  Steven G. Kargl  

backport from trunk
PR fortran/77694
* gfortran.dg/pr77694.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr77694.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/frontend-passes.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/70754] [5/6/7 Regression] ICE during predictive commoning

[pthaugen at gcc dot gnu.org]

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

--- Comment #5 from Pat Haugen  ---
(In reply to Pat Haugen from comment #4)
> This also occurs on powerpc64/powerpc64le.
> 

I should note that the failure on powerpc64* doesn't start until GCC 7 rev
236043, where a TARGET_SCHED_REASSOCIATION_WIDTH function was added, which I
guess makes sense since predictive commoning appears to do some reassociation.
The failure also requires -mcpu=power8 or -mcpu=power9 since those are the only
2 values currently where the target hook will return a value > 1.

[Bug c++/61414] enum class bitfield size-checking failure

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-28
 Ever confirmed|0   |1

--- Comment #7 from Jonathan Wakely  ---
PR 51242 discusses the same issue, and PR 51242 comment 27 notes that Clang
only warns when a value that isn't known to fit is assigned to the bitfield,
which seems more useful.

At the very least there should be a -Wxxx switch controlling this option so it
can be disabled.

[Bug c++/61414] enum class bitfield size-checking failure

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Xidorn Quan from comment #5)
> It seems G++ always throw that warning for enum class as bitfield, even when
> the enum class is actually empty:
> > enum class K {};
> > struct S {
> >   K v : 5;
> > };
> 
> G++ would give:
> > test.cpp:3:9: warning: 'S::v' is too small to hold all values of 'enum 
> > class K'
> >K v : 5;

Yes, read comment 2.

[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields

[redi at gcc dot gnu.org]

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

--- Comment #29 from Jonathan Wakely  ---
(In reply to Sasha B from comment #28)
> You can disregard whether the underlying type is fixed or not. So, GCC
> should not give a warning unless a bitfield containing Foo really is too
> small to hold a given value of Foo, warning on the assignment makes sense.

I agree that we could warn on assignment instead. If the values assigned to the
bitfield are constant and known to fit, there's no need to warn. See PR 61414
for the same warning. I don't know if we need to keep both bugs open.

[Bug target/77756] __get_cpuid() returns wrong values for level 7 (extended features)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #5 from H.J. Lu  ---
For level >= 7, ECX may have other input values.  It is incorrect to
assume that ECX only takes 0 or 1.  We should get another macro for
level >= 7 with input for ECX:

static __inline int
__get_cpuid (unsigned int __level,
 unsigned int *__eax, unsigned int *__ebx,
 unsigned int *__ecx, unsigned int *__edx)
{
  unsigned int __ext = __level & 0x8000;

  if (__get_cpuid_max (__ext, 0) < __level)
return 0;

  if (__level >= 7)
return 0;

  __cpuid (__level, *__eax, *__ebx, *__ecx, *__edx);
  return 1;
}

static __inline int
__get_cpuid_count (unsigned int __level, unsigned int count,
 unsigned int *__eax, unsigned int *__ebx,
 unsigned int *__ecx, unsigned int *__edx)
{
  unsigned int __ext = __level & 0x8000;

  if (__get_cpuid_max (__ext, 0) < __level)
return 0;

  __cpuid_count (__level, count, *__eax, *__ebx, *__ecx, *__edx);
  return 1;
}

[Bug rtl-optimization/71709] [6 Regression] powerpc64le: argument to strcpy() optimised out

[wschmidt at gcc dot gnu.org]

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

--- Comment #13 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Sep 28 21:36:59 2016
New Revision: 240599

URL: https://gcc.gnu.org/viewcvs?rev=240599=gcc=rev
Log:
2016-09-28  Bill Schmidt  
Alan Modra  

Backport from mainline
2016-07-01  Alan Modra  

PR rtl-optimization/71709
* ira-lives.c (find_call_crossed_cheap_reg): Exit loop on arg reg
being set, not referenced.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/ira-lives.c

[Bug rtl-optimization/71709] [6 Regression] powerpc64le: argument to strcpy() optimised out

[wschmidt at gcc dot gnu.org]

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

--- Comment #12 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Sep 28 21:35:37 2016
New Revision: 240598

URL: https://gcc.gnu.org/viewcvs?rev=240598=gcc=rev
Log:
2016-09-28  Bill Schmidt  
Alan Modra  

Backport from mainline
2016-07-01  Alan Modra  

PR rtl-optimization/71709
* ira-lives.c (find_call_crossed_cheap_reg): Exit loop on arg reg
being set, not referenced.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/ira-lives.c

[Bug target/77756] __get_cpuid() returns wrong values for level 7 (extended features)

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Sep 28 21:29:47 2016
New Revision: 240597

URL: https://gcc.gnu.org/viewcvs?rev=240597=gcc=rev
Log:
PR target/77756
* config/i386/cpuid.h (__get_cpuid): Handle CPUID level >= 7.

testsuite/ChangeLog:

PR target/77756
* gcc.target/i386/pr77756.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr77756.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/cpuid.h
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/77683] [7 regression] ICE on %lf directive in format_floating in gimple-ssa-sprintf.c:1163

[gerald at pfeifer dot com]

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

Gerald Pfeifer  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #5 from Gerald Pfeifer  ---
Also verified with the testcase from Bug 77740: building Wine.

[Bug target/77756] __get_cpuid() returns wrong values for level 7 (extended features)

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Yale Zhang from comment #2)

> But does level 13 really exist? I don't see any documentation for it.

Yes, apparently. It was added to driver-i386.c by Intel people, where:

  if (max_level >= 13)
{
  __cpuid_count (13, 1, eax, ebx, ecx, edx);

  has_xsaveopt = eax & bit_XSAVEOPT;
  has_xsavec = eax & bit_XSAVEC;
  has_xsaves = eax & bit_XSAVES;
}

> Also, any idea why the AVX2 auto detection used for function multiversioning
> was working earlier, which used __get_cpuid()? Was it just by chance?

This is handled via a different code path in libgcc/config/i386/cpunfo.c,
get_available_features, where __cpuid_count is used to get advanced features at
level 7.

[Bug middle-end/77784] duplicate warning for snprintf when n > object size

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The preexisting warning is not that misleading, because even if there is not
any buffer overflow, the program is still terminated whenever the user provided
buffer size is bigger than the __builtin_object_size provided size, without
actually trying to print anything into the buffer.  If you want to suggest
different wording for the *snprintf* case, it could be changed, but I believe
it is the right spot for the warning - after all the GIMPLE optimizations,
regardless of what warning options are enabled or not.

[Bug c++/77787] New: segfault in mangle.c

[petschy at gmail dot com]

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

Bug ID: 77787
   Summary: segfault in mangle.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petschy at gmail dot com
  Target Milestone: ---

Background: while trying to put cold data to a dedicated section I managed to
crash the compiler. The idea was that rarely used strings, eg src file names
and expressions of assertions will be separated from normal data, resulting in
better dcache utilization:

void prn(const char*);
void foo() {
__attribute__((section(".cold_rodata")))
static const char x[] = "foo";
prn(x);
}
inline void bar() {
__attribute__((section(".cold_rodata")))
static const char x[] = "bar";
prn(x);
} 
int main() {
foo();
bar();
}

Let's pretend that the x[] arrays were put there by ASSERT() macros.
Unfortunately, this won;t compile:
$ g++ -c 20160928-section_type_conflict.cpp 
20160928-section_type_conflict.cpp:9:20: error: x causes a section type
conflict with x
  static const char x[] = "bar";
^
20160928-section_type_conflict.cpp:4:20: note: ‘x’ was declared here
  static const char x[] = "foo";
^
I know, I know: I shouldn't be using __attribute__ on non-globals.
Unfortunately, there is no hot/cold attribute for data, only for code. For my
specific case, a 'cold' data attribute would partly solve the problem, but
that's probably another discussion.

The explanation can be found here, along with proposed solutions:
http://stackoverflow.com/questions/35091862/inline-static-data-causes-a-section-type-conflict

I thought that rather than messing with __asm__, I go full ret^H^H^Hcrafty:
instead of the static x[], I define a local struct with a static inline fn,
which has the static x[] in the desired section. This way x[] is always in an
inline function, so the conflict goes away. The result: gcc segfaults. 5.4.1,
6.2.1 and 7.0.0 all do it. I built a -g -O0 from 7.0, this is the output:

common/src/dbgmac.h:264:23: internal compiler error: in operator[], at
vec.h:732
DBG_STRING_DEF(expr_str, #expr); \
   ^
common/src/platform.h:97:29: note: in definition of macro ‘CONCAT_’
 #define CONCAT_(a_, b_)  a_ ## b_
  ^~
common/src/platform.h:99:33: note: in expansion of macro ‘CONCAT2’
 #define CONCAT3(a_, b_, c_)  CONCAT2(CONCAT2(a_, b_), c_)
  ^~
common/src/platform.h:98:29: note: in expansion of macro ‘CONCAT_’
 #define CONCAT2(a_, b_)  CONCAT_(a_, b_)
  ^~
common/src/platform.h:99:44: note: in expansion of macro ‘CONCAT2’
 #define CONCAT3(a_, b_, c_)  CONCAT2(CONCAT2(a_, b_), c_)
  ^~
common/src/dbgmac.h:73:34: note: in expansion of macro ‘CONCAT3’
 #define UNIQ_VAR_NAME(n_)CONCAT3(n_, _, __LINE__)
  ^~
common/src/dbgmac.h:86:22: note: in expansion of macro ‘UNIQ_VAR_NAME’
static const char UNIQ_VAR_NAME(var_) [] = val_; \
  ^
common/src/dbgmac.h:264:4: note: in expansion of macro ‘DBG_STRING_DEF’
DBG_STRING_DEF(expr_str, #expr); \
^~
common/src/dbgmac.h:208:35: note: in expansion of macro ‘HARD_ASSERT’
 #define ASSERT(expr, args...) HARD_ASSERT(expr, ## args);
   ^~~
common/src/json.hpp:1493:2: note: in expansion of macro ‘ASSERT’
  ASSERT(div_ != 0);
  ^~
0x7c190a vec<tree_node*, va_gc, vl_embed>::operator[](unsigned int)
../../gcc/vec.h:732
0xa2f260 local_class_index
../../gcc/cp/mangle.c:1845
0xa2f9ea discriminator_for_local_entity
../../gcc/cp/mangle.c:1881
0xa2fd6f write_local_name
../../gcc/cp/mangle.c:1972
0xa299c0 write_name
../../gcc/cp/mangle.c:917
0xa291f0 write_encoding
../../gcc/cp/mangle.c:779
0xa2fb5d write_local_name
../../gcc/cp/mangle.c:1941
0xa299c0 write_name
../../gcc/cp/mangle.c:917
0xa291f0 write_encoding
../../gcc/cp/mangle.c:779
0xa28c89 write_mangled_name
../../gcc/cp/mangle.c:744
0xa39b28 mangle_decl_string
../../gcc/cp/mangle.c:3709
0xa39b6e get_mangled_id
../../gcc/cp/mangle.c:3731
0xa3a032 mangle_decl(tree_node*)
../../gcc/cp/mangle.c:3801
0x145f393 decl_assembler_name(tree_node*)
../../gcc/tree.c:669
0xbd4c72 symbol_table::insert_to_assembler_name_hash(symtab_node*, bool)
../../gcc/symtab.c:171
0xbd4fef symbol_table::symtab_initialize_asm_name_hash()
../../gcc/symtab.c:263
0xbd71dc symtab_node::get_for_asmname(tree_node const*)
../../gcc/symtab.c:930
0xbf366d handle_alias_pairs
../../gcc/

[Bug c++/77711] Add fix-it hints for missing parentheses in member function call

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Yet another variation on missing argument list for a member function call:

call.cc: In function ‘int main()’:
call.cc:20:14: error: cannot convert ‘A::foo’ from type ‘int (A::)()’ to type
‘int (A::*)()’
   auto x = a.foo;
  ^~~

Another completely different error, that's also pretty unhelpful. This should
probably use invalid_nonstatic_memfn_p too.

Clang gives exactly the same error in this case as for the bar( a.foo ) case,
which is much better than two different unclear messages.

[Bug c++/77711] Add fix-it hints for missing parentheses in member function call

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
For comparison, clang gives a much clearer error:

77711.cc:11:9: error: reference to non-static member function must be called;
did you mean to call it with no arguments?
  x.f
  ~~^
 ()

It says *why* it's invalid (it must be called), and suggests adding an empty
argument list (including when the function has parameters but they have default
arguments).

I have a fix for PR7 so we can print the same range info and fix-it as
clang does.

[Bug middle-end/77721] -Wformat-length not uses arg range for converted vars

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Wed Sep 28 19:51:08 2016
New Revision: 240595

URL: https://gcc.gnu.org/viewcvs?rev=240595=gcc=rev
Log:
PR middle-end/77721 - -Wformat-length not uses arg range for converted vars

gcc/testsuite/ChangeLog:
PR middle-end/77721
* gcc.dg/tree-ssa/builtin-sprintf-warn-6.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-6.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/77786] internal compiler error: in tsubst_copy, at cp/pt.c:13040

[matthias.thul at gmail dot com]

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

--- Comment #1 from Matthias Thul  ---
Created attachment 39721
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39721=edit
preprocessed file

[Bug c++/77786] New: internal compiler error: in tsubst_copy, at cp/pt.c:13040

[matthias.thul at gmail dot com]

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

Bug ID: 77786
   Summary: internal compiler error: in tsubst_copy, at
cp/pt.c:13040
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthias.thul at gmail dot com
  Target Milestone: ---

Created attachment 39720
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39720=edit
compiler output

The below code fails with the the internal compiler error "in tsubst_copy, at
cp/pt.c:13040" in 5.4.1. The code compiles successfully with 4.9.4 and 6.2.0 as
well as Clang 3.8.0.

When removing the template parameter from foo, the internal compiler error
changes to "Segmentation fault".

When checking whether this was a duplicate of 70343, I changed the capture of
the lambda bar from [&] to [] and the internal compiler error still occurs
(though the code is not valid any longer).

== code ==

#include 

template
void foo(std::vector a) {
auto const a_size = a.size();

auto bar = [&](auto y) -> void {
int a_size_2 = a_size;
};

double x = 0.0;
bar(x);
}

int main() {
std::vector a(1);
foo<1>(a);
}

== output of gcc -v ==

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

== complete command line that triggers the bug ==

g++ -std=c++14 main.cpp -o main

[Bug fortran/77707] [5/6/7 Regression] formatted direct access: nextrec off by one

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
Fixed on trunk. Will backport in a few days.

[Bug fortran/77707] [5/6/7 Regression] formatted direct access: nextrec off by one

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
Author: jvdelisle
Date: Wed Sep 28 19:43:03 2016
New Revision: 240593

URL: https://gcc.gnu.org/viewcvs?rev=240593=gcc=rev
Log:
2016-09-28  Jerry DeLisle  

PR libgfortran/77707
* gfortran.dg/inquire_17.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/inquire_17.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/77707] [5/6/7 Regression] formatted direct access: nextrec off by one

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
Author: jvdelisle
Date: Wed Sep 28 19:38:03 2016
New Revision: 240592

URL: https://gcc.gnu.org/viewcvs?rev=240592=gcc=rev
Log:
2016-09-28  Jerry DeLisle  

PR libgfortran/77707
io/transfer.c (next_record): Flush before calculating next_record.
Correctly calculate.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c

[Bug c++/77467] Segmentation fault with switch statement in constexpr function

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Sep 28 19:21:47 2016
New Revision: 240591

URL: https://gcc.gnu.org/viewcvs?rev=240591=gcc=rev
Log:
PR c++/77467
* constexpr.c (enum constexpr_switch_state): New.
(struct constexpr_ctx): Add css_state field.
(label_matches): Add CTX and STMT arguments, remove I and
DEFAULT_LABEL.  For CASE_LABEL_EXPR assert ctx->css_state != NULL,
handle default labels according to css_state.
(cxx_eval_statement_list): Remove statement skipping, label_matches
and default_label handling code.
(cxx_eval_loop_expr): Exit after first iteration even if
switches (jump_target).
(cxx_eval_switch_expr): Set up css_state field in ctx, if default
label has been seen in the body, but no cases matched, evaluate
the body second time.
(cxx_eval_constant_expression): Handle stmt skipping and label_matches
here.  Handle PREDICT_EXPR.  For MODIFY_EXPR or INIT_EXPR, assert
statement is not skipped.  For COND_EXPR during skipping, don't
evaluate condition, just the then block and if still skipping at the
end also the else block.
(cxx_eval_outermost_constant_expr): Adjust constexpr_ctx initializer.
(is_sub_constant_expr): Likewise.

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

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

[Bug target/77756] __get_cpuid() returns wrong values for level 7 (extended features)

[yzhang1985 at gmail dot com]

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

--- Comment #2 from Yale Zhang  ---
(In reply to Uroš Bizjak from comment #1)
> Created attachment 39711 [details]
> Patch that fixes __get_cpuid
> 
> Can you please check if the attached patch fixes your problem?

Great, your patch works. Thanks for taking care of it so quickly.

I see you made it flexible by setting ECX to 0 only for certain levels, without
increasing machine code size since __get_cpuid() is inlined and most of the
unused cases will get thrown away as dead code.

But does level 13 really exist? I don't see any documentation for it.

Also, any idea why the AVX2 auto detection used for function multiversioning
was working earlier, which used __get_cpuid()? Was it just by chance?

[Bug c++/68703] __attribute__((vector_size(N))) template member confusion

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

--- Comment #8 from David Edelsohn  ---
The new vector32.C and vector32a.C testcases fail on AIX:

src/gcc/testsuite/g++.dg/ext/vector32.C: In function 'int main()':
src/gcc/testsuite/g++.dg/ext/vector32.C:18:1: internal compiler error: in get,
at cgraph.h:395

gcc_checking_assert (TREE_CODE (decl) == FUNCTION_DECL
 || (TREE_CODE (decl) == VAR_DECL
 && (TREE_STATIC (decl) || DECL_EXTERNAL (decl)
 || in_lto_p)));

[Bug fortran/69080] No automatic deallocation of allocatable function results

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #15 from Jerry DeLisle  ---
(In reply to Mueller from comment #14)
> I'd really like to know why this report has been closed although there may
> be a problem with deallocation. I think the rephrasing of Mikael pinpointed
> what I meant.

This is a tricky question to 'see'. Whether or not a temporary is used as
Mikael states, seems to be an implementation dependent artifact.

dummy_create_allocatable() is allocating an object. dummy_do_nothing takes it
as intent(in) so it is not modified or changed in anyway.

dummy_trigger does not do anything with it and as written can not even access
it.

So I think the example program itself is or ought to be invalid. Then from my
simple minded view you can choose to ignore the situation, generate a
diagnostic like "unused function result", or as Mikael suggested, maybe try to
clean it up.

The least effort approach is do nothing with this, especially since doing
something gains nothing from a program that does nothing.  It gets to be a
policy or philosophical question.

One could also make a point that the underlying operating system software takes
care of it as well.  Regardless, the code is sort of intriguing leaving things
sort of hanging there. If it is indicative of some other underlying issue yet
to be uncovered of course we should fix it. comp.lang.fortran might be a better
place for the broader questions of what 'should' it do.

[Bug rtl-optimization/71709] [6 Regression] powerpc64le: argument to strcpy() optimised out

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
Working on the backports.  Stay tuned.

[Bug middle-end/77784] duplicate warning for snprintf when n > object size

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-28
Summary|duplicate warning for   |duplicate warning for
   |snprintf for n > object |snprintf when n > object
   |size|size
 Ever confirmed|0   |1
   Severity|normal  |minor

[Bug bootstrap/77753] [7 Regression] broken profiledbootstrap due to -Werror=format-length in varasm.c:1573

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
The warning should be gone with r240581 but my profiledbootstrap on powerpc64
fails in the feedback stage with the error below.  I'll try again without ada
and resolve this in the meantime as fixed.  If another -Wformat-length error
shows up please open a new bug for it.

+===GNAT BUG DETECTED==+
| 7.0.0 20160928 (experimental) (powerpc64le-unknown-linux-gnu) GCC error: |
| in check_die, at dwarf2out.c:5897|
| Error detected around /src/gcc/trunk/gcc/ada/atree.adb:2538:8|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

/src/gcc/trunk/gcc/ada/system.ads
/src/gcc/trunk/gcc/ada/exp_unst.adb
/src/gcc/trunk/gcc/ada/exp_unst.ads
/src/gcc/trunk/gcc/ada/table.ads
/src/gcc/trunk/gcc/ada/types.ads
/src/gcc/trunk/gcc/ada/unchconv.ads
/src/gcc/trunk/gcc/ada/unchdeal.ads
/src/gcc/trunk/gcc/ada/atree.ads
/src/gcc/trunk/gcc/ada/alloc.ads
/src/gcc/trunk/gcc/ada/sinfo.ads
/src/gcc/trunk/gcc/ada/namet.ads
/src/gcc/trunk/gcc/ada/hostparm.ads
/src/gcc/trunk/gcc/ada/uintp.ads
/src/gcc/trunk/gcc/ada/urealp.ads
/src/gcc/trunk/gcc/ada/einfo.ads
ada/snames.ads
/src/gcc/trunk/gcc/ada/debug.ads
/src/gcc/trunk/gcc/ada/elists.ads
/src/gcc/trunk/gcc/ada/lib.ads
/src/gcc/trunk/gcc/ada/nlists.ads
ada/nmake.ads
/src/gcc/trunk/gcc/ada/opt.ads
/src/gcc/trunk/gcc/ada/s-string.ads
/src/gcc/trunk/gcc/ada/ada.ads
/src/gcc/trunk/gcc/ada/a-uncdea.ads
/src/gcc/trunk/gcc/ada/s-wchcon.ads
/src/gcc/trunk/gcc/ada/output.ads
/src/gcc/trunk/gcc/ada/s-os_lib.ads
/src/gcc/trunk/gcc/ada/rtsfind.ads
/src/gcc/trunk/gcc/ada/sem.ads
/src/gcc/trunk/gcc/ada/sem_ch8.ads
/src/gcc/trunk/gcc/ada/sem_mech.ads
/src/gcc/trunk/gcc/ada/sem_res.ads
/src/gcc/trunk/gcc/ada/sem_util.ads
/src/gcc/trunk/gcc/ada/exp_tss.ads
/src/gcc/trunk/gcc/ada/sinput.ads
/src/gcc/trunk/gcc/ada/casing.ads
/src/gcc/trunk/gcc/ada/tbuild.ads
/src/gcc/trunk/gcc/ada/s-exctab.ads
/src/gcc/trunk/gcc/ada/s-stalib.ads
/src/gcc/trunk/gcc/ada/a-unccon.ads
/src/gcc/trunk/gcc/ada/s-unstyp.ads
/src/gcc/trunk/gcc/ada/s-conca2.ads
/src/gcc/trunk/gcc/ada/s-assert.ads
/src/gcc/trunk/gcc/ada/s-secsta.ads
/src/gcc/trunk/gcc/ada/s-stoele.ads
/src/gcc/trunk/gcc/ada/a-except.ads
/src/gcc/trunk/gcc/ada/s-parame.ads
/src/gcc/trunk/gcc/ada/s-traent.ads
/src/gcc/trunk/gcc/ada/s-soflin.ads
/src/gcc/trunk/gcc/ada/s-stache.ads
/src/gcc/trunk/gcc/ada/table.adb
/src/gcc/trunk/gcc/ada/tree_io.ads
/src/gcc/trunk/gcc/ada/s-memory.ads
/src/gcc/trunk/gcc/ada/atree.adb
/src/gcc/trunk/gcc/ada/aspects.ads
/src/gcc/trunk/gcc/ada/gnat.ads
/src/gcc/trunk/gcc/ada/g-hesorg.ads
/src/gcc/trunk/gcc/ada/s-imenne.ads


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:406
make[3]: *** [ada/exp_unst.o] Error 1
make[3]: *** Waiting for unfinished jobs

[Bug libgcc/77519] [5 Regression] complex multiply excess precision handling inverted

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #7 from Joseph S. Myers  ---
Also fixed for GCC 5.5.

[Bug libgcc/77519] [5 Regression] complex multiply excess precision handling inverted

[jsm28 at gcc dot gnu.org]

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

--- Comment #6 from Joseph S. Myers  ---
Author: jsm28
Date: Wed Sep 28 17:37:45 2016
New Revision: 240586

URL: https://gcc.gnu.org/viewcvs?rev=240586=gcc=rev
Log:
Correct libgcc complex multiply excess precision handling (PR libgcc/77519).

libgcc complex multiply is meant to eliminate excess
precision from certain internal values by forcing them to memory in
exactly those cases where the type has excess precision.  But in
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01894.html I
accidentally inverted the logic so that values get forced to memory in
exactly the cases where it's not needed.  (This is a pessimization in
the no-excess-precision case, in principle could lead to bad results
depending on code generation in the excess-precision case.  Note: I do
not have a test demonstrating bad results.)

Bootstrapped with no regressions on x86_64-pc-linux-gnu.  Code size
went down on x86_64 as expected; old sizes:

   textdata bss dec hex filename
887   0   0 887 377 _muldc3.o
810   0   0 810 32a _mulsc3.o
   2032   0   02032 7f0 _multc3.o
983   0   0 983 3d7 _mulxc3.o

New sizes:

847   0   0 847 34f _muldc3.o
770   0   0 770 302 _mulsc3.o
   2032   0   02032 7f0 _multc3.o
951   0   0 951 3b7 _mulxc3.o

Backport from mainline
2016-09-07  Joseph Myers  

PR libgcc/77519
* libgcc2.c (NOTRUNC): Invert settings.

Modified:
branches/gcc-5-branch/libgcc/ChangeLog
branches/gcc-5-branch/libgcc/libgcc2.c

[Bug c/77762] Incorrect destination buffer length in -Wformat-length warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Fixed by r240584.

I've raised bug 77784 for the duplicate warning.

[Bug fortran/77782] New: ICE in gfc_get_union_type, at fortran/trans-types.c:2387

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

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

Bug ID: 77782
   Summary: ICE in gfc_get_union_type, at
fortran/trans-types.c:2387
   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: ---

Together with option -fdec :


$ cat z1.f90
program p
  structure /s1/
union
  map
integer(4) a
  end map
  map
real(4) b
  end map
end union
  end structure
  structure /s2/
union
  map
integer(2) x, y
integer(4) z
  end map
end union
  end structure
  record /s1/ r1
  r1.a = 0
end


$ gfortran-7-20160925 -fdec z1.f90
z1.f90:1:0:

 program p

internal compiler error: in gfc_get_union_type, at fortran/trans-types.c:2387
0x7b79a6 gfc_get_union_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2387
0x7b7d88 gfc_copy_dt_decls_ifequal(gfc_symbol*, gfc_symbol*, bool)
../../gcc/fortran/trans-types.c:2325
0x7b7445 gfc_get_derived_type(gfc_symbol*, bool)
../../gcc/fortran/trans-types.c:2730
0x7b7b8c gfc_typenode_for_spec(gfc_typespec*, bool)
../../gcc/fortran/trans-types.c:1110
0x7b5bb3 gfc_sym_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2167
0x74eaa4 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1640
0x7526e7 generate_local_decl
../../gcc/fortran/trans-decl.c:5313
0x70df2b do_traverse_symtree
../../gcc/fortran/symbol.c:3963
0x753542 generate_local_vars
../../gcc/fortran/trans-decl.c:5513
0x753542 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6192
0x6de170 translate_all_program_units
../../gcc/fortran/parse.c:5940
0x6de170 gfc_parse_file()
../../gcc/fortran/parse.c:6146
0x720d82 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/77785] New: ICE in gfc_get_caf_token_offset, at fortran/trans-expr.c:1990

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

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

Bug ID: 77785
   Summary: ICE in gfc_get_caf_token_offset, at
fortran/trans-expr.c:1990
   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: ---

Since recently :

$ cat z1.f90
subroutine s(x)
   integer, allocatable :: x(:)[:]
   allocate (x(1)[*])
end


$ gfortran-7-20160925 -fcoarray=single -c z1.f90
$ gfortran-7-20160925 -fcoarray=lib -c z1.f90
z1.f90:3:0:

allocate (x(1)[*])

internal compiler error: in gfc_get_caf_token_offset, at
fortran/trans-expr.c:1990
0x765017 gfc_get_caf_token_offset(gfc_se*, tree_node**, tree_node**,
tree_node*, tree_node*, gfc_expr*)
../../gcc/fortran/trans-expr.c:1989
0x7373d5 gfc_array_allocate(gfc_se*, gfc_expr*, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, gfc_expr*, tree_node*, bool)
../../gcc/fortran/trans-array.c:5546
0x7ac165 gfc_trans_allocate(gfc_code*)
../../gcc/fortran/trans-stmt.c:5799
0x723ff7 trans_code
../../gcc/fortran/trans.c:1870
0x753838 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6257
0x6de170 translate_all_program_units
../../gcc/fortran/parse.c:5940
0x6de170 gfc_parse_file()
../../gcc/fortran/parse.c:6146
0x720d82 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/69080] No automatic deallocation of allocatable function results

[sv.muel...@tu-braunschweig.de]

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

--- Comment #14 from Mueller  ---
I'd really like to know why this report has been closed although there may be a
problem with deallocation. I think the rephrasing of Mikael pinpointed what I
meant.

[Bug middle-end/77784] New: duplicate warning for snprintf for n > object size

[msebor at gcc dot gnu.org]

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

Bug ID: 77784
   Summary: duplicate warning for snprintf for n > object size
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As mentioned in bug 77762#2, with both the -Wformat-length option used and
_FORTIFY_SOURCE defined (and with optimization enabled), GCC now prints two
warnings for calls to functions like snprintf (which normally calls
__builtin___snprintf_chk).  Only one warning should be printed.

$ cat zzz.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wall -Wformat-length=1 zzz.c
char d [2];

void f (const char *s)
{
  __builtin___snprintf_chk (d, 4, 0, 2, s);
}
zzz.c: In function ‘f’:
zzz.c:5:3: warning: specified size 4 exceeds the size 2 of the destination
object [-Wformat-length=]
   __builtin___snprintf_chk (d, 4, 0, 2, s);
   ^~~~
zzz.c:5:3: warning: call to __builtin___snprintf_chk will always overflow
destination buffer


As also pointed out in bug 77762 and as the following program shows, the latter
warning is misleading because a buffer overflow need not actually take place
and the call may be valid.  This is just a minor detail when the default
implementation of the __snprintf_chk function is used that calls abort in this
case, but printing a more accurate message becomes important when an alternate
implementation is used that does not abort (as is sometimes done in operating
system kernels, for example).

$ cat zzz.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -Wall
-Wformat -Wextra -Wpedantic -Wformat-length=1 zzz.c && ./a.out 
typedef __SIZE_TYPE__ size_t;

char d [2];

int main (void)
{
  char s[] = "x";
  __builtin___snprintf_chk (d, 4, 0, 2, s);
}

int __snprintf_chk (char *s, size_t maxlen, int flag, size_t os,
const char *fmt, ...)
{
  __builtin_printf ("%s(%p, %zu, %i, %zu, \"%s\"...)\n",
__func__, s, maxlen, flag, os, fmt);
  return __builtin_puts (fmt);
}

zzz.c: In function ‘main’:
zzz.c:8:3: warning: specified size 4 exceeds the size 2 of the destination
object [-Wformat-length=]
   __builtin___snprintf_chk (d, 4, 0, 2, s);
   ^~~~
zzz.c:8:3: warning: call to __builtin___snprintf_chk will always overflow
destination buffer
__snprintf_chk(0x601049, 4, 0, 2, "x"...)
x

[Bug fortran/77783] ICE in gfc_compare_union_types, at fortran/interface.c:545

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

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

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

Some variations :


$ cat z2.f90
subroutine f(x)
  structure /s1/
union
  integer i
end union
  end structure
  record /s1/ x
  x.i = 0
end
subroutine g
  structure /s1/
union
end union
  end structure
  record /s1/ x
  call f(x)
end


$ cat z3.f90
subroutine f(x)
  structure /s1/
union
end union
  end structure
  record /s1/ x
  x.i = 0
end
subroutine g
  structure /s1/
union
end union
  end structure
  record /s1/ x
  call f(x)
end


$ gfortran-7-20160925 -fdec -c z3.f90
z3.f90:7:5:

   x.i = 0
 1
Error: 'i' at (1) is not a member of the 'S1' structure
f951: internal compiler error: Segmentation fault
0xc28c9f crash_signal
../../gcc/toplev.c:337
0x694783 gfc_compare_union_types(gfc_symbol*, gfc_symbol*)
../../gcc/fortran/interface.c:544
0x69469a compare_components
../../gcc/fortran/interface.c:502
#...

[Bug fortran/77783] New: ICE in gfc_compare_union_types, at fortran/interface.c:545

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

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

Bug ID: 77783
   Summary: ICE in gfc_compare_union_types, at
fortran/interface.c:545
   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: ---

Needs option -fdec, affects version 6 and 7 :


$ cat z1.f90
subroutine f(x)
  structure /s1/
union
  map
integer i
  end map
end union
  end structure
  record /s1/ x
  x.i = 0
end
subroutine g
  structure /s1/
union
end union
  end structure
  record /s1/ x
  call f(x)
end


$ gfortran-7-20160925 -fdec -c z1.f90
f951: internal compiler error: Segmentation fault
0xc28c9f crash_signal
../../gcc/toplev.c:337
0x694787 gfc_compare_union_types(gfc_symbol*, gfc_symbol*)
../../gcc/fortran/interface.c:545
0x69469a compare_components
../../gcc/fortran/interface.c:502
0x694918 gfc_compare_derived_types(gfc_symbol*, gfc_symbol*)
../../gcc/fortran/interface.c:633
0x713474 gfc_type_compatible(gfc_typespec*, gfc_typespec*)
../../gcc/fortran/symbol.c:4906
0x6945a8 gfc_compare_types(gfc_typespec*, gfc_typespec*)
../../gcc/fortran/interface.c:693
0x696b8b compare_parameter
../../gcc/fortran/interface.c:2205
0x69792b compare_actual_formal
../../gcc/fortran/interface.c:2876
0x6998cd gfc_procedure_use(gfc_symbol*, gfc_actual_arglist**, locus*)
../../gcc/fortran/interface.c:3611
0x6f382d resolve_global_procedure
../../gcc/fortran/resolve.c:2477
0x6f3ba7 resolve_call
../../gcc/fortran/resolve.c:3455
0x6f0f60 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10758
0x6f3382 resolve_codes
../../gcc/fortran/resolve.c:15724
0x6f347e gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15759
0x6ddf9a resolve_all_program_units
../../gcc/fortran/parse.c:5879
0x6ddf9a gfc_parse_file()
../../gcc/fortran/parse.c:6131
0x720d82 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug c++/77777] Use rich location to mark correct expression for "invalid use of non-static member function"

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
FWIW the location information is available in the frame above:

Breakpoint 6, invalid_nonstatic_memfn_p (loc=205792, expr=, complain=3)
at ../../src/gcc/cp/typeck.c:1834
1834expr);
(gdb) list
1829  if (complain & tf_error)
1830{
1831  if (DECL_P (expr))
1832{
1833  error_at (loc, "invalid use of non-static member function
%qD",
1834expr);
1835  inform (DECL_SOURCE_LOCATION (expr), "declared here");
1836}

within EXPR_LOCATION (arg):

(gdb) up
#7  0x007b1a65 in resolve_args (args=0x71a14460 = {...},
complain=3) at ../../src/gcc/cp/call.c:4012
4012  else if (invalid_nonstatic_memfn_p (input_location, arg,
complain))

(gdb) call inform (arg->exp.locus, "")
/tmp/pr7.cc: In function ‘int main()’:
/tmp/pr7.cc:11:9: note: 
   x.f
   ~~^

so this location could be passed to invalid_nonstatic_memfn_p and a fix-it hint
added.

[Bug c++/77777] Use rich location to mark correct expression for "invalid use of non-static member function"

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Or maybe even better, make the caret point to the member function, but cover
the entire expression:

  x.foo
  ~~^~~


(Please ignore the "did you mean...?" part shown in the initial comment, that
was produced by a locally patched gcc, but is not relevant to this bug).

[Bug c++/77777] Use rich location to mark correct expression for "invalid use of non-static member function"

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to David Malcolm from comment #1)
> (In reply to Jonathan Wakely from comment #0)
> > There are lots of cases where we should use rich locations, but here's one
> Do you mean a fix-it hint?

I don't think so, but maybe I do :-)

What I mean is we should display something like:

c.cc:12:4: error: invalid use of non-static member function ‘int X::f()’
  x.f
  ^~~

with a range that covers the relevant expression, not just a range of length
zero pointing to the wrong place.

[Bug middle-end/69976] Zero the local stack on function exit

[daniel.gutson at intel dot com]

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

--- Comment #11 from Daniel Gutson  ---
Any update on this?

[Bug c/77762] Incorrect destination buffer length in -Wformat-length warning

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Wed Sep 28 16:24:35 2016
New Revision: 240584

URL: https://gcc.gnu.org/viewcvs?rev=240584=gcc=rev
Log:
PR c/77762 - Incorrect destination buffer length in -Wformat-length warning

gcc/testsuite/ChangeLog:

PR c/77762
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test_vsnprintf_chk_s):
Call __builtin___vsnprintf_chk, not __builtin___snprintf_chk.
(test_sprintf_p_const): Adjust line numbers to avoid failures
introduced in r240503.

gcc/ChangeLog:

PR c/77762
* gimple-ssa-sprintf.c (pass_sprintf_length::handle_gimple_call):
Fix typos.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c

[Bug middle-end/77683] [7 regression] ICE on %lf directive in format_floating in gimple-ssa-sprintf.c:1163

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed by r240583.

[Bug libgcc/77519] [5 Regression] complex multiply excess precision handling inverted

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

Summary|[5/6 Regression] complex|[5 Regression] complex
   |multiply excess precision   |multiply excess precision
   |handling inverted   |handling inverted

--- Comment #5 from Joseph S. Myers  ---
Now fixed for GCC 6.3 as well.

[Bug middle-end/77683] [7 regression] ICE on %lf directive in format_floating in gimple-ssa-sprintf.c:1163

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Wed Sep 28 16:13:12 2016
New Revision: 240583

URL: https://gcc.gnu.org/viewcvs?rev=240583=gcc=rev
Log:
PR middle-end/77683 - ICE on %lf directive in format_floating in

gcc/testsuite/ChangeLog:

PR middle-end/77683
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Add test cases.

gcc/ChangeLog:

PR middle-end/77683
* gimple-ssa-sprintf.c (format_integer): Fail gracefully when
length modifier is not expected.
(format_floating): Ignore l length modifier and fail gracefuly
when it isn't one of the other expected ones.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c

[Bug c++/77781] [DR 1315] Some valid cases of partial specialization not accepted

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||jason at redhat dot com
Summary|[DR 1315]   |[DR 1315] Some valid cases
   ||of partial specialization
   ||not accepted

--- Comment #1 from Ville Voutilainen  ---
gcc rejects the following, clang accepts it:

template struct S; template struct
S{};

both gcc and clang reject this:

template struct S; template struct S{};

gcc accepts the following, clang rejects it:

template struct S; template struct S{};

[Bug libgcc/77519] [5/6 Regression] complex multiply excess precision handling inverted

[jsm28 at gcc dot gnu.org]

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

--- Comment #4 from Joseph S. Myers  ---
Author: jsm28
Date: Wed Sep 28 16:11:44 2016
New Revision: 240582

URL: https://gcc.gnu.org/viewcvs?rev=240582=gcc=rev
Log:
Correct libgcc complex multiply excess precision handling (PR libgcc/77519).

libgcc complex multiply is meant to eliminate excess
precision from certain internal values by forcing them to memory in
exactly those cases where the type has excess precision.  But in
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01894.html I
accidentally inverted the logic so that values get forced to memory in
exactly the cases where it's not needed.  (This is a pessimization in
the no-excess-precision case, in principle could lead to bad results
depending on code generation in the excess-precision case.  Note: I do
not have a test demonstrating bad results.)

Bootstrapped with no regressions on x86_64-pc-linux-gnu.  Code size
went down on x86_64 as expected; old sizes:

   textdata bss dec hex filename
887   0   0 887 377 _muldc3.o
810   0   0 810 32a _mulsc3.o
   2032   0   02032 7f0 _multc3.o
983   0   0 983 3d7 _mulxc3.o

New sizes:

847   0   0 847 34f _muldc3.o
770   0   0 770 302 _mulsc3.o
   2032   0   02032 7f0 _multc3.o
951   0   0 951 3b7 _mulxc3.o

Backport from mainline
2016-09-07  Joseph Myers  

PR libgcc/77519
* libgcc2.c (NOTRUNC): Invert settings.

Modified:
branches/gcc-6-branch/libgcc/ChangeLog
branches/gcc-6-branch/libgcc/libgcc2.c

[Bug c++/77781] New: [DR 1315]

[ville.voutilainen at gmail dot com]

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

Bug ID: 77781
   Summary: [DR 1315]
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
  Target Milestone: ---

[Bug bootstrap/77753] [7 Regression] broken profiledbootstrap due to -Werror=format-length in varasm.c:1573

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Wed Sep 28 16:02:06 2016
New Revision: 240581

URL: https://gcc.gnu.org/viewcvs?rev=240581=gcc=rev
Log:
PR bootstrap/77753 - [7 Regression] broken profiledbootstrap due to

gcc/ChangeLog:

PR bootstrap/77753
* varasm.c (assemble_addr_to_section): Increase local buffer size.


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

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[iains at gcc dot gnu.org]

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

--- Comment #27 from Iain Sandoe  ---
(In reply to Jonathan Ross from comment #26)
> (In reply to Iain Sandoe from comment #23)
> > (In reply to Francois-Xavier Coudert from comment #22)
> > > When a fix is designed, could you please backport it to the 6 branch (so 
> > > it
> > > can make it into 6.3 for example)? It is also affected.
> > 
> > sure, "all open branches" would be the intent.
> 
> I can confirm that 5.3 is also affected.

OK. so the status is
  - we're checking for other test-cases that need amendment.
  - IMO this is a sufficiently invasive change that it needs testing on some
bigger chunks of code
  - likewise across a representative set of the *darwin* patch
   * I will check ppc-d9 when I'm back in the office; with both ld-85.2.1 and
my back ported ld64-253.9
   * I think Dominique will check x86_64-d10.

feel free to volunteer to do some similar testing of builds of larger codes
(e.g. python or LLVM etc).

* I'll do back-ports for 6.x and 5.x early next week, traveling until then.

[Bug go/77780] New: Go front-end ignores NO_DOLLAR_IN_LABEL

[dje at gcc dot gnu.org]

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

Bug ID: 77780
   Summary: Go front-end ignores NO_DOLLAR_IN_LABEL
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: dje at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---
Target: powerpc-ibm-aix*

The Go front-end uses '$' as a joiner and creates symbols such as
internal_race.Acquire$descriptor. This is invalid on some targets. The Go
front-end ignores the NO_DOLLAR_IN_LABEL macro and generates identifiers
containing dollar signs.

[Bug go/77780] Go front-end ignores NO_DOLLAR_IN_LABEL

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-28
 CC||tony.reix at atos dot net
 Ever confirmed|0   |1

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

[Bug middle-end/77718] [7 Regression] expand_builtin_memcmp swaps args

[acsawdey at gcc dot gnu.org]

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

--- Comment #6 from acsawdey at gcc dot gnu.org ---
I can confirm that Bernd's patch fixes the issue, bootstraps on powerpc64le,
and does not cause any new regression test failures in "make check".

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[jonathan.ross at imc dot com]

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

Jonathan Ross  changed:

   What|Removed |Added

 CC||jonathan.ross at imc dot com

--- Comment #26 from Jonathan Ross  ---
(In reply to Iain Sandoe from comment #23)
> (In reply to Francois-Xavier Coudert from comment #22)
> > When a fix is designed, could you please backport it to the 6 branch (so it
> > can make it into 6.3 for example)? It is also affected.
> 
> sure, "all open branches" would be the intent.

I can confirm that 5.3 is also affected.

[Bug fortran/77385] "Unclassifiable statement" from gfortran

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.7 up to trunk (7.0), Polymorphic arrays are not yet supported
on 4.6.

Note that the following variant

MODULE a
   IMPLICIT NONE
   TYPE :: b
  CONTAINS
 PROCEDURE :: e
   END TYPE b
   TYPE :: c
  CLASS(b), POINTER :: i(:) => NULL()
   END TYPE c
   CONTAINS
  FUNCTION e(this ) RESULT (s)
 CLASS(b) :: this
 TYPE(b) :: s
 s = b()
  END FUNCTION e
END MODULE a
MODULE m
   USE a
   IMPLICIT NONE
   TYPE d
  CLASS(b), DIMENSION(:), POINTER :: f => NULL()
   END TYPE d
   CONTAINS
  FUNCTION g() RESULT (h)
 TYPE(d) :: j
 TYPE(c) :: h
 allocate(j%f(1))
 print *, shape(j%f)
 ASSOCIATE( k => j%f )
 END ASSOCIATE
  END FUNCTION g
END MODULE m
   use m
   type(c) :: res
   res = g()
end

gives

  ASSOCIATE( k => j%f )

internal compiler error: Segmentation fault: 11

and

MODULE a
   IMPLICIT NONE
   TYPE :: b
  CONTAINS
 PROCEDURE :: e
   END TYPE b
   TYPE :: c
  CLASS(b), POINTER :: i(:) => NULL()
   END TYPE c
   CONTAINS
  FUNCTION e(this ) RESULT (s)
 CLASS(b) :: this
 TYPE(b) :: s
 s = b()
  END FUNCTION e
END MODULE a
MODULE m
   USE a
   IMPLICIT NONE
   TYPE d
  CLASS(b), DIMENSION(:), POINTER :: f => NULL()
   END TYPE d
   CONTAINS
  FUNCTION g() RESULT (h)
 TYPE(d) :: j
 TYPE(c) :: h
ALLOCATE(h%i(1))
allocate(j%f(1))
SELECT TYPE ( l => h%i )
TYPE IS ( b )
   l(1) = j*f(1)%e()
END SELECT
  END FUNCTION g
END MODULE m

gives

l(1) = j*f(1)%e()
 1
Error: Symbol 'f' at (1) has no IMPLICIT type

[Bug middle-end/77779] New: unnecessary trap checks for pointer subtraction with -ftrapv

[jfc at mit dot edu]

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

Bug ID: 9
   Summary: unnecessary trap checks for pointer subtraction with
-ftrapv
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jfc at mit dot edu
  Target Milestone: ---

Consider this code:

long diff(long *a, long *b) { return (a - b) + (a - b); }

Compiled with gcc -O2 -ftrapv on x86-64 the resulting code is

diff:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
call__subvdi3
sarq$3, %rax
movq%rax, %rdi
movq%rax, %rsi
call__addvdi3
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size   diff, .-diff


There are two problems here -- not bugs, but suboptimal code.

1. Pointer subtraction of sizes larger than 2 bytes should not generate a
trapping subtract.  In the usual case where pointers and ptrdiff_t are the same
size, the result will fit in a ptrdiff_t.

2. The addition can not overflow.  In general, x/A + y/B with A and B both
greater than 2 will not overflow.  (This might not be worth fixing, but I think
the previous problem is.)

I contrived this C example after seeing the first problem in C++.  The real
code is a call to

   std::vector::size()

with type T 4 bytes or larger.  size() can't overflow, but g++ inserts a call
to __subvdi3 anyway.  On Linux+ELF this results in a dynamic linker operation.

This is in 5.2 and 5.4.1 20160926.  I have not checked gcc 6+.

[Bug bootstrap/77768] [7 Regression] LTO/PGO -O3 bootstrap broken: tree-vrp.c:11053:0: internal compiler error: Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||chengniansun at gmail dot com

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

[Bug tree-optimization/77778] ICE at -Os and above on x86_64-linux-gnu in both 32-bit and 64-bit modes (Segmentation fault, visit_reference_op_store, extract_and_process_scc_for_name)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

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

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

[Bug tree-optimization/77778] New: ICE at -Os and above on x86_64-linux-gnu in both 32-bit and 64-bit modes (Segmentation fault, visit_reference_op_store, extract_and_process_scc_for_name)

[chengniansun at gmail dot com]

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

Bug ID: 8
   Summary: ICE at -Os and above on x86_64-linux-gnu in both
32-bit and 64-bit modes (Segmentation fault,
visit_reference_op_store,
extract_and_process_scc_for_name)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/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 20160928 (experimental) [trunk revision 240565] (GCC) 
$ 
$ gcc-trunk -O3 small.c 
small.c: In function ‘main’:
small.c:5:5: warning: assignment discards ‘const’ qualifier from pointer target
type [-Wdiscarded-qualifiers]
   c = 
 ^
small.c:4:5: internal compiler error: Segmentation fault
 int main() {
 ^~~~
0xbd143f crash_signal
../../gcc-source-trunk/gcc/toplev.c:337
0xda517d visit_reference_op_store
../../gcc-source-trunk/gcc/tree-ssa-sccvn.c:3613
0xda517d visit_use
../../gcc-source-trunk/gcc/tree-ssa-sccvn.c:3858
0xda675c process_scc
../../gcc-source-trunk/gcc/tree-ssa-sccvn.c:4111
0xda675c extract_and_process_scc_for_name
../../gcc-source-trunk/gcc/tree-ssa-sccvn.c:4198
0xda675c DFS
../../gcc-source-trunk/gcc/tree-ssa-sccvn.c:4250
0xda6e55 sccvn_dom_walker::before_dom_children(basic_block_def*)
../../gcc-source-trunk/gcc/tree-ssa-sccvn.c:4716
0x128aed7 dom_walker::walk(basic_block_def*)
../../gcc-source-trunk/gcc/domwalk.c:265
0xda8532 run_scc_vn(vn_lookup_kind)
../../gcc-source-trunk/gcc/tree-ssa-sccvn.c:4827
0xd7d345 execute
../../gcc-source-trunk/gcc/tree-ssa-pre.c:5021
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 
$ cat small.c
static const int a;
int b;
int *c, *d;
int main() {
  c = 
  c == d ?: __builtin_abort(); 
  for (; b; b++ >= (*d = a))
;
  return 0;
}

$

[Bug c++/77777] Use rich location to mark correct expression for "invalid use of non-static member function"

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
(In reply to Jonathan Wakely from comment #0)
> There are lots of cases where we should use rich locations, but here's one
Do you mean a fix-it hint?

[Bug middle-end/55152] MAX_EXPR(a,-a) is really ABS_EXPR(a)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Testing a patch.

[Bug bootstrap/77774] Build failure on netbsd-7.0.1/arm6hf of gcc 6.2.0, 7-20160925

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Earnshaw  ---
OK.  Resolving this issue as invalid.

[Bug bootstrap/77774] Build failure on netbsd-7.0.1/arm6hf of gcc 6.2.0, 7-20160925

[coypu at sdf dot org]

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

--- Comment #6 from coypu  ---
It is a local change bug! thanks.
I'll let you know if the build completes.

[Bug c++/77775] [7 Regression] since r238559 Kdevelop gets miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |7.0

[Bug tree-optimization/72712] [7 Regression] Tenfold compile time regression

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Now that we have another (early) pass things should be even worse.  Current
trunk at -O2 with -fno-checking improved though (I guess by means of a cost
model or so):

 phase opt and generate  :  69.39 (99%) usr   0.98 (98%) sys  72.38 (99%) wall 
289872 kB (97%) ggc
 tree SSA incremental:  16.94 (24%) usr   0.00 ( 0%) sys  17.36 (24%) wall 
 13582 kB ( 5%) ggc
 backwards jump threading:   5.04 ( 7%) usr   0.00 ( 0%) sys   5.20 ( 7%) wall 
115843 kB (39%) ggc
 PRE :  18.37 (26%) usr   0.25 (25%) sys  19.13 (26%) wall 
   270 kB ( 0%) ggc

[Bug bootstrap/77774] Build failure on netbsd-7.0.1/arm6hf of gcc 6.2.0, 7-20160925

[rearnsha at gcc dot gnu.org]

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

--- Comment #5 from Richard Earnshaw  ---
(In reply to coypu from comment #4)
> indeed in EXTRAOBJS I only have netbsd.o
> I'll try to use arm*) instead, and will report back.

netbsd.o (and netbsd.c) don't appear to exist or be referenced anywhere in the
gcc-6 sources.  I suspect this is a bug in some local changes you have.

[Bug fortran/77764] ICE in is_anonymous_component, at fortran/interface.c:450

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug testsuite/77710] FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c

[thopre01 at gcc dot gnu.org]

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

--- Comment #4 from Thomas Preud'homme  ---
(In reply to Martin Sebor from comment #3)
> With GCC 7.0.0 20160927 configured with --build=x86_64-pc-linux-gnu
> --host=x86_64-pc-linux-gnu --target=arm-none-eabi I get the expected output
> (below).  I see failures in other tests in the results reported for
> arm-unknown-linux-gnueabihf below but none in the builtin-sprintf-warn-4.c
> test:
> https://gcc.gnu.org/ml/gcc-testresults/2016-09/msg02201.html
> 
> Can you please check again?
> 
> /src/gcc/trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:10:24:
> warning: writing a terminating nul past the end of the destination
> [-Wformat-length=]
>sprintf (dst + 7, "%-s", "1");
>   ~~^~
> /src/gcc/trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:10:3:
> note: format output 2 bytes into a destination of size 1
>sprintf (dst + 7, "%-s", "1");
>^
> /src/gcc/trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:22:22:
> warning: '%-s' directive writing 4 bytes into a region of size 1
> [-Wformat-length=]
>sprintf (dst + 7, "%-s", "abcd");
>   ^~~   ~~
> /src/gcc/trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:22:3:
> note: format output 5 bytes into a destination of size 1
>sprintf (dst + 7, "%-s", "abcd");
>^~~~

At r240573 I still get:

% build/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=build/gcc/xgcc
Target: arm-none-eabi
Configured with: src/configure --prefix=install --target=arm-none-eabi
--enable-languages=c,c++ --with-cpu=cortex-m0 --with-mode=thumb --with-newlib
--with-headers=src/newlib/libc/include --enable-newlib-register-fini
--disable-newlib-supplied-syscalls --disable-multilib --with-libexpat
--with-system-zlib --disable-gdbtk --enable-plugins --disable-libgomp
--disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libstdcxx-pch --disable-nls --disable-rda --disable-sid --disable-tui
--disable-utils --disable-werror --disable-fixed-point 
Thread model: single
gcc version 7.0.0 20160928 (experimental) (GCC)

% grep -A 2 FAIL build/gcc/testsuite/gcc/gcc.logFAIL:
gcc.dg/tree-ssa/builtin-sprintf-warn-4.c (test for excess errors)
Excess errors:
src/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:10:24: warning:
writing a terminating nul past the end of the destination
[-Wformat-length=]src/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-4.c:22:22:
warning: '%-s' directive writing 4 bytes into a region of size 1
[-Wformat-length=]

I'll try to investigate myself since it is difficult to reproduce it for you.

Best regards,

Thomas

[Bug middle-end/77407] Optimize integer i / abs (i) into the sign of i

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug c++/77711] Add fix-it hints for missing parentheses in member function call

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Ideally we'd look to see if a.foo() would return a type that would make the
call bar( a.foo() ) valid, and not suggest it otherwise (there's no point
suggesting it if a.foo() returns void, for example).

And we could also look to see if bar( ::foo ) would be valid, and suggest
that if so.

Sometimes either would be valid, e.g. template void bar(T).

[Bug c++/77733] Add fixit hint suggesting to use std::move

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
(In reply to Jonathan Wakely from comment #1)
> As well as a fixit hint suggesting to use std::move it might be useful to
> display the "" text in colour so it stands out.

Good idea.

[Bug c++/77733] Add fixit hint suggesting to use std::move

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #3 from David Malcolm  ---
(In reply to Jonathan Wakely from comment #2)
> The location for the "cannot bind rvalue reference" error is not a rich
> location, so I couldn't figure out how to add a proper fix-it.

It's trivial to get a rich_location from a location_t:

   rich_location richloc (loc);
   // maybe add some fixits to richloc here...
   error_at_rich_loc (, "cannot bind..." etc etc

An issue here is that "loc" isn't a good enough location_t: in
convert_like_real it comes from:

  location_t loc = EXPR_LOC_OR_LOC (expr, input_location);

In the example, expr is a VAR_DECL and uses of decls don't have locations, so
it uses input_location for "loc", putting it on the closing paren of the call:

/tmp/test.cc: In function ‘int main()’:
/tmp/test.cc:14:10: error: cannot bind rvalue reference of type ‘X&&’ to lvalue
of type ‘X’
   y.foo(x);
  ^

If loc had a meaningful location for x, you could use something like,:
  richloc.add_fixit_insert_before (loc, "std::move (");
  richloc.add_fixit_insert_after (loc, ")");

The "not every expression has a location_t" is PR 43486 - maybe this should be
a dependency of that bug? (unless there's some way to ensure that all callers
of convert_like_real preserve the location information from the cp_expr in the
C++ parser).

(I've been experimenting with ideas for fixing PR 43486, but it's unlikely to
make it for gcc 7).

> This just adds "did you mean std::move(x)?" to the end:
> 
> --- a/gcc/cp/call.c
> +++ b/gcc/cp/call.c
> @@ -6804,7 +6804,8 @@ convert_like_real (conversion *convs, tree expr, tree
> fn, int argnum,
> if (TYPE_REF_IS_RVALUE (ref_type)
> && lvalue_p (expr))
>   error_at (loc, "cannot bind rvalue reference of type %qT to "
> -"lvalue of type %qT", totype, extype);
> +"lvalue of type %qT; did you mean
> %?",
> +totype, extype, expr);
> else if (!TYPE_REF_IS_RVALUE (ref_type) && !lvalue_p (expr)
>  && !CP_TYPE_CONST_NON_VOLATILE_P (TREE_TYPE (ref_type)))
>   error_at (loc, "cannot bind non-const lvalue reference of "

FWIW, I'm not sure we want to add uses of %E to the compiler; my recollection
is that it can lead to poor output for the more complicated cases.

> Of course sometimes std::move is not the right fix, and it should be
> std::forward(x) instead. Maybe it would be possible to detect
> whether the expression is a function parameter declared as a forwarding
> reference, but that's probably beyond my ken.
> Also, if the lvalue is cv-qualified this still suggests std::move(x) even
> when that wouldn't work:
> 
> move2.cc:13:9: error: cannot bind rvalue reference of type ‘X&&’ to lvalue
> of type ‘const X’; did you mean ‘std::move(x)’? 
> 
> 
> There's room for improvement.

(nods)

[Bug c++/77711] Add fix-it hints for missing parentheses in member function call

[redi at gcc dot gnu.org]

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

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

--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -1823,6 +1823,7 @@ invalid_nonstatic_memfn_p (location_t loc, tree expr,
tsubst_flags_t complain)
   /* Don't enforce this in MS mode.  */
   if (flag_ms_extensions)
 return false;
+  tree origexpr = expr;
   if (is_overloaded_fn (expr) && !really_overloaded_fn (expr))
 expr = get_first_fn (expr);
   if (DECL_NONSTATIC_MEMBER_FUNCTION_P (expr))
@@ -1831,8 +1832,18 @@ invalid_nonstatic_memfn_p (location_t loc, tree expr,
tsubst_flags_t complain)
{
  if (DECL_P (expr))
{
- error_at (loc, "invalid use of non-static member function %qD",
-   expr);
+  tree args = TREE_CHAIN (TYPE_ARG_TYPES (TREE_TYPE (expr)));
+  if (list_length (args) == 1)
+  {
+gcc_rich_location richloc (loc);
+richloc.add_fixit_insert_before(loc, "()");
+error_at_rich_loc (, "invalid use of non-static "
+   "member function %qD; did you mean "
+   "%<%E()%>?", expr, origexpr);
+  }
+  else
+error_at (loc, "invalid use of non-static member function
%qD",
+  expr);
  inform (DECL_SOURCE_LOCATION (expr), "declared here");
}
  else

the first example gives:

call.cc: In function ‘int main()’:
call.cc:19:14: error: invalid use of non-static member function ‘int A::foo()’;
did you mean ‘a.A::foo()’?
   bar( a.foo );
  ^
  ()
call.cc:2:7: note: declared here
   int foo();
   ^~~

Which is OK, but not great.

It should say a.foo() not a.A::foo().

The fixit is correct, but it would be better if we had a rich_location covering
a.foo rather than a non-rich one pointing to the next token (PR7). In this
specific example inserting () at the suggested location would match the GNU
coding standards (with a space before the parentheses) but nobody writes C++
like that, and it's not correct if there's any more whitespace before the next
token.

[Bug bootstrap/77774] Build failure on netbsd-7.0.1/arm6hf of gcc 6.2.0, 7-20160925

[coypu at sdf dot org]

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

--- Comment #4 from coypu  ---
indeed in EXTRAOBJS I only have netbsd.o
I'll try to use arm*) instead, and will report back.

[Bug c++/77777] New: Use rich location to mark correct expression for "invalid use of non-static member function"

[redi at gcc dot gnu.org]

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

Bug ID: 7
   Summary: Use rich location to mark correct expression for
"invalid use of non-static member function"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

There are lots of cases where we should use rich locations, but here's one to
start with:

struct X {
  int f();
};

void g(int);

int main()
{
  X x;
  g(
  x.f
   );
}

The error is:

c.cc: In function ‘int main()’:
c.cc:12:4: error: invalid use of non-static member function ‘int X::f()’; did
you mean ‘x.X::f()’?
);
^
()
c.cc:2:7: note: declared here
   int f();
   ^

The location should point to x.f not the next token.

[Bug tree-optimization/77399] Poor code generation for vector casts and loads

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
I have a patch handling same-size element conversions mixed with permutations.
Thus in addition to the testcase in the description also

typedef int v4si __attribute__((vector_size(16)));
typedef float v4sf __attribute__((vector_size(16)));
v4sf vec_cast(v4si f)
{
  return (v4sf){f[1], f[1], f[2], f[3]};
}

expanding to

vec_cast:
.LFB0:
.cfi_startproc
pshufd  $229, %xmm0, %xmm0
cvtdq2ps%xmm0, %xmm0
ret

Note this doesn't handle int <-> double conversions where on GIMPLE we'd have
VEC_UNPACK_* VEC_PACK_* but I'm not sure those represent a good middle-end
representation for optimizers (we should create/pattern match those late
and only if the target supports the ops).

vector construction from loads is another story (I think SLP vectorization
should handle this and IIRC there is already a bug for this - CONSTRUCTORS
supposed to be handled the same as grouped stores).

[Bug testsuite/77411] object-size-9.c -fpic -m32 failure

[edlinger at gcc dot gnu.org]

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

--- Comment #5 from Bernd Edlinger  ---
Author: edlinger
Date: Wed Sep 28 12:48:16 2016
New Revision: 240575

URL: https://gcc.gnu.org/viewcvs?rev=240575=gcc=rev
Log:
backport from mainline
2016-09-23  Bernd Edlinger  
Tom de Vries  

PR testsuite/77411
* c-c++-common/ubsan/object-size-9.c: Call __builtin_exit in C++.

Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/c-c++-common/ubsan/object-size-9.c

[Bug libstdc++/77686] [6/7 Regression] wrong code on arm-linux-gnueabi and arm-linux-gnueabihf

[redi at gcc dot gnu.org]

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

--- Comment #23 from Jonathan Wakely  ---
Author: redi
Date: Wed Sep 28 12:47:24 2016
New Revision: 240574

URL: https://gcc.gnu.org/viewcvs?rev=240574=gcc=rev
Log:
libstdc++/77686 use may_alias for std::function storage

PR libstdc++/77686
* include/std/functional (_Any_data): Add may_alias attribute.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/std/functional

[Bug libstdc++/77776] New: C++17 std::hypot implementation is poor

[redi at gcc dot gnu.org]

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

Bug ID: 6
   Summary: C++17 std::hypot implementation is poor
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Make it better.

https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02075.html
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02120.html

[Bug c++/77775] [7 Regression] since r238559 Kdevelop gets miscompiled

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
g++ -O0 -fPIC -c moc_area.ii -S -o bad_

[Bug c++/77775] [7 Regression] since r238559 Kdevelop gets miscompiled

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
Created attachment 39719
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39719=edit
bad assembly

[Bug c++/77775] [7 Regression] since r238559 Kdevelop gets miscompiled

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Created attachment 39718
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39718=edit
good assembly

[Bug c++/77775] New: [7 Regression] since r238559 Kdevelop gets miscompiled

[trippels at gcc dot gnu.org]

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

Bug ID: 5
   Summary: [7 Regression] since r238559 Kdevelop gets miscompiled
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

Created attachment 39717
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39717=edit
unreduced testcase

Starting with r238559:

commit 5157eff877f9491e7c0fc9231ac2b686983eaa41
Author: jason 
Date:   Thu Jul 21 06:05:33 2016 +

PR c++/71121 - -Waddress, constexpr, and PMFs.

* cp-gimplify.c (cp_fully_fold): First call maybe_constant_value.

Kdevelop gets miscompiled and crashes on startup.

I've narrowed the issue to a single file.
See the attachments.

x4 sublime # diff -u good_ bad_
--- good_   2016-09-28 12:37:52.508094930 +0200
+++ bad_2016-09-28 14:24:11.674668521 +0200
@@ -1016,7 +1016,7 @@
pushq   %r13
pushq   %r12
pushq   %rbx
-   subq$376, %rsp
+   subq$216, %rsp
.cfi_offset 15, -24
.cfi_offset 14, -32
.cfi_offset 13, -40
@@ -1337,19 +1337,15 @@
movq8(%rax), %rax
movq%rax, -72(%rbp)
movq-72(%rbp), %rax
-   movq(%rax), %rdx
-   movq   
_ZN7Sublime4Area9viewAddedEPNS_9AreaIndexEPNS_4ViewE@GOTPCREL(%rip), %rax
-   movq%rax, %r8
-   movl$0, %r9d
-   movq%r8, %rax
-   cmpq%rax, %rdx
+   movq(%rax), %rax
+   testq   %rax, %rax
jne .L87
movq-72(%rbp), %rax
movq8(%rax), %rdx
movq   
_ZN7Sublime4Area9viewAddedEPNS_9AreaIndexEPNS_4ViewE@GOTPCREL(%rip), %rax
-   movq%rax, %r10
-   movl$0, %r11d
-   movq%r11, %rax
+   movq%rax, %r8
+   movl$0, %r9d
+   movq%r9, %rax
cmpq%rax, %rdx
je  .L88
movq-72(%rbp), %rax
@@ -1362,19 +1358,15 @@
jmp .L55
 .L87:
movq-72(%rbp), %rax
-   movq(%rax), %rdx
-   movq   
_ZN7Sublime4Area17aboutToRemoveViewEPNS_9AreaIndexEPNS_4ViewE@GOTPCREL(%rip),
%rax
-   movq%rax, %r12
-   movl$0, %r13d
-   movq%r12, %rax
-   cmpq%rax, %rdx
+   movq(%rax), %rax
+   testq   %rax, %rax
jne .L89
movq-72(%rbp), %rax
movq8(%rax), %rdx
movq   
_ZN7Sublime4Area17aboutToRemoveViewEPNS_9AreaIndexEPNS_4ViewE@GOTPCREL(%rip),
%rax
-   movq%rax, %r14
-   movl$0, %r15d
-   movq%r15, %rax
+   movq%rax, %r10
+   movl$0, %r11d
+   movq%r11, %rax
cmpq%rax, %rdx
je  .L90
movq-72(%rbp), %rax
...

[Bug bootstrap/77774] Build failure on netbsd-7.0.1/arm6hf of gcc 6.2.0, 7-20160925

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #2)
> The configure target used here is armv6--netbsdelf-eabihf (note two dashes
> after armv6)
> 
> aarch64-common.o is added to extra_objs in config.gcc

Of course I meant aarch-common.o. Muscle memory...

[Bug fortran/77707] [5/6/7 Regression] formatted direct access: nextrec off by one

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-28
  Known to work|4.3.5   |4.3.6
 Ever confirmed|0   |1
  Known to fail||4.4.7, 5.4.0, 6.2.0, 7.0

--- Comment #2 from Dominique d'Humieres  ---
Patch submitted at https://gcc.gnu.org/ml/fortran/2016-09/msg00172.html.

[Bug bootstrap/77774] Build failure on netbsd-7.0.1/arm6hf of gcc 6.2.0, 7-20160925

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
The configure target used here is armv6--netbsdelf-eabihf (note two dashes
after armv6)

aarch64-common.o is added to extra_objs in config.gcc
for arm*-*-*. Would that catch armv6--netbsdelf-eabihf?

[Bug bootstrap/77774] Build failure on netbsd-7.0.1/arm6hf of gcc 6.2.0, 7-20160925

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Earnshaw  ---
This function is defined in aarch-common.c.  It sounds like configure has
probably failed to add that to the build list.

A quick test on a cross build to that target does show aarch-common.o in
EXTRA_OBJS in gcc/Makefile, so can you check to see if that is the same for
you.

[Bug c++/77733] Add fixit hint suggesting to use std::move

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
The location for the "cannot bind rvalue reference" error is not a rich
location, so I couldn't figure out how to add a proper fix-it.

This just adds "did you mean std::move(x)?" to the end:

--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6804,7 +6804,8 @@ convert_like_real (conversion *convs, tree expr, tree fn,
int argnum,
if (TYPE_REF_IS_RVALUE (ref_type)
&& lvalue_p (expr))
  error_at (loc, "cannot bind rvalue reference of type %qT to "
-"lvalue of type %qT", totype, extype);
+"lvalue of type %qT; did you mean %?",
+totype, extype, expr);
else if (!TYPE_REF_IS_RVALUE (ref_type) && !lvalue_p (expr)
 && !CP_TYPE_CONST_NON_VOLATILE_P (TREE_TYPE (ref_type)))
  error_at (loc, "cannot bind non-const lvalue reference of "

Of course sometimes std::move is not the right fix, and it should be
std::forward(x) instead. Maybe it would be possible to detect
whether the expression is a function parameter declared as a forwarding
reference, but that's probably beyond my ken.

Also, if the lvalue is cv-qualified this still suggests std::move(x) even when
that wouldn't work:

move2.cc:13:9: error: cannot bind rvalue reference of type ‘X&&’ to lvalue of
type ‘const X’; did you mean ‘std::move(x)’? 


There's room for improvement.

[Bug c++/77748] pr77550.C fails on arm-none-eabi

[edlinger at gcc dot gnu.org]

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

--- Comment #24 from Bernd Edlinger  ---
Author: edlinger
Date: Wed Sep 28 12:11:57 2016
New Revision: 240573

URL: https://gcc.gnu.org/viewcvs?rev=240573=gcc=rev
Log:
2016-09-28  Bernd Edlinger  

PR c++/77748
* g++.dg/pr77550.C: Avoid undefined behavior.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/pr77550.C

[Bug libstdc++/77686] [6/7 Regression] wrong code on arm-linux-gnueabi and arm-linux-gnueabihf

[rguenther at suse dot de]

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

--- Comment #22 from rguenther at suse dot de  ---
On Wed, 28 Sep 2016, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77686
> 
> Jonathan Wakely  changed:
> 
>What|Removed |Added
> 
>  Status|NEW |RESOLVED
>  Resolution|--- |FIXED
> 
> --- Comment #21 from Jonathan Wakely  ---
> Fixed.

The issue is latent on the GCC 5 branch as well I guess.

[Bug libstdc++/77686] [6/7 Regression] wrong code on arm-linux-gnueabi and arm-linux-gnueabihf

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #21 from Jonathan Wakely  ---
Fixed.

[Bug libstdc++/77686] [6/7 Regression] wrong code on arm-linux-gnueabi and arm-linux-gnueabihf

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  ---
Author: redi
Date: Wed Sep 28 12:03:43 2016
New Revision: 240571

URL: https://gcc.gnu.org/viewcvs?rev=240571=gcc=rev
Log:
libstdc++/77686 use may_alias for std::function storage

PR libstdc++/77686
* include/std/functional (_Any_data): Add may_alias attribute.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/std/functional