[Bug c++/68203] Аbout infinite compilation time on struct with nested array of pairs with -std=c++11

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||memory-hog

--- Comment #1 from Andrew Pinski  ---
This is most likely a memory hog which is generating lots of default
constructors rather than a loop over them.

[Bug rtl-optimization/67753] [6 Regression] FAIL: cxg1005, cxg2002, cxg2006, cxg2007, cxg2008, cxg2018, cxg2019 and cxg2020

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-04
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Alexandre Oliva  ---
Created attachment 36645
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36645&action=edit
Here's a patch I'm testing to fix this problem

The problem is that the copy of args in PARALLELs from entry_parm to stack_parm
is deferred to the parm conversion insn seq, but the copy from stack_parm to
target_reg was inserted in the normal copy seq, that is executed before the
conversion insn seq.  Oops.

I seem to have managed to do away with the need for the stack_parm, which would
have avoided the need for emitting the copy to target_reg in the conversion
seq, but at least on pa, due to the need for stack to copy between SI and SF
modes, it seems like using the reserved stack slot is beneficial, so I put in
logic to use a pre-reserved stack slot and emit the copy to target_reg in the
conversion seq if needed.

[Bug tree-optimization/21643] GCC fails to merge ranges in comparison.

[rivasgilbie121 at gmail dot com]

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

Gilbie Rivas  changed:

   What|Removed |Added

 CC||rivasgilbie121 at gmail dot com

--- Comment #8 from Gilbie Rivas  ---
Lovely article - one of the best things I've recently read, and by far the most
useful. That helped me a lot. I would like to share with you a great service to
merge some files online. BTW, there is an online service through which you can
merge any PDF files, the link is here http://www.altomerge.com/";
>altomerge.com.

[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||i.am.inuyasha at gmail dot com

--- Comment #8 from Markus Trippelsdorf  ---
*** Bug 68207 has been marked as a duplicate of this bug. ***

[Bug c++/68207] internal compiler error: in reshape_init_class, at cp/decl.c:5469 caused by nested struct initialization

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
dup.

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

[Bug libstdc++/68190] [5/6 Regression] iterator mix up with set::find and heterogenous lookup

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Howard's suggestion is approved if someone tests it, I only have my phone and
no machine I can build or test on.

[Bug c++/68207] New: internal compiler error: in reshape_init_class, at cp/decl.c:5469 caused by nested struct initialization

[i.am.inuyasha at gmail dot com]

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

Bug ID: 68207
   Summary: internal compiler error: in reshape_init_class, at
cp/decl.c:5469 caused by nested struct initialization
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i.am.inuyasha at gmail dot com
  Target Milestone: ---

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

$ cat test.cpp 
typedef struct {
int x, y, z;
} Vertex;

typedef struct {
int cmd;
struct {
Vertex pos;
};
} Command;

int main(int argc, char **argv) {
Command c = {
.cmd = 0,
};

c = {
.cmd = 1,
.pos = {.x=-2, .y=0, .z=-6},
};
return 0;
}

$ gcc -v -save-temps test.cpp -o gcctest && ./gcctest
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-5.2.0/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release --with-default-libstdcxx-abi=gcc4-compatible
Thread model: posix
gcc version 5.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'gcctest' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -mtune=generic -march=x86-64 -fpch-preprocess -o test.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0

/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0/x86_64-unknown-linux-gnu

/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0/backward
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'gcctest' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1plus -fpreprocessed test.ii
-quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -version
-o test.s
GNU C++ (GCC) version 5.2.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version
3.1.3-p4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 5.2.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version
3.1.3-p4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9ed1d81099b98de89457560501a9ea0c
test.cpp: In function ‘int main(int, char**)’:
test.cpp:20:2: warning: extended initializer lists only available with
-std=c++11 or -std=gnu++11
  };
  ^
test.cpp:17:4: warning: extended initializer lists only available with
-std=c++11 or -std=gnu++11
  c = {
^
test.cpp:17:4: internal compiler error: in reshape_init_class, at
cp/decl.c:5469
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Happening on Arch AMD64 with latest version from repo. Using --std=c++11
suppresses the warnings but doesn't prevent the internal error.

[Bug preprocessor/68206] New: ICE: unimplemented: unexpected AST of kind loop_expr in potential_constant_expression_1

[chrisb2244 at gmail dot com]

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

Bug ID: 68206
   Summary: ICE: unimplemented: unexpected AST of kind loop_expr
in potential_constant_expression_1
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrisb2244 at gmail dot com
  Target Milestone: ---

Code below hits ICE.

///
#include 
#include 

template
class A
{
using Arr = std::array;
public:
constexpr A() = default;

constexpr void displayArr() {
for (uint n=0; n a;
a.displayArr(); // If this isn't called - no problems
return 0;
}
///

Error:

loopFail.cpp: In instantiation of 'constexpr const Arr A::arr_':
loopFail.cpp:13:30:   required from 'constexpr void A::displayArr() const
[with T = double; unsigned int N = 5u]'
loopFail.cpp:31:18:   required from here
loopFail.cpp:26:40: error: 'static constexpr A::Arr A::makeArr()
[with T = double; unsigned int N = 5u; A::Arr = std::array]'
called in a constant expression
 static constexpr Arr arr_ = makeArr();
^
loopFail.cpp:18:26: note: 'static constexpr A::Arr A::makeArr()
[with T = double; unsigned int N = 5u; A::Arr = std::array]'
is not usable as a constexpr function because:
 static constexpr Arr makeArr() {
  ^
loopFail.cpp:18:26: sorry, unimplemented: unexpected AST of kind loop_expr
loopFail.cpp:18:26: internal compiler error: in
potential_constant_expression_1, at cp/constexpr.c:4639
0x8064db potential_constant_expression_1
../../gcc-svn-sources/gcc/cp/constexpr.c:4639
0x805d0d potential_constant_expression_1
../../gcc-svn-sources/gcc/cp/constexpr.c:4257
0x805d0d potential_constant_expression_1
../../gcc-svn-sources/gcc/cp/constexpr.c:4257
0x805d0d potential_constant_expression_1
../../gcc-svn-sources/gcc/cp/constexpr.c:4257
0x7fd453 require_potential_rvalue_constant_expression(tree_node*)
../../gcc-svn-sources/gcc/cp/constexpr.c:4680
0x7fd453 explain_invalid_constexpr_fn(tree_node*)
../../gcc-svn-sources/gcc/cp/constexpr.c:842
0x7fdbc1 cxx_eval_call_expression
../../gcc-svn-sources/gcc/cp/constexpr.c:1258
0x7ffa11 cxx_eval_constant_expression
../../gcc-svn-sources/gcc/cp/constexpr.c:3207
0x805211 cxx_eval_outermost_constant_expr
../../gcc-svn-sources/gcc/cp/constexpr.c:3746
0x686fbe store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc-svn-sources/gcc/cp/typeck2.c:823
0x5ed78f check_initializer
../../gcc-svn-sources/gcc/cp/decl.c:6111
0x60cdb4 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc-svn-sources/gcc/cp/decl.c:6739
0x642270 instantiate_decl(tree_node*, int, bool)
../../gcc-svn-sources/gcc/cp/pt.c:21459
0x6c0a22 mark_used(tree_node*, int)
../../gcc-svn-sources/gcc/cp/decl2.c:5152
0x64d7bb tsubst_copy
../../gcc-svn-sources/gcc/cp/pt.c:13889
0x659ce2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-svn-sources/gcc/cp/pt.c:16692
0x65b6e8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-svn-sources/gcc/cp/pt.c:15910
0x65a1b7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-svn-sources/gcc/cp/pt.c:15879
0x6462e0 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-svn-sources/gcc/cp/pt.c:15498
0x644a26 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-svn-sources/gcc/cp/pt.c:14875


I'm not certain the code is valid, but even in the case it isn't - shouldn't I
just be told what is wrong with it? 
In particular, the error line:

makeArr() [ with T = ... ] is not usable as a constexpr function because:
static constexpr Arr makeArr() {
 ^

doesn't tell me much.

[Bug rtl-optimization/68205] New: ICE compiling gcc.c-torture/execute/20040709-2.c with -fno-common on arm-none-eabi

[sandra at gcc dot gnu.org]

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

Bug ID: 68205
   Summary: ICE compiling gcc.c-torture/execute/20040709-2.c with
-fno-common on arm-none-eabi
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi
 Build: i686-pc-linux-gnu

I am seeing this failure on the GCC 5 branch, built for arm-none-eabi:

$ arm-none-eabi-gcc -S
/scratch/sandra/arm-altera-stable/src/gcc-5-2015.11/gcc/testsuite/gcc.c-torture/execute/20040709-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never-O2  -w -fno-common
-fdump-rtl-all
/scratch/sandra/arm-altera-stable/src/gcc-5-2015.11/gcc/testsuite/gcc.c-torture/execute/20040709-2.c:
In function 'testW':
/scratch/sandra/arm-altera-stable/src/gcc-5-2015.11/gcc/testsuite/gcc.c-torture/execute/20040709-2.c:114:72:
error: insn does not satisfy its constraints:
/scratch/sandra/arm-altera-stable/src/gcc-5-2015.11/gcc/testsuite/gcc.c-torture/execute/20040709-2.c:54:10:
note: in definition of macro 'T'
(insn 389 374 387 7 (parallel [
(set (reg:SI 2 r2 [323])
(truncate:SI (lshiftrt:DI (mult:DI (sign_extend:DI (reg:SI 9 r9
[orig:321 D.8956 ] [321]))
(sign_extend:DI (reg:SI 6 r6 [324])))
(const_int 32 [0x20]
(clobber (scratch:SI))
])
/scratch/sandra/arm-altera-stable/src/gcc-5-2015.11/gcc/testsuite/gcc.c-torture/execute/20040709-2.c:114
57 {*smulsi3_highpart_nov6}
 (nil))
/scratch/sandra/arm-altera-stable/src/gcc-5-2015.11/gcc/testsuite/gcc.c-torture/execute/20040709-2.c:114:72:
internal compiler error: in extract_constrain_insn, at recog.c:2246
/scratch/sandra/arm-altera-stable/src/gcc-5-2015.11/gcc/testsuite/gcc.c-torture/execute/20040709-2.c:54:10:
note: in definition of macro 'T'
0x85431b7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/scratch/sandra/arm-eabi-5/src/gcc-5/gcc/rtl-error.c:110
0x85431f5 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/scratch/sandra/arm-eabi-5/src/gcc-5/gcc/rtl-error.c:121
0x8519445 extract_constrain_insn(rtx_insn*)
/scratch/sandra/arm-eabi-5/src/gcc-5/gcc/recog.c:2246
0x84fb55f reload_cse_simplify_operands
/scratch/sandra/arm-eabi-5/src/gcc-5/gcc/postreload.c:430
0x84fdf12 reload_cse_simplify
/scratch/sandra/arm-eabi-5/src/gcc-5/gcc/postreload.c:207
0x84fdf12 reload_cse_regs_1
/scratch/sandra/arm-eabi-5/src/gcc-5/gcc/postreload.c:246
0x84fe122 reload_cse_regs
/scratch/sandra/arm-eabi-5/src/gcc-5/gcc/postreload.c:94
0x84fe122 execute
/scratch/sandra/arm-eabi-5/src/gcc-5/gcc/postreload.c:2387
0x84fe122 execute
/scratch/sandra/arm-eabi-5/src/gcc-5/gcc/postreload.c:2381
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Same test case with same options compiles successfully on GCC 4.9 branch.

On mainline the test also compiles successfully.  I tracked down that it was
"fixed" by r224048, but that patch looks unrelated (I think it just changed the
input to reload by making different optimization decisions) so perhaps the bug
is still latent?

[Bug c++/68204] g++ fails to expand a template parameter pack in with variable templates in a function

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Krügler  ---
Seems to be fixed in gcc HEAD 6.0.0 20151102 (experimental)

[Bug c++/68202] Missed diagnostic: rvalue reference allowed in exception-specifier

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Krügler  ---
I agree, according to [except.spec] p2:

"A type denoted in a dynamic-exception-specification shall not denote an [..]
rvalue reference type."

[Bug c++/68170] Declaring friend template class template in C++1z produces error: specialization of ‘template class A’ must appear at namespace

[mohammad.nabil.h at gmail dot com]

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

--- Comment #1 from Mohammad Alaggan  ---
In gcc-6-20151101, the attached example compiles correctly. However, the same
problem manifests in this example: 

// { dg-do compile }
// { dg-options "-std=c++1z" }

template
concept bool C() { return __is_class(T); }

template< typename T >
class A
{
};

template
class A
{
template< typename X >
friend class A;
};

template<>
class A< int >
{
template< typename X >
friend class A;
};

[Bug libobjc/24775] libobjc should not include GCC's target headers

[tbsaunde at gcc dot gnu.org]

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

--- Comment #7 from tbsaunde at gcc dot gnu.org ---
Author: tbsaunde
Date: Tue Nov  3 22:43:22 2015
New Revision: 229727

URL: https://gcc.gnu.org/viewcvs?rev=229727&root=gcc&view=rev
Log:
remove usage of ROUND_TYPE_SIZE from encoding.c

gcc got rid of this target macro in 2003, so it seems safe to assume the
alternate path works fine on all targets.

libobjc/ChangeLog:

2015-11-03  Trevor Saunders  

PR libobjc/24775
* encoding.c (objc_layout_finish_structure): Remove usage of
ROUND_TYPE_SIZE.

Modified:
trunk/libobjc/ChangeLog
trunk/libobjc/encoding.c

[Bug c++/68204] New: g++ fails to expand a template parameter pack in with variable templates in a function

[morwenn29 at hotmail dot fr]

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

Bug ID: 68204
   Summary: g++ fails to expand a template parameter pack in with
variable templates in a function
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: morwenn29 at hotmail dot fr
  Target Milestone: ---

To be honest, the title fails to accurately describe the problem. Anyway, this
sample does the job nicely:

template
void eat(TT...) {}

template
int some_value;

template
void baz()
{
eat(some_value...);
}

When trying to compile the previous code, g++ emits the following error:

main.cpp: In function 'void baz()':
main.cpp:10:23: error: expansion pattern 'some_value' contains no
argument packs
 eat(some_value...);
   ^

If I'm not mistaken, it should be equivalent to eat(some_value,
some_value, some_value) for some types T, U and V and thus feed a bunch
of integers to eat.

[Bug c++/68203] New: Аbout infinite compilation time on struct with nested array of pairs with -std=c++11

[mirzayanovmr at gmail dot com]

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

Bug ID: 68203
   Summary: Аbout infinite compilation time on struct with nested
array of pairs with -std=c++11
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mirzayanovmr at gmail dot com
  Target Milestone: ---

Tried on g++.EXE (tdm-1) 5.1.0 and g++ (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)

Compile the following minimal source code with command line 'g++ -std=c++11
t.cpp'

#include 
using namespace std;
struct A {
pair values[200];
};
int main() {
  A x;
  return 0;
}

Compilation hangs for a very long time.

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

[EngyCZ at gmail dot com]

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

--- Comment #9 from Jiří Engelthaler  ---
(In reply to Manuel López-Ibáñez from comment #8)
> 
> Good catch! In principle your patch seems correct. I think you are only
> missing a testcase. This patch is small enough to not require a copyright
> assignment:
> 
> https://gcc.gnu.org/wiki/GettingStarted#Basics:
> _Contributing_to_GCC_in_10_easy_steps

Hi.
I'm not able to create a test case because first xgcc parameters are controlled
by GCC testsuite itself.

[Bug fortran/54224] Warn for unused internal procedures

[dominiq at lps dot ens.fr]

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

--- Comment #29 from Dominique d'Humieres  ---
I have tried the following patch

--- ../_clean/gcc/fortran/trans-decl.c  2015-10-29 18:20:14.0 +0100
+++ gcc/fortran/trans-decl.c2015-11-03 19:39:39.0 +0100
@@ -285,7 +285,11 @@ gfc_build_label_decl (tree label_id)
 void
 gfc_set_decl_location (tree decl, locus * loc)
 {
-  DECL_SOURCE_LOCATION (decl) = loc->lb->location;
+  unsigned int offset = loc->nextc - loc->lb->line;
+  DECL_SOURCE_LOCATION (decl) = linemap_position_for_loc_and_offset
(line_table,
+   
loc->lb->location,
+offset);
+  /* DECL_SOURCE_LOCATION (decl) = loc->lb->location; */
 }


but it does not fix the issue and makes
gfortran.dg/array_constructor_type_14.f03 and
gfortran.dg/realloc_on_assign_18.f90 regress

/opt/gcc/work/gcc/testsuite/gfortran.dg/array_constructor_type_14.f03:7:0:

 PROGRAM test
1
internal compiler error: in linemap_position_for_loc_and_offset, at
libcpp/line-map.c:714

so I give up. I am planning to submit the following patch, open a new PR for
the bad locus, then close this PR as fixed.

--- ../_clean/gcc/testsuite/gfortran.dg/warn_unused_function_2.f90 
2014-03-26 17:49:50.0 +0100
+++ gcc/testsuite/gfortran.dg/warn_unused_function_2.f902015-11-03
12:47:30.0 +0100
@@ -2,6 +2,7 @@
 ! { dg-options "-Wall" }
 !
 ! [4.8 Regression] PR 54997: -Wunused-function gives false warnings
+! PR 54224: missing warnings with -Wunused-function
 !
 ! Contributed by Janus Weil 

@@ -14,6 +15,9 @@ contains

   subroutine s1! { dg-warning "defined but not used" }
 call s2(s3)
+contains
+  subroutine s4! { dg-warning "defined but not used" }
+  end subroutine
   end subroutine

   subroutine s2(dummy) ! { dg-warning "Unused dummy argument" }
@@ -30,5 +34,10 @@ subroutine sub
 entry en
 end subroutine

+program test
+contains
+  subroutine s5! { dg-warning "defined but not used" }
+  end subroutine
+end

 ! { dg-final { cleanup-modules "m" } }

[Bug c++/68202] New: Missed diagnostic: rvalue reference allowed in exception-specifier

[andrey.vul at gmail dot com]

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

Bug ID: 68202
   Summary: Missed diagnostic: rvalue reference allowed in
exception-specifier
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.vul at gmail dot com
  Target Milestone: ---

Given the example

// begin a.cpp
template  void f(T...) throw (T&&...) { }
int main() {
f(1, "ab");
}
// end a.cpp

and gcc -v:
Using built-in specs.
COLLECT_GCC=g++-6.0.0-alpha20151101
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20151101/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-6.0.0_alpha20151101/work/gcc-6-20151101/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/6.0.0-alpha20151101
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20151101/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/6.0.0-alpha20151101
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/6.0.0-alpha20151101/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/6.0.0-alpha20151101/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0-alpha20151101/include/g++-v6
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/6.0.0-alpha20151101/python
--enable-languages=c,c++,go,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 6.0.0_alpha20151101' --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj
--enable-libgomp --disable-libmudflap --disable-libssp --enable-libcilkrts
--enable-lto --with-isl --disable-isl-version-check --enable-libsanitizer
--disable-default-pie --enable-default-ssp
Thread model: posix
gcc version 6.0.0-alpha20151101 20151101 (experimental) (Gentoo
6.0.0_alpha20151101) 

a diagnostic is not emitted regarding rvalue reference in exception-specifier,
unlike Clang 3.6+.

[Bug c/67882] surprising offsetof result on an invalid array member without diagnostic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed by r229717.

[Bug c/67882] surprising offsetof result on an invalid array member without diagnostic

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Tue Nov  3 18:53:19 2015
New Revision: 229717

URL: https://gcc.gnu.org/viewcvs?rev=229717&root=gcc&view=rev
Log:
PR c++-common/67882

* c-family/c-common.h (fold_offsetof_1): Add argument.
* c-family/c-common.c (fold_offsetof_1): Diagnose more invalid
offsetof expressions that reference elements past the end of
an array.

* c-c++-common/builtin-offsetof-2.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/builtin-offsetof-2.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/testsuite/ChangeLog

[Bug c/68162] [5/6 Regression] Incompatible pointer type using a typedef

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-03
   Target Milestone|--- |5.3
Summary|Incompatible pointer type   |[5/6 Regression]
   |using a typedef |Incompatible pointer type
   ||using a typedef
 Ever confirmed|0   |1

--- Comment #1 from Joseph S. Myers  ---
Regression in GCC 5 (maybe exposed by the discarded-array-qualifiers changes;
the underlying issue in the code is older).  Testing a patch.

[Bug fortran/67982] Incorrect -Wunused-function warning

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #9 from Dominique d'Humieres  ---
> Committing a valid test case for something that has been fixed
> by something unknown falls under the "obviously correct" category,
> so it can be done without a review.  Just drop a mail to fortran@
> and gcc-patches@ after committing with the details.

Done. Closing.

[Bug fortran/67982] Incorrect -Wunused-function warning

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #8 from Joost VandeVondele  
---
(In reply to dominiq from comment #7)
> Author: dominiq
> Date: Tue Nov  3 18:03:38 2015
> New Revision: 229716


thanks... just doing this myself :-)

[Bug fortran/67982] Incorrect -Wunused-function warning

[dominiq at gcc dot gnu.org]

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

--- Comment #7 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Tue Nov  3 18:03:38 2015
New Revision: 229716

URL: https://gcc.gnu.org/viewcvs?rev=229716&root=gcc&view=rev
Log:
2015-11-03  Dominique d'Humieres 

PR fortran/67982
* gfortran.dg/warn_unused_function_3.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/warn_unused_function_3.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/68149] [6 Regression][ARM] ICE when splitting unaligned DImode load

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
   Target Milestone|--- |6.0

[Bug target/68149] [6 Regression][ARM] ICE when splitting unaligned DImode load

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-03
 Ever confirmed|0   |1

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Seems that the unaligned_loaddi splitter was just added as a helper for
gen_movmem_ldrd_strd to try to emulate DImode unaligned loads when expanding
movmems.

I'm testing a fix that involves removint he unaligned_loaddi and
unaligned_storedi altogether and instead doing the right thing on unaligned
movmems directly inside gen_movmem_ldrd_strd

[Bug c/68201] New: alloc_size attribute and memory pools

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 68201
   Summary: alloc_size attribute and memory pools
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

When memory pool is used to allocate fixed-size blocks, size of block is often
stored in structure describing mempool. In such case it is not possible to tell
gcc via alloc_size attribute how much memory is allocated in pool_alloc
function. Please add new attribute or extend existing one to support this case
too. You can also provide new build-in function __builtin_set_object_size(ptr,
size) which would be used to handle all non-trivial cases.

Example:

struct MemPool
{
size_t block_size;
};

void* pool_alloc(struct MemPool *pool)
{
void *ptr = get_block_from_pool(pool);
__builtin_set_object_size(ptr, pool->block_size); // example
return ptr;
}

[Bug libstdc++/68200] g++ 5.2 optimizes out pointer assignment in libstdc++ mt_allocator freelist destructor, causing crash at global-dtor time

[oremanj at mit dot edu]

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

--- Comment #1 from Joshua Oreman  ---
Correction: the original bug was PR 52604, not PR 52064.

[Bug libstdc++/68200] New: g++ 5.2 optimizes out pointer assignment in libstdc++ mt_allocator freelist destructor, causing crash at global-dtor time

[oremanj at mit dot edu]

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

Bug ID: 68200
   Summary: g++ 5.2 optimizes out pointer assignment in libstdc++
mt_allocator freelist destructor, causing crash at
global-dtor time
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oremanj at mit dot edu
  Target Milestone: ---

PR 52064 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604) added a guard
assignment to libstdc++-v3/src/c++98/mt_allocator.cc (_M_thread_freelist = 0),
so that attempts to use the freelist after it had been destroyed would not
access invalid memory. This resolved issues with global-scope STL containers
that used mt_allocator being destroyed after the mt_allocator freelist was
destroyed.

~__freelist()
{
  if (_M_thread_freelist_array)
{
  __gthread_key_delete(_M_key);
  ::operator delete(static_cast(_M_thread_freelist_array));
  _M_thread_freelist = 0;
}
}

The setting of the _M_thread_freelist member can validly be optimized away,
because accessing the object after its destructor has run is undefined
behavior, and the _M_thread_freelist assignment can't be detected other than by
doing that. Since PR 52064 was resolved in 2012, it appears that gcc has become
smarter about optimizing this case, and the guard assignment no longer is
compiled. I get this assembly:

0x7055d4f0 <(anonymous namespace)::__freelist::~__freelist()>:
+ 0:  cmpq   $0x0,0x8(%rdi)
+ 5:  je 0x7055d510 <(anonymous
namespace)::__freelist::~__freelist()+32>
+ 7:  push   %rbx
+ 8:  mov%rdi,%rbx
+11:  mov0x18(%rdi),%edi
+14:  callq  0x7054d670 
+19:  mov0x8(%rbx),%rdi
+23:  pop%rbx
+24:  jmpq   0x7054b9f0 <_ZdlPv@plt>
+29:  nopl   (%rax)
+32:  repz retq 

It does seem like the existing code is taking advantage of undefined behavior,
so maybe a larger change is in order, but changing the assignment to happen
through a volatile pointer - const_cast<_Thread_record *volatile
&>(_M_thread_freelist) = 0 - resolves the issue.

[Bug fortran/66680] [5 Regression] ICE with openmp, a loop and a type bound procedure

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #5 from Dominique d'Humieres  ---
> The ICE appeared between revisions r221569 (2015-03-22, OK)
> and r221610 (2015-03-23, ICE). It has been fixed between r224647
> (2015-06-19, ICE) and r224707 (2015-06-20, OK).

Do we need to add a test case in order to close this PR as FIXED?

[Bug ada/68179] Default_Component_Value aspect wrongly ignored on derived type

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Keywords|accepts-invalid |wrong-code
Summary|Missing error on|Default_Component_Value
   |Default_Value and   |aspect wrongly ignored on
   |Default_Component_Value |derived type
   |aspects specified for   |
   |derived type|

--- Comment #5 from Eric Botcazou  ---
> You are correct that RM 3.5. 56.3/3 says the same for Default_Value, that it
> shall only be applied to full_type_declaration. So obviously
> full_type_declaration here must include derived types, or the whole feature
> would be useless.

You're right, I misremembered, so both are allowed for derived types.

[Bug tree-optimization/68198] [6 Regression]Excessive code size, compile time and memory usage bloat due to FSM threading in 453.povray

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Target|arm, aarch64|arm, aarch64,x86_64, ppc64

--- Comment #4 from Ramana Radhakrishnan  ---
(In reply to Markus Trippelsdorf from comment #3)
> aarch64 isn't the only architecture affected by this big code size increase.
> ppc64  and x86 are also affected. See "Individual Sizes" graphs on:
> https://vmakarov.fedorapeople.org/spec/

Update the target field then 

[Bug target/68199] New: avr-gcc rise a warning when defining a custom interruption

[astralien3000 at yahoo dot fr]

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

Bug ID: 68199
   Summary: avr-gcc rise a warning when defining a custom
interruption
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: astralien3000 at yahoo dot fr
  Target Milestone: ---

Created attachment 36643
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36643&action=edit
The minimal code that rise the warning

Hello,

For AVRs, interruptions names, as defined in avr-libc, should begin with
"_vector".

So that, avr-gcc check this condition when a function is marked with attribute
"signal" or "interrupt".

But if you want to create a custom startup_script (crt.o), which use custom
interruption names, you get this kind of warning : 
warning: 'rx' appears to be a misspelled signal handler

I did not find any option to gcc that disable this warning. It would be great
to have this option !

[Bug libstdc++/68190] [5/6 Regression] iterator mix up with set::find and heterogenous lookup

[howard.hinnant at gmail dot com]

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

--- Comment #9 from Howard Hinnant  ---
Untested fix suggested:

#if __cplusplus > 201103L   
  template
auto
find(const _Kt& __x) -> decltype(iterator{_M_t._M_find_tr(__x)})
{ return iterator{_M_t._M_find_tr(__x)}; }  

  template
auto
find(const _Kt& __x) const ->
decltype(const_iterator{_M_t._M_find_tr(__x)})  
{ return const_iterator{_M_t._M_find_tr(__x)}; }
#endif

[Bug tree-optimization/68198] [6 Regression]Excessive code size, compile time and memory usage bloat due to FSM threading in 453.povray

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf  ---
aarch64 isn't the only architecture affected by this big code size increase.
ppc64  and x86 are also affected. See "Individual Sizes" graphs on:
https://vmakarov.fedorapeople.org/spec/

[Bug tree-optimization/68198] [6 Regression]Excessive code size, compile time and memory usage bloat due to FSM threading in 453.povray

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-03
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
Confirmed - I'm also seeing this today with a patch that I was testing.

[Bug ada/68179] Missing error on Default_Value and Default_Component_Value aspects specified for derived type

[gcc at gyw dot com]

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

--- Comment #4 from Troy  ---
You are correct that RM 3.5. 56.3/3 says the same for Default_Value, that it
shall only be applied to full_type_declaration. So obviously
full_type_declaration here must include derived types, or the whole feature
would be useless.

[Bug ada/68179] Missing error on Default_Value and Default_Component_Value aspects specified for derived type

[gcc at gyw dot com]

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

--- Comment #3 from Troy  ---
RM 3.6. 22.2/3 says that Default_Component_Value should only be specified for a
full_type_declaration. I.e. not for derived types. Is this not correct?

[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

[Bug fortran/63861] OpenACC coarray ICE (also with OpenMP?)

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
The ICE is gone and between revisions r229303 and r229482 compiling the test
gcc/testsuite/gfortran.dg/goacc/coarray.f95 with '-fcoarray=single -fopenacc'
gives

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/goacc/coarray.f95:13:0:

 !$acc declare device_resident (a)
^
sorry, unimplemented: directive not yet implemented
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/goacc/coarray.f95:21:0:

 !$acc host_data use_device (a)
^
sorry, unimplemented: directive not yet implemented

Is what remains  duplicate of pr63859?

[Bug libstdc++/68190] [5/6 Regression] iterator mix up with set::find and heterogenous lookup

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Nik Bougalis from comment #6)
> I don't follow why an auto return is used, instead of simply
> iterator/const_iterator which is the required return value per the
> documentation I've read.

Because doing that would make the functions declared unconditionally, which
would violate the standard. Using decltype means we get the SFINAE constraint
on the _M_find_tr function and so the overload is disabled when the comparison
function is not transparent, as required by the standard.

But it could be decltype(_M_t._M_find_tr(__x), iterator{}) which would still
check the constraint, and also return the correct type.

I can't test that until I'm home though.

[Bug fortran/54224] Warn for unused internal procedures

[manu at gcc dot gnu.org]

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

--- Comment #28 from Manuel López-Ibáñez  ---
(In reply to Dominique d'Humieres from comment #27)
> > At some moment, the Fortran FE sets DECL_SOURCE_LOCATION() on a tree,
> > probably using loc->lb->line. Finding out where this happens probably
> > requires a bit of debugging.
> 
> /* Set the backend source location of a decl.  */
> 
> void
> gfc_set_decl_location (tree decl, locus * loc)
> {
>   DECL_SOURCE_LOCATION (decl) = loc->lb->location;
> }
> 
> in gcc/fortran/trans-decl.c?

I guess you can always try, but yes it looks one place that could be fixed. I
suggest to add a wrapper function. Something like:

location_t
gfc_location_from_locus (const locus * loc)
{
unsigned int offset = loc->nextc - loc->lb->line;
return linemap_position_for_loc_and_offset (line_table,
loc->lb->location,
offset));
}

I think there is at least one place already that could use this wrapper.

[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #9 from Dominique d'Humieres  ---
I don't get any error for both tests with 5.2.0 and trunk (6.0). The change
occurred between revisions r223194 (2015-05-14, error) and r223447 (2015-05-20,
compiles).

[Bug fortran/54224] Warn for unused internal procedures

[dominiq at lps dot ens.fr]

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

--- Comment #27 from Dominique d'Humieres  ---
> At some moment, the Fortran FE sets DECL_SOURCE_LOCATION() on a tree,
> probably using loc->lb->line. Finding out where this happens probably
> requires a bit of debugging.

/* Set the backend source location of a decl.  */

void
gfc_set_decl_location (tree decl, locus * loc)
{
  DECL_SOURCE_LOCATION (decl) = loc->lb->location;
}

in gcc/fortran/trans-decl.c?

[Bug fortran/59577] OpenMP: ICE with type(c_ptr) in private()

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Dominique d'Humieres  ---
> What is the added value of this PR with respect to pr51024?
> IMO it should be closed as a duplicate.

No feedback for over a year and a half, closing as duplicate of pr51024.

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

[Bug fortran/51024] OpenMP: ICE with type(c_ptr) in private()

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||06needhamt at gmail dot com

--- Comment #4 from Dominique d'Humieres  ---
*** Bug 59577 has been marked as a duplicate of this bug. ***

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez  ---
(In reply to Jiří Engelthaler from comment #7)
> Created attachment 36638 [details]
> diag_color.patch
> 
> fdiagnostics_color_idx can by on first place so comparing as > 1 will miss
> it.
> There should be >= 1

Good catch! In principle your patch seems correct. I think you are only missing
a testcase. This patch is small enough to not require a copyright assignment:

https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

[Bug fortran/54224] Warn for unused internal procedures

[manu at gcc dot gnu.org]

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

--- Comment #26 from Manuel López-Ibáñez  ---
(In reply to Dominique d'Humieres from comment #25)
> > Nonetheless, as a work-around, you could use:
> >
> >unsigned int offset = loc->nextc - loc->lb->line;
> >location = linemap_position_for_loc_and_offset (line_table,
> >loc->lb->location,
> >offset));
> >
> > to create a new location_t with the correct column number and use that
> > for the tree it creates.
> 
> Where should this be done?

At some moment, the Fortran FE sets DECL_SOURCE_LOCATION() on a tree, probably
using loc->lb->line. Finding out where this happens probably requires a bit of
debugging.

[Bug fortran/52531] [OOP] Compilation fails with polymorphic dummy argument and OpenMP

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #9 from Dominique d'Humieres  ---
The code compiles with 4.8.5, 4.9.3, 5.2.0, and to trunk (6.0), but not with
4.8.2 or 4.9.0. The change occurred between revisions r215860 (2014-10-03,
error) and r216098 (2014-10-10, compiles).

[Bug tree-optimization/68198] [6 Regression]Excessive code size, compile time and memory usage bloat due to FSM threading in 453.povray

[law at redhat dot com]

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

--- Comment #1 from Jeffrey A. Law  ---
I'm on the road the rest of this will, but will definitely take a look at this
ASAP.

[Bug tree-optimization/68198] [6 Regression]Excessive code size, compile time and memory usage bloat due to FSM threading in 453.povray

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|Excessive code size,|[6 Regression]Excessive
   |compile time and memory |code size, compile time and
   |usage bloat due to FSM  |memory usage bloat due to
   |threading in 453.povray |FSM threading in 453.povray
  Known to fail||6.0

[Bug tree-optimization/68198] New: Excessive code size, compile time and memory usage bloat due to FSM threading in 453.povray

[ktkachov at gcc dot gnu.org]

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

Bug ID: 68198
   Summary: Excessive code size, compile time and memory usage
bloat due to FSM threading in 453.povray
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: compile-time-hog, memory-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
CC: law at redhat dot com
  Target Milestone: ---
Target: arm, aarch64

Created attachment 36642
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36642&action=edit
-fmem-report output

I see a large compile-time regression building 453.povray from SPEC2006 on arm
and aarch64.

The file in question is fnpovfpu.cpp.
Try compiling it with:

arm-none-linux-gnueabihf-g++ -DSPEC_CPU -DNDEBUG-Ofast -mcpu=cortex-a57
-mfpu=neon-vfpv4 -mfloat-abi=hard -mthumb -fno-strict-aliasing -w fnpovfpu.cpp

A gcc from around end of Sep 23rd takes about 1.4s to compile the file on my
machine.

Recent gcc at r229696 takes about 6 and a half minutes and consumes a peak of
9.1GB of memory on an x86_64 host.

I'm attaching the -fmem-report I get.
The offending function pov::POVFPU_RunDefault is a large switch statement
inside a while (true), so I'm suspecting the FSM threading code.

The resulting assembly code on arm is so large that it doesn't assemble with
many "branch offset out of range" errors.

I'm seeing a similar time and space explosion on aarch64.
Jeff, could you please take a look?

[Bug fortran/40876] OpenMP private variable referenced in a statement function

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Dominique d'Humieres  ---
Relate to/duplicate of pr38724?

[Bug fortran/38724] Segfault caused by derived-type with allocatable component in OpenMP private clause

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Dominique d'Humieres  ---
Between revisions r211105 (2014-05-31, malloc error) and r211652 (2014-06-13,
no run time error) the has started to run without error. The 'fix' has been
back ported to 4.9.

> So the test case should probably be rejected by the front end
> (alternatively: support it as a GNU extension).

The code compiles and executes at r229706 (trunk 6.0).

Relate to/duplicate of pr40876?

[Bug tree-optimization/67742] 3rd-level restrict ignored

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
Just this patch left: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00202.html

[Bug rtl-optimization/49429] [4.7 Regression] dse.c change (r175063) causes execution failures

[hp at gcc dot gnu.org]

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

--- Comment #20 from Hans-Peter Nilsson  ---
(In reply to Alexandre Oliva from comment #19)
> Would you guys with access to the affected platforms please let me know in
> case revision 229696, just installed in the trunk, regresses this?

Yes, I would eventually.
To wit: the number of regressions between r229676 and r229696 (10) did not
change for cris-elf and contains none of those in the list in my first comment
and none of Steve's.

[Bug target/68192] AIX libstdc++ TLS symbols not exported

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
This is a regression, but only indirectly a GCC regression.

[Bug fortran/54224] Warn for unused internal procedures

[dominiq at lps dot ens.fr]

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

--- Comment #25 from Dominique d'Humieres  ---
> Nonetheless, as a work-around, you could use:
>
>unsigned int offset = loc->nextc - loc->lb->line;
>location = linemap_position_for_loc_and_offset (line_table,
>loc->lb->location,
>offset));
>
> to create a new location_t with the correct column number and use that
> for the tree it creates.

Where should this be done?

[Bug rtl-optimization/68194] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Created attachment 36641
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36641&action=edit
cse2 dump containing the 'bad' RTL

attaching the cse2 dump.

[Bug rtl-optimization/68194] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Created attachment 36640
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36640&action=edit
cprop dump before the suspected bad transformation

Confirmed the failure.
However I think the cited revision (RTL if-conversion change) exposes another
bug.

I think cse goes wrong and ends up CSEing a memory load from a symbol_ref to
'f':
(insn 67 66 68 13 (set (reg:HI 108 [ f ])
(mem/c:HI (symbol_ref:DI ("f") [flags 0x2]  ) [2 f+0 S2 A16])) fail.c:28 88 {*movhi_internal}
 (nil))
(insn 68 67 69 13 (set (reg:SI 109 [ f ])
(sign_extend:SI (subreg:QI (reg:HI 108 [ f ]) 0))) fail.c:28 146
{extendqisi2}
 (expr_list:REG_DEAD (reg:HI 108 [ f ])
(nil)))

in basic block 13 gets transformed to:
(insn 68 66 69 13 (set (reg:SI 109 [ f ])
(sign_extend:SI (subreg:QI (reg:HI 112 [ f ]) 0))) fail.c:28 146
{extendqisi2}
 (expr_list:REG_DEAD (reg:HI 108 [ f ])
(nil)))

because (symbol_ref:DI ("f") gets loaded into reg 112 in another basic block
(bb 8).
This seems bogus to me.
Indeed, adding -fno-rerun-cse-after-loop (the flag controlling cse2) to the
flags makes the testcase pass

[Bug rtl-optimization/68189] [4.9/5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu by RTL if-conversion

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
  Component|tree-optimization   |rtl-optimization
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
Summary|[4.9/5/6 Regression] wrong  |[4.9/5/6 Regression] wrong
   |code at -Os and above on|code at -Os and above on
   |x86_64-linux-gnu|x86_64-linux-gnu by RTL
   ||if-conversion

--- Comment #4 from Richard Biener  ---
-fno-tree-pre hides the bug (what PRE does doesn't look invalid to me).
-fno-if-conversion fixes it as well (on the GCC 5 branch), disabling ce1 and
ce2
is required (ce1 does the bogus job).

[Bug rtl-optimization/68189] [4.9/5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu by RTL if-conversion

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Symptom in the asm is that %ecx is used uninitialized.

[Bug target/68178] [arm] Relative address expressions bind at as-time, even if symbol is weak

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #8 from Richard Earnshaw  ---
Based on the follow-up discussions, I'm re-opening this.  While I don't think
it's really a GCC bug, we can work around the assembler ambiguity problems in
the compiler.

To do this, legitimize_pic_address needs to not call arm_pic_static_addr() when
a symbol definition is weak, even if it does bind locally.

[Bug fortran/65751] Bogus &L in error message

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
I don't understand comment 2

> And I think an English error message that points out the place
> of the error is more useful than a native-language one which doesn't,
> so I would favor back porting.

Does it mean that the patch in comment 1 will break translation?

[Bug tree-optimization/68189] [4.9/5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to work||4.8.5
   Target Milestone|6.0 |4.9.4
Summary|[6 Regression] wrong code   |[4.9/5/6 Regression] wrong
   |at -Os and above on |code at -Os and above on
   |x86_64-linux-gnu|x86_64-linux-gnu

--- Comment #3 from Richard Biener  ---
(In reply to Marek Polacek from comment #1)
> Started with r217827.

Are you sure?  It is miscompiled with GCC 5 for me as well.  It also
aborts with GCC 4.9 (but only with -O2), GCC 4.8 seems to work.

[Bug c++/68184] [4.9/5/6 Regression] Exception from a virtual function does not get caught

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.3.4
   Keywords||wrong-code
   Last reconfirmed||2015-11-03
 Ever confirmed|0   |1
Summary|Exception from a virtual|[4.9/5/6 Regression]
   |function does not get   |Exception from a virtual
   |caught  |function does not get
   ||caught
   Target Milestone|--- |4.9.4
  Known to fail||4.8.5, 5.2.0

--- Comment #1 from Richard Biener  ---
Confirmed.  Works with -O0 and fails with -O1+.  Works with GCC 4.3.

[Bug c++/68188] Ambiguous code gets compiled successfully when class and its namespace have the same name

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid,
   ||rejects-valid

--- Comment #1 from Richard Biener  ---
So the actual bug is that the following is rejected:

namespace Foo
{
  class Foo
{
public:
  static int x;
};

  int Foo::x;
}

int main()
{
  using namespace Foo;
  Foo::x;
  return 0;
}

which means that GCC does not consider the used namespace Foo when seeing
the qualified name 'Foo::x' (it finds Foo::Foo:x just fine).

When changing the above to

namespace Foo
{
  namespace Foo
{
  int x;
}
}
int main()
{
  using namespace Foo;
  Foo::x;
  return 0;
}

then we get

t.C: In function ‘int main()’:
t.C:11:3: error: reference to ‘Foo’ is ambiguous
   Foo::x;
   ^
t.C:2:1: note: candidates are: namespace Foo { }
 {
 ^
t.C:4:5: note: namespace Foo::Foo { }
 {
 ^

which means that the actual ambiguity is on 'Foo' (also with your own
testcase)?

[Bug rtl-optimization/68194] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-03
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r228194.

[Bug tree-optimization/68189] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|wrong code at -Os and above |[6 Regression] wrong code
   |on x86_64-linux-gnu |at -Os and above on
   ||x86_64-linux-gnu

--- Comment #2 from Richard Biener  ---
Mine then.

[Bug c/68193] _Generic -Woverflow false alarm

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-03
 Ever confirmed|0   |1

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

[Bug rtl-optimization/68194] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |6.0
Summary|wrong code at -O2 and -O3   |[6 Regression] wrong code
   |on x86_64-linux-gnu |at -O2 and -O3 on
   ||x86_64-linux-gnu

[Bug fortran/66465] Procedure pointer component & non-component interpreted as different type or kind

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|[4.9.2,5.1.0,6.0.0] |Procedure pointer component
   |procedure pointer component |& non-component interpreted
   |& non-component interpreted |as different type or kind
   |as different type or kind   |

--- Comment #2 from Dominique d'Humieres  ---
I see the error from 4.5.4 up to trunk (6.0). Procedure component was not
implemented in 4.4.

[Bug target/67657] [SH][5/6 Regression]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[olegendo at gcc dot gnu.org]

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

--- Comment #20 from Oleg Endo  ---
OK, thanks for checking.

[Bug target/67657] [SH][5/6 Regression]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #19 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #18)
> Sorry, I don't think anybody will remember to keep polling the build
> machines to monitor the build of this package.

You don't have to. The package built successfully ;). And, yes, I could
configure the buildds to send mails in such cases but I don't really want the
avalanche of mails in my inbox :).

Anyway, I can confirm this issue has been fixed!

Adrian

[Bug target/67657] [SH][5/6 Regression]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

[olegendo at gcc dot gnu.org]

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

--- Comment #18 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #17)
> I have scheduled a rebuild of libjpeg-turbo now. The package is now waiting
> for the next free buildd. Please have a look at the package log here [1]
> once any of the buildds has made a build attempt.

Sorry, I don't think anybody will remember to keep polling the build machines
to monitor the build of this package.  Can't buildd send emails on
success/failure (on a selective base, not for everything)?

[Bug fortran/68196] [4.9/5/6 Regression] ICE on function result with procedure pointer component

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-03
 CC||mikael at gcc dot gnu.org
Summary|[6.0.0] ICE on function |[4.9/5/6 Regression] ICE on
   |result with procedure   |function result with
   |pointer component   |procedure pointer component
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
The ICE appeared between revisions r207428 (2014-02-03, compiles) and r207996
(2014-02-21, ICE). AFAICT this is due to an infinite loop in the recursive call
to has_finalizer_component

static bool
has_finalizer_component (gfc_symbol *derived)
{
   gfc_component *c;

  for (c = derived->components; c; c = c->next)
{
  if (c->ts.type == BT_DERIVED && c->ts.u.derived->f2k_derived
  && c->ts.u.derived->f2k_derived->finalizers)
return true;

  if (c->ts.type == BT_DERIVED
  && !c->attr.pointer && !c->attr.allocatable
  && has_finalizer_component (c->ts.u.derived))
return true;
}
  return false;
}

[Bug target/65251] sh4: internal compiler error: Bus error when compiling cpp-netlib

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #5)
> Hmm, the build now failed due to "out of memory" apparently [1]:
> 
> [  7%] Building CXX object
> libs/network/src/CMakeFiles/cppnetlib-uri.dir/uri/uri.cpp.o
> cd /<>/cpp-netlib-0.11.2+dfsg1/obj-sh4-linux-gnu/libs/network/src
> && /usr/bin/c++   -DBOOST_NETWORK_ENABLE_HTTPS -DBOOST_TEST_DYN_LINK
> -Dcppnetlib_uri_EXPORTS -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -D_FORTIFY_SOURCE=2  -Wall -fPIC
> -I/<>/cpp-netlib-0.11.2+dfsg1-o
> CMakeFiles/cppnetlib-uri.dir/uri/uri.cpp.o -c
> /<>/cpp-netlib-0.11.2+dfsg1/libs/network/src/uri/uri.cpp
> virtual memory exhausted: Cannot allocate memory
> 
> Any ideas?

Could be something in the compiler running in a loop.
Can you get the preprocessed source?

[Bug libstdc++/68197] New: negative index to ios_base::iword lead to unpredictable result

[mickael.guene at st dot com]

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

Bug ID: 68197
   Summary: negative index to ios_base::iword lead to
unpredictable result
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mickael.guene at st dot com
  Target Milestone: ---

Created attachment 36639
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36639&action=edit
segfault on my machine

Attach test program will crash since iword(-100) return invalid memory
address.
 In that case it should return a valid long& intialized to 0.

 Inline iword and pword should check negative value.

[Bug target/68192] AIX libstdc++ TLS symbols not exported

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Is this a regression?

[Bug libstdc++/68190] [5/6 Regression] iterator mix up with set::find and heterogenous lookup

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org
Summary|iterator mix up with|[5/6 Regression] iterator
   |set::find and heterogenous  |mix up with set::find and
   |lookup  |heterogenous lookup

--- Comment #7 from Markus Trippelsdorf  ---
I'll let Jonathan handle this, when he comes back from traveling.

[Bug fortran/68196] New: [6.0.0] ICE on function result with procedure pointer component

[damian at sourceryinstitute dot org]

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

Bug ID: 68196
   Summary: [6.0.0] ICE on function result with procedure pointer
component
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

Is this related to 36704 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36704)
or 66465 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66465)?

$ cat proc-ptr-component.f90 
  type AA
procedure(foo), pointer :: funct
  end type 
contains
   function foo(A)
 class(AA) A
 type(AA) foo
   end function 
end 

$ gfortran proc-ptr-component.f90 
gfortran: internal compiler error: Segmentation fault: 11 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ gfortran --version
GNU Fortran (MacPorts gcc6 6-20151018_0) 6.0.0 20151018 (experimental)

[Bug c++/68071] Generic lambda variadic argument pack cannot be empty

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
auto l = [](auto&& x, auto&&...y) { return x; };
l(1);

compiles in GCC. This looks like a parsing issue - the ... is being parsed as
C-style varargs instead of a pack.

[Bug ada/68179] Missing error on Default_Value and Default_Component_Value aspects specified for derived type

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-03
 CC||ebotcazou at gcc dot gnu.org
Summary|No warning when specifying  |Missing error on
   |a Default_Component_Value   |Default_Value and
   |on derived type, resulting  |Default_Component_Value
   |in unexpected behavior  |aspects specified for
   ||derived type
 Ever confirmed|0   |1
   Severity|major   |normal

--- Comment #2 from Eric Botcazou  ---
I think this should be flagged as an error as per RM 22.2/3.  Likewise for
Default _Value as per RM 56.3/3, i.e. the rules are actually consistent.

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

[EngyCZ at gmail dot com]

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

--- Comment #7 from Jiří Engelthaler  ---
Created attachment 36638
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36638&action=edit
diag_color.patch

fdiagnostics_color_idx can by on first place so comparing as > 1 will miss it.
There should be >= 1