[Bug c++/78898] [7 Regression] ICE: in get_template_base, at cp/pt.c:19665

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-22
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Started with r243870:

commit 784c77ce8cac38defa95faf85144c8f02848dfdb
Author: jason 
Date:   Wed Dec 21 19:38:50 2016 +

PR c++/42329 - deducing base template for template template arg

[Bug c++/78898] New: [7 Regression] ICE: in get_template_base, at cp/pt.c:19665

[trippels at gcc dot gnu.org]

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

Bug ID: 78898
   Summary: [7 Regression] ICE: in get_template_base, at
cp/pt.c:19665
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  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: ---

A very recent regression:

 % cat nsIconChannel.ii
struct A {
  template  A(T);
  template  class SmartPtr> A(SmartPtr) { A(0); }
};

 % g++ -c nsIconChannel.ii
nsIconChannel.ii: In substitution of ‘template class SmartPtr>
A::A(SmartPtr) [with SmartPtr = ]’:
nsIconChannel.ii:3:68:   required from here
nsIconChannel.ii:3:68: internal compiler error: in get_template_base, at
cp/pt.c:19665
   template  class SmartPtr> A(SmartPtr) { A(0); }
^~~~
0x10166603 get_template_base
../../gcc/gcc/cp/pt.c:19665
0x102a97f7 unify
../../gcc/gcc/cp/pt.c:20305
0x102aed5f unify_one_argument
../../gcc/gcc/cp/pt.c:18901
0x102b180b type_unification_real
../../gcc/gcc/cp/pt.c:19022
0x102b459b fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/gcc/cp/pt.c:18412
0x101ebc6b add_template_candidate_real
../../gcc/gcc/cp/call.c:3168
0x101ecbaf add_template_candidate
../../gcc/gcc/cp/call.c:3246
0x101ecbaf add_candidates
../../gcc/gcc/cp/call.c:5481
0x101e7a9b build_user_type_conversion_1
../../gcc/gcc/cp/call.c:3795
0x101e82e3 implicit_conversion
../../gcc/gcc/cp/call.c:1898
0x101e9c8f reference_binding
../../gcc/gcc/cp/call.c:1746
0x101e8593 implicit_conversion
../../gcc/gcc/cp/call.c:1837
0x101eaecf add_function_candidate
../../gcc/gcc/cp/call.c:2191
0x101ecbe7 add_candidates
../../gcc/gcc/cp/call.c:5491
0x101ed863 build_new_method_call_1
../../gcc/gcc/cp/call.c:8656
0x101ed863 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:8856
0x101ef2af build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/gcc/cp/call.c:8387
0x101f2e67 perform_direct_initialization_if_possible(tree_node*, tree_node*,
bool, int)
../../gcc/gcc/cp/call.c:10091
0x103b4e53 build_static_cast_1
../../gcc/gcc/cp/typeck.c:6795
0x103b6597 cp_build_c_cast(tree_node*, t

[Bug c++/78894] [c++17] ICE for std::list template deduction from std:: initializer_list

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-22
 CC||jason at gcc dot gnu.org,
   ||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug middle-end/78879] -fprofile-generate causes undefined reference to `____ilog2_NaN'

[coolypf at qq dot com]

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

--- Comment #8 from Yuan Pengfei  ---
I have sent a patch that fixes this bug. Please review it. Thanks!

https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01824.html

[Bug middle-end/78879] -fprofile-generate causes undefined reference to `____ilog2_NaN'

[coolypf at qq dot com]

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

Yuan Pengfei  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 CC||law at redhat dot com
 Resolution|DUPLICATE   |---

--- Comment #7 from Yuan Pengfei  ---
After some binary search, I figure out that this bug is a regression since
r226516 .
Here are the related patches:
  https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01856.html
  https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00096.html

[Bug c++/78897] New: ICE: in output_constructor_regular_field, at varasm.c:5019

[trippels at gcc dot gnu.org]

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

Bug ID: 78897
   Summary: ICE: in output_constructor_regular_field, at
varasm.c:5019
   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
  Target Milestone: ---

markus@x4 /tmp % cat const.ii
struct Optional {
  constexpr Optional() : _dummy{} { _value = 1; }
  union {
int _dummy;
int _value;
  };
};
Optional opt{};

markus@x4 /tmp % clang++ -std=c++14 -c const.ii
markus@x4 /tmp % icpc -std=c++14 -c const.ii
markus@x4 /tmp % g++ -c const.ii
const.ii:8:15: internal compiler error: in output_constructor_regular_field, at
varasm.c:5019
 Optional opt{};
   ^
0x104e345 output_constructor_regular_field
/home/markus/gcc/gcc/varasm.c:5019
0x104e345 output_constructor
/home/markus/gcc/gcc/varasm.c:5327
0x104d2aa output_constant
/home/markus/gcc/gcc/varasm.c:4704
0x104d2aa output_constructor_regular_field
/home/markus/gcc/gcc/varasm.c:5057
0x104d2aa output_constructor
/home/markus/gcc/gcc/varasm.c:5327
0x104f4d1 output_constant
/home/markus/gcc/gcc/varasm.c:4704
0x104f4d1 assemble_variable_contents
/home/markus/gcc/gcc/varasm.c:2083
0x10561ef assemble_variable(tree_node*, int, int, int)
/home/markus/gcc/gcc/varasm.c:2259
0x105ba21 varpool_node::assemble_decl()
/home/markus/gcc/gcc/varpool.c:588
0x96311c output_in_order
/home/markus/gcc/gcc/cgraphunit.c:2248
0x963523 symbol_table::compile()
/home/markus/gcc/gcc/cgraphunit.c:2488
0x965ed6 symbol_table::compile()
/home/markus/gcc/gcc/cgraphunit.c:2587
0x965ed6 symbol_table::finalize_compilation_unit()
/home/markus/gcc/gcc/cgraphunit.c:2584

[Bug c++/78896] New: Segmentation fault occurs when use variable initialized using structured binding with capture-by-ref lambda

[duongdominhchau at hotmail dot com]

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

Bug ID: 78896
   Summary: Segmentation fault occurs when use variable
initialized using structured binding with
capture-by-ref lambda
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: duongdominhchau at hotmail dot com
  Target Milestone: ---

I found a segmentation fault while trying structured binding using GCC 7:

This is the source code which caused the segmentation fault:
int main() {
  int a {10};
  auto [b]{ [&a](){} };
  return b - a;
}

The same code under Clang 4 would raise an error instead of a segmentation
fault.
GCC 7: http://melpon.org/wandbox/permlink/WDd8mSy4dCXj8CSa
Clang 4: http://melpon.org/wandbox/permlink/EQfQxrdTrbNbTw2b

If I change the lambda to capture by value, or never use the variable
initialized using structured binding (the variable `b` in my code), no
segmentation fault occurs.



This is the output of the compiler:
prog.cc: In function 'int main()':
prog.cc:4:10: internal compiler error: Segmentation fault
   return b - a;
  ^
0xb04b0f crash_signal
/home/heads/gcc/gcc-source/gcc/toplev.c:333
0x88b893 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/heads/gcc/gcc-source/gcc/expr.c:10107
0x895c1a store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/home/heads/gcc/gcc-source/gcc/expr.c:5552
0x89684e expand_assignment(tree_node*, tree_node*, bool)
/home/heads/gcc/gcc-source/gcc/expr.c:5321
0x7ab45d expand_gimple_stmt_1
/home/heads/gcc/gcc-source/gcc/cfgexpand.c:3641
0x7ab45d expand_gimple_stmt
/home/heads/gcc/gcc-source/gcc/cfgexpand.c:3737
0x7aca1f expand_gimple_basic_block
/home/heads/gcc/gcc-source/gcc/cfgexpand.c:5744
0x7b1be6 execute
/home/heads/gcc/gcc-source/gcc/cfgexpand.c:6355
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug bootstrap/78893] gcc-6.3.0 build fails on genattrtab on CentOS 7

[williambader at hotmail dot com]

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

--- Comment #2 from William Bader  ---
Thanks for the quick reply. The system is a VM. I have the results of 'free'
below. The VMs where the build worked all have slightly more memory and swap.
What is the recommended minimum to build gcc-6?
$ free -h
  totalusedfree  shared  buff/cache   available
Mem:   993M239M382M 10M371M564M
Swap:  1.0G977M 47M

Regards, William

[Bug bootstrap/78893] gcc-6.3.0 build fails on genattrtab on CentOS 7

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>make[3]: *** [s-attrtab] Killed


How much memory do you have on your system?  Do you have a swap space?
Provide the output of the command "free".

[Bug tree-optimization/78895] New: [6 regression] wrong code with -O1 when setting union twice since 6.3

[james410 at cowgill dot org.uk]

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

Bug ID: 78895
   Summary: [6 regression] wrong code with -O1 when setting union
twice since 6.3
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: james410 at cowgill dot org.uk
  Target Milestone: ---

Created attachment 40394
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40394&action=edit
union-twice.c

The attached testcase correctly prints nothing and exits with status 0 when
using GCC 6.2, but with 6.3 it prints "FAIL" and exits with status 10.

Originally reduced from strange behavior in jackd2
(https://bugs.debian.org/848285). The noinline bit is not required in the
original code in jackd2, but is in my testcase.

Compiled with:
 gcc -O1 union-twice.c -o union-twice

I bisected it to revision 241788 (the first bad revision):

2016-11-02  Richard Biener  

Backport from mainline
2016-11-02  Richard Biener  

PR tree-optimization/78047
* tree-ssa-structalias.c (push_fields_onto_fieldstack): Initialize
fake field at offset zero conservatively regarding to
may_have_pointers.

2016-10-31  Richard Biener  

PR lto/78129
* lto.c (do_whole_program_analysis): Bail out after errors
from WPA analysis.

2016-10-07  Richard Biener  

PR tree-optimization/77879
* tree-ssa-structalias.c (handle_const_call): Properly handle
NRV return slots.
(handle_pure_call): Likewise.

2016-10-06  Richard Biener  

PR tree-optimization/77839
* tree-ssa-sccvn.c (set_ssa_val_to): Forbid value -> constant value
lattice transition.

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

2016-09-27  Richard Biener  

PR tree-optimization/77745
* tree-ssa-pre.c (eliminate_dom_walker::before_dom_children):
When removing redundant stores make sure to check compatibility
of the TBAA state for downstream accesses.
* tree-ssa-sccvn.c (visit_reference_op_store): Likewise for when
value-numbering virtual operands for store matches.

* g++.dg/torture/pr77745.C: New testcase.

2016-09-21  Richard Biener  

PR tree-optimization/77648
* tree-ssa-structalias.c (process_constraint): Handle all DEREF
with complex RHS.
(make_transitive_closure_constraints): Adjust comment.
(make_any_offset_constraints): New function.
(handle_rhs_call): Make sure to first expand a pointer to all
subfields before transitively closing it.
(handle_const_call): Likewise.  Properly expand returned
pointers as well.
(handle_pure_call): Likewise.

* gcc.dg/torture/pr77648-1.c: New testcase.
* gcc.dg/torture/pr77648-2.c: Likewise.

[Bug c++/78894] New: [c++17] ICE for std::list template deduction from std:: initializer_list

[tom.m935 at hotmail dot com]

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

Bug ID: 78894
   Summary: [c++17] ICE for std::list template deduction from
std:: initializer_list
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom.m935 at hotmail dot com
  Target Milestone: ---

Created attachment 40393
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40393&action=edit
Preprocessed source

The code (preprocessed attached)

#include 

int main() {
// Should construct std::list
std::list list = { 0, 0 };
//  ^
// internal compiler error: in tsubst_copy, at cp/pt.c:14727, Abort trap: 6
}

crashes on gcc 7.0.0 20161204.  Expected behaviour is to construct a
std::list with two 0 elements.

Command: g++ bug.ii -std=c++17 -Wall -Wextra
Error:
bug.cpp: In function 'std::__cxx11::list(std::__cxx11::list<_Tp,
_Alloc>::size_type, const value_type&, const allocator_type&)->
std::__cxx11::list<_Tp, _Alloc> [with _Tp = int; _Alloc = std::allocator;
std::__cxx11::list<_Tp, _Alloc>::size_type = long unsigned int;
std::__cxx11::list<_Tp, _Alloc>::value_type = int; std::__cxx11::list<_Tp,
_Alloc>::allocator_type = std::allocator]':
bug.cpp:5:29: internal compiler error: in tsubst_copy, at cp/pt.c:14727
 std::list list = { 0, 0 };
 ^

bug.cpp:5:29: internal compiler error: Abort trap: 6
g++: internal compiler error: Abort trap: 6 (program cc1plus)

[Bug bootstrap/78893] New: gcc-6.3.0 build fails on genattrtab on CentOS 7

[williambader at hotmail dot com]

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

Bug ID: 78893
   Summary: gcc-6.3.0 build fails on genattrtab on CentOS 7
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: williambader at hotmail dot com
  Target Milestone: ---

Created attachment 40392
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40392&action=edit
build log

I built gcc-6.3.0 on CentOS 4, 5, and 6 using the same procedures that had
worked for previous gcc-6 releases, but on CentOS 7, the build fails in
genattrtab.  genattrtab crashes pretty hard -- running it under valgrind ends
with 'Killed', and valgrind exists without giving a traceback or diagnostics.
gdb couldn't get a stack trace either. I also tried running the build with -O0.
Is there anything else that I can try? I attached a log of the configure and
make.
The system is CentOS 7.3.1611 with kernel 3.10.0-327.36.2.el7.x86_64 and gcc
4.8.5 20150623 (Red Hat 4.8.5-11).
Regards,
William

[Bug c++/72707] [5/6/7 regression] local anonymous union member hides names in the same scope

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec 21 22:49:59 2016
New Revision: 243877

URL: https://gcc.gnu.org/viewcvs?rev=243877&root=gcc&view=rev
Log:
PR c++/72707
* name-lookup.c (pushdecl_maybe_friend_1): Do check shadowing of
artificial x if it is an anonymous union variable.

* g++.dg/warn/Wshadow-12.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wshadow-12.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78892] New: [7.0 Regression] no type conversion before coarray put

[damian at sourceryinstitute dot org]

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

Bug ID: 78892
   Summary: [7.0 Regression] no type conversion before coarray put
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

The code below demonstrates a regression in which gfortran 7.0.0 20161215 is
not performing a necessary implicit type conversion before putting data on a
remote image.  By contrast, the code below works as expected with gfortran
5.4.0 and 6.2.0. 

$ cat convert-before-put.f90 
  real :: a[*]
  integer :: receiver
  associate(me=>this_image())
if (me == 1) then
  do receiver = 2, num_images()
a[receiver] = receiver ! implicit real(receiver) needed here
sync images (receiver) ! notify remote image that data has been put
  end do 
else
  sync images (1) ! await notification of data put by image 1
  if (a/=real(me)) print *, "Image ",me,": received ",a,", but expected
",real(me)
end if
  end associate
end 

$ caf convert-before-put.f90 

$ cafrun -np 2 ./a.out
 Image2 : received0. , but expected2.

[Bug c++/78826] jump bypasses non-POD

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
(In reply to Jonathan Wakely from comment #4)
> Jason, do you see any advantage to making this a pedwarn for -std=c++98

That seems to make sense, given that other compilers diagnose it.

[Bug c++/78749] [7 Regression] bogus warning for friend member function in anonymous namespace

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed

[Bug c++/78767] [7 Regression] ICE when inheriting constructor of base class

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/42329] Deduction of template template argument via base class fails

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #5 from Jason Merrill  ---
Fixed for GCC 7.

[Bug rtl-optimization/71724] [5/6/7 Regression] ICE: Segmentation fault, deep recursion between combine_simplify_rtx and subst

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
I am using the following, which also fixes the infinite loop, and seems to
not regress code quality much at all (I found *one* pattern where it made
things one machine insn worse, involving a define_insn_and_split (with
cost 0, so any finite cost is better -- combine did manage to do something
that is better according to its costs!)

But I am worried something similar then needs to be done to true_rtx, and
I don't see what.


===
diff --git a/gcc/combine.c b/gcc/combine.c
index c7255f0..ecdd3fd 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -5658,7 +5658,7 @@ combine_simplify_rtx (rtx x, machine_mode op0_mode, int
in
 here since true_rtx or false_rtx might share RTL with x as a
 result of the if_then_else_cond call above.  */
  true_rtx = subst (copy_rtx (true_rtx), pc_rtx, pc_rtx, 0, 0, 0);
- false_rtx = subst (copy_rtx (false_rtx), pc_rtx, pc_rtx, 0, 0, 0);
+ false_rtx = subst (copy_rtx (false_rtx), cond, const0_rtx, 0, 0, 0);

  /* If true_rtx and false_rtx are not general_operands, an
if_then_else
 is unlikely to be simpler.  */

===

[Bug rtl-optimization/78812] [5/6/7 Regression] Wrong code generation due to hoisting memory load across function call

[law at redhat dot com]

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

--- Comment #9 from Jeffrey A. Law  ---
So it's been a long time...  And IIRC, rth was the one that fixed this wart in
gcse.


A BB that ends with a call that can throw or any other abnormal edge is
supposed to suppress hoisting for precisely the reasons outlined in this BZ. 
Essentially we need to insert on the edge, but we can't (easily) do that for
the EH/abnormal edge and we can't safely insert before the call.

Theother possibility was that we kill the expressions in the EH landing pads. 
I thought we looked at that as well.

[Bug rtl-optimization/78580] [6/7 Regression] Segfault in gcc with multilib (-m32) and -ffixed-*

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
Author: vmakarov
Date: Wed Dec 21 22:20:11 2016
New Revision: 243875

URL: https://gcc.gnu.org/viewcvs?rev=243875&root=gcc&view=rev
Log:
2016-12-21  Vladimir Makarov  

PR rtl-optimization/78580
* ira-costs.c (find_costs_and_classes): Make regno_aclass
translated into an allocno class.

2016-12-21  Vladimir Makarov  

PR rtl-optimization/78580
* gcc.target/i386/pr78580.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr78580.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-costs.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec 21 22:15:59 2016
New Revision: 243874

URL: https://gcc.gnu.org/viewcvs?rev=243874&root=gcc&view=rev
Log:
PR bootstrap/78817
* tree-pass.h (make_pass_post_ipa_warn): Declare.
* builtins.c (validate_arglist): Adjust get_nonnull_args call.
Check for NULL pointer argument to nonnull arg here.
(validate_arg): Revert 2016-12-14 changes.
* calls.h (get_nonnull_args): Remove declaration.
* tree-ssa-ccp.c: Include diagnostic-core.h.
(pass_data_post_ipa_warn): New variable.
(pass_post_ipa_warn): New class.
(pass_post_ipa_warn::execute): New method.
(make_pass_post_ipa_warn): New function.
* tree.h (get_nonnull_args): Declare.
* tree.c (get_nonnull_args): New function.
* calls.c (maybe_warn_null_arg): Removed.
(maybe_warn_null_arg): Removed.
(initialize_argument_information): Revert 2016-12-14 changes.
* passes.def: Add pass_post_ipa_warn after first ccp after IPA.
c-family/
* c-common.c (struct nonnull_arg_ctx): New type.
(check_function_nonnull): Return bool instead of void.  Use
nonnull_arg_ctx as context rather than just location_t.
(check_nonnull_arg): Adjust for the new context type, set
warned_p to true if a warning has been diagnosed.
(check_function_arguments): Return bool instead of void.
* c-common.h (check_function_arguments): Adjust prototype.
c/
* c-typeck.c (build_function_call_vec): If check_function_arguments
returns true, set TREE_NO_WARNING on CALL_EXPR.
cp/
* typeck.c (cp_build_function_call_vec): If check_function_arguments
returns true, set TREE_NO_WARNING on CALL_EXPR.
* call.c (build_over_call): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/calls.c
trunk/gcc/calls.h
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/typeck.c
trunk/gcc/passes.def
trunk/gcc/tree-pass.h
trunk/gcc/tree-ssa-ccp.c
trunk/gcc/tree.c
trunk/gcc/tree.h

[Bug c++/77829] Bad fix-it for nested-name-specifier

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

[Bug c++/78656] Fix-it suggestion for std::alocator doesn't include std::allocator

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

[Bug c/78891] Array out of bound access generates wrong code in O2 or higher optimizations

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

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #4 from Andreas Schwab  ---
Because it's undefined there are no constraints.

[Bug c++/77830] internal compiler error: in output_constructor_regular_field, at varasm.c:4968, when using constexpr (with testcase)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec 21 21:58:23 2016
New Revision: 243873

URL: https://gcc.gnu.org/viewcvs?rev=243873&root=gcc&view=rev
Log:
PR c++/77830
* constexpr.c (cxx_eval_array_reference): Perform out of bounds
verification even if lval is true, just allow one past the last
element in that case.
(cxx_eval_store_expression): Detect stores to out of bound
ARRAY_REF.

* g++.dg/cpp1y/pr77830.C: New test.
* g++.dg/cpp0x/pr65398.C: Adjust expected diagnostics.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr77830.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/pr65398.C

[Bug c/78891] Array out of bound access generates wrong code in O2 or higher optimizations

[gcc at fischerpaulsen dot dk]

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

Christian Paulsen  changed:

   What|Removed |Added

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

--- Comment #3 from Christian Paulsen  ---
valgrind does NOT catch the the problem in the original code using array
indexing and not pointer calculation.

As the generated code does not access the array at all

[Bug rtl-optimization/71724] [5/6/7 Regression] ICE: Segmentation fault, deep recursion between combine_simplify_rtx and subst

[bernds at gcc dot gnu.org]

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

--- Comment #4 from Bernd Schmidt  ---
Maybe we just need to test for that condition, even though it's ugly. However,
I think there are some other improvements we could make here.

Part of the problem seems to be what if_then_else_cond does on this rtx:

(plus:SI (if_then_else:SI (eq (reg:CC 185)
(const_int 0 [0]))
(reg:SI 165)
(reg:SI 174 [ t9.0_1+4 ]))
(reg:SI 165))

Reg 165 is known to be zero or one, so it gets turned into a condition, and we
have two different conditions on the operands. That causes us to fail to make
the fairly obvious transformation to 
 cond = reg:CC 185
 true_rtx = (plus r165 r165)
 false_rtx = (plus r174 r165)

I'm testing the following, which tries to undo such transformation of plain REG
if that seems it'll enable other transformations which are more likely to be
beneficial. It makes the crash go away.

Index: combine.c
===
--- combine.c   (revision 242958)
+++ combine.c   (working copy)
@@ -9031,11 +9031,31 @@ if_then_else_cond (rtx x, rtx *ptrue, rt
  the same value, compute the new true and false values.  */
   else if (BINARY_P (x))
 {
-  cond0 = if_then_else_cond (XEXP (x, 0), &true0, &false0);
-  cond1 = if_then_else_cond (XEXP (x, 1), &true1, &false1);
+  rtx op0 = XEXP (x, 0);
+  rtx op1 = XEXP (x, 1);
+  cond0 = if_then_else_cond (op0, &true0, &false0);
+  cond1 = if_then_else_cond (op1, &true1, &false1);
+
+  if ((cond0 != 0 && cond1 != 0 && !rtx_equal_p (cond0, cond1))
+ && (REG_P (op0) || REG_P (op1)))
+   {
+ /* Try to enable a simplification by undoing work done by
+if_then_else_cond if it converted a REG into something more
+complex.  */
+ if (REG_P (op0))
+   {
+ cond0 = 0;
+ true0 = false0 = op0;
+   }
+ else
+   {
+ cond1 = 0;
+ true1 = false1 = op1;
+   }
+   }

   if ((cond0 != 0 || cond1 != 0)
- && ! (cond0 != 0 && cond1 != 0 && ! rtx_equal_p (cond0, cond1)))
+ && ! (cond0 != 0 && cond1 != 0 && !rtx_equal_p (cond0, cond1)))
{
  /* If if_then_else_cond returned zero, then true/false are the
 same rtl.  We must copy one of them to prevent invalid rtl

[Bug rtl-optimization/11488] Pre-regalloc scheduling severely worsens performance

[pthaugen at gcc dot gnu.org]

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

--- Comment #13 from Pat Haugen  ---
Fixed on powerpc. Testcase times (at 8X original loop count to get measurable
times).

base: 4.436 sec
base + -fno-schedule-insns: 2.052 sec
base + patch: 1.815 sec

[Bug c++/42329] Deduction of template template argument via base class fails

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Dec 21 19:38:50 2016
New Revision: 243870

URL: https://gcc.gnu.org/viewcvs?rev=243870&root=gcc&view=rev
Log:
PR c++/42329 - deducing base template for template template arg

* pt.c (unify_bound_ttp_args): Split out from unify.
(try_class_unification): Handle BOUND_TEMPLATE_TEMPLATE_PARM.
(unify): Check for type/non-type mismatch early.
[BOUND_TEMPLATE_TEMPLATE_PARM]: Try get_template_base.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-ttp6.C
trunk/gcc/testsuite/g++.dg/template/ttp-derived1.C
trunk/gcc/testsuite/g++.dg/template/ttp-derived2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-2.C

[Bug rtl-optimization/11488] Pre-regalloc scheduling severely worsens performance

[pthaugen at gcc dot gnu.org]

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

--- Comment #12 from Pat Haugen  ---
Author: pthaugen
Date: Wed Dec 21 19:15:32 2016
New Revision: 243866

URL: https://gcc.gnu.org/viewcvs?rev=243866&root=gcc&view=rev
Log:
PR rtl-optimization/11488
* common/config/rs6000/rs6000-common.c
(rs6000_option_optimization_table): Enable -fsched-pressure.
* config/rs6000/rs6000.c (TARGET_COMPUTE_PRESSURE_CLASSES): Define
target hook.
(rs6000_option_override_internal): Set default -fsched-pressure
algorithm.
(rs6000_compute_pressure_classes): Implement target hook.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/common/config/rs6000/rs6000-common.c
trunk/gcc/config/rs6000/rs6000.c

[Bug c++/78767] [7 Regression] ICE when inheriting constructor of base class

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Dec 21 19:10:23 2016
New Revision: 243864

URL: https://gcc.gnu.org/viewcvs?rev=243864&root=gcc&view=rev
Log:
PR c++/78767 - ICE with inherited constructor default argument

* method.c (strip_inheriting_ctors): Strip template as appropriate.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor24.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c

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

[seurer at gcc dot gnu.org]

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

--- Comment #19 from seurer at gcc dot gnu.org ---
Author: seurer
Date: Wed Dec 21 19:09:10 2016
New Revision: 243863

URL: https://gcc.gnu.org/viewcvs?rev=243863&root=gcc&view=rev
Log:
[PATCH, v2, rs6000] pr65479 Add -fasynchronous-unwind-tables when the
-fsanitize=address option is seen.

All feedback from the earlier version has been taken into account now.

This patch adds the -fasynchronous-unwind-tables option to compilations when
the -fsanitize=address option is seen but not if any
-fasynchronous-unwind-tables options were already specified.
-fasynchronous-unwind-tables causes a full strack trace to be produced when
the sanitizer detects an error.  Without the full trace several of the asan
test cases fail on powerpc.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 for more information.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu,
powerpc64be-unknown-linux-gnu, and x86_64-pc-linux-gnu with no regressions.
Is this ok for trunk?

[gcc]

2016-12-21  Bill Seurer  

PR sanitizer/65479
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add
-fasynchronous-unwind-tables option when -fsanitize=address is
specified.

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

[Bug c/78891] Array out of bound access generates wrong code in O2 or higher optimizations

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Let's consider following runnable test-case:

$ cat pr78891.c
void readArray(unsigned char *p);

int main(void)
{
  unsigned char array[16];
  unsigned short index;

  readArray(array);

  for(index = 0;((*(array+index) == 0x0) && (index < 16)); ++index);

  return (index < 16) ? 1 : 0;
}

$ cat pr78891-2.c
void readArray(unsigned char *ptr)
{
  __builtin_bzero (ptr, 16);
}

$ gcc pr78891.c pr78891-2.c -O2 && valgrind ./a.out 
==28173== Memcheck, a memory error detector
==28173== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==28173== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==28173== Command: ./a.out
==28173== 
==28173== Conditional jump or move depends on uninitialised value(s)
==28173==at 0x4003E7: main (in /home/marxin/Programming/testcases/a.out)

$ gcc pr78891.c pr78891-2.c -O2 -fsanitize=undefined && ./a.out 
pr78891.c:10:19: runtime error: load of address 0x7fff856791b0 with
insufficient space for an object of type 'unsigned char'
0x7fff856791b0: note: pointer points here
 00 00 00 00  00 00 00 00 00 00 00 00  b0 06 40 00 00 00 00 00  a0 05 40 00 00
00 00 00  91 c2 ea 1a
  ^ 
Both undefined behavior sanitizer and valgrind can detect the undefined
behavior. Thus I'm closing as invalid.

[Bug c/78891] Array out of bound access generates wrong code in O2 or higher optimizations

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
((*(array+index) == 0x0) && (index < 16))

This is undefined code.  You should swap around the two operands to the short
cutting boolean and to have defined code.

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

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
It looks very much like PR71724 indeed, but I cannot get this one to fail.

[Bug c/78891] New: Array out of bound access generates wrong code in O2 or higher optimizations

[gcc at fischerpaulsen dot dk]

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

Bug ID: 78891
   Summary: Array out of bound access generates wrong code in O2
or higher optimizations
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at fischerpaulsen dot dk
  Target Milestone: ---

Created attachment 40391
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40391&action=edit
Faulty code

The included isSet function will return 1 without checking the contents of
array if compiled with optimization -O2 -O3 or -Os. Especially it will return 1
if array contains 16 0's - which is wrong. 

It will work correctly if compiled with lower optimization.

It will also work correctly if 
- the array is defined as unsigned char array[17];
or
- the expression array[index] == 0x0 is changed to *(array+index) == 0x0

Note that the code might access the element array[16] - which is outside the
array - but the contents of this is irrelvant for the result.

The command line used for compilation is
gcc -O2 -save-temps  -Wall -Wextra -c prog.c

It was run on a standard ubuntu PC
uname -a
Linux cpa-ThinkPad-T530 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux

The problem has been observed on a number of gcc versions (e.g. cygwin on
windows 7 using gcc version 4.9.2)

[Bug c++/78890] [5/6/7 Regression] ICE on invalid reference type in union

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-21
  Known to work||4.9.4
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.3.0, 7.0

[Bug c++/78749] [7 Regression] bogus warning for friend member function in anonymous namespace

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Dec 21 18:28:54 2016
New Revision: 243862

URL: https://gcc.gnu.org/viewcvs?rev=243862&root=gcc&view=rev
Log:
PR c++/78749 - friend in anonymous namespace

* decl.c (wrapup_globals_for_namespace): Don't complain about friend
pseudo-template instantiations.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wunused-function3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c

[Bug c++/78890] New: [5/6/7 Regression] ICE on invalid reference type in union

[trippels at gcc dot gnu.org]

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

Bug ID: 78890
   Summary: [5/6/7 Regression] ICE on invalid reference type in
union
   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
  Target Milestone: ---

Reddit user sjd96 reported the following issue:

 % cat union.ii
int main() {
  union {
int a;
int &b = a;
  };
  a = 1;
  auto c = b + 1;
}

 % g++ -c union.ii
union.ii: In function ‘int main()’:
union.ii:1:5: error: invalid first operand of MEM_REF
 int main() {
 ^~~~
_2
union.ii:7:12: note: in statement
   auto c = b + 1;
^
_3 = MEM[(int &)_2];
union.ii:1:5: internal compiler error: verify_gimple failed
 int main() {
 ^~~~
0xda2bd5 verify_gimple_in_cfg(function*, bool)
/home/markus/gcc/gcc/tree-cfg.c:5266
0xc85c06 execute_function_todo
/home/markus/gcc/gcc/passes.c:1965
0xc86cab execute_todo
/home/markus/gcc/gcc/passes.c:2015


 % g++ -std=c++98 -c union.ii
union.ii: In function ‘int main()’:
union.ii:4:14: warning: non-static data member initializers only available with
-std=c++11 or -std=gnu++11
 int &b = a;
  ^
union.ii:4:14: error: in C++98 ‘main()b’ may not have
reference type ‘int&’ because it is a member of a union
union.ii:7:8: error: ‘c’ does not name a type
   auto c = b + 1;
^

[Bug debug/78685] -Og generates too many ""s

[eggert at gnu dot org]

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

--- Comment #5 from Paul Eggert  ---
Just to clarify: 'main' (in the sample program) is just an example. The
problems developers are seeing when debugging Emacs almost all involve
functions other than 'main'.

It should be OK for -Og to optimize significantly less than it does now, so
long as -Og remains better than -O0. As things stand, -Og is pretty much
useless for its stated purpose because GDB so often cannot display values of
locals, and I expect this partly explains why -Og is so rarely used in
practice.

In Emacs, developers use -O0 for debugging, but this can be reeeaally slow
because -O0 does not inline and Emacs relies heavily on small inlined
functions. Although Emacs works around this problem by using macros instead of
functions, such workarounds have obvious drawbacks. For Emacs, it would be nice
if -Og did not discard locals, but continued to inline.

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

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #4 from Bernd Schmidt  ---
Seems very likely.

[Bug tree-optimization/78887] [7 Regression] Failure to build aarch64 allmodconfig Linux kernel 4.9

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Can you attach the preprocessed sources associated with sha1-ce.o ?  It should
be only one or two files.

[Bug tree-optimization/71518] [6 Regression] wrong code at -O3 on x86_64-linux-gnu in 64-bit mode (not in 32-bit mode)

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #10 from Mikael Pettersson  ---
Shouldn't this be closed as fixed?  The fix was backported to gcc-6-branch long
ago.

[Bug middle-end/78888] New: toupper(x) can be assumed not to be in the range 'a' - 'z'

[msebor at gcc dot gnu.org]

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

Bug ID: 7
   Summary: toupper(x) can be assumed not to be in the range 'a' -
'z'
   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: ---

The return value of the toupper function is guaranteed not to be in the range
'a' - 'z'.  Similarly, the tolower return value is guaranteed not to be in the
range 'A' - 'Z'.  For non-EBCDIC character sets, it would be useful to set the
range on the return value reflecting this constrained range.  (The range is
actually the intersection of the range [0, UCHAR_MAX] and the anti-range ~['a',
'z'], plus the value EOF).

In addition, it would be useful to issue a warning if the return value is
compared against a constant from its anti-range since such a comparison in
always false (this might naturally fall out of the optimization).

The following test case shows that GCC does not take advantage of this
optimization (it doesn't remove the call to f()) or issue the warning.

$ cat d.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout d.c 
void f (void);

void g (int x)
{
  if (__builtin_toupper ((unsigned char)x) == 'a')
f ();
}

;; Function g (g, funcdef_no=0, decl_uid=1797, cgraph_uid=0, symbol_order=0)

Removing basic block 5
g (int x)
{
  int _1;
  int _6;

   [100.00%]:
  _6 = x_3(D) & 255;
  _1 = __builtin_toupper (_6);
  if (_1 == 97)
goto ; [22.95%]
  else
goto ; [77.05%]

   [22.95%]:
  f (); [tail call]

   [100.00%]:
  return;

}

[Bug fortran/78866] ICE in gimplify_adjust_omp_clauses_1, at gimplify.c:8721

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug tree-optimization/78886] [5/6/7 Regression] Segmentation fault malloc and volatile

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
I'd say tree-ssa-strlen.c is not the pass that should remove the malloc.
The patch is preapproved with suitable testcase and ChangeLog.

[Bug libstdc++/78870] Support std::filesystem on Windows

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Jan Niklas Hasse from comment #6)
> According to https://www.gnu.org/licenses/license-list.html the Boost
> License is GPL compatible. So when I mark the code I copied with the source,
> it should work, shouldn't it?

See the legal prerequisites. As it says, the FSF prefers to hold the copyright
on all code contributed to GCC. If you copy somebody else's code you can't
assign copyright to the FSF because you don't own the copyright. We could
request all the authors of Boost.Filesystem to assign copyright, but I don't
want to do that, I want an independent implementation (the Boost implementation
doesn't follow exactly the same specification anyway).

I'm not interested in simply copying the Boost.Filesystem code into GCC.

If you want to use the Boost implementation then just use that, with
appropriate preprocessor hackery and namespace aliases.

[Bug target/71321] [6/7 Regression] x86: worse code for uint8_t % 10 and / 10

[bernds at gcc dot gnu.org]

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

--- Comment #6 from Bernd Schmidt  ---
Author: bernds
Date: Wed Dec 21 16:45:33 2016
New Revision: 243861

URL: https://gcc.gnu.org/viewcvs?rev=243861&root=gcc&view=rev
Log:

PR target/71321
* config/i386/i386.md (lea_general_2b, lea_general_3b): New
patterns.
* config/i386/predicates.md (const123_operand): New.

PR target/71321
* gcc.target/i386/pr71321.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr71321.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/78870] Support std::filesystem on Windows

[jhasse at bixense dot com]

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

--- Comment #6 from Jan Niklas Hasse  ---
> Yes.

Okay thanks, I'll look into it.

> You can't copy any code, that would be a copyright violation. It's OK to see
> which Windows API functions Boost uses for a particular filesystem
> operation, but if you're not sure what is covered by copyright law then it's
> safer not to use another project at all.

According to https://www.gnu.org/licenses/license-list.html the Boost License
is GPL compatible. So when I mark the code I copied with the source, it should
work, shouldn't it?

> I was hoping that somebody who actually knows the Windows API would
> contribute the code, so they already know what the appropriate functions are.

I know the Windows API, but the details are hard to get right. Especially
getting everything to be bug-free. Many man hours have already been spend on
boost::filesystem and the API is similar to std::filesystem. Why should I
re-invent the wheel?

[Bug fortran/78866] ICE in gimplify_adjust_omp_clauses_1, at gimplify.c:8721

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec 21 16:16:20 2016
New Revision: 243860

URL: https://gcc.gnu.org/viewcvs?rev=243860&root=gcc&view=rev
Log:
PR fortran/78866
* openmp.c (resolve_omp_clauses): Diagnose assumed size arrays in
OpenMP map, to and from clauses.
* trans-openmp.c: Include diagnostic-core.h, temporarily redefining
GCC_DIAG_STYLE to __gcc_tdiag__.
(gfc_omp_finish_clause): Diagnose implicitly mapped assumed size
arrays.

* gfortran.dg/gomp/map-1.f90: Add expected error.
* gfortran.dg/gomp/pr78866-1.f90: New test.
* gfortran.dg/gomp/pr78866-2.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr78866-1.f90
trunk/gcc/testsuite/gfortran.dg/gomp/pr78866-2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c
trunk/gcc/fortran/trans-openmp.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/gomp/map-1.f90

[Bug target/76731] [AVX512] _mm512_i32gather_epi32 and other scatter/gather routines have incorrect signature

[andrew.n.senkevich at gmail dot com]

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

Andrew Senkevich  changed:

   What|Removed |Added

 CC||andrew.n.senkevich at gmail 
dot co
   ||m

--- Comment #8 from Andrew Senkevich  ---
(In reply to Uroš Bizjak from comment #7)
> (In reply to Jakub Jelinek from comment #5)
> > Kyrill/Uros, is this something we should change?
> > Any comments on the #c1 questions?
> 
> Someone from Intel (HJ CC'd) will have to clarify the issue first.

Hi, the issue take place, and it is hard to say about its history.

I think we should follow here declarations from icc headers to be compatible
with it.
We will work on update SDM accordingly.

[Bug libstdc++/78870] Support std::filesystem on Windows

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jan Niklas Hasse from comment #4)
> Do you mean the part about legal paperwork in
> https://gcc.gnu.org/contribute.html ?

Yes.

> And can I look at how boost::filesystem does this?

You can't copy any code, that would be a copyright violation. It's OK to see
which Windows API functions Boost uses for a particular filesystem operation,
but if you're not sure what is covered by copyright law then it's safer not to
use another project at all.

I was hoping that somebody who actually knows the Windows API would contribute
the code, so they already know what the appropriate functions are.

[Bug bootstrap/78880] [7 Regression] Revision 243196 breaks bootstrap on x86_64-w64-mingw32

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Posting revision number as r243196 so BZ will linkify it.

[Bug target/78875] -fstack-protector on powerpc64 now always use TLS, won't work for kernel/firmware

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-21
 CC||dje at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug driver/70936] Hard-coded C++ header paths and relocation problem

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target|i686-w64-mingw32|
   Last reconfirmed|2016-05-27 00:00:00 |2016-12-21
 CC||dje at gcc dot gnu.org
Summary|Hard-coded C++ header paths |Hard-coded C++ header paths
   |and relocation problem on   |and relocation problem
   |Windows |
  Known to fail||6.3.0

--- Comment #12 from David Edelsohn  ---
Dakon: Reconfirmed with 6.3.  Not x86 dependent.  Not Windows or mingw
dependent.

[Bug tree-optimization/78886] [5/6/7 Regression] Segmentation fault malloc and volatile

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
The return value of malloc is ignored? Your patch looks ok to me, thanks. If it
is convenient, you might want to remove the statement, otherwise I expect
another pass will handle it later.

[Bug tree-optimization/78887] [7 Regression] Failure to build aarch64 allmodconfig Linux kernel 4.9

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||aarch64-linux-gnu
  Known to work||6.2.1
   Target Milestone|--- |7.0
  Known to fail||7.0

[Bug tree-optimization/78887] New: [7 Regression] Failure to build aarch64 allmodconfig Linux kernel 4.9

[ktkachov at gcc dot gnu.org]

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

Bug ID: 78887
   Summary: [7 Regression] Failure to build aarch64 allmodconfig
Linux kernel 4.9
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

Building an allmodconfig 4.9 kernel for arm64 fails with current trunk (make
ARCH=arm64 allmodconfig)

The error is:
FATAL: arch/arm64/crypto/sha1-ce: sizeof(struct cpu_device_id)=2 is not a
modulo of the size of section __mod_cpu___device_table=1.
Fix definition of struct cpu_device_id in mod_devicetable.h
make[1]: *** [arch/arm64/crypto/sha1-ce.o] Error 1

Some kind of assert is triggering in one of the kernel build scripts.
The build succeeds with GCC 6.

Looks like the compiler renamed some asan-related symbols from:
 '_GLOBAL__sub_D_65535_0_sha1_ce_glue.c' to 
'_GLOBAL__sub_D_65535_0___odr_asan.__mod_cpu__cpu_feature_match_SHA1_device_table'

Not sure if this is a duplicate of 78513

[Bug middle-end/78884] ICE when gimplifying VLA in OpenMP SIMD region

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] ICE when |ICE when gimplifying VLA in
   |gimplifying VLA in OpenMP   |OpenMP SIMD region
   |SIMD region |

--- Comment #3 from Martin Liška  ---
Ok, dropping regression prefix.

[Bug tree-optimization/78886] [5/6/7 Regression] Segmentation fault malloc and volatile

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #3 from Martin Liška  ---
Following patch fixes that:

diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index 67075f07e29..4a05725ca7c 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -1869,6 +1869,9 @@ handle_builtin_malloc (enum built_in_function bcode,
gimple_stmt_iterator *gsi)
 {
   gimple *stmt = gsi_stmt (*gsi);
   tree lhs = gimple_call_lhs (stmt);
+  if (lhs == NULL_TREE)
+return;
+
   gcc_assert (get_stridx (lhs) == 0);
   int idx = new_stridx (lhs);
   tree length = NULL_TREE;

If Mark Glisse, the author of the handle_builtin_malloc function, is fine, I'll
test that.

[Bug middle-end/78884] [5/6/7 Regression] ICE when gimplifying VLA in OpenMP SIMD region

[amonakov at gcc dot gnu.org]

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

--- Comment #2 from Alexander Monakov  ---
Not sure how well this qualifies as a regression: prior to 4.9, there was no
OpenMP SIMD support, so 4.8 just diagnoses a warning for an unrecognized
omp-simd pragma.

[Bug tree-optimization/78886] [5/6/7 Regression] Segmentation fault malloc and volatile

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started with GCC 5.

[Bug middle-end/78884] [5/6/7 Regression] ICE when gimplifying VLA in OpenMP SIMD region

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-21
 CC||marxin at gcc dot gnu.org
  Known to work||4.8.5
Summary|ICE when gimplifying VLA in |[5/6/7 Regression] ICE when
   |OpenMP SIMD region  |gimplifying VLA in OpenMP
   ||SIMD region
 Ever confirmed|0   |1
  Known to fail||4.9.4, 5.4.0, 6.3.0

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

[Bug driver/78877] Missing suggestion for -fsanitize=addres

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
There's very similar one seen by Jakub in:
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01765.html

$ ./xgcc -B. -fsanitize=nul /tmp/a.c
xgcc: error: unrecognized argument to -fsanitize= option: ‘nul’
$ ./xgcc -B. -fsanitiz=nul /tmp/a.c
xgcc: error: unrecognized command line option ‘-fsanitiz=nul’; did you mean
‘-fsanitize=null’?

[Bug driver/78863] [6 Regression] error on -fsanitize suggests invalid -fsanitize=all

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

Summary|[6/7 Regression] error on   |[6 Regression] error on
   |-fsanitize suggests invalid |-fsanitize suggests invalid
   |-fsanitize=all  |-fsanitize=all

--- Comment #5 from Martin Liška  ---
Fixed on trunk so far.

[Bug driver/78863] [6/7 Regression] error on -fsanitize suggests invalid -fsanitize=all

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Wed Dec 21 15:05:10 2016
New Revision: 243857

URL: https://gcc.gnu.org/viewcvs?rev=243857&root=gcc&view=rev
Log:
Do not suggest -fsanitize=all (PR driver/78863).

PR driver/78863
* gcc.c (driver::build_option_suggestions): Do not add
-fsanitize=all as a suggestion candidate.
PR driver/78863
* gcc.dg/spellcheck-options-13.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/spellcheck-options-13.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcc.c
trunk/gcc/testsuite/ChangeLog

[Bug c/78886] gcc Segmentation fault malloc and volatile

[prekgeo at yahoo dot com]

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

--- Comment #1 from George Prekas  ---
Created attachment 40390
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40390&action=edit
the preprocessed file

[Bug rtl-optimization/78883] [avr] ICE triggered by change to combine.c (r243578)

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  ---
Created attachment 40389
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40389&action=edit
.combine dump as requested.

Genrated with

$ avr-gcc pr26833.c -S -O1 -mmcu=avr4 -S -fdump-rtl-combine-details

FYI, the error goes away with -Os or -O2.

[Bug c/78886] New: gcc Segmentation fault malloc and volatile

[prekgeo at yahoo dot com]

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

Bug ID: 78886
   Summary: gcc Segmentation fault malloc and volatile
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prekgeo at yahoo dot com
  Target Milestone: ---

Created attachment 40388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40388&action=edit
test case

$ ./configure --disable-multilib --enable-languages=c --prefix=/home/prekas/gcc

$ uname -a
Linux sciicebpc1 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux

$ ../gcc/bin/gcc -v -save-temps -S -O2 gcc_bug.c
Using built-in specs.
COLLECT_GCC=../gcc/bin/gcc
Target: x86_64-pc-linux-gnu
Configured with: ./configure --disable-multilib --enable-languages=c
Thread model: posix
gcc version 6.3.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-S' '-O2' '-mtune=generic'
'-march=x86-64'
 /home/prekas/gcc/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.3.0/cc1 -E -quiet -v
-imultiarch x86_64-linux-gnu -iprefix
/home/prekas/gcc/bin/../lib/gcc/x86_64-pc-linux-gnu/6.3.0/ gcc_bug.c
-mtune=generic -march=x86-64 -O2 -fpch-preprocess -o gcc_bug.i
ignoring nonexistent directory
"/home/prekas/gcc/bin/../lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory
"/home/prekas/gcc/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.3.0/include"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring duplicate directory
"/home/prekas/gcc/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.3.0/include-fixed"
ignoring nonexistent directory
"/home/prekas/gcc/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/prekas/gcc/bin/../lib/gcc/x86_64-pc-linux-gnu/6.3.0/include
 /home/prekas/gcc/bin/../lib/gcc/x86_64-pc-linux-gnu/6.3.0/include-fixed
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-S' '-O2' '-mtune=generic'
'-march=x86-64'
 /home/prekas/gcc/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.3.0/cc1
-fpreprocessed gcc_bug.i -quiet -dumpbase gcc_bug.c -mtune=generic
-march=x86-64 -auxbase gcc_bug -O2 -version -o gcc_bug.s
GNU C11 (GCC) version 6.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.3.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 6.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.3.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: aac98bc8a6db7b45e88f65faa8c8f64b
gcc_bug.c: In function 'foo':
gcc_bug.c:3:6: internal compiler error: Segmentation fault
 void foo(void)
  ^~~
0x9c5cdf crash_signal
../.././gcc/toplev.c:333
0xb131f1 get_stridx
../.././gcc/tree-ssa-strlen.c:195
0xb14e8e handle_builtin_malloc
../.././gcc/tree-ssa-strlen.c:1837
0xb14e8e strlen_optimize_stmt
../.././gcc/tree-ssa-strlen.c:2156
0xb14e8e strlen_dom_walker::before_dom_children(basic_block_def*)
../.././gcc/tree-ssa-strlen.c:2339
0xf4ace2 dom_walker::walk(basic_block_def*)
../.././gcc/domwalk.c:265
0xb12b0f execute
../.././gcc/tree-ssa-strlen.c:2411
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/78870] Support std::filesystem on Windows

[jhasse at bixense dot com]

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

--- Comment #4 from Jan Niklas Hasse  ---
> Great! Please read 
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html 
> especially the part about legal paperwork.

Do you mean the part about legal paperwork in
https://gcc.gnu.org/contribute.html ?

> No. Just look at the existing code and figure out what the equivalent code 
> would be for Windows, and write an alternative implementation e.g. replace 
> calls to POSIX stat() with whatever Windows uses to query file properties, 
> and replace calls to POSIX chmod with whatever Windows uses to change file 
> permissions.

And can I look at how boost::filesystem does this?

[Bug c/78885] gcac checking too slow to be useful ?

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Gcac is always collect when ggc_collect is called so yes it will be slow as gc
collecting is slow due to having to mark and sweep over huge amounts of memory
and there are many calls to ggc_collect now. Each new pass gets one new call.

[Bug c/78885] New: gcac checking too slow to be useful ?

[dcb314 at hotmail dot com]

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

Bug ID: 78885
   Summary: gcac checking too slow to be useful ?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I just tried out a plain non-bootstrap build
of gcc trunk using --enable-checking=gcac. 

Configure line was

../trunk/configure --prefix=/home/dcb/gcc/results.243837 \
--disable-bootstrap \
--disable-multilib \
--disable-werror \
--enable-checking=gcac \
--enable-languages=c,c++,fortran

In the build, some compilations took over an hour on a 4GHZ
AMD machine. Using ulimit -t 3600 meant the build would not complete.

I checked how many times gcac gets mentioned in this
bug database. To my surprise, only two mentions, so the
gcac checking isn't helping to find bugs very much.

Suggest rework gcac checking option to be fast enough
to be usable. 

Splitting gcac into a fast checker that doesn't check much and 
a full-fat checker that does as much as the current version
might be the way forward.

[Bug target/78807] Loop optimization trigger bus error

[m.gcc.gnu.org at alias dot viem.se]

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

--- Comment #3 from Mauritz Sundell  ---
I did not have access to a Solaris/sparc machine with GCC 6.
But on Linux/sparc test program do not crash compiled with GCC 6.2.0.

$ uname -a
Linux xxx 4.1.12-80.el6uek.sparc64 #1 SMP Wed Nov 30 03:09:10 PST 2016 sparc64
sparc64 sparc64 GNU/Linux 

$ bin/gcc-6.2.0/bin/gcc -m64 -O3 -fPIC -o bug78807 bug78807.c
$ ./bug78807
$

[Bug c++/64194] [C++14] for function template with auto return

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
It is confirmed, and has been since 2014-12-08. If you look at the dropdown
you'll see there is no CONFIRMED status in GCC's bugzilla.

[Bug target/78831] [nvptx] -mgomp -Os init_softstack_frame ICE

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #3 from Alexander Monakov  ---
Fixed.

[Bug target/78831] [nvptx] -mgomp -Os init_softstack_frame ICE

[amonakov at gcc dot gnu.org]

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

--- Comment #2 from Alexander Monakov  ---
Author: amonakov
Date: Wed Dec 21 14:20:09 2016
New Revision: 243855

URL: https://gcc.gnu.org/viewcvs?rev=243855&root=gcc&view=rev
Log:
nvptx: do not assume that crtl->is_leaf is unset

PR target/78831
* config/nvptx/nvptx.c (init_softstack_frame): Remove assert.  Compute
crtl->is_leaf only if unset.  Adjust comment.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c

[Bug rtl-optimization/78883] [avr] ICE triggered by change to combine.c (r243578)

[vogt at linux dot vnet.ibm.com]

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

--- Comment #1 from Dominik Vogt  ---
Can you please attach a combine dump?

[Bug c++/64194] [C++14] for function template with auto return

[lcid-fire at gmx dot net]

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

--- Comment #2 from lcid-fire at gmx dot net ---
Shouldn't the status be confirmed?

[Bug c++/78843] error: 'functionname' was not declared in this scope

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #1)
> are different identifiers, C/C++ is case sensitive.

[Bug c++/78882] std::bind not working with templated function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |RESOLVED
Version|unknown |6.3.0
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
This isn't a problem with std::bind, but converting a function template into a
pointer:

template void bind(F) { }

template 
auto anonymousWrap() {
return T();
};

int main() {
  bind(anonymousWrap);
}

This is a dup of Bug 64194

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

[Bug c++/64194] [C++14] for function template with auto return

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||lcid-fire at gmx dot net

--- Comment #1 from Jonathan Wakely  ---
*** Bug 78882 has been marked as a duplicate of this bug. ***

[Bug testsuite/52641] Test cases fail for 16-bit int targets

[gjl at gcc dot gnu.org]

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

--- Comment #12 from Georg-Johann Lay  ---
Author: gjl
Date: Wed Dec 21 13:50:11 2016
New Revision: 243854

URL: https://gcc.gnu.org/viewcvs?rev=243854&root=gcc&view=rev
Log:
gcc/testsuite/
PR testsuite/52641
* gcc.dg/builtin-object-size-16.c (ia0, ia1, ia9): Handle case
where neither short nor int has a size of 4; use long.
* gcc.dg/builtin-object-size-17.c: Same.
* gcc.dg/builtin-stringop-chk-1.c (test2) : Use int32_t
for components as 4 components are supposed to occupy 16 bytes.
* gcc.dg/pr78408-1.c: Require target size32plus.
* gcc.dg/pr78408-2.c: Same.
* gcc.dg/tree-ssa/pr78428.c. Require target int32plus.
* gcc.dg/tree-ssa/tailcall-7.c: Require target trampolines.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/builtin-object-size-16.c
trunk/gcc/testsuite/gcc.dg/builtin-object-size-17.c
trunk/gcc/testsuite/gcc.dg/builtin-stringop-chk-1.c
trunk/gcc/testsuite/gcc.dg/pr78408-1.c
trunk/gcc/testsuite/gcc.dg/pr78408-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr78428.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/tailcall-7.c

[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
There's no need to determine the addresses, only the truth of the inequality.

The standard says distinct functions have distinct addresses. Yes, linker
trickery can break that, but it's reasonable to rely on it because it's
guaranteed by the standard. Code that cares about addresses of functions
(typically when registering callbacks) is unlikely to care about comparing
addresses of builtins or functions in libgcc, only for user code.

[Bug c++/78826] jump bypasses non-POD

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Jonathan Wakely  ---
(In reply to Krzysztof Laskowski from comment #3)
> (In reply to Jonathan Wakely from comment #2)
> > I assume GCC 4.5 stopped diagnosing it due to the revised specification
> > which only cares about trivial constructor or trivial destructor, not
> > PODness.
> I couldn't actually find any clause allowing jump over trivially constructed
> variable in ISO/IEC 14882:1998 nor ISO/IEC 14882:2003. Moreover, icc (13,
> 16, 17) and clang (3.0-3.9) warn and err, respectively, on example.

I didn't suggest you'd find it in C++03.

> It seems to correlate with introducing c++0x support in gcc.

Yes, obviously. Because the refined rule was introduced for C++11. That's what
I meant by revised specification.

> https://gcc.gnu.org/gcc-4.5/changes.html
> "Diagnostics that used to complain about passing non-POD types to ... or
> jumping past the declaration of a non-POD variable now check for triviality
> rather than PODness, as per C++0x."

So it's even documented as being deliberate, isn't that clear?

> > Giving a diagnostic here would just be pedantic and unhelpful.
> I agree it's harmless to bypass trivially constructed variable. Does it mean
> that it's a deliberate deviation from standard for the sake of ease of c++11
> implementation at the cost of portability/conformance?

No, not for the ease of implementation. For the benefit of users.

I repeat: Giving a diagnostic here would just be pedantic and unhelpful.

The old rule doesn't prevent bugs, it doesn't make code faster, it has no
advantages. The only reason the C++03 rule was in terms of POD was because we
didn't have a better property to use. What matters is whether non-trivial
initialization or destruction gets bypassed, and with modern C++ we are able to
express the rule more precisely.

Jason, do you see any advantage to making this a pedwarn for -std=c++98, or
should we just close as WONTFIX?

[Bug target/78762] Regression: Splitting unaligned AVX loads also when AVX2 is enabled

[venkataramanan.kumar at amd dot com]

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

--- Comment #15 from Venkataramanan  ---
Considering this PR, removing the tuning (splitting of unaligned avx256 loads)
for generic is suggested.

[Bug target/78762] Regression: Splitting unaligned AVX loads also when AVX2 is enabled

[venkataramanan.kumar at amd dot com]

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

--- Comment #14 from Venkataramanan  ---
(In reply to Allan Jensen from comment #13)
> The question is if the unaligned store is still slow on Excavator and Ryzen
> which support AVX2. As far as I understand the bulldozer architectures just
> prefer split AVX because it was basically emulating them with 128-bit
> micro-ops anyway.

I have to benchmark and then comeback on store splitting.

[Bug sanitizer/77963] inconsistent (false?) leaks detection.

[pawel_sikora at zoho dot com]

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

--- Comment #2 from Pawel Sikora  ---
(In reply to Kostya Serebryany from comment #1)
> lsan does not work with ptrace. 
> There is https://github.com/google/sanitizers/issues/728 for it. 
> We don't have plans to fix it, but the change I sent for review yesterday 
> causes lsan to complain loudly instead of producing false reports. 

this change clarify the situation with shiny message but doesn't help to much
in the real development scenario. under gdb/strace session the process will
terminate with exit code 1 and may breaks application flow due to unexpected
exit code of the child process. in such case i need to setup manually for debug
session the ASAN_OPTIONS=detect_leaks=0 to workaround the lsan die(). it would
be better to omit the die() in such case (no ptrace-available).

[Bug libstdc++/71444] Error constants for MinGW-w64

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Fixed on gcc trunk. Assuming no problems show up this is suitable for
backporting to the branches, so I'll leave the bug open for now.

[Bug middle-end/78884] New: ICE when gimplifying VLA in OpenMP SIMD region

[amonakov at gcc dot gnu.org]

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

Bug ID: 78884
   Summary: ICE when gimplifying VLA in OpenMP SIMD region
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

Noticed this ICE when looking at OpenMP gimplification/lowering:

void use(int*);
void f(int n)
{
#pragma omp simd
  for (int i=0; i<1024; i++)
{
  int t[n];
  use(t);
}
}


$ gcc/cc1 -fopenmp t.c

will ICE (segfault) in omp_add_variable() due to NULL DECL_VALUE_EXPR on 't'.

[Bug rtl-optimization/78883] New: [avr] ICE triggered by change to combine.c (r243578)

[gjl at gcc dot gnu.org]

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

Bug ID: 78883
   Summary: [avr] ICE triggered by change to combine.c (r243578)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

r243578 triggers several ICEs in avr-gcc test suite; amongst them:

$ avr-gcc /gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/pr26833.c
-S -O1 -mmcu=avr4 -S -da
/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/pr26833.c: In
function 'yasm_lc3b__parse_insn':
/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/pr26833.c:19:1:
error: insn does not satisfy its constraints:
 }
 ^
(jump_insn 58 98 59 9 (set (pc)
(if_then_else (eq (and:HI (reg:HI 31 r31)
(const_int 1 [0x1]))
(const_int 0 [0]))
(label_ref 70)
(pc)))
"/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/pr26833.c":11 415
{*sbrx_and_branchhi}
 (int_list:REG_BR_PROB 375 (nil))
 -> 70)
/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/pr26833.c:19:1:
internal compiler error: in extract_constrain_insn, at recog.c:2213
0x9840e3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../gcc.gnu.org/trunk/gcc/rtl-error.c:108
0x98410f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../../gcc.gnu.org/trunk/gcc/rtl-error.c:119
0x95b61d extract_constrain_insn(rtx_insn*)
../../../gcc.gnu.org/trunk/gcc/recog.c:2213
0x939b45 reload_cse_simplify_operands
../../../gcc.gnu.org/trunk/gcc/postreload.c:391
0x93a725 reload_cse_simplify
../../../gcc.gnu.org/trunk/gcc/postreload.c:179
0x93a725 reload_cse_regs_1
../../../gcc.gnu.org/trunk/gcc/postreload.c:218
0x93c3ab reload_cse_regs
../../../gcc.gnu.org/trunk/gcc/postreload.c:64
0x93c3ab execute
../../../gcc.gnu.org/trunk/gcc/postreload.c:2342
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
georg@pandora:~/test>

R31 is the last hard reg (8-bit) and must never be allocated to HImode.

GCC configured as:

$ ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-7 --disable-shared --disable-nls --with-dwarf2
--enable-target-optspace=yes --with-gnu-as --with-gnu-ld
--enable-checking=release --enable-languages=c,c++

[Bug libstdc++/71444] Error constants for MinGW-w64

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Wed Dec 21 13:09:13 2016
New Revision: 243853

URL: https://gcc.gnu.org/viewcvs?rev=243853&root=gcc&view=rev
Log:
PR 71444 define more error constants for mingw-w64

PR libstdc++/71444
* config/os/mingw32-w64/error_constants.h
(address_family_not_supported, address_in_use, address_not_available)
(already_connected, connection_aborted, connection_already_in_progress)
connection_refused, connection_reset, cross_device_link)
(destination_address_required, host_unreachable, message_size)
(network_down, network_reset, network_unreachable, no_buffer_space)
(no_protocol_option, not_a_socket, not_connected, operation_canceled)
(operation_in_progress, operation_not_supported, protocol_error)
(protocol_not_supported, too_many_links, too_many_symbolic_link_levels)
(value_too_large, wrong_protocol_type): Define.
(bad_message, identifier_removed, no_link, no_message_available)
(no_message, no_stream_resources, not_a_stream, owner_dead)
(state_not_recoverable, stream_timeout, text_file_busy): Define
conditionally.
* testsuite/19_diagnostics/headers/system_error/errc_std_c++0x.cc:
Guard test for no_message with _GLIBCXX_HAVE_ENOMSG.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/os/mingw32-w64/error_constants.h
   
trunk/libstdc++-v3/testsuite/19_diagnostics/headers/system_error/errc_std_c++0x.cc

[Bug middle-end/78879] -fprofile-generate causes undefined reference to `____ilog2_NaN'

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
(In reply to Yuan Pengfei from comment #5)
> (In reply to Markus Trippelsdorf from comment #3)
> > (In reply to Yuan Pengfei from comment #2)
> > > (In reply to Markus Trippelsdorf from comment #1)
> > > > See discussion in PR72785.
> > > 
> > > I am using GCC 6.2.1. Is it the same problem?
> > 
> > Yes, I think so. The compiler is under no obligation to optimize the
> > ilog2_NaN call away. It looks like a kernel bug.
> 
> I don't think so. In this case, the value of sector_size is constant (256,
> 512, 1024, 2048, 4096) and the ilog2_NaN call can be optimized away.
> 
> It is after enabling the -fprofile-generate option when the compiler thinks
> the ilog2_NaN call can not be optimized away.
> 
> Reference source code:
> http://lxr.free-electrons.com/source/drivers/scsi/sd.c?v=3.10#L2163

Yes, sorry I got that the wrong way round. 

The compiler is under no obligation not to duplicate (optimize) and thereby
produce that ilog2_NaN undefined symbol.

[Bug middle-end/78879] -fprofile-generate causes undefined reference to `____ilog2_NaN'

[coolypf at qq dot com]

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

--- Comment #5 from Yuan Pengfei  ---
(In reply to Markus Trippelsdorf from comment #3)
> (In reply to Yuan Pengfei from comment #2)
> > (In reply to Markus Trippelsdorf from comment #1)
> > > See discussion in PR72785.
> > 
> > I am using GCC 6.2.1. Is it the same problem?
> 
> Yes, I think so. The compiler is under no obligation to optimize the
> ilog2_NaN call away. It looks like a kernel bug.

I don't think so. In this case, the value of sector_size is constant (256, 512,
1024, 2048, 4096) and the ilog2_NaN call can be optimized away.

It is after enabling the -fprofile-generate option when the compiler thinks the
ilog2_NaN call can not be optimized away.

Reference source code:
http://lxr.free-electrons.com/source/drivers/scsi/sd.c?v=3.10#L2163

[Bug c/77767] [5/6/7 Regression] Side-effect from VLA array parameters lost

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec 21 12:52:06 2016
New Revision: 243851

URL: https://gcc.gnu.org/viewcvs?rev=243851&root=gcc&view=rev
Log:
PR c/77767
* c-decl.c (grokdeclarator): If *expr is non-NULL, append expression
to *expr instead of overwriting it.

* gcc.c-torture/execute/pr77767.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.c-torture/execute/pr77767.c
Modified:
branches/gcc-6-branch/gcc/c/ChangeLog
branches/gcc-6-branch/gcc/c/c-decl.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug ipa/77905] [5/6 Regression] ICE at -Os and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in ipa_comdats, at ipa-comdats.c:352)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec 21 12:49:44 2016
New Revision: 243850

URL: https://gcc.gnu.org/viewcvs?rev=243850&root=gcc&view=rev
Log:
Backported from mainline
2016-12-13  Jakub Jelinek  

PR ipa/77905
* ipa-pure-const.c (cdtor_p): Return true for
DECL_STATIC_{CON,DE}STRUCTOR even when it is
DECL_LOOPING_CONST_OR_PURE_P.

* g++.dg/ipa/pr77905.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/ipa/pr77905.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/ipa-pure-const.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/78866] ICE in gimplify_adjust_omp_clauses_1, at gimplify.c:8721

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug target/78762] Regression: Splitting unaligned AVX loads also when AVX2 is enabled

[linux at carewolf dot com]

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

--- Comment #13 from Allan Jensen  ---
The question is if the unaligned store is still slow on Excavator and Ryzen
which support AVX2. As far as I understand the bulldozer architectures just
prefer split AVX because it was basically emulating them with 128-bit micro-ops
anyway.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[janus at gcc dot gnu.org]

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

--- Comment #1 from janus at gcc dot gnu.org ---
It seems that this problem not only appears when reading from internal units,
but also from std input:



module t_m
   implicit none

   type, public :: t
  character(len=:), allocatable :: m_s
   contains
  procedure, pass(this) :: read_t
  generic :: read(formatted) => read_t
   end type

contains

subroutine read_t(this, lun, iotype, vlist, istat, imsg)
  ! argument definitions
  class(t), intent(inout) :: this
  integer, intent(in) :: lun
  character(len=*), intent(in):: iotype
  integer, intent(in) :: vlist(:)
  integer, intent(out):: istat
  character(len=*), intent(inout) :: imsg
  ! local variables
  character :: c
  integer :: i

  do i=1,5
 read( unit=lun, fmt="(a1)", iostat=istat, iomsg=imsg ) c
 select case ( istat )
case ( 0 )
   write( *, *) "i = ", i, ", c = ", c
case default
   write( *, *) "i = ", i, ", istat = ", istat, imsg
   return
 end select
  end do

   end subroutine

end module


program p
   use t_m
   implicit none

!character(len=5) :: s = "Hello"
   type(t) :: foo

   read( unit=*, fmt=*) foo
end

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[trippels at gcc dot gnu.org]

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

--- Comment #22 from Markus Trippelsdorf  ---
(In reply to dhowe...@redhat.com from comment #21)
> (In reply to Markus Trippelsdorf from comment #20)
> > *** Bug 78879 has been marked as a duplicate of this bug. ***
> 
> Kernel bug or not, it should be noted that this means that you cannot use
> gcc from r236831 to compile any kernel from the introduction and use of
> ilog2() to the current day - and these kernel versions cannot be
> retroactively fixed.

No. I build allmodconfig kernels regularly with gcc trunk and it works fine.