[Bug middle-end/65950] exit in main is causing the path to it to become unlikely.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #10)
> I am testing it right now.

No regressions so I will submit it over the weekend.

[Bug c++/66333] [C++14] Static constexpr template

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.4

--- Comment #2 from Andrew Pinski  ---
Fixed so closing as such.

[Bug libgcc/63882] internal compiler error: in int_mode_for_mode, at stor-layout.c:395

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Does this work now?

[Bug middle-end/64516] [4.9/5 Regression] arm: wrong unaligned load generated

[markus at oberhumer dot com]

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

--- Comment #8 from Markus F.X.J. Oberhumer  ---
Richard, many thanks for finally fixing this issue.

Will there be a backport to 4.9.4 and/or 5.4 ?

[Bug middle-end/64516] [4.9/5 Regression] arm: wrong unaligned load generated

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Tue, 2 Aug 2016, markus at oberhumer dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64516
> 
> --- Comment #8 from Markus F.X.J. Oberhumer  ---
> Richard, many thanks for finally fixing this issue.
> 
> Will there be a backport to 4.9.4 and/or 5.4 ?

It's too late for 4.9.4 but I will backport for 5.5.

Richard.

[Bug c++/67545] [concepts] Failure to properly substitute template parameters into requires-clause

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||assemble-failure
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-02
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
I get in GCC 6.1:

/tmp/cc5ugLqN.s: Assembler messages:
/tmp/cc5ugLqN.s:68: Error: symbol `_ZNSt12experimental9ranges_v16modelsL4SameE'
is already defined
/tmp/cc5ugLqN.s:84: Error: symbol `_ZNSt12experimental9ranges_v16modelsL4SameE'
is already defined
/tmp/cc5ugLqN.s:88: Error: symbol `_ZNSt12experimental9ranges_v16modelsL4SameE'
is already defined
/tmp/cc5ugLqN.s:92: Error: symbol `_ZNSt12experimental9ranges_v16modelsL4SameE'
is already defined

[Bug tree-optimization/66646] small loop turned into memmove because of tree ldist

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
After commit reordering passes:

commit 410372fef14173261ce8e547db98eafb3174921f
Author: rguenth 
Date:   Thu May 19 07:39:52 2016 +

2016-05-19  Richard Biener  

PR tree-optimization/70729
* passes.def: Move LIM pass before PRE.  Remove no longer
required copyprop and move first DCE out of the loop pipeline.

* gcc.dg/autopar/outer-6.c: Adjust to avoid redundant store.
* gcc.dg/graphite/scop-18.c: Likewise.
* gcc.dg/pr41783.c: Disable LIM.
* gcc.dg/tree-ssa/loadpre10.c: Likewise.
* gcc.dg/tree-ssa/loadpre23.c: Likewise.
* gcc.dg/tree-ssa/loadpre24.c: Likewise.
* gcc.dg/tree-ssa/loadpre25.c: Likewise.
* gcc.dg/tree-ssa/loadpre4.c: Likewise.
* gcc.dg/tree-ssa/loadpre8.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-16.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-18.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-20.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-3.c: Likewise.
* gfortran.dg/pr42108.f90: Likewise.


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

GCC no longer recognizes &a[j]/&a[j-1].  This is because of changed IR.  I will
report another bug for this while keeping this one for track of memcopy
improvement (or ldist).

[Bug bootstrap/25508] MULTILIB_OSDIRNAMES undocumented

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #4 from Andrew Pinski  ---
Fixed so closing.(In reply to jos...@codesourcery.com from comment #3)
> It looks like the documentation was added by
> 
> r193508 | doko | 2012-11-14 21:29:15 + (Wed, 14 Nov 2012) | 36 lines
> 
> but without closing this bug.

Most likely because he did not know there was a bug filed for this.

[Bug tree-optimization/72772] New: Missed SCEV after pass reordering@236440

[amker at gcc dot gnu.org]

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

Bug ID: 72772
   Summary: Missed SCEV after pass reordering@236440
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

For below case
int foo (int flag, char *a)
{  
  short i, j;  
  short l = 0; 
  if (flag == 1)   
l = 3; 

  for (i = 0; i < 4; i++)  
{  
  for (j = l - 1; j > 0; j--)  
a[j] = a[j - 1];   
  a[0] = i;
}  
}

GCC can't recognize &a[j]/&a[j-1] as SCEVs after pass reordering @commit:

commit 410372fef14173261ce8e547db98eafb3174921f
Author: rguenth 
Date:   Thu May 19 07:39:52 2016 +

2016-05-19  Richard Biener  

PR tree-optimization/70729
* passes.def: Move LIM pass before PRE.  Remove no longer
required copyprop and move first DCE out of the loop pipeline.

* gcc.dg/autopar/outer-6.c: Adjust to avoid redundant store.
* gcc.dg/graphite/scop-18.c: Likewise.
* gcc.dg/pr41783.c: Disable LIM.
* gcc.dg/tree-ssa/loadpre10.c: Likewise.
* gcc.dg/tree-ssa/loadpre23.c: Likewise.
* gcc.dg/tree-ssa/loadpre24.c: Likewise.
* gcc.dg/tree-ssa/loadpre25.c: Likewise.
* gcc.dg/tree-ssa/loadpre4.c: Likewise.
* gcc.dg/tree-ssa/loadpre8.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-16.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-18.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-20.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-3.c: Likewise.
* gfortran.dg/pr42108.f90: Likewise.


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


This is because of changed IR, from:

Loop_guard:
  if (prephitmp_41 > 0)
goto ;
  else
goto ;

Preheader:
  :

Loop:
  :
  # j_29 = PHI 
  _3 = (sizetype) j_29;
  _4 = a_21(D) + _3;
  _5 = _3 + 18446744073709551615;
  _6 = a_21(D) + _5;
  _7 = *_6;
  *_4 = _7;
  j.2_8 = (unsigned short) j_29;
  _9 = j.2_8 + 65535;
  j_23 = (short int) _9;
  if (j_23 > 0)
goto ;
  else
goto ;

Latch:
  :
  goto ;


To:
Loop_guard:
  if (prephitmp_43 > 0)
goto ;
  else
goto ;

Preheader:
  :
  # j_16 = PHI 

Loop:
  :
  # j_29 = PHI 
  _3 = (sizetype) j_29;
  _4 = a_21(D) + _3;
  _5 = _3 + 18446744073709551615;
  _6 = a_21(D) + _5;
  _7 = *_6;
  *_4 = _7;
  j.2_8 = (unsigned short) j_29;
  _9 = j.2_8 + 65535;
  j_23 = (short int) _9;
  if (j_23 > 0)
goto ;
  else
goto ;

Latch:
  :
  goto ;

Specifically, simplif_using_initial_conditions failed in this case because it
missed expanding simple operations in single-arg PHI in preheader.

[Bug target/72773] New: AVX512: Invalid operand for vcvttss2siq instruction

[wen...@mitsuba-renderer.org]

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

Bug ID: 72773
   Summary: AVX512: Invalid operand for vcvttss2siq instruction
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wen...@mitsuba-renderer.org
  Target Milestone: ---

Created attachment 39047
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39047&action=edit
Preprocessed file causing the issue

Hi,

I'm running into a pesky AVX512F code generation issue using the latest HEAD
version of gcc on my OSX development machine.
Compiling the attached preprocessed file yields the following error messages:

g++-7 test.i -xc++ -std=c++14 -O3 -DNDEBUG -fomit-frame-pointer -mavx2 -mfma
-mf16c -mavx512f -Wa,-mavx512f

/var/folders/94/rfzxfhbn3hjb4p402lg_yjgwgn/T//cci4IcB4.s:555:14: error:
invalid operand for instruction
vcvttss2siq %xmm18, %rax
^~
/var/folders/94/rfzxfhbn3hjb4p402lg_yjgwgn/T//cci4IcB4.s:559:14: error:
invalid operand for instruction
vcvttss2siq %xmm17, %rax
^~
/var/folders/94/rfzxfhbn3hjb4p402lg_yjgwgn/T//cci4IcB4.s:561:14: error:
invalid operand for instruction
vcvttss2siq %xmm16, %rax
^~

AFAIK on OSX, GCC uses the Clang assembler. There are thus two possibilities:

1. The vcvttss2siq instrunction does not exist for new-style xmm register
arguments, and GCC should not have generated it

2. It is a valid instruction, and it's the Clang assembler's fault for not
recognizing it.

I am not familiar enough with the AVX512F assembly and will create a ticket in
both the GCC and LLVM bugtracker so that this problem can be addressed.

Details on my compiler version:

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

[Bug target/72773] AVX512: Invalid operand for vcvttss2siq instruction

[wen...@mitsuba-renderer.org]

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

--- Comment #1 from Wenzel Jakob  ---
The LLVM ticket is here: https://llvm.org/bugs/show_bug.cgi?id=28810

[Bug target/72773] AVX512: Invalid operand for vcvttss2siq instruction

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
http://marc.info/?l=macports-dev&m=131805731507623

[Bug c++/16994] [meta-bug] VLA and C++

[pinskia at gcc dot gnu.org]

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

Bug 70556 Summary: ICE in cxx_eval_vec_init_1 on a ill-formed lambda capture of 
a VLA in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70556

   What|Removed |Added

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

[Bug c++/70556] ICE in cxx_eval_vec_init_1 on a ill-formed lambda capture of a VLA in a template

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||6.1.0, 7.0
 Resolution|--- |FIXED

--- Comment #2 from Andrew Pinski  ---
Is working in GCC 6.1 release and works on the trunk.

[Bug tree-optimization/70509] wrong code with extract from a v64qi

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #11 from Andrew Pinski  ---
Fixed.

[Bug c++/72768] Potential bug about the order of destructors of static objects and atexit() callbacks in C++?

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
It is necessary for correctness that destructors are run for objects which have
completed a constructor. It is not necessary for correctness to order static
destructors after the destructor for an object still being initialized, both
interpretations are reasonable.

It seems fairly clear to me that initialization for data(1) is not complete
until the principal constructor returns.

(In reply to lh_mouse from comment #0)
> The problem would be gone only if the GCC front-end registers the dtor after
> the delegated constructor returns.

But then if the delegating constructor throws you would run the destructor
twice e.g.

extern "C" int puts(const char*);

struct X {
  X() {
puts("delegated constructor");
  }
  X(int) : X() {
puts("delegating constructor");
throw 1;
  }
  ~X(){
puts("destructor");
  }
};

int main() {
  try {
X x(1);
  } catch (...) {
  }
}

Until the delegating constructor returns normally you can't know if the
destructor needs to be registered.

> Is this a GCC bug?

I'm coming to the conclusion it isn't a bug, but is required for correctness.

[Bug c++/72768] Potential bug about the order of destructors of static objects and atexit() callbacks in C++?

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> It is necessary for correctness that destructors are run for objects which
> have completed a constructor. It is not necessary for correctness to order
> static destructors after the destructor for an object still being

Oops, I meant atexit callbacks, not static destructors.

[Bug target/71910] ICE on valid OpenMP code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||x86_64-pc-cygwin
  Component|c++ |target
Summary|ICE on invalid OpenMP code  |ICE on valid OpenMP code

--- Comment #4 from Andrew Pinski  ---
Only happens for cygwin

[Bug other/67299] demangler mishandles complex types

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-02
  Component|c++ |other
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug target/72758] AArch64 missing support for poly64_t/poly64x1_t/poly64x2_t/poly128_t intrinsics

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2016-07-30 00:00:00 |2016-8-2
 CC||jgreenhalgh at gcc dot gnu.org,
   ||tamar.christina at arm dot com
   Assignee|unassigned at gcc dot gnu.org  |tamar.christina at arm 
dot com
Summary|GCC 4.9.2 on Aarch64|AArch64 missing support for
   |missing |poly64_t/poly64x1_t/poly64x
   |vreinterpretq_u64_p128 and  |2_t/poly128_t intrinsics
   |friends |

--- Comment #4 from James Greenhalgh  ---
Tamar is working on this. Thanks for the report.

[Bug target/67577] Trivial float-vectorization foiled by a loop

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |RESOLVED
  Component|tree-optimization   |target
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #4 from Andrew Pinski  ---
Fixed for GCC 6.1.

[Bug bootstrap/68048] Unable to compile ./host-x86_64-pc-linux-gnu/gcc/version.c! Can't pass preprocessor strings!

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
>./configure

Building in the src directory is known not always to work.
Build in a separate obj directory and this will work.

Also does this work now?

[Bug bootstrap/68048] Unable to compile ./host-x86_64-pc-linux-gnu/gcc/version.c! Can't pass preprocessor strings!

[ghasemi.arash at gmail dot com]

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

--- Comment #2 from Arash Ghasemi  ---
Thanks Andrew! How do you compile in a separate obj directory?

mkdir obj; cd obj; ../configure bla bla bla 

right?

[Bug c++/72774] New: ICE on invalid C++ code on x86_64-linux-gnu (tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in consider_binding_level, at cp/name-lookup.c:4721

[chengniansun at gmail dot com]

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

Bug ID: 72774
   Summary: ICE on invalid C++ code on x86_64-linux-gnu (tree
check: expected tree that contains ‘decl minimal’
structure, have ‘tree_list’ in consider_binding_level,
at cp/name-lookup.c:4721)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ 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 20160802 (experimental) [trunk revision 238976] (GCC) 
$ g++-trunk small.C
small.C: In function ‘void bar()’:
small.C:7:19: internal compiler error: tree check: expected tree that contains
‘decl minimal’ structure, have ‘tree_list’ in consider_binding_level, at
cp/name-lookup.c:4721
   0 ? static_cast(0) : __assert_fail;
   ^
0x103eed4 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc-source-trunk/gcc/tree.c:9914
0x87cb28 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc-source-trunk/gcc/tree.h:3137
0x87cb28 consider_binding_level
../../gcc-source-trunk/gcc/cp/name-lookup.c:4721
0x88272a lookup_name_fuzzy(tree_node*, lookup_name_fuzzy_kind)
../../gcc-source-trunk/gcc/cp/name-lookup.c:4742
0x791d5d cp_parser_diagnose_invalid_type_name
../../gcc-source-trunk/gcc/cp/parser.c:3168
0x7b437d cp_parser_parse_and_diagnose_invalid_type_name
../../gcc-source-trunk/gcc/cp/parser.c:3327
0x7a0317 cp_parser_type_specifier_seq
../../gcc-source-trunk/gcc/cp/parser.c:20107
0x7aaa62 cp_parser_type_id_1
../../gcc-source-trunk/gcc/cp/parser.c:19957
0x7a2b99 cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:6406
0x7a0c8c cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8012
0x7aac27 cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:8689
0x7ab1db cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8790
0x7abaa0 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9077
0x7ae3fa cp_parser_expression
../../gcc-source-trunk/gcc/cp/parser.c:9246
0x7abbbd cp_parser_question_colon_clause
../../gcc-source-trunk/gcc/cp/parser.c:9020
0x7abbbd cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9083
0x7ae3fa cp_parser_expression
../../gcc-source-trunk/gcc/cp/parser.c:9246
0x7ae9a3 cp_parser_expression_statement
../../gcc-source-trunk/gcc/cp/parser.c:10709
0x7bdcc6 cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10560
0x7be6ac cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:10832
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ cat small.C
void __assert_fail();
namespace A {
void g();
}
void bar() {
  using A::g;
  0 ? static_cast(0) : __assert_fail;
}
$

[Bug c++/72768] Potential bug about the order of destructors of static objects and atexit() callbacks in C++?

[lh_mouse at 126 dot com]

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

--- Comment #6 from lh_mouse  ---
> But then if the delegating constructor throws you would run the destructor 
> twice e.g.

The `atexit()` callback in question can check the `__cxa_guard` of the object
to determine whether it should call the destructor. Lack of a guard object
(when the static object has namespace scope instead of block scope) is out of
question because throwing anything out of the constructor would result in a
call to `std::terminate()`.

[Bug tree-optimization/69848] poor vectorization of a loop from SPEC2006 464.h264ref

[amker at gcc dot gnu.org]

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

--- Comment #10 from amker at gcc dot gnu.org ---
Patches @https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00058.html and
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00059.html implements
vcond_mask/vec_cmp/vcond stuff on AArch64 and fix the target dependent problem.
 Number of instructions inside the loop is 8 with them.

The target-independent problem remains and needs different fix.

[Bug tree-optimization/72772] Missed SCEV after pass reordering@236440

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-08-02
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Note that for some odd reason creating the preheader causes the PHI to appar.
Fixing that would be appreciated - it's the make_forwarder_block CFG hook
that causes this.  Not sure why create_preheader doesn't special-case the
single_entry != NULL case by simply splitting the edge.

The following fixes the testcase:

Index: cfgloopmanip.c
===
--- cfgloopmanip.c  (revision 238938)
+++ cfgloopmanip.c  (working copy)
@@ -1497,7 +1497,7 @@ has_preds_from_loop (basic_block block,
 basic_block
 create_preheader (struct loop *loop, int flags)
 {
-  edge e, fallthru;
+  edge e;
   basic_block dummy;
   int nentry = 0;
   bool irred = false;
@@ -1544,9 +1544,14 @@ create_preheader (struct loop *loop, int

   mfb_kj_edge = loop_latch_edge (loop);
   latch_edge_was_fallthru = (mfb_kj_edge->flags & EDGE_FALLTHRU) != 0;
-  fallthru = make_forwarder_block (loop->header, mfb_keep_just, NULL);
-  dummy = fallthru->src;
-  loop->header = fallthru->dest;
+  if (single_entry)
+dummy = split_edge (single_entry);
+  else
+{
+  edge fallthru = make_forwarder_block (loop->header, mfb_keep_just,
NULL);
+  dummy = fallthru->src;
+  loop->header = fallthru->dest;
+}

   /* Try to be clever in placing the newly created preheader.  The idea is to
  avoid breaking any "fallthruness" relationship between blocks.

[Bug c++/72768] Potential bug about the order of destructors of static objects and atexit() callbacks in C++?

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
It *could* check, but that doesn't mean it should.

[Bug fortran/72770] [7 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:263

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-02
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE in make_ssa_name_fn, at |[7 Regression] ICE in
   |tree-ssanames.c:263 |make_ssa_name_fn, at
   ||tree-ssanames.c:263
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
#2  0x00fc40ea in remap_ssa_name (name=, 
id=0x7fffda60) at /space/rguenther/src/svn/trunk/gcc/tree-inline.c:238
238   new_tree = make_ssa_name (remap_type (TREE_TYPE (name), id));
(gdb) p name
$1 = 
(gdb) p debug_tree (name)
 

probably caused by early-SSA and not properly gimplified type sizes.  Thus
a fortran FE issue with respect to missing DECL_EXPRs.

[Bug fortran/72770] [7 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:263

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
.original has:

case 85893463:;
.__tmp_CHARACTER_0_1 = x->_len;
__tmp_CHARACTER_0_1 = x->_data;
__tmp_CHARACTER_0_1.dtype = ((integer(kind=8)) SAVE_EXPR
<(sizetype) .__tmp_CHARACTER_0_1> << 6) + 49;
{
  logical(kind=4) test.2;
  character(kind=1)[0:][1:.__tmp_CHARACTER_0_1] * D.3488;
  integer(kind=8) D.3489;
  integer(kind=8) D.3490;
  integer(kind=8) D.3491;
  integer(kind=8) D.3494;

  test.2 = 0;
  D.3488 = (character(kind=1)[0:][1:.__tmp_CHARACTER_0_1] *)
__tmp_CHARACTER_0_1.data;
  D.3489 = __tmp_CHARACTER_0_1.offset;
  D.3490 = __tmp_CHARACTER_0_1.dim[0].lbound;
...

and the type of D.3488 misses a DECL_EXPR (or manual handling in the Fortran FE
like we do for some cases - simply copy x->_len to a decl and use that for
the upper bound).

[Bug tree-optimization/72772] Missed SCEV after pass reordering@236440

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Note that for some odd reason creating the preheader causes the PHI to appar.
> Fixing that would be appreciated - it's the make_forwarder_block CFG hook
> that causes this.  Not sure why create_preheader doesn't special-case the
> single_entry != NULL case by simply splitting the edge.
> 
Thanks.  I am also testing patch to simplify_using_initial_conditions and
loop_exits_before_oveflow.  I think they worth fixing too because patches are
kind like a simplification.  Anyway I will send for comment once passes
bootstrap&test.

[Bug c++/72774] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu (tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_list’ in consider_binding_level, at cp/name-loo

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-02
  Known to work||6.1.0
   Target Milestone|--- |7.0
Summary|ICE on invalid C++ code on  |[7 Regression] ICE on
   |x86_64-linux-gnu (tree  |invalid C++ code on
   |check: expected tree that   |x86_64-linux-gnu (tree
   |contains ‘decl minimal’ |check: expected tree that
   |structure, have ‘tree_list’ |contains ‘decl minimal’
   |in consider_binding_level,  |structure, have ‘tree_list’
   |at cp/name-lookup.c:4721)   |in consider_binding_level,
   ||at cp/name-lookup.c:4721)
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed, 6.1 works.

[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination

[amker at gcc dot gnu.org]

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

--- Comment #7 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Aug  2 10:09:33 2016
New Revision: 238982

URL: https://gcc.gnu.org/viewcvs?rev=238982&root=gcc&view=rev
Log:
PR tree-optimization/34114
* fold-const.c (multiple_of_p): Improve MULT_EXPR, PLUS_EXPR,
PLUS_EXPR case.  Handle SSA_NAME case.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c

[Bug tree-optimization/34114] Missed optimization: cannot determine loop termination

[amker at gcc dot gnu.org]

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

--- Comment #8 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Aug  2 10:13:28 2016
New Revision: 238983

URL: https://gcc.gnu.org/viewcvs?rev=238983&root=gcc&view=rev
Log:
PR tree-optimization/34114
* tree-ssa-loop-niter.c (number_of_iterations_ne): Prove no-overflow
information for more control IVs.

gcc/testsuite
PR tree-optimization/34114
* gcc.dg/tree-ssa/loop-42.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-42.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c

[Bug fortran/72770] [7 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:263

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Caused by revision r235817.

[Bug driver/70783] -spec option behavior is different to implicit spec file

[andreas.g.jhoss at gmx dot de]

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

--- Comment #2 from Andreas.G.JHOSS  ---
Hmm?
So but how can I add and change implicitely a substitute rule then?
I want to add certain libraries to build process permanently for certain
platforms so I can get platform independent. And clearly I want to add a rule
where I can disable this libararies explicitely. I thought this is far common
how I do this.

Must the user always state --spec to override/add a single substitue rule in
gcc?

[Bug fortran/72770] [7 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:263

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Note this just exposed a latent issue in the FE.

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

[wschmidt at gcc dot gnu.org]

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

--- Comment #17 from Bill Schmidt  ---
Vlad, the patch checks out very well on powerpc64le.  403.gcc no longer
degrades.  We are seeing some very nice improvements from LRA over reload on a
few benchmarks (435.gromacs leads the way with +9.5%).  Everything in CPU2006
is positive or noise except for 401.bzip2, which shows about a 2% degradation. 
We'll look into that separately to see if it's real and open another bug if
there is anything to report.

Once the patch is in place, I think we will be ready to switch the POWER server
targets to use LRA by default.

Thanks!  Excellent results.

Bill

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

[mpolacek at gcc dot gnu.org]

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

Bug ID: 72775
   Summary: internal compiler error: in finish_expr_stmt, at
cp/semantics.c:677
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Since r233183, we ICE with:

class S {
  bool b;
  char a[] = "foo";
  S () {}
};

$ ./cc1plus -quiet q.cc
q.cc: In constructor ‘S::S()’:
q.cc:4:8: internal compiler error: in finish_expr_stmt, at cp/semantics.c:677
   S () {}
^
0x9b904c finish_expr_stmt(tree_node*)
/home/marek/src/gcc/gcc/cp/semantics.c:677
0x98ed5a perform_member_init
/home/marek/src/gcc/gcc/cp/init.c:803
0x990727 emit_mem_initializers(tree_node*)
/home/marek/src/gcc/gcc/cp/init.c:1179
0x9bc39a finish_mem_initializers(tree_node*)
/home/marek/src/gcc/gcc/cp/semantics.c:1627
0x90c782 cp_parser_ctor_initializer_opt
/home/marek/src/gcc/gcc/cp/parser.c:13491
0x919f06 cp_parser_ctor_initializer_opt_and_function_body
/home/marek/src/gcc/gcc/cp/parser.c:20764
0x922f70 cp_parser_function_definition_after_declarator
/home/marek/src/gcc/gcc/cp/parser.c:25475
0x92556b cp_parser_late_parsing_for_member
/home/marek/src/gcc/gcc/cp/parser.c:26354
0x91bf8d cp_parser_class_specifier_1
/home/marek/src/gcc/gcc/cp/parser.c:21630
0x91c06a cp_parser_class_specifier
/home/marek/src/gcc/gcc/cp/parser.c:21656
0x9108e2 cp_parser_type_specifier
/home/marek/src/gcc/gcc/cp/parser.c:15883
0x90b753 cp_parser_decl_specifier_seq
/home/marek/src/gcc/gcc/cp/parser.c:12802
0x90ac9e cp_parser_simple_declaration
/home/marek/src/gcc/gcc/cp/parser.c:12336
0x90ac26 cp_parser_block_declaration
/home/marek/src/gcc/gcc/cp/parser.c:12283
0x90a9a8 cp_parser_declaration
/home/marek/src/gcc/gcc/cp/parser.c:12180
0x90a501 cp_parser_declaration_seq_opt
/home/marek/src/gcc/gcc/cp/parser.c:12059
0x8fa316 cp_parser_translation_unit
/home/marek/src/gcc/gcc/cp/parser.c:4350
0x948552 c_parse_file()
/home/marek/src/gcc/gcc/cp/parser.c:37581
0xafbce0 c_common_parse_file()
/home/marek/src/gcc/gcc/c-family/c-opts.c:1070
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |6.3

--- Comment #1 from Marek Polacek  ---
GCC 5 rejects the code:

q.cc:3:14: error: initializer-string for array of chars is too long
[-fpermissive]
   char a[] = "foo";
  ^
q.cc: In constructor ‘S::S()’:
q.cc:4:8: error: initializer-string for array of chars is too long
[-fpermissive]
   S () {}
^

GCC 6 and trunk ICE.  But before r233183 this code compiled fine.

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

[ramana at gcc dot gnu.org]

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

--- Comment #18 from Ramana Radhakrishnan  ---
(In reply to Bill Schmidt from comment #17)
> Vlad, the patch checks out very well on powerpc64le.  403.gcc no longer
> degrades.  We are seeing some very nice improvements from LRA over reload on
> a few benchmarks (435.gromacs leads the way with +9.5%).  Everything in
> CPU2006 is positive or noise except for 401.bzip2, which shows about a 2%
> degradation.  We'll look into that separately to see if it's real and open
> another bug if there is anything to report.
> 
> Once the patch is in place, I think we will be ready to switch the POWER
> server targets to use LRA by default.
> 
> Thanks!  Excellent results.
> 
> Bill

We'll look at what this does on AArch64 and feedback on this thread.

[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2016-08/msg00113.ht
   ||ml
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com

--- Comment #12 from Alan Modra  ---
Bug reproduced on powerpc-e500v2-linux-gnuspe.  The testcase needs -Os -mlra
-fstack-protector -fPIC, or you need to configure gcc so that -fPIC and
-fstack-protector are on by default.  I haven't yet tested whether the lra
patch I posted for comment #1 testcase also fixes the e500 testcase.

[Bug middle-end/72776] New: Too large array size not diagnosed properly when inferred from an initializer

[amonakov at gcc dot gnu.org]

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

Bug ID: 72776
   Summary: Too large array size not diagnosed properly when
inferred from an initializer
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

For the following testcase:

static char c[] = {[~0ul] = 1};

the array c would cover the whole address space. It's been noted that objects
spanning more than half of address space are not supportable from the
middle-end point of view. However, there is no early check for arrays that have
their size inferred from their initializer, like the above; they would be
diagnosed when an attempt to emit the initializer to assembly is made, causing
the diagnostic to be omitted at -O1+ (if the object is unused) or
-fsyntax-only.

Moreover, for the example above GCC gets confused about the size of c and emits
it as a zero-sized object. This is due to code in stor-layout.c:

/* ??? We have no way to distinguish a null-sized array from an
   array spanning the whole sizetype range, so we arbitrarily
   decide that [0, -1] is the only valid representation.  */
if (integer_zerop (length)
&& TREE_OVERFLOW (length)
&& integer_zerop (lb))
  length = size_zero_node;

(I don't really understand the comment). This is from
https://gcc.gnu.org/ml/gcc-patches/2012-11/msg02230.html which gives as an
example

  type Arr is array(Long_Integer) of Boolean;

As I understand this would declare a similar array consuming the whole address
space. From the testcases in the patch, it looks like the intention is to allow
such huge array types while still rejecting objects of those types (?).

[Bug c++/72768] Potential bug about the order of destructors of static objects and atexit() callbacks in C++?

[lh_mouse at 126 dot com]

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

--- Comment #8 from lh_mouse  ---
(In reply to Jonathan Wakely from comment #7)
> It *could* check, but that doesn't mean it should.

I was merely stating that the twice-destruction problem wasn't unresolvable.

The topic about the C++ standard starts here:
https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/VipjQOBUg6M

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[tulipawn at gmail dot com]

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

--- Comment #19 from PeteVine  ---
Here's what I've been doing to arrive at that profile-use crash:

In the unpacked archive's top-level directory (see URL), edit premake4.lua to
point to your SDL2 includes (instead of /opt) and add `-fprofile-generate` to
your release CFLAGS. Followed by:

$ premake4 gmake

Now add -lgcov to the final link command in build/TEngine.mak at line 56

$ LDFLAGS=-lgcov make config=release -j4
$ ./t-engine

The welcome screen is basically enough to gather lots of profile data.
In the second step, CFLAGS in premake4.lua need changing to `-fprofile-use`,
and after deleting all object files in obj/Release, it's the same dance again:

$ premake gmake 
$ make config=release

and on my machine gcc 6.1.1 (20160721) prints:

 Building physfs (release) 
physfsrwops.c
physfs.c
../src/physfs/physfs.c:76:5: warning: initialization from incompatible pointer
type [-Wincompatible-pointer-types]
 &__PHYSFS_Archiver_BIND_PHYSFS,
 ^
../src/physfs/physfs.c:76:5: note: (near initialization for
‘supported_types[0]’)
../src/physfs/physfs.c: In function ‘PHYSFS_eof’:
../src/physfs/physfs.c:2292:1: error: corrupted profile info: profile data is
not flow-consistent
 }
 ^
../src/physfs/physfs.c:2292:1: error: corrupted profile info: number of
executions for edge 3-4 thought to be 1419
../src/physfs/physfs.c:2292:1: error: corrupted profile info: number of
executions for edge 3-7 thought to be -3
../src/physfs/physfs.c:2086:44: error: corrupted value profile: ic profile
counter (1420 out of 1419) inconsistent with basic-block count (1419)
 return((fh->bufpos == fh->buffill) && (fh->funcs->eof(fh->opaque)));
   ~^~~
../src/physfs/physfs.c: In function ‘PHYSFS_openRead’:
../src/physfs/physfs.c:2292:1: error: corrupted profile info: profile data is
not flow-consistent
 }
 ^
../src/physfs/physfs.c:2292:1: error: corrupted profile info: number of
executions for edge 4-5 thought to be 930
../src/physfs/physfs.c:2292:1: error: corrupted profile info: number of
executions for edge 4-6 thought to be -8
../src/physfs/physfs.c: In function ‘sanitizePlatformIndependentPath’:
../src/physfs/physfs.c:2292:1: error: corrupted profile info: profile data is
not flow-consistent
../src/physfs/physfs.c:2292:1: error: corrupted profile info: number of
executions for edge 16-18 thought to be -6
../src/physfs/physfs.c:2292:1: error: corrupted profile info: number of
executions for edge 16-17 thought to be 4164

[Bug c++/72777] New: broken error message with reference in constexpr arguments in c++11 mode

[bloerwald at googlemail dot com]

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

Bug ID: 72777
   Summary: broken error message with reference in constexpr
arguments in c++11 mode
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bloerwald at googlemail dot com
  Target Milestone: ---

The error message for modifying a reference argument in a constexpr is not
exactly perfect, and degrades horribly when using indirection to access the
reference:

struct integral { int value; };

#ifdef fun
constexpr int& value_of (integral& x) { return x.value; }
#else
#define value_of(x) x.value
#endif

constexpr int dop (integral& lhs, integral& rhs)
{
  return value_of (lhs) -= value_of (rhs);
}

$ c++ tmp.cpp -o/dev/null -c --std=c++11 -Ufun
tmp.cpp: In function ‘constexpr int dop(integral&, integral&)’:
tmp.cpp:15:1: error: expression ‘(lhs.integral::value = (lhs.integral::value -
rhs.integral::value))’ is not a constant-expression
 }
 ^

Note that it is not only not pointing to the actually bad expression, but also
shows `(l = (l - r))` instead of `l -= r` which the user wrote. Using the
value_of function instead of direct .value access somehow adds an 
and completely breaks the expression:

$ c++ tmp.cpp -o/dev/null -c --std=c++11 -Dfun
tmp.cpp: In function ‘constexpr int dop(integral&, integral&)’:
tmp.cpp:11:1: error: expression ‘(value_of((* & lhs)) = (value_of((* & rhs)),
(value_of((* & lhs)) - )))’ is not a constant-expression
 }
 ^

which after stripping roughly is `(l = (r, l - ))`.  

Note that --std=c++14 lets everything compile just fine (I guess due to the
relaxation of constexpr rules). I am not sure if this is valid c++14 though.

[Bug c++/72777] broken error message with reference in constexpr arguments in c++11 mode

[bloerwald at googlemail dot com]

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

--- Comment #1 from bloerwald at googlemail dot com ---
Note: compiles fine in c++11 mode of clang 3.8, so not sure if it actually is
forbidden by the standard.

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
I'll note that in the case where the stride is known (slsr-35.c), SLSR is
making at least a somewhat rational decision based on cost not to
strength-reduce the phi candidate.  In this case the stride is a power of 2, so
the benefit of replacing a multiply is pretty low.  SLSR would have to replace
the multiply with an add, and introduce two adds for the PHI arguments.  There
is a somewhat simplistic calculation of dead code savings for removal of the
PHI itself, in which only PHI arguments that have a single use are considered
removable.  In this case that is overly conservative because the only other use
of _17 is in the definition of _18, which is judged to go dead.  If we
aggressively assume we would remove the definition of _17 as well, SLSR would
make the transformation because the savings would be zero, and we currently do
optimize when the result looks neutral.  So there is opportunity here to be
more intelligent about dead code savings estimation.

Processing dependency tree rooted at 1.
  Conditional candidate 7:
add_costs = 12 # Replace mult and phi args
mult_savings = 4   # It's a shift, so low cost
dead_savings = 4   # Really should be 8
cost = 4   # Really should be 0
  Not replaced.# Could replace, but it's on the bubble.

However, for the case of an unknown stride as in slsr-36.c, this seems unlikely
to be a close decision, so I suspect something worse is wrong there.  Will
analyze that next.

[Bug driver/70783] -spec option behavior is different to implicit spec file

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andreas.G.JHOSS from comment #2)
> Hmm?
> So but how can I add and change implicitely a substitute rule then?
> I want to add certain libraries to build process permanently for certain
> platforms so I can get platform independent. And clearly I want to add a
> rule where I can disable this libararies explicitely. I thought this is far
> common how I do this.
> 
> Must the user always state --spec to override/add a single substitue rule in
> gcc?

You dump the current specs and then you edit them as I mentioned in the
previous comment.

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

[vmakarov at gcc dot gnu.org]

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

--- Comment #19 from Vladimir Makarov  ---
Author: vmakarov
Date: Tue Aug  2 16:07:36 2016
New Revision: 238991

URL: https://gcc.gnu.org/viewcvs?rev=238991&root=gcc&view=rev
Log:
2016-08-02  Vladimir Makarov  

PR rtl-optimization/69847
* lra-int.h (struct lra-reg): Use restore_rtx instead of
restore_regno.
(lra_rtx_hash): New.
* lra.c (initialize_lra_reg_info_element): Use restore_rtx instead
of restore_regno.
(lra_rtx_hash): Rename and move lra-remat.c::rtx_hash.
* lra-remat.c (rtx_hash): Rename and Move to lra.c.
* lra-spills.c (lra_final_code_change): Don't delete insn when the
next insn is USE with the same reg as the current insn source.
* lra-constraints.c (curr_insn_transform): Use restore_rtx instead
of restore_regno.
(lra_constraints_init): Call initiate_invariants.
(lra_constraints_finish): Call finish_invariants.
(struct invariant, invariant_t, invariant_ptr_t): New.
(const_invariant_ptr_t, invariants, invariants_pool): New.
(invariant_table, invariant_hash, invariant_eq_p): New.
(insert_invariant, initiate_invariants, finish_invariants): New.
(clear_invariants, invalid_invariant_regs): New.
(inherit_reload_reg, split_reg, fix_bb_live_info): Use restore_rtx
instead of restore_regno.
(invariant_p, process_invariant_for_inheritance): New.
(inherit_in_ebb): Implement invariant inheritance.
(lra_inheritance): Initialize and finalize invalid_invariant_regs.
(remove_inheritance_pseudos): Implement undoing invariant
inheritance.
(undo_optional_reloads, lra_undo_inheritance): Use restore_rtx
instead of restore_regno.
* lra-assigns.c (regno_live_length): New.
(reload_pseudo_compare_func): Use regno_live_length.
(assign_by_spills): Use restore_rtx instead of restore_regno.
(lra_assign): Ditto.  Initiate regno_live_length.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c
trunk/gcc/lra-constraints.c
trunk/gcc/lra-int.h
trunk/gcc/lra-remat.c
trunk/gcc/lra-spills.c
trunk/gcc/lra.c

[Bug tree-optimization/69848] poor vectorization of a loop from SPEC2006 464.h264ref

[amker at gcc dot gnu.org]

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

--- Comment #11 from amker at gcc dot gnu.org ---
I am also investigating as Alan suggested in comment #3 to see how to fix the
reduction issue.

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

[vmakarov at gcc dot gnu.org]

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

--- Comment #20 from Vladimir Makarov  ---
(In reply to Bill Schmidt from comment #17)
> Vlad, the patch checks out very well on powerpc64le.  403.gcc no longer
> degrades.  We are seeing some very nice improvements from LRA over reload on
> a few benchmarks (435.gromacs leads the way with +9.5%).  Everything in
> CPU2006 is positive or noise except for 401.bzip2, which shows about a 2%
> degradation.  We'll look into that separately to see if it's real and open
> another bug if there is anything to report.
> 
> Once the patch is in place, I think we will be ready to switch the POWER
> server targets to use LRA by default.
> 
> Thanks!  Excellent results.

Mike, Bill, thank you for benchmarking the patch.  I've just submitted the
patch into the trunk.  As the patch affects a complicated inheritance code in
LRA, there is a possibility of new regressions on some targets.  So if this
happens, another iteration on the patch might be done.

[Bug middle-end/72778] New: [7 Regression] internal compiler error: in create_pre_exit, at mode-switching.c:451

[hjl.tools at gmail dot com]

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

Bug ID: 72778
   Summary: [7 Regression] internal compiler error: in
create_pre_exit, at mode-switching.c:451
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On x86, r238991 caused:

[hjl@gnu-6 gcc]$ ./xgcc -B./
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/mpx/pr66048.cc
-S -O2 -fcheck-pointer-bounds -mmpx -mavx
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/mpx/pr66048.cc:
In function ‘c1 test.chkp(c2, #‘pointer_bounds_type’ not supported by
dump_type#, void, ...)’:
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/mpx/pr66048.cc:16:1:
internal compiler error: in create_pre_exit, at mode-switching.c:451
 }
 ^
0x1b3e104 create_pre_exit
/export/gnu/import/git/sources/gcc/gcc/mode-switching.c:437
0x1b3e377 optimize_mode_switching
/export/gnu/import/git/sources/gcc/gcc/mode-switching.c:534
0x1b3f6a6 execute
/export/gnu/import/git/sources/gcc/gcc/mode-switching.c:892
0xfe1176 gcc::pass_manager::execute_pass_mode_switching()
/export/gnu/import/git/sources/gcc/gcc/passes.c:123
0x14d5a3a rest_of_handle_insert_vzeroupper
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386.c:2685
0x14d95d2 execute
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386.c:4068
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-6 gcc]$

[Bug middle-end/72778] [7 Regression] internal compiler error: in create_pre_exit, at mode-switching.c:451

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |7.0

[Bug middle-end/72778] [7 Regression] internal compiler error: in create_pre_exit, at mode-switching.c:451

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #1 from Vladimir Makarov  ---
H.J., thanks for reporting this.

I am planning to fix it today.

[Bug target/72771] [6/7 Regression] powerpc64le ICE with -mcpu=power9

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-02
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |6.2
Summary|powerpc64le ICE with|[6/7 Regression]
   |-mcpu=power9|powerpc64le ICE with
   ||-mcpu=power9
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed with GCC 6.1 and 7.0, 4.9.2 looks fine and I don't have 5.x.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-08-02
 CC||marxin at gcc dot gnu.org
   Target Milestone|6.3 |6.2
Summary|internal compiler error: in |[6/7 Regression] internal
   |finish_expr_stmt, at|compiler error: in
   |cp/semantics.c:677  |finish_expr_stmt, at
   ||cp/semantics.c:677
 Ever confirmed|0   |1

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

[Bug target/72773] AVX512: Invalid operand for vcvttss2siq instruction

[wen...@mitsuba-renderer.org]

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

--- Comment #3 from Wenzel Jakob  ---
It looks like it is an LLVM issue (see
https://llvm.org/bugs/show_bug.cgi?id=28810)

[Bug target/72773] AVX512: Invalid operand for vcvttss2siq instruction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   See Also||https://llvm.org/bugs/show_
   ||bug.cgi?id=28810
 Resolution|--- |INVALID

--- Comment #4 from Andrew Pinski  ---
Invalid then so closing as such.

[Bug bootstrap/68048] Unable to compile ./host-x86_64-pc-linux-gnu/gcc/version.c! Can't pass preprocessor strings!

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Arash Ghasemi from comment #2)
> Thanks Andrew! How do you compile in a separate obj directory?
> 
> mkdir obj; cd obj; ../configure bla bla bla 
> 
> right?

https://gcc.gnu.org/wiki/FAQ#configure
https://gcc.gnu.org/wiki/InstallingGCC

[Bug tree-optimization/71815] SLSR misses several PHI candidate cases

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
Actually, it looks like a similar problem for the unknown stride case.  Again
there is logic that relies on single-reached-use for determining what
expressions go dead.  We need to factor in expressions that go dead conditional
on other expressions going dead.  I'll work on a solution.

[Bug middle-end/72778] [7 Regression] internal compiler error: in create_pre_exit, at mode-switching.c:451

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
Author: vmakarov
Date: Tue Aug  2 20:57:04 2016
New Revision: 239000

URL: https://gcc.gnu.org/viewcvs?rev=239000&root=gcc&view=rev
Log:
2016-08-02  Vladimir Makarov  

PR middle-end/72778
* lra-spills.c (regno_in_use_p): New.
(lra_final_code_change): Use it.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-spills.c

[Bug c++/72779] New: ice when compiling included lambda pattern (internal compiler error: in is_base_type, at dwarf2out.c:9968)

[sjust at redhat dot com]

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

Bug ID: 72779
   Summary: ice when compiling included lambda pattern (internal
compiler error: in is_base_type, at dwarf2out.c:9968)
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjust at redhat dot com
  Target Milestone: ---

Created attachment 39048
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39048&action=edit
Tarball with reproduction information

When compiling the attached repro.cc without the -g flag, g++ succeeds:

~/gcc_bug [deepthought●] » g++ -std=c++11 repro.cc  

With the -g flag, g++ hits an internal compiler error:

~/gcc_bug [deepthought●] » g++ -std=c++11 repro.cc -g
repro.cc: In instantiation of ‘struct lambda_visitor’:
repro.cc:10:8:   required from ‘struct lambda_visitor’
repro.cc:49:62:   required from here
repro.cc:22:8: internal compiler error: in is_base_type, at dwarf2out.c:9968
 struct lambda_visitor 
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/cclEDzyl.out file, please attach this to
your bugreport.

g++ -v:

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

ice.tgz is attached with
- error.out has the above output
- repro.cc has the source which triggers the ice
- preprocessed_source.cc has the preprocessed source
- the crash file

[Bug c++/72779] ice when compiling included lambda pattern (internal compiler error: in is_base_type, at dwarf2out.c:9968)

[sjust at redhat dot com]

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

--- Comment #1 from Samuel Just  ---
Created attachment 39049
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39049&action=edit
Shorter reproducer

I simplified the reproducer a bit more, same stuff included.

[Bug c++/72779] ice when compiling included lambda pattern (internal compiler error: in is_base_type, at dwarf2out.c:9968)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #2 from Andrew Pinski  ---
Have you tried 4.9.x or a latter version of GCC.  GCC 4.8.x is no longer being
supported or updated.

[Bug debug/72779] ice when compiling included lambda pattern (internal compiler error: in is_base_type, at dwarf2out.c:9968)

[sjust at redhat dot com]

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

--- Comment #3 from Samuel Just  ---
I have not, let me rustle up a newer version and get back to you.

[Bug debug/72779] ice when compiling included lambda pattern (internal compiler error: in is_base_type, at dwarf2out.c:9968)

[sjust at redhat dot com]

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

--- Comment #4 from Samuel Just  ---
Seems to be ok on 5.3.1.  I guess I should bother the ubuntu maintainers about
a backport?

~/Downloads [pondermatic●] » g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)

[Bug middle-end/70895] OpenACC: loop reduction does not work. Output is zero.

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
 CC||cltang at gcc dot gnu.org
  Component|fortran |middle-end
   Assignee|tschwinge at gcc dot gnu.org   |cltang at gcc dot 
gnu.org

--- Comment #5 from Thomas Schwinge  ---
We've gotten that aspect of the OpenACC specification clarified as follows
(comments inside parens are mine): "A scalar variable referenced in a parallel
construct without predetermined (already implemented) or explicitly determined
data attributes (already implemented) will have its data attributes implicitly
determined as described in this paragraph. If the scalar variable appears in a
reduction clause on the parallel construct (already implemented), or in a
reduction clause on a loop construct in the parallel construct (relevant for
this PR70895), or is assigned in an atomic construct in the parallel construct
(another change), the scalar variable is treated as if it appeared in a copy
clause for the parallel construct. In all other cases, the scalar variable is
treated as if it appeared in a firstprivate clause for the parallel construct
(already implemented)."

Chung-Lin, please sanity-check that this will make work Ralph's example program
as attached, and then implement these semantics for trunk, gcc-6-branch,
gomp-4_0-branch (gcc/gimplify.c; hopefully the same patch will do for all three
branches; please shout if not).  In addition to Ralph's example program as
attached, also add ample testsuite coverage, for various nesting of OpenACC
constructs, for all of C, C++, and Fortran.

If the change is non-trivial to detect that a "scalar variable [...] is
assigned in an atomic construct" ("another change" above), please leave that
aspect aside for the moment.

[Bug debug/72779] ice when compiling included lambda pattern (internal compiler error: in is_base_type, at dwarf2out.c:9968)

[sjust at redhat dot com]

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

--- Comment #5 from Samuel Just  ---
To clarify, this bug is present on 4.8.4, but not 5.3.1 suggesting that it may
not be present in any currently supported versions.

[Bug debug/63243] [meta-bug] RH GDB project tracker

[aoliva at gcc dot gnu.org]

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

Bug 60782 Summary: DWARF does not represent _Atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60782

   What|Removed |Added

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

[Bug debug/60782] DWARF does not represent _Atomic

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||aoliva at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Alexandre Oliva  ---
It appears to me that this should have long been closed, no?  The patch that
implements it is in, and functional.  I'm closing it; please reopen if there's
any reason for it to remain so.

[Bug tree-optimization/71824] [4.9/6/7 Regression] ICE when compiling libiberty with Graphite loop optimizations

[lluixhi at gmail dot com]

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

Aric Belsito  changed:

   What|Removed |Added

 CC||lluixhi at gmail dot com

--- Comment #2 from Aric Belsito  ---
Confirmed on armv6kz-hardfloat-linux-musleabi

[Bug fortran/71952] [Coarray, F2008] Rejects valid coarray access with array partref

[damian at sourceryinstitute dot org]

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

--- Comment #4 from Damian Rouson  ---
Additional demonstrations of related unsupported syntax are below.  I also
removed  "implicit none" and one unused variable because these are not needed
to generate the error message:

$ cat additional-examples.f90 
  type particles
real x(1)
  end type
  type(particles) outbox(1)[*]
  print *,outbox(1)[1]%x(1:1) 
  print *,outbox(1)[1]%x(:)   
  print *,outbox(1)[1]%x  
end 

$ gfortran -fcoarray=lib additional-examples.f90 
additional-examples.f90:5:10:

   print *,outbox(1)[1]%x(1:1)
  1
Error: Sorry, coindexed access at (1) to a scalar component with an array
partref is not yet supported
additional-examples.f90:6:10:

   print *,outbox(1)[1]%x(:)
  1
Error: Sorry, coindexed access at (1) to a scalar component with an array
partref is not yet supported
additional-examples.f90:7:10:

   print *,outbox(1)[1]%x
  1
Error: Sorry, coindexed access at (1) to a scalar component with an array
partref is not yet supported

$ gfortran --version
GNU Fortran (MacPorts gcc7 7-20160605_0) 7.0.0 20160605 (experimental)

[Bug c++/72780] New: public `using` directive exposes protected base-class constructor

[kyle.strand at beckman dot com]

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

Bug ID: 72780
   Summary: public `using` directive exposes protected base-class
constructor
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kyle.strand at beckman dot com
  Target Milestone: ---

In the code below, the protected constructors of `Base` and `MyCrtp` should
both be inaccessible and therefore trigger access errors in `main`. However,
the CRTP base-class constructor call does NOT trigger an error in GCC.

class Base {
  protected:
Base(int) {}
};

class Derived : public Base {
  public:
using Base::Base;
};

template 
class MyCrtp {
  protected:
template 
  MyCrtp(T&&) { }
};

class Implementer : public MyCrtp {
  using BASE = MyCrtp;
  public:
using BASE::MyCrtp;
};

int main()
{
  Derived d(3); // Compile error with GCC and Clang
  Implementer i(3); // GCC gives NO error
}

[Bug target/71680] [7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) w/ -Os -mlra

[amodra at gmail dot com]

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

--- Comment #13 from Alan Modra  ---
The e500 issue is quite different, and is not fixed by my lra patch.  From the
lra dump,

  Creating newreg=436, assigning class NO_REGS to save r436
  536: r192:SI=0x1
  REG_EQUAL 0x1
Add reg<-save after:
  621: r362:SI#0=r436:DF

  184: NOTE_INSN_BASIC_BLOCK 21
Add save<-reg after:
  620: r436:DF=r362:SI#0

So r362 is being saved for some reason, then later:

  Reassigning non-reload pseudos
   Assign 66 to r362 (freq=4000)

so r362 is finding its way into ctr.

[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer

[asmwarrior at gmail dot com]

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

--- Comment #8 from asmwarrior  ---
Hi, I just build wx2.8.12 under TDM-GCC 5.1 with
-fno-delete-null-pointer-checks enabled. But the bad thing is that I still see
the same crash here. The whole command is below:

mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release
UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-Wno-unused-local-typedefs
-Wno-deprecated-declarations -fno-keep-inline-dllexport 
-fno-delete-null-pointer-checks -g" >log-release-no-delete-null.txt 2>&1

For some assembler code of the crash:

[debug]Stack level 0, frame at 0x22e004:
[debug] eip = 0x6d11fb05 in wxClassInfo::IsKindOf
(F:\wx\wxMSW-2.8.12\include\wx\object.h:94); saved eip = 0x6cfa043d
[debug] inlined into frame 1
[debug] source language c++.
[debug] Arglist at unknown address.
[debug] Locals at unknown address, Previous frame's sp in esp
[debug]>>cb_gdb:
[debug]> disassemble 0x6d11fb05
[debug]Dump of assembler code for function wxCheckDynamicCast(wxObject*,
wxClassInfo*):
[debug]   0x6d11fa70 <+0>:  push   ebp
[debug]   0x6d11fa71 <+1>:  push   edi
[debug]   0x6d11fa72 <+2>:  push   esi
[debug]   0x6d11fa73 <+3>:  push   ebx
[debug]   0x6d11fa74 <+4>:  subesp,0x1c
[debug]   0x6d11fa77 <+7>:  movebx,DWORD PTR [esp+0x30]
[debug]   0x6d11fa7b <+11>: movesi,DWORD PTR [esp+0x34]
[debug]   0x6d11fa7f <+15>: test   ebx,ebx
[debug]   0x6d11fa81 <+17>: je 0x6d11fb50

[debug]   0x6d11fa87 <+23>: moveax,DWORD PTR [ebx]
[debug]   0x6d11fa89 <+25>: movecx,ebx
[debug]   0x6d11fa8b <+27>: call   DWORD PTR [eax]
[debug]   0x6d11fa8d <+29>: test   esi,esi
[debug]   0x6d11fa8f <+31>: movedx,eax
[debug]   0x6d11fa91 <+33>: je 0x6d11fb50

[debug]   0x6d11fa97 <+39>: cmpeax,esi
[debug]   0x6d11fa99 <+41>: je 0x6d11fb3e

[debug]   0x6d11fa9f <+47>: movedi,DWORD PTR [eax+0xc]
[debug]   0x6d11faa2 <+50>: test   edi,edi
[debug]   0x6d11faa4 <+52>: je 0x6d11fb05

[debug]   0x6d11faa6 <+54>: cmpesi,edi
[debug]   0x6d11faa8 <+56>: je 0x6d11fb3e

[debug]   0x6d11faae <+62>: movebp,DWORD PTR [edi+0xc]
[debug]   0x6d11fab1 <+65>: test   ebp,ebp
[debug]   0x6d11fab3 <+67>: je 0x6d11faed

[debug]   0x6d11fab5 <+69>: cmpesi,ebp
[debug]   0x6d11fab7 <+71>: je 0x6d11fb3e

[debug]   0x6d11fabd <+77>: movecx,DWORD PTR [ebp+0xc]
[debug]   0x6d11fac0 <+80>: test   ecx,ecx
[debug]   0x6d11fac2 <+82>: je 0x6d11fad5

[debug]   0x6d11fac4 <+84>: movDWORD PTR [esp],esi
[debug]   0x6d11fac7 <+87>: call   0x6d166c80

[debug]   0x6d11facc <+92>: subesp,0x4
[debug]   0x6d11facf <+95>: test   al,al
[debug]   0x6d11fad1 <+97>: movecx,ebx
[debug]   0x6d11fad3 <+99>: jne0x6d11fb40

[debug]   0x6d11fad5 <+101>:movecx,DWORD PTR [ebp+0x10]
[debug]   0x6d11fad8 <+104>:test   ecx,ecx
[debug]   0x6d11fada <+106>:je 0x6d11faed

[debug]   0x6d11fadc <+108>:movDWORD PTR [esp],esi
[debug]   0x6d11fadf <+111>:call   0x6d166c80

[debug]   0x6d11fae4 <+116>:subesp,0x4
[debug]   0x6d11fae7 <+119>:test   al,al
[debug]   0x6d11fae9 <+121>:movecx,ebx
[debug]   0x6d11faeb <+123>:jne0x6d11fb40

[debug]   0x6d11faed <+125>:movecx,DWORD PTR [edi+0x10]
[debug]   0x6d11faf0 <+128>:test   ecx,ecx
[debug]   0x6d11faf2 <+130>:je 0x6d11fb05

[debug]   0x6d11faf4 <+132>:movDWORD PTR [esp],esi
[debug]   0x6d11faf7 <+135>:call   0x6d166c80

[debug]   0x6d11fafc <+140>:subesp,0x4
[debug]   0x6d11faff <+143>:test   al,al
[debug]   0x6d11fb01 <+145>:movecx,ebx
[debug]   0x6d11fb03 <+147>:jne0x6d11fb40

[debug]=> 0x6d11fb05 <+149>:movedx,DWORD PTR [edx+0x10]
[debug]   0x6d11fb08 <+152>:test   edx,edx
[debug]   0x6d11fb0a <+154>:je 0x6d11fb50

[debug]   0x6d11fb0c <+156>:cmpesi,edx
[debug]   0x6d11fb0e <+158>:je 0x6d11fb3e

[debug]   0x6d11fb10 <+160>:movecx,DWORD PTR [edx+0xc]
[debug]   0x6d11fb13 <+163>:test   ecx,ecx
[debug]   0x6d11fb15 <+165>:je 0x6d11fb28

[debug]   0x6d11fb17 <+167>:movDWORD PTR [esp],esi
[debug]   0x6d11fb1a <+170>:call   0x6d166c80

[debug]   0x6d11fb1f <+175>:subesp,0x4
[debug]   0x6d11fb22 <+178>:test   al,al
[debug]   0x6d11fb24 <+180>:movecx,ebx
[debug]   0x6d11fb26 <+182>:jne0x6d11fb40

[debug]   0x6d11fb28 <+184>:movecx,DWORD PTR [edx+0x10]
[debug]   0x6d11fb2b <+187>:test   ecx,ecx
[debug]   0x6d11fb2d <+189>:je 0x6d11fb50

[debug]   0x6d11fb2f <+191>:movDWORD PTR [esp],esi
[debug]   0x6d11fb32 <+194>:call   0x6d166c80

[debug]   0x6d11fb37 <+199>:subesp,0x4
[debug]   0x6d11fb3a <+202>:test   al,al
[debug]   0x6d11fb3c <+204>:je 0x6d11fb50

[debug]   0x6d11fb3e <+206>:movecx,ebx
[debug]   0x6d11fb40 <+208

[Bug tree-optimization/66278] Missed auto-vectorization of an array subtraction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||6.1.0

--- Comment #3 from Andrew Pinski  ---
I know there has been some improvements to tree-chrec on the trunk but I have
not tried there yet.

[Bug libgomp/65070] libgomp calls syscall instruction directly

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Nadav Har'El from comment #4)
> *That* is the Linux ABI, not the  x86-64 instruction.

Actually the Linux ABI is just the syscall ABI, nothing more and nothing less. 
The GNU/Linux ABI (glibc) is built on top of the syscall ABI.

[Bug c++/70229] error: constexpr constructor does not have empty body

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||6.1.0

--- Comment #4 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #3)
> but this is not a regression so I suppose we'll have to wait till gcc7?

It is now stage 1 of gcc 7, it might be a good idea to test and put in this
patch.

[Bug c++/54366] [meta-bug] decltype issues

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
.

[Bug c/67025] Missing aggressive loop optimization warning when -fPIC used

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Not a bug and here is why:
With -fPIC foo is considered as being able to be overridden at runtime so it
cannot be inlined into main.
Without -fPIC, since foo cannot be changed at runtime and it is called once and
it is small, it gets inline.