[Bug middle-end/79399] GCC fails to compile big source at -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #12 from Jakub Jelinek  ---
Thanks for testing that.

[Bug target/41557] gcc.exe: Internal error: (null) (program cc1plus)

[andris at gcc dot gnu.org]

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

Andris Pavenis  changed:

   What|Removed |Added

 CC||andris at gcc dot gnu.org

--- Comment #7 from Andris Pavenis  ---
About latest (djgpp-stdint.h) it should. Works for me with recent trunk
versions. I have not however got any feedback related to other proposed patch
version.

[Bug c++/79301] With -Werror=pedantic outside C++17 mode, __has_cpp_attribute(fallthrough) is nonzero but [[fallthrough]] fails

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-08
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Interesting.  I'm not sure about how this would work with -Wpedantic
-Wno-error=pedantic.  I don't think there is a precedent for tying the behavior
of language features (or feature test macros) to -Werror settings.  I do agree,
though, that having the built-in return an affirmative result only to have the
compiler reject the feature seems to run counter to its intended purpose.  I'll
confirm this if only to see what others think.

[Bug testsuite/79418] ERROR: gcc.dg/torture/stackalign/builtin-apply-2.c -O0 : syntax error in targe t selector "target arm_hf_eabi || avr-*-* || riscv*-*-*" for "

[andrew at sifive dot com]

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

Andrew Waterman  changed:

   What|Removed |Added

 CC||andrew at sifive dot com

--- Comment #1 from Andrew Waterman  ---
A patch has been submitted to correct this error:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00490.html

[Bug c++/79314] friend function with qualified name definition

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-08
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.5.3, 4.8.3, 4.9.3, 5.3.0,
   ||6.2.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed with today's top of trunk (7.0).  It was never diagnosed so it
doesn't look like a regression.

[Bug c++/79345] [6/7 Regression] passing yet-uninitialized member as argument to base class constructor should warn (-Wunitialized)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-08
 CC||msebor at gcc dot gnu.org
Summary|passing yet-uninitialized   |[6/7 Regression] passing
   |member as argument to base  |yet-uninitialized member as
   |class constructor should|argument to base class
   |warn (-Wunitialized)|constructor should warn
   ||(-Wunitialized)
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed.  Bisection points to r222135 (gcc 6.0.0):

r222135 | jason | 2015-04-15 17:17:29 -0400 (Wed, 15 Apr 2015) | 5 lines

* constexpr.c (cxx_eval_store_expression): Ignore clobbers.
(build_constexpr_constructor_member_initializers): Loop to find
the BIND_EXPR.
* decl.c (start_preparsed_function): Clobber the object at the
beginning of a constructor.


A somewhat simplified test case:

struct A {
  A (int);
};

struct B: A {
  const bool x = true;

  B (): A (x ? 3 : 7) { }
};

void f (void*);
void g ()
{
  B b;
  f ();
}

[Bug c++/79414] [7 Regression] internal compiler error after "error: expected unqualified-id at end of input"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-08
 CC||msebor at gcc dot gnu.org
Summary|internal compiler error |[7 Regression] internal
   |after "error: expected  |compiler error after
   |unqualified-id at end of|"error: expected
   |input"  |unqualified-id at end of
   ||input"
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed but it's so new that I can't easily bisect it yet.  The most recent
revision before that I have access to is r245021 and it doesn't ICE.

[Bug c++/79415] [6/7 Regression] -fcheck-pointer-bounds results in internal compiler error weakref attributes

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-08
 CC||hubicka at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
Summary|-fcheck-pointer-bounds  |[6/7 Regression]
   |results in internal |-fcheck-pointer-bounds
   |compiler error weakref  |results in internal
   |attributes  |compiler error weakref
   ||attributes
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed as a 6/7 regression.  Bisection points to r231373:

r231373 (gcc 6.0.0) failed (status 4):

r231373 | hubicka | 2015-12-07 12:36:54 -0500 (Mon, 07 Dec 2015) | 47 lines

PR ipa/61886

[Bug middle-end/79399] GCC fails to compile big source at -O0

[babokin at gmail dot com]

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

--- Comment #11 from Dmitry Babokin  ---
With new patch it compiled successfully. It took 41G of memory and 5:25 hours
to complete.

[Bug c++/79420] New: ICE on invalid C++ code on x86_64-linux-gnu: in tsubst_copy, at cp/pt.c:14573

[su at cs dot ucdavis.edu]

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

Bug ID: 79420
   Summary: ICE on invalid C++ code on x86_64-linux-gnu: in
tsubst_copy, at cp/pt.c:14573
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This seems to be a recent regression. 

$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170207 (experimental) [trunk revision 245240] (GCC)
$
$ g++-trunk -c -w small.cpp
small.cpp: In instantiation of ‘int f() [with int  = 0]’:
small.cpp:8:12:   required from here
small.cpp:3:12: internal compiler error: in tsubst_copy, at cp/pt.c:14573
   return f.x;
  ~~^
0x6f90b0 tsubst_copy
../../gcc-source-trunk/gcc/cp/pt.c:14573
0x6fe380 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-source-trunk/gcc/cp/pt.c:17858
0x6fe8ae tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-source-trunk/gcc/cp/pt.c:17458
0x6f1957 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:16405
0x6f315c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15666
0x6f2153 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15882
0x6ef5b4 instantiate_decl(tree_node*, bool, bool)
../../gcc-source-trunk/gcc/cp/pt.c:22821
0x73e9a2 instantiate_pending_templates(int)
../../gcc-source-trunk/gcc/cp/pt.c:22942
0x783e01 c_parse_final_cleanups()
../../gcc-source-trunk/gcc/cp/decl2.c:4525
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.
$





template < int > int f ()
{ 
  return f.x;
}

void g ()
{ 
  f < 0 > ();
}

[Bug c++/79416] [4.5/5/6/7 Regression] Internal compiler error for recursive template expansion

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-08
 CC||msebor at gcc dot gnu.org
Summary|Internal compiler error for |[4.5/5/6/7 Regression]
   |recursive template  |Internal compiler error for
   |expansion   |recursive template
   ||expansion
 Ever confirmed|0   |1
  Known to fail||4.5.3, 4.8.3, 4.9.3, 5.3.0,
   ||6.2.0, 7.0

--- Comment #1 from Martin Sebor  ---
Bisection was slow but eventually came up with r149873 (gcc 4.5.0) as the
commit that likely introduced the SEGV.  Prior to it GCC failed with the
following error so the ICE is a regression.

t.C: In function ‘void nops() [with int N = 302]’:
t.C:11:2: error: template instantiation depth exceeds maximum of 500 (use
-ftemplate-depth-NN to increase the maximum) instantiating ‘void nops() [with
int N = 301]’


r149873 | jason | 2009-07-21 23:32:30 -0400 (Tue, 21 Jul 2009) | 4 lines

Core issue 934
* call.c (reference_binding): Implement binding to { }.
(initialize_reference): Binding temporary to non-const && is fine.
* decl.c (grok_reference_init): Remove error for CONSTRUCTOR.

[Bug c++/79419] Explicit specialization of constrained member template: ICE in set_constraints

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-08
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.

[Bug middle-end/41001] alloca broken for -fno-builtin

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #8 from Martin Sebor  ---
In light of the responses and due to no further activity in the last 7+ years
I'm resolving this report as invalid.

[Bug c++/79419] New: Explicit specialization of constrained member template: ICE in set_constraints

[hstong at ca dot ibm.com]

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

Bug ID: 79419
   Summary: Explicit specialization of constrained member
template: ICE in set_constraints
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

### SOURCE ():
template 
struct A {
  template 
  requires U::happyA
  static void foo();

  //template 
  //requires U::happyB
  //static void foo();
};

template <>
template 
requires U::happyA
void A::foo() { }


### COMPILER INVOCATION:
g++ -std=c++1z -fconcepts -c -o /dev/null -x c++ -


### OUTPUT:
:15:18: internal compiler error: in set_constraints, at cp/pt.c:25605
0x60cae9 set_constraints(tree_node*, tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:25605
0x62ee9b determine_specialization
/home/heads/gcc/gcc-source/gcc/cp/pt.c:2376
0x62f1fa check_explicit_specialization(tree_node*, tree_node*, int, int)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:2972
0x5b2544 grokfndecl
/home/heads/gcc/gcc-source/gcc/cp/decl.c:8833
0x6004ae grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
/home/heads/gcc/gcc-source/gcc/cp/decl.c:12180
0x602576 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/decl.c:15096
0x688634 cp_parser_function_definition_from_specifiers_and_declarator
/home/heads/gcc/gcc-source/gcc/cp/parser.c:26071
0x688634 cp_parser_init_declarator
/home/heads/gcc/gcc-source/gcc/cp/parser.c:19152
0x667e7a cp_parser_single_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:26661
0x68399c cp_parser_template_declaration_after_parameters
/home/heads/gcc/gcc-source/gcc/cp/parser.c:26265
0x6836fb cp_parser_explicit_template_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:26500
0x6836fb cp_parser_template_declaration_after_export
/home/heads/gcc/gcc-source/gcc/cp/parser.c:26519
0x66806b cp_parser_explicit_specialization
/home/heads/gcc/gcc-source/gcc/cp/parser.c:16292
0x66837e cp_parser_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:12436
0x68dc7b cp_parser_declaration_seq_opt
/home/heads/gcc/gcc-source/gcc/cp/parser.c:12366
0x68df62 cp_parser_translation_unit
/home/heads/gcc/gcc-source/gcc/cp/parser.c:4369
0x68df62 c_parse_file()
/home/heads/gcc/gcc-source/gcc/cp/parser.c:38354
0x75b223 c_common_parse_file()
/home/heads/gcc/gcc-source/gcc/c-family/c-opts.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


### g++ -v output:
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/heads/gcc/gcc-source/configure
--prefix=/usr/local/gcc-head --enable-languages=c,c++ --enable-lto
--disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release
--disable-nls
Thread model: posix
gcc version 7.0.1 20170125 (experimental) (GCC)

[Bug testsuite/79418] New: ERROR: gcc.dg/torture/stackalign/builtin-apply-2.c -O0 : syntax error in targe t selector "target arm_hf_eabi || avr-*-* || riscv*-*-*" for "

[danglin at gcc dot gnu.org]

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

Bug ID: 79418
   Summary: ERROR: gcc.dg/torture/stackalign/builtin-apply-2.c
-O0 : syntax error in targe t selector "target
arm_hf_eabi ||  avr-*-*  ||  riscv*-*-*" for "
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/stackalign/builtin-apply-1.c  
-fno-
diagnostics-show-caret -fdiagnostics-color=never-O2 -flto -fpic  -S   -o
bui
ltin-apply-1.s(timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gc
c/gcc/testsuite/gcc.dg/torture/stackalign/builtin-apply-1.c
-fno-diagnostics-sho
w-caret -fdiagnostics-color=never -O2 -flto -fpic -S -o builtin-apply-1.s
PASS: gcc.dg/torture/stackalign/builtin-apply-1.c   -O2 -flto -fpic (test for
ex
cess errors)
ERROR: gcc.dg/torture/stackalign/builtin-apply-2.c   -O0 : syntax error in
targe
t selector "target arm_hf_eabi ||  avr-*-*  ||  riscv*-*-*" for " dg-skip-if 12 
"Variadic funcs use different argument passing from normal funcs" { arm_hf_eabi 
|| { avr-*-* } || { riscv*-*-* } } "*" "" "

UNRESOLVED: gcc.dg/torture/stackalign/builtin-apply-2.c   -O0 : syntax error in 
target selector "target arm_hf_eabi ||  avr-*-*  ||  riscv*-*-*" for "
dg-skip-i
f 12 "Variadic funcs use different argument passing from normal funcs" {
arm_hf_
eabi || { avr-*-* } || { riscv*-*-* } } "*" "" "

[Bug libffi/41014] Fix for libffi err_bad_abi test failure

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Martin Sebor  ---
Looks like the xfail was removed in r184897 as part of the merge from upstream
libffi so resolving as fixed.

[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Martin Sebor  ---
I see no error for the test case in comment #0 with the top of trunk (GCC 7.0)
so I'm resolving this report as fixed.  Please reopen it if the problem
persists with different symptoms.

[Bug target/79282] [7 Regresion] FAIL: gcc.target/arm/neon-for-64bits-1.c scan-assembler-times vshr 0

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov  ---
(In reply to Vladimir Makarov from comment #6)

> I think changing pattern
> 
> (1) = 0(2), r(3)
> 
> to
> 
> r(1) = 0(2), r(3)
> 
> would be a right solution on the target side.  The operand 1 can not
> get the same hard register as input operands or other early clobbered
> output operands because it should be the same as operand 2 which
> already can not be assigned to the same hard reg as other input and
> early clobber output operands.
> 
> 
Sorry, It will not work.  I missed the case when operand 2 and 3 is the same
pseudo.  In this case we can not just remove early clobber flag '&'.

OK, I'll try to implement fix in LRA. But it might take 1-2 weeks.

[Bug middle-end/41098] We should be better in folding pow with integer powers

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
The XFAIL is still in the test and replacing it with linker_error() makes the
test fail, so it looks like the optimization opportunities are still there.  I
note that since r229408 fold_builtin_pow doesn't exist anymore as the logic was
 moved to fold_const_builtin_pow and match.pd.

[Bug ipa/70795] [7 Regression] gcc/libjava/interpret.cc:1948:1: ICE: in binds_to_current_def_p, at symtab.c:2232

[dave.anglin at bell dot net]

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

--- Comment #13 from dave.anglin at bell dot net ---
On 2017-02-05, at 1:12 PM, hubicka at gcc dot gnu.org wrote:

> I would aprechiate if someone could bootstrap this
> Index: cgraphunit.c
> ===
> --- cgraphunit.c(revision 245196)
> +++ cgraphunit.c(working copy)
> @@ -541,6 +541,8 @@ cgraph_node::add_new_function (tree fnde
>node->local.local = false;
>node->definition = true;
>node->force_output = true;
> +   if (TREE_PUBLIC (fndecl))
> + node->externally_visible = true;
>if (!lowered && symtab->state == EXPANSION)
>  {
>push_cfun (DECL_STRUCT_FUNCTION (fndecl));

Tested on hppa2.0w-hp-hpux11.11.  The patch fixes the ICE in the revised
testcase.  No regressions were observed in the testsuite.

Dave
--
John David Anglin   dave.ang...@bell.net

[Bug c/41142] make implicit pointer conversions an error when sizeof(int) != sizeof(void *)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-02-07
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
There has been no update on this request in over 7 years.  Is it still relevant
(especially in light of comment #1)?  If so, can you provide more details? 
I.e., what warnings specifically would you like to treat as errors that
-Werror=warning-name doesn't let you do?  Like so:

$ cat t.c && /build/gcc-git/gcc/xgcc -B /build/gcc-git/gcc -O0 -S -Wall
-Werror=int-conversion t.c
int f (void*);
void* g (void)
{
  char *s = f (0);
  f (123);
  s = 345;
  return 456;
}
t.c: In function ‘g’:
t.c:4:13: error: initialization makes pointer from integer without a cast
[-Werror=int-conversion]
   char *s = f (0);
 ^
t.c:5:6: error: passing argument 1 of ‘f’ makes pointer from integer without a
cast [-Werror=int-conversion]
   f (123);
  ^~~
t.c:1:5: note: expected ‘void *’ but argument is of type ‘int’
 int f (void*);
 ^
t.c:6:5: error: assignment makes pointer from integer without a cast
[-Werror=int-conversion]
   s = 345;
 ^
t.c:7:10: error: return makes pointer from integer without a cast
[-Werror=int-conversion]
   return 456;
  ^~~
t.c:4:9: warning: variable ‘s’ set but not used [-Wunused-but-set-variable]
   char *s = f (0);
 ^
cc1: some warnings being treated as errors

[Bug tree-optimization/21485] [5/6/7 Regression] missed load PRE, PRE makes i?86/7 suck

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #62 from Jeffrey A. Law  ---
So one thing that seems to ever so slightly improve this code is to realize
that as we come around to the top of the loop the test _14 < j_20 can be
rewritten as _14 != j_20 (we already know that _14 <= j_20).

That's quite a surprise as all that seems to do is allow propagation of j_20
for _14 in a later PHI node and we do less use work in PRE -- so it seems like
a step backwards at this point.

But then sink comes along and moves two address computations and a load into a
more control dependent block.  LIM4 later pulls the two address computations
totally out of the loop.

But that all seems to be relatively accidental improvements based on PRE not
seeing a transformation.

[Bug middle-end/41150] segmentation fault after using __attribute__((optimize()))

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #11 from Martin Sebor  ---
No ICE on recent trunk (GCC 7).  Resolving as fixed.

[Bug driver/41179] Documentation for "-fno-toplevel-reorder" is confusing (and wrong)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
The description of the option has changed since this issue was first raised but
I agree that the description could be made clearer.  In GCC 7 it reads:

  -fno-toplevel-reorder
   Do not reorder top-level functions, variables, and asm statements.
Output them in the same order that they appear in the input file. When this
option is used, unreferenced static variables are not removed. This option is
intended to support existing code that relies on a particular ordering. For new
code, it is better to use attributes when possible.

   Enabled at level -O0. When disabled explicitly, it also implies
-fno-section-anchors, which is otherwise enabled at -O0 on some targets.

The confusing "-fno-xxx" option ... is enabled/disabled" phrasing is used in at
least a couple pf others places:

  -fno-defer-pop
   ...
   Disabled at levels -O, -O2, -O3, -Os. 

It's unclear whether disabled means -fno-defer-pop is in effect, or whether it
means that -fdefer-pop is.

Or, arguably even more confusing:

  -fno-branch-count-reg
  ...
   Enabled by default at -O1 and higher.
   The default is -fbranch-count-reg.

Most of the remaining -fno-xxx (and -fxxx) options use the phrase "The default
is -fxxx" (or "The default is -fno-xxx"), such as "The default is
-fzero-initialized-in-bss."  I think it would be best to adopt this style
throughout.

[Bug fortran/79417] New: -Wconversion warns wrongly of real(16) to real(8)

[john.harper at vuw dot ac.nz]

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

Bug ID: 79417
   Summary: -Wconversion warns wrongly of real(16) to real(8)
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

If array parameters are declared with both quad and double precision, the quad
one triggers a -Wconversion warning but the program's output shows that the
conversion did not happen. (The warning does not occur with a scalar quad
parameter, nor if the double precision ones are commented out.)  


cayley[~/Jfh] % cat realtest2.f90
program tryit
  implicit none
  integer,parameter:: qp = selected_real_kind(30), dp = kind(1d0)
  real(qp),parameter:: q1 = 1, q23(1) = 2*q1/3
  real(dp),parameter:: d1 = 1, d23(1) = real(q23,dp)
  print "(F42.36)",q23
  print "(F24.18)",d23
end program tryit
cayley[~/Jfh] % gfortran -Wconversion realtest2.f90
realtest2.f90:4:39:

   real(qp),parameter:: q1 = 1, q23(1) = 2*q1/3
   1
Warning: Change of value in conversion from ‘REAL(16)’ to ‘REAL(8)’ at (1)
[-Wconversion]
cayley[~/Jfh] % ./a.out
0.6635
0.30
cayley[~/Jfh] % cayley[~/Jfh] % gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/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
Thread model: posix
gcc version 6.1.1 20160602 (GCC) 
cayley[~/Jfh] %

[Bug tree-optimization/41203] -mtune=pentium2 structure related tree-outof-ssa internal compiler error

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Martin Sebor  ---
Unable to reproduce with the current trunk (GCC 7.0).  Resolving as fixed.

[Bug debug/41272] FAIL: gcc.dg/debug/dwarf2/inline2.c scan-assembler-times \(DIE \(.*?\) DW_TAG_in lined_subroutine 6

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #7 from Martin Sebor  ---
I don't see the test failure in the most recent results for the
hppa-unknown-linux-gnu target:
https://gcc.gnu.org/ml/gcc-testresults/2017-02/msg00693.html

I'll resolve this as fixed.  Please reopen if it still is a problem or it if
reappears.

[Bug tree-optimization/41339] Variables can occur multiple times in cfun->local_decls

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-02-07
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Martin Sebor  ---
The patch doesn't apply in its current form.  Was it ever posted for review to
gcc-patches?  If so, what was the outcome? (I.e., can this bug be resolved one
way or the other?)

[Bug middle-end/79399] GCC fails to compile big source at -O0

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb  7 21:51:21 2017
New Revision: 245256

URL: https://gcc.gnu.org/viewcvs?rev=245256=gcc=rev
Log:
PR middle-end/79399
* ira-int.h (struct target_ira_int): Change x_max_struct_costs_size
type from int to size_t.
* ira-costs.c (struct_costs_size): Change type from int to size_t.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-costs.c
trunk/gcc/ira-int.h

[Bug preprocessor/41540] -dM -E doesn't #define __FILE__

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||documentation, patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-02-07
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Martin Sebor  ---
A documentation-only patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00560.html

[Bug target/68163] GCC on power8 does not issue the stxsspx instruction on power8

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 40691
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40691=edit
Proposed patch to fix the problem.

I believe this patch fixes the problem.

Note, I am going on vacation, and won't return until the end of February, so I
won't be submitting the patch until I get back (unless somebody else wants to
verify that it works and submits it).

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[aldyh at gcc dot gnu.org]

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

--- Comment #53 from Aldy Hernandez  ---
Created attachment 40690
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40690=edit
reduced testcase with rtl dumps and assembly

Ughh, that was painful.  The attached .tar.gz file has a reduced testcase.ii as
well as the RTL dumps and testcase.s.  The testcase looks big, but it only
generates one small function: crapola.

I hope I didn't botch something in the reduction.  The order of loop is
somewhat changed, but I think still exhibits the behavior.  That is:

[snip]
addi 7,5,-1  ;; r7 = length - 1
lwz 3,4(9)
addi 8,8,8
mtctr 7  ;; init CTR to length - 1
li 10,1  ;; j
li 4,1
.align 4
L..3:
lwzu 9,4(8)
lwz 9,4(9)
andis. 7,9,0x4000
beq 0,L..12
addi 10,10,1 ;; keep r10/j updated even though...
bdnz L..3;; ...we iterate with CTR
blr
.align 4
L..12:
lwz 6,0(3)
lwz 7,0(6)
cmpwi 7,7,0
bne- 7,L..13
rlwinm 9,10,29,3,29
rlwinm 7,10,0,27,31
add 9,6,9
addi 10,10,1
lwz 6,12(9)
cmplw 7,5,10 ;; compare length and j
slw 7,4,7
or 7,6,7
stw 7,12(9)
bne+ 7,L..3  ;; branch on j/length but we fail to update CTR!!
blr

[Bug c++/79416] New: Internal compiler error for recursive template expansion

[mini at cs dot technion.ac.il]

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

Bug ID: 79416
   Summary: Internal compiler error for recursive template
expansion
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mini at cs dot technion.ac.il
  Target Milestone: ---

Target: x86_64-linux-gnu
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 

I ran it about 10 times. 9 times I got this output:
$ g++ prog.cpp 
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I got this output 1 time:
$ g++ prog.cpp 

cc1plus: out of memory allocating 268435144 bytes after a total of 101212160
bytes


to reproduce:
$ cat prog.cpp 
template 
void nops() __attribute((always_inline));

template 
void more_nops() __attribute((always_inline));

template 
inline void nops()
{
asm("nop");
nops();
}

template<>
inline void nops<0>()
{
};

template 
inline void more_nops()
{
nops<800>();
more_nops();
};

template<>
inline void more_nops<0>()
{
};

int main() {
more_nops<300>();
}

$ g++ prog.cpp

[Bug c++/79410] [6 Regression] internal compiler error: in gimplify_init_ctor_preeval, at gimplify.c:3489

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This got fixed or went latent with r240845.
r230365 is the first rev that ICEs.

[Bug target/79282] [7 Regresion] FAIL: gcc.target/arm/neon-for-64bits-1.c scan-assembler-times vshr 0

[vmakarov at gcc dot gnu.org]

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

--- Comment #6 from Vladimir Makarov  ---
Here is my analysis of the problem.

 The test was successful as LRA actually did not work for the test.
LRA just checked that all insn constraints were satisfied.  If LRA did
any transformation, the test would fail too before the latest changes
in LRA.

The recent changes in LRA force it to do always a live analysis.  If we
have an insn with the following alternative and operands 1 and 2 are
different pseudos assigned to the same hard register by IRA:

(1) = 0(2), r(3)

lra-constraints.c decides that the insn does not need any
transformation.  If LRA live analysis is executed, it decides that
pseudos in operands 1 and 2 conflicts because LRA live analysis
(lra-lives.c) ignores the fact that they should be in the same hard
register.

Fixing this bug in LRA would require LRA live analysis to be aware of
the chosen alternative and matched operands.  It is a big change,
implementing this would affect other targets unpredictably.  Probably
it is not wise to do it at this stage.

I think changing pattern

(1) = 0(2), r(3)

to

r(1) = 0(2), r(3)

would be a right solution on the target side.  The operand 1 can not
get the same hard register as input operands or other early clobbered
output operands because it should be the same as operand 2 which
already can not be assigned to the same hard reg as other input and
early clobber output operands.

Although I don't know how big the part of .md file will be affected by such
change.

[Bug c++/79415] New: -fcheck-pointer-bounds results in internal compiler error weakref attributes

[jussi.judin at ericsson dot com]

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

Bug ID: 79415
   Summary: -fcheck-pointer-bounds results in internal compiler
error weakref attributes
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jussi.judin at ericsson dot com
  Target Milestone: ---

GCC 7.0.1 (git hash 7458afd6b35c4851d146f058435ba3dd6215db44) results in
internal compiler error on following input with -fcheck-pointer-bounds and
-mmpx options on x86_64 architecture:

void fn1();
static __typeof fn1 fn2 __attribute__((__weakref__("")));
void fn3() { void *a = (void *)fn2; }

When I compile that code, I get following output:

$ gcc-bin/bin/g++ --std=c++11 -c -fcheck-pointer-bounds -mmpx
gcc-error-verify-cgraph-node-failed.cc
gcc-error-verify-cgraph-node-failed.cc:3:37: error: node is weakref but not an
transparent_alias
 void fn3() { void *a = (void *)fn2; }
 ^
_ZL3fn2v.chkp/5 (void fn2.chkp()) @0x7fb2e16b7450
  Type: function alias weakref target:
  Visibility: weak
  Address is taken.
  References: 
  Referring: _Z3fn3v.chkp/2 (addr)
  Availability: not_available
  First run: 0
  Function flags:
  Called by: 
  Calls: 
  Is instrumented version.
gcc-error-verify-cgraph-node-failed.cc:3:37: internal compiler error:
verify_cgraph_node failed
0x92460b cgraph_node::verify_node()
../../gcc/gcc/cgraph.c:3490
0x91937c symtab_node::verify()
../../gcc/gcc/symtab.c:1183
0x91944f symtab_node::verify_symtab_nodes()
../../gcc/gcc/symtab.c:1203
0xb626a5 symtab_node::checking_verify_symtab_nodes()
../../gcc/gcc/cgraph.h:616
0xb626a5 symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc/gcc/ipa.c:698
0xc53fce execute_todo
../../gcc/gcc/passes.c:2030
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.

gcc -v returns following information on Ubuntu 14.04 based x86_64 system:

Using built-in specs.
COLLECT_GCC=/home/ejusjud/local/gcc-bin/bin/g++
COLLECT_LTO_WRAPPER=/local/ejusjud/gcc-bin/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --enable-libmpx
--prefix=/home/ejusjud/local/gcc-bin : (reconfigured) ../gcc/configure
--enable-languages=c,c++ --enable-libmpx --prefix=/home/ejusjud/local/gcc-bin :
(reconfigured) ../gcc/configure --enable-languages=c,c++ --enable-libmpx
--prefix=/home/ejusjud/local/gcc-bin : (reconfigured) ../gcc/configure
--enable-languages=c,c++ --enable-libmpx --prefix=/home/ejusjud/local/gcc-bin :
(reconfigured) ../gcc/configure --enable-languages=c,c++ --enable-libmpx
--prefix=/home/ejusjud/local/gcc-bin : (reconfigured) ../gcc/configure
--enable-languages=c,c++ --enable-libmpx --prefix=/home/ejusjud/local/gcc-bin :
(reconfigured) ../gcc/configure --enable-languages=c,c++ --enable-libmpx
--prefix=/home/ejusjud/local/gcc-bin : (reconfigured) ../gcc/configure
--enable-languages=c,c++ --enable-libmpx --prefix=/home/ejusjud/local/gcc-bin
Thread model: posix
gcc version 7.0.1 20170207 (experimental) (GCC)

[Bug pch/41346] Precompiled headers from stdin don't work

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Martin Sebor  ---
This has been changed and stdin is no longer accepted as input for c-header:

$ gcc -x c-header - 

[Bug c++/41373] attribute error and warning dont show the instantiation stack

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed with recent trunk of GCC 7.  The instantiation context should be
present in all diagnostics.

$ cat t.C && gcc -S -Wall t.C
void f (int) __attribute__ ((error ("error")));
void f (double) __attribute__ ((warning ("warning")));
void f (void*) __attribute__ ((deprecated));

template 
void g ()
{
  f (T ());
}

int main ()
{
  g();
  g();
  g();
}
t.C: In instantiation of ‘void g() [with T = void*]’:
t.C:15:12:   required from here
t.C:8:5: warning: ‘void f(void*)’ is deprecated [-Wdeprecated-declarations]
   f (T ());
   ~~^~
t.C:3:6: note: declared here
 void f (void*) __attribute__ ((deprecated));
  ^
t.C: In function ‘void g() [with T = int]’:
t.C:8:5: error: call to ‘f’ declared with attribute error: error
   f (T ());
   ~~^~
t.C: In function ‘void g() [with T = double]’:
t.C:8:5: warning: call to ‘f’ declared with attribute warning: warning
   f (T ());
   ~~^~

[Bug c/41517] Unexpected behaviour of #pragma in statement context

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=63326
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
It seems this should either be confirmed or resolved as a duplicate of bug
63326.  Silently treating #pragmas differently between C and C++ is a recipe
for subtle bugs.  A warning as suggested in bug 63326 comment 8 would be
helpful.

[Bug c++/79414] New: internal compiler error after "error: expected unqualified-id at end of input"

[jussi.judin at ericsson dot com]

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

Bug ID: 79414
   Summary: internal compiler error after "error: expected
unqualified-id at end of input"
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jussi.judin at ericsson dot com
  Target Milestone: ---

GCC 7.0.1 (git commit 7458afd6b35c4851d146f058435ba3dd6215db44) segmentation
faults on following code after "error: expected unqualified-id at end of
input". I encountered this while applying C-Reduce to another type of crash:

class x0;
template  x2() {
x0 x3 = x3.

If I try to compile this with "gcc-bin/bin/g++ tst.cc" command, it will result
in following output:

tst.cc:2:11: error: ‘x1’ has not been declared
 template  x2() {
   ^~
tst.cc:2:18: error: ISO C++ forbids declaration of ‘x2’ with no type
[-fpermissive]
 template  x2() {
  ^
tst.cc: In function ‘int x2()’:
tst.cc:3:4: warning: ‘x3’ has incomplete type
 x0 x3 = x3.
^~
tst.cc:1:7: note: forward declaration of ‘class x0’
 class x0;
   ^~
tst.cc:3:11: error: expected unqualified-id at end of input
 x0 x3 = x3.
   ^
tst.cc:3:11: internal compiler error: Segmentation fault
0xd27c4f crash_signal
../../gcc/gcc/toplev.c:333
0x60a355 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6877
0x708c2c cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19398
0x70947c cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12792
0x70a235 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12617
0x70ace9 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:12227
0x6e59c3 cp_parser_statement
../../gcc/gcc/cp/parser.c:10714
0x6e6a5d cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11046
0x6e6b2f cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11000
0x6fad43 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21450
0x6fad43 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21488
0x7037a1 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26255
0x708fa0 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26167
0x708fa0 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19177
0x6e2a0a cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:26713
0x702ddc cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:26317
0x702a6c cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:26552
0x702a6c cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:26571
0x6e2ed9 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12464
0x71369b cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12391
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.

gcc -v gives following output on x86_64 Ubuntu 14.04 based system:

Using built-in specs.
COLLECT_GCC=/home/ejusjud/local/gcc-bin/bin/g++
COLLECT_LTO_WRAPPER=/local/ejusjud/gcc-bin/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --enable-libmpx
--prefix=/home/ejusjud/local/gcc-bin : (reconfigured) ../gcc/configure
--enable-languages=c,c++ --enable-libmpx --prefix=/home/ejusjud/local/gcc-bin :
(reconfigured) ../gcc/configure --enable-languages=c,c++ --enable-libmpx
--prefix=/home/ejusjud/local/gcc-bin : (reconfigured) ../gcc/configure
--enable-languages=c,c++ --enable-libmpx --prefix=/home/ejusjud/local/gcc-bin :
(reconfigured) ../gcc/configure --enable-languages=c,c++ --enable-libmpx
--prefix=/home/ejusjud/local/gcc-bin : (reconfigured) ../gcc/configure
--enable-languages=c,c++ --enable-libmpx --prefix=/home/ejusjud/local/gcc-bin :
(reconfigured) ../gcc/configure --enable-languages=c,c++ --enable-libmpx
--prefix=/home/ejusjud/local/gcc-bin : (reconfigured) ../gcc/configure
--enable-languages=c,c++ --enable-libmpx --prefix=/home/ejusjud/local/gcc-bin
Thread model: posix
gcc version 7.0.1 20170207 (experimental) (GCC)

[Bug testsuite/41671] Unsatisfied symbol "__sync_fetch_and_add_4"

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #3 from John David Anglin  ---
I have fixed all the testcases where this is a problem (for the moment).

[Bug c++/41596] handling of library-related options by g++spec.c causes a failure when generating pch.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-02-07
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug preprocessor/41590] No __STDC__ definition in -g3 -E output on STDC_0_IN_SYSTEM_HEADERS systems

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||documentation, patch
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #3 from Martin Sebor  ---
Documentation patch:
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00560.html

[Bug c/79411] [5/6/7 Regression] ICE: SSA corruption (fail_abnormal_edge_coalesce)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
There is just a single SSA_NAME_OCCURS_IN_ABNORMAL_PHI check in
tree-ssa-reassoc.c in the range handling code, I'd say that is significantly
less than what really is needed.  Unless we want to add code to be extremely
careful about (ab) SSA_NAMEs, I'd say we just shouldn't try to reassociate
anything involving those.  To be precise, it would be ok if say we have:
  _2 = d_1(ab) + 1;
...
  _5 = _2 + 1;
to turn that into
  _30 = d_1(ab);
...
  _5 = _30 + 2;
and similar, but the (ab) uses would need to stay at the points they were used
in, I guess that would be a lot of work though (and still we shouldn't look
through (ab) SSA_NAMEs e.g. when linearizing trees etc.
So perhaps it will be much easier to just punt if (ab) appears on lhs or
rhs{1,2}, and don't look through in linearization if there are (ab) operands in
those (so that ops array stays (ab) free.  Richard, what do you think about
that?

[Bug target/41557] gcc.exe: Internal error: (null) (program cc1plus)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-02-07
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Martin Sebor  ---
Is this still a problem or did the fix in r231804 resolve it?

[Bug c/79411] [5/6/7 Regression] ICE: SSA corruption (fail_abnormal_edge_coalesce)

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Seems it is reassoc1 that transforms:
@@ -48,7 +69,6 @@ foo (struct C * x, const int * y, unsign

 ;;   basic block 5, loop depth 0
 ;;pred:   3
-  _2 = d_1(ab) + 1;
   _3 = x_25(D)->c1;
   if (_3 != 0)
 goto ; [50.00%]
@@ -81,7 +101,7 @@ foo (struct C * x, const int * y, unsign
 ;;pred:   7
   _5 = e_27(D) == 0;
   _6 = d_1(ab) > 7;
-  _7 = _5 | _6;
+  _7 = _6 | _5;
   if (_7 != 0)
 goto ; [50.00%]
   else
@@ -155,7 +175,7 @@ foo (struct C * x, const int * y, unsign

 ;;   basic block 16, loop depth 0
 ;;pred:   15
-  _11 = _2 + 1;
+  _11 = d_1(ab) + 2;
   *z_29(D) = _11;
 ;;succ:   17

which is not valid, because while in bb5 d_1(ab) is the current SSA_NAME of d,
in bb16 it is d_13(ab), so it can't be propagated.  Looking into it.

[Bug c++/41575] GCC lists private methods as candidates in "no matching function for call"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #3 from Martin Sebor  ---
As stated in the comments the error message is strictly correct because
overload resolution takes place before access checking.  At the same time, I do
agree that it might be helpful to mention the access level of each candidate in
the error message if/when the access matters, similarly to what Clang does
(below). On that basis I'll confirm this as an enhancement request.

t.C:11:16: error: 'f' is a private member of 'Klass'
Klass::f (x);
   ^
t.C:5:21: note: declared private here
static void f(const char*& a, int b) {}
^
t.C:11:20: error: too few arguments to function call, expected 2, have 1
Klass::f (x);
   ^
t.C:5:9: note: 'f' declared here
static void f(const char*& a, int b) {}

[Bug target/41644] -minimal-toc not helping for toc section exceeding 64k

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #12 from Martin Sebor  ---
Based on the comments it sounds to me like this is not a bug but a known
limitation of the architecture that recent GCC versions (4.6 and newer) provide
a mechanism to help mitigate.  I'll close this as invalid.  Please feel free to
reopen it if you feel GCC is still deficient in some respect here.

[Bug testsuite/41667] g++.dg/debug/dwarf2/typedef1.C scan-assembler-times fails

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Martin Sebor  ---
The test is not reported as failing in recent hppa64-hp-hpux11.11 test results 
(https://gcc.gnu.org/ml/gcc-testresults/2017-02/msg00756.html).  Resolving as
fixed.

[Bug testsuite/41671] Unsatisfied symbol "__sync_fetch_and_add_4"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-02-07
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
I don't have access to an HPPA host.  John David, is this still a problem with
GCC 7 or can this report be closed?

[Bug c++/41727] [7 Regression] inner template specialization on non-type arg template causes ICE

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||msebor at gcc dot gnu.org
Summary|inner template  |[7 Regression] inner
   |specialization on non-type  |template specialization on
   |arg template causes ICE |non-type arg template
   ||causes ICE
 Ever confirmed|0   |1
  Known to fail||4.5.3, 7.0

--- Comment #3 from Martin Sebor  ---
Confirmed with GCC 7.0 (see below).  The ICE must have gone away and then
reappeared.  The first recent revision that triggers it is r243868.

r243868 | jason | 2016-12-21 14:38:35 -0500 (Wed, 21 Dec 2016) | 5 lines

Check that a partial specialization is more specialized.

* pt.c (process_partial_specialization): Use
get_partial_spec_bindings to check that the partial specialization
is more specialized than the primary template.

Before that, GCC failed to compile the test case with the following error so
I'm marking this as a GCC 7 regression.

t.C:97:6: error: invalid use of incomplete type ‘struct
outer::inner >’
   >::type
  ^~~~
t.C:18:5: note: declaration of ‘struct outer::inner >’
 inner
 ^



$ /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O2 -S -Wall -Wextra
-Wmaybe-uninitialized -Wuninitialized -xc++ t.C
t.C: In substitution of ‘template struct
outer::inner [with InnerArg0 = outer_arg0; InnerArg1 = ]’:
t.C:70:5:   required from here
t.C:70:5: internal compiler error: tree check: accessed elt 2 of tree_vec with
1 elts in tsubst, at cp/pt.c:13424
 inner
 ^
   < InnerArg0
   ~~~
   , value_wrap
   
   #ifdef INNER_ARG1_NON_TYPE
   ~~
 < InnerArg1NonType
 ~~
   #else
   ~
 < inner_arg1_non_type
 ~
   #endif
   ~~
 >
 ~
   >
   ~
0x14fb4e4 tree_vec_elt_check_failed(int, int, char const*, int, char const*)
/src/gcc/trunk/gcc/tree.c:10012
0x7efcf3 tree_vec_elt_check(tree_node*, int, char const*, int, char const*)
/src/gcc/trunk/gcc/tree.h:3281
0x8b0fda tsubst(tree_node*, tree_node*, int, tree_node*)
/src/gcc/trunk/gcc/cp/pt.c:13424
0x8a3d34 tsubst_template_arg
/src/gcc/trunk/gcc/cp/pt.c:10762
0x8a710a tsubst_template_args
/src/gcc/trunk/gcc/cp/pt.c:11645
0x8a6d60 tsubst_template_args
/src/gcc/trunk/gcc/cp/pt.c:11605
0x8b2617 tsubst(tree_node*, tree_node*, int, tree_node*)
/src/gcc/trunk/gcc/cp/pt.c:13693
0x8d86ce get_partial_spec_bindings
/src/gcc/trunk/gcc/cp/pt.c:21519
0x885c5f process_partial_specialization
/src/gcc/trunk/gcc/cp/pt.c:4618
0x88a2b0 push_template_decl_real(tree_node*, bool)
/src/gcc/trunk/gcc/cp/pt.c:5343
0x88ccdb push_template_decl(tree_node*)
/src/gcc/trunk/gcc/cp/pt.c:5584
0x874a4d maybe_process_partial_specialization(tree_node*)
/src/gcc/trunk/gcc/cp/pt.c:974
0x98b2ce cp_parser_class_head
/src/gcc/trunk/gcc/cp/parser.c:22715
0x9893e3 cp_parser_class_specifier_1
/src/gcc/trunk/gcc/cp/parser.c:22031
0x98a494 cp_parser_class_specifier
/src/gcc/trunk/gcc/cp/parser.c:22344
0x97e5cc cp_parser_type_specifier
/src/gcc/trunk/gcc/cp/parser.c:16408
0x97957d cp_parser_decl_specifier_seq
/src/gcc/trunk/gcc/cp/parser.c:13325
0x9924c7 cp_parser_single_declaration
/src/gcc/trunk/gcc/cp/parser.c:26602
0x99178d cp_parser_template_declaration_after_parameters
/src/gcc/trunk/gcc/cp/parser.c:26293
0x99235f cp_parser_explicit_template_declaration
/src/gcc/trunk/gcc/cp/parser.c:26529
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/79412] [5/6/7 Regression] ICE in fold_convert_loc, at fold-const.c:2239

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Seems the C FE on such redeclarations doesn't merge the decls (correct), but
overwrites the type in pop_scope:
1345  I_SYMBOL_BINDING (b->id) = b->shadowed;
1346  if (b->shadowed && b->shadowed->u.type)
1347TREE_TYPE (b->shadowed->decl) = b->shadowed->u.type;
so we end up gimplifying POSTINCREMENT_EXPR of a VAR_DECL with array type, no
wonder we ICE on that.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[msebor at gcc dot gnu.org]

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

Bug 41817 Summary: bogus "may be uninitialized" (huge testcase, inlining?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41817

   What|Removed |Added

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

[Bug middle-end/41744] ICE: fold check: original tree changed by fold

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #3 from Martin Sebor  ---
I can't reproduce this ICE with a recent trunk (GCC 7).  Since GCC 4.5 is no
longer maintained I'm closing this as worksforsome.  Please open a new bug if
this is still an issue with a maintained version of GCC.

[Bug middle-end/41817] bogus "may be uninitialized" (huge testcase, inlining?)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #9 from Martin Sebor  ---
The test case in attachment 1 compiles with no warning with recent trunk
(GCC 7) with the same options as in comment #0.  Resolving as fixed.

[Bug plugins/41820] cc1: error: Cannot load plugin ./selfassign.so

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Martin Sebor  ---
The test doesn't fail in recent test results with GCC 7:
  https://gcc.gnu.org/ml/gcc-testresults/2017-02/msg00756.html

I'm resolving this as fixed.  John David, please reopen the bug if I missed
something.

[Bug c/79412] [5/6/7 Regression] ICE in fold_convert_loc, at fold-const.c:2239

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug c++/79369] namespace definition with qualified id

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Tue Feb  7 18:02:05 2017
New Revision: 245252

URL: https://gcc.gnu.org/viewcvs?rev=245252=gcc=rev
Log:
PR c++/79369 inline namespaces
gcc/cp
* cp-tree.h (NAMESPACE_CHECK): New.
(NAMESPACE_INLINE_P): New.
* name-lookup.h (push_namespace): Return int.
* name-lookup.c (push_namespace): Return int. Adjust.
* parser.c (cp_parser_namespace_definition): Reorder nested
parsing.  Check inline redefinition.
gcc/testsuite/
* g++.dg/cpp0x/pr65558.C: Adjust error loc.
* g++.dg/cpp0x/pr79369.C: New.
* g++.dg/cpp1z/nested-namespace-def1.C: Adjust.

Added:
branches/c++-modules/gcc/testsuite/g++.dg/cpp0x/pr79369.C
Modified:
branches/c++-modules/ChangeLog.modules
branches/c++-modules/gcc/cp/cp-tree.h
branches/c++-modules/gcc/cp/name-lookup.c
branches/c++-modules/gcc/cp/name-lookup.h
branches/c++-modules/gcc/cp/parser.c
branches/c++-modules/gcc/testsuite/g++.dg/cpp0x/pr65558.C
branches/c++-modules/gcc/testsuite/g++.dg/cpp1z/nested-namespace-def1.C

[Bug c++/79369] namespace definition with qualified id

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
r245252 on c++-modules has a patch (for when stage 1 opens)

[Bug middle-end/41838] Incorrect "dereferencing pointer '' does break strict-aliasing rules"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Martin Sebor  ---
The test case from attachment 18908 compiles with just a -Wunused-parameter
warning on trunk.  Resolving as fixed.

t.c: In function ‘Twine operator+(const Twine&, const Twine&)’:
t.c:16:63: warning: unused parameter ‘RHS’ [-Wunused-parameter]
  inline Twineoperator + (const Twine & LHS, const Twine & RHS) {
   ^~~

[Bug tree-optimization/56456] [meta-bug] bogus warning when inlining or unrolling: "array subscript is above array bounds"

[msebor at gcc dot gnu.org]

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

Bug 41847 Summary: warning: array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41847

   What|Removed |Added

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

[Bug c++/41847] warning: array subscript is above array bounds

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #8 from Martin Sebor  ---
With the top of trunk (GCC 7) the test case from attachment 18916 compiles
cleanly both with a s390x cross-compiler and natively on x86_64:

$ /build/s390x-linux/gcc-trunk/gcc/xgcc -B /build/s390x-linux/gcc-trunk/gcc -O2
-S -Wall -Wextra t.C
t.C: In instantiation of ‘void ImplHomMatrixTemplate<_RowSize>::ludcmp(short
unsigned int*) [with unsigned int _RowSize = 4]’:
t.C:89:21:   required from here
t.C:62:36: warning: unused parameter ‘nIndex’ [-Wunused-parameter]
  void ludcmp(unsigned short nIndex[])
^

Resolving as fixed.

[Bug c/79411] [5/6/7 Regression] ICE: SSA corruption (fail_abnormal_edge_coalesce)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|ICE: SSA corruption |[5/6/7 Regression] ICE: SSA
   |(fail_abnormal_edge_coalesc |corruption
   |e)  |(fail_abnormal_edge_coalesc
   ||e)
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r198096.

[Bug c/79413] [7 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:265

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Started with r235817.

[Bug target/41880] CONSTANT_ADDRESS_P undefined.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||build
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Martin Sebor  ---
The top of trunk (GCC 7) builds successfully for rx-elf, and according to
comment #3, GCC 5 apparently does as well.  Resolving as fixed.

[Bug middle-end/79396] [7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O2

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
Created attachment 40689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40689=edit
preprocessed source

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[tss at iki dot fi]

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

Timo Sirainen  changed:

   What|Removed |Added

 CC||tss at iki dot fi

--- Comment #4 from Timo Sirainen  ---
I ran into this issue as well while looking at where all the memory is going
to. I've potentially tens of thousands of processes running, and 71 kB of
memory per process for something that almost never happens is too expensive. I
wouldn't mind std::bad_alloc just killing the process immediately if it
happens.

So at least having the LIBSTDCXX_EMERGENCY_EH_POOL_SIZE environment would be
helpful in future.

[Bug rtl-optimization/79386] [7 Regression] ICE: segmentation fault in cprop w/ -O2 on 32-bit BE powerpc

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb  7 17:45:57 2017
New Revision: 245251

URL: https://gcc.gnu.org/viewcvs?rev=245251=gcc=rev
Log:
PR rtl-optimization/79386
* cprop.c (bypass_conditional_jumps): Initialize
bypass_last_basic_block already before splitting bbs after
unconditional traps...
(bypass_conditional_jumps): ... rather than here.

* gcc.c-torture/compile/pr79386.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr79386.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cprop.c
trunk/gcc/testsuite/ChangeLog

[Bug c/79412] [5/6/7 Regression] ICE in fold_convert_loc, at fold-const.c:2239

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Likely started with r193882.

[Bug c/79412] [5/6/7 Regression] ICE in fold_convert_loc, at fold-const.c:2239

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|ICE in fold_convert_loc, at |[5/6/7 Regression] ICE in
   |fold-const.c:2239   |fold_convert_loc, at
   ||fold-const.c:2239
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  GCC 4.7 doesn't ICE.

[Bug c++/42000] missing -Wuninitialized warning on a user-defined class ctor

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
With the top of trunk (GCC 7) the test case in comment #0 isn't diagnosed with
-O2 or at any other optimization level.

I suspect this does fall under one of the existing -Wuninitialized bugs.  I'm
not sure bug 2972 covers this case.  Just quickly eyeballing the patch in bug
19808, I don't think it's meant to detect this problem either since it's
front-end only solution focused solely on dependencies between members in ctor
initializer lists.

I'll confirm this for now and if someone finds a pre-existing duplicate it can
be closed then.

[Bug bootstrap/42176] bootstrap fails while building libstdc++-v3 on debian sarge (related to cstdio and similar to #30915)

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Bug 30915 is similar, and the problem was related to gentoo-specific patches to
glibc. Possibly caused by A mismatched combination of libstdc++ and glibc.

I've never been able to reproduce it, and I don't think it's a GCC problem, so
I agree with closing this. Thanks, Martin.

[Bug c/79413] New: ICE in make_ssa_name_fn, at tree-ssanames.c:265

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

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

Bug ID: 79413
   Summary: ICE in make_ssa_name_fn, at tree-ssanames.c:265
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Seen with test-version 7 at -Os, -O2 or higher :


$ cat z1.c
void fn1 ()
{
  typeof (int [1/0]) a;
}
void fn2 ()
{
  fn1();
}


$ gcc-6 -O2 -c z1.c
$ gcc-7-20170205 -O1 -c z1.c
$ gcc-7-20170205 -O2 -c z1.c
z1.c: In function 'fn2':
z1.c:7:3: internal compiler error: Segmentation fault
   fn1();
   ^
0xbf633f crash_signal
../../gcc/toplev.c:333
0xe150aa make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int)
../../gcc/tree-ssanames.c:265
0xc704d6 make_ssa_name
../../gcc/tree-ssanames.h:113
0xc704d6 remap_ssa_name
../../gcc/tree-inline.c:238
0xc76d1c copy_tree_body_r(tree_node**, int*, void*)
../../gcc/tree-inline.c:1081
0xec walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11796
0xec2676 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:12113
0xc6eba0 remap_type_1
../../gcc/tree-inline.c:565
0xc6fac1 remap_type(tree_node*, copy_body_data*)
../../gcc/tree-inline.c:593
0xc6e456 remap_decl(tree_node*, copy_body_data*)
../../gcc/tree-inline.c:370
0xc6fbfd remap_decls
../../gcc/tree-inline.c:642
0xc70e60 remap_block
../../gcc/tree-inline.c:700
0xc70fa1 remap_blocks
../../gcc/tree-inline.c:721
0xc79823 expand_call_inline
../../gcc/tree-inline.c:4617
0xc7b834 gimple_expand_calls_inline
../../gcc/tree-inline.c:4868
0xc7b834 optimize_inline_calls(tree_node*)
../../gcc/tree-inline.c:5008
0x1323321 early_inliner(function*)
../../gcc/ipa-inline.c:2721

[Bug c/79412] New: ICE in fold_convert_loc, at fold-const.c:2239

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

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

Bug ID: 79412
   Summary: ICE in fold_convert_loc, at fold-const.c:2239
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With invalid code down to at least gcc 4.8 (configured with
--enable-checking=yes) on x86_64 GNU/Linux.
(official releases: confused by earlier errors, bailing out)


$ cat z1.c
int a;
void fn1 ()
{
  a++;
}
int a[] = {2};


$ gcc-7-20170205 -c z1.c
z1.c:6:5: error: conflicting types for 'a'
 int a[] = {2};
 ^
z1.c:1:5: note: previous declaration of 'a' was here
 int a;
 ^
z1.c: In function 'fn1':
z1.c:4:4: internal compiler error: in fold_convert_loc, at fold-const.c:2239
   a++;
   ~^~
0x90910f fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2238
0x97abe8 gimplify_self_mod_expr(tree_node**, gimple**, gimple**, bool,
tree_node*)
../../gcc/gimplify.c:2966
0x973f70 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11135
0x9773e6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6478
0x9786cd gimplify_bind_expr
../../gcc/gimplify.c:1290
0x9745ba gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11402
0x9773e6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6478
0x9793b9 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:12396
0x979a54 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:12554
0x7f17c7 cgraph_node::analyze()
../../gcc/cgraphunit.c:655
0x7f4ce3 analyze_functions
../../gcc/cgraphunit.c:1116
0x7f5a3a symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2597

[Bug c/79411] New: ICE: SSA corruption (fail_abnormal_edge_coalesce)

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

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

Bug ID: 79411
   Summary: ICE: SSA corruption (fail_abnormal_edge_coalesce)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With a modified test pr57026.c at -Os, -O1 or above, down to gcc 4.9 :


$ cat z1.c
typedef struct __jmp_buf_tag { char buf[1024]; } jmp_buf[1];
extern int setjmp (jmp_buf);
extern int bar (unsigned int *);
extern jmp_buf *baz (void);
struct C { int c1; unsigned int c2, c3, c4; };
void
foo (struct C *x, const int *y, unsigned int *z, unsigned int e, unsigned int
g)
{
  unsigned int d = 0;
  unsigned long f;
  setjmp (*baz ());
  f = 1 + d;
  if ((x->c1 || x->c2) && g && (!e || d >= 8))
d = 16;
  else
d = 8;
  if ((!x->c3 && !x->c4 || *y == 0) && !e && bar (z))
*z = 1 + f;
}


$ gcc-7-20170205 -O2 -c z1.c

Unable to coalesce ssa_names 12 and 13 which are marked as MUST COALESCE.
d_12(ab) and  d_13(ab)
z1.c: In function 'foo':
z1.c:7:1: internal compiler error: SSA corruption
 foo (struct C *x, const int *y, unsigned int *z, unsigned int e, unsigned int
g)
 ^~~
0xd152af fail_abnormal_edge_coalesce
../../gcc/tree-ssa-coalesce.c:1010
0xd152af coalesce_partitions
../../gcc/tree-ssa-coalesce.c:1399
0xd152af coalesce_ssa_name()
../../gcc/tree-ssa-coalesce.c:1889
0xca3d03 remove_ssa_form
../../gcc/tree-outof-ssa.c:948
0xca3d03 rewrite_out_of_ssa(ssaexpand*)
../../gcc/tree-outof-ssa.c:1172
0x7bdf30 execute
../../gcc/cfgexpand.c:6164

[Bug c/61342] Segfault when using default clause and VLA in OpenMP task

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

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #1 from Gerhard Steinmetz  
---
Update :


$ gcc-7-20170205 -fopenmp -c pr61342.c
'
In function 'main':
Segmentation fault
 (*f)[i][j] = 1;
 ~~~^~~
0xbf633f crash_signal
../../gcc/toplev.c:333
0x6aa870 c_tree_printer
../../gcc/c/c-objc-common.c:169
0x13df6cf pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:679
0x13d2aa8 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:961
0x13d2e03 diagnostic_impl
../../gcc/diagnostic.c:1084
0x13d36d4 error(char const*, ...)
../../gcc/diagnostic.c:1310
0x96e275 omp_default_clause
../../gcc/gimplify.c:6825
0x96e275 omp_notice_variable
../../gcc/gimplify.c:7118
0x96ee85 gimplify_var_or_parm_decl
../../gcc/gimplify.c:2587
0x97387b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11646
0x972426 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11931
0x97b74c gimplify_compound_lval
../../gcc/gimplify.c:2826
0x972653 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11155
0x985e45 gimplify_modify_expr
../../gcc/gimplify.c:5473
0x9743ca gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11203
0x9773e6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6478
0x9786cd gimplify_bind_expr
../../gcc/gimplify.c:1290
0x9745ba gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11402
0x9773e6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6478
0x975b71 gimplify_and_add(tree_node*, gimple**)
../../gcc/gimplify.c:435

[Bug c/43374] ICE with __builtin_isinf() and _Decimal argument

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

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #5 from Gerhard Steinmetz  
---
Update :


$ gcc-7-20170205 -c pr43374.c
pr43374.c: In function 'func':
pr43374.c:4:10: internal compiler error: in decimal_to_decnumber, at dfp.c:134
   return __builtin_isinf(v);
  ^~
0x12b9f38 decimal_to_decnumber
../../gcc/dfp.c:134
0x12ba0bf encode_decimal32(real_format const*, long*, real_value const*)
../../gcc/dfp.c:161
0xb51d15 real_to_target(long*, real_value const*, format_helper)
../../gcc/real.c:2835
0xbc73bc simplify_immed_subreg
../../gcc/simplify-rtx.c:5824
0xbd3578 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, unsigned
int)
../../gcc/simplify-rtx.c:6260
0x8ba3b5 emit_move_via_integer
../../gcc/expr.c:3301
0x8c7198 emit_move_insn_1(rtx_def*, rtx_def*)
../../gcc/expr.c:3652
0x8c7494 emit_move_insn(rtx_def*, rtx_def*)
../../gcc/expr.c:3738
0x7a1434 emit_library_call_value_1
../../gcc/calls.c:4895
0x7a82af emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, int, ...)
../../gcc/calls.c:5159
0xaf5ab6 prepare_float_lib_cmp
../../gcc/optabs.c:4172
0xaf5ab6 prepare_cmp_insn
../../gcc/optabs.c:3945
0xaf5bf5 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, int)
../../gcc/optabs.c:4051
0x8314cc do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, int)
../../gcc/dojump.c:1145
0x8319e7 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, int)
../../gcc/dojump.c:1140
0x8b6314 emit_store_flag_force(rtx_def*, rtx_code, rtx_def*, rtx_def*,
machine_mode, int, int)
../../gcc/expmed.c:5936
0x8d7cde do_store_flag
../../gcc/expr.c:11453
0x8d7cde expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:9203
0x7b6382 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3676
0x7b6382 expand_gimple_stmt
../../gcc/cfgexpand.c:3737

[Bug c/30552] gcc crashed when compiling an example

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

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

--- Comment #2 from Gerhard Steinmetz  
---
Other test cases :


$ cat z1.c
void f()
{
  void g()
void a[( {void b} )];
}


$ cat z2.c
int f()
{
  int g()
int a[( {int b} )];
}

[Bug c/30552] gcc crashed when compiling an example

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

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #1 from Gerhard Steinmetz  
---
Update :


$ gcc-7-20170205 -c pr30552.c
pr30552.c: In function 'fun':
pr30552.c:6:5: internal compiler error: Segmentation fault
 int a[({void h(){}2;})];
 ^~~
0xbf633f crash_signal
../../gcc/toplev.c:333
0x670701 c_push_function_context()
../../gcc/c/c-decl.c:9504
0x6cf8a2 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2038
0x6d3ea2 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:4831
0x6af37a c_parser_postfix_expression
../../gcc/c/c-parser.c:7665
0x6b939a c_parser_unary_expression
../../gcc/c/c-parser.c:7052
0x6ba1a7 c_parser_cast_expression
../../gcc/c/c-parser.c:6881
0x6ba3c2 c_parser_binary_expression
../../gcc/c/c-parser.c:6690
0x6bb0a5 c_parser_conditional_expression
../../gcc/c/c-parser.c:6458
0x6bb800 c_parser_expr_no_commas
../../gcc/c/c-parser.c:6375
0x6ccebe c_parser_direct_declarator_inner
../../gcc/c/c-parser.c:3591
0x6cea04 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:1797
0x6cf7ce c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2073
0x6d3ea2 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:4831
0x6d44ce c_parser_compound_statement
../../gcc/c/c-parser.c:4740
0x6cf90c c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2112
0x6d791b c_parser_external_declaration
../../gcc/c/c-parser.c:1468
0x6d8379 c_parser_translation_unit
../../gcc/c/c-parser.c:1348
0x6d8379 c_parse_file()
../../gcc/c/c-parser.c:18185
0x736892 c_common_parse_file()
../../gcc/c-family/c-opts.c:1107

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[segher at gcc dot gnu.org]

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

--- Comment #52 from Segher Boessenkool  ---
(In reply to Aldy Hernandez from comment #50)
> Though at this
> point, I'd rather we figure out why the erroneous code is being generated in
> comment 45.

If you can send me the output (.s and .c.*) with -dap I can probably
figure it out.  But please with a cut-down testcase -- this 2.5MB source
file results in 2.5GB of output files.

[Bug preprocessor/42014] Inconsistent column number display for "In file incuded from"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Martin Sebor  ---
Looks like a fix was proposed but the approval was made contingent on getting
some a suite issue sorted out.  Marcin, did you manage to resolve the test
suite issue with David's suggestion?

I'm moving the status to New.

[Bug c++/79410] [6 Regression] internal compiler error: in gimplify_init_ctor_preeval, at gimplify.c:3489

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
No ICE with -std=gnu++11 so maybe related to C++14 constexpr rules.

Similar to Bug 60951.

[Bug c++/79143] [7 Regression][new inheriting constructors] inheriting constructor fails with brace initialization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/79410] New: [6 Regression] internal compiler error: in gimplify_init_ctor_preeval, at gimplify.c:3489

[redi at gcc dot gnu.org]

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

Bug ID: 79410
   Summary: [6 Regression] internal compiler error: in
gimplify_init_ctor_preeval, at gimplify.c:3489
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This gives an ICE with -O1

struct duration {
  long val;
  static constexpr duration max() { return {}; }
};
struct S {
  duration max = duration::max();
};
void Ice(S& s) {
  s = {};
}

ice.cc: In function ‘void Ice(S&)’:
ice.cc:9:9: internal compiler error: in gimplify_init_ctor_preeval, at
gimplify.c:3489
   s = {};
 ^
0x8e5582 gimplify_init_ctor_preeval
../../gcc-6.3.0/gcc/gimplify.c:3489
0x8e5acf gimplify_init_constructor
../../gcc-6.3.0/gcc/gimplify.c:4063
0x8e6421 gimplify_modify_expr_rhs
../../gcc-6.3.0/gcc/gimplify.c:4346
0x8e652f gimplify_modify_expr
../../gcc-6.3.0/gcc/gimplify.c:4683
0x8dcd99 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-6.3.0/gcc/gimplify.c:10386
0x8dfae6 gimplify_stmt(tree_node**, gimple**)
../../gcc-6.3.0/gcc/gimplify.c:5687
0x8dc8d8 gimplify_cleanup_point_expr
../../gcc-6.3.0/gcc/gimplify.c:5463
0x8dc8d8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-6.3.0/gcc/gimplify.c:10751
0x8dfae6 gimplify_stmt(tree_node**, gimple**)
../../gcc-6.3.0/gcc/gimplify.c:5687
0x8e0cac gimplify_body(tree_node*, bool)
../../gcc-6.3.0/gcc/gimplify.c:11532
0x8e1077 gimplify_function_tree(tree_node*)
../../gcc-6.3.0/gcc/gimplify.c:11688
0x7bfd27 cgraph_node::analyze()
../../gcc-6.3.0/gcc/cgraphunit.c:625
0x7c26df analyze_functions
../../gcc-6.3.0/gcc/cgraphunit.c:1086
0x7c2e58 symbol_table::finalize_compilation_unit()
../../gcc-6.3.0/gcc/cgraphunit.c:2542
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug debug/42065] DWARF .debug_macinfo contains unused macros

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
It doesn't look like this has changed between GCC 4.5 and GCC 7 so I'll confirm
it as a missing space optimization.

$ cat t.c && gcc -g3 -Wall -feliminate-unused-debug-symbols
-feliminate-unused-debug-types t.c && readelf -wm a.out | grep -e NOT -e USED
#define NOT used
#define USED(x) x
int main (void) { return USED (0); }
 DW_MACRO_GNU_define_indirect - lineno : 1 macro : NOT used
 DW_MACRO_GNU_define_indirect - lineno : 2 macro : USED(x) x

With GCC 7, even an empty object file contains 345 macro definitions (one for
each macro predefined by GCC):

$ /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -c -g3 -xc -ot.o -

[Bug target/42102] ICE of optimize

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Martin Sebor  ---
Current trunk (GCC 7) configured for the rx-elf target compiles the test case
successfully.  Resolving as fixed. 

$ /build/rx-elf/gcc-trunk/gcc/xgcc -B /build/rx-elf/gcc-trunk/gcc  -S -O2 -v
t.c
Reading specs from /build/rx-elf/gcc-trunk/gcc/specs
COLLECT_GCC=/build/rx-elf/gcc-trunk/gcc/xgcc
Target: rx-elf
Configured with: /src/gcc/trunk/configure --enable-languages=c,c++
--prefix=/build/sysroot/rx-elf --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=rx-elf --without-headers
Thread model: single
gcc version 7.0.1 20170207 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-B' '/build/rx-elf/gcc-trunk/gcc' '-S' '-O2' '-v'
 /build/rx-elf/gcc-trunk/gcc/cc1 -quiet -v -iprefix
/home/msebor/build/rx-elf/gcc-trunk/gcc/../lib/gcc/rx-elf/7.0.1/ -isystem
/build/rx-elf/gcc-trunk/gcc/include -isystem
/build/rx-elf/gcc-trunk/gcc/include-fixed t.c -quiet -dumpbase t.c -auxbase t
-O2 -version -o t.s
GNU C11 (GCC) version 7.0.1 20170207 (experimental) (rx-elf)
compiled by GNU C version 5.3.1 20151207 (Red Hat 5.3.1-2), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
...
#include "..." search starts here:
#include <...> search starts here:
 /build/rx-elf/gcc-trunk/gcc/include
 /build/rx-elf/gcc-trunk/gcc/include-fixed
End of search list.
GNU C11 (GCC) version 7.0.1 20170207 (experimental) (rx-elf)
compiled by GNU C version 5.3.1 20151207 (Red Hat 5.3.1-2), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 982af928627021b9f23f5068d2fd4ae5
t.c: In function ‘pagevec_release’:
t.c:27:6: warning: implicit declaration of function ‘pagevec_count’; did you
mean ‘pagevec_release’? [-Wimplicit-function-declaration]
  if (pagevec_count(pvec))
  ^
  pagevec_release
t.c:28:3: warning: implicit declaration of function ‘__pagevec_release’; did
you mean ‘pagevec_release’? [-Wimplicit-function-declaration]
   __pagevec_release(pvec);
   ^
   pagevec_release
t.c: In function ‘write_cache_pages’:
t.c:52:14: warning: implicit declaration of function ‘pagevec_lookup_tag’
[-Wimplicit-function-declaration]
   nr_pages = pagevec_lookup_tag(, mapping, ,
  ^~
t.c:57:4: warning: implicit declaration of function ‘lock_page’
[-Wimplicit-function-declaration]
lock_page(page);
^
t.c:60:5: warning: implicit declaration of function ‘unlock_page’
[-Wimplicit-function-declaration]
 unlock_page(page);
 ^~~
t.c:64:9: warning: implicit declaration of function ‘clear_page_dirty_for_io’
[-Wimplicit-function-declaration]
if (!clear_page_dirty_for_io(page))
 ^~~
t.c:67:28: warning: implicit declaration of function ‘bdi_write_congested’
[-Wimplicit-function-declaration]
if (wbc->nonblocking && bdi_write_congested(bdi)) {
^~~
COMPILER_PATH=/build/rx-elf/gcc-trunk/gcc/
LIBRARY_PATH=/build/rx-elf/gcc-trunk/gcc/
COLLECT_GCC_OPTIONS='-B' '/build/rx-elf/gcc-trunk/gcc' '-S' '-O2' '-v'

[Bug driver/42106] Simplistic build works, then fails to find cc1plus on its own

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Martin Sebor  ---
There isn't enough information here to tell what may have been the problem but
current Solaris test results show no such failures with recent versions of GCC:

https://gcc.gnu.org/ml/gcc-testresults/2017-02/msg00616.html

Since GCC 4.3 is no lo longer maintained I'm closing this report.  Please open
a new bug if the problem persists with the current GCC.

[Bug bootstrap/42176] bootstrap fails while building libstdc++-v3 on debian sarge (related to cstdio and similar to #30915)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #4 from Martin Sebor  ---
The most recent test results for the oldest Debian I could find are for 5.4.1:
https://gcc.gnu.org/ml/gcc-testresults/2017-02/msg00656.html.  Since those are
successful (as are other Debian test results) and since GCC 4.4 is no longer
maintained I'll close this.  Please open a new bug if the problems persist with
recent versions of GCC.

[Bug tree-optimization/79409] New: [7 Regression] [graphite] ICE in outermost_loop_in_sese, at sese.c:300 w/ -fgraphite-identity -ftree-loop-distribution -O1 (or above)

[asolokha at gmx dot com]

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

Bug ID: 79409
   Summary: [7 Regression] [graphite] ICE in
outermost_loop_in_sese, at sese.c:300 w/
-fgraphite-identity -ftree-loop-distribution -O1 (or
above)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-7.0.0-alpha20170205 snapshot ICEs when compiling the following snippet w/
-O1 (-O2, -O3, -Ofast) -fgraphite-identity -ftree-loop-distribution:

struct
{
  int bz;
} od, ka[2];
int fw;

void
pc (void)
{
  for (od.bz = 0; od.bz < 2; ++od.bz)
{
  ++fw;
  ka[0] = ka[1];
}
}

% gcc-7.0.0-alpha20170205 -O1 -fgraphite-identity -ftree-loop-distribution -c
ady9pcky.c
ady9pcky.c: In function 'pc':
ady9pcky.c:8:1: internal compiler error: in outermost_loop_in_sese, at
sese.c:300
 pc (void)
 ^~

[Bug c++/79143] [7 Regression][new inheriting constructors] inheriting constructor fails with brace initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
I think this is a bug. derived is not an aggregate, because it inherits a
user-provided constructor, so braced-init should call the base(int, int)
constructor, not attempt aggregate init.

[Bug c++/79143] [7 Regression][new inheriting constructors] inheriting constructor fails with brace initialization

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Yeah, found the same in the mean time.
Following works, I bet in the #c0 CLASSTYPE_NON_AGGREGATE isn't set on derived
for some reason.

struct base {
  base(int, int) {}
};

template
struct derived : base {
  derived(int, int) : base(0, 0) {}
};

int main() {
  base(13, 42); // Fine
  derived(13, 42); // Fine
  base{13, 42}; // Fine
  derived{13, 42}; // Fine
}

[Bug c++/79143] [7 Regression][new inheriting constructors] inheriting constructor fails with brace initialization

[Casey at Carter dot net]

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

Casey Carter  changed:

   What|Removed |Added

 CC||Casey at Carter dot net

--- Comment #4 from Casey Carter  ---
(In reply to Jonathan Wakely from comment #3)
> I think this is a bug. derived is not an aggregate, because it inherits a
> user-provided constructor, so braced-init should call the base(int, int)
> constructor, not attempt aggregate init.

This. N4618 [dcl.init.aggr]/1 says:

1 An aggregate is an array or a class with

  1.1 --- no user-provided, explicit, or inherited constructors

  [...]

[Bug libgomp/42125] check libgomp fails

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Martin Sebor  ---
The latest Cygwin test results reported for GCC 6.4.1 show only a handful of
libgomp failures
(https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg02442.html).  Since this
report is older than 7 years, never been confirmed, and GCC 4.4 is not
supported anymore I'm closing it.

[Bug c++/79143] [7 Regression][new inheriting constructors] inheriting constructor fails with brace initialization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Fails since r241187, aka http://wg21.link/p0017
Jonathan, is it rejected correctly after P0017R1 or not?

[Bug rtl-optimization/79149] bad optimization on MIPS and ARM leading to excessive stack usage in some cases

[arnd at linaro dot org]

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

--- Comment #13 from Arnd Bergmann  ---
(In reply to wilco from comment #12)
> Does wp512 use 64-bit types? If so, this is likely PR77308.

Yes, as seen in the attachment it uses lots of 64-bit operations. However, it
sounds like PR77308 is ARM specific, but I see the same behavior
on most other architectures, including 64-bit ones. Quoting the
kernel patch I linked to, with stack frame sizes for the function
depending on architecture, optimization flags and compiler version
(only 4.9 and 7.0 here, there is little difference anyway)

default: -O2
press:   -O2 -fsched-pressure
nopress: -O2 -fschedule-insns -fno-sched-pressure
nosched: -O2 -no-schedule-insns (disables sched-pressure)

default press   nopress nosched
alpha-linux-gcc-4.9.3   1136848 1136176
am33_2.0-linux-gcc-4.9.32100207621002104
arm-linux-gnueabi-gcc-4.9.3 848 848 1048352
cris-linux-gcc-4.9.3272 272 272 272
frv-linux-gcc-4.9.3 112810001128280
hppa64-linux-gcc-4.9.3  1128336 1128184
hppa-linux-gcc-4.9.3644 308 644 276
i386-linux-gcc-4.9.3352 352 352 352
m32r-linux-gcc-4.9.3720 656 720 268
microblaze-linux-gcc-4.9.3  1108604 1108256
mips64-linux-gcc-4.9.3  1328592 1328208
mips-linux-gcc-4.9.31096624 1096240
powerpc64-linux-gcc-4.9.3   1088432 1088160
powerpc-linux-gcc-4.9.3 1080584 1080224
s390-linux-gcc-4.9.3456 456 624 360
sh3-linux-gcc-4.9.3 292 292 292 292
sparc64-linux-gcc-4.9.3 992 240 992 208
sparc-linux-gcc-4.9.3   680 592 680 312
x86_64-linux-gcc-4.9.3  224 240 272 224
xtensa-linux-gcc-4.9.3  1152704 1152304

aarch64-linux-gcc-7.0.0 224 224 1104208
arm-linux-gnueabi-gcc-7.0.1 824 824 1048352
mips-linux-gcc-7.0.01120648 1120272
mips64-linux-gcc-7.0.0  1072608 1072224
x86_64-linux-gcc-7.0.1  240 240 304 240

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[dje at gcc dot gnu.org]

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

--- Comment #51 from David Edelsohn  ---
If you use /scratch for source, build and TMPDIR, as well as

SHELL=/usr/bin/bash CONFIG_SHELL=/usr/bin/bash

it should build faster on AIX.

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[aldyh at gcc dot gnu.org]

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

--- Comment #50 from Aldy Hernandez  ---
(In reply to David Edelsohn from comment #48)
> Based on Comment #45, is this a problem in the Stage 1 compilers?  Note that
> Alan and Segher adjusted the doloop patterns in this release cycle.  Does
> backporting that patch or bootstrapping with current trunk function better?

The stage2 compiler fails to build anything (libgcc in this case) because the
stage1 compiler miscompiled the testcase I posted.

I tried backporting the following two patches to no avail:

commit b2d4fe71855caaae720f7839d3e33b061d2069ca
Author: amodra 
Date:   Sat Jan 14 13:24:46 2017 +

Avoid PR72749 by not using unspecs

Rather than using unspecs in doloop insns to stop combine creating
these insns, use legitimate_combined_insn.

PR target/72749
* combine.c (recog_for_combine_1): Set INSN_CODE before calling
target legitimate_combined_insn.
* config/rs6000/rs6000.c (TARGET_LEGITIMATE_COMBINED_INSN): Define.
(rs6000_legitimate_combined_insn): New function.
* config/rs6000/rs6000.md (UNSPEC_DOLOOP): Delete, and remove
all uses.
(ctr_internal3): Rename from *ctr_internal5.
(ctr_internal4): Rename from *ctr_internal6.
(ctr_internal1, ctr_internal2): Remove '*' from name.

commit d7a73763f9dfa9cec35bcf40d926ee03ae85fb2d
Author: amodra 
Date:   Mon Jul 11 10:28:48 2016 +

[RS6000] Don't allow combine to form doloop pattern

* config/rs6000/rs6000.md (UNSPEC_DOLOOP): New unspec.
(ctr): Add unspec.
(ctr_internal*): Likewise.

And yes, I'm sure bootstrapping the current trunk would work, but that would
have us back at square one, having no idea why the patch in question is now
bootstrapping ;-).

I suppose we could remove Richi's patch that makes the problem disappear, and
bisect forward to see if there's another set of patches that also fix the
problem but are related to doloop or the patch at hand.  Though at this point,
I'd rather we figure out why the erroneous code is being generated in comment
45.  Bisecting AIX and the hand-holding required takes a good hour and a half
at each of the 13 iterations it would at least take.

[Bug target/79299] [7 Regression] Operand size mismatch for `vpgatherqd' w/ -O3 -masm=intel -mavx512bw

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/79299] [7 Regression] Operand size mismatch for `vpgatherqd' w/ -O3 -masm=intel -mavx512bw

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb  7 15:42:42 2017
New Revision: 245248

URL: https://gcc.gnu.org/viewcvs?rev=245248=gcc=rev
Log:
PR target/79299
* config/i386/sse.md (xtg_mode, gatherq_mode): New mode attrs.
(*avx512f_gathersi, *avx512f_gathersi_2,
*avx512f_gatherdi, *avx512f_gatherdi_2): Use them,
fix -masm=intel patterns.

* gcc.target/i386/avx512vl-pr79299-1.c: New test.
* gcc.target/i386/avx512vl-pr79299-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr79299-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr79299-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/79149] bad optimization on MIPS and ARM leading to excessive stack usage in some cases

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #12 from wilco at gcc dot gnu.org ---
Does wp512 use 64-bit types? If so, this is likely PR77308.