[Bug tree-optimization/71893] ['7 Regression] gfortran.dg ICEs in gcc/tree-ssa-pre.c; -fcode-hoisting?

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization
   Target Milestone|--- |7.0
Summary|gfortran.dg ICEs in |['7 Regression] gfortran.dg
   |gcc/tree-ssa-pre.c; |ICEs in gcc/tree-ssa-pre.c;
   |-fcode-hoisting?|-fcode-hoisting?

[Bug fortran/71764] [4.9/5/6/7 Regression] ICE in gfc_trans_structure_assign

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Jul 16 05:10:10 2016
New Revision: 238411

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

Backport from trunk:
PR fortran/71764
* trans-expr.c (gfc_trans_structure_assign): Remove assert.

* gfortran.dg/pr71764.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr71764.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/71764] [4.9/5/6/7 Regression] ICE in gfc_trans_structure_assign

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Jul 16 03:54:12 2016
New Revision: 238410

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

Backport from trunk:
PR fortran/71764
* trans-expr.c (gfc_trans_structure_assign): Remove assert.

* gfortran.dg/pr71764.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr71764.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/trans-expr.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c/57853] pointer arithmetic on arrays

[brodhow at sbcglobal dot net]

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

--- Comment #17 from this is me  ---
Its simpler than what Andrew was describing! It is simply incrementing by 1
character datatype width to the next character with "++".

[Bug libstdc++/71899] An internal BooleanTestable trait should be provided

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/71900] Final keyword does not work as intended.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
This is already fixed in GCC 4.9.3

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

[Bug c++/64901] [4.9/5 Regression] overriding final function defined out of line does not lead to an error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||pavan.narasimhaprasad@hughe
   ||s.com

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

[Bug c++/71900] Final keyword does not work as intended.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Works correctly in GCC 6.1.0 release.

[Bug c++/71900] New: Final keyword does not work as intended.

[pavan.narasimhaprasad at hughes dot com]

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

Bug ID: 71900
   Summary: Final keyword does not work as intended.
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pavan.narasimhaprasad at hughes dot com
  Target Milestone: ---

Created attachment 38914
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38914=edit
override_error.cpp

File: override_error.cpp


When a virtual method print() in Class A is declared as final and when
inherited in the Class B, overriding this method is not generating a
compilation error. 


g++ -std=c++11 override_error.cpp


File: overrride.cpp

When virtual method print() in Class A is defined within the class and when
inherited in the Class B, overriding this method is  generating a compilation
error as expected.

g++ -std=c++11 override.cpp
verride.cpp:29:15: error: virtual function 'virtual void B::printVal()'
 void  printVal() override;
   ^
override.cpp:13:22: error: overriding final function 'virtual void
A::printVal()'
 virtual void printVal() final

[Bug tree-optimization/71702] dr_group_sort_cmp violates transitivity required for qsort

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #4 from David Edelsohn  ---
New.

[Bug c++/71896] [6/7 Regression] Constexpr function with pointer to member parameter doesn't return constexpr value

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-15
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |6.2
Summary|Constexpr function with |[6/7 Regression] Constexpr
   |pointer to member parameter |function with pointer to
   |doesn't return constexpr|member parameter doesn't
   |value   |return constexpr value
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r229018.

[Bug libstdc++/71899] New: An internal BooleanTestable trait should be provided

[daniel.kruegler at googlemail dot com]

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

Bug ID: 71899
   Summary: An internal BooleanTestable trait should be provided
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.kruegler at googlemail dot com
  Target Milestone: ---

I suggest to provide an internal type trait that corresponds to the currently
discussed BooleanTestable requirement set as described in LWG 2743:

http://cplusplus.github.io/LWG/lwg-active.html#2743

This trait could be used in SFINAE-constraints such as for the recently added
comparison functions of std::optional or as argument of static_assert for the
existing comparison functions of std::tuple and possibly other places as well.

In the absence of any better name, I suggest to introduce a type trait named
__is_boolean_testable in header .

Given that LWG 2743 is not resolved yet, I recommend to start with a very weak
set of requirements for some type T, e.g. the logical AND of

std::is_convertible::value
std::is_constructible::value

I'm willing to provide this contribution.

[Bug fortran/71686] ICE on broken character continuation

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #5 from Jerry DeLisle  ---
Fixed, closing

[Bug c++/71896] Constexpr function with pointer to member parameter doesn't return constexpr value

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
That looks like a regression to me: It worked from gcc 4.6.4 on until gcc 5.3.0
and does no longer work in gcc 6.1.0 or in gcc HEAD 7.0.0.

[Bug fortran/62125] Nested select type not accepted (rejects valid)

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #11 from Jerry DeLisle  ---
Fixed on trunk, closing.

[Bug fortran/62125] Nested select type not accepted (rejects valid)

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Jul 15 19:58:55 2016
New Revision: 238400

URL: https://gcc.gnu.org/viewcvs?rev=238400=gcc=rev
Log:
2016-07-15  Jerry DeLisle  
Marco Restelli 

PR fortran/62125
* symbol.c (select_type_insert_tmp): Recursively call self to take care
of nested select type.

* gfortran.dg/pr62125.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr62125.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/71886] Incorrect error on operator() being an member in template

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  ---
(In reply to Ville Voutilainen from comment #2)
> Clang also rejects the template.

And Visual Studio 2015 rejects the template also.

[Bug middle-end/71898] New: [7 Regression] [graphite] ICE: verify_ssa failed

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 71898
   Summary: [7 Regression] [graphite] ICE: verify_ssa failed
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

The following started regressing roughly July 7th/8th:

> cat bug.f90
MODULE d3_poly
INTEGER, PUBLIC, PARAMETER :: max_grad2=5
INTEGER, PUBLIC, PARAMETER :: max_grad3=3
INTEGER, PUBLIC, PARAMETER :: cached_dim2=(max_grad2+1)*(max_grad2+2)/2
INTEGER, PUBLIC, PARAMETER ::
cached_dim3=(max_grad3+1)*(max_grad3+2)*(max_grad3+3)/6
INTEGER, SAVE, DIMENSION(3,cached_dim3) :: a_mono_exp3
INTEGER, SAVE, DIMENSION(cached_dim2,cached_dim2) :: a_mono_mult2
INTEGER, SAVE, DIMENSION(cached_dim3,cached_dim3) :: a_mono_mult3
INTEGER, SAVE, DIMENSION(4,cached_dim3) :: a_mono_mult3a
CONTAINS
SUBROUTINE init_d3_poly_module()
INTEGER  :: grad, i, ii, ij, j, subG
INTEGER, DIMENSION(3):: monoRes3
DO grad=0,max_grad2
DO i=grad,0,-1
DO j=grad-i,0,-1
END DO
END DO
END DO
DO ii=1,cached_dim3
DO ij=ii,cached_dim2
a_mono_mult2(ij,ii)=a_mono_mult2(ii,ij)
END DO
END DO
DO ii=1,cached_dim3
DO ij=ii,cached_dim3
monoRes3=a_mono_exp3(:,ii)+a_mono_exp3(:,ij)
   
a_mono_mult3(ii,ij)=mono_index3(monoRes3(1),monoRes3(2),monoRes3(3))+1
a_mono_mult3(ij,ii)=a_mono_mult3(ii,ij)
END DO
END DO
DO i=1,cached_dim3
   DO j=1,4
  a_mono_mult3a(j,i)=a_mono_mult3(j,i)
   END DO
END DO
END SUBROUTINE
PURE FUNCTION mono_index3(i,j,k) RESULT(res)
INTEGER, INTENT(in)  :: i, j, k
res=grad*(grad+1)*(grad+2)/6+(sgrad)*(sgrad+1)/2+k
END FUNCTION
END MODULE d3_poly

> gfortran -c -floop-nest-optimize -O1 bug.f90
bug.f90:11:0:

 SUBROUTINE init_d3_poly_module()

Error: definition in block 74 follows the use
for SSA_NAME: _56 in statement:
_104 = _56 + graphite_IV.7_99;
bug.f90:11:0: internal compiler error: verify_ssa failed
0xdd4efc verify_ssa(bool, bool)
../../gcc/gcc/tree-ssa.c:1039
0xd24a41 verify_loop_closed_ssa(bool)
../../gcc/gcc/tree-ssa-loop-manip.c:736
0x131afa9 checking_verify_loop_closed_ssa
../../gcc/gcc/tree-ssa-loop-manip.h:35
0x131afa9 graphite_verify
../../gcc/gcc/graphite-isl-ast-to-gimple.c:98
0x131afa9 graphite_regenerate_ast_isl(scop*)
../../gcc/gcc/graphite-isl-ast-to-gimple.c:3205
0x13124c3 graphite_transform_loops()
../../gcc/gcc/graphite.c:329
0x1312990 graphite_transforms
../../gcc/gcc/graphite.c:356
0x1312990 execute
../../gcc/gcc/graphite.c:433
Please submit a full bug report,

[Bug c++/58796] throw nullptr not caught by catch(type*)

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  ---
With GCC 7 from svn trunk the original test case now prints:

About to 'throw nullptr' (first case)
Caught 'throw nullptr' as type 'int A::*PointerToMember'
About to 'throw nullptr' (second case)
Caught 'throw nullptr' as type 'void *'
About to 'throw nullptr' (last case)
Caught 'throw nullptr' as type 'int A::*PointerToMember'

And all the caught pointers are null.

Not all cases work though, nullptr cannot be caught as a pointer to member
function, and fixing that is difficult, so I'm keeping this open.

[Bug driver/71897] crashed on querying help information from command line

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I think I fixed this for GCC 7.

[Bug c++/71495] [6/7 Regression] Spurious "note: initializing argument ... of ..." without any warning/error

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Jul 15 18:56:29 2016
New Revision: 238397

URL: https://gcc.gnu.org/viewcvs?rev=238397=gcc=rev
Log:
PR c++/71495 - spurious note during SFINAE.

* call.c (convert_like_real): Mask complain.
* semantics.c (perform_koenig_lookup): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae57.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/semantics.c

[Bug c++/58796] throw nullptr not caught by catch(type*)

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
Author: redi
Date: Fri Jul 15 18:51:51 2016
New Revision: 238396

URL: https://gcc.gnu.org/viewcvs?rev=238396=gcc=rev
Log:
c++/58796 Make nullptr match exception handlers of pointer type

libstdc++-v3:

PR c++/58796
* libsupc++/pbase_type_info.cc (__pbase_type_info::__do_catch): Make
nullptr match handlers of pointer type.

gcc/testsuite:

PR c++/58796
* g++.dg/cpp0x/nullptr21.C: Remove void* handlers.
* g++.dg/cpp0x/nullptr35.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/nullptr35.C
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/nullptr21.C
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/libsupc++/pbase_type_info.cc

[Bug c++/71092] [6/7 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1449; only with -Os

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Fri Jul 15 18:49:38 2016
New Revision: 238395

URL: https://gcc.gnu.org/viewcvs?rev=238395=gcc=rev
Log:
PR c++/71092 - ICE with array and constexpr.

* constexpr.c (cxx_eval_call_expression): Fail quietly when cgraph
threw away DECL_SAVED_TREE.

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

[Bug c++/71117] [6/7 Regression] Overeager application of conversion to function pointer during overload resolution of call to function object

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Jul 15 18:49:25 2016
New Revision: 238394

URL: https://gcc.gnu.org/viewcvs?rev=238394=gcc=rev
Log:
PR c++/71117 - core 2189 and generic lambda

* call.c (add_template_conv_candidate): Disable if there are
viable candidates.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-conv2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/g++.dg/cpp0x/conv-tmpl1.C

[Bug c++/71814] [6/7 Regression] ICE on valid C++11 code: in write_type, at cp/mangle.c:2158

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Fri Jul 15 18:38:15 2016
New Revision: 238389

URL: https://gcc.gnu.org/viewcvs?rev=238389=gcc=rev
Log:
PR c++/71814 - mangling sizeof... (sP and sZ)

gcc/cp/
* mangle.c (write_expression): Handle sizeof... an argument pack.
libiberty/
* cp-demangle.c (cplus_demangle_operators): Add sP and sZ.
(d_print_comp_inner): Handle them.
(d_template_args_1): Split out from d_template_args.
(d_args_length): New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-mangle1.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-mangle1a.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-mangle2.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-mangle2a.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-mangle3.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-mangle3a.C
Modified:
trunk/gcc/common.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/mangle.c
trunk/libiberty/ChangeLog
trunk/libiberty/cp-demangle.c
trunk/libiberty/testsuite/demangle-expected

[Bug c++/70824] [6/7 Regression] cc1plus consumes all available memory on specific template code

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Fri Jul 15 18:37:48 2016
New Revision: 238386

URL: https://gcc.gnu.org/viewcvs?rev=238386=gcc=rev
Log:
PR c++/70824 - initializer_list in template

* init.c (constant_value_1): Don't instantiated DECL_INITIAL of
artificial variables.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-template1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c

[Bug c++/71718] [6/7 Regression] ICE on erroneous recursive template error printing

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Fri Jul 15 18:37:56 2016
New Revision: 238387

URL: https://gcc.gnu.org/viewcvs?rev=238387=gcc=rev
Log:
PR c++/71718 - infinite recursion and alias template

* pt.c (push_tinst_level_loc): Set at_eof before fatal_error.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-55.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/71511] [6/7 Regression] ICE on valid C++11 code (with decltype) on x86_64-linux-gnu: in cxx_incomplete_type_diagnostic, at cp/typeck2.c:567

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Jul 15 18:38:48 2016
New Revision: 238393

URL: https://gcc.gnu.org/viewcvs?rev=238393=gcc=rev
Log:
PR c++/71511 - ICE on decltype scope in declaration.

* typeck2.c (cxx_incomplete_type_diagnostic): Handle DECLTYPE_TYPE.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype65.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck2.c

[Bug c++/54430] [C++11] For-Loop: Scope of iterating variable begins too early

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill  ---
Author: jason
Date: Fri Jul 15 18:38:31 2016
New Revision: 238391

URL: https://gcc.gnu.org/viewcvs?rev=238391=gcc=rev
Log:
PR c++/71604 - type definition in range-based for

PR c++/54430
* parser.c (cp_parser_range_for): Modify IDENTIFIER_BINDING directly.
(cp_parser_simple_declaration): Diagnose type definition in
for-range-declaration.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/range-for31.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/g++.dg/cpp0x/range-for8.C

[Bug c++/71513] [6/7 Regression] ICE on valid C++11 code (with alignas specifier) on x86_64-linux-gnu: Segmentation fault

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Fri Jul 15 18:38:40 2016
New Revision: 238392

URL: https://gcc.gnu.org/viewcvs?rev=238392=gcc=rev
Log:
PR c++/71513 - alignas on member enum in template

* pt.c (tsubst_attributes): Fix loop logic.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alignas7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/71711] [6/7 Regression] ICE on valid C++1z code with fold expression: tree check: expected tree_vec, have expr_pack_expansion in tsubst_unary_left_fold, at cp/pt.c:10792

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Fri Jul 15 18:38:23 2016
New Revision: 238390

URL: https://gcc.gnu.org/viewcvs?rev=238390=gcc=rev
Log:
PR c++/71711 - mangle C++1z fold-expressions.

* operators.def: Add *_FOLD_EXPR.
* cp-tree.h (FOLD_EXPR_P): Parenthesize.
* mangle.c (write_expression): Handle fold-expressions.
* pt.c (tsubst_unary_left_fold, tsubst_binary_left_fold)
(tsubst_unary_right_fold, tsubst_binary_right_fold): Handle
partial instantiation.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/fold-mangle.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/mangle.c
trunk/gcc/cp/operators.def
trunk/gcc/cp/pt.c

[Bug c++/71604] [6/7 Regression] ICE on valid C++11 code with range-based for loop: in pop_binding, at cp/name-lookup.c:376

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Fri Jul 15 18:38:31 2016
New Revision: 238391

URL: https://gcc.gnu.org/viewcvs?rev=238391=gcc=rev
Log:
PR c++/71604 - type definition in range-based for

PR c++/54430
* parser.c (cp_parser_range_for): Modify IDENTIFIER_BINDING directly.
(cp_parser_simple_declaration): Diagnose type definition in
for-range-declaration.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/range-for31.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/g++.dg/cpp0x/range-for8.C

[Bug c/71897] New: crashed on querying help information from command line

[thomas.br...@virtuell-zuhause.de]

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

Bug ID: 71897
   Summary: crashed on querying help information from command line
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.br...@virtuell-zuhause.de
  Target Milestone: ---

GCC told me to come here.

$/rest/inst/gcc-6.1.0/usr/local/bin/gcc --help=^
cc1: internal compiler error: Speicherzugriffsfehler
0x9c70ff crash_signal
../../gcc/toplev.c:333
0x1008c00 common_handle_option(gcc_options*, gcc_options*, cl_decoded_option
const*, unsigned int, int, unsigned int, cl_option_handlers const*,
diagnostic_context*)
../../gcc/opts.c:1615
0x100c457 handle_option
../../gcc/opts-common.c:981
0x100c586 read_cmdline_option(gcc_options*, gcc_options*, cl_decoded_option*,
unsigned int, unsigned int, cl_option_handlers const*, diagnostic_context*)
../../gcc/opts-common.c:1180
0x9157a7 read_cmdline_options
../../gcc/opts-global.c:229
0x9157a7 decode_options(gcc_options*, gcc_options*, cl_decoded_option*,
unsigned int, unsigned int, diagnostic_context*)
../../gcc/opts-global.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$/rest/inst/gcc-6.1.0/usr/local/bin/gcc --version
gcc (GCC) 6.1.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug fortran/71891] fortran/symbol.c:4864: suspicious if ?

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to David Binderman from comment #1)
> According to svn blame, kargl is the author of this line of code.
> 
> Adding them in.


Please, do not my email address to any bug report.

[Bug c++/71892] Recent optimization changes introduce bugs

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Both examples you give are undefined behaviour according to the C++ standard.
You can claim the code is valid, but that doesn't make it true.

You seem to be confusing "it worked OK until now" with "this code is valid
according to the language standard".

[Bug c++/71896] New: Constexpr function with pointer to member parameter doesn't return constexpr value

[raphael.kargon at gmail dot com]

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

Bug ID: 71896
   Summary: Constexpr function with pointer to member parameter
doesn't return constexpr value
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raphael.kargon at gmail dot com
  Target Milestone: ---

Created attachment 38913
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38913=edit
Preprocessed source that produces this error.

The following code fails to compile in gcc 6.1.0, but compiles successfully in
clang:
```
#include 

struct Foo {
  int x;
};

constexpr bool compare(int Foo::*t) { return t == ::x; }

int main(int, char **) {
  // GCC will fail here, "(::x == 0) is not a constant expression"
  constexpr bool b = compare(::x);
  return b ? 0 : 1;
}
```

The compiler output is:
constexpr-test.cpp: In function 'int main(int, char**)':
constexpr-test.cpp:11:29:   in constexpr expansion of 'compare(::x)'
constexpr-test.cpp:7:48: error: '(::x == 0)' is not a constant expression
 constexpr bool compare(int Foo::*t) { return t == ::x; }

The commands used to compile are:
gcc-6 --std=c++14 --save-temps -Wall -Wextra constexpr-test.cpp -o
constexpr-test
clang --std=c++14 --save-temps -Wall -Wextra constexpr-test.cpp -o
constexpr-test 

Preprocessed source is attached. 

Output of "gcc-6 --version":

Using built-in specs.
COLLECT_GCC=gcc-6
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/6.1.0/libexec/gcc/x86_64-apple-darwin15.5.0/6.1.0/lto-wrapper
Target: x86_64-apple-darwin15.5.0
Configured with: ../configure --build=x86_64-apple-darwin15.5.0
--prefix=/usr/local/Cellar/gcc/6.1.0
--libdir=/usr/local/Cellar/gcc/6.1.0/lib/gcc/6
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-6
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking
--enable-checking=release --enable-lto --with-build-config=bootstrap-debug
--disable-werror --with-pkgversion='Homebrew gcc 6.1.0'
--with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin
--disable-nls --enable-multilib
Thread model: posix
gcc version 6.1.0 (Homebrew gcc 6.1.0)

[Bug target/71889] [MIPS] python: "insn does not satisfy its constraints"

[kabel at blackhole dot sk]

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

--- Comment #3 from Marek Behun  ---
> Enabling optimizations without any -O is a no-op so you effectively tested
> -O0.

So even if I use all the -f flags, without any -O, they are not turned on? So
if I want for example just to turn on half of the -O1 flags, I jave to use -O1
and -fno-* for all the -O1 flags that I don't want?

> What GCC version was able to compile the file?

4.9.3 compiled Python successfuly.

[Bug middle-end/50060] intrinsics not folded by the middle-end

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 38912
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38912=edit
gcc7-pr50060.patch

Untested patch (for -std=c++14 and later only).

[Bug fortran/71895] ICE in gfc_compare_derived_types, at fortran/interface.c:520

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0).

[Bug fortran/71894] ICE in gfc_add_component_ref, at fortran/class.c:227

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk.

[Bug fortran/71895] New: ICE in gfc_compare_derived_types, at fortran/interface.c:520

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

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

Bug ID: 71895
   Summary: ICE in gfc_compare_derived_types, at
fortran/interface.c:520
   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: ---

Eventually cross-linked with pr71862, pr71894 :


$ cat z1.f90
program p
   type t
  integer :: n
   end type
   type(t) :: x
   class(t) :: y
   print *, extends_type_of(x, y)
   print *, extends_type_of(y, x)
end


$ gfortran-6 z1.f90# release
z1.f90:6:16:

class(t) :: y
1
Error: CLASS variable 'y' at (1) must be dummy, allocatable or pointer
(null):0: confused by earlier errors, bailing out


$ gfortran-7-20160710 z1.f90   # eperimental
z1.f90:6:16:

class(t) :: y
1
Error: CLASS variable 'y' at (1) must be dummy, allocatable or pointer
f951: internal compiler error: in gfc_compare_derived_types, at
fortran/interface.c:520
0x68db69 gfc_compare_derived_types(gfc_symbol*, gfc_symbol*)
../../gcc/fortran/interface.c:520
0x70b3da gfc_type_is_extension_of(gfc_symbol*, gfc_symbol*)
../../gcc/fortran/symbol.c:4832
0x6fcabb gfc_simplify_extends_type_of(gfc_expr*, gfc_expr*)
../../gcc/fortran/simplify.c:2384
0x694cb9 do_simplify
../../gcc/fortran/intrinsic.c:4150
0x69e60c gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.c:4506
0x6e3e66 resolve_unknown_f
../../gcc/fortran/resolve.c:2718
0x6e3e66 resolve_function
../../gcc/fortran/resolve.c:3020
0x6e3e66 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6353
0x6e8a91 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10469
0x6e87eb gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:9520
0x6e8b9e gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10459
0x6eb272 resolve_codes
../../gcc/fortran/resolve.c:15667
0x6eb361 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15701
0x6d668a resolve_all_program_units
../../gcc/fortran/parse.c:5853
0x6d668a gfc_parse_file()
../../gcc/fortran/parse.c:6105
0x718d12 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/71894] ICE in gfc_add_component_ref, at fortran/class.c:227

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

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

--- Comment #1 from Gerhard Steinmetz  
---
A variation :

$ cat za1.f90
program p
   type t
   end type
   class(t) :: x
   class(t), allocatable :: y
   select type (y)
   type is (t)
  y = x
   end select
end

[Bug fortran/71894] New: ICE in gfc_add_component_ref, at fortran/class.c:227

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

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

Bug ID: 71894
   Summary: ICE in gfc_add_component_ref, at fortran/class.c:227
   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: ---

Should also been taken into account, in addition to pr71862 :


$ cat z1.f90
program p
   type t
  integer :: n
   end type
   type(t) :: x
   class(t) :: y
   x = y
end


$ gfortran-6 z1.f90# release
z1.f90:6:16:

class(t) :: y
1
Error: CLASS variable 'y' at (1) must be dummy, allocatable or pointer
(null):0: confused by earlier errors, bailing out


$ gfortran-7-20160710 z1.f90   # eperimental
z1.f90:6:16:

class(t) :: y
1
Error: CLASS variable 'y' at (1) must be dummy, allocatable or pointer
f951: internal compiler error: Segmentation fault
0xc0f1ff crash_signal
../../gcc/toplev.c:335
0x66ab51 gfc_add_component_ref(gfc_expr*, char const*)
../../gcc/fortran/class.c:227
0x6ead24 resolve_ordinary_assign
../../gcc/fortran/resolve.c:9751
0x6ead24 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10570
0x6eb272 resolve_codes
../../gcc/fortran/resolve.c:15667
0x6eb361 gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15701
0x6d668a resolve_all_program_units
../../gcc/fortran/parse.c:5853
0x6d668a gfc_parse_file()
../../gcc/fortran/parse.c:6105
0x718d12 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/71862] [4.9/5/6/7 Regression] ICE in gfc_add_component_ref, at fortran/class.c:241

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

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

--- Comment #5 from Gerhard Steinmetz  
---
More test files :


$ cat z5.f90
program p
   type t
  integer :: n = 0
  integer, pointer :: q => null()
   end type
   type(t) :: x
   print *, associated(x%q)
   x = f()
   print *, associated(x%q)
contains
   function f() result (z)
  class(t), allocatable :: z
  print *, associated(z%q)
   end
end


$ cat za1.f90
program p
   class(*), allocatable :: z(:)
   allocate (integer :: z(2))
   select type (z)
   type is (integer)
   end select
end

[Bug tree-optimization/71872] [7 Regression] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant

[gary at intrepid dot com]

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

--- Comment #10 from Gary Funck  ---
Thanks.  Works for me.

[Bug target/71874] [4.9 Regression] memmove works wrong

[sudakov_ivan at mail dot ru]

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

--- Comment #3 from Ivan  ---
It works wrong only for overlapped memory blocks?

[Bug tree-optimization/71881] [4.9/6 Regression] ICE on valid code at -O3 with -g enabled on x86_64-linux-gnu: cannot update SSA form

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[4.9/6/7 Regression] ICE on |[4.9/6 Regression] ICE on
   |valid code at -O3 with -g   |valid code at -O3 with -g
   |enabled on  |enabled on
   |x86_64-linux-gnu: cannot|x86_64-linux-gnu: cannot
   |update SSA form |update SSA form

--- Comment #9 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/71881] [4.9/6/7 Regression] ICE on valid code at -O3 with -g enabled on x86_64-linux-gnu: cannot update SSA form

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Fri Jul 15 13:05:56 2016
New Revision: 238374

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

PR tree-optimization/71881
* tree-loop-distribution.c (destroy_loop): Remove blocks in
reverse DOM order to make debug temp generation happy.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr71881.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-loop-distribution.c

[Bug tree-optimization/71887] [7 Regression] wrong code (SIGFPE) at -O1 and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Component|rtl-optimization|tree-optimization
 Resolution|--- |FIXED

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

[Bug tree-optimization/71887] [7 Regression] wrong code (SIGFPE) at -O1 and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Fri Jul 15 12:56:17 2016
New Revision: 238373

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

PR tree-optimization/71887
* tree-ssa-phiopt.c (absorbing_element_p): Add rhs arg and
verify it is not zero for division / modulo handling.
(value_replacement): Adjust.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr71887.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiopt.c

[Bug fortran/71861] [4.9/5/6/7 Regression] ICE in write_symbol(): bad module symbol

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
Likely caused by r197053.

[Bug middle-end/71893] gfortran.dg ICEs in gcc/tree-ssa-pre.c; -fcode-hoisting?

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Index: gcc/tree-ssa-sccvn.c
===
*** gcc/tree-ssa-sccvn.c(revision 238370)
--- gcc/tree-ssa-sccvn.c(working copy)
*** copy_reference_ops_from_ref (tree ref, v
*** 810,815 
--- 810,818 
  /* Always record lower bounds and element size.  */
  temp.op1 = array_ref_low_bound (ref);
  temp.op2 = array_ref_element_size (ref);
+ /* array_ref_element_size forces the result to sizetype
+even if that is the same as bitsizetype.  */
+ STRIP_USELESS_TYPE_CONVERSION (temp.op2);
  if (TREE_CODE (temp.op0) == INTEGER_CST
  && TREE_CODE (temp.op1) == INTEGER_CST
  && TREE_CODE (temp.op2) == INTEGER_CST)

[Bug middle-end/71893] gfortran.dg ICEs in gcc/tree-ssa-pre.c; -fcode-hoisting?

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Value numbering _5 stmt = _5 = (bitsizetype) _4;
Setting value number of _5 to _5 (changed)
...
Value numbering _74 stmt = _74 = (sizetype) _6;
Match-and-simplified (sizetype) _6 to _5
RHS (sizetype) _6 simplified to _5
Setting value number of _74 to _5 (changed)

so it seems sizetype and bitsizetype are actually the same.

Indeed:

(gdb) p sizetype_tab[stk_sizetype]
$1 = (tree_node *) 0x7688c0a8
(gdb) p sizetype_tab[stk_bitsizetype]
$2 = (tree_node *) 0x7688c150
(gdb) p debug_tree ($1)
  constant 64>
unit size  constant 8>
align 64 symtab 0 alias set -1 canonical type 0x7688c0a8 precision 64
min  max >
$3 = void
(gdb) p debug_tree ($2)
  constant 64>
unit size  constant 8>
align 64 symtab 0 alias set -1 canonical type 0x7688c150 precision 64
min  max >
$4 = void


and array_ref_element_size even notices this:

  /* If a size was specified in the ARRAY_REF, it's the size measured
 in alignment units of the element type.  So multiply by that value.  */
  if (aligned_size)
{
  /* ??? tree_ssa_useless_type_conversion will eliminate casts to
 sizetype from another type of the same width and signedness.  */
  if (TREE_TYPE (aligned_size) != sizetype)
aligned_size = fold_convert_loc (loc, sizetype, aligned_size);
  return size_binop_loc (loc, MULT_EXPR, aligned_size,
 size_int (TYPE_ALIGN_UNIT (elmt_type)));

because otherwise size_binop would complain.

I'll fixup in VN/PRE.

[Bug fortran/71623] [5/6/7 Regression] Segfault when allocating deferred-length characters to size of a pointer

[vehre at gcc dot gnu.org]

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

--- Comment #10 from vehre at gcc dot gnu.org ---
Waiting one week for regression reports before closing.

[Bug fortran/70842] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer

[vehre at gcc dot gnu.org]

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

--- Comment #11 from vehre at gcc dot gnu.org ---
Waiting one week for regression reports before applying to gcc-*-branches.

[Bug fortran/71807] [5/6/7 Regression] Internal compiler error with NULL() reference in structure constructor

[vehre at gcc dot gnu.org]

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Waiting one week for regression reports before applying to gcc-*-branches.

[Bug middle-end/71893] gfortran.dg ICEs in gcc/tree-ssa-pre.c; -fcode-hoisting?

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I can reproduce it but get_or_alloc_expr_for must not fail (I see its
implementation can).

Ok, and I see it comes here via

#2  0x0102e258 in create_component_ref_by_pieces_1 (
block=, ref=0x1d15800, 
operand=0x7fffd39c, stmts=0x7fffd5e0)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:2590
2590genop3 = find_or_generate_expression (block, genop3,
stmts);
(gdb) l
2585  genop3 = NULL_TREE;
2586else
2587  {
2588genop3 = size_binop (EXACT_DIV_EXPR, genop3,
2589 size_int (TYPE_ALIGN_UNIT
(elmt_type)));
2590genop3 = find_or_generate_expression (block, genop3,
stmts);
2591if (!genop3)
2592  return NULL_TREE;

We have

MEM[(character(kind=1)[2][1:D.904] *)_36][0]{lb: 0 sz: (sizetype) _3}

which has bitsizetype sz: but should have sizetype.  This is the
thing confusing stuff here I think.

This seems to be introduced during early FRE.

[Bug tree-optimization/71872] [7 Regression] ICE in inchash::add_expr, at tree.c:7782 - OEP_ADDRESS_OF asserted for ADDR_EXPR applied to constant

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/71893] New: gfortran.dg ICEs in gcc/tree-ssa-pre.c; -fcode-hoisting?

[tschwinge at gcc dot gnu.org]

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

Bug ID: 71893
   Summary: gfortran.dg ICEs in gcc/tree-ssa-pre.c;
-fcode-hoisting?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org, steven at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

Testing gfortran.dg for nvptx-none on r238326, there are a number of ICEs in
gcc/tree-ssa-pre.c.  I reproduced "gfortran.dg/bounds_check_10.f90 -O2"
manually, and the ICE disappears when reverting r238242, or when specifying
-fno-code-hoisting.  (Of course, it may be a latent issue, just now exposed by
-fcode-hoisting.)

Program received signal SIGSEGV, Segmentation fault.
0x00cfcb6e in get_expr_value_id (expr=expr@entry=0x0) at
[...]/source-gcc/gcc/tree-ssa-pre.c:682
682   switch (expr->kind)
(gdb) bt
#0  0x00cfcb6e in get_expr_value_id (expr=expr@entry=0x0) at
[...]/source-gcc/gcc/tree-ssa-pre.c:682
#1  0x00d058a2 in find_or_generate_expression
(block=block@entry=0x768f2680, op=op@entry=0x7697f3a0,
stmts=stmts@entry=0x7fffca70) at [...]/source-gcc/gcc/tree-ssa-pre.c:2672
#2  0x00d06454 in create_component_ref_by_pieces_1
(block=block@entry=0x768f2680, ref=ref@entry=0x17ef190,
operand=operand@entry=0x7fffc82c, stmts=stmts@entry=0x7fffca70) at
[...]/source-gcc/gcc/tree-ssa-pre.c:2590
#3  0x00d06190 in create_component_ref_by_pieces_1
(block=block@entry=0x768f2680, ref=ref@entry=0x17ef190,
operand=operand@entry=0x7fffc82c, stmts=stmts@entry=0x7fffca70) at
[...]/source-gcc/gcc/tree-ssa-pre.c:2556
#4  0x00d05f42 in create_component_ref_by_pieces_1
(block=block@entry=0x768f2680, ref=ref@entry=0x17ef190,
operand=operand@entry=0x7fffc82c, stmts=stmts@entry=0x7fffca70) at
[...]/source-gcc/gcc/tree-ssa-pre.c:2514
#5  0x00d06647 in create_component_ref_by_pieces
(block=block@entry=0x768f2680, ref=0x17ef190,
stmts=stmts@entry=0x7fffca70) at [...]/source-gcc/gcc/tree-ssa-pre.c:2657
#6  0x00d06a45 in create_expression_by_pieces
(block=block@entry=0x768f2680, expr=0x190a088,
stmts=stmts@entry=0x7fffca70, type=0x768e2b28) at
[...]/source-gcc/gcc/tree-ssa-pre.c:2799
#7  0x00d08483 in do_hoist_insertion
(block=block@entry=0x768f2680) at [...]/source-gcc/gcc/tree-ssa-pre.c:3541
#8  0x00d0b54e in insert_aux (block=block@entry=0x768f2680,
do_pre=do_pre@entry=true, do_hoist=do_hoist@entry=true) at
[...]/source-gcc/gcc/tree-ssa-pre.c:3615
#9  0x00d0b592 in insert_aux (block=block@entry=0x768f2618,
do_pre=do_pre@entry=true, do_hoist=do_hoist@entry=true) at
[...]/source-gcc/gcc/tree-ssa-pre.c:3622
#10 0x00d0b592 in insert_aux (block=0x768f2548,
do_pre=, do_hoist=) at
[...]/source-gcc/gcc/tree-ssa-pre.c:3622
#11 0x00d0b693 in insert () at
[...]/source-gcc/gcc/tree-ssa-pre.c:3646
#12 0x00d0ba06 in (anonymous namespace)::pass_pre::execute
(this=0x1752760, fun=0x769575e8) at
[...]/source-gcc/gcc/tree-ssa-pre.c:5011
#13 0x00a9b6cd in execute_one_pass (pass=pass@entry=0x1752760) at
[...]/source-gcc/gcc/passes.c:2344
#14 0x00a9bce8 in execute_pass_list_1 (pass=0x1752760) at
[...]/source-gcc/gcc/passes.c:2428
#15 0x00a9bcfa in execute_pass_list_1 (pass=0x17516e0) at
[...]/source-gcc/gcc/passes.c:2429
#16 0x00a9bd45 in execute_pass_list (fn=0x769575e8,
pass=) at [...]/source-gcc/gcc/passes.c:2439
#17 0x007541ad in cgraph_node::expand
(this=this@entry=0x7695d000) at [...]/source-gcc/gcc/cgraphunit.c:1983
#18 0x00755c84 in expand_all_functions () at
[...]/source-gcc/gcc/cgraphunit.c:2119
#19 symbol_table::compile (this=this@entry=0x768d2000) at
[...]/source-gcc/gcc/cgraphunit.c:2475
#20 0x00757e7a in symbol_table::finalize_compilation_unit
(this=0x768d2000) at [...]/source-gcc/gcc/cgraphunit.c:2565
#21 0x00b639ad in compile_file () at
[...]/source-gcc/gcc/toplev.c:490
#22 0x00562eeb in do_compile () at
[...]/source-gcc/gcc/toplev.c:1998
#23 toplev::main (this=this@entry=0x7fffce50, argc=argc@entry=18,
argv=argv@entry=0x7fffcf58) at [...]/source-gcc/gcc/toplev.c:2132
#24 0x00564a87 in main (argc=18, argv=0x7fffcf58) at
[...]/source-gcc/gcc/main.c:39
(gdb) frame 1
#1  0x00d058a2 in find_or_generate_expression
(block=block@entry=0x768f2680, op=op@entry=0x7697f3a0,
stmts=stmts@entry=0x7fffca70) at [...]/source-gcc/gcc/tree-ssa-pre.c:2672
2672  unsigned int lookfor = get_expr_value_id (expr);

Unexpectedly, "expr" is NULL, which has been 

[Bug c/71858] Surprising suggestions for misspellings

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jul 15 10:40:39 2016
New Revision: 238369

URL: https://gcc.gnu.org/viewcvs?rev=238369=gcc=rev
Log:
PR c/71858
* c-common.h (enum lookup_name_fuzzy_kind): Add
FUZZY_LOOKUP_FUNCTION_NAME.

* c-decl.c (implicit_decl_warning): Use FUZZY_LOOKUP_FUNCTION_NAME
instead of FUZZY_LOOKUP_NAME.
(lookup_name_fuzzy): For FUZZY_LOOKUP_FUNCTION_NAME consider
FUNCTION_DECLs, {VAR,PARM}_DECLs function pointers and macros.

* gcc.dg/spellcheck-identifiers-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/spellcheck-identifiers-3.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/71523] Static variables given automatic initializers with -finit-* and -fmax-stack-var-size

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> Patch submitted, see https://gcc.gnu.org/ml/fortran/2016-06/msg00032.html

Hit return too soon!-(

The patch works as advertised. I think you should ping the mailing lists and
assign the PR to yourself.

[Bug fortran/71523] Static variables given automatic initializers with -finit-* and -fmax-stack-var-size

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-07-15
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> Patch submitted, see https://gcc.gnu.org/ml/fortran/2016-06/msg00032.html

[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0). Note that the ICE for 4.8 and 4.9 is

pr71884.f90:3:0: internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:106(4|5)

[Bug c++/71885] Incorrect code generated with -01, memset() function call is missing

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
An optimizing compiler optimizes on the assumption that undefined behavior does
not happen.  So, if you want to keep using code that invokes undefined behavior
(which is a very bad idea), you need to be prepared to pass some extra options
that tell the compiler not to do it.
-flitefime-dse=1 or -fno-lifetime-dse in this case (the latter if you also
"assume" that object after its destruction will still contain the data you've
stored in there), -fno-aggressive-loop-optimizations, -fno-strict-aliasing, -O0
in certain cases, in some cases there just isn't an option.
The -Wuninitialized* family of warnings is able to warn in certain cases about
this problem, but you of course don't get a guarantee this will be warned about
every time.

[Bug fortran/71891] fortran/symbol.c:4864: suspicious if ?

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-15
 CC||fritzoreese at gmail dot com
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> According to svn blame, kargl is the author of this line of code.

r235999 and actually the author was Fritz Reese.

[Bug fortran/71883] [5/6/7 Regression] ICE in identical_array_ref, at fortran/dependency.c:104

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-15
 CC||pault at gcc dot gnu.org
  Known to work||5.4.0, 6.1.0
Summary|ICE in identical_array_ref, |[5/6/7 Regression] ICE in
   |at fortran/dependency.c:104 |identical_array_ref, at
   ||fortran/dependency.c:104
 Ever confirmed|0   |1
  Known to fail||5.4.1, 6.1.1, 7.0

--- Comment #3 from Dominique d'Humieres  ---
I confirm the ICE with trunk (7.0). With gcc version 5.4.1 20160707 r238074 and
6.1.1 20160706 r238061, I get

(null):0: confused by earlier errors, bailing out

which replaces the ICE for compilers configured with --enable-checking=release.

On trunk the change occurred between r237310 (2016-06-10, errors) and r237536
(2016-06-16, (null):0:...), likely r237358 (pr70673).

IMO the code in comment 2 is invalid: sections are not allocated on assign. The
code executes if I add

   allocate(z(2,2))

[Bug fortran/71807] [5/6/7 Regression] Internal compiler error with NULL() reference in structure constructor

[vehre at gcc dot gnu.org]

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

--- Comment #4 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Fri Jul 15 09:28:47 2016
New Revision: 238368

URL: https://gcc.gnu.org/viewcvs?rev=238368=gcc=rev
Log:
gcc/fortran/ChangeLog:

2016-07-15  Andre Vehreschild  

PR fortran/71807
* trans-expr.c (gfc_trans_subcomponent_assign): Special casing
when allocatable component is set to null() in initializer.

gcc/testsuite/ChangeLog:

2016-07-15  Andre Vehreschild  

PR fortran/71807
* gfortran.dg/null_9.f90: New test.



Added:
trunk/gcc/testsuite/gfortran.dg/null_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/71885] Incorrect code generated with -01, memset() function call is missing

[kern at sibbald dot com]

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

--- Comment #12 from Kern Sibbald  ---
Yes, I clearly understand your point. My responses were meant for the project
were not directed at you. Hopefully someone will consider taking your advice of
not making this the default.  It may be difficult to backpeddle, but it is
better than breaking tens and possibly hundreds of projects.

[Bug fortran/71880] pointer to allocatable character

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 5.4.0 up to trunk (7.0). Compiling the tests with gcc-4.8/9
gives an ICE.

[Bug c++/71885] Incorrect code generated with -01, memset() function call is missing

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #11 from Markus Trippelsdorf  ---
Well, I'm really the wrong person to justify this optimization.
CCing the author...

[Bug tree-optimization/71347] [7 regression] Performance drop after r235513 on x86-64 in 32-bit mode.

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from amker at gcc dot gnu.org ---
Fixed.

[Bug tree-optimization/71347] [7 regression] Performance drop after r235513 on x86-64 in 32-bit mode.

[amker at gcc dot gnu.org]

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

--- Comment #6 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Jul 15 08:53:48 2016
New Revision: 238366

URL: https://gcc.gnu.org/viewcvs?rev=238366=gcc=rev
Log:
gcc/testsuite
PR tree-optimization/71347
* gcc.dg/tree-ssa/pr71347.c: XFAIL on ia64, arm, m68k and sparc.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71347.c

[Bug tree-optimization/71881] [4.9/6/7 Regression] ICE on valid code at -O3 with -g enabled on x86_64-linux-gnu: cannot update SSA form

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #5)
> Thanks.  I see some reset_debug_uses calls in the ldist pass, perhaps it is
> needed somewhere else too (where we decide the loops should be destroyed).

I think those are premature as well, we simply need to make sure to walk
stmts/BBs backwards in the stmt removal that is done in
generate_loops_for_partition as well.  Not sure if worth the trouble though.

[Bug c++/71885] Incorrect code generated with -01, memset() function call is missing

[kern at sibbald dot com]

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

--- Comment #10 from Kern Sibbald  ---
Thanks for your definition of "undetermined" behavior.  The problem here is
that at the time the compiler applied its optimization we were just in the
process of creating the object as is permitted by the C++ language, and in that
process the g++ compiler made what I consider to be a very risky assumption
about the state of the object while it was being created. I maintain that our
code is valid and should not be optimized away by the compiler. This, in my
opinion, is a case of the compiler writer not realizing that his assumption was
not valid in our particular case (object being created in an overridden new). 
The problem would be corrected in general by ensuring that no "unsafe"
optimizations are made at low levels of optimization.  At higher levels the
developer knows he risks problems.

[Bug tree-optimization/71881] [4.9/6/7 Regression] ICE on valid code at -O3 with -g enabled on x86_64-linux-gnu: cannot update SSA form

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
So in theory release_ssa_name()s insert_debug_temp_for_var_def should have
saved
us here.  But!  We have a single debug-use left plus the definition stmt is

  i_21 = i_29 + 1;

and thus i_29 + 1 counts as sth we can use as replacement.

BUT!

This only works if i_29 isn't yet removed which it is because destroy_loop
doesn't care about the BB order in its BB removal process (it has DOM order
but walks forward).

With that fixed the debug stmt ends up as

  :
  b = 0;
  # DEBUG i => 0 + 1

which is correct but also unfolded.

  /* If we didn't replace uses with a debug decl fold the
 resulting expression.  Otherwise we end up with invalid IL.  */
  if (TREE_CODE (value) != DEBUG_EXPR_DECL)
{
  gimple_stmt_iterator gsi = gsi_for_stmt (stmt);
  fold_stmt_inplace ();
}

but fold_stmt_inplace doesn't really do much to debug stmts.

[Bug c++/71885] Incorrect code generated with -01, memset() function call is missing

[eric at baculasystems dot com]

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

--- Comment #9 from Eric Bollengier  ---
Thanks for the "behavior is undefined" explanation. I understand a bit better
why the GCC team did this choice.

However, here, we don't talk about such kind of objects. In my case for
example, objects that uses this way of initializing the memory are always
allocated with a new(). The programmer controls that side.

I would rather prefer see some warnings about uninitialized variables when the
object allocation is automatic rather than stripping my initialization because
it doesn't work in all cases.

I would also vote to move this optimization to some -O3 -O4 level instead of
-O1.

[Bug c++/71892] Recent optimization changes introduce bugs

[kern at sibbald dot com]

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

--- Comment #2 from Kern Sibbald  ---
Yes, we are aware of the option and how to fix the problem.  The issue is that
this optimization at low levels of -O1 and -O2 is not reasonable, and it is
unreasonable and irresponsible to make such changes. Just search Internet to
see what kinds of pains this creates -- all for nothing.  

Some years ago, we just accepted these kinds of crippling and costly changes.
This incident has caused bad versions of Bacula to be distributed by at least
two popular distros that seg fault because of g++.  We are not the only project
to be affected. For me this comes down to the philosophy of how the gcc project
treats its users. Do you force risky changes on your users or do you try to
protect them. The gcc project has its view, but this result is not acceptable
to me.  

Some years ago there was no alternative to g++, but faced with these kind of
problems that take months to fix because of an "unstable" and "incompatible"
new compiler releases, I for one will now take a careful look at the
alternatives.

I suggest that you (the gcc project) carefully reconsider whether making such
assumptions leading to risky optimizations is best practice.

[Bug c++/71885] Incorrect code generated with -01, memset() function call is missing

[trippels at gcc dot gnu.org]

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

--- Comment #8 from Markus Trippelsdorf  ---
See Initializers 8.6.12:  

When storage for an object with automatic or dynamic storage duration is
obtained, the object has an indeterminate value, and if no initialization is
performed for the object, that object retains an indeterminate value until that
value is replaced (5.17). [ Note: Objects with static or thread storage
duration are zero-initialized, see 3.6.2. — end note ] If an indeterminate
value is produced by an evaluation, the behavior is undefined...

[Bug tree-optimization/71881] [4.9/6/7 Regression] ICE on valid code at -O3 with -g enabled on x86_64-linux-gnu: cannot update SSA form

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Thanks.  I see some reset_debug_uses calls in the ldist pass, perhaps it is
needed somewhere else too (where we decide the loops should be destroyed).

[Bug tree-optimization/71881] [4.9/6/7 Regression] ICE on valid code at -O3 with -g enabled on x86_64-linux-gnu: cannot update SSA form

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|6.2 |4.9.4

--- Comment #4 from Richard Biener  ---
I will have a look (bah).

[Bug c++/71885] Incorrect code generated with -01, memset() function call is missing

[kern at sibbald dot com]

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

--- Comment #7 from Kern Sibbald  ---
Just to be clear:

- This change might be appropriate for higher level of optimization, but is not
appropriate as a default for -O2 and -O1.

- There is no undefined behavior here. We override the new operator explicitly
to be able to allocate and manage the memory the way we want.  The g++ compiler
can make assumptions about what a new operator returns, but it should make any
assumptions about what we are doing to initialize memory inside an overridden
new operator particularly at low optimization levels.  The g++ behavior is
incorrect in this case.  Please correct it.

[Bug c++/71892] Recent optimization changes introduce bugs

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
There is an option to disable both of these. Also the null pointer one had
always been there. Just it got smarter.

[Bug rtl-optimization/71887] [7 Regression] wrong code (SIGFPE) at -O1 and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-07-15
   Target Milestone|--- |7.0
Summary|wrong code (SIGFPE) at -O1  |[7 Regression] wrong code
   |and above on|(SIGFPE) at -O1 and above
   |x86_64-linux-gnu (in both   |on x86_64-linux-gnu (in
   |32-bit and 64-bit modes)|both 32-bit and 64-bit
   ||modes)
 Ever confirmed|0   |1

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

2016-07-13  Richard Biener  

PR tree-optimization/24574
* tree-ssa-phiopt.c (absorbing_element_p): Pass in argument
position and add shift, rotate, divison and modulo support
for left zero.
(value_replacement): Pass in argument position to absorbing_element_p.

this didn't consider that we might divide/modulo by zero and have that guarded
(implicitely) by a guard on the left-hand value.  In the testcase it's quite
explicit though:

  if (c_5 == 0)
goto ;
  else
goto ;

  :
  _2 = c_5 % c_5;

  :
  # _6 = PHI <0(2), _2(3)>

[Bug c++/71892] New: Recent optimization changes introduce bugs

[kern at sibbald dot com]

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

Bug ID: 71892
   Summary: Recent optimization changes introduce bugs
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kern at sibbald dot com
  Target Milestone: ---

The optimizations that you made to g++ 6.0 are not reasonable since they create
programming bugs.  This applies to two optimizations you have made.  One
disallowing this to be tested against NULL and the second elimination of what
you determine to be unnecessary memory clearing with memset. 

In both case, the assumptions you make are not valid and thus these
optimizations should not be made at low levels such as -O2 and below.

First the case of testing this == NULL.  You state: "When optimizing, GCC now
assumes the this pointer can never be null, which is guaranteed by the language
rules."

This seems to be incorrect to me.  "this" is nothing but a pointer to the class
structure and at least in the case of non-virtual methods this can be zero, and
it is often useful for it to be zero, and it is even more useful for a class
implementer to be able to know if his method is being called with an
uninitialized class.  For example, if one has an optional list implemented as a
class(as is the case in Bacula), rather than testing everywhere in the code
whether or not the list pointer is NULL, it is more efficient to do so in the
class.  In our case, we return a zero in the size() method and thus there is no
need in perhaps hundreds of places to test for a NULL pointer because it is
done in the class.  Another more important use of testing for this == NULL is
for a class author to be able to know if the class has been initialized.  If
so, the method can continue, and if not the class writer can take appropriate
action and avoid a seg fault.  With your optimization, you explicitly remove
this feature from the C++ language.

The second case is you do not generate code in a overridden new operator when
memset() is used to zero the memory.  You are assuming that memory has already
been zeroed, but we are overridding new specifically to use our own memory
allocator that guarantees that the memory is non-zero.  While your optimization
may be appropriate at higher levels of optimization, it is not appropriate at
-O2 which is used by many programs.

I maintain that it is irresponsible to implement the above two unsafe
optimizations at levels -O2 and below.  I am fully aware that we could test for
the compiler level and add new command line options, but that is a lot of
unnecessary work, and in the mean time, g++ is not generating the code that
corresponds to what we wrote (i.e. it is generating incorrect code and
introducing seg faults in many programs).  Please implement these
"optimizations" if you must at higher optimization levels and leave levels -O2
and -O1 with only optimizations that are safe and do not modify the behavior of
the program as written.

[Bug c++/71888] internal compiler error: in force_type_die, at dwarf2out.c:23236

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/71889] [MIPS] python: "insn does not satisfy its constraints"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|[5.4 Regression] [MIPS] |[MIPS] python: "insn does
   |python: "insn does not  |not satisfy its
   |satisfy its constraints"|constraints"

--- Comment #2 from Richard Biener  ---
mipsel-softfloat-linux-gnu-gcc -pthread -fPIC -fno-strict-aliasing -O2
-fomit-frame-pointer -pipe -mmt -march=1004kc -fwrapv -c
_codecs_cn.preprocessed.c

/var/tmp/portage/dev-lang/python-2.7.11-r2/work/Python-2.7.11/Modules/cjkcodecs/_codecs_cn.c:
In function ‘gb18030_encode’:
/var/tmp/portage/dev-lang/python-2.7.11-r2/work/Python-2.7.11/Modules/cjkcodecs/_codecs_cn.c:243:1:
error: insn does not satisfy its constraints:
(insn 588 291 583 32 (parallel [
(set (reg:SI 25 $25 [494])
(truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (reg:SI 16
$16 [orig:488 tc ] [488]))
(zero_extend:DI (reg:SI 8 $8 [544])))
(const_int 32 [0x20]
(clobber (scratch:SI))
])
/var/tmp/portage/dev-lang/python-2.7.11-r2/work/Python-2.7.11/Modules/cjkcodecs/_codecs_cn.c:220
68 {umulsi3_highpart_internal}
 (nil))
/var/tmp/portage/dev-lang/python-2.7.11-r2/work/Python-2.7.11/Modules/cjkcodecs/_codecs_cn.c:243:1:
internal compiler error: in extract_constrain_insn, at recog.c:2246

quoting for easier searches.

Enabling optimizations without any -O is a no-op so you effectively tested -O0.

What GCC version was able to compile the file?

[Bug fortran/71891] fortran/symbol.c:4864: suspicious if ?

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
According to svn blame, kargl is the author of this line of code.

Adding them in.

[Bug c++/71885] Incorrect code generated with -01, memset() function call is missing

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
For the record, I was against enabling this optimization by default.
(Because the potential gain doesn't justify the possible confusion it may
cause.
And -fsanitize=undefined doesn't catch these issues yet.)

But in the end it is just another instance were the compiler correctly assumes
that undefined behavior will never happen and so optimizes accordingly.

The issue is that the object has an indeterminate value when the constructor
starts, so stores to it before this point are lost.

[Bug fortran/71891] New: fortran/symbol.c:4864: suspicious if ?

[dcb314 at hotmail dot com]

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

Bug ID: 71891
   Summary: fortran/symbol.c:4864: suspicious if ?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I did a fortran build and used the flag -Wlogical-op. It said

../../src/trunk/gcc/fortran/symbol.c:4864:50: warning: logical ‘and’ of equal
expressions [-Wlogical-op]
   if ((is_derived1 && is_derived2) || (is_union1 && is_union1))
~~^~~~
I am guessing this should be

   if ((is_derived1 && is_derived2) || (is_union1 && is_union2))

[Bug libgcc/71890] when using setjmp do context switch, libgcc crash the process when do unwind in thread cancel signal handler on X86_64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
I don't think this is a valid thing to do with setjmp and longjmp.

Why are you not using makecontext/setcontext/getcontext/swapcontext instead?

Also why do you think this is a libgcc bug because if you try to unwind the
stack using gdb, you will get the same behavior because the stack was that one
thread is now on the other one but the that thread has now exited.

[Bug c++/71885] Incorrect code generated with -01, memset() function call is missing

[kern at sibbald dot com]

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

Kern Sibbald  changed:

   What|Removed |Added

 CC||kern at sibbald dot com

--- Comment #5 from Kern Sibbald  ---
I would like to see a precise explanation of what "undefined behavior" is. 
Bacula does zero memory that is passed as a replacement to a new.  This
behavior is desirable and very well defined. I may be wrong, but it seems that
you are assuming that the memory is already zero, which is not a good
assumption. In the case of Bacula memory that is allocated from the heap is
non-zero by explicit programming.  Consequently this seems to me to be an
overly aggressive optimization that should be enabled at a much higher
optimization level than -O2, generally used by Bacula and many other programs.

At some point g++'s tinkering with valid user's programs should stop.  Yes, we
can probably work around the g++ generated bug by explicitly testing for the
g++ compiler version and adding another command line option, but this should be
unnecessary.

Changing g++ in this manner (rather cavalier in my opinion) can create lots of
unnecessary problems for many programs. As you might image, I call this new g++
feature "unreasonable" and "dangerous".  Please remove it or at least make it a
new option that the g++ user must explicitly add.

[Bug libgcc/71890] New: when using setjmp do context switch, libgcc crash the process when do unwind in thread cancel signal handler on X86_64

[wgkun at hotmail dot com]

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

Bug ID: 71890
   Summary: when using setjmp do context switch, libgcc
crash the process when do unwind in thread cancel
signal handler on X86_64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wgkun at hotmail dot com
  Target Milestone: ---

Created attachment 38911
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38911=edit
test case to reproduce crash problem

This problem happens when we implement a user space context switching framework
by setjmp 
The attached file is a simple case can reproduce this problem. We create a
thread by pthread_create and mmap two memory blocks as the stack pool of it.
And then use setjmp to make the thread switch between these two stacks.
We call the stack which the pthread_create allocate for the thread as original
stack, and the other two mmap stacks as stack 1 and stack 2. The thread only
switchs from original stack to stack 1 once after it created and then only
switchs between stack 1 and stack 2. Then the result is that if release stack 1
when the thread runs on stack 2 and cancel the thread, libgcc will crash the
process when do unwind in cancel handler. It try to visit some where on stack 1
which has been released. However whenever we release stack 2 and cancel the
thread, libgcc will run ok.
We first found this problem on Wind River's commercial version and then
reproduce on other free release.
We have tested on X86_64, MIPS, PPC and found it only happens on X86_64.
Compile the case file simply with "gcc -lpthread my_test.c -o my_test"
If use -fno-asynchronous-unwind-tables to not generate the unwind table, the
process will not crash.

the version infomation:
1. 
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/4.9.3/lto-wrapper
Target: x86_64-linux-gnu
Configured with: /build/distro/work/shared/gcc-4.9.3/configure --build=none
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --prefix=/usr
--with-sysroot=/
--with-build-sysroot=/build/distro/work/x86_64/rootfs/x86_64-linux-gnu
--disable-nls --disable-bootstrap --enable-languages=c,c++ --with-system-zlib
--enable-shared --disable-static --with-pkgversion=distro-v2.5-sctpmh
--disable-install-libiberty --with-arch=core2 --disable-multilib
Thread model: posix
gcc version 4.9.3 (distro-v2.5-sctpmh) 

2.
$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.5/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)

3.
Thread model: posix
gcc version 4.4.1 (Wind River Linux Sourcery G++ 4.4a-450)