[Bug c++/66647] [5/6 regression] ICE: in instantiate_class_template_1, at cp/pt.c:9254

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Could you please attach the unreduced testcase?

[Bug c++/66647] [5/6 regression] ICE: in instantiate_class_template_1, at cp/pt.c:9254

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.2

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-24
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Well, even if it is a small loop the theory is that mem* inline expansion will
produce better code than the loop copying chars.

niter is

  :
  if (flag_6(D) == 1)
goto ;
  else
goto ;

  :

  :
  # prephitmp_41 = PHI <-1(OVF)(2), 2(3)>

...
  _3 = (unsigned short) prephitmp_41;
  _30 = _3 + 65535;
  _48 = (sizetype) _30;

here and the loop is guarded with

  :
  # i_28 = PHI 
  if (prephitmp_41 > 0)

there is a pre-existing issue of a (OVF) constant in the IL (that's a no-no)
and a missed jump-threading to expose the constant.  There is also
range info on the size argument of the memmove at expansion time:

  # RANGE [1, 2] NONZERO 3
  _47 = _48 + 1;
  __builtin_memmove (_36, _33, _47);


but we don't seem to have a target/middle-end expander for BUILT_IN_MEMMOVE.
So that's a missed optimization there.

Without loop distribution we fail to peel the inner loop as well (on the
tree level), because

Loop 2 iterates at most 32767 times.

so we fail to compute a proper upper bound.  The very same issue is
present during loop distribution so it can't know the loop iterates only
1 or 2 times.

Apart from special-casing this memmove in RTL expansion we could also enhance
the memory builtin folders (in gimple-fold.c) to honor range information
and in this case expand the memmove to something more optimal, like

  if (_47 == 1)
*_36 = *_33;
  else
*(unsigned short *)_36 = *(unsigned short *)_33;

of course creating control-flow here is not expected (so dealing with this
at RTL expansion time is easier).


Thus confirmed - but applies to similar loops (niter bound not precise)
before the SCEV changes.

[Bug c++/66647] [5/6 regression] ICE: in instantiate_class_template_1, at cp/pt.c:9254

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-24
  Known to work||4.9.2
 Ever confirmed|0   |1
  Known to fail||5.0, 6.0

--- Comment #2 from Markus Trippelsdorf  ---
markus@x4 tmp % cat testcase.ii
template  struct A
{
  static constexpr _Tp value = 1;
};
template  class B
{
public:
  template  struct rebind
  {
  };
};

template  class C
{
  template 
  static A _S_chk (typename _Alloc2::template rebind<_Tp2> *);

public:
  using __type = decltype (_S_chk<_Alloc, _Tp> (0));
};

template ::__type::value>
struct D;
template  struct D<_Alloc, _Tp, 1>
{
  typedef typename _Alloc::template rebind<_Tp> __type;
};
template  struct F
{
  template  using rebind_alloc = typename D<_Alloc, _Tp>::__type;
};
template  struct __alloc_traits
{
  template  struct rebind
  {
typedef typename F<_Alloc>::template rebind_alloc other;
  };
};
template  struct G
{
  typename __alloc_traits<_Alloc>::template rebind::other _Tp_alloc_type;
};
template  > class vector : G<_Alloc>
{
};

template  using tfuncptr = void();
template  struct H
{
  vector > funcs;
};


markus@x4 tmp % g++ -std=c++11 testcase.ii
testcase.ii: In instantiation of ‘struct B::rebind’:
testcase.ii:41:64:   required from ‘struct G > >’
testcase.ii:43:58:   required from ‘class vector >’
testcase.ii:50:24:   required from here
testcase.ii:8:30: internal compiler error: in instantiate_class_template_1, at
cp/pt.c:9267
   template  struct rebind
  ^
0x662f01 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:9266
0x662f01 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9730
0x70763b complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:139
0x6629b9 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:9503
0x6629b9 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9730
0x70763b complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:139
0x70782f complete_type_or_maybe_complain(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.c:151
0x5faf79 xref_basetypes(tree_node*, tree_node*)
../../gcc/gcc/cp/decl.c:12474
0x662246 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:9328
0x662246 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9730
0x70763b complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:139
0x609350 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/gcc/cp/decl.c:10782
0x6ac556 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../../gcc/gcc/cp/decl2.c:876
0x6fb20b cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:21123
0x6d6e0d cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:20675
0x6d6e0d cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:19867
0x6d6e0d cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:20103
0x6d6e0d cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14732
0x6ea87e cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11958
0x6f9e98 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:23771
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++/66647] [5/6 regression] ICE: in instantiate_class_template_1, at cp/pt.c:9254

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Started with r217250.

[Bug c++/66647] [5/6 regression] ICE: in instantiate_class_template_1, at cp/pt.c:9254

[allan at archlinux dot org]

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

--- Comment #4 from Allan McRae  ---
Created attachment 35839
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35839&action=edit
Unreduced testcase

Unreduced testcase attached.

[Bug target/63408] [4.9/5/6 regression] GCC emits incorrect fixed->fp conversion instruction on Cortex-M4 target

[ramana at gcc dot gnu.org]

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

--- Comment #13 from Ramana Radhakrishnan  ---
Author: ramana
Date: Wed Jun 24 08:28:08 2015
New Revision: 224879

URL: https://gcc.gnu.org/viewcvs?rev=224879&root=gcc&view=rev
Log:
Fix PR target/63408

The attached patch fixes PR target/63408 and adds a regression test
for the same. The problem is essentially that
vfp3_const_double_for_fract_bits() needs to be aware that negative
values cannot be used in this context.

Tested with a bootstrap and regression test run on armhf. Applied.




2015-06-24  Ramana Radhakrishnan  

PR target/63408
* config/arm/arm.c (vfp3_const_double_for_fract_bits): Disable
for negative numbers.

2015-06-24  Ramana Radhakrishnan  

PR target/63408
* gcc.target/arm/pr63408.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr63408.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/30044] ICE in tsubst, at cp/pt.c:7359

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/65375] aarch64: poor codegen for vld2q_f32 and vst2q_f32

[ramana at gcc dot gnu.org]

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

--- Comment #11 from Ramana Radhakrishnan  ---
(In reply to Jim Wilson from comment #10)
> Improved, but not completely resolved.  We still get unnecessary orr
> instructions, same as in comment 2.  This is partly an issue with the
> register allocator not handling partially overlapping register reads/writes
> very well.  We already have a few other bugs for that.  This is also partly
> an issue with how the aarch64 builtins work, via
> __builtin_aarch64_[gs]et_qregoiv4sf which create the partially overlapping
> register reads/writes.  The ARM builtins don't work this way, they use a
> union for type punning, and hence don't have the same problem.

Both the ARM and the AArch64 ports have the issues with partially overlapping
register reads / writes especially with the vzip / vuzip style intrinsics in
AArch32 world or even the larger vld3/4 intrinsics in both ARM and AArch64
states. It would be nice to fix that finally.

If that is the only issue left in the ticket - maybe we should just park this
example in that ticket - IIRC PR43725 and close this one out ?

regards
Ramana

[Bug target/65375] aarch64: poor codegen for vld2q_f32 and vst2q_f32

[kugan at gcc dot gnu.org]

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

kugan at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #12 from kugan at gcc dot gnu.org ---
Fixed in trunk except for the additional orr instruction (overlapping register
reads / write). As Ramana mentioned, that is a known problem and tracked in
PR43725.

[Bug fortran/66549] [5 Regression] ICE on valid in OMP parallel region

[mikael at gcc dot gnu.org]

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

--- Comment #6 from Mikael Morin  ---
Author: mikael
Date: Wed Jun 24 09:16:13 2015
New Revision: 224887

URL: https://gcc.gnu.org/viewcvs?rev=224887&root=gcc&view=rev
Log:
Fix openmp global state fortran regression

PR fortran/66549
gcc/fortran/
* resolve.c (resolve_global_procedure): Don't save and restore
OpenMP state around the call to gfc_resolve.
(gfc_resolve): Save OpenMP state on entry and restore it on return.
gcc/testsuite/
* gfortran.dg/gomp/omp_parallel_1.f90: New file.


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/gomp/omp_parallel_1.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/65811] [6 Regression] ice in vague_linkage_p

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Jun 24 09:21:45 2015
New Revision: 224888

URL: https://gcc.gnu.org/viewcvs?rev=224888&root=gcc&view=rev
Log:
/cp
2015-06-24  Paolo Carlini  

PR c++/65811
* decl.c (duplicate_decls): Adjust DECL_COMDAT of newdecl.

/testsuite
2015-06-24  Paolo Carlini  

PR c++/65811
* g++.dg/other/linkage2.C: New.

Added:
trunk/gcc/testsuite/g++.dg/other/linkage2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/65811] [6 Regression] ice in vague_linkage_p

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #6 from Paolo Carlini  ---
Fixed.

[Bug c++/66639] Feature request C++: mark __func__ , __FUNCTION__ & __PRETTY_FUNCTION__ as constexpr

[simon at gleissner dot de]

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

--- Comment #3 from Simon Gleissner  ---
Hi *

> If at all, this could only be provided as compiler extension.

Good point. Yes, i think this would be a adequate solution.

> (assuming making it constexpr doesn't break anything)

... which IMHO could only be tested safely with an optional compiler switch.

I have modified the test program (see below), instead of __PRETTY_FUNCTION__ i
have declared a 'static constexpr const char testarray[]'. This works
perfectly, the concatenated string is now stored as a constant object in
section .rodata:

.section.rodata
.align 32
.type   _ZZ4mainE4what, @object
.size   _ZZ4mainE4what, 37
_ZZ4mainE4what:
.byte   105
.byte   110
.byte   32
.byte   39
...

As 'testarray[]' is no longer needed after evaluating 'what', it is removed
completely (i have not found it in the .S file), therefore only the final
string is stored.


#define THROW_SYSTEM_ERROR(ERROR_NO, CAUSE) \
do{ \
constexpr static auto what = MyLib::concatenate(\
"in '", testarray, "' by '" CAUSE "'"); \
throw std::system_error(ERROR_NO,   \
std::system_category(), what.str);  \
} while(0)

int main()
{
try
{
static constexpr const char testarray[] = "constexprFunc()";

THROW_SYSTEM_ERROR(EINVAL, "testfunc()");
}
catch(const std::system_error& exception)
{
std::cerr << "Exception " << exception.what() << " (" <<
exception.code() << ")" << std::endl;
}

return 0;
}

[Bug fortran/66549] [5/6 Regression] ICE on valid in OMP parallel region

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[5 Regression] ICE on valid |[5/6 Regression] ICE on
   |in OMP parallel region  |valid in OMP parallel
   ||region

--- Comment #7 from Mikael Morin  ---
Fixed on trunk (upcoming 6.1) and 5 branch (upcoming 5.2).

[Bug fortran/66633] [5/6 regression] ICE on valid "verify_gimple failed" with OpenMP

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

Summary|ICE on valid "verify_gimple |[5/6 regression] ICE on
   |failed" with OpenMP |valid "verify_gimple
   ||failed" with OpenMP

--- Comment #3 from Mikael Morin  ---
The backtrace on the 5 branch is:

comment_1.f90:4:0:

 !$omp parallel
 ^
internal compiler error: in get_expr_operands, at tree-ssa-operands.c:910
0xb973ef get_expr_operands
/home/mik/gcc/svn_gcc5/src/gcc/tree-ssa-operands.c:910
0xb972fb get_expr_operands
/home/mik/gcc/svn_gcc5/src/gcc/tree-ssa-operands.c:798
0xb97806 parse_ssa_operands
/home/mik/gcc/svn_gcc5/src/gcc/tree-ssa-operands.c:959
0xb98c77 build_ssa_operands
/home/mik/gcc/svn_gcc5/src/gcc/tree-ssa-operands.c:974
0xb98c77 update_stmt_operands(function*, gimple_statement_base*)
/home/mik/gcc/svn_gcc5/src/gcc/tree-ssa-operands.c:1105
0xaeb7b0 update_stmt
/home/mik/gcc/svn_gcc5/src/gcc/gimple-ssa.h:178
0xaeb7b0 mark_def_sites
/home/mik/gcc/svn_gcc5/src/gcc/tree-into-ssa.c:703
0xaeb7b0 mark_def_dom_walker::before_dom_children(basic_block_def*)
/home/mik/gcc/svn_gcc5/src/gcc/tree-into-ssa.c:2300
0xf70961 dom_walker::walk(basic_block_def*)
/home/mik/gcc/svn_gcc5/src/gcc/domwalk.c:188
0xae987a execute
/home/mik/gcc/svn_gcc5/src/gcc/tree-into-ssa.c:2412
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


The 4.9 branch accepts the code, at least at revision r222077, which makes this
a regression.

[Bug c++/65919] Regression - GCC 5.1 with options "-g -std=c++14" fails to compile multiple lambdas used as default function parameters

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|drew.dormann at gmail dot com  |
   Severity|major   |normal

[Bug c++/65919] [5/6 Regression] GCC 5.1 with options "-g -std=c++14" fails to compile multiple lambdas used as default function parameters

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-24
Summary|Regression - GCC 5.1 with   |[5/6 Regression] GCC 5.1
   |options "-g -std=c++14" |with options "-g
   |fails to compile multiple   |-std=c++14" fails to
   |lambdas used as default |compile multiple lambdas
   |function parameters |used as default function
   ||parameters
 Ever confirmed|0   |1

[Bug fortran/66633] [5/6 regression] ICE on valid "verify_gimple failed" with OpenMP

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-24
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
> The 4.9 branch accepts the code, at least at revision r222077,
> which makes this a regression.

This is only true for the reduced test in comment 1. This occurred between
revisions r211105 (2014-05-31, OK) and r211652 (2014-06-13, ICE).

The original test gives an ICE starting at 4.6.4 (it does not compile without
error with 4.5).

[Bug target/66200] GCC for ARM / AArch64 doesn't define TARGET_RELAXED_ORDERING

[ramana at gcc dot gnu.org]

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

--- Comment #8 from Ramana Radhakrishnan  ---
Author: ramana
Date: Wed Jun 24 09:59:28 2015
New Revision: 224890

URL: https://gcc.gnu.org/viewcvs?rev=224890&root=gcc&view=rev
Log:
Fix PR target/66200

This applies the same fix for PR target/66200 for AArch64 on the GCC 5 branch
as on the 4.9 branch. On trunk we've fixed this differently by optimizing
the access to the guard variable using a load acquire style instruction.

2015-06-24  Ramana Radhakrishnan  

PR target/66200
* g++.dg/abi/aarch64_guard1.C: Adjust.

2015-06-24  Ramana Radhakrishnan  

PR target/66200
* configure.host (host_cpu): Add aarch64 case.
* config/cpu/aarch64/atomic_word.h: New file.



Added:
branches/gcc-5-branch/libstdc++-v3/config/cpu/aarch64/
branches/gcc-5-branch/libstdc++-v3/config/cpu/aarch64/atomic_word.h
Modified:
branches/gcc-5-branch/gcc/config/aarch64/aarch64.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/g++.dg/abi/aarch64_guard1.C
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/configure.host

[Bug target/66648] New: [4.9/5/6 regression] incorrect memcpy expansion with unrolled_loop strategy at -O2

[ebotcazou at gcc dot gnu.org]

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

Bug ID: 66648
   Summary: [4.9/5/6 regression] incorrect memcpy expansion with
unrolled_loop strategy at -O2
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-linux

Created attachment 35840
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35840&action=edit
Testcase

One of the numerous paths of ix86_expand_set_or_movmem using the unrolled_loop
strategy can generate wrong code (buffer overflow) at -O2, when VRP is able to
compute a minimum copying size.

Compile and run the attached testcase with -O2
-mstringop-strategy=unrolled_loop -mtune=nocona on a x86-64/Linux machine.

[Bug target/66648] [4.9/5/6 regression] incorrect memcpy expansion with unrolled_loop strategy at -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.3

[Bug bootstrap/66638] [6 Regression] profiledbootstrap failure on x86-64 with LTO

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org,
   ||izamyatin at gmail dot com

--- Comment #1 from Igor Zamyatin  ---
r224020 is guilty

[Bug c++/30044] ICE in tsubst, at cp/pt.c:7359

[ppalka at gcc dot gnu.org]

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

--- Comment #6 from Patrick Palka  ---
Author: ppalka
Date: Wed Jun 24 12:10:57 2015
New Revision: 224896

URL: https://gcc.gnu.org/viewcvs?rev=224896&root=gcc&view=rev
Log:
Revert fix for PR c++/30044

gcc/cp/ChangeLog:

Revert:
2015-06-23  Patrick Palka  

PR c++/30044
* parser.c (cp_parser_template_parameter_list): Update
current_template_parms right after processing a paramater.
* pt.c (template_parms_to_args): Remove obsolete hack for
giving template template arguments the proper level.
(check_default_tmpl_args): Account for tested template
parameter_lists.
(splite_late_return_type): Remove obsolete hack for giving
template template arguments the proper level.

gcc/testsuite/ChangeLog:

Revert:
2015-06-23  Patrick Palka  

PR c++/30044
* g++.dg/cpp0x/auto45.C: New test.
* g++.dg/template/pr30044.C: New test.
* g++.dg/template/crash83.C: Accept any error string.
* g++.dg/cpp0x/variadic18.C: Adjust to not shadow template
parameters.
* g++.dg/cpp0x/variadic18.C: Likewise
* g++.dg/template/canon-type-13.C: Likewise.
* g++.old-deja/g++.pt/ttp42.C: Likewise.


Removed:
trunk/gcc/testsuite/g++.dg/cpp0x/auto45.C
trunk/gcc/testsuite/g++.dg/template/pr30044.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/variadic18.C
trunk/gcc/testsuite/g++.dg/cpp0x/variadic19.C
trunk/gcc/testsuite/g++.dg/template/canon-type-13.C
trunk/gcc/testsuite/g++.dg/template/crash83.C
trunk/gcc/testsuite/g++.dg/torture/20070621-1.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/ttp42.C

[Bug c++/30044] ICE in tsubst, at cp/pt.c:7359

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #7 from Patrick Palka  ---
Reopened, the fix was reverted because it caused the build of LLVM to seemingly
hang.

[Bug target/66648] [4.9/5/6 regression] incorrect memcpy expansion with unrolled_loop strategy at -O2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Uroš Bizjak  ---
Adding CC.

[Bug target/66611] SH: ICE on -O2

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-24
 Ever confirmed|0   |1

--- Comment #2 from Oleg Endo  ---
Sorry, not the same issue as PR 66358.  It seems more like another bug of PR
65979, which is a buggy peephole optimization.

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[olegendo at gcc dot gnu.org]

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

--- Comment #36 from Oleg Endo  ---
It seems the tstsi peephole is still wrong.  While working on AMS the following
example:

int test (char* x, char* y, int z)
{
  return ((x[2] & x[3]) == 0) + z;
}

silently produced wrong code by omitting one of the two mem loads.  After an
update to the current trunk it results in

sh_tmp.cpp: In function 'int test(char*, char*, int)':
sh_tmp.cpp:6:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 88 69 89 2 (set (reg:SI 1 r1)
(sign_extend:SI (mem:QI (plus:SI (reg/v/f:SI 4 r4 [orig:169 x ] [169])
(const_int 3 [0x3])) [0 MEM[(char *)x_1(D) + 3B]+0 S1
A8]))) sh_tmp.cpp:5 232 {*extendqisi2_compact_mem_disp}
 (nil))

which I think is the same as PR 66611.  The tstsi related peephole at line
14709 is causing the trouble.

[Bug c++/66639] declare __func__ , __FUNCTION__ & __PRETTY_FUNCTION__ as constexpr

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

Version|5.1.1   |6.0
Summary|Feature request C++: mark   |declare __func__ ,
   |__func__ , __FUNCTION__ &   |__FUNCTION__ &
   |__PRETTY_FUNCTION__ as  |__PRETTY_FUNCTION__ as
   |constexpr   |constexpr

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Simon Gleissner from comment #3)
> > If at all, this could only be provided as compiler extension.
> 
> Good point. Yes, i think this would be a adequate solution.
> 
> > (assuming making it constexpr doesn't break anything)
> 
> ... which IMHO could only be tested safely with an optional compiler switch.

Due to past negative experiences, compiler extensions are only accepted under
very careful consideration and if they do not conflict with an existing (or
future) standard. Extensions accepted under an optional compiler switch are
even more rare: They add another very rarely tested point of failure and
increment the complexity of the compiler for very little benefit. The best
option is: create a tentative implementation, test it (by compiling and testing
GCC, libstdc++, boost, QT, Clang and other large C++ code bases) and propose
its standardization.

[Bug c++/66649] New: variable template specializations not being found

[public at alisdairm dot net]

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

Bug ID: 66649
   Summary: variable template specializations not being found
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: public at alisdairm dot net
  Target Milestone: ---

Created attachment 35841
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35841&action=edit
C++ code that should compile in C++14 mode, but fails

The attached file shows a simple test case for variable templates that I
believe is correct, and passes with Clang:

template 
constexpr bool is_same_v = false;

template 
constexpr bool is_same_v = true;

template 
auto make() -> T;

template 
void AssertMakeSame() {
   static_assert( is_same_v, "Type should be the same as itself");
   static_assert( is_same_v()), T>, "make should produce the
same type");
};

int main() {
   AssertMakeSame();
// AssertMakeSame();  // Should be an error
   AssertMakeSame();
}


In gcc 5, I get an error that the partial specialization must be at namespace
scope, but this appears to be fixed in trunk.  However, all 4 static asserts
fire in both trunk and 5.

Tested with:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin14/6.0.0/lto-wrapper
Target: x86_64-apple-darwin14
Configured with:
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/gcc6/work/gcc-6-20150614/configure
--prefix=/opt/local --build=x86_64-apple-darwin14
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc6 --includedir=/opt/local/include/gcc6
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-6 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-6
--with-gxx-include-dir=/opt/local/include/gcc6/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc6 6-20150614_0'
Thread model: posix
gcc version 6.0.0 20150614 (experimental) (MacPorts gcc6 6-20150614_0) 


and with:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin14/5.1.0/lto-wrapper
Target: x86_64-apple-darwin14
Configured with:
/opt/local/var/macports/build/_opt_mports_dports_lang_gcc5/gcc5/work/gcc-5.1.0/configure
--prefix=/opt/local --build=x86_64-apple-darwin14
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc5 --includedir=/opt/local/include/gcc5
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-5 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-5
--with-gxx-include-dir=/opt/local/include/gcc5/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc5 5.1.0_1'
Thread model: posix
gcc version 5.1.0 (MacPorts gcc5 5.1.0_1)

[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler

[olegendo at gcc dot gnu.org]

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

--- Comment #37 from Oleg Endo  ---
(In reply to Oleg Endo from comment #36)
> It seems the tstsi peephole is still wrong.  While working on AMS the
> following example:
> 
> int test (char* x, char* y, int z)
> {
>   return ((x[2] & x[3]) == 0) + z;
> }
> 
> silently produced wrong code by omitting one of the two mem loads.  After an
> update to the current trunk it results in
> 
> sh_tmp.cpp: In function 'int test(char*, char*, int)':
> sh_tmp.cpp:6:1: error: insn does not satisfy its constraints:
>  }
>  ^
> (insn 88 69 89 2 (set (reg:SI 1 r1)
> (sign_extend:SI (mem:QI (plus:SI (reg/v/f:SI 4 r4 [orig:169 x ]
> [169])
> (const_int 3 [0x3])) [0 MEM[(char *)x_1(D) + 3B]+0 S1
> A8]))) sh_tmp.cpp:5 232 {*extendqisi2_compact_mem_disp}
>  (nil))
> 
> which I think is the same as PR 66611.  The tstsi related peephole at line
> 14709 is causing the trouble.

The peephole in question can't be used for code sequences that include QImode
or HImode mem loads of the operands.  The following fixes the issue by matching
the resulting insn pattern and the constraints while emitting the new peephole
insns.  I think it's good to do those full checks as opposed to checking for
the currently known problematic mem loads.  This way we an be sure that
whatever the "emit_insn (gen_rtx_SET ..." produces is actually valid code.

The problem exists on the 5 branch and on trunk.

Kaz, could you please add this to your test runs?  For me it's a bit difficult
to do proper testing at the moment.

Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 224565)
+++ gcc/config/sh/sh.md (working copy)
@@ -14727,8 +14727,19 @@
   if (REGNO (operands[1]) == REGNO (operands[2]))
   operands[2] = gen_rtx_REG (SImode, REGNO (operands[0]));

-  sh_check_add_incdec_notes (emit_insn (gen_rtx_SET (operands[2],
-operands[3])));
+  // We don't know what the new set insn will be in detail.  Just make sure
+  // that it still can be recognized and the constraints are satisfied.
+  rtx_insn* i = emit_insn (gen_rtx_SET (operands[2], operands[3]));
+
+  recog_data_d prev_recog_data = recog_data;
+  bool i_invalid = insn_invalid_p (i, false); 
+  recog_data = prev_recog_data;
+  
+  if (i_invalid)
+FAIL;
+
+  sh_check_add_incdec_notes (i);
+
   emit_insn (gen_tstsi_t (operands[2],
  gen_rtx_REG (SImode, (REGNO (operands[1]);
 })
@@ -14755,8 +14766,19 @@
|| REGNO (operands[2]) == REGNO (operands[5]))"
   [(const_int 0)]
 {
-  sh_check_add_incdec_notes (emit_insn (gen_rtx_SET (operands[2],
-operands[3])));
+  // We don't know what the new set insn will be in detail.  Just make sure
+  // that it still can be recognized and the constraints are satisfied.
+  rtx_insn* i = emit_insn (gen_rtx_SET (operands[2], operands[3]));
+
+  recog_data_d prev_recog_data = recog_data;
+  bool i_invalid = insn_invalid_p (i, false); 
+  recog_data = prev_recog_data;
+  
+  if (i_invalid)
+FAIL;
+
+  sh_check_add_incdec_notes (i);
+  
   emit_insn (gen_tstsi_t (operands[2],
  gen_rtx_REG (SImode, (REGNO (operands[1]);
 })

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[olegendo at gcc dot gnu.org]

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

--- Comment #33 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #32)

I see, thanks.  In this case, could you please add a comment e.g.:

;; Loads of the GOTPC relocation values must not be optimized away
;; by e.g. any kind of CSE and must stay as they are.  Although there
;; are other various ways to ensure this, we use an artificial counter
;; operand to generate unique symbols.
(define_expand "GOTaddr2picreg"

[Bug libfortran/66650] New: libgfortran: warning: left shift of negative value [-Wshift-negative-value]

[tschwinge at gcc dot gnu.org]

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

Bug ID: 66650
   Summary: libgfortran: warning: left shift of negative value
[-Wshift-negative-value]
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

As of the changes in context of PR65179,
,
I'm seeing a bunch of -Wshift-negative-value warnings in the libgfortran build,
for example:

In file included from [...]/libgfortran/intrinsics/cshift0.c:26:0:
[...]/libgfortran/intrinsics/cshift0.c: In function 'cshift0':
[...]/libgfortran/libgfortran.h:408:48: warning: left shift of negative
value [-Wshift-negative-value]
   ((~((index_type) 0) >> GFC_DTYPE_SIZE_SHIFT) << GFC_DTYPE_SIZE_SHIFT)
^
[...]/libgfortran/libgfortran.h:409:35: note: in expansion of macro
'GFC_DTYPE_SIZE_MASK'
 #define GFC_DTYPE_TYPE_SIZE_MASK (GFC_DTYPE_SIZE_MASK |
GFC_DTYPE_TYPE_MASK)
   ^
[...]/libgfortran/libgfortran.h:411:52: note: in expansion of macro
'GFC_DTYPE_TYPE_SIZE_MASK'
 #define GFC_DTYPE_TYPE_SIZE(desc) ((desc)->dtype &
GFC_DTYPE_TYPE_SIZE_MASK)
^
[...]/libgfortran/intrinsics/cshift0.c:94:15: note: in expansion of macro
'GFC_DTYPE_TYPE_SIZE'
   type_size = GFC_DTYPE_TYPE_SIZE (array);
   ^

Unless this will be resolved by demoting the warning (I have not reviewed the
recent discussion, such as PR66066,
),
I supposed this should be fixed in libgfortran/libgfortran.h, perhaps by making
index_type an unsiged type if that's possible?

[Bug tree-optimization/66642] transform_to_exit_first_loop_alt doesn't use result of low iteration count loop

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Created attachment 35842
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35842&action=edit
[1/2] Tentative patch

[Bug tree-optimization/66642] transform_to_exit_first_loop_alt doesn't use result of low iteration count loop

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
Created attachment 35843
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35843&action=edit
[2/2] Tentative patch

[Bug c++/66651] New: altivec.h + c++11 r

[timothee.ewart at epfl dot ch]

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

Bug ID: 66651
   Summary: altivec.h + c++11 r
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: timothee.ewart at epfl dot ch
  Target Milestone: ---

#include 
#include 
int main(){

}

hch058@jupp30:~/miniapps/ll-counter$ g++ --version
g++ (Ubuntu 4.9.1-16ubuntu6) 4.9.1
Copyright (C) 2014 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.

hch058@jupp30:~/miniapps/ll-counter$ g++ -std=c++11 -maltivec main.cpp
In file included from main.cpp:2:0:
/usr/include/c++/4.9/limits:195:57: error: cannot convert ‘bool’ to ‘const
__vector(4) __bool int’ in initialization
 static _GLIBCXX_USE_CONSTEXPR bool is_specialized = false;


machine: Power8 machine boot in little_endian, Ubuntu 14.10

[Bug c++/65750] [4.9/5 Regression] misinterpret in a virtual member function with a C++11 style function signature

[paolo at gcc dot gnu.org]

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

--- Comment #7 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Jun 24 15:11:06 2015
New Revision: 224901

URL: https://gcc.gnu.org/viewcvs?rev=224901&root=gcc&view=rev
Log:
/cp
2015-06-24  Adam Butcher  

PR c++/65750
* parser.c (cp_parser_simple_type_specifier): Don't synthesize
implicit template parm if 'auto' is a placeholder for trailing
return type.

/testsuite
2015-06-24  Adam Butcher  

PR c++/65750
* g++.dg/cpp0x/trailing11.C: New.

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

[Bug c++/65750] [4.9/5 Regression] misinterpret in a virtual member function with a C++11 style function signature

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  ---
Fixed in trunk so far.

[Bug c++/66651] altivec.h + c++11 r

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I believe that is a user error.
When using altivec.h and -maltivec in C++, you should either use the non-iso
-std modes like -std=gnu++11 or -std=gnu++98 or -std=gnu++14, or
#undef vector
#undef bool
after including altivec.h, or -D__APPLE_ALTIVEC__.  In iso modes without
-D__APPLE_ALTIVEC__, vector/bool are not contextual macros, but normal macros,
which is of course totally incompatible with all of the STL.

[Bug c++/66501] [4.9/5/6 Regression] Default move assignment does not move array members

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Jun 24 15:40:08 2015
New Revision: 224904

URL: https://gcc.gnu.org/viewcvs?rev=224904&root=gcc&view=rev
Log:
PR c++/66501
* class.c (type_has_nontrivial_assignment): Remove.
* cp-tree.h: Remove declaration.
* init.c (vec_copy_assign_is_trivial): New.
(build_vec_init): Use it.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/init.c

[Bug c++/66501] [4.9/5/6 Regression] Default move assignment does not move array members

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed Jun 24 15:41:10 2015
New Revision: 224905

URL: https://gcc.gnu.org/viewcvs?rev=224905&root=gcc&view=rev
Log:
PR c++/66501
* init.c (vec_copy_assign_is_trivial): New.
(build_vec_init): Use it.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/rv-array1.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/init.c

[Bug c++/66501] [4.9/5/6 Regression] Default move assignment does not move array members

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Jun 24 15:41:52 2015
New Revision: 224906

URL: https://gcc.gnu.org/viewcvs?rev=224906&root=gcc&view=rev
Log:
PR c++/66501
* init.c (vec_copy_assign_is_trivial): New.
(build_vec_init): Use it.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/rv-array1.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/init.c

[Bug c++/66651] altivec.h + c++11 r

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug c++/66651] altivec.h + c++11 r

[timothee.ewart at epfl dot ch]

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

timocafe  changed:

   What|Removed |Added

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

--- Comment #2 from timocafe  ---
Hum thank you for the point. It fixes the issue, have a nice day

[Bug rtl-optimization/66412] [5/6 Regression] ICE on valid code at -O2 and -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5748

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
This testcase exposes latent problem in combine pass in conjunction with debug.

We start with:

[...]

(insn 8 7 9 2 (set (reg:QI 95)
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) pr66412.c:9 597 {*setcc_qi}
 (expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
(insn 9 8 11 2 (set (reg:SI 94 [ D.1784 ])
(zero_extend:SI (reg:QI 95))) pr66412.c:9 134 {*zero_extendqisi2}
 (expr_list:REG_DEAD (reg:QI 95)
(nil)))
(debug_insn 11 9 12 2 (var_location:HI g (subreg:HI (reg:SI 94 [ D.1784 ]) 0))
pr66412.c:9 -1
 (nil))
(debug_insn 12 11 13 2 (var_location:HI e (subreg:HI (ashift:SI (reg:SI 94 [
D.1784 ])
(const_int 1 [0x1])) 0)) pr66412.c:10 -1
 (nil))
(insn 13 12 14 2 (parallel [
(set (reg:SI 96 [ D.1783 ])
(ashift:SI (reg:SI 94 [ D.1784 ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) pr66412.c:11 501 {*ashlsi3_1}
 (expr_list:REG_DEAD (reg:SI 94 [ D.1784 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 14 13 15 2 (set (reg:CCZ 17 flags)
(compare:CCZ (subreg:HI (reg:SI 96 [ D.1783 ]) 0)
(const_int 0 [0]))) pr66412.c:11 2 {*cmphi_ccno_1}
 (expr_list:REG_DEAD (reg:SI 96 [ D.1783 ])
(nil)))
(insn 15 14 16 2 (set (reg:QI 98)
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) pr66412.c:11 597 {*setcc_qi}
 (expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))

[...]

and combine pass sequentially combines several insns into (insn 15):

Trying 8 -> 9:
Successfully matched this instruction:
(set (reg:SI 94 [ D.1784 ])
(eq:SI (reg:CCZ 17 flags)
(const_int 0 [0])))
allowing combination of insns 8 and 9
original costs 4 + 4 = 8
replacement cost 4
deferring deletion of insn with uid = 8.
modifying insn i3 9: r94:SI=flags:CCZ==0
  REG_DEAD flags:CCZ
deferring rescan insn with uid = 9.

Trying 13 -> 14:
Successfully matched this instruction:
(set (reg:CCZ 17 flags)
(compare:CCZ (ashift:SI (reg:SI 94 [ D.1784 ])
(const_int 1 [0x1]))
(const_int 0 [0])))
allowing combination of insns 13 and 14
original costs 4 + 4 = 8
replacement cost 4
deferring deletion of insn with uid = 13.
modifying insn i314: {flags:CCZ=cmp(r94:SI<<0x1,0);clobber scratch;}
  REG_DEAD r94:SI
deferring rescan insn with uid = 14.

Trying 9, 14 -> 15:
Failed to match this instruction:
(set (reg:QI 98)
(ne:QI (eq:SI (reg:CCZ 17 flags)
(const_int 0 [0]))
(const_int 0 [0])))
Splitting with gen_split_5441
Successfully matched this instruction:
(set (reg:QI 98)
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0])))
allowing combination of insns 9, 14 and 15
original costs 4 + 4 + 4 = 12
replacement cost 4
deferring deletion of insn with uid = 14.

Calling propagate_for_debug for:

(debug_insn 11 9 12 2 (var_location:HI g (subreg:HI (reg:SI 94 [ D.1784 ]) 0))
pr66412.c:9 -1
 (nil))

we found (wrong) replacement for (reg:SI 94):

(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))

and we try to call simplify_gen_subreg with:

(gdb) f 3
#3  0x00aa2aaa in simplify_gen_subreg (outermode=HImode,
op=0x712aff00, innermode=SImode, byte=0) at
/home/uros/gcc-svn/trunk/gcc/simplify-rtx.c:5969
5969  newx = simplify_subreg (outermode, op, innermode, byte);
(gdb) p debug_rtx (op)
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))

which crashes at:

#2  0x00aa261a in simplify_subreg (outermode=HImode, op=0x712aff00,
innermode=SImode, byte=0) at /home/uros/gcc-svn/trunk/gcc/simplify-rtx.c:5749
5749  gcc_assert (GET_MODE (op) == innermode

[Bug libfortran/66650] libgfortran: warning: left shift of negative value [-Wshift-negative-value]

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-24
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed for r222892 and more recent revisions, not present for r222830.

[Bug rtl-optimization/66412] [5/6 Regression] ICE on valid code at -O2 and -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5748

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #4 from Uroš Bizjak  ---
CC combine pass expert.

[Bug debug/66482] [6 Regression] ICE in gen_formal_parameter_die

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #7 from Aldy Hernandez  ---
Fixed in mainline.

Sorry, I forgot to include the PR in the commit message (though it is in the
ChangeLog), so bugzilla didn't pick it up:

https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=224907

[Bug rtl-optimization/66412] [5/6 Regression] ICE on valid code at -O2 and -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5748

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
I bet the bug is in whatever creates the mode mismatch.

[Bug rtl-optimization/66412] [5/6 Regression] ICE on valid code at -O2 and -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5748

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
Please note that combine already calls propagate_for_debug with wrong i1src:

reakpoint 3, internal_error (gmsgid=gmsgid@entry=0x1622837 "in %s, at %s:%d")
at /home/uros/gcc-svn/trunk/gcc/diagnostic.c:1266
1266{
(gdb) f 6
#6  0x0103276c in try_combine (i3=i3@entry=0x7171c580,
i2=, i2@entry=0x7171c540, i1=, i0=, i0@entry=0x0, 
new_direct_jump_p=new_direct_jump_p@entry=0x7fffd95c,
last_combined_insn=last_combined_insn@entry=0x7171c580) at
/home/uros/gcc-svn/trunk/gcc/combine.c:4386
4386   this_basic_block);
(gdb) list
4381  {
4382LOG_LINKS (i1) = NULL;
4383REG_NOTES (i1) = 0;
4384if (MAY_HAVE_DEBUG_INSNS)
4385  propagate_for_debug (i1, last_combined_insn, i1dest, i1src,
4386   this_basic_block);
4387SET_INSN_DELETED (i1);
4388  }
4389
4390if (i0)
(gdb) p debug_rtx (i1dest)
(reg:SI 94 [ D.1784 ])
$74 = void
(gdb) p debug_rtx (i1src)
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))

[Bug rtl-optimization/66412] [5/6 Regression] ICE on valid code at -O2 and -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5748

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #5)
> I bet the bug is in whatever creates the mode mismatch.

I don't think so. Combiner somehow mixes up i1src, please see Comment #6.

[Bug tree-optimization/66652] New: try_transform_to_exit_first_loop_alt generates incorrect loop

[vries at gcc dot gnu.org]

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

Bug ID: 66652
   Summary: try_transform_to_exit_first_loop_alt generates
incorrect loop
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

This testcase fails on trunk:
...
$ cat libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt-5.c
/* { dg-do run } */
/* { dg-options "-O2 -ftree-parallelize-loops=2" } */

#include 
#include 
#include 

unsigned int
__attribute__((noclone,noinline))
f (unsigned int n, unsigned int sum)
{
  unsigned int i;

  i = UINT_MAX;
  do
{
  sum += i % 13;
  i++;
}
  while (i < n - 1);

  return sum;
}

int
main (void)
{
  unsigned int actual = f (0, 12);
  unsigned int expected = 4294967290;

  if (actual != expected)
abort ();

  return 0;
}
...

try_transform_to_exit_first_loop_alt changes the loop into this, and the loop
is never entered:
...
  i = UINT_MAX;
  while (i < n)
{
  sum += i % 13;
  i++;
}
...

[Bug c++/66653] New: ice in gen_type_die_with_usage, at dwarf2out.c:20876

[dcb314 at hotmail dot com]

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

Bug ID: 66653
   Summary: ice in gen_type_die_with_usage, at dwarf2out.c:20876
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 35844
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35844&action=edit
gzipped C++ source code

For gcc trunk dated 20150624, I get the following error:

$ ../results/bin/gcc -g -c bug213.cc
cc1plus: internal compiler error: in gen_type_die_with_usage, at
dwarf2out.c:20876
0x9d2f41 gen_type_die_with_usage
../../src/trunk/gcc/dwarf2out.c:20876
0x9d29fd gen_type_die_with_usage
../../src/trunk/gcc/dwarf2out.c:20791
0x9d3276 gen_type_die
../../src/trunk/gcc/dwarf2out.c:20887
0x9d0dc4 gen_decl_die
../../src/trunk/gcc/dwarf2out.c:21496
0x9d1a2c dwarf2out_decl
../../src/trunk/gcc/dwarf2out.c:21923
0x93a0e2 analyze_functions
../../src/trunk/gcc/cgraphunit.c:1153
0x93a520 symbol_table::finalize_compilation_unit()
../../src/trunk/gcc/cgraphunit.c:2491
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.

[Bug c++/66654] New: ice in digest_init_r, at cp/typeck2.c:1103

[dcb314 at hotmail dot com]

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

Bug ID: 66654
   Summary: ice in digest_init_r, at cp/typeck2.c:1103
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 35845
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35845&action=edit
gzipped C++ source code

For gcc trunk dated 20150624, I get

$ ../results/bin/gcc -c -std=c++11 bug214.cc
In file included from
/home/dcb/rpmbuild/BUILD/MuseScore-2.0.0/libmscore/stafftext.h:18:0,
 from
/home/dcb/rpmbuild/BUILD/MuseScore-2.0.0/libmscore/plugins.cpp:34:
/home/dcb/rpmbuild/BUILD/MuseScore-2.0.0/libmscore/staff.h:118:44: internal
compiler error: in digest_init_r, at cp/typeck2.c:1103
   QColor _color  { MScore::defaultColor };
^
0x690163 digest_init_r
../../src/trunk/gcc/cp/typeck2.c:1103
0x692e40 digest_init_flags(tree_node*, tree_node*, int)
../../src/trunk/gcc/cp/typeck2.c:1154
0x692e40 digest_nsdmi_init(tree_node*, tree_node*)
../../src/trunk/gcc/cp/typeck2.c:1170
0x70b4a2 cp_parser_late_parse_one_default_arg
../../src/trunk/gcc/cp/parser.c:24304

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  ---
BTW, is the resulting warning actually correct?

[Bug target/66655] New: [5.1 Regression] miscompilation due to ipa-ra on MinGW

[amonakov at gcc dot gnu.org]

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

Bug ID: 66655
   Summary: [5.1 Regression]  miscompilation due to ipa-ra on
MinGW
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-w64-mingw32

Created attachment 35846
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35846&action=edit
testcase

Attached is a testcase that, when compiled with a MinGW GCC 5.1, aborts on
execution.  Swapping the order of .o files in the final link, or compiling
main.cc with -O2 will produce a correct executable.

The failure is caused by interplay of -fipa-ra (enabled by default at -O2) and
MinGW's treatment of symbols that would normally be weak on ELF platforms.

When compiling c.cc, ipa-ra does not save/restore %rax around the call to
S::set (a static inline class method), apparently since the body emitted in
that translation unit does not indeed clobber %rax and is not considered
replaceable.  On Linux, S::set is weak and optimization is not performed. 
However, S::set is also emitted when compiling main.cc, and its copy in main.o
clobbers %rax since optimization is not enabled. During final link, the copy of
S::set from main.o is used, producing a broken executable.

(this issue is reduced from a miscompiled Clang produced by mingw-w64 5.1
cross-compiler)

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
This is the warning we get when "fixed":

/home/manuel/test3/src/gcc/testsuite/gfortran.dg/wunused-parameter.f90:8:0:

 SUBROUTINE sub (neq, time, y, dydt)
^
Warning: unused parameter ‘time’ [-Wunused-parameter]

There is no such warning with 4.3.1

[Bug c++/66617] C++11 {brace} initialisation of virtually inherited derived class = failure to override base virtual function, unless all base ctors have same signature

[db0451 at gmail dot com]

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

--- Comment #4 from DB  ---
Attaching verbose output and tempfiles as recommended by bug reporting guide.




$ gcc -v -save-temps -std=c++11 virtual2.cpp -o virtual2.exe
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.9.2/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --with-gxx-include-dir=/mingw64/include/c++/4.9.2
--enable-bootstrap --with-arch=x86-64 --with-tune=generic
--enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared
--enable-static --enable-libatomic --enable-threads=posix --enable-graphite
--enable-fully-dynamic-string --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-cloog-backend=isl
--enable-version-specific-runtime-libs --disable-cloog-version-check
--disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib
--enable-checking=release --disable-rpath --disable-win32-registry
--disable-nls --disable-werror --disable-symvers --with-libiconv
--with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64
--with-isl=/mingw64 --with-cloog=/mingw64 --with-pkgversion='Rev5, Built by
MSYS2 project' --with-bugurl=http://sourceforge.net/projects/msys2
--with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 4.9.2 (Rev5, Built by MSYS2 project)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-o' 'virtual2.exe'
'-mtune=generic' '-march=x86-64'
 C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/cc1plus.exe -E -quiet -v
-D_REENTRANT virtual2.cpp -mtune=generic -march=x86-64 -std=c++11
-fpch-preprocess -o virtual2.ii
ignoring nonexistent directory "/mingw64/include"
ignoring duplicate directory "C:/msys64/mingw64/x86_64-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 C:/msys64/mingw64/include/c++/4.9.2
 C:/msys64/mingw64/include/c++/4.9.2/x86_64-w64-mingw32
 C:/msys64/mingw64/include/c++/4.9.2/backward
 C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/include
 C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/../../../../include
 C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/include-fixed

C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/../../../../x86_64-w64-mingw32/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-o' 'virtual2.exe'
'-mtune=generic' '-march=x86-64'
 C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/cc1plus.exe -fpreprocessed
virtual2.ii -quiet -dumpbase virtual2.cpp -mtune=generic -march=x86-64 -auxbase
virtual2 -std=c++11 -version -o virtual2.s
GNU C++ (Rev5, Built by MSYS2 project) version 4.9.2 (x86_64-w64-mingw32)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version
3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Rev5, Built by MSYS2 project) version 4.9.2 (x86_64-w64-mingw32)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version
3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 31108f4eb997d1c5310b0f90916e0ed9
virtual2.cpp: In constructor 'Right_Bottom::Right_Bottom(int, int, int, int)':
virtual2.cpp:51:6: error: cannot allocate an object of abstract type
'Left_Bottom'
   d{d}
  ^
virtual2.cpp:20:8: note:   because the following virtual functions are pure
within 'Left_Bottom':
 struct Left_Bottom: public virtual Left_Top
^
virtual2.cpp:12:15: note:   virtual void Left_Top::pure_virtual() const
  virtual void pure_virtual() const = 0;
   ^
virtual2.cpp:51:6: error: cannot allocate an object of abstract type
'Right_Top'
   d{d}
  ^
virtual2.cpp:31:8: note:   because the following virtual functions are pure
within 'Right_Top':
 struct Right_Top: public virtual Left_Top
^
virtual2.cpp:12:15: note:   virtual void Left_Top::pure_virtual() const
  virtual void pure_virtual() const = 0;
   ^

[Bug c++/66617] C++11 {brace} initialisation of virtually inherited derived class = failure to override base virtual function, unless all base ctors have same signature

[db0451 at gmail dot com]

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

--- Comment #5 from DB  ---
Created attachment 35847
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35847&action=edit
-save-temps output files plus the triggering cpp file

see corresponding -v output added in latest comment. Please advise when this
issue has been received and reviewed. Thanks.

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> BTW, is the resulting warning actually correct?

According the gfortran manual

-Wunused-parameter
Contrary to gcc's meaning of -Wunused-parameter, gfortran's implementation of
this option does not warn about unused dummy arguments (see
-Wunused-dummy-argument), but about unused PARAMETER values. -Wunused-parameter
is implied by -Wextra if also -Wunused or -Wall is used. 

If I understand correctly the above statement, -Wunused-parameter should not
emit a warning for the test in comment 0: there is no parameter. The warning
should be issued with -Wunused-dummy-argument

pr66605.f90:5:25:

 SUBROUTINE sub (neq, time, y, dydt)
 1
Warning: Unused dummy argument 'time' at (1) [-Wunused-dummy-argument]

[Bug c++/66656] New: static constexpr array member: cannot get size via constexpr function

[g5834847 at trbvm dot com]

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

Bug ID: 66656
   Summary: static constexpr array member: cannot get size via
constexpr function
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g5834847 at trbvm dot com
  Target Milestone: ---



#include 

template 
constexpr size_t array_size(const T (&)[N])
{
  return N;
}

class X {
public:
  struct item {
char const* const name;
int   price;
  };

  static const item arr0[2];
  static constexpr item arr1[3] = {{"asdf", 0}, {"qwer", 1}, {"zxcv", 2}};

  static size_t constexpr size0() {
return array_size(arr0);// perfect
  }

  static size_t constexpr size1() {
return array_size(arr1);// problem!!
  }

};

const X::item X::arr0[] = {{"asdf", 0}, {"qwer", 1}};

int main()
{
  X x;
  std::cout << x.size0() << std::endl; // perfect
  std::cout << x.size1() << std::endl; // ERROR IN THIS LINE (cannot link!??)
  return 0;
}




$ c++ -std=c++14 -o go go.cpp

/tmp/ccPGS4ZN.o: In function `X::size1()':
go.cpp:(.text._ZN1X5size1Ev[_ZN1X5size1Ev]+0x5): undefined reference to
`X::arr1'
collect2: error: ld returned 1 exit status

[Bug c++/51911] [C++11] G++ accepts new auto { list }

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-06-24
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
Mine.

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
Another alternative is to add support for printing %D to gfc_format_decoder, it
is a matter of adding something like:

case 'D':
if (DECL_NAME (t))
{
  pp_string (pp, lang_hooks.decl_printable_name (t, 2));
  return true;
}

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez  ---
(In reply to Dominique d'Humieres from comment #5)
> If I understand correctly the above statement, -Wunused-parameter should not
> emit a warning for the test in comment 0: there is no parameter. The warning
> should be issued with -Wunused-dummy-argument

If so, then the ICE was not caused by my diagnostic changes, it just exposes a
problem that has been latent or introduced later. Thus, I'm not planning to
investigate further.

If it is possible to generate a valid warning that triggers the same ICE, then
we should consider one of the options I have proposed above. From your
explanation above, it seems likely that Fortran doesn't ever want to get the
middle-end warning (which makes me wonder why this warning is given in the
middle-end to begin with!). Thus another (ugly?) fix may be to disable the
warning (all warnings?) completely around calls to finalize_function.

[Bug c++/66654] [6 Regression] ice in digest_init_r, at cp/typeck2.c:1103

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-24
 CC||trippels at gcc dot gnu.org
Summary|ice in digest_init_r, at|[6 Regression] ice in
   |cp/typeck2.c:1103   |digest_init_r, at
   ||cp/typeck2.c:1103
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
class A {
  A();
};
class B {
  A r{r};
};

[Bug c++/66654] [6 Regression] ice in digest_init_r, at cp/typeck2.c:1103

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0

--- Comment #2 from Marek Polacek  ---
Started with r224289.

[Bug c++/66653] [6 Regression] ice in gen_type_die_with_usage, at dwarf2out.c:20876

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org
Summary|ice in  |[6 Regression] ice in
   |gen_type_die_with_usage, at |gen_type_die_with_usage, at
   |dwarf2out.c:20876   |dwarf2out.c:20876

--- Comment #1 from Markus Trippelsdorf  ---
template  class A
{
  static __thread T a;
};

[Bug c++/66653] [6 Regression] ice in gen_type_die_with_usage, at dwarf2out.c:20876

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-24
 Ever confirmed|0   |1

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> If so, then the ICE was not caused by my diagnostic changes, it just exposes a
> problem that has been latent or introduced later. Thus, I'm not planning to
> investigate further.

Well, I think that is caused by your diagnostic changes, but is due to a
conflicting definition of -Wunused-parameter in C* and gfortran which now share
the same code (?).

I am not sure if it is too late or not to change the name of the option in one
of the front end. If it is too late, is it possible for the fortran FE to
rename internally the option before passing it to the ME?

[Bug rtl-optimization/66412] [5/6 Regression] ICE on valid code at -O2 and -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5748

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org

--- Comment #8 from Segher Boessenkool  ---
Okay, looking.

[Bug c++/66653] [6 Regression] ice in gen_type_die_with_usage, at dwarf2out.c:20876

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0

--- Comment #2 from Marek Polacek  ---
Started with r224161.

[Bug fortran/66643] Missing compilation error for formatted data transfer without format

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #3 from Jerry DeLisle  ---
I will take this one.  It seems we could detect this as a useful diagnostic.

[Bug c++/66647] [5/6 regression] ICE: in instantiate_class_template_1, at cp/pt.c:9254

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/66647] [5/6 regression] ICE: in instantiate_class_template_1, at cp/pt.c:9254

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed Jun 24 19:59:28 2015
New Revision: 224917

URL: https://gcc.gnu.org/viewcvs?rev=224917&root=gcc&view=rev
Log:
PR c++/66647
* pt.c (dependent_type_p_r): Check for dependent alias template
specialization sooner.

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

[Bug c++/66542] [4.9/5/6 Regression] [C++11] Can create static variable of type that has deleted destructor

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed for GCC 6; I tend not to backport fixes for invalid code bugs.

[Bug c++/66501] [4.9/5/6 Regression] Default move assignment does not move array members

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/65879] [4.9/5/6 Regression] Bogus linkage errors for member class of anonymous class

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/66644] Rejects C++11 in-class anonymous union members initialization

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler  ---
The problem also exists in the current HEAD (Tested for gcc HEAD 6.0.0 20150623
(experimental))

[Bug c++/66647] [5/6 regression] ICE: in instantiate_class_template_1, at cp/pt.c:9254

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Jun 24 20:23:53 2015
New Revision: 224921

URL: https://gcc.gnu.org/viewcvs?rev=224921&root=gcc&view=rev
Log:
PR c++/66647
* pt.c (dependent_type_p_r): Check for dependent alias template
specialization sooner.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/alias-decl-49.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/pt.c

[Bug c++/65919] [5/6 Regression] GCC 5.1 with options "-g -std=c++14" fails to compile multiple lambdas used as default function parameters

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Jun 24 20:24:01 2015
New Revision: 224922

URL: https://gcc.gnu.org/viewcvs?rev=224922&root=gcc&view=rev
Log:
PR c++/65919
* mangle.c (mangle_decl): Always SET_IDENTIFIER_GLOBAL_VALUE.
(decl_implicit_alias_p): Split out from maybe_remove_implicit_alias.
* cp-tree.h (DECL_REALLY_EXTERN): Handle null DECL_LANG_SPECIFIC.

Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/cp-tree.h
branches/gcc-5-branch/gcc/cp/mangle.c
branches/gcc-5-branch/gcc/testsuite/g++.dg/abi/mangle58.C

[Bug c++/66656] static constexpr array member: cannot get size via constexpr function

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Krügler  ---
The compiler/linker is right: You still need to provide a definition for the
second static data member. Providing an initializer does not provide such a
definition. To fix your problem, just add the line

constexpr X::item X::arr1[];

to your code.

This is not a defect.

[Bug c++/65919] [5/6 Regression] GCC 5.1 with options "-g -std=c++14" fails to compile multiple lambdas used as default function parameters

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed on the trunk by one of the patches for bug 44282; I've backported the
relevant section.

[Bug c++/66647] [5/6 regression] ICE: in instantiate_class_template_1, at cp/pt.c:9254

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/66654] [6 Regression] ice in digest_init_r, at cp/typeck2.c:1103

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug driver/66657] New: Feature request - assembly output from lto compiler

[kalmquist1 at hotmail dot com]

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

Bug ID: 66657
   Summary: Feature request - assembly output from lto compiler
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kalmquist1 at hotmail dot com
  Target Milestone: ---

There should be a gcc command line option to generate the assembly language
output of the lto compiler.  The -S option doesn't do this because it prevents
the lto compilation phase from running at all.

Currently, the only way to accomplish this is to run the lto compiler directly,
as in the following example:

  ld -r -plugin /usr/lib/gcc/x86_64-linux-gnu/4.8/liblto_plugin.so \
 -plugin-opt=/bin/true -plugin-opt=-fresolution=out.res in1.o in2.o
  /usr/lib/gcc/x86_64-linux-gnu/4.8/lto1 -quiet \
 -fresolution=out.res -o out.s -O2 in1.o in2.o

This is ugly and undocumented.

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[manu at gcc dot gnu.org]

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

--- Comment #9 from Manuel López-Ibáñez  ---
(In reply to Dominique d'Humieres from comment #8)
> > If so, then the ICE was not caused by my diagnostic changes, it just 
> > exposes a
> > problem that has been latent or introduced later. Thus, I'm not planning to
> > investigate further.
> 
> Well, I think that is caused by your diagnostic changes, but is due to a
> conflicting definition of -Wunused-parameter in C* and gfortran which now
> share the same code (?).

It could be when we changed Fortran options to use the common options
machinery. But that sounds strange anyway, because -Wunused-parameter would
have enabled the middle-end warning in any case. I cannot find any code that
disabled the warning before my changes. In fact, this same testcase in GCC
4.5.1 (way before my changes!) had the middle-end option enabled but it didn't
give any warning.

> I am not sure if it is too late or not to change the name of the option in
> one of the front end. If it is too late, is it possible for the fortran FE
> to rename internally the option before passing it to the ME?

It could simply set:

{
 int tmp_warn_unused_parameter = warn_unused_parameter;
 warn_unused_parameter = 0
 cgraph_node::finalize_function (fndecl, true);
 warn_unused_parameter= tmp_warn_unused_parameter;
}

But it seems quite ugly to me. It would be better to understand why the
middle-end thinks it is unused (perhaps Fortran needs to mark it as used or
mark it with TREE_NO_WARNING?).

In fact, the exact same code in GCC 4.5.1 has TREE_NO_WARNING set in the
PARAM_DECL corresponding to time, but I'm not sure where it is set.

The middle-end warning also shows that the location given by Fortran to the
PARAM_DECL is very poor.

I still think this is a latent bug in the way that Fortran is generating the
PARAM_DECL for time, but if the Fortran maintainers are not interested in
investigating that, then I could prepare a patch with any of the work-arounds I
have proposed above as soon as a Fortran maintainer (someone that will approve
the patch) chooses one.

[Bug driver/66657] Feature request - assembly output from lto compiler

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>There should be a gcc command line option to generate the assembly language 
>output of the lto compiler. 

Use -save-temps.

[Bug driver/66657] Feature request - assembly output from lto compiler

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
What are you trying to do with the assembly after the fact?

[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Manuel López-Ibáñez from comment #9)
> I still think this is a latent bug in the way that Fortran is generating the
> PARAM_DECL for time, but if the Fortran maintainers are not interested in
> investigating that, then I could prepare a patch with any of the
> work-arounds I have proposed above as soon as a Fortran maintainer (someone
> that will approve the patch) chooses one.

Scratch that. Since the goal is to bluntly silence the warning, then the only
work-around I see is the one proposed in the previous comment. 

(It would be interesting to know at which GCC version or revision the warning
started appearing).

[Bug other/58133] GCC should emit arm assembly following the unified syntax

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #4 from Ramana Radhakrishnan  ---
Thumb1 Fixed for 5.0 with Terry's work - see release notes 
https://gcc.gnu.org/gcc-5/changes.html


ARM state is a bit more involved.

[Bug other/58133] GCC should emit arm assembly following the unified syntax

[ramana at gcc dot gnu.org]

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

--- Comment #5 from Ramana Radhakrishnan  ---
Oh and Kyrylo fixed up vfp.md last year too. So it's only ARM state that
remains. I have a few patches in flight that I'm testing.

[Bug c/66658] New: missing -Wunused-value negating a function result in a comma expression

[msebor at gcc dot gnu.org]

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

Bug ID: 66658
   Summary: missing -Wunused-value negating a function result in a
comma expression
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wunused-value warning is documented to:
Warn whenever a statement computes a result that is explicitly not used.

There are two minor issues here:

1) The following test case shows that GCC misses the opportunity to diagnose
the NOT expression in the first operand of the comma expression:

$ cat /build/tmp/u.c && ~/bin/gcc-5.1.0/bin/g++ -Wunused-value -c -o/dev/null
/build/tmp/u.c
int foo (int, int = 0);

int bar (int a)
{
if (a && !foo (0), 1)
return 1;

return 0;
}

Clang diagnoses this code as one would expect.

The example isn't C++ specific but with default arguments it's easy to
accidentally write "... !foo (0), 1)" when "... foo (0, 1))" is intended.
Having GCC issue a warning will help find these types of mistakes.

2) The documentation is subtly incorrect in that it uses the term "statement"
when what it actually means "expression."  If it really meant statement then
expressions such as initializers of function default arguments such as in the
example below would be excluded (when they are not):

int a;
int foo (int, int = 0);
int bar (int, int = (a && !foo (0), 1));

[Bug middle-end/65358] wrong parameter passing code with tail call optimization on arm

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #27 from Ramana Radhakrishnan  ---
Fixed for 6.0

[Bug rtl-optimization/64172] [4.9 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||ra
  Component|target  |rtl-optimization

--- Comment #17 from Ramana Radhakrishnan  ---
Really an rtl-optimization bug - Vlad are you considering a 4.9 backport given
this is a P2 ?

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #4 from Ramana Radhakrishnan  ---
Need to apply Aurelien's patch - looks like that's slipped through the cracks.

[Bug c/48956] -Wconversion should warn when a complex value is assigned to a real result

[matt at bitbashing dot io]

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

Matt Kline  changed:

   What|Removed |Added

 CC||matt at bitbashing dot io

--- Comment #15 from Matt Kline  ---
> Fixed for GCC 6.

May I ask why this is being deferred until GCC 6.x? I'll readily admit that I'm
not well-versed in the GCC release cycle, but this seems like a trivial
enhancement and would be useful immediately. My team has been bitten by these
silent conversions, and -Wconversion on Clang currently provides a similar
warning.

[Bug c/48956] -Wconversion should warn when a complex value is assigned to a real result

[manu at gcc dot gnu.org]

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

--- Comment #16 from Manuel López-Ibáñez  ---
(In reply to Matt Kline from comment #15)
> > Fixed for GCC 6.
> 
> May I ask why this is being deferred until GCC 6.x? I'll readily admit that
> I'm not well-versed in the GCC release cycle, but this seems like a trivial
> enhancement and would be useful immediately. My team has been bitten by
> these silent conversions, and -Wconversion on Clang currently provides a
> similar warning.

GCC 6 is the next development release, which will be released early next year.
GCC 5 is the current stable release and, normally, only bugfixes are added to
it. If you wish to propose a backport, you'll need to write to the release
managers (for example, by writing to gcc@) and ask for permission, then you
need to do (or find someone to do) the backport, test it and commit it.

I'd rather have two new features in GCC 6 than one new feature in both GCC 5
and GCC 6, thus I (and likely others) prefer to dedicate my time to fixing
other things (and there is a lot of work to do:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps)
rather than on back-porting new features.

[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu

[kkojima at gcc dot gnu.org]

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

--- Comment #34 from Kazumoto Kojima  ---
Author: kkojima
Date: Wed Jun 24 22:11:04 2015
New Revision: 224925

URL: https://gcc.gnu.org/viewcvs?rev=224925&root=gcc&view=rev
Log:
PR target/66563
* [SH] Add a new operand to GOTaddr2picreg so to avoid CSE.  Modify caller
  of gen_GOTaddr2picreg.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.md

[Bug c/48956] -Wconversion should warn when a complex value is assigned to a real result

[matt at bitbashing dot io]

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

--- Comment #17 from Matt Kline  ---
Thanks for the info and such a quick response! I'll see if I can do the
required legwork.

[Bug fortran/66528] [6 Regression] unbalanced IF/ENDIF with -fmax-errors=1 causes invalid free

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
Author: manu
Date: Wed Jun 24 22:16:42 2015
New Revision: 224926

URL: https://gcc.gnu.org/viewcvs?rev=224926&root=gcc&view=rev
Log:
The problem is that diagnostic_action_after_output tries to delete the active
pretty-printer which tries to delete its output_buffer, which is normally
dynamically allocated via placement-new, but the output_buffer used by the
error_buffer of Fortran is statically allocated. Being statically allocated
simplifies a lot pushing/poping several instances of error_buffer.

The solution is to reset the active output_buffer back to the default one
before calling diagnostic_action_after_output. This is a bit ugly, because this
function does use the output_buffer, however, at the point that Fortran calls
it, both are in an equivalent state, thus there is no visible difference.

gcc/testsuite/ChangeLog:

2015-06-24  Manuel López-Ibáñez  

PR fortran/66528
* gfortran.dg/maxerrors.f90: New test.

gcc/fortran/ChangeLog:

2015-06-24  Manuel López-Ibáñez  

PR fortran/66528
* error.c (gfc_warning_check): Restore the default output_buffer
before calling diagnostic_action_after_output.
(gfc_error_check): Likewise.
(gfc_diagnostics_init): Add comment.

Added:
trunk/gcc/testsuite/gfortran.dg/maxerrors.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/error.c
trunk/gcc/testsuite/ChangeLog