[Bug middle-end/79521] [7 Regression] Bootstrap failure on i686-linux starting with r245436

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #6 from Jeffrey A. Law  ---
Fixed on trunk.

[Bug middle-end/79521] [7 Regression] Bootstrap failure on i686-linux starting with r245436

[law at gcc dot gnu.org]

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

--- Comment #5 from Jeffrey A. Law  ---
Author: law
Date: Thu Feb 16 06:35:29 2017
New Revision: 245500

URL: https://gcc.gnu.org/viewcvs?rev=245500=gcc=rev
Log:
PR middle-end/79521
* ira-costs.c (scan_one_insn): Check have_regs_of_mode before calling
ira_init_register_move_cost_if_necessary.

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

[Bug libfortran/79540] [7 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
Possibly due to r240018 which is fix for pr77393.

[Bug c++/79550] New: ICE in tsubst, at cp/pt.c:13474 with partial specialization of auto... template parameter pack

[rs2740 at gmail dot com]

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

Bug ID: 79550
   Summary: ICE in tsubst, at cp/pt.c:13474 with partial
specialization of auto... template parameter pack
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

template 
struct meow;

template 
struct meow { };

template struct meow<1>;

prog.cc: In substitution of 'template struct meow [with auto C =
1]':
prog.cc:7:17:   required from here
prog.cc:7:17: internal compiler error: in tsubst, at cp/pt.c:13474
 template struct meow<1>;
 ^~~
0x5d6a8c tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13474
0x5df37c tsubst_template_args
../../source/gcc/cp/pt.c:11638
0x5d5d5b tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13695
0x5d49f7 get_partial_spec_bindings
../../source/gcc/cp/pt.c:21511
0x5d4cbd most_specialized_partial_spec
../../source/gcc/cp/pt.c:21741
0x5ef83b instantiate_class_template_1
../../source/gcc/cp/pt.c:10183
0x5ef83b instantiate_class_template(tree_node*)
../../source/gcc/cp/pt.c:10751
0x652235 complete_type(tree_node*)
../../source/gcc/cp/typeck.c:133
0x5ead7b do_type_instantiation(tree_node*, tree_node*, int)
../../source/gcc/cp/pt.c:22011
0x64661f cp_parser_explicit_instantiation
../../source/gcc/cp/parser.c:16210
0x627581 cp_parser_declaration
../../source/gcc/cp/parser.c:12467
0x64d05b cp_parser_declaration_seq_opt
../../source/gcc/cp/parser.c:12391
0x64d342 cp_parser_translation_unit
../../source/gcc/cp/parser.c:4366
0x64d342 c_parse_file()
../../source/gcc/cp/parser.c:38425
0x71b2a3 c_common_parse_file()
../../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.

[Bug c++/79549] New: ICE in tsubst, at cp/pt.c:13474 with partial specialization of auto... template parameter pack

[rs2740 at gmail dot com]

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

Bug ID: 79549
   Summary: ICE in tsubst, at cp/pt.c:13474 with partial
specialization of auto... template parameter pack
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

template 
struct meow;

template 
struct meow { };

template struct meow<1>;

prog.cc: In substitution of 'template struct meow [with auto C =
1]':
prog.cc:7:17:   required from here
prog.cc:7:17: internal compiler error: in tsubst, at cp/pt.c:13474
 template struct meow<1>;
 ^~~
0x5d6a8c tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13474
0x5df37c tsubst_template_args
../../source/gcc/cp/pt.c:11638
0x5d5d5b tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13695
0x5d49f7 get_partial_spec_bindings
../../source/gcc/cp/pt.c:21511
0x5d4cbd most_specialized_partial_spec
../../source/gcc/cp/pt.c:21741
0x5ef83b instantiate_class_template_1
../../source/gcc/cp/pt.c:10183
0x5ef83b instantiate_class_template(tree_node*)
../../source/gcc/cp/pt.c:10751
0x652235 complete_type(tree_node*)
../../source/gcc/cp/typeck.c:133
0x5ead7b do_type_instantiation(tree_node*, tree_node*, int)
../../source/gcc/cp/pt.c:22011
0x64661f cp_parser_explicit_instantiation
../../source/gcc/cp/parser.c:16210
0x627581 cp_parser_declaration
../../source/gcc/cp/parser.c:12467
0x64d05b cp_parser_declaration_seq_opt
../../source/gcc/cp/parser.c:12391
0x64d342 cp_parser_translation_unit
../../source/gcc/cp/parser.c:4366
0x64d342 c_parse_file()
../../source/gcc/cp/parser.c:38425
0x71b2a3 c_common_parse_file()
../../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.

[Bug c/68971] -Woverflow false alarm in code unreachable after __builtin_mul_overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #13 from Martin Sebor  ---
Thanks.  You are correct, that was the case in my original patch for bug 68120
but it ended up morphing into the _p built-ins (not by my choice).

Resolving as fixed by r237238.

[Bug libstdc++/58909] C++11's condition variables fail with static linking

[joel at clambassador dot com]

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

joel at clambassador dot com changed:

   What|Removed |Added

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

--- Comment #9 from joel at clambassador dot com ---
Wow, I had completely forgotten about the time I spent puzzled over this
behaviour in 2013.

I'm guessing that just the existence of this as a bug report for 'condition
variables static linking' is sufficient documentation for the rare time it
happens for people. As such I'll note that my unpleasant fix was to include
this in a header:

void pthread_cond_bug() {
pthread_cond_signal((pthread_cond_t *) nullptr);
pthread_cond_init((pthread_cond_t *) nullptr,
  (const pthread_condattr_t *) nullptr);
pthread_cond_destroy((pthread_cond_t *) nullptr);
pthread_cond_timedwait((pthread_cond_t *) nullptr, (pthread_mutex_t *)
   nullptr, (const struct timespec *) nullptr);
pthread_cond_wait((pthread_cond_t *) nullptr, (pthread_mutex_t *)
(nullptr);
}

without actually ever calling it; iirc it links in the functions as a result.

[Bug middle-end/60488] missing uninitialized warning (address taken, VOP)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
  Known to fail||4.8.3, 4.9.3, 5.3.0, 6.2.0,
   ||7.0

--- Comment #4 from Martin Sebor  ---
You're right that the goto isn't essential here.  The same problem can be
demonstrated in the simplified test case below.  When f() && f() evaluates
to true (and assuming f() initializes what it points to) there "exists a path
from the function entry to a use of the variable that is initialized."  But
f() evaluates to false f() is not called then "there exists a path for
which b is not initialized."  Since there is no way to prove that the second
path is not taken at runtime then, according to the documentation, GCC should
emit a warning.  However, no warning is issued.

int f (int*);

int foo (void)
{
  int a, b;

  if (f () && f ())
return 0;

  return a + b;
}

[Bug c++/60068] missing diagnostic on array with negative bounds in template

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-16
 Ever confirmed|0   |1
  Known to fail||4.8.3, 4.9.3, 5.3.0, 6.2.0,
   ||7.0

--- Comment #1 from Martin Sebor  ---
No change in GCC 7.0.  Clang 5.0, EDG eccp 4.11, and Oracle CC 5.13 all reject
the code.  Thus confirmed.

[Bug c++/60063] [5/6/7 Regression] -Wunused-local-typedefs warning despite attribute used in a template

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-16
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79548
Summary|-Wunused-local-typedefs |[5/6/7 Regression]
   |warning despite attribute   |-Wunused-local-typedefs
   |used in a template  |warning despite attribute
   ||used in a template
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
No change in GCC 7.  The -Wunused-local-typedefs warning is still issued
inconsistently.  The warning on the template is a regression from GCC 4.6 most
likely introduced in r187757, along with bug 79548.

$ cat u.C && gcc -S -Wall -Wextra -Wpedantic -Wunused u.C
void foo ()
{
typedef __attribute__ ((used)) int T;
}

template 
void bar ()
{
  typedef __attribute__ ((used)) T U;
}
u.C: In function ‘void bar()’:
u.C:9:36: warning: typedef ‘U’ locally defined but not used
[-Wunused-local-typedefs]
   typedef __attribute__ ((used)) T U;
^

[Bug c/68971] -Woverflow false alarm in code unreachable after __builtin_mul_overflow

[eggert at gnu dot org]

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

--- Comment #12 from Paul Eggert  ---
Ah, sorry, I am using GCC 6.3.1, whereas __builtin_mul_overflow_p is a GCC
7-ism.  Somehow I got it into my head that __builtin_mul_overflow(A,B,C) should
be a constant expression if A, B, are constant expressions and C is a
(constant) null pointer, but evidently that's not the case. Since the problem
must be fixed in GCC 7 with its new __builtin_mul_overflow_p primitive, please
close this bug.

[Bug c++/79548] [5/6/7 Regression] missing -Wunused-variable on a typedef'd variable in a function template

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=33255
Summary|missing -Wunused-variable   |[5/6/7 Regression] missing
   |on a typedef'd variable in  |-Wunused-variable on a
   |a function template |typedef'd variable in a
   ||function template

--- Comment #1 from Martin Sebor  ---
This a regression introduced in GCC 4.7, most likely r178692 (my bisection
points to r178694 because I don't have access to the other binary, but that
seems less likely).

[Bug c++/79548] New: missing -Wunused-variable on a typedef'd variable in a function template

[msebor at gcc dot gnu.org]

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

Bug ID: 79548
   Summary: missing -Wunused-variable on a typedef'd variable in a
function template
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC diagnoses the unused local variable in function f() below but misses the
unused variable in the explicitly instantiated template g():

$ cat u.C && gcc -S -Wall -Wextra -Wpedantic -Wunused u.C
void f ()
{
  typedef int T;
  T t;   // warning, ok
}

template 
void g ()
{
  T t;   // warning, ok

  typedef T U;
  U u;   // no warning, bug
}

template void g();
u.C: In function ‘void f()’:
u.C:4:5: warning: unused variable ‘t’ [-Wunused-variable]
   T t;   // warning, ok
 ^
u.C: In instantiation of ‘void g() [with T = int]’:
u.C:16:22:   required from here
u.C:10:5: warning: unused variable ‘t’ [-Wunused-variable]
   T t;   // warning, ok
 ^

[Bug c/59220] bogus warning: packed attribute is unnecessary on an overaligned char

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-16
 Ever confirmed|0   |1
  Known to fail||4.8.3, 4.9.3, 5.3.0, 6.2.0,
   ||7.0

--- Comment #1 from Martin Sebor  ---
Confirming my own bug with today's top of trunk (GCC 7.0).

[Bug c++/44648] missing -Wunused warning on a const variable in if statement

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||5.3.0, 6.3.0, 7.0

--- Comment #5 from Martin Sebor  ---
Today's trunk warns on three out of the four cases, missing just the 'if (const
bool b2 = 1)' conditional.

$ cat t.C && gcc -Wall -Wextra -Wpedantic t.C
int main()
{
  bool b0 = 1;   // { dg-warning "" }
  const bool b00 = 1;// { dg-warning "" }
  if (bool b1 = 1)   // { dg-warning "" }
return 0;
  else
return 1;

  if (const bool b2 = 1) // { dg-warning "" }
return 0;
  else
return 1;
}
t.C: In function ‘int main()’:
t.C:5:12: warning: unused variable ‘b1’ [-Wunused-variable]
   if (bool b1 = 1)   // { dg-warning "" }
^~
t.C:3:8: warning: unused variable ‘b0’ [-Wunused-variable]
   bool b0 = 1;   // { dg-warning "" }
^~
t.C:4:14: warning: unused variable ‘b00’ [-Wunused-variable]
   const bool b00 = 1;// { dg-warning "" }
  ^~~

[Bug libfortran/79540] [7 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net ---
I see failure in r240386 (20160923).  r239642 and 239726 were okay.

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

[Bug c++/40261] confusing diagnostic on ill-formed template definition

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2009-08-25 15:42:13 |2017-2-15
  Known to fail||4.4.0, 5.3.0, 6.3.0, 7.0

--- Comment #2 from Martin Sebor  ---
No change in GCC 7.  For reference, other compilers print:

Clang 5.0:
t.C:4:31: error: nested name specifier 'B::' for declaration does not refer
  into a class, class template or class template partial specialization
template  void B::foo () { }
~~^

EDG eccp 4.11:
"t.C", line 4: error: template argument list must match the parameter list
  template  void B::foo () { }
  ^
Oracle CC:
"t.C", line 4: Error: Cannot define member of undefined specialization "B".
1 Error(s) detected.

IBM XLC++:
"t.C", line 4.25: 1540-0708 (S) The template argument 2 does not match the
corresponding template parameter of "template struct B".

[Bug libfortran/79540] [7 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-02-16
 Ever confirmed|0   |1

[Bug c/35503] Warning about restricted pointers?

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
*** Bug 29465 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/30334] [meta-bug] Request for -Wundefined

[msebor at gcc dot gnu.org]

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

Bug 29465 Summary: warning for overlapping memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29465

   What|Removed |Added

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

[Bug c/29465] warning for overlapping memcpy()

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
The -Wrestrict warning (new in GCC 7) points out this bug.  Unfortunately, the
option is not in -Wall or -Wextra and must be explicitly enabled so few users
will benefit from it.

$ gcc -S -Wrestrict t.c
t.c: In function ‘main’:
t.c:6:13: warning: passing argument 1 to restrict-qualified parameter aliases
with argument 2 [-Wrestrict]
 memcpy (, , sizeof i);
 ^~  ~~

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

[Bug c++/71093] use of pseudo-destructor accepted in constant expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Setting Status to Confirmed per comment #1.

[Bug tree-optimization/79547] duplicate strlen calls with same argument not folded

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Most likely the alias analysis thinks s escapes such that f touches it.

Look at the alias dump and also add -vops to the dump option.

[Bug middle-end/71315] missing strlen optimization on a POINTER_PLUS expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79547
 Resolution|--- |FIXED

--- Comment #5 from Martin Sebor  ---
Resolving the original bug as fixed.  I've raised bug 79547 for the problem
pointed out in comment #3.

[Bug libfortran/79540] [7 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #2 from Jerry DeLisle  ---

Do you have any idea when the last time this test passed on this platform?

[Bug tree-optimization/79547] New: duplicate strlen calls with same argument not folded

[msebor at gcc dot gnu.org]

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

Bug ID: 79547
   Summary: duplicate strlen calls with same argument not folded
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As mentioned in bug 71315 comment 3, GCC folds the first of a series of calls
to strlen with the same argument but not the subsequent ones:

$ cat t.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout t.c
void f (unsigned);

void f1 (void)
{
char s[] = "1234";

f (__builtin_strlen (s));
}

void f2 (void)
{
char s[] = "1234";

f (__builtin_strlen (s));
f (__builtin_strlen (s));
}


void f3 (void)
{
char s[] = "1234";

f (__builtin_strlen (s));
f (__builtin_strlen (s));
f (__builtin_strlen (s));
}


;; Function f1 (f1, funcdef_no=0, decl_uid=1797, cgraph_uid=0, symbol_order=0)

f1 ()
{
  char s[5];

   [100.00%]:
  s = "1234";
  f (4);
  s ={v} {CLOBBER};
  return;

}



;; Function f2 (f2, funcdef_no=1, decl_uid=1801, cgraph_uid=1, symbol_order=1)

f2 ()
{
  char s[5];
  long unsigned int _3;
  unsigned int _4;

   [100.00%]:
  s = "1234";
  f (4);
  _3 = __builtin_strlen ();
  _4 = (unsigned int) _3;
  f (_4);
  s ={v} {CLOBBER};
  return;

}



;; Function f3 (f3, funcdef_no=2, decl_uid=1805, cgraph_uid=2, symbol_order=2)

f3 ()
{
  char s[5];
  long unsigned int _3;
  unsigned int _4;
  long unsigned int _5;
  unsigned int _6;

   [100.00%]:
  s = "1234";
  f (4);
  _3 = __builtin_strlen ();
  _4 = (unsigned int) _3;
  f (_4);
  _5 = __builtin_strlen ();
  _6 = (unsigned int) _5;
  f (_6);
  s ={v} {CLOBBER};
  return;

}

[Bug c++/55004] [meta-bug] constexpr issues

[msebor at gcc dot gnu.org]

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

Bug 71391 Summary: error on aggregate initialization with side-effects in a 
constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71391

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/71391] error on aggregate initialization with side-effects in a constexpr function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
  Known to fail|7.0 |

--- Comment #1 from Martin Sebor  ---
This appears to have been fixed in r224381 (gcc 6.0.0):

r224381 | jason | 2015-06-11 11:45:01 -0400 (Thu, 11 Jun 2015) | 3 lines

PR c++/66450
* constexpr.c (cxx_eval_store_expression): Avoid messing up outer
ctx->ctor.

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

[Bug c++/66450] [5 Regression][C++11][constexpr] Issues when delegating implicit copy constructor in constexpr function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
*** Bug 71391 has been marked as a duplicate of this bug. ***

[Bug c/68971] -Woverflow false alarm in code unreachable after __builtin_mul_overflow

[msebor at gcc dot gnu.org]

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

--- Comment #11 from Martin Sebor  ---
Right.  Because the call to __builtin_mul_overflow in the test case is not a
constant expression, the -Woverflow warning detects the overflow in the
multiplication subexpression that is constant.  The __builtin_mul_overflow call
is evaluated into a constant but not until after the warning has detected the
overflow.

The patch for bug 68120 introduced other built-ins to determine overflow at
compile-time.  Using those the return statement in this test case would look
something like this:

return __builtin_mul_overflow_p (0x7fff, 0x7fff, 0)
   ? 2 : (0x7fff * 0x7fff == 0x7fff * 0x7fff);

and compile with no warning.

[Bug libstdc++/79522] std::regex_match always returns false

[jmichae3 at yahoo dot com]

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

Jim Michaels  changed:

   What|Removed |Added

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

--- Comment #3 from Jim Michaels  ---
(In reply to Jonathan Wakely from comment #2)
> You did get them swapped. Obviously the regex "abcdefg" can't match "def".
> 
> But even in your second example the behaviour is correct, std::regex_match
> matches the entire string, not any part of it. "def" doesn't match "abcdefg"
> it only matches part of it. Use std::regex_search for that.
> 
> (And "I don't know how C++ works" is still not a bug)

that was a lam, not a response.
this is a valid bug in at least comment #2. UNLESS in a regex /regex/ is
required. that I did not try. so let's try it. different regexes have different
requirements. some you have to just have 2 of the same character at both ends.
I am not some programming dweeb. yeah, I get stuff wrong sometimes, oftentimes
in fact, but I like my code as good as I can get it. and std::regex_match is
supposed to return a bool, which in iostream just comes out as a 0 or 1 I found
out.  so it's great for test rigs. (think: autoconf for fun?)

the documentation does not spell out such a syntax as /regex/.
there is probably a bug in the regex state machine, because it's failing 100%
of the time in my tests. what about your tests? did you apply any?

std::regex should be SO EASY to use. this should have been a no-brainer. I used
a manual.

so here is test#3:

#include 
#include 
int main(void) {
std::cout<<"none of these should fail."<ut
none of these should fail.
test 1 failed
test 2 failed
test 3 failed
test 4 failed

 Wed 02/15/2017 15:53:24.12 L:\projects\find\1.0\win>

[Bug c++/55004] [meta-bug] constexpr issues

[msebor at gcc dot gnu.org]

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

Bug 71459 Summary: ICE writing to a string-initialized local array in a 
constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71459

   What|Removed |Added

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

[Bug c++/71459] ICE writing to a string-initialized local array in a constexpr function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
The ICE was removed in r243448 (gcc 7.0.0):

r243448 | nathan | 2016-12-08 13:34:04 -0500 (Thu, 08 Dec 2016) | 9 lines

PR c++/78551
* constexpr.c (extract_string_elt): New.  Broken out of ...
(cxx_eval_array_reference): ... here.  Call it.
(cxx_eval_store_expression): Convert init by STRING_CST into
CONSTRUCTOR, if needed.

[Bug c/68971] -Woverflow false alarm in code unreachable after __builtin_mul_overflow

[eggert at gnu dot org]

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

--- Comment #10 from Paul Eggert  ---
Unfortunately, the patch for Bug#68120 does not seem to have addressed the
problem here. For example, although the following code uses the new feature
enabled by that patch:

  int f (void) {
return (__builtin_mul_overflow (0x7fff, 0x7fff, (int *) 0)
? 2
: 0x7fff * 0x7fff);
  }

I still get the following warning with GCC 6.3.1 20161221 (Red Hat 6.3.1-1)
x86-64:

t.c: In function ‘f’:
t.c:4:19: warning: integer overflow in expression [-Woverflow]
  : 0x7fff * 0x7fff);
   ^

[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[msebor at gcc dot gnu.org]

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

--- Comment #21 from Martin Sebor  ---
*** Bug 71457 has been marked as a duplicate of this bug. ***

[Bug c++/71457] valid pointer plus conversion to bool rejected in constexpr context

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Sebor  ---
Looks like this was fixed in r244333 (gcc 7.0.0):

r244333 | jakub | 2017-01-11 15:10:36 -0500 (Wed, 11 Jan 2017) | 8 lines

PR c++/71537
* fold-const.c (maybe_nonzero_address): Return 1 for function
local objects.
(tree_single_nonzero_warnv_p): Don't handle function local objects
here.

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

[Bug c++/55004] [meta-bug] constexpr issues

[msebor at gcc dot gnu.org]

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

Bug 71457 Summary: valid pointer plus conversion to bool rejected in constexpr 
context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71457

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c/71479] error on __builtin_add_overflow with bool or enum pointer as last argument

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Wrong dupe id.

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

[Bug c/66938] using bool as destination in overflow checkers

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
*** Bug 71479 has been marked as a duplicate of this bug. ***

[Bug c/71479] error on __builtin_add_overflow with bool or enum pointer as last argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|rejects-valid   |diagnostic
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
  Known to fail|7.0 |

--- Comment #6 from Martin Sebor  ---
Resolving as a dupe of 66943 (the error is correct).

Trunk (GCC 7.0) prints:

t.c: In function ‘f’:
t.c:4:33: error: argument 3 in call to function ‘__builtin_add_overflow’ has
pointer to boolean type
   __builtin_add_overflow (0, 0, );
 ^
t.c:7:33: error: argument 3 in call to function ‘__builtin_add_overflow’ has
pointer to enumerated type
   __builtin_add_overflow (0, 0, );
 ^

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

[Bug c++/66943] GCC warns of Unknown Pragma for OpenMP, even though it support it.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #9 from Martin Sebor  ---
*** Bug 71479 has been marked as a duplicate of this bug. ***

[Bug c/66938] using bool as destination in overflow checkers

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED
  Known to fail||5.3.0, 6.3.0

--- Comment #1 from Martin Sebor  ---
This was fixed in r237754.  Current trunk (GCC 7.0) prints the following
errors:

$ cat t.c && gcc -S -Wall t.c
void f (void)
{
  _Bool b;
  __builtin_add_overflow (0, 0, );

  enum E { e0 } e;
  __builtin_add_overflow (0, 0, );

  char c;
  __builtin_add_overflow (0, 0, );
}
t.c: In function ‘f’:
t.c:4:33: error: argument 3 in call to function ‘__builtin_add_overflow’ has
pointer to boolean type
   __builtin_add_overflow (0, 0, );
 ^
t.c:7:33: error: argument 3 in call to function ‘__builtin_add_overflow’ has
pointer to enumerated type
   __builtin_add_overflow (0, 0, );
 ^

[Bug c/79546] Strange error: missed loop optimization, the loop counter may overflow [-Werror=unsafe-loop-optimizations]

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>-Werror=unsafe-loop-optimizations

That is not enabled by default even with -Werror -W -Wall.

But "missed loop optimization, the loop counter may overflow" is basically
saying if i was an signed integer, the loop counter would overflow in some
cases.  The case depends the value of len.  The only way to fix this would be
rewrite the code so that case would not happen.
The cases where it would happen is len = SIZET_MIN ... SIZET_MIN-0x0FFF (if I
did my math correctly).

[Bug c++/69564] [5/6/7 Regression] lto and/or C++ make scimark2 LU slower

[law at redhat dot com]

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

--- Comment #30 from Jeffrey A. Law  ---
Looking at the dumps, the tests for whether or not to use the vectorized loop
are considerably more complex with LTO with memory references as well when
compared to the non-LTO version.  It's almost as-if the program-wide visibility
provided by LTO has *hidden* redundancies and mucked up the IV analysis.

The first block of the LTO check looks like:

  # ivtmp.66_807 = PHI 
  Aii_206 = MEM[base: A_139, index: ivtmp.66_807, step: 8, offset: 0B];
  _208 = Aii_206 + _765;
  AiiJ_209 = *_208;
  _449 = SOR_size_15 > i_167;
  _763 = (unsigned int) i_167;
  _762 = _686 - _763;
  _444 = _762 > 8;
  _443 = _444 & _449;
  _438 = Aii_206 + _760;
  _433 = _434 >= _438;
  _425 = Aii_206 + _435;
  _424 = _425 >= _429;
  _423 = _424 | _433;
  _422 = _423 & _443;
  if (_422 != 0)
goto ; [80.00%]
  else
goto ; [20.00%]

Compared to the non-LTO block:

  _156 = ivtmp.112_242 + 16;
  _155 = prephitmp_168 + _156;
  _151 = Aii_72 + ivtmp.112_242;
  _150 = _151 >= _155;
  _146 = Aii_72 + _156;
  _142 = prephitmp_168 + ivtmp.112_242;
  _141 = _142 >= _146;
  _140 = _141 | _150;
  _139 = _140 & _160;
  if (_139 != 0)
goto ;
  else
goto ;


Then the next block in the check (LTO):

;;   basic block 57, loop depth 3, count 0, freq 66, maybe hot
;;prev block 56, next block 58, flags: (NEW, REACHABLE, VISITED)
;;pred:   56 [80.0%]  (TRUE_VALUE,EXECUTABLE)
  niters.2_408 = SOR_size_15 > i_167 ? _762 : 1;
  _366 = (unsigned long) _425;
  _365 = _366 >> 3;
  _364 = -_365;
  _363 = (unsigned int) _364;
  prolog_loop_niters.4_367 = _363 & 1;
  _740 = (unsigned int) ivtmp.86_769;
  _509 = _686 + 4294967294;
  _738 = _509 - _740;
  _295 = SOR_size_15 > i_167 ? _738 : 0;
  _283 = prolog_loop_niters.4_367 == 0 ? 1 : 2;
  if (_283 > _295)
goto ; [10.00%]
  else
goto ; [90.00%]


non-LTO:

;;   basic block 23, loop depth 2, count 0, freq 2, maybe hot
;;prev block 22, next block 24, flags: (NEW, REACHABLE)
;;pred:   22 [80.0%]  (TRUE_VALUE,EXECUTABLE)
  _119 = (unsigned long) _151;
  _118 = _119 & 15;
  _117 = _118 >> 3;
  _116 = -_117;
  _115 = (unsigned int) _116;
  _114 = _115 & 1;
  prolog_loop_niters.46_120 = MIN_EXPR <_114, ivtmp.115_244>;
  if (prolog_loop_niters.46_120 == 0)
goto ;
  else
goto ;


Egad.  No wonder LTO loses.  I don't think the loop iterates enough to make up
for this mess.

[Bug c/68971] -Woverflow false alarm in code unreachable after __builtin_mul_overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-02-15
 Ever confirmed|0   |1

--- Comment #9 from Martin Sebor  ---
Paul, with bug 68120 resolved, can this bug be closed as well or is there
something else to do here?

[Bug c/79479] -Woverflow false alarm in unreachable expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #15 from Martin Sebor  ---


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

[Bug middle-end/4210] should not warning with dead code

[msebor at gcc dot gnu.org]

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

--- Comment #26 from Martin Sebor  ---
*** Bug 79479 has been marked as a duplicate of this bug. ***

[Bug target/79545] gcc[5/6]: RS6000, xvcvuxdsp and xvcvsxdsp RTL defines have wrong type

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||powerpc*-*-*
   Target Milestone|--- |6.4
  Known to fail||5.4.1, 6.3.1

[Bug target/79545] gcc[5/6]: RS6000, xvcvuxdsp and xvcvsxdsp RTL defines have wrong type

[carll at gcc dot gnu.org]

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

Carl Love  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-02-15
   Assignee|unassigned at gcc dot gnu.org  |carll at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Carl Love  ---
The issue has been fixed in mainline 7.0, commit r245460 on 2017-02-14.

Commit  r245460 needs to be back ported to GCC 5 and GCC 6.

[Bug c/79546] New: Strange error: missed loop optimization, the loop counter may overflow [-Werror=unsafe-loop-optimizations]

[rjones at redhat dot com]

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

Bug ID: 79546
   Summary: Strange error: missed loop optimization, the loop
counter may overflow
[-Werror=unsafe-loop-optimizations]
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rjones at redhat dot com
  Target Milestone: ---

#include 
#include 

int f (size_t len);

int
main (int argc, char *argv[])
{
  size_t len;

  if (argc < 2) abort ();
  if (sscanf (argv[1], "%zu", ) != 1) abort ();

  f (len);

  exit (0);
}

int
f (size_t len)
{
  size_t i;

  i = 0;
  while (i < len) {
i += 0x1000;
printf ("page %zu\n", i);
  }
}
---

When compiled with:

$ gcc -O2 -Werror=unsafe-loop-optimizations test.c -o test
test.c: In function ‘main’:
test.c:25:9: error: missed loop optimization, the loop counter may overflow
[-Werror=unsafe-loop-optimizations]
   while (i < len) {
 ^
test.c: In function ‘f’:
test.c:25:9: error: missed loop optimization, the loop counter may overflow
[-Werror=unsafe-loop-optimizations]
   while (i < len) {
 ^
cc1: some warnings being treated as errors

---

What I don't understand is what the error means, nor how to correct it.

---

$ gcc --version
gcc (GCC) 7.0.1 20170204 (Red Hat 7.0.1-0.6)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

From Fedora 26.

[Bug target/79545] New: gcc[5/6]: RS6000, xvcvuxdsp and xvcvsxdsp RTL defines have wrong type

[carll at gcc dot gnu.org]

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

Bug ID: 79545
   Summary: gcc[5/6]: RS6000, xvcvuxdsp and xvcvsxdsp RTL defines
have wrong type
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carll at gcc dot gnu.org
  Target Milestone: ---

The following issue was found in gcc 6.1.  It also exists in gcc5.4.

The source and return operand types for xvcvuxdsp and xvcvsxdsp instructions
do not match the instruction definitions from the Power ISA document.  The
current code expects a V2DF source and returns V4SI.  The two instructions
should take a V2DI source and return V4SF.

Additionally, there is a typo in the instruction generation for the xvcvuxdsp
instruction generates instruction xvcvuxwdp instead of xvcvuxdsp.  The issues
are in file gcc/config/rs6000/vsx.md for define_insn "vsx_xvcvsxdsp" and 
define_insn "vsx_xvcvuxdsp" RTL statements.

[Bug middle-end/4210] should not warning with dead code

[eggert at gnu dot org]

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

--- Comment #25 from Paul Eggert  ---
I'd like this bug to be changed from SUSPENDED to CONFIRMED, given that it's
continuing to be a problem (e.g., bug#79479).

Also, I'd like to suggest what I hope is a simple fix. In 2006 Joseph wrote
"skip_evaluation can't be set for if (0) because you can jump into if (0),
whereas jumps into statement expressions are not permitted". So, how about if
we merely set skip_evaluation for "if (0)" when the then-part lacks labels?
This should be an easy test, as it shouldn't require parsing the whole function
body. The test might still generate false alarms for code containing gotos, but
in practice such gotos are rare, so the proposed change should be a significant
improvement even if it's not perfect.

[Bug c++/78572] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4968

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c/79479] -Woverflow false alarm in unreachable expression

[eggert at gnu dot org]

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

--- Comment #14 from Paul Eggert  ---
Thanks, please feel free to mark this as a duplicate of Bug#4210. I plan to
follow up there.

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Component|c++ |tree-optimization

--- Comment #4 from Jason Merrill  ---
Changing component since this seems to be a tree-ssa-uninit.c issue.

[Bug c++/69564] [5/6/7 Regression] lto and/or C++ make scimark2 LU slower

[law at redhat dot com]

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

--- Comment #29 from Jeffrey A. Law  ---
So to bring this BZ back to the core questions (the scope seems to have widened
through the year since this originally reported).  Namely are the use of LTO or
C++ making things slower, particularly for scimark's LU factorization test.

>From my experiments, the answer is a very clear yes. I hacked up the test a bit
to only run LU and run a fixed number of iterations.  That makes comparisons
with something like callgrind much easier. 

Use of C++ adds 2-3% in terms of instruction counts.  LTO adds an additional
2-3% to the instruction counts.  These are additive, C++ with LTO is about 5%
higher than C without LTO.

The time (not surprisingly) is lost in LU_factor, the main culprit seems to be
this pair of nested loops:

   int ii;
for (ii=j+1; ii

[Bug target/79544] vec_sra (unsigned long long,foo) generating vsrd instead of vsrad

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from Bill Schmidt  ---
Note that this is indeed wrong because the semantics of vec_sra are to
duplicate the sign bit even for unsigned inputs.

[Bug target/79544] vec_sra (unsigned long long,foo) generating vsrd instead of vsrad

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Keywords||wrong-code
Version|unknown |7.0
   Target Milestone|--- |7.0

[Bug target/79544] New: vec_sra (unsigned long long,foo) generating vsrd instead of vsrad

[willschm at gcc dot gnu.org]

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

Bug ID: 79544
   Summary: vec_sra (unsigned long long,foo) generating vsrd
instead of vsrad
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: willschm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40756
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40756=edit
sample test

Noticed that vec_sra is generating a vsrd instruction rather than the expected
vsrad instruction when using "unsigned long long" parameter.   

>   #include 
>   vector unsigned long long
>   test6_sra (vector unsigned long long x, vector unsigned long long y)
>   {
> return vec_sra (x, y);
>   }

> #> gcc -c testme_sra.c  -S -mvsx -O3 

> #> grep -A 3 test6_sra: testme_sra.s
> test6_sra:
>   vsrd 2,2,3
>   blr
>   .long 0

vec_sra() against char,short,int appear OK. 

Seeing this on trunk (20170208) as well as older distro supplied compilers. 

test attached.

[Bug rtl-optimization/78127] [5/6/7 Regression] AArch64 internal compiler error: in lra_eliminate, at lra-eliminations.c:1440

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #2 from Vladimir Makarov  ---
I've reproduced it and started to work on it.  I think the fix will be ready on
this week.

[Bug c++/79363] [6 Regression] ICE with NSDMI and array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE with   |[6 Regression] ICE with
   |NSDMI and array |NSDMI and array

--- Comment #5 from Martin Sebor  ---
Fixed on trunk via r245494.

[Bug c++/79050] [5/6/7 Regression] ICE: tree code 'template_type_parm' is not supported in LTO streams

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/79464] [7 Regression] ICE in ipa_modify_formal_ parameters

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Feb 15 20:29:08 2017
New Revision: 245495

URL: https://gcc.gnu.org/viewcvs?rev=245495=gcc=rev
Log:
PR c++/79464 - ICE in IPA with omitted constructor parms

* class.c (build_clone): Also omit parms from TYPE_ARG_TYPES.
(adjust_clone_args): Adjust.
(add_method): Remember omitted parms.
* call.c (add_function_candidate): Likewise.
* mangle.c (write_method_parms): Likewise.
* method.c (ctor_omit_inherited_parms): Return false if there are no
parms to omit.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/class.c
trunk/gcc/cp/mangle.c
trunk/gcc/cp/method.c
trunk/gcc/testsuite/g++.dg/cpp1z/inh-ctor23.C

[Bug c++/79464] [7 Regression] ICE in ipa_modify_formal_ parameters

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/79363] [6/7 Regression] ICE with NSDMI and array

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Wed Feb 15 20:28:32 2017
New Revision: 245494

URL: https://gcc.gnu.org/viewcvs?rev=245494=gcc=rev
Log:
PR c++/79363 - ICE with NSDMI and array

gcc/cp/ChangeLog:

PR c++/79363
* init.c (maybe_reject_flexarray_init): New function.
(perform_member_init): Call it.

gcc/testsuite/ChangeLog:

PR c++/79363
* g++.dg/ext/flexary12.C: Adjust.
* g++.dg/ext/flexary20.C: Same.
* g++.dg/ext/flexary21.C: Same.
* g++.dg/ext/flexary22.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ext/flexary22.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/flexary12.C
trunk/gcc/testsuite/g++.dg/ext/flexary20.C
trunk/gcc/testsuite/g++.dg/ext/flexary21.C

[Bug middle-end/32003] Undocumented -fdump-tree options

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
Author: msebor
Date: Wed Feb 15 20:13:11 2017
New Revision: 245493

URL: https://gcc.gnu.org/viewcvs?rev=245493=gcc=rev
Log:
2017-02-15  Martin Sebor  

PR middle-end/32003
* doc/invoke.texi (-fdump-final-insns): Replace option accidentally
removed in a prior commit.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

[Bug c/79479] -Woverflow false alarm in unreachable expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #13 from Martin Sebor  ---
The false positives/negatives I'm concerned about would result from moving the
warning from the front-end to the middle-end.  This would be necessary to
handle some of the non-trivial cases I mentioned in comment #11.  In the
front-end the warning only sees as far as the end of a full expression.  The
front-end does no data flow analysis beyond attempting to evaluate expressions.

In the middle-end, to expose dependencies between statements (such as the
dependency of expr on cond in "if (cond) { expr; }" the warning would depend on
various transformations done by optimization passes (such as constant
propagation and dead code elimination).  Some of these transformations could
also simplify or remove expressions that involve constant overflows, leading to
false negatives, and others could introduce them even though they didn't exist
in the original code (e.g., along new code paths that may never be even
executed), causing false positives.

Bugs certainly should be raised for these problems (and many have been) but
because of the complex interactions between the transformations they tend to be
quite difficult to fix, and some can't be fixed at all.  The net result would
be a trade-off between one set of fairly simple bugs or complaints vs another,
much more complex bugs.  There are a number of examples of these trade-offs in
Bugzilla with even more discussion on gcc-patches.  This doesn't mean that
warnings shouldn't be implemented in the middle-end, just that they aren't
going to be perfect there either, or make everyone happy (in fact, simple
warnings like -Woverflow tend to be less controversial than data flow warnings
because they are for the most part decidable.)

In any case, since bug 4210 already tracks the enhancement you would like to
see I propose to close this as a duplicate of that bug.  Please let me know if
you disagree, otherwise I'll go ahead and resolve it as such.

[Bug other/79543] New: Inappropriate "ld --version" checking

[tschwinge at gcc dot gnu.org]

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

Bug ID: 79543
   Summary: Inappropriate "ld --version" checking
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jsm28 at gcc dot gnu.org
  Target Milestone: ---

libgomp (and, from a quick scan, also other places of GCC/other target
libraries) conditionally use certain linker features, depending on linker
version numbers.  For example, linker version scripts in libgomp; see
LIBGOMP_BUILD_VERSIONED_SHLIB, LIBGOMP_BUILD_VERSIONED_SHLIB_GNU usage in
libgomp/Makefile.am, which are defined in libgomp/acinclude.m4 based on the
enable_symvers value, which is set by some logic depending on "ld --version"
output.  Looking at one specific build's libgomp/config.log, I see:

[...]
configure:16132: checking if the linker ([...]/gcc/collect-ld) is GNU ld
configure:16147: result: yes
[...]
configure:16389: WARNING: === Linker version 1125 is too old for
configure:16391: WARNING: === full symbol versioning support in this
release of GCC.
configure:16393: WARNING: === You would need to upgrade your binutils to
version
configure:16395: WARNING: === 21400 or later and rebuild GCC.
configure:16404: WARNING: === Symbol versioning will be disabled.
[...]

Now, what is this "1125" linker version?

$ [...]/gcc/collect-ld --version
GNU ld (Sourcery CodeBench ([...]) Lite 2015.11-[...]) 2.25.51

..., and then apply the "magic" used in libgomp/acinclude.m4 to compute
libgomp_gnu_ld_version:

$ [...]/gcc/collect-ld --version | sed -e 's/GNU gold /GNU ld /;s/GNU ld
version /GNU ld /;s/GNU ld ([^)]*) /GNU ld /;s/GNU ld \([0-9.][0-9.]*\).*/\1/;
q' | awk -F. '{ if (NF<3) $3=0; print ($1*100+$2)*100+$3 }'
1125

"1125" instead of the expected "22551".  That's pretty weird, and I suppose it
may be causing all kinds of "interesting" issues, when using a linker that has
been configured to override/augment its version string?

Joseph told me that "the correct logic for finding the version number is to
take everything after the last space on the first line of the output, as per
the GNU Coding Standards.  (It's possible some very old binutils versions may
not have properly formatted output; my view is that each GCC version should
have a minimum corresponding binutils version, no more than say five years old,
for targets using GNU binutils.)"

Yet better, obviously, would be to not rely on such version-based decisions at
all.

(Hopefully, similar parsing is not also being done for "as --version", or other
tools, and this was just a one-off problem, possibly originally introduced in
libstdc++-v3/acinclude.m4, 15 years ago, and the copied from there to other
target libraries?  I haven't looked in detail.)


(For reference, this is the root cause for the issue reported in
.)

[Bug ada/79542] New: [7.0 regression] GNAT bug box

[reznikmm at gmail dot com]

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

Bug ID: 79542
   Summary: [7.0 regression] GNAT bug box
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reznikmm at gmail dot com
  Target Milestone: ---

Created attachment 40754
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40754=edit
package body

Here is a reproducer for regression in GCC 7.
The regression was found by fedora project while recompiling packages
with new compiler. gcc 6, gcc 5 works fine with it.

gcc version 7.0.1 20170212 (experimental) (GCC)
Target: x86_64-pc-linux-gnu
Configured with: /work/reznik/gcc/gcc-7-20170212/configure
--enable-languages=ada,c,c++ --prefix=/work/reznik/gcc/install
--disable-multilib

Command line:
gcc -O2 -c -g finite_automatons.adb

Output:
+===GNAT BUG DETECTED==+
| 7.0.1 20170212 (experimental) (x86_64-pc-linux-gnu) GCC error:   |
| in add_gnat_descriptive_type_attribute, at dwarf2out.c:19511 |
| Error detected around finite_automatons.adb:34:8 |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

finite_automatons.adb
finite_automatons.ads


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:406

[Bug ada/79542] [7.0 regression] GNAT bug box

[reznikmm at gmail dot com]

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

--- Comment #1 from Maxim Reznik  ---
Created attachment 40755
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40755=edit
package spec

[Bug rtl-optimization/79541] New: lra reads uninitialized memory (with invalid input)

[bernds at gcc dot gnu.org]

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

Bug ID: 79541
   Summary: lra reads uninitialized memory (with invalid input)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernds at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40753
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40753=edit
Reproducer

Disclaimer: I'm uncertain how severe this is: the test program contains an
invalid assembly statement that LRA converts into a nop. If that asm is
corrected, the problem no longer reproduces, and I don't know if the issue
could show up on a legitimate input. I noticed this because an unrelated patch
that should have had no effect on this program caused differences in assembly
output.

Compile the test program as follows, for ppc-linux (I use an x86_64-linux x
ppc-linux cross):

valgrind ./cc1 -O2 sl4.i   -I include 

The following should show up in the output:

==7398== Conditional jump or move depends on uninitialised value(s)
==7398==at 0xCB3791: lra_eliminate_regs_1(rtx_insn*, rtx_def*,
machine_mode, bool, bool, long, bool) (lra-eliminations.c:403)
==7398==by 0xCB4133: lra_eliminate_regs_1(rtx_insn*, rtx_def*,
machine_mode, bool, bool, long, bool) (lra-eliminations.c:642)
==7398==by 0xCC1D71: remove_pseudos(rtx_def**, rtx_insn*)
(lra-spills.c:421)
==7398==by 0xCC1E1F: remove_pseudos(rtx_def**, rtx_insn*)
(lra-spills.c:431)
==7398==by 0xCC2089: spill_pseudos() (lra-spills.c:475)
==7398==by 0xCC27A9: lra_spill() (lra-spills.c:604)
==7398==by 0xC93355: lra(_IO_FILE*) (lra.c:2486)
==7398==by 0xC38FC0: do_reload() (ira.c:5400)
==7398==by 0xC39476: (anonymous namespace)::pass_reload::execute(function*)
(ira.c:5584)
==7398==by 0xD83360: execute_one_pass(opt_pass*) (passes.c:2465)
==7398==by 0xD836C4: execute_pass_list_1(opt_pass*) (passes.c:2554)
==7398==by 0xD836F5: execute_pass_list_1(opt_pass*) (passes.c:2555)

The unitialized memory seems to be the sp_offset field of an insn created by
LRA. The .reload dump should contain a line as follows, with random numbers for
sp_off:

 Choosing alt 5 in insn 266:  (0) m  (1) r {*movsi_internal1}
(sp_off=139971034200304)

[Bug middle-end/79537] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:12009

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
This

void fn1 ()
{
  L: goto *&
}

doesn't ICE because we handle the goto here
11406 case GOTO_EXPR:
11407   /* If the target is not LABEL, then it is a computed jump
11408  and the target needs to be gimplified.  */
11409   if (TREE_CODE (GOTO_DESTINATION (*expr_p)) != LABEL_DECL)
11410 {
11411   ret = gimplify_expr (_DESTINATION (*expr_p), pre_p,
11412NULL, is_gimple_val, fb_rvalue);

notice the fb_rvalue, so then we won't reach the switch in Comment 3.

[Bug libfortran/79540] [7 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Removed comment:

# ./fmt_fw_d.exe
 print '(f2.1)',100.00  ! => : no digits

Program aborted. Backtrace:

[Bug libfortran/79540] New: [7 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

Bug ID: 79540
   Summary: [7 Regression] FAIL: gfortran.dg/fmt_fw_d.f90   -O0
execution test
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-hpux*
Target: hppa*-*-hpux*
 Build: hppa*-*-hpux*

spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc
/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11
/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/fmt_fw_d.f90
-fno-di
agnostics-show-caret -fdiagnostics-color=never -O0 -std=gnu
-B/test/gnu/gcc/objd
ir/hppa64-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux
11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortr
an/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libatomic/.libs
-B/test/gn
u/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa
64-hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/.
/libquadmath/.libs -lm -o ./fmt_fw_d.exe
PASS: gfortran.dg/fmt_fw_d.f90   -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfort
ran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu
/gcc/objdir/hppa64-hp-hpux11.11/./libatomic/.libs:/test/gnu/gcc/objdir/hppa64-hp
-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/gcc:.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libatomic/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/gcc
spawn [open ...]
Program aborted. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
FAIL: gfortran.dg/fmt_fw_d.f90   -O0  execution test

[Bug libstdc++/79114] [6 Regression] std::throw_with_nested("string literal") is rejected

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Wed Feb 15 19:10:43 2017
New Revision: 245492

URL: https://gcc.gnu.org/viewcvs?rev=245492=gcc=rev
Log:
PR libstdc++/79114 use dg-require-atomic-builtins for new test

PR libstdc++/79114
* testsuite/18_support/nested_exception/79114.cc: Add dg-require.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog

[Bug c/79518] __builtin_assume_aligned should mark argument as aligned

[e...@coeus-group.com]

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

--- Comment #4 from Evan Nemerson  ---
I agree that GCC's implementation makes more sense, but unfortunately it makes
it hard to write portable code.

I'm not suggesting the current behavior be abandoned, only that
__builtin_assume_aligned be enhanced so the argument is marked as aligned when
possible.

Think of it as an optimization opportunity; given something like

  void* foo = __builtin_assume_aligned(bar, 16);
  /* Use bar for something instead of foo */

GCC could see that bar is 16-byte aligned and generate better code accordingly,
even though the programmer did something dumb.

I won't reopen this, but I hope you will…  AFAICT there aren't any
disadvantages, and it would be very helpful for people with code already
optimized using MSVC, ICC, etc.

[Bug middle-end/79537] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:12009

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
I wonder if something like this would be appropriate:

--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -12003,6 +12003,10 @@ gimplify_expr (tree *expr_p, gimple_seq *pre_p,
gimple_seq *post_p,
 gimple_test_f, fallback);
  break;

+   case LABEL_DECL:
+ /* A LABEL_DECL that is FORCED_LABEL.  Skip it.  */
+ break;
+
default:
   /* Anything else with side-effects must be converted to
  a valid statement before we get here.  */

[Bug middle-end/79537] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:12009

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
gimplify_expr has code to handle taking the address of a label:
11610 case LABEL_DECL:
11611   /* We get here when taking the address of a label.  We mark
11612  the label as "forced"; meaning it can never be removed and
11613  it is a potential target for any computed goto.  */
11614   FORCED_LABEL (*expr_p) = 1;
11615   ret = GS_ALL_DONE;
11616   break;

but we crash later on in the switch here:

11978   /* We aren't looking for a value, and we don't have a valid
11979  statement.  If it doesn't have side-effects, throw it away.  */
11980   if (!TREE_SIDE_EFFECTS (*expr_p))
11981 *expr_p = NULL;
11982   else if (!TREE_THIS_VOLATILE (*expr_p))
11983 {
11984   /* This is probably a _REF that contains something nested that
11985  has side effects.  Recurse through the operands to find it. 
*/
11986   enum tree_code code = TREE_CODE (*expr_p);

The problem is that the LABEL_DECL L is considered TREE_SIDE_EFFECTS, because
the definition of FORCED_LABEL is:

#define FORCED_LABEL(NODE) (LABEL_DECL_CHECK (NODE)->base.side_effects_flag)

[Bug libstdc++/79539] __polynomial mode lookahead still has an exponential behavior

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

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

--- Comment #1 from Tim Shen  ---
Assign to myself.

[Bug libstdc++/79539] New: __polynomial mode lookahead still has an exponential behavior

[timshen at gcc dot gnu.org]

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

Bug ID: 79539
   Summary:  __polynomial mode lookahead still has an
exponential behavior
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: timshen at gcc dot gnu.org
  Target Milestone: ---

Lookahead is implemented in terms of non-memoized recursion, which may have
exponential behavior.

In __polynomial mode, we can add a quadratic memoization to it, making it
O(|state| * |target string|) at worst. It's not linear, but still polynomial.

[Bug libstdc++/79114] [6 Regression] std::throw_with_nested("string literal") is rejected

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Ah yes, because throw_with_nested still depends on atomics in gcc-6-branch, and
so we need a dg-require- in the test (but only on the branch). I'll add that.

[Bug middle-end/79537] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:12009

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Even r104500 ICEs so an ancient issue.

[Bug middle-end/79537] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:12009

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-15
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|ICE in gimplify_expr, at|[5/6/7 Regression] ICE in
   |gimplify.c:12009|gimplify_expr, at
   ||gimplify.c:12009
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  GCC 4.4 ICEs too, but gcc34 doesn't.

[Bug middle-end/78452] -Wformat-length=2 wrong length in %s directive with an array argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Target Milestone|--- |7.0

--- Comment #1 from Martin Sebor  ---
The latest trunk (GCC 7.0) doesn't issue the second warning due to bug 79538. 
Changing the test case to get around that limitation and trigger the warning
shows that the warning and the subsequent note are now correct.  The warning
says "may write a terminating nul past the end of the destination" is correct
because when the longer of the two arrays holds the longest string that can fit
(one whose length is 3 bytes) the function will write the terminating nul just
past the end.  Because the string could be shorter than that, the warning
correctly says "may write."  The note then explains that the total number of
bytes written by the function is between 1 byte (for the nul alone when the
string is empty) and 4 bytes (when the string length is 3, plus the terminating
nul).


$ cat t.c && gcc -O2 -S -Wall -Wformat-overflow t.c
char d[3];

const char s3[] = "123";
const char s4[] = "1234";

void f (int i)
{
  const char *s = i < 0 ? s3 : s4;
  __builtin_sprintf (d, "%-s", s);   // warning (expected), bytes correct
}

struct S
{
  char a3[3];
  char a4[4];
  int i;
};

void g (int i, struct S *p)
{
  const char *s = i < 0 ? p->a3 : p->a4;
  __builtin_sprintf (d, "%-s", s);   // warning (expected), bytes wrong
}
t.c: In function ‘f’:
t.c:9:26: warning: ‘%-s’ directive writing between 3 and 4 bytes into a region
of size 3 [-Wformat-overflow=]
   __builtin_sprintf (d, "%-s", s);   // warning (expected), bytes correct
  ^~~
t.c:9:3: note: ‘__builtin_sprintf’ output between 4 and 5 bytes into a
destination of size 3
   __builtin_sprintf (d, "%-s", s);   // warning (expected), bytes correct
   ^~~
t.c: In function ‘g’:
t.c:22:25: warning: ‘__builtin_sprintf’ may write a terminating nul past the
end of the destination [-Wformat-overflow=]
   __builtin_sprintf (d, "%-s", s);   // warning (expected), bytes wrong
 ^
t.c:22:3: note: ‘__builtin_sprintf’ output between 1 and 4 bytes into a
destination of size 3
   __builtin_sprintf (d, "%-s", s);   // warning (expected), bytes wrong
   ^~~

[Bug c++/79535] [6/7 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2636

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-15
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.4
Summary|ICE in verify_ctor_sanity,  |[6/7 Regression] ICE in
   |at cp/constexpr.c:2636  |verify_ctor_sanity, at
   ||cp/constexpr.c:2636
 Ever confirmed|0   |1

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

[Bug middle-end/79536] [5/6/7 Regression] ICE in fold_binary_loc, at fold-const.c:9060

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Component|c   |middle-end
   Target Milestone|--- |5.5

[Bug c/79536] [5/6/7 Regression] ICE in fold_binary_loc, at fold-const.c:9060

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-15
 CC||mpolacek at gcc dot gnu.org
Summary|ICE in fold_binary_loc, at  |[5/6/7 Regression] ICE in
   |fold-const.c:9060   |fold_binary_loc, at
   ||fold-const.c:9060
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  I bet it started with r121511.

[Bug middle-end/79538] New: missing -Wformat-overflow with %s and global array arguments

[msebor at gcc dot gnu.org]

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

Bug ID: 79538
   Summary: missing -Wformat-overflow with %s and global array
arguments
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wformat-overflow option detects the possible buffer overflow in function f
below but missed the same possible overflow in function g.  The function it
relies on to detect the sizes of the array, get_range_strlen() in
gimple-fold.c, handles member arrays but not the non-member array case.

$ cat u.c && gcc -O2 -S -Wall -Wformat-overflow  u.c
char d[3];

struct S {
  char a3[3];
  char a4[4];
};

void f (int i, const struct S *p)
{
  const char *s = i < 0 ? p->a3 : p->a4;
  __builtin_sprintf (d, "%-s", s); 
}

char a3[3];
char a4[4];

void g (int i)
{
  const char *s = i < 0 ? a3 : a4;
  __builtin_sprintf (d, "%-s", s); 
}
u.c: In function ‘f’:
u.c:11:25: warning: ‘__builtin_sprintf’ may write a terminating nul past the
end of the destination [-Wformat-overflow=]
   __builtin_sprintf (d, "%-s", s);
 ^
u.c:11:3: note: ‘__builtin_sprintf’ output between 1 and 4 bytes into a
destination of size 3
   __builtin_sprintf (d, "%-s", s);
   ^~~

[Bug c/79528] DFP double rounding bug

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
On Wed, 15 Feb 2017, jakub at gcc dot gnu.org wrote:

> It seems besides conversion from integer to decimal{32,64} also all the
> arithmetics e.g. in real_arithmetics are performed in _Decimal128 precision 
> and
> rounded according to that and then rounded again to the corresponding
> _Decimal{32,64} type.  As the precision in decimal digits of _Decimal64 is 
> just
> 16 and _Decimal128 is 34 decimal digits, perhaps it is just fine for +/-, but
> not sure about multiplication or FMA (if we ever allow that for decimal 
> float).

Multiplication is trivially OK (as the product of any two _Decimal64 
numbers is exactly representable in _Decimal128).

Division and square root may well be OK but would require a more detailed 
analysis.

Double rounding for fma is never OK (in round-to-nearest) as the product 
of two values can be an exactly half-way value, which is then added to 
something much smaller.

[Bug c++/79288] [7 Regression] TLS model wrong for static data members since r241137

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/79534] tree-ifcombine aarch64 regression with trunk@245151

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
r245151

[Bug tree-optimization/79534] tree-ifcombine aarch64 regression with trunk@245151

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
R245151

[Bug c/79537] New: ICE in gimplify_expr, at gimplify.c:12009

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

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

Bug ID: 79537
   Summary: ICE in gimplify_expr, at gimplify.c:12009
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Affects versions down to at least 4.8 (on x86_64 GNU/Linux) :


$ cat z1.c
void fn1 ()
{
  L: *&
}


$ gcc-7-20170212 -c z1.c
z1.c: In function 'fn1':
z1.c:3:6: internal compiler error: in gimplify_expr, at gimplify.c:12009
   L: *&
  ^
0x983ca5 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12009
0x9840c6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6478
0x97f483 gimplify_statement_list
../../gcc/gimplify.c:1716
0x97f483 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11619
0x9840c6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6478
0x986a8d gimplify_bind_expr
../../gcc/gimplify.c:1290
0x98129a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11391
0x9840c6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6478
0x987789 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:12385
0x987e24 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:12543
0x7f1607 cgraph_node::analyze()
../../gcc/cgraphunit.c:657
0x7f4d73 analyze_functions
../../gcc/cgraphunit.c:1118
0x7f58ba symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2599

[Bug c/79536] New: ICE in fold_binary_loc, at fold-const.c:9060

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

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

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

Affects versions down to at least 4.8 (on x86_64 GNU/Linux) :


$ cat z1.c
typedef int A;
void fn1 (A x, A y)
{
  if ( (x+(x-y)*1i) != -(-x+(y-x)*1i) );
}


$ gcc-7-20170212 -c z1.c
z1.c: In function 'fn1':
z1.c:4:3: internal compiler error: in fold_binary_loc, at fold-const.c:9060
   if ( (x+(x-y)*1i) != -(-x+(y-x)*1i) );
   ^~
0x8fc0af fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:9057
0x904faa fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:12242
0x90ff0a fold_negate_expr
../../gcc/fold-const.c:583
0x910517 negate_expr
../../gcc/fold-const.c:735
0x8fa3de fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:9522
0x904faa fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:12242
0x90fc4c fold_negate_expr
../../gcc/fold-const.c:625
0x906c95 fold_unary_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc/fold-const.c:7827
0x916f4c fold(tree_node*)
../../gcc/fold-const.c:11875
0x6e36ea c_fully_fold_internal
../../gcc/c/c-fold.c:412
0x6e492b c_fully_fold(tree_node*, bool, bool*)
../../gcc/c/c-fold.c:90
0x69c7fa build_binary_op(unsigned int, tree_code, tree_node*, tree_node*, int)
../../gcc/c/c-typeck.c:11752
0x69d836 parser_build_binary_op(unsigned int, tree_code, c_expr, c_expr)
../../gcc/c/c-typeck.c:3633
0x6bae1a c_parser_binary_expression
../../gcc/c/c-parser.c:6818
0x6bb2b5 c_parser_conditional_expression
../../gcc/c/c-parser.c:6458
0x6bba10 c_parser_expr_no_commas
../../gcc/c/c-parser.c:6375
0x6bbc92 c_parser_expression
../../gcc/c/c-parser.c:8597
0x6be519 c_parser_expression_conv
../../gcc/c/c-parser.c:8630
0x6be592 c_parser_condition
../../gcc/c/c-parser.c:5421
0x6be627 c_parser_paren_condition
../../gcc/c/c-parser.c:5440

[Bug c++/79535] New: ICE in verify_ctor_sanity, at cp/constexpr.c:2636

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

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

Bug ID: 79535
   Summary: ICE in verify_ctor_sanity, at cp/constexpr.c:2636
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Affects versions 6/7 (on x86_64 GNU/Linux) :


$ cat z1.cc
struct A
{
  int b = 1;
  int c = 2;
  int x[] = { c, 3 };
};
A a = { 4, 5 };


$ gcc-7-20170212 -c z1.cc
z1.cc:7:14: internal compiler error: in verify_ctor_sanity, at
cp/constexpr.c:2636
 A a = { 4, 5 };
  ^
0x8bb029 verify_ctor_sanity
../../gcc/cp/constexpr.c:2635
0x8c595e cxx_eval_bare_aggregate
../../gcc/cp/constexpr.c:2665
0x8bfd79 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:4304
0x8c5ae6 cxx_eval_bare_aggregate
../../gcc/cp/constexpr.c:2681
0x8bfd79 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:4304
0x8c67e1 cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:4603
0x8c9dc0 maybe_constant_init(tree_node*, tree_node*)
../../gcc/cp/constexpr.c:4926
0x73a7c2 store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/cp/typeck2.c:819
0x6966ca check_initializer
../../gcc/cp/decl.c:6359
0x6c2577 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7025
0x7bdbf8 cp_parser_init_declarator
../../gcc/cp/parser.c:19397
0x7be5af cp_parser_simple_declaration
../../gcc/cp/parser.c:12792
0x7bf30a cp_parser_block_declaration
../../gcc/cp/parser.c:12618
0x7c722e cp_parser_declaration
../../gcc/cp/parser.c:12515
0x7c7686 cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:12391
0x7c79b8 cp_parser_translation_unit
../../gcc/cp/parser.c:4366
0x7c79b8 c_parse_file()
../../gcc/cp/parser.c:38425
0x92a392 c_common_parse_file()
../../gcc/c-family/c-opts.c:1107

[Bug tree-optimization/79472] [8 Regression] x86-64: Switch table generation fails if default case has different code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2017-02/msg00945.ht
   ||ml
   Target Milestone|7.0 |8.0
Summary|[7 Regression] x86-64:  |[8 Regression] x86-64:
   |Switch table generation |Switch table generation
   |fails if default case has   |fails if default case has
   |different code  |different code

--- Comment #9 from Jakub Jelinek  ---
Postponed to GCC 8, the patch is too large for GCC 7 this late.

[Bug tree-optimization/79347] [7 regression] vect_do_peeling is messing up profile

[amker at gcc dot gnu.org]

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

--- Comment #9 from amker at gcc dot gnu.org ---
(In reply to Pat Haugen from comment #7)
> See pr77536 for similar issue. Not sure if that should be marked as dup of
> this one or left open as a more general bug on what should be done to
> specifically fix the vectorized loop.

Hi Pat,
Thanks for pointing me to this.  This report is mostly tracking mismatch issue
introduced when I rewriting loop peeling in vectorizer.  Issue that vectorized
loop's frequency is wrong is scaled exists regardless of peeling change, so
IMHO it would be better to close this one and tracking the issue in PR77536.

Thanks.

[Bug tree-optimization/79534] New: tree-ifcombine aarch64 regression with trunk@245151

[brzycki at gmail dot com]

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

Bug ID: 79534
   Summary: tree-ifcombine aarch64 regression with trunk@245151
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brzycki at gmail dot com
  Target Milestone: ---

Created attachment 40752
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40752=edit
Reduced test-case. Larger scores are better.

I am seeing about a 6-10% performance regression on a proprietary benchmark on
AArch64, depending on the target micro-architecture.

# SHA d2c3261, trunk@245149, patch immediately preceding regression
/gcc/2017-02-03-12-17-59-d2c3261-master/bin/aarch64-sarc-linux-gnu-g++ -O3
-mcpu=cortex-a57 -std=c++11 -c a.cpp -o a.o
/gcc/2017-02-03-12-17-59-d2c3261-master/bin/aarch64-sarc-linux-gnu-g++  -o a
a.o
(best of 3 runs)
  SCORE_DIRECTION ==> larger is better
  SCORE ==> 1619.832509

# SHA f56c861, trunk@245151, regressing patch
/gcc/2017-02-03-14-03-35-f56c861-master/bin/aarch64-sarc-linux-gnu-g++ -O3
-mcpu=cortex-a57 -std=c++11 -c a.cpp -o a.o
/gcc/2017-02-03-14-03-35-f56c861-master/bin/aarch64-sarc-linux-gnu-g++  -o a
a.o
(best of 3 runs)
  SCORE_DIRECTION ==> larger is better
  SCORE ==> 1468.440527

# SHA e502db7, a recent 2/14/2017 tip build
/gcc/2017-02-14-23-11-19-e502db7-master/bin/aarch64-sarc-linux-gnu-g++ -O3
-mcpu=cortex-a57 -std=c++11 -c a.cpp -o a.o
/gcc/2017-02-14-23-11-19-e502db7-master/bin/aarch64-sarc-linux-gnu-g++  -o a
a.o
  SCORE_DIRECTION ==> larger is better
  SCORE ==> 1483.952217


I do not see the slowdown when testing on x86_64.

[Bug sanitizer/79341] Many Asan tests fail on s390

[vogt at linux dot vnet.ibm.com]

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

--- Comment #74 from Dominik Vogt  ---
With the pending patches/fixes, the *san testsuites are clean on s390x biarch
and s390.  :-)