[Bug target/64364] gcc ICE on min() on Intel Sandy Bridge CPU if compiler built on Haswell

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
No feedback in over a year so closing as invalid.

[Bug fortran/77507] New: gfortran rejects keyworded calls to procedures from intrinsic modules

[mathewc at nag dot co.uk]

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

Bug ID: 77507
   Summary: gfortran rejects keyworded calls to procedures from
intrinsic modules
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mathewc at nag dot co.uk
  Target Milestone: ---

$ uname -a && gfortran --version && cat foo.f90 && gfortran foo.f90
Linux cuivienen.nag.co.uk 4.7.2-201.fc24.x86_64 #1 SMP Fri Aug 26 15:58:40 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux
GNU Fortran (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Program p
  Use ieee_arithmetic
  Use iso_c_binding
  Print *, ieee_value(x=1.0, class=ieee_negative_inf)
  Print *, c_associated(c_ptr_1=c_null_ptr)
End Program
foo.f90:4:10:

   Print *, ieee_value(x=1.0, class=ieee_negative_inf)
  1
Error: There is no specific function for the generic ‘ieee_value’ at (1)
foo.f90:5:10:

   Print *, c_associated(c_ptr_1=c_null_ptr)
  1
Error: Can't find keyword named ‘c_ptr_1’ in call to ‘c_associated’ at (1)

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #11 from Richard Biener  ---
CCing libstdc++ people -- not sure if std::stable_sort (on which kind of
collection?) is safe for std::shared_ptr.

Would be nice if you could track down where the object gets destroyed btw
(maybe use a watchpoint on the vtable slot?)

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[david.abdurachmanov at gmail dot com]

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

--- Comment #12 from David Abdurachmanov  
---
Looks to be std::vector> (aka
ConstRecHitContainer).

Here is the class and typedef for the containers:
https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/DataFormats/TrackingRecHit/interface/TrackingRecHit.h#L35

Here we call sort which is a member function (at the end of the file):
https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/RecoMuon/TrackingTools/src/MuonTrajectoryUpdator.cc#L119

That member function calls stable_sort.

stable_sort is called here:
https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/RecoMuon/TrackingTools/src/MuonTrajectoryUpdator.cc#L260

This is the comparison function used:
https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/RecoMuon/TrackingTools/interface/MuonTrajectoryUpdator.h#L98

Will try to check where dtor is happening.

[Bug fortran/77501] ICE in gfc_match_generic, at fortran/decl.c:9429

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-07
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |6.3
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, all releases I have ICE (4.5.0+).

[Bug fortran/77500] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:2822

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-07
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, first version which ICEs is 4.7.0.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |7.0
Summary|Regression after|[7 Regression] Regression
   |code-hoisting, due to   |after code-hoisting, due to
   |combine pass failing to |combine pass failing to
   |evaluate known value range  |evaluate known value range

--- Comment #3 from Richard Biener  ---
on x86 the code is if-converted which might help combine (though there is
nothing to combine on x86).

It looks like nonzero_bits never looks at sets of REGs and thus can only work
on expressions.  Code hoisting generally makes sub-expressions no longer
single-use (in this case the x >> 1) which means they won't appear as part of
a larger expression (and combine doesn't consider re-combining them unless in
some very specific circumstances).  In this case r111:SI is used multiple
times.

It seems with thumb the code is only if-converted after reload for some reason.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Oh, and with -fno-code-hoisting I see

movwr6, #45345
.L5:
smull   lr, r4, r5, r1
sub r4, r4, r1, asr #31
add r4, r4, r4, lsl #1
cmp r1, r4
sub r1, r1, r3
ite ne
eorne   r0, r6, r0, lsr #1
lsreq   r0, r0, #1
cmp r2, r1
blt .L5

while with code hoisting

movwr6, #45345
.L4:
smull   r5, r4, r7, r1
lsrsr0, r0, #1
sub r4, r4, r1, asr #31
eor r5, r0, r6
add r4, r4, r4, lsl #1
cmp r1, r4
sub r1, r1, r3
it  ne
uxthne  r0, r5
cmp r2, r1
blt .L4

so we are talking about the uxthne insn (I don't know arm / thumb very well).

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

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Richard Biener from comment #3)
> It seems with thumb the code is only if-converted after reload for some
> reason.

Most likely because it is going through the cond_exec route.

[Bug middle-end/77377] [7 Regression] c-c++-common/pr59037.c ICEs with -fpic -msse on i686

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #6 from Martin Liška  ---
*** Bug 77401 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/77401] [7 Regression] ICE: in simplify_binary_operation_1, at simplify-rtx.c:3731 with out-of-bounds vector access

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
It's a dup, fixed in r239854.

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

[Bug middle-end/77383] -fcheck-pointer-bounds -mmpx ICE with VLA struct return type

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-07
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |5.5
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.2.0

--- Comment #1 from Martin Liška  ---
Confirmed, starting from 5.1.0, first release where MPX support was added.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/24194] emit_input_reload_insns secondary reload handling is unsafe

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug c++/77304] ICE on C++ code with invalid template parameter: in gimplify_expr, at gimplify.c:11260

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2016-9-7
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |5.5

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

[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842
Bug 29842 depends on bug 24194, which changed state.

Bug 24194 Summary: emit_input_reload_insns secondary reload handling is unsafe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24194

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug c++/77508] New: ICE on valid C++ code: in finish_class_member_access_expr, at cp/typeck.c:2783

[su at cs dot ucdavis.edu]

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

Bug ID: 77508
   Summary: ICE on valid C++ code: in
finish_class_member_access_expr, at cp/typeck.c:2783
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This is a regression from 6.2. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160906 (experimental) [trunk revision 240004] (GCC)
$
$ g++-6.2 small.cpp
$ clang++ small.cpp
$
$ g++-trunk small.cpp
small.cpp: In member function ‘void B::g()’:
small.cpp:10:23: internal compiler error: in finish_class_member_access_expr,
at cp/typeck.c:2783
 this->B::template f < &B < T >::g > ();
   ^
0x7e8254 finish_class_member_access_expr(cp_expr, tree_node*, bool, int)
../../gcc-source-trunk/gcc/cp/typeck.c:2783
0x79dd04 cp_parser_postfix_dot_deref_expression
../../gcc-source-trunk/gcc/cp/parser.c:7364
0x79b54c cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6967
0x799e6c cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8019
0x7a3d17 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:8696
0x7a4315 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8798
0x7a4c00 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9086
0x7a74f9 cp_parser_expression
../../gcc-source-trunk/gcc/cp/parser.c:9253
0x7a7b1f cp_parser_expression_statement
../../gcc-source-trunk/gcc/cp/parser.c:10736
0x7b645c cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10587
0x7b73dc cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:10859
0x7b74cf cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:10813
0x7b767f cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20832
0x7b767f cp_parser_ctor_initializer_opt_and_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20868
0x7b8121 cp_parser_function_definition_after_declarator
../../gcc-source-trunk/gcc/cp/parser.c:25565
0x7bbf80 cp_parser_late_parsing_for_member
../../gcc-source-trunk/gcc/cp/parser.c:26446
0x796d56 cp_parser_class_specifier_1
../../gcc-source-trunk/gcc/cp/parser.c:21719
0x798679 cp_parser_class_specifier
../../gcc-source-trunk/gcc/cp/parser.c:21745
0x798679 cp_parser_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:15971
0x7abdf3 cp_parser_decl_specifier_seq
../../gcc-source-trunk/gcc/cp/parser.c:12889
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$


---


template < typename T > struct A
{ 
  template < void (T::*Fn) () > void f () {}
};

template < typename T > struct B : A < B < T > >
{ 
  void g ()
  { 
this->B::template f < &B < T >::g > ();
  }
};

int main ()
{ 
  B < int > b;
  b.g ();
  return 0;
}

[Bug middle-end/21786] Segmentation fault under FreeBSD 5.3-RELEASE-p15

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
Fixed so closing.

[Bug tree-optimization/77503] [7 regression] ICE in vect_transform_stmt compiling postgresql

[trippels at gcc dot gnu.org]

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

--- Comment #11 from Markus Trippelsdorf  ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Markus Trippelsdorf from comment #6)
> > markus@x4 tmp % cat fsmpage.i
> 
> You got to it before I could do that :).

Yeah, sorry. I already finished reducing when I read your message...

[Bug bootstrap/10802] Bootstrap of gcc-3.3 on Solaris 9 x86 fails on undefined symbol in libgcj.so

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #14 from Andrew Pinski  ---
Does this really still happen?

[Bug c++/77508] [7 Regression] ICE on valid C++ code: in finish_class_member_access_expr, at cp/typeck.c:2783

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-07
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE on valid C++ code: in   |[7 Regression] ICE on valid
   |finish_class_member_access_ |C++ code: in
   |expr, at cp/typeck.c:2783   |finish_class_member_access_
   ||expr, at cp/typeck.c:2783
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r236221.

[Bug bootstrap/30136] bootstrap fail for 4.3-20061209

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
Does this work with a much newer GCC?

[Bug c++/77509] New: ICE on invalid C++ code: in finish_class_member_access_expr, at cp/typeck.c:2783

[su at cs dot ucdavis.edu]

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

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

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


$ g++-trunk -v 
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160906 (experimental) [trunk revision 240004] (GCC) 
$ 
$ g++-trunk -c small.cpp
small.cpp:3:8: warning: direct base ‘A’ inaccessible in ‘C’ due to ambiguity
 struct C : A, B {};
^
small.cpp: In function ‘void foo()’:
small.cpp:8:8: internal compiler error: in finish_class_member_access_expr, at
cp/typeck.c:2783
   c.C::m < int > ();
^
0x7e8254 finish_class_member_access_expr(cp_expr, tree_node*, bool, int)
../../gcc-source-trunk/gcc/cp/typeck.c:2783
0x79dd04 cp_parser_postfix_dot_deref_expression
../../gcc-source-trunk/gcc/cp/parser.c:7364
0x79b54c cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6967
0x799e6c cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8019
0x7a3d17 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:8696
0x7a4315 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8798
0x7a4c00 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9086
0x7a74f9 cp_parser_expression
../../gcc-source-trunk/gcc/cp/parser.c:9253
0x7a7b1f cp_parser_expression_statement
../../gcc-source-trunk/gcc/cp/parser.c:10736
0x7b645c cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10587
0x7b73dc cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:10859
0x7b74cf cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:10813
0x7b767f cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20832
0x7b767f cp_parser_ctor_initializer_opt_and_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20868
0x7b8121 cp_parser_function_definition_after_declarator
../../gcc-source-trunk/gcc/cp/parser.c:25565
0x7b8e35 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-source-trunk/gcc/cp/parser.c:25477
0x7b8e35 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18603
0x7b9189 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12495
0x7b94c1 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12363
0x7c22a0 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12260
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


-


struct A {  template < class > void m ();  };
struct B : A {};
struct C : A, B {};

void foo ()
{
  C c; 
  c.C::m < int > ();
}

[Bug target/30026] useless stack movement

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
I think this might be fixed now.

gcc-bugs@gcc.gnu.org

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
Fixed a while back, maybe even in GCC 4.9.x

[Bug java/16200] gcj generates dependencies on the full contents of the extensions directory

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
No feedback in over 4 years so closing and gcj is about to remove :)

[Bug other/31566] @missing_file gives bad error message

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||easyhack
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-07
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
This should be something easy for someone new to develop too.

[Bug target/30199] config/freebsd.h does not define HANDLE_PRAGMA_PACK_PUSH_POP

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.3.0

--- Comment #2 from Andrew Pinski  ---
Fixed a long time ago.

[Bug tree-optimization/77450] [5/6 Regression] ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Wed Sep  7 08:22:01 2016
New Revision: 240025

URL: https://gcc.gnu.org/viewcvs?rev=240025&root=gcc&view=rev
Log:
2016-09-07  Richard Biener  

PR c/77450
* c-c++-common/vector-subscript-8.c: Move ..
* gcc.dg/pr77450.c: ... here.

Added:
trunk/gcc/testsuite/gcc.dg/pr77450.c
  - copied, changed from r240024,
trunk/gcc/testsuite/c-c++-common/vector-subscript-8.c
Removed:
trunk/gcc/testsuite/c-c++-common/vector-subscript-8.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/77509] ICE on invalid C++ code: in finish_class_member_access_expr, at cp/typeck.c:2783

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-07
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |5.5
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, all releases I have (4.5.0) ICE.

[Bug fortran/77501] ICE in gfc_match_generic, at fortran/decl.c:9429

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Target Milestone|6.3 |---

[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-09-07
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Note this revision isn't really related to code hoisting.  It merely allows PRE
to perform simple predictive commoning and more PRE in general.  The commoning
can interfere with sinking (see the adjusted testcase).

For the testcase we apply commoning which increases register pressure.

The pcom pass does a better job (well, it was designed for this).

I suppose this PRE improvement raises the general question (again) whether
we want it to introduce loop-carried dependences at all.  In this case
it trades 18 loads for 18 loop-carried dependences - optimally reg colaesced
and thus "free", maybe reg-reg copies or worst spills (as seen here).

I'll need to think about this (again).

[Bug driver/77497] [5/6/7 Regression] Setting DWARF level and debug level together has flag-ordering-dependent results

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.5
Summary|Setting DWARF level and |[5/6/7 Regression] Setting
   |debug level together has|DWARF level and debug level
   |flag-ordering-dependent |together has
   |results |flag-ordering-dependent
   ||results

[Bug target/77483] [6/7 regression] gcc.target/i386/mask-unpack.c etc. FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from Richard Biener  ---
> You could add dg-skip-if or XFAILs to the tests now failing.  IMHO a testsuite
> issue.

I though about just adding -mno-stackrealign to the affected testcases
instead.  This would work everywhere and avoid duplicating the effects
of the i386/cygming.h and i386/sol2.h definitions of
STACK_REALIGN_DEFAULT:

cygming.h:#define STACK_REALIGN_DEFAULT TARGET_SSE
sol2.h:#define STACK_REALIGN_DEFAULT (TARGET_64BIT ? 0 : 1)

Rainer

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

[avieira at gcc dot gnu.org]

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

--- Comment #6 from avieira at gcc dot gnu.org ---
> so we are talking about the uxthne insn (I don't know arm / thumb very well).

Yes, the uxthne is the "zero_extend" that is otherwise optimized away if you
turn off code-hoisting.

This is because the way the code gets transformed leads to:
r112:SI=r112:SI 0>>0x1, this is the combination of instructions 12 and 13 in my
example earlier. r112 is also the first operand of the xor instruction and
because of the way combine does its "nonzero bit analysis" it always looks at
the last set value for each pseudo. For r112 here, thats an infinite loop and
so it will not be able to recognize that r112 originated from r0, thus loosing
the information that it is at most an unsigned short. Leading to the decision
not to get rid of the zero_extend.

I'll have a look at if-convert.

[Bug middle-end/66661] incorrect memory access in optimization with flexible array member

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

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

--- Comment #12 from Florian Weimer  ---
Here's a new test case.  It prints for me (without Address Sanitizer):

  count 2, align 4, minimum size 10, struct size 12, actual size 12
  count 5, align 4, minimum size 13, struct size 16, actual size 20
  count 0, align 8, minimum size 8, struct size 8, actual size 8
  count 3, align 4, minimum size 11, struct size 12, actual size 24
* count 0, align 16, minimum size 8, struct size 16, actual size 8
  count 8, align 4, minimum size 16, struct size 16, actual size 16
  count 4, align 4, minimum size 12, struct size 12, actual size 12
  count 2, align 4, minimum size 10, struct size 12, actual size 12
* count 2, align 8, minimum size 10, struct size 16, actual size 12
  count 6, align 4, minimum size 14, struct size 16, actual size 16
  count 7, align 4, minimum size 15, struct size 16, actual size 16
  count 3, align 4, minimum size 11, struct size 12, actual size 12
  count 3, align 4, minimum size 11, struct size 12, actual size 12
  count 6, align 4, minimum size 14, struct size 16, actual size 44
* count 5, align 32, minimum size 13, struct size 32, actual size 16
  count 8, align 4, minimum size 16, struct size 16, actual size 16
  count 9, align 4, minimum size 17, struct size 20, actual size 20
  count 7, align 4, minimum size 15, struct size 16, actual size 16
  count 1, align 4, minimum size 9, struct size 12, actual size 12
* count 1, align 8, minimum size 9, struct size 16, actual size 12

I believe this shows that GCC has some bug in this area.  Whether it's the
over-reads (but over-reads can be fine here because they cannot trap, and GCC
knows that they won't introduce observable data races), the object allocation
in the .data section (again, could be harmless), or the Address Sanitizer
report, I'm not sure.

#include 
#include 
#include 
#include 

struct flexible
{
  int count;
  int align;
  char bytes[];
};

#define ARGS_0
#define ARGS_1 1
#define ARGS_2 1, 2
#define ARGS_3 1, 2, 3
#define ARGS_4 1, 2, 3, 4
#define ARGS_5 1, 2, 3, 4, 5
#define ARGS_6 1, 2, 3, 4, 5, 6
#define ARGS_7 1, 2, 3, 4, 5, 6, 7
#define ARGS_8 1, 2, 3, 4, 5, 6, 7, 8
#define ARGS_9 1, 2, 3, 4, 5, 6, 7, 8, 9

#define DECL(name, count, align) \
  _Alignas (align) struct flexible name = {count, align,{ ARGS_##count }}

DECL (v4, 4, 4);
DECL (v1, 1, 8);
DECL (v7, 1, 4);
DECL (v17, 7, 4);
DECL (v15, 9, 4);
DECL (v16, 8, 4);
DECL (v11, 5, 32);
DECL (v12, 6, 4);
DECL (v5, 3, 4);
DECL (v9, 3, 4);
DECL (v13, 7, 4);
DECL (v18, 6, 4);
DECL (v2, 2, 8);
DECL (v8, 2, 4);
DECL (v10, 4, 4);
DECL (v14, 8, 4);
DECL (v0, 0, 16);
DECL (v3, 3, 4);
DECL (v5a, 0, 8);
DECL (v19, 5, 4);
DECL (v6, 2, 4);

enum { count = 21 };

static int
cmp(const void *a, const void *b)
{
  struct flexible *const *a1 = a;
  struct flexible *const *b1 = b;
  if (*a1 < *b1)
return -1;
  if (*a1 > *b1)
return 1;
  return 0;
}

int
main()
{
  struct flexible *p[count]
= {&v0, &v1, &v2, &v3, &v4, &v5, &v5a, &v6, &v7, &v8, &v9, &v10,
   &v11, &v12, &v13, &v14, &v15, &v16, &v17, &v18, &v19};
  qsort (p, count, sizeof (p[0]), cmp);
  for (int i = 0; i < count - 1; ++i)
{
  size_t min_size = offsetof (struct flexible, bytes) + p[i]->count;
  size_t align_mask = p[i]->align - 1;

  /* Struct size is the size that a struct with the requested
 length of the flexible array member would have.  */
  size_t struct_size = (min_size + align_mask) & ~align_mask;

  /* The actual size is the offset between this and the next
 object in the data section.  (This can be an over-estimate if
 other objects not listed above are placed between the listed
 objects.)  */
  size_t actual_size = (p[i + 1] - p[i]) * sizeof (*p[i]);

  /* The lines marked with * have an object whose struct size
 exceeds the object size.  If GCC assumes that objects always
 have their struct size allocated, this leads to an
 out-of-bounds acccess.  */
  printf ("%c count %d, align %d, minimum size %zu, struct size %zu, actual
size %zu\n",
  struct_size > actual_size ? '*' : ' ',
  p[i]->count, p[i]->align, min_size, struct_size, actual_size);
}
}

[Bug bootstrap/77510] New: genautomata memory footprint for MIPS

[lly.dev at gmail dot com]

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

Bug ID: 77510
   Summary: genautomata memory footprint for MIPS
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lly.dev at gmail dot com
  Target Milestone: ---

Created attachment 39578
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39578&action=edit
genautomata output MIPS32

Hello,

bootstrapping/crosscompiling gcc 5.4.0 for MIPS, genautomata uses a lot of
memory. This causes swapping/thrashing and extremely long build times on low
memory systems. According to valgrind massif report, it requires 527MB of heap
now.

genautomata output(-time -progress -stats) attached to PR. Probably we need to
try to decrease reservations for `xlp_cpu', `xlp_fpu' since simple
disable(comment out it in mips.md) of xlp support decreases heap usage down to
43MB.

Similar to bug 70473, which requests that a new bug is filed.
Thank you for your attention!

[Bug bootstrap/30136] bootstrap fail for 4.3-20061209

[dcb314 at hotmail dot com]

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

--- Comment #9 from David Binderman  ---
(In reply to Andrew Pinski from comment #8)
> Does this work with a much newer GCC?

Hard to say for definite. The machine was recycled many years
ago and is probably in landfill by now.

Given the great age of this bug report, I'd say
it's pretty certain the problem has either gone away 
or we don't care about that machine type by now.

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

[avieira at gcc dot gnu.org]

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

--- Comment #7 from avieira at gcc dot gnu.org ---
if-convert is a no go here, for the reason Andrew pointed out, sorry missed
that comment!

So I dont know... Only thing I can think of is better "value-range"-like
analysis for combine, but that might be too costly?

The fact is that for the code-hoisting to work here, the pseudo for r112 has to
be shared among both code-paths, so unless you add an extra move:

BB0:
r112:SI = r0:SI

BB 1:
...
r116:SI=r112:SI 0>>0x1
rNEW:SI=zero_extend(r116:SI#0)
...
if CC goto BB2 else BB Extra
BB 2:
r127:SI=rNEW:SI^r129:SI
r112:SI=zero_extend(r127:SI#0)
if LOOP: goto BB1 else BB exit
BB EXTRA:
r112:SI=rNEW:SI
if LOOP: goto BB1 else BB exit

And you end up with an extra move rather than a zero_extend. But maybe the move
can be optimized away in later stages? Or maybe put in the same conditional
execution block as the XOR...

[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #11)
> CCing libstdc++ people -- not sure if std::stable_sort (on which kind of
> collection?) is safe for std::shared_ptr.

It's required to work correctly. It should be equivalent to sorting
TrackingRecHit* pointers.

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

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Wed, 7 Sep 2016, avieira at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
> 
> --- Comment #7 from avieira at gcc dot gnu.org ---
> if-convert is a no go here, for the reason Andrew pointed out, sorry missed
> that comment!
> 
> So I dont know... Only thing I can think of is better "value-range"-like
> analysis for combine, but that might be too costly?

So we are not really looking for combine to combine the shift stmt
with the xor stmt?  Because combine doesn't consider that because of
the multi-use.

> The fact is that for the code-hoisting to work here, the pseudo for r112 has 
> to
> be shared among both code-paths, so unless you add an extra move:
> 
> BB0:
> r112:SI = r0:SI
> 
> BB 1:
> ...
> r116:SI=r112:SI 0>>0x1
> rNEW:SI=zero_extend(r116:SI#0)
> ...
> if CC goto BB2 else BB Extra
> BB 2:
> r127:SI=rNEW:SI^r129:SI
> r112:SI=zero_extend(r127:SI#0)
> if LOOP: goto BB1 else BB exit
> BB EXTRA:
> r112:SI=rNEW:SI
> if LOOP: goto BB1 else BB exit
> 
> And you end up with an extra move rather than a zero_extend. But maybe the 
> move
> can be optimized away in later stages? Or maybe put in the same conditional
> execution block as the XOR...

Well, we run into a general issue of the RTL combiner -- fwprop and
ree are other passes that are supposed to remove extensions in some
cases.

Really, the user could have written the code in a way CSEing the
shift himself -- it's unfortunate that we now fail to optimize the
non-CSEd source but that can only be a reason to enhance downstream
passes.

[Bug c/77511] New: libbacktrace could not find executable to open

[zheltonozhskiy at gmail dot com]

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

Bug ID: 77511
   Summary: libbacktrace could not find executable to open
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zheltonozhskiy at gmail dot com
  Target Milestone: ---

When I'm trying to build this -
https://github.com/Randl/skypeopensource2/tree/a1ec02c05797853e1862ae26d8e46a1d52f4b77f
Target skyauth_exe failes on Release configuration with following:

C:\Users\eabes\Downloads\skypeopensource2-4870457f725b332ec52d6d72e688c9beddbdd87b\skypeopensource2-4870457f725b332ec52d6d72e688c9beddbdd87b\skyauth\dh_384.c:
In function 'rc4_key_generate.constprop':
C:\Users\eabes\Downloads\skypeopensource2-4870457f725b332ec52d6d72e688c9beddbdd87b\skypeopensource2-4870457f725b332ec52d6d72e688c9beddbdd87b\skyauth\dh_384.c:49:5:
internal compiler error: in get_ptr_info, at tree-ssanames.c:586
 int rc4_key_generate(int buf, int a_key, unsigned int a_len) { //TODO: MinGW
bug lto-wrapper failed
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper.exe: fatal error:
C:\PROGRA~1\MINGW-~1\X86_64~1.0-P\mingw64\bin\G__~1.EXE returned 1 exit status
compilation terminated.
C:/PROGRA~1/MINGW-~1/X86_64~1.0-P/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
lto-wrapper failed
collect2.exe: error: ld returned 1 exit status
mingw32-make.exe[2]: *** [skyauth/skyauth_exe.exe] Error 1

for both MinGW 6.1.0 and 6.2.0 x64.

[Bug tree-optimization/77503] [7 regression] ICE in vect_transform_stmt compiling postgresql

[amker at gcc dot gnu.org]

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

--- Comment #12 from amker at gcc dot gnu.org ---
ICE is because prologue peeling changes code (to be specific, the initial
argument of reduction phi node in loop header), as a result, the statement to
be vectorized is not the statement that was previously analyzed.
One possible fix is be conservative and fall back to generic conditional
reduction if loop needs to be peeled for prologue.  Another (better) fix is we
don't update/inherit reduction value from prologue loop for vectorized loop,
and after vectorized loop, we combine the result manually.  Code would be like:

prolog_loop:
  c_1 = PHI
  c_2 = (cond) ? 1 : c_1;
  if (prolog_cond)  goto prolog_header
  else  goto prolog_exit

prolog_exit:
  c_3 = PHI;

vector_loop:
  c_4 = PHI;
  c_5 = (cond) ? 1 : c_4
  if (vector_cond) goto vector_header
  else goto vector_exit

vector_exit:
  c_6 = PHI;
  c_7 = (c_3 == 1 || c_5 == 1) ? 1 : 0;

We need to change how loop peeling updates SSA(PHI) nodes.  Since I have other
patches rewriting loop peeling, better to check this method after loop peeling
patches.  For now, I think we'd better go with the first method which disables
the optimization in peeling cases.

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

[avieira at gcc dot gnu.org]

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

--- Comment #9 from avieira at gcc dot gnu.org ---

> > So I dont know... Only thing I can think of is better "value-range"-like
> > analysis for combine, but that might be too costly?
> 
> So we are not really looking for combine to combine the shift stmt
> with the xor stmt?  Because combine doesn't consider that because of
> the multi-use.

AFAIK, combine will not combine the shift and xor because they are in different
basic blocks. The multi-use prevents it from tracking the origin of r112 back
to a point where it knows that it its higher bits are all 0.

> > 
> > And you end up with an extra move rather than a zero_extend. But maybe the 
> > move
> > can be optimized away in later stages? Or maybe put in the same conditional
> > execution block as the XOR...
> 
> Well, we run into a general issue of the RTL combiner -- fwprop and
> ree are other passes that are supposed to remove extensions in some
> cases.
> 
> Really, the user could have written the code in a way CSEing the
> shift himself -- it's unfortunate that we now fail to optimize the
> non-CSEd source but that can only be a reason to enhance downstream
> passes.

True, if say the unused 'y' I left in there for some odd reason were used to
CSE (x >> 1) outside the if-then-else, then you would end up with the
zero_extend in both -fcode-hoisting and -fno-code-hoisting.

[Bug bootstrap/77512] New: gcc compilation stops with Arithmetic Exception

[michael at mijobe dot org]

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

Bug ID: 77512
   Summary: gcc compilation stops with Arithmetic Exception
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael at mijobe dot org
  Target Milestone: ---

Created attachment 39579
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39579&action=edit
temporary compiler files

I am trying to install gcc-6.2.0 on Sparc Solaris 10
In stage 2 I get the following error:


$HOME/gcc-6.2.0-build/./prev-gcc/xg++ -B$HOME/gcc-6.2.0-build/./prev-gcc/
-B$HOME/gcc-6.2.0-bin/sparc-sun-solaris2.10/bin/ -nostdinc++
-B$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/src/.libs
-B$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs

-I$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/include/sparc-sun-solaris2.10
 -I$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/include 
-I$HOME/gcc-6.2.0/libstdc++-v3/libsupc++
-L$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/src/.libs
-L$HOME/gcc-6.2.0-build/prev-sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-I. -I. -I../../gcc-6.2.0/gcc -I../../gcc-6.2.0/gcc/.
-I../../gcc-6.2.0/gcc/../include -I./../intl
-I../../gcc-6.2.0/gcc/../libcpp/include -I$HOME/gcc-6.2.0-build/./gmp
-I$HOME/gcc-6.2.0/gmp -I$HOME/gcc-6.2.0-build/./mpfr -I$HOME/gcc-6.2.0/mpfr
-I$HOME/gcc-6.2.0/mpc/src  -I../../gcc-6.2.0/gcc/../libdecnumber
-I../../gcc-6.2.0/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-6.2.0/gcc/../libbacktrace -I$HOME/gcc-6.2.0-build/./isl/include
-I$HOME/gcc-6.2.0/isl/include  -o haifa-sched.o -MT haifa-sched.o -MMD -MP -MF
./.deps/haifa-sched.TPo ../../gcc-6.2.0/gcc/haifa-sched.c
In file included from ../../gcc-6.2.0/gcc/haifa-sched.c:141:0:
../../gcc-6.2.0/gcc/haifa-sched.c: In function 'int dep_cost_1(dep_t, dw_t)':
../../gcc-6.2.0/gcc/sched-int.h:252:31: internal compiler error: Arithmetische
Ausnahme
 #define DEP_COST(D) ((D)->cost)
   ^
../../gcc-6.2.0/gcc/haifa-sched.c:1438:12: note: in expansion of macro
'DEP_COST'
 return DEP_COST (link);
^~~~
First stage was compiled using gcc 4.0.3
Prerequisits are dowload using contrib/download_prerequisites
GNU binutils-2.27 are used
configuration was done with:
../gcc-6.2.0/configure --prefix=$HOME/gcc-6.2.0-bin
--target=sparc-sun-solaris2.10 --with-gnu-as --with-gnu-ld --disable-libgcj
--enable-languages=c,c++

[Bug tree-optimization/77503] [7 regression] ICE in vect_transform_stmt compiling postgresql

[amker at gcc dot gnu.org]

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

--- Comment #13 from amker at gcc dot gnu.org ---
(In reply to amker from comment #12)
> ICE is because prologue peeling changes code (to be specific, the initial
> argument of reduction phi node in loop header), as a result, the statement
> to be vectorized is not the statement that was previously analyzed.
> One possible fix is be conservative and fall back to generic conditional
> reduction if loop needs to be peeled for prologue.  Another (better) fix is
> we don't update/inherit reduction value from prologue loop for vectorized
> loop, and after vectorized loop, we combine the result manually.  Code would

Actually, existing code handles peeling for prologue loop well, I only need to
get the initial constant value from prologue loop.

[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET

[vogt at linux dot vnet.ibm.com]

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

--- Comment #14 from Dominik Vogt  ---
Okay, it looks like outgoing_args_size is rounded up to a multiple of
preferred_stack_boundary, so there's no problem on s390 or other targets with a
stack allocation size smaller than STACK_BOUNDARY.  So, what needs to be done
to get the patch back in?

1. Test and apply a patch with the change suggersted in comment 10.  (I can do
a quick test of the patch on AIX, but someone else should test AIX/Darwin/Linux
on Power with the patch)
2. Reapply the backed out patch.
3. Create a bug report for the not matching conditions in STACK_DYNAMIC_OFFSET
and STACK_BOUNDARY in rs6000.h and let the maintainers of that code clean it
up.

Opinions?

[Bug c++/77513] New: -Wzero-as-null-pointer-constant vs 0, nullptr, NULL and __null

[petschy at gmail dot com]

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

Bug ID: 77513
   Summary: -Wzero-as-null-pointer-constant vs 0, nullptr, NULL
and __null
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petschy at gmail dot com
  Target Milestone: ---

Created attachment 39580
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39580&action=edit
Preprocessed source, generated with g++-7.0.0 -std=c++14
-Wzero-as-null-pointer-constant 20160907-null.cpp -E > 20160907-null.ii

Yesterday I switched on the warning for a ~250kloc codebase to clean it up.
Used 7.0, it was tedious but it was done. I had to replace NULLs also, not just
0s, but at that time I wasn't suspecting anything, though it seemed a bit
strange.

Then, tried to build on another machine with 5.4.1, and to my surprise, tons of
warnings appeared. Then tried to build on my machine with 5.4.1, the same
results. It turned out that NULLs are frowned upon, quite inconsistently.

5.4.1 has problems with 7 cpp files, 6.2.1 and 7.0 with just a single one. Did
a grep for NULL, and as expected for a large and aging codebase, there were
lots of them, but they are not treated equally. All files are c++, and compiled
with the same flags.

Preprocessed 2 problematic files with all three gcc versions mentioned. Diffing
them revealed that there is no difference in the actual code, only what gets
included due to the differing gcc versions. All NULLs were replaced with
__null's by the preprocessor, which is defined in the gcc version specific
stddef.h include.

Crafted a test case:

#include 
char* a = 0;
char* b = nullptr;
char* c = __null;
char* d = NULL;
int main()
{
}

$ g++-5.4.1 -std=c++14 -Wzero-as-null-pointer-constant 20160907-null.cpp
20160907-null.cpp:2:11: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
 char* a = 0;
   ^
20160907-null.cpp:4:11: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
 char* c = __null;
   ^
6.2.1 and 7.0 print exactly the same warnings.

So NULL is ok, but __null is not? The end of the preprocessed source looks like
this:

# 2 "20160907-null.cpp"
char* a = 0;
char* b = nullptr;
char* c = __null;
char* d = 
# 5 "20160907-null.cpp" 3 4
 __null
# 5 "20160907-null.cpp"
 ;
int main()
{
}

c and d initialized the same except for whitespace and the two "'# 6" lines
around d's __null. I naively thought that these are only to communicate line
info to the compiler, but if I delete the first one:

$ g++-7.0.0 -std=c++14 -Wzero-as-null-pointer-constant 20160907-null.ii
20160907-null.cpp:2:11: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
 char* a = 0;
   ^
20160907-null.cpp:4:11: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
 char* c = __null;
   ^~
20160907-null.cpp:6:10: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
 int main()
  ^

The interpretation of __null at d changed for some reason. What is going on? It
seems that the interpretation can change unpredictably, and in the problematic
source files __null's are misdiagnosed even when the "# ..." lines are around
them.

For c++11 and later code, why is NULL defined as __null, rather than nullptr?

I put a fast bandaid on my code by redefining NULL to be nullptr after the last
include in the problematic files, but since the number of problematic files
seems to change from gcc version to gcc version, this is rather fragile, let
alone unelegant.

Platform is Debian Jessie AMD64, the gcc versions:

$ g++-5.4.1 -v
Using built-in specs.
COLLECT_GCC=g++-5.4.1
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.4.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-5.4.1 --disable-bootstrap CFLAGS='-O2 -march=native'
CXXFLAGS='-O2 -march=native'
Thread model: posix
gcc version 5.4.1 20160829 (GCC)

$ g++-6.2.1 -v
Using built-in specs.
COLLECT_GCC=g++-6.2.1
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-6.2.1 --disable-bootstrap CFLAGS='-O2 -march=native'
CXXFLAGS='-O2 -march=native'
Thread model: posix
gcc version 6.2.1 20160831 (GCC)

$ g++-7.0.0 -v
Using built-in specs.
COLLECT_GCC=g++-7.0.0
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --disable-multilib
--program-suffix=-7.0.0 --disable-bootstrap CFLAGS='-O2 -march=native'
CXXFLAGS='-O2 -march=native'
Thread model: posix
gcc version 7.0.0 20160831 (experimental) (GCC)

[Bug c++/77513] -Wzero-as-null-pointer-constant vs 0, nullptr, NULL and __null

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

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

--- Comment #1 from Andreas Schwab  ---
The "3" flag on the line marker marks the following lines as originating from a
system header where warnings are suppressed.  Use -Wsystem-headers to enable
them.

[Bug c++/77513] -Wzero-as-null-pointer-constant vs 0, nullptr, NULL and __null

[petschy at gmail dot com]

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

--- Comment #2 from petschy at gmail dot com ---
I don't want to enable them. The problem is not with too little but too many
warnings.

A snippet from one of the problematic files:

{ NULL, NULL, false, false }

is preprocessed to 

 { 
# 62 "AdsPlugin.cpp" 3 4
  __null
# 62 "AdsPlugin.cpp"
  , 
# 62 "AdsPlugin.cpp" 3 4
__null
# 62 "AdsPlugin.cpp"
, false, false }
};

Here I see the same flags, yet for these two NULLs gcc warns.

[Bug libfortran/77393] [7 Regression] Revision r237735 changed the behavior of F0.0

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #13 from Jerry DeLisle  ---
> Author: jvdelisle
> Date: Tue Sep  6 23:22:26 2016
> New Revision: 240018
>
> URL: https://gcc.gnu.org/viewcvs?rev=240018&root=gcc&view=rev
> Log:
> 2016-09-06  Jerry DeLisle  
>
> PR libgfortran/77393
> * io/write_float.def (build_float_string): Recognize when the
> result will not fit in the user provided, star fill, and exit
> early.
>
> * gfortran.dg/fmt_f0_2.f90: Update test.
> * gfortran.dg/fmt_f0_3.f90: New test.

I've only now managed to test the patch: it passes on both
i386-pc-solaris2.12 and sparc-sun-solaris2.12.

Thanks.
Rainer

[Bug fortran/57117] [OOP] ICE for sourced allocation of a polymorphic entity using TRANSPOSE

[vehre at gcc dot gnu.org]

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

--- Comment #13 from vehre at gcc dot gnu.org ---
Created attachment 39581
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39581&action=edit
Shorter version to fix the issue.

Hi all,

Dominique pointed out, that the patches proposed by Paul conflict with my accaf
patch. I took a look and found a less-intrusive version to fix this issue.

Note!!! This patch is base on my patch for pr72832 available from:

https://gcc.gnu.org/ml/fortran/2016-09/msg7.html

Bootstraps and regtests ok on x86_64-linux/F23. I haven't tested this patch in
combination with my accaf patch yet (time constraints).

- Andre

[Bug fortran/60483] [5/6/7 Regression] No IMPLICIT type error with: ASSOCIATE( X => derived_type() ) [i.e. w/ structure constructor]

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug target/77483] [6/7 regression] gcc.target/i386/mask-unpack.c etc. FAIL

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #5 from H.J. Lu  ---
(In reply to Eric Botcazou from comment #2)
> 
> Well, this patch is a workaround for a pass that wreaks serious havoc except
> on Linux.  Feel free to come up with a better solution...

Is there a bug report?

[Bug c++/77513] -Wzero-as-null-pointer-constant vs 0, nullptr, NULL and __null

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to petschy from comment #0)
> For c++11 and later code, why is NULL defined as __null, rather than nullptr?

Because defining NULL as nullptr would violate the requirements of the
standard, which very intentionally says that NULL is an integral constant
expression, not nullptr.

[Bug target/63346] xserver_xorg-server-1.15.1 crash on RaspberryPi when compiled with gcc-4.9

[ps.report at gmx dot net]

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

--- Comment #5 from Peter Seiderer  ---
Seems to be fixed in 5.4.0, tested with the original buildroot/xserver/dillo
testcase (with up to date buildroot) and the provided fbpict.c testcase.

[Bug fortran/57117] [OOP] ICE for sourced allocation of a polymorphic entity using TRANSPOSE

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres  ---
> Created attachment 39581 [details]
> Shorter version to fix the issue.
> ...

The patch fixes the ICEs, but generates wrong-code for the original test: the
output at run time is

 FAIL:  T T T T F T T T T T T T T T T

Same thing for the test in comment 5:

 ti
   1.2.3.  
 4.5.6.   
7.8.9. 
 ri
   1.2.3.  
 4.5.0.   
0.0.0. 
   1   2   3   4   0   0   
   0   0   0

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

[asolokha at gmx dot com]

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

Bug ID: 77514
   Summary: [7 Regression] ICE in VN_INFO_GET, at
tree-ssa-sccvn.c:406 w/ -O2 (and above)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-7.0.0-alpha20160904 ICEs when compiling the following reduces snippet at
-O2 (-O3, -Ofast):

void
m1 (char l0, char e8, int hw)
{
  char *rs = &l0;

 yu:
  l0 = 1;
  while (l0 != 0)
{
  l0 = -l0;
  l0 += (*rs ^ (l0 &= 1));
}
  for (;;)
{
  if (hw != 0)
goto yu;
  rs = &e8;
}
}


% gcc-7.0.0-alpha20160904 -O2 -c nhbgsfda.c -Wall -Wextra -Wpedantic
nhbgsfda.c: In function 'm1':
nhbgsfda.c:11:10: warning: operation on 'l0' may be undefined
[-Wsequence-point]
   l0 += (*rs ^ (l0 &= 1));
  ^~
nhbgsfda.c:2:1: internal compiler error: in VN_INFO_GET, at
tree-ssa-sccvn.c:406
 m1 (char l0, char e8, int hw)
 ^~

[Bug middle-end/77515] New: GCC fusing of multiply-add ["FMA"] occurring at "-O3" withOUT "-ffast-math" and withOUT "-ffp-contract=fast"

[abe_skolnik at yahoo dot com]

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

Bug ID: 77515
   Summary: GCC fusing of multiply-add ["FMA"] occurring at "-O3"
withOUT "-ffast-math" and withOUT "-ffp-contract=fast"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abe_skolnik at yahoo dot com
  Target Milestone: ---

In GCC, on both x86_64 and AArch64, fusing of multiply-add ["FMA"] is occurring
at "-O3" withOUT "-ffast-math" and withOUT "-ffp-contract=fast".  This seems to
be in violation of preservation of exactly the same results as "-O2" and lower
without those "-f<...>" flags, since the fusing may result in higher precision
and therefor different results.

Clang/LLVM without "-f<...>" flags, on both x86_64 and AArch64, only performs
fusing at "-Ofast", not at "-O3".



fma_test.c
--
double fma(double a, double b, double c) {
  return a*b+c;
}



example console log
---
> clang_amd64 -march=haswell -O3fma_test.c -S -o - |  grep -c fmadd
0
> clang_amd64 -march=haswell -O3fma_test.c -S -o - | egrep -c 
> '(addsd|mulsd)'
2

> clang_amd64 -march=haswell -Ofast fma_test.c -S -o - |  grep -c fmadd
1
> clang_amd64 -march=haswell -Ofast fma_test.c -S -o - | egrep -c 
> '(addsd|mulsd)'
0

> clang_aarch64  -O3fma_test.c -S -o - |  grep -c fmadd
0
> clang_aarch64  -O3fma_test.c -S -o - | egrep -c '(fadd|fmul)'
2

> clang_aarch64  -Ofast fma_test.c -S -o - |  grep -c fmadd
1
> clang_aarch64  -Ofast fma_test.c -S -o - | egrep -c '(fadd|fmul)'
0

> gcc_aarch64-O3fma_test.c -S -o - |  grep -c fmadd
1
> gcc_aarch64-O3fma_test.c -S -o - | egrep -c '(fadd|fmul)'
0

> gcc_amd64   -march=haswell -O3fma_test.c -S -o - | grep -c fmadd
1
> gcc_amd64   -march=haswell -O3fma_test.c -S -o - | egrep -c 
> '(addsd|mulsd)'
0

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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-07
 CC||trippels at gcc dot gnu.org
Summary|[7 Regression] ICE in   |[6/7 Regression] ICE in
   |VN_INFO_GET, at |VN_INFO_GET, at
   |tree-ssa-sccvn.c:406 w/ -O2 |tree-ssa-sccvn.c:406 w/ -O2
   |(and above) |(and above)
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
gcc-6 is also affected. 
Git blame points to r228320.

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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #2 from Markus Trippelsdorf  ---
On the other hand: l0 += (*rs ^ (l0 &= 1));
looks like undefined behavior.

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

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
(In reply to avieira from comment #9)
> > > So I dont know... Only thing I can think of is better "value-range"-like
> > > analysis for combine, but that might be too costly?

That is what nonzero_bits etc. is about.  We could do much better nowadays
with the generic DF framework.

> > So we are not really looking for combine to combine the shift stmt
> > with the xor stmt?  Because combine doesn't consider that because of
> > the multi-use.
> 
> AFAIK, combine will not combine the shift and xor because they are in
> different basic blocks. The multi-use prevents it from tracking the origin
> of r112 back to a point where it knows that it its higher bits are all 0.

Yes.  Cross BB prevents combining insns; multiple use does not (but it
does of course make it less likely, and you typically get a 3->2 combination).

Is code hoisting making the code better at all here?  (At RTL level)

[Bug middle-end/77515] GCC fusing of multiply-add ["FMA"] occurring at "-O3" withOUT "-ffast-math" and withOUT "-ffp-contract=fast"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
GCC enables it with -O2 not just -O3.
GCC also defaults to -ffp-contract=on.

This has been true since 2.95.3 or even earlier (most likely ever since PowerPC
support was added).

[Bug middle-end/77515] GCC fusing of multiply-add ["FMA"] occurring at "-O3" withOUT "-ffast-math" and withOUT "-ffp-contract=fast"

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
>This seems to be in violation of preservation of exactly the same results

Huh?  Where did you read that?  

Also GCC defaults not to on but to:
-ffp-contract=fast


Read:
https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#index-ffp-contract-715

Where it says that :).

[Bug bootstrap/30136] bootstrap fail for 4.3-20061209

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
So let's close as invalid then.

[Bug target/63346] xserver_xorg-server-1.15.1 crash on RaspberryPi when compiled with gcc-4.9

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.4

--- Comment #6 from Andrew Pinski  ---
Fixed then.

[Bug target/60918] [mips] unaligned memory copy with LWL/LWR

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
This code is correct because GCC assumes memcpy is used on normal memory.
If you use memcpy on non-normal memory you should not be using memcpy here.

   0: 8c04123c  lw  a0,4668(zero)
   4: 3c021234  lui v0,0x1234
   8: 24425678  addiu v0,v0,22136
   c: 8c031240  lw  v1,4672(zero)
  10: ac82  sw  v0,0(a0)
  14: 8885  lwl a1,0(a0)  -> first access: LWL command
  18: 1021  move  v0,zero
  1c: 98850003  lwr a1,3(a0)  -> second access: LWR command
  20:   nop
  24: a865  swl a1,0(v1)  -> for store operation the same procedure
  28: 03e8  jr  ra
  2c: b8650003  swr a1,3(v1)  -> second store command

[Bug fortran/77516] New: ICE in is_gimple_min_invariant, at gimple-expr.c:706

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

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

Bug ID: 77516
   Summary: ICE in is_gimple_min_invariant, at gimple-expr.c:706
   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: ---

Invalid code with a zero or negative safelen value.
Affects versions 5, 6, 7 (not supported below 5) at -Os, -O1 or higher.


$ cat z1.f90
program p
   integer :: i, x
   x = 0
!$omp simd safelen(0) reduction(+:x)
   do i = 1, 8
  x = x + 1
   end do
   print *, x
end


$ gfortran-7-20160904 -O2 -fopenmp z1.f90
z1.f90:4:0:

 !$omp simd safelen(0) reduction(+:x)

internal compiler error: Segmentation fault
0xc2100f crash_signal
../../gcc/toplev.c:336
0x98a370 is_gimple_min_invariant(tree_node const*)
../../gcc/gimple-expr.c:706
0x9bc9d0 gimplify_compound_lval
../../gcc/gimplify.c:2208
0x9b394a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:10495
0x9c6ab5 gimplify_modify_expr
../../gcc/gimplify.c:4824
0x9b578a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:10543
0x9b8ae6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:5805
0x9b9621 gimplify_and_add(tree_node*, gimple**)
../../gcc/gimplify.c:427
0x9b9621 gimplify_assign(tree_node*, tree_node*, gimple**)
../../gcc/gimplify.c:12062
0xb26abb lower_rec_input_clauses
../../gcc/omp-low.c:5249
0xb2b8b9 lower_omp_for
../../gcc/omp-low.c:15131
0xb1b946 lower_omp_1
../../gcc/omp-low.c:17041
0xb1b946 lower_omp
../../gcc/omp-low.c:17178
0xb1aadc lower_omp_1
../../gcc/omp-low.c:17017
0xb1aadc lower_omp
../../gcc/omp-low.c:17178
0xb1b47c lower_omp_1
../../gcc/omp-low.c:17026
0xb1b47c lower_omp
../../gcc/omp-low.c:17178
0xb2265f execute_lower_omp
../../gcc/omp-low.c:17913
0xb2265f execute
../../gcc/omp-low.c:17950

[Bug fortran/77517] New: ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

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

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

Bug ID: 77517
   Summary: ICE in conv_intrinsic_move_alloc, at
fortran/trans-intrinsic.c:9517
   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: ---

Invalid code with a name conflict between variable and subroutine.
Affects versions 5, 6, 7 :


$ cat z1.f90
program p
   class(*), allocatable :: a, b
   call move_alloc (a, b)
contains
   subroutine b
   end
end


$ gfortran-7-20160904 z1.f90
z1.f90:3:0:

call move_alloc (a, b)

internal compiler error: in conv_intrinsic_move_alloc, at
fortran/trans-intrinsic.c:9517
0x77fe2e conv_intrinsic_move_alloc
../../gcc/fortran/trans-intrinsic.c:9516
0x77fe2e gfc_conv_intrinsic_subroutine(gfc_code*)
../../gcc/fortran/trans-intrinsic.c:9770
0x7229f2 trans_code
../../gcc/fortran/trans.c:1746
0x7517a8 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6224
0x6dd050 translate_all_program_units
../../gcc/fortran/parse.c:5911
0x6dd050 gfc_parse_file()
../../gcc/fortran/parse.c:6117
0x71f602 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

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

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

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

Similar with subroutine named "a" :


$ cat z2.f90
program p
   class(*), allocatable :: a, b
   call move_alloc (a, b)
contains
   subroutine a
   end
end


$ gfortran-7-20160904 z2.f90
f951: internal compiler error: Invalid expression in gfc_element_size.
0x68953f gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1317
0x71304b gfc_element_size(gfc_expr*)
../../gcc/fortran/target-memory.c:126
0x671517 find_intrinsic_vtab
../../gcc/fortran/class.c:2583
0x671517 gfc_find_vtab(gfc_typespec*)
../../gcc/fortran/class.c:2725
0x66703d gfc_check_move_alloc(gfc_expr*, gfc_expr*)
../../gcc/fortran/check.c:3347
0x6a4f87 gfc_intrinsic_sub_interface(gfc_code*, int)
../../gcc/fortran/intrinsic.c:4676
0x6f2972 resolve_unknown_s
../../gcc/fortran/resolve.c:3356
0x6f2972 resolve_call
../../gcc/fortran/resolve.c:3472
0x6ef8c0 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:10733
0x6f1cb2 resolve_codes
../../gcc/fortran/resolve.c:15697
0x6f1dae gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:15732
0x6dce7a resolve_all_program_units
../../gcc/fortran/parse.c:5850
0x6dce7a gfc_parse_file()
../../gcc/fortran/parse.c:6102
0x71f602 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug fortran/77517] ICE in conv_intrinsic_move_alloc, at fortran/trans-intrinsic.c:9517

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

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

--- Comment #2 from Gerhard Steinmetz  
---

For completeness, older versions below 5 give :


$ gfortran-4.9 z1.f90
z1.f90:3.20:

   call move_alloc (a, b)
1
Error: 'from' argument of 'move_alloc' intrinsic at (1) must be the same type
and kind as 'to'


$ gfortran-4.9 z2.f90
z2.f90:1.9:

program p
 1
Internal Error at (1):
Invalid expression in gfc_element_size.


$ gfortran-4.8 z2.f90
z2.f90: In function 'p':
z2.f90:1:0: internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1136
 program p
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

---


Backup, now silently accepted :

program p
   class(*), allocatable :: a, b
contains
   subroutine b
   end
end

program p
   class(*), allocatable :: a, b
contains
   subroutine a
   end
end

program p
   class(*), allocatable :: a, b
contains
   function b()
   end
end

program p
   class(*), allocatable :: a, b
contains
   function a()
   end
end

[Bug fortran/77518] New: ICE in gfc_advance_chain, at fortran/trans.c:58

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

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

Bug ID: 77518
   Summary: ICE in gfc_advance_chain, at fortran/trans.c:58
   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: ---

Compiles with 4.8/4.9, aborts with versions 5/6/7 :


$ cat z1.f90
program p
   type t
   end type
   class(t), allocatable :: z[:]
   print *, sizeof(z)
end


$ gfortran-7-20160904 -fcoarray=single z1.f90
z1.f90:5:0:

print *, sizeof(z)

internal compiler error: in gfc_advance_chain, at fortran/trans.c:58
0x72227b gfc_advance_chain(tree_node*, int)
../../gcc/fortran/trans.c:58
0x755d5f gfc_class_vptr_get(tree_node*)
../../gcc/fortran/trans-expr.c:149
0x756778 class_vtab_field_get
../../gcc/fortran/trans-expr.c:222
0x756778 gfc_class_vtab_size_get(tree_node*)
../../gcc/fortran/trans-expr.c:255
0x77b8e9 gfc_conv_intrinsic_sizeof
../../gcc/fortran/trans-intrinsic.c:6006
0x783d6b gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:8276
0x760f72 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7602
0x767ca8 gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7737
0x78aa06 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2459
0x7227d7 trans_code
../../gcc/fortran/trans.c:1886
0x787828 build_dt
../../gcc/fortran/trans-io.c:1958
0x7227f7 trans_code
../../gcc/fortran/trans.c:1858
0x7517a8 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6224
0x6dd050 translate_all_program_units
../../gcc/fortran/parse.c:5911
0x6dd050 gfc_parse_file()
../../gcc/fortran/parse.c:6117
0x71f602 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

[Bug tree-optimization/67971] Failure to unify conditional argument selection with conditional result selection

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Note we should able to optimize this just to
int
f1 (int cond, double x, double y)
{ 
  double z1, z2;

  z2 = __builtin_cos (cond ? x : y);
  return z2 == z2;
}


But that is 64700.

[Bug target/77494] -mcpu=cortex-a53 does not allow use of crc extensions

[buzz at exotica dot org.uk]

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

--- Comment #4 from Jools Wills  ---
Thanks - reported here - https://sourceware.org/bugzilla/show_bug.cgi?id=20567

[Bug fortran/77505] Negative character length not treated as LEN=0

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
This is going to require someone smarting than I to fix.
The problem lies in trans-array.c (get_array_ctor_strlen).
This function walks the elments of the array constructor
looking for the string length.  It nave takes into account
the type spec in [character(len=ii) :: ].

[Bug fortran/77505] Negative character length not treated as LEN=0

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #2 from Steve Kargl  ---
On Wed, Sep 07, 2016 at 07:01:40PM +, kargl at gcc dot gnu.org wrote:
> --- Comment #1 from kargl at gcc dot gnu.org ---
> This is going to require someone smarting than I to fix.
> The problem lies in trans-array.c (get_array_ctor_strlen).
> This function walks the elments of the array constructor
> looking for the string length.  It nave takes into account
> the type spec in [character(len=ii) :: ].

s/nave/never

Note, the problem may actually be in some other function
that calls get_array_ctor_strlen, because this function
never have been called!

[Bug c++/77513] -Wzero-as-null-pointer-constant vs 0, nullptr, NULL and __null

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to petschy from comment #2)
> Here I see the same flags, yet for these two NULLs gcc warns.

prog.cc:6:28: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
 , false, false };
^

because the location given is wrong, so the location in this case is not within
the system-header flags. If the location was right (under __null), it would not
warn. That is the bug.

[Bug c++/33952] -Wfatal-errors truncates multi-line error messages.

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Richard Biener from comment #3)
> Apart from the issue regarding that the last two errors should be notes this
> is really impossible to "fix" if -Wfatal-errors should continue to work as
> designed.  That is, the only way would be to annotate all _callers_ of
> diagnostic
> functions to eventually terminate compilation, which is a too large overhead
> really.

Well, the fix is clear. A diagnostic should be an error/warning/sorry/... plus
one or more notes. The API should allow attaching notes to diagnostics and
everything is emitted at once. Clear but not easy to implement because of how
diagnostics work right now.

The second and third error are notes now, so using -fmax-errors=2 will print
the whole message and stop before the next error.

A hackish fix would be for -Wfatal-errors to check before emitting another
diagnostic (except notes) and stop if the numbers of errors is already 1. That
is better than -fmax-errors=2, since the latter will continue until the next
error, printing warnings along the way.

[Bug fortran/77504] "is used uninitialized" with allocatable string and array constructors

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez  ---
If you do

gfortran -Wuninitialized test.f90 -fdump-tree-all-all-lineno

and look at test.f90.004t.gimple

you'll see that gfortran generates gimple such as:

  [test.f90:3:0] D.3445 = (sizetype) .help_textD.3381;
  [test.f90:3:0] D.3446 = (bitsizetype) D.3445;
  [test.f90:3:0] D.3438 = D.3446 * 8;
  [test.f90:3:0] D.3439 = (sizetype) .help_textD.3381;
  [test.f90:3:0] [test.f90:3:0] help_textD.3396.dataD.3382 = 0B;

I don't know much about Fortran or gfortran, but that is clearly using an
uninitialized value .help_text.

Interestingly, none of the D.* variables above are used for anything else, so I
wonder what is the purpose of that code.

[Bug fortran/56670] Allocatable-length character var causes bogus warning with -Wall

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Rich Townsend from comment #0)
> ...causes the following bogus warning:

If you compile with -fdump-tree-all-all-lineno and look at test.f90.004t.gimple
you'll see that gfortran generates:

  [test.f90:5:0] name_formatD.3382 = 0B;
  [test.f90:7:0] {
integer(kind=4)D.8 D.3383;

[test.f90:7:0] if (name_formatD.3382 != 0B) goto L.1D.3384; else goto
;
...
L.1D.3384:
[test.f90:7:0] if (.name_formatD.3381 == 0) goto L.2D.3385; else goto
;

If the last line is reached, then .name_format is used uninitialized. This
cannot happen here, because the first 'if' is always false. However, GCC does
not know that without the analysis done when using optimization. With -O1 there
is no warning.

(That code is quite strange, why test for != 0B after initializing it to 0B?)

> uninit_test.f90: In function ‘uninit_test’:
> uninit_test.f90:7:0: warning: ‘.name_format’ may be used uninitialized in
> this function [-Wmaybe-uninitialized]
>name_format = ''
>  ^
> 
> (Note also that the warning arises in the main program, and not in a
> function as the message suggests).

This is the output in a modern gfortran (with colors!):

test.f90:7:0:

   name_format = ''
 ^
Warning: ‘.name_format’ may be used uninitialized in this function
[-Wmaybe-uninitialized]

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

[clyon at gcc dot gnu.org]

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

--- Comment #4 from Christophe Lyon  ---
Author: clyon
Date: Wed Sep  7 20:18:17 2016
New Revision: 240030

URL: https://gcc.gnu.org/viewcvs?rev=240030&root=gcc&view=rev
Log:
PR middle-end/77475: Fix AArch64 testcases.

2016-09-07  Jakub Jelinek  

PR middle-end/77475
* gcc.target/aarch64/arch-diagnostics-1.c: Expect error on line 0.
* gcc.target/aarch64/arch-diagnostics-2.c: Likewise.
* gcc.target/aarch64/cpu-diagnostics-1.c: Likewise.
* gcc.target/aarch64/cpu-diagnostics-2.c: Likewise.
* gcc.target/aarch64/cpu-diagnostics-3.c: Likewise.
* gcc.target/aarch64/cpu-diagnostics-4.c: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/arch-diagnostics-1.c
trunk/gcc/testsuite/gcc.target/aarch64/arch-diagnostics-2.c
trunk/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-1.c
trunk/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-2.c
trunk/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-3.c
trunk/gcc/testsuite/gcc.target/aarch64/cpu-diagnostics-4.c

[Bug fortran/66459] bogus warning 'w.offset' may be used uninitialized in this function [-Wmaybe-uninitialized]

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  ---
If you do

gfortran -Wuninitialized test.f90 -fdump-tree-all-all-lineno -O1

and look at test.f90.162t.uninit1, we see:

  # .MEM_24 = PHI <.MEM_15(D)(28), .MEM_68(37)>
  # w$dim$1$stride_46 = PHI 
  # w$offset_26 = PHI 

but this code is transformed by optimization. The unoptimized SSA contains:

  [test.f90:9:0] # VUSE <.MEM_18>
  _22 = [test.f90:9:0] *m_21(D);
  [test.f90:9:0] _23 = MAX_EXPR <_22, 0>;
  [test.f90:9:0] _24 = (integer(kind=8)D.9) _23;
...
  [test.f90:9:0] _39 = _24;
...
  [test.f90:9:0] _68 = ~_39;
...
  [test.f90:9:0] wD.3400.offsetD.3387 = _68;

and the gimple generated by Fortran contains something similar:

[test.f90:9:0] D.3429 = [test.f90:9:0] *mD.3381;
[test.f90:9:0] D.3430 = MAX_EXPR ;
[test.f90:9:0] D.3402 = (integer(kind=8)D.9) D.3430;

It seems that *mD.3381 is not initialized.

(It is very strange that gfortran converts user-defined variables to lowercase.
It makes reading the dumps more difficult. It also does many unnecessary
copies, making the code harder to analyze.)

[Bug libgcc/77519] New: [5/6/7 Regression] complex multiply / divide excess precision handling inverted

[jsm28 at gcc dot gnu.org]

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

Bug ID: 77519
   Summary: [5/6/7 Regression] complex multiply / divide excess
precision handling inverted
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

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

[Bug c/77520] New: wrong value for extended ASCII characters in -Wformat message

[msebor at gcc dot gnu.org]

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

Bug ID: 77520
   Summary: wrong value for extended ASCII characters in -Wformat
message
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The argument_parser::find_format_char_info function is c-family/c-format.c
passes the value of an unexpected format character whose type is char as an
argument to a %x directive.  When char is a signed type and the value is in the
extended ASCII range ('\x80' and greater) it is sign-extended and yields a very
large value on output as in the test case below.  The character should be cast
to unsigned char to avoid the sign extension.  The following test case shows
the problem:

$ cat t.c && /home/msebor/build/gcc-49905/gcc/xgcc
-B/home/msebor/build/gcc-49905/gcc -S -Wformat t.c
void f (void)
{
  __builtin_printf ("%\x80");
}
t.c: In function ‘f’:
t.c:3:23: warning: unknown conversion type character 0xff80 in format
[-Wformat=]
   __builtin_printf ("%\x80");
   ^~~~

Clang produces better output:

t.c:3:23: warning: invalid conversion specifier '\x80'

[Bug c/77520] wrong value for extended ASCII characters in -Wformat message

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |minor

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

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #1 from Joseph S. Myers  ---
Correction: only multiply is affected, not divide.

[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)

[pault at gcc dot gnu.org]

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

--- Comment #19 from Paul Thomas  ---
Author: pault
Date: Wed Sep  7 21:21:16 2016
New Revision: 240032

URL: https://gcc.gnu.org/viewcvs?rev=240032&root=gcc&view=rev
Log:
2016-09-07  Dominique Dhumieres  

PR fortran/48298
* gfortran.dg/assumed_rank_12.f90: Correct tree scan.
* gfortran.dg/assumed_type_2.f90: Correct tree scans.
* gfortran.dg/coarray_lib_comm_1.f90: Likewise.
* gfortran.dg/coarray_lib_this_image_2.f90: Likewise.
* gfortran.dg/coarray_lock_7.f90: Likewise.
* gfortran.dg/coarray_stat_function.f90: Likewise.
* gfortran.dg/no_arg_check_2.f90: Likewise.
* gfortran.dg/pr32921.f: Likewise.

Modified:
branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev
branches/fortran-dev/gcc/testsuite/gfortran.dg/assumed_rank_12.f90
branches/fortran-dev/gcc/testsuite/gfortran.dg/assumed_type_2.f90
branches/fortran-dev/gcc/testsuite/gfortran.dg/coarray_lib_comm_1.f90
branches/fortran-dev/gcc/testsuite/gfortran.dg/coarray_lib_this_image_2.f90
branches/fortran-dev/gcc/testsuite/gfortran.dg/coarray_lock_7.f90
branches/fortran-dev/gcc/testsuite/gfortran.dg/coarray_stat_function.f90
branches/fortran-dev/gcc/testsuite/gfortran.dg/no_arg_check_2.f90
branches/fortran-dev/gcc/testsuite/gfortran.dg/pr32921.f

[Bug c++/71710] [7 Regression] ICE on valid C++11 code with decltype and alias template: in lookup_member, at cp/search.c:1255

[su at cs dot ucdavis.edu]

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

--- Comment #3 from Zhendong Su  ---
A related, but simpler test that triggers the same ICE: 





template < typename > struct A
{
  A a;
  template < int > using B = decltype (a);
  B < 0 > b;
};

[Bug c/77521] New: %qc format directive should quote non-printable characters

[msebor at gcc dot gnu.org]

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

Bug ID: 77521
   Summary: %qc format directive should quote non-printable
characters
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The GCC-specific %qc format directive prints its character argument in quotes. 
One might expect the directive to quote non-printable characters similarly to
the %s directive but that's not what happens.  %qc prints the character as is. 
As a result, callers of the warning_at and error APIs that use the %qc
directive must be careful not to call it with non-printable characters (for
instance, by using the ISGRAPH() macro as done in c-family/c-format.c) and use
a different directive for those.  Those that don't might end up corrupting the
compiler stderr output as in the test case below.  Those that are careful end
up using a different alternate directive (e.g., %x or %o) resulting in
inconsistent diagnostics.

This bug is to change the %qc directive in the GCC pretty printer to format
non-printable characters using some other directive than the C %c (for example,
"\x%x" as done in c-family/c-format.c).

$ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wformat t.c
void g (int foo, int bar)
{
  asm ("combine %2, %0" : "=r" (foo) : "0" (foo), "\n" (bar));
}
t.c: In function ‘g’:
t.c:3:3: error: invalid punctuation ‘
’ in constraint
   asm ("combine %2, %0" : "=r" (foo) : "0" (foo), "\n" (bar));
   ^~~
t.c:3:3: error: invalid punctuation ‘
’ in constraint


The following is a list of GCC formatted output functions with the %qc
directive:

find gcc -name "*.c" ! -path "*/testsuite/*" | xargs grep "%qc")
gcc/fortran/io.c:  const char *unexpected_element  = _("Unexpected element %qc
in format "
gcc/fortran/matchexp.c: gfc_error ("Bad character %qc in OPERATOR name at %C",
name[i]);
gcc/fortran/symbol.c: gfc_error ("Letter %qc already set in IMPLICIT
statement at %C",
gcc/fortran/symbol.c: gfc_error ("Letter %qc already has an IMPLICIT
type at %C",
gcc/c-family/c-lex.c: error_at (*loc, "stray %qc in program", (int) c);
gcc/c-family/c-format.c:" %qc in format",
gcc/c-family/c-format.c:  "use of %qs length
modifier with %qc type"
grep: gcc/cp/.#decl.c: No such file or directory
gcc/stmt.c: warning (0, "output constraint %qc for operand %d "
gcc/stmt.c: error ("input operand constraint contains %qc",
constraint[j]);
gcc/stmt.c: error ("invalid punctuation %qc in constraint",
constraint[j]);
gcc/config/mmix/mmix.c:  internal_error ("MMIX Internal: Missing %qc case
in mmix_print_operand", code);
gcc/config/avr/driver-avr.c:error ("strange device name %qs after %qs:
bad character %qc",
gcc/gcc.c:  error ("spec failure: unrecognized spec option %qc", c);
gcc/gcc.c:  fatal_error (input_location, "braced spec %qs is invalid at %qc",
orig, *p);

[Bug fortran/77507] gfortran rejects keyworded calls to procedures from intrinsic modules

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
This should have been 2 separate bug reports as ieee support
is distinct from ISO C binding support.  This patch fixes
the latter, but cannot be committed because you've tied it
to the former.

Index: intrinsic.c
===
--- intrinsic.c (revision 240029)
+++ intrinsic.c (working copy)
@@ -1239,7 +1239,8 @@ add_functions (void)
 *z = "z", *ln = "len", *ut = "unit", *han = "handler",
 *num = "number", *tm = "time", *nm = "name", *md = "mode",
 *vl = "values", *p1 = "path1", *p2 = "path2", *com = "command",
-*ca = "coarray", *sub = "sub", *dist = "distance", *failed="failed";
+*ca = "coarray", *sub = "sub", *dist = "distance", *failed="failed",
+*c_ptr_1 = "c_ptr_1", *c_ptr_2 = "c_ptr_2";

   int di, dr, dd, dl, dc, dz, ii;

@@ -2914,8 +2915,8 @@ add_functions (void)
   /* The following functions are part of ISO_C_BINDING.  */
   add_sym_2 ("c_associated", GFC_ISYM_C_ASSOCIATED, CLASS_INQUIRY, ACTUAL_NO,
 BT_LOGICAL, dl, GFC_STD_F2003, gfc_check_c_associated, NULL, NULL,
-"C_PTR_1", BT_VOID, 0, REQUIRED,
-"C_PTR_2", BT_VOID, 0, OPTIONAL);
+c_ptr_1, BT_VOID, 0, REQUIRED,
+c_ptr_2, BT_VOID, 0, OPTIONAL);
   make_from_module();

   add_sym_1 ("c_loc", GFC_ISYM_C_LOC, CLASS_INQUIRY, ACTUAL_NO,

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

[jsm28 at gcc dot gnu.org]

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

--- Comment #2 from Joseph S. Myers  ---
Author: jsm28
Date: Wed Sep  7 23:02:56 2016
New Revision: 240033

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

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

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

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

New sizes:

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

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

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/libgcc2.c

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

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

   Target Milestone|--- |5.5
Summary|[5/6/7 Regression] complex  |[5/6 Regression] complex
   |multiply excess precision   |multiply excess precision
   |handling inverted   |handling inverted

--- Comment #3 from Joseph S. Myers  ---
Fixed for GCC 7.  Not yet fixed for GCC 5 or 6.

[Bug fortran/77507] gfortran rejects keyworded calls to procedures from intrinsic modules

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #2 from Steve Kargl  ---
On Wed, Sep 07, 2016 at 10:12:22PM +, kargl at gcc dot gnu.org wrote:
>
> This should have been 2 separate bug reports as ieee support
> is distinct from ISO C binding support.  This patch fixes
> the latter, but cannot be committed because you've tied it
> to the former.
> 

This appears to fix both issues.

Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c (revision 240029)
+++ gcc/fortran/intrinsic.c (working copy)
@@ -1239,7 +1239,8 @@ add_functions (void)
 *z = "z", *ln = "len", *ut = "unit", *han = "handler",
 *num = "number", *tm = "time", *nm = "name", *md = "mode",
 *vl = "values", *p1 = "path1", *p2 = "path2", *com = "command",
-*ca = "coarray", *sub = "sub", *dist = "distance", *failed="failed";
+*ca = "coarray", *sub = "sub", *dist = "distance", *failed="failed",
+*c_ptr_1 = "c_ptr_1", *c_ptr_2 = "c_ptr_2";

   int di, dr, dd, dl, dc, dz, ii;

@@ -2914,8 +2915,8 @@ add_functions (void)
   /* The following functions are part of ISO_C_BINDING.  */
   add_sym_2 ("c_associated", GFC_ISYM_C_ASSOCIATED, CLASS_INQUIRY, ACTUAL_NO,
 BT_LOGICAL, dl, GFC_STD_F2003, gfc_check_c_associated, NULL, NULL,
-"C_PTR_1", BT_VOID, 0, REQUIRED,
-"C_PTR_2", BT_VOID, 0, OPTIONAL);
+c_ptr_1, BT_VOID, 0, REQUIRED,
+c_ptr_2, BT_VOID, 0, OPTIONAL);
   make_from_module();

   add_sym_1 ("c_loc", GFC_ISYM_C_LOC, CLASS_INQUIRY, ACTUAL_NO,
Index: libgfortran/ieee/ieee_arithmetic.F90
===
--- libgfortran/ieee/ieee_arithmetic.F90(revision 240029)
+++ libgfortran/ieee/ieee_arithmetic.F90(working copy)
@@ -857,12 +857,12 @@ contains

   ! IEEE_VALUE

-  elemental real(kind=4) function IEEE_VALUE_4(X, C) result(res)
-implicit none
+  elemental real(kind=4) function IEEE_VALUE_4(X, CLASS) result(res)
+
 real(kind=4), intent(in) :: X
-type(IEEE_CLASS_TYPE), intent(in) :: C
+type(IEEE_CLASS_TYPE), intent(in) :: CLASS

-select case (C%hidden)
+select case (CLASS%hidden)
   case (1) ! IEEE_SIGNALING_NAN
 res = -1
 res = sqrt(res)
@@ -895,12 +895,12 @@ contains
  end select
   end function

-  elemental real(kind=8) function IEEE_VALUE_8(X, C) result(res)
-implicit none
+  elemental real(kind=8) function IEEE_VALUE_8(X, CLASS) result(res)
+
 real(kind=8), intent(in) :: X
-type(IEEE_CLASS_TYPE), intent(in) :: C
+type(IEEE_CLASS_TYPE), intent(in) :: CLASS

-select case (C%hidden)
+select case (CLASS%hidden)
   case (1) ! IEEE_SIGNALING_NAN
 res = -1
 res = sqrt(res)
@@ -934,12 +934,12 @@ contains
   end function

 #ifdef HAVE_GFC_REAL_10
-  elemental real(kind=10) function IEEE_VALUE_10(X, C) result(res)
-implicit none
+  elemental real(kind=10) function IEEE_VALUE_10(X, CLASS) result(res)
+
 real(kind=10), intent(in) :: X
-type(IEEE_CLASS_TYPE), intent(in) :: C
+type(IEEE_CLASS_TYPE), intent(in) :: CLASS

-select case (C%hidden)
+select case (CLASS%hidden)
   case (1) ! IEEE_SIGNALING_NAN
 res = -1
 res = sqrt(res)
@@ -971,15 +971,16 @@ contains
 res = 0
  end select
   end function
+
 #endif

 #ifdef HAVE_GFC_REAL_16
-  elemental real(kind=16) function IEEE_VALUE_16(X, C) result(res)
-implicit none
+  elemental real(kind=16) function IEEE_VALUE_16(X, CLASS) result(res)
+
 real(kind=16), intent(in) :: X
-type(IEEE_CLASS_TYPE), intent(in) :: C
+type(IEEE_CLASS_TYPE), intent(in) :: CLASS

-select case (C%hidden)
+select case (CLASS%hidden)
   case (1) ! IEEE_SIGNALING_NAN
 res = -1
 res = sqrt(res)

[Bug target/77494] -mcpu=cortex-a53 does not allow use of crc extensions

[rearnsha at gcc dot gnu.org]

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

--- Comment #5 from Richard Earnshaw  ---
(In reply to Jools Wills from comment #4)
> Thanks - reported here -
> https://sourceware.org/bugzilla/show_bug.cgi?id=20567

And already fixed in GAS earlier today.

[Bug target/77494] -mcpu=cortex-a53 does not allow use of crc extensions

[buzz at exotica dot org.uk]

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

--- Comment #6 from Jools Wills  ---
Thanks for the fix - I'll mark the other bug as resolved.

[Bug fortran/77507] gfortran rejects keyworded calls to procedures from intrinsic modules

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

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

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

[su at cs dot ucdavis.edu]

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

Bug ID: 77522
   Summary: ICE on invalid code C++14 code: in tsubst_decl, at
cp/pt.c:12447
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

It affects 4.9.x and later, which have C++14 support. 


$ g++-trunk -c -std=c++14 small.cpp
small.cpp: In instantiation of ‘f(T):: [with T = int]’:
small.cpp:3:18:   required from ‘struct f(T) [with T = int]::’
small.cpp:3:8:   required from ‘void f(T) [with T = int]’
small.cpp:8:7:   required from here
small.cpp:3:24: error: use of ‘f(T) [with T = int]__a’ before
deduction of ‘auto’
   auto g = [&a = f] () {};
^
small.cpp:3:24: error: use of ‘f(T) [with T = int]__a’ before
deduction of ‘auto’
small.cpp:3:24: internal compiler error: in tsubst_decl, at cp/pt.c:12447
0x6fe7c6 tsubst_decl
../../gcc-source-trunk/gcc/cp/pt.c:12447
0x6f32de tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:12907
0x6e07fa tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15284
0x6dfa43 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15419
0x6dd120 instantiate_decl(tree_node*, int, bool)
../../gcc-source-trunk/gcc/cp/pt.c:22159
0x7266b5 instantiate_class_template_1
../../gcc-source-trunk/gcc/cp/pt.c:10346
0x7266b5 instantiate_class_template(tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:10416
0x7cbf13 complete_type(tree_node*)
../../gcc-source-trunk/gcc/cp/typeck.c:133
0x6eaf2c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-source-trunk/gcc/cp/pt.c:17269
0x6df247 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15936
0x5df520 tsubst_init
../../gcc-source-trunk/gcc/cp/pt.c:13966
0x6e3144 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15334
0x6dec3b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15228
0x6dfa43 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15419
0x6dd120 instantiate_decl(tree_node*, int, bool)
../../gcc-source-trunk/gcc/cp/pt.c:22159
0x72a5f2 instantiate_pending_templates(int)
../../gcc-source-trunk/gcc/cp/pt.c:22278
0x76f597 c_parse_final_cleanups()
../../gcc-source-trunk/gcc/cp/decl2.c:4617
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$


-


template < class T = int > void f (T)
{ 
  auto g = [&a = f] () {};
}

int main ()
{ 
  f (0);
  return 0;
}

[Bug c++/77523] New: rejects valid C++14 code with initialized lambda capture

[su at cs dot ucdavis.edu]

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

Bug ID: 77523
   Summary: rejects valid C++14 code with initialized lambda
capture
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The code is accepted by both Clang and MSVC (it is derived from PR 77522's
test). 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160907 (experimental) [trunk revision 240025] (GCC) 
$ 
$ clang++ -c -std=c++14 small.cpp
$ 
$ g++-trunk -c -std=c++14 small.cpp
small.cpp: In function ‘void f(T)’:
small.cpp:3:18: error: cannot capture ‘f<>’ by reference
   auto g = [&a = f <>] () {};
  ^~~~
small.cpp: In instantiation of ‘void f(T) [with T = int]’:
small.cpp:8:7:   required from here
small.cpp:3:12: error: cannot bind non-const lvalue reference of type ‘void
(*&)(int)’ to an rvalue of type ‘void (*)(int)’
   auto g = [&a = f <>] () {};
^
$ 


-


template < class T = int > void f (T)
{
  auto g = [&a = f <>] () {};
}

int main ()
{
  f (0);
  return 0; 
}

[Bug preprocessor/53469] #pragma GCC diagnostic works, but using _Pragma doesn't for -Wunused-local-typedefs

[spencer8 at sbcglobal dot net]

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

j8spencer  changed:

   What|Removed |Added

 CC||spencer8 at sbcglobal dot net

--- Comment #4 from j8spencer  ---
I'm still seeing this behavior in 4.8.4.  #pragma can ignore
unused-local-typedefs, _Pragma cannot.  This is on Ubuntu 16.04.  Options are
-fPIE -O3 -NDEBUG -Wall -Wextra -Werror.  Because of -Werror, I also tried
putting in _Pragma ("GCC diagnostic warning \"-Wunused-local-typedefs\"")
before the ignored.  But regular #pragma works just fine.