[Bug c++/70163] C++ DR 257 constructor forward to virtual base class's constructor in an abstract class required

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-19
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed with today's trunk (7.0) and prior released versions.  Clang ineeds
accepts it, EDG 4.10 does not.

$ cat u.cpp && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wall -Wextra -Wpedantic u.cpp
struct A {
  A(const int i, const int j) {};
};

struct B1 : virtual public A {
  virtual void moo()=0;
  B1() {};   // (1) Look! not "B1() : A(5,6) {};"
};

struct B2 : virtual public A {
  virtual void cow()=0;
  B2() {};   // (2) Look! not "B2() : A(7,8) {};"
};

struct C : public B1, public B2 {
  C() : A(2,3) {};
  void moo() {};
  void cow() {};
};

int main() {
  C c;
  return 0;
};

u.cpp: In constructor ‘A::A(int, int)’:
u.cpp:2:15: warning: unused parameter ‘i’ [-Wunused-parameter]
   A(const int i, const int j) {};
   ^
u.cpp:2:28: warning: unused parameter ‘j’ [-Wunused-parameter]
   A(const int i, const int j) {};
^
u.cpp: In constructor ‘B1::B1()’:
u.cpp:7:8: error: no matching function for call to ‘A::A()’
   B1() {};   // (1) Look! not "B1() : A(5,6) {};"
^
u.cpp:2:3: note: candidate: A::A(int, int)
   A(const int i, const int j) {};
   ^
u.cpp:2:3: note:   candidate expects 2 arguments, 0 provided
u.cpp:1:8: note: candidate: constexpr A::A(const A&)
 struct A {
^
u.cpp:1:8: note:   candidate expects 1 argument, 0 provided
u.cpp:1:8: note: candidate: constexpr A::A(A&&)
u.cpp:1:8: note:   candidate expects 1 argument, 0 provided
u.cpp: In constructor ‘B2::B2()’:
u.cpp:12:8: error: no matching function for call to ‘A::A()’
   B2() {};   // (2) Look! not "B2() : A(7,8) {};"
^
u.cpp:2:3: note: candidate: A::A(int, int)
   A(const int i, const int j) {};
   ^
u.cpp:2:3: note:   candidate expects 2 arguments, 0 provided
u.cpp:1:8: note: candidate: constexpr A::A(const A&)
 struct A {
^
u.cpp:1:8: note:   candidate expects 1 argument, 0 provided
u.cpp:1:8: note: candidate: constexpr A::A(A&&)
u.cpp:1:8: note:   candidate expects 1 argument, 0 provided
u.cpp: At global scope:
u.cpp:24:2: warning: extra ‘;’ [-Wpedantic]
 };
  ^

[Bug c++/70097] Cannot assign ref-qualified non-static member function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-19
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Somehow the using declaration isn't working correctly and doesn't
seem to have ever worked as expected for reference [lr]value references.

[Bug c++/69872] [6/7 Regression] -Wnarrowing note without warning/errror

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||5.3.0
   Keywords||diagnostic
   Last reconfirmed||2016-05-19
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Wnarrowing note without |[6/7 Regression]
   |warning/errror  |-Wnarrowing note without
   ||warning/errror
  Known to fail||6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  If I'm not mistaken it was introduced as part of the delayed
folding merge in r230365.

[Bug libstdc++/69769] arithmetic operation on pointer to a function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||jwakely.gcc at gmail dot com,
   ||msebor at gcc dot gnu.org
  Component|c++ |libstdc++

--- Comment #1 from Martin Sebor  ---
The  header is part of libstdc++ so setting Component to it.  I agree
that this should be rejected but I'm not sure that this isn't actually a defect
in the standard.  AFAICS, the partial specializations of atomic for pointers
don't say that function pointers should be treated differently than object
pointers.  Jonathan, is there an issue on this (I may have overlooked int)?

[Bug c++/71147] [6 Regression] Flexible array member wrongly rejected in template

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||69698

--- Comment #4 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01427.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69698
[Bug 69698] [meta-bug] flexible array members

[Bug c++/71189] ICE with VLA with second dimension from a function call expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Last reconfirmed||2016-5-18
 CC||msebor at gcc dot gnu.org
 Resolution|--- |DUPLICATE
  Known to fail||4.9.0, 5.3.0, 6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed as a duplicate of bug 58646, even though current trunk (7.0) doesn't
crash on this test case, it does on the slightly modified one below:

$ echo "int f() { int f[2][f()] = {}; }" | /build/gcc-trunk-svn/gcc/xgcc -B
/build/gcc-trunk-svn/gcc -S -Wall -Wextra -Wpedantic -xc++ -
: In function ‘int f()’:
:1:23: warning: ISO C++ forbids variable length array ‘f’ [-Wvla]
:1:15: warning: unused variable ‘f’ [-Wunused-variable]
:1:31: warning: no return statement in function returning non-void
[-Wreturn-type]
:1:15: internal compiler error: in make_decl_rtl, at varasm.c:1299
0x143c037 make_decl_rtl(tree_node*)
/src/gcc-svn/gcc/varasm.c:1295
0xcc72ad expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/src/gcc-svn/gcc/expr.c:9479
0xcc04a6 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/src/gcc-svn/gcc/expr.c:7829
0xca85f4 expand_expr
/src/gcc-svn/gcc/expr.h:272
0xccf433 expr_size(tree_node*)
/src/gcc-svn/gcc/expr.c:11499
0xcc0163 expand_constructor
/src/gcc-svn/gcc/expr.c:7696
0xcc86e4 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/src/gcc-svn/gcc/expr.c:9745
0xcc04a6 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/src/gcc-svn/gcc/expr.c:7829
0xcb75a4 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/src/gcc-svn/gcc/expr.c:5276
0xcb81a3 store_expr(tree_node*, rtx_def*, int, bool, bool)
/src/gcc-svn/gcc/expr.c:5463
0xcbc849 store_field
/src/gcc-svn/gcc/expr.c:6675
0xcb57ad expand_assignment(tree_node*, tree_node*, bool)
/src/gcc-svn/gcc/expr.c:4893
0xb6f5b1 expand_gimple_stmt_1
/src/gcc-svn/gcc/cfgexpand.c:3618
0xb6f99c expand_gimple_stmt
/src/gcc-svn/gcc/cfgexpand.c:3714
0xb76a69 expand_gimple_basic_block
/src/gcc-svn/gcc/cfgexpand.c:5720
0xb7853b execute
/src/gcc-svn/gcc/cfgexpand.c:6335
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
tmp$

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

[Bug c++/58646] ICE on a multidimensional VLA with an empty initializer list

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||jaak at ristioja dot ee

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

[Bug driver/69265] Option suggestion provides a wrong hint

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #8 from David Malcolm  ---
Should be implemented as of r236439.

[Bug driver/69265] Option suggestion provides a wrong hint

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
Author: dmalcolm
Date: Thu May 19 00:52:08 2016
New Revision: 236439

URL: https://gcc.gnu.org/viewcvs?rev=236439=gcc=rev
Log:
PR driver/69265: add hint for options with misspelled arguments

opts-common.c's cmdline_handle_error handles invalid arguments
for options with CL_ERR_ENUM_ARG by building a string listing the
valid arguments.  By also building a vec of valid arguments, we
can use find_closest_string and provide a hint if we see a close
misspelling.

gcc/ChangeLog:
PR driver/69265
* Makefile.in (GCC_OBJS): Move spellcheck.o to...
(OBJS-libcommon-target): ...here.
* opts-common.c: Include spellcheck.h.
(cmdline_handle_error): Build a vec of valid options and use it
to suggest provide hints for misspelled arguments.

gcc/testsuite/ChangeLog:
PR driver/69265
* gcc.dg/spellcheck-options-11.c: New test case.

Added:
trunk/gcc/testsuite/gcc.dg/spellcheck-options-11.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/opts-common.c
trunk/gcc/testsuite/ChangeLog

[Bug c/71171] [6/7 Regression] Conditional jump or move depends on uninitialised value(s) in can_be_stored_compactly_p (line-map.c:148)

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Candidate patch posted here:
  https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01425.html

[Bug c++/71189] New: ICE with VLA with second dimension from a function call expression

[jaak at ristioja dot ee]

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

Bug ID: 71189
   Summary: ICE with VLA with second dimension from a function
call expression
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jaak at ristioja dot ee
  Target Milestone: ---

Code:

int f() { int f[0][f()] = {}; }

Both gcc and g++ versions 5.3.0 (in make_decl_rtl, at varasm.c:1313) 4.9.3 (in
make_decl_rtl, at varasm.c:1223) ICE on this. No ICE with 4.8.5.

[Bug c/71188] missing warning converting constant integer expression zero to pointer

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
Unlike the diagnostics for values that are not constant integers, any 
diagnostic for these cases must not be a pedwarn, because converting an 
arbitrary integer constant expression with value 0 implicitly to pointer 
type is valid in ISO C.

[Bug c++/71184] ICE on "operator new["

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01424.html

[Bug c/71188] missing warning converting constant integer expression zero to pointer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|missing warning converting  |missing warning converting
   |__builtin_offsetof and  |constant integer expression
   |sizeof to pointer   |zero to pointer

--- Comment #1 from Martin Sebor  ---
This seems to be a general issue with all constant integer expressions that
evaluate to zero, such as enumerators, so changing the Summary to reflect that.

$ cat u.cpp && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wall -Wextra -Wpedantic -xc u.cpp
enum { e, f };
int *p = e;
int *q = f;
u.cpp:3:10: warning: initialization makes pointer from integer without a cast
[-Wint-conversion]
 int *q = f;
  ^

[Bug middle-end/71177] Spurious -Waggressive-loop-optimizations warning

[tavianator at gmail dot com]

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

Tavian Barnes  changed:

   What|Removed |Added

  Attachment #38516|0   |1
is obsolete||

--- Comment #2 from Tavian Barnes  ---
Created attachment 38520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38520=edit
Further reduced testcase

> Please don't set regression markers if you don't know what you are doing (but
> feel free to suggest that something should have regression markers).
>
> Happens also in 5.3.0, 4.9.3 and 7.0, so not a regression.

Oops, sorry!  This only showed up in my actual build on upgrading to GCC 6, but
I didn't check the reduced version against older GCCs.

> If you could reduce the testcase further and point out at a missing
> optimization, the chances of getting this fixed would increase. Otherwise,
> someone needs to look at the dump files and figure out why the ranges are not
> affected by the check and whether they should.

I've attached a further reduced testcase.

> The 'else' block is not unreachable, but loop optimizations look at the 
> possible
> ranges within the loop and those may not be taking into account any range
> information derived from the caller.

The else block is unreachable *from within normalize()*.  And since the warning
only shows up due to constant propagation from normalize(), it would be nice to
avoid it.

Specifically, normalize() calls resize(length - 2) which calls (in the
unreached else block) append(n - length).  (n - length) gets constant-folded to
(size_t)-2 which then overflows a ptrdiff_t later.

[Bug c/71115] Missing warning: excess elements in struct initializer

[msebor at gcc dot gnu.org]

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

--- Comment #9 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01423.html

[Bug preprocessor/71183] [7 Regression] gcc -E always gives __DATE__ and __TIME__ as Jan 1 1970 00:00:00

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-18
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from David Malcolm  ---
Confirmed with trunk:

$ echo '__DATE__ __TIME__' | ./xgcc -B. -E -
# 1 ""
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 ""
"Jan  1 1970" "00:00:00"

[Bug c/71188] New: missing warning converting __builtin_offsetof and sizeof to pointer

[msebor at gcc dot gnu.org]

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

Bug ID: 71188
   Summary: missing warning converting __builtin_offsetof and
sizeof to pointer
   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: ---

I would expect the following test case to elicit at least three warnings, one
for each of the initializations.  GCC seems to treat the __builtin_offsetof and
sizeof result and as a literal zero and doesn't give a warning.  (Clang gives a
-Wnon-literal-null-conversion warning for the first two and a -Wint-conversion
for the last one).

$ cat u.cpp && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wall -Wextra -Wpedantic -xc u.cpp
struct S { int i; };

int a [0];

int *p = __builtin_offsetof (struct S, i);
int *q = sizeof a;
int *r = (char*)&((struct S*)0)->i - (char*)((struct S*)0);
u.cpp:3:5: warning: ISO C forbids zero-size array ‘a’ [-Wpedantic]
 int a [0];
 ^
u.cpp:7:10: warning: initialization makes pointer from integer without a cast
[-Wint-conversion]
 int *r = (char*)&((struct S*)0)->i - (char*)((struct S*)0);
  ^

[Bug c++/69672] Useless -Wenum-compare when comparing enum vaue against the same value in enum hack

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0
   Severity|normal  |enhancement

--- Comment #2 from Martin Sebor  ---
Unlike bug 69670 I think it makes sense to consider this change request for two
reasons: first, because when one of the enumerated types is anonymous it seems
like a good indication that its enumerators are intended to be used as poor
man's integer constants whose type doesn't matter, and second, because Clang
doesn't warn in this case.

$ cat u.cpp && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wall -Wextra -Wpedantic u.cpp
enum E { e };
enum { f = e };

int foo (E a)
{
  return a == f;
}
u.cpp: In function ‘int foo(E)’:
u.cpp:6:15: warning: comparison between ‘enum E’ and ‘enum’
[-Wenum-compare]
   return a == f;
   ^

[Bug libstdc++/71187] declval() can be implemented without requiring a template instantiation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-18
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Thanks, Eric. Ville pointed me to your LLVM bug report earlier, and I think
it's great.

[Bug c++/69670] Useless -Wenum-compare when comparing parallel enums in static_assert

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
The warning works as designed but in cases when it isn't useful it can be
suppressed either on the command line (-Wno-enum-compare) or using #pragma
diagnostic ignored "-Wenum-compare", or by casting one of the enumerators to
(for example) int.

[Bug libstdc++/71187] New: declval() can be implemented without requiring a template instantiation

[eric.niebler at gmail dot com]

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

Bug ID: 71187
   Summary: declval() can be implemented without requiring a
template instantiation
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.niebler at gmail dot com
  Target Milestone: ---

declval gets used *everywhere*. It doesn't need to instantiate a template.
Rather than:

  template
inline typename add_rvalue_reference<_Tp>::type
declval() noexcept
{
  static_assert(__declval_protector<_Tp>::__stop,
"declval() must not be used!");
  return __declval_protector<_Tp>::__delegate();
}

declval can be defined as:

  template
_Up
__declval(int);

  template
_Tp
__declval(long);

  template
auto declval() noexcept -> decltype(__declval<_Tp>(0))
{
  static_assert(__declval_protector<_Tp>::__stop,
"declval() must not be used!");
  return __declval_protector<_Tp>::__delegate();
}


In a large code base that makes heavy use of templates, this small change is a
measured 4% compile-time win (g++ (GCC) 5.x 20160302).

I think the as-if rule gives implementers enough latitude to make this change.

[Bug tree-optimization/71170] [7 Regression] ICE in rewrite_expr_tree, at tree-ssa-reassoc.c:3898

[kugan at gcc dot gnu.org]

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

--- Comment #7 from kugan at gcc dot gnu.org ---
Created attachment 38519
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38519=edit
Another way to fix

Thanks Martin Liška for looking into this. I am attaching another way to fox
this. Testing ongoing and will update once the results are available.

[Bug target/71186] New: PowerPC64: Autovectorised code hits ICE with -O3 -mpower9 -mlra

[anton at samba dot org]

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

Bug ID: 71186
   Summary: PowerPC64: Autovectorised code hits ICE with -O3
-mpower9 -mlra
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at samba dot org
  Target Milestone: ---

The following testcase:

static unsigned short x[(16384/sizeof(unsigned short))] __attribute__ ((aligned
(16)));
static unsigned short y[(16384/sizeof(unsigned short))] __attribute__ ((aligned
(16)));
static unsigned short a;

void obfuscate(void *a, ...);

static void __attribute__((noinline)) do_one(void)
{
 unsigned long i;

 obfuscate(x, y, );

 for (i = 0; i < (16384/sizeof(unsigned short)); i++)
  y[i] = a * x[i];

 obfuscate(x, y, );
}

int main(void)
{
 unsigned long i;

 for (i = 0; i < 100; i++)
  do_one();

 return 0;
}

built with:

gcc -O3 -Wall -mcpu=power9 -mlra testcase.c

gets an ICE:

scale_unsigned_short.c: In function ‘do_one’:
scale_unsigned_short.c:17:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 81 43 86 3 (set (reg:V8HI 77 0 [199])
(vec_duplicate:V8HI (const_int 0 [0]))) scale_unsigned_short.c:14 1045
{xxspltib_v8hi_nosplit}
 (expr_list:REG_EQUIV (const_vector:V8HI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
])
(nil)))
scale_unsigned_short.c:17:1: internal compiler error: in
extract_constrain_insn, at recog.c:2190
0x108211f3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x1082124b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:119
0x107e6f57 extract_constrain_insn(rtx_insn*)
../../gcc/gcc/recog.c:2190
0x106d5137 check_rtl
../../gcc/gcc/lra.c:2022
0x106daa8f lra(_IO_FILE*)
../../gcc/gcc/lra.c:2432
0x1067abab do_reload
../../gcc/gcc/ira.c:5381
0x1067abab execute
../../gcc/gcc/ira.c:5565

[Bug preprocessor/71183] [7 Regression] gcc -E always gives __DATE__ and __TIME__ as Jan 1 1970 00:00:00

[jrtc27 at jrtc27 dot com]

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

--- Comment #2 from James Clarke  ---
(In reply to Andrew Pinski from comment #1)
> Works on GCC 6.1.0 release:
> # 1 ""
> # 1 ""
> # 1 ""
> # 31 ""
> # 1
> "/data1/src/gcc-cavium/toolchain-6/thunderx-tools/aarch64-thunderx-linux-gnu/
> sys-root/usr/include/stdc-predef.h" 1 3 4
> # 32 "" 2
> # 1 ""
> "May 18 2016" "14:38:12"

My bad; Debian backported the commit to their gcc-6.

[Bug libstdc++/71181] Reserving in unordered_map doesn't reserve enough

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||fdumont at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  ---
François, this seems familiar to me but I couldn't find any other bug reports
from a very quick search  ... is this something you've looked at (and possibly
explained to me!) before?

[Bug preprocessor/71183] [7 Regression] gcc -E always gives __DATE__ and __TIME__ as Jan 1 1970 00:00:00

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Version|6.1.1   |7.0
   Target Milestone|--- |7.0
Summary|gcc -E always gives |[7 Regression] gcc -E
   |__DATE__ and __TIME__ as|always gives __DATE__ and
   |Jan  1 1970 00:00:00|__TIME__ as Jan  1 1970
   ||00:00:00

--- Comment #1 from Andrew Pinski  ---
Works on GCC 6.1.0 release:
# 1 ""
# 1 ""
# 1 ""
# 31 ""
# 1
"/data1/src/gcc-cavium/toolchain-6/thunderx-tools/aarch64-thunderx-linux-gnu/sys-root/usr/include/stdc-predef.h"
1 3 4
# 32 "" 2
# 1 ""
"May 18 2016" "14:38:12"

[Bug c++/71100] [6/7 regression] Internal compiler error while calling a pointer to member function that throws

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/71160] libasan: Backport support for malloc within dlsym

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed May 18 21:28:49 2016
New Revision: 236433

URL: https://gcc.gnu.org/viewcvs?rev=236433=gcc=rev
Log:
Backported from mainline
2016-05-17  Jakub Jelinek  

PR sanitizer/71160
* asan/asan_malloc_linux.cc: Cherry pick upstream r254395
and r269633.

Modified:
branches/gcc-5-branch/libsanitizer/ChangeLog
branches/gcc-5-branch/libsanitizer/asan/asan_malloc_linux.cc

[Bug sanitizer/71160] libasan: Backport support for malloc within dlsym

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Wed May 18 21:26:54 2016
New Revision: 236432

URL: https://gcc.gnu.org/viewcvs?rev=236432=gcc=rev
Log:
Backported from mainline
2016-05-17  Jakub Jelinek  

PR sanitizer/71160
* asan/asan_malloc_linux.cc: Cherry pick upstream r254395
and r269633.

Modified:
branches/gcc-6-branch/libsanitizer/ChangeLog
branches/gcc-6-branch/libsanitizer/asan/asan_malloc_linux.cc

[Bug c++/71100] [6/7 regression] Internal compiler error while calling a pointer to member function that throws

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed May 18 21:24:16 2016
New Revision: 236431

URL: https://gcc.gnu.org/viewcvs?rev=236431=gcc=rev
Log:
PR c++/71100
* cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Don't drop
lhs if it has TREE_ADDRESSABLE type.

* g++.dg/opt/pr71100.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/opt/pr71100.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/cgraph.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/71100] [6/7 regression] Internal compiler error while calling a pointer to member function that throws

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed May 18 21:23:07 2016
New Revision: 236430

URL: https://gcc.gnu.org/viewcvs?rev=236430=gcc=rev
Log:
PR c++/71100
* cgraph.c (cgraph_edge::redirect_call_stmt_to_callee): Don't drop
lhs if it has TREE_ADDRESSABLE type.

* g++.dg/opt/pr71100.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr71100.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/testsuite/ChangeLog

[Bug target/71185] New: ice in gimplify_modify_expr, at gimplify.c:4873

[dcb314 at hotmail dot com]

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

Bug ID: 71185
   Summary: ice in gimplify_modify_expr, at gimplify.c:4873
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 38518
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38518=edit
C source code

The attached source code, when compiled by gcc trunk dated 20160516,
also given compiler flags -c -O3 -march=native, does this:

$ ../results/bin/gcc -c -O3 -march=native bug286.c
In function ‘cubic_stage_fn’:
cc1: internal compiler error: in gimplify_modify_expr, at gimplify.c:4873
0x98d609 gimplify_modify_expr
../../src/trunk/gcc/gimplify.c:4872
0x977b74 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src/trunk/gcc/gimplify.c:10301
0x97a346 gimplify_stmt(tree_node**, gimple**)
../../src/trunk/gcc/gimplify.c:5699
0x97d000 gimplify_and_add(tree_node*, gimple**)
../../src/trunk/gcc/gimplify.c:427

Machine is

model name  : AMD Phenom(tm) II X4 970 Processor

[Bug c++/71184] ICE on "operator new["

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-18
 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
My bad; it's a read-through-NULL here:

13793   /* Look for the `]' token.  */
13794   end_loc = cp_parser_require (parser, CPP_CLOSE_SQUARE,
13795RT_CLOSE_SQUARE)->location;

Working on a fix.

[Bug middle-end/66110] uint8_t memory access not optimized

[palves at redhat dot com]

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

Pedro Alves  changed:

   What|Removed |Added

 CC||palves at redhat dot com

--- Comment #16 from Pedro Alves  ---
I ran into this, and thought that:

 typedef unsigned int __attribute__ ((__mode__(__byte__))) byte;

or:

 typedef unsigned int __attribute__ ((__mode__(QI))) byte;

might be syntax that already worked for creating an 8-bit type that doesn't
alias.  Alas, it does not work.  Maybe it should.

[Bug c++/71184] New: ICE on "operator new["

[rippey.e at gmail dot com]

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

Bug ID: 71184
   Summary: ICE on "operator new["
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rippey.e at gmail dot com
  Target Milestone: ---

Using g++ 6.1.0 on a file that contains just "operator new[" produces the
following error message:

int_286791631.cpp:1:13: internal compiler error: Segmentation fault
 operator new[
 ^
0xaf5d8f crash_signal
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/toplev.c:333
0x6821f0 cp_parser_operator
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:13796
0x6821f0 cp_parser_operator_function_id
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:13724
0x699d5b cp_parser_template_name
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:15049
0x699d5b cp_parser_template_id
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:14821
0x69b03a cp_parser_type_name
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:16376
0x68ca51 cp_parser_type_name
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:16347
0x68ca51 cp_parser_simple_type_specifier
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:16261
0x688ecd cp_parser_type_specifier
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:15914
0x69a9fc cp_parser_decl_specifier_seq
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:12760
0x6a4c41 cp_parser_simple_declaration
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:12301
0x6a50ba cp_parser_block_declaration
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:12248
0x6aae2e cp_parser_declaration
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:12145
0x6a98e6 cp_parser_declaration_seq_opt
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:12024
0x6a9be0 cp_parser_translation_unit
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:4323
0x6a9be0 c_parse_file()
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/cp/parser.c:37464
0x773542 c_common_parse_file()
/disk/0/erippey/gcc/objdir/../gcc-6.1.0/gcc/c-family/c-opts.c:1064
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug preprocessor/71183] New: gcc -E always gives __DATE__ and __TIME__ as Jan 1 1970 00:00:00

[jrtc27 at jrtc27 dot com]

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

Bug ID: 71183
   Summary: gcc -E always gives __DATE__ and __TIME__ as Jan  1
1970 00:00:00
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrtc27 at jrtc27 dot com
  Target Milestone: ---

The inclusion of the SOURCE_DATE_EPOCH patch (SVN revision 235550) broke
__DATE__ and __TIME__ when running the preprocessor on its own, as
pfile->source_date_epoch is only initialised in c_lex_with_flags, so
pfile->source_date_epoch is 0 when _cpp_builtin_macro_text is called, rather
than -1 (telling it to use the current time) or the true value of
SOURCE_DATE_EPOCH.

$ echo '__DATE__ __TIME__' | gcc -E -
# 1 ""
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 ""
"Jan  1 1970" "00:00:00"

[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to David Binderman from comment #2)

> The compiler only sees code that gets through the preprocessor.

> Still worth fixing, in my view. 2e9 bytes isn't a lot of source code these
> days.

In that case, I would say "not really". If you have any time to contribute to
GCC, there are plenty more important things that you could do with your time.
But there is no harm in keeping it open in case someone disagrees and decides
to fix it.

[Bug c++/71182] New: parser.c cp_lexer_previous_token sanitizer detects member call on null pointer

[zeccav at gmail dot com]

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

Bug ID: 71182
   Summary: parser.c cp_lexer_previous_token sanitizer detects
member call on null pointer
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

// ../../gcc7/gcc/cp/parser.c:766:7: runtime error: member call on null pointer
of type 'struct vec'
class A {
  template  void As();
};
template  class B : A {
  void f() {
A *g ;
g ? g->As() : nullptr;
  }
};

[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
(In reply to Manuel López-Ibáñez from comment #1)
> I wonder why GCC -Wformat does not catch this, since "static const char"
> literals contents should be visible as formatting strings. In this case, it
> doesn't even make sense to use a separate variable.

There is a much simpler explanation for this.

The compiler only sees code that gets through the preprocessor.

The code in question has

#ifdef DO_STATS

around it.

Still worth fixing, in my view. 2e9 bytes isn't a lot of source code these
days.

[Bug middle-end/71177] Spurious -Waggressive-loop-optimizations warning

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-18
 CC||manu at gcc dot gnu.org
Summary|[6 Regression] Spurious |Spurious
   |-Waggressive-loop-optimizat |-Waggressive-loop-optimizat
   |ions warning|ions warning
 Ever confirmed|0   |1
  Known to fail||5.3.0, 6.1.1, 7.0

--- Comment #1 from Manuel López-Ibáñez  ---
Please don't set regression markers if you don't know what you are doing (but
feel free to suggest that something should have regression markers).

Happens also in 5.3.0, 4.9.3 and 7.0, so not a regression.

If you could reduce the testcase further and point out at a missing
optimization, the chances of getting this fixed would increase. Otherwise,
someone needs to look at the dump files and figure out why the ranges are not
affected by the check and whether they should.

The 'else' block is not unreachable, but loop optimizations look at the
possible ranges within the loop and those may not be taking into account any
range information derived from the caller.

[Bug target/71145] Alpha: Error: No lda !gpdisp!278 was found

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #10 from Uroš Bizjak  ---
Fixed everywhere.

[Bug target/71145] Alpha: Error: No lda !gpdisp!278 was found

[uros at gcc dot gnu.org]

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

--- Comment #9 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed May 18 19:53:16 2016
New Revision: 236427

URL: https://gcc.gnu.org/viewcvs?rev=236427=gcc=rev
Log:
PR target/71145
* config/alpha/alpha.md (trap): Add (use (reg:DI 29)).
(*exception_receiver_1): Return "#" for TARGET_EXPLICIT_RELOCS.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/alpha/alpha.md

[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||easyhack
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-18
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
I wonder why GCC -Wformat does not catch this, since "static const char"
literals contents should be visible as formatting strings. In this case, it
doesn't even make sense to use a separate variable.

[Bug target/71145] Alpha: Error: No lda !gpdisp!278 was found

[uros at gcc dot gnu.org]

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

--- Comment #8 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed May 18 19:41:34 2016
New Revision: 236426

URL: https://gcc.gnu.org/viewcvs?rev=236426=gcc=rev
Log:
PR target/71145
* config/alpha/alpha.md (trap): Add (use (reg:DI 29)).
(*exception_receiver_1): Return "#" for TARGET_EXPLICIT_RELOCS.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/alpha/alpha.md

[Bug target/71145] Alpha: Error: No lda !gpdisp!278 was found

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed May 18 19:39:49 2016
New Revision: 236425

URL: https://gcc.gnu.org/viewcvs?rev=236425=gcc=rev
Log:
PR target/71145
* config/alpha/alpha.md (trap): Add (use (reg:DI 29)).
(*exception_receiver_1): Return "#" for TARGET_EXPLICIT_RELOCS.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/alpha/alpha.md

[Bug libstdc++/71181] Reserving in unordered_map doesn't reserve enough

[riad93 at mail dot ru]

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

Alexey Dmitriev  changed:

   What|Removed |Added

Version|5.1.0   |6.1.0

--- Comment #2 from Alexey Dmitriev  ---
Changing version to 6.1.0 because it's affected too

http://coliru.stacked-crooked.com/a/081723abb3d2cad6

[Bug c/71115] Missing warning: excess elements in struct initializer

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez  ---
(In reply to Martin Sebor from comment #7)
> Thanks, Manuel.  That does the trick.  Let me put a patch together.

Note also that the extra:

uu.c:3:26: note: (near initialization for ‘a’)

is just a relic of the no-caret era. Clang does not mention it and G++ simply
says:

too many initializers for 'const char* [1]'

which is more informative (although G++ location info is worse than in GCC).

[Bug libstdc++/71181] Reserving in unordered_map doesn't reserve enough

[riad93 at mail dot ru]

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

--- Comment #1 from Alexey Dmitriev  ---
in n4582 it's already not valid as they've change 23.2.5p15 to <=

[Bug libstdc++/71181] New: Reserving in unordered_map doesn't reserve enough

[riad93 at mail dot ru]

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

Bug ID: 71181
   Summary: Reserving in unordered_map doesn't reserve enough
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: riad93 at mail dot ru
  Target Milestone: ---

Code:

#include 
#include 
using namespace std;

int main() {
std::unordered_map x;
x.reserve(97);
std::cout << x.bucket_count() << std::endl;
for (int i = 0; i < 97; ++i) {
x[i] = 1;
}
std::cout << x.bucket_count() << std::endl;
}

it prints for me

97
199

It doesn't contradict my reading of the Standard but still counterintuitive.
If user reserves smth, he would expect no rehashes

Note, probably any prime will do.

Generally, for each as far as I understand rehashing happens when 
new_size >= buckets_count (multiplied by load_factor which is 1)

I propose changing >= to >

[Bug target/71145] Alpha: Error: No lda !gpdisp!278 was found

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed May 18 19:15:22 2016
New Revision: 236423

URL: https://gcc.gnu.org/viewcvs?rev=236423=gcc=rev
Log:
PR target/71145
* config/alpha/alpha.md (trap): Add (use (reg:DI 29)).
(*exception_receiver_1): Return "#" for TARGET_EXPLICIT_RELOCS.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/alpha/alpha.md

[Bug c/71115] Missing warning: excess elements in struct initializer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Thanks, Manuel.  That does the trick.  Let me put a patch together.

[Bug fortran/71156] PURE interface/definition inconsistency: accepts invalid, rejects valid

[damian at sourceryinstitute dot org]

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

--- Comment #2 from Damian Rouson  ---
Thanks!

D

> On May 18, 2016, at 12:18 AM, pault at gcc dot gnu.org 
>  wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71156
> 
> Paul Thomas  changed:
> 
>   What|Removed |Added
> 
> CC||pault at gcc dot gnu.org
>   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot 
> gnu.org
> 
> --- Comment #1 from Paul Thomas  ---
> I'll get on to it today.
> 
> Thanks for the report.
> 
> Paul
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug middle-end/71180] [7 Regression] r236373 breaks x86 exception handling

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||EH, wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-18
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed based on two different bug reports.

[Bug c++/71178] lots of C++ exception test failures on x86_64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 71180 which pinpoints the revision.

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

[Bug middle-end/71180] [7 Regression] r236373 breaks x86

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---
*** Bug 71178 has been marked as a duplicate of this bug. ***

[Bug middle-end/71180] New: [7 Regression] r236373 breaks x86

[hjl.tools at gmail dot com]

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

Bug ID: 71180
   Summary: [7 Regression] r236373 breaks x86
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: segher at gcc dot gnu.org, ubizjak at gmail dot com
  Target Milestone: ---
Target: x86

On x86, r236373 caused:

FAIL: 18_support/exception_ptr/lifespan.cc execution test
FAIL: 18_support/nested_exception/rethrow_if_nested.cc execution test
FAIL: 20_util/function/63840.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/char/stod.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/char/stof.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/char/stold.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/char/stoll.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/char/stoul.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/char/stoull.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stod.cc execution
test
FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stof.cc execution
test
FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stoi.cc execution
test
FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stol.cc execution
test
FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stold.cc execution
test
FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stoll.cc execution
test
FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stoul.cc execution
test
FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stoull.cc execution
test
FAIL: 22_locale/locale/cons/12352.cc execution test
FAIL: 22_locale/locale/cons/2.cc execution test
FAIL: 22_locale/numpunct/members/pod/2.cc execution test
FAIL: 23_containers/bitset/to_ulong/1.cc execution test
FAIL: 23_containers/deque/cons/2.cc execution test
FAIL: 23_containers/deque/requirements/exception/basic.cc execution test
FAIL: 23_containers/deque/requirements/exception/propagation_consistent.cc
execution test
FAIL: 23_containers/forward_list/requirements/exception/basic.cc execution test
FAIL:
23_containers/forward_list/requirements/exception/propagation_consistent.cc
execution test
FAIL: 23_containers/list/modifiers/insert/25288.cc execution test
FAIL: 23_containers/list/requirements/exception/basic.cc execution test
FAIL: 23_containers/list/requirements/exception/propagation_consistent.cc
execution test
FAIL: 23_containers/map/requirements/exception/basic.cc execution test
FAIL: 23_containers/map/requirements/exception/propagation_consistent.cc
execution test
FAIL: 23_containers/multimap/requirements/exception/basic.cc execution test
FAIL: 23_containers/multimap/requirements/exception/propagation_consistent.cc
execution test
FAIL: 23_containers/multiset/requirements/exception/basic.cc execution test
FAIL: 23_containers/multiset/requirements/exception/propagation_consistent.cc
execution test
FAIL: 23_containers/set/requirements/exception/basic.cc execution test
FAIL: 23_containers/set/requirements/exception/propagation_consistent.cc
execution test
FAIL: 23_containers/unordered_map/requirements/exception/basic.cc execution
test
FAIL:
23_containers/unordered_map/requirements/exception/propagation_consistent.cc
execution test
FAIL: 23_containers/unordered_multimap/requirements/exception/basic.cc
execution test
FAIL:
23_containers/unordered_multimap/requirements/exception/propagation_consistent.cc
execution test
FAIL: 23_containers/unordered_multiset/insert/hash_policy.cc execution test
FAIL: 23_containers/unordered_multiset/requirements/exception/basic.cc
execution test
FAIL:
23_containers/unordered_multiset/requirements/exception/propagation_consistent.cc
execution test
FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test
FAIL: 23_containers/unordered_set/max_load_factor/robustness.cc execution test
FAIL: 23_containers/unordered_set/requirements/exception/basic.cc execution
test
FAIL:
23_containers/unordered_set/requirements/exception/propagation_consistent.cc
execution test
FAIL: 23_containers/vector/capacity/2.cc execution test
FAIL: 23_containers/vector/cons/4.cc execution test
FAIL: 23_containers/vector/modifiers/push_back/strong_guarantee.cc execution
test
FAIL: 23_containers/vector/requirements/exception/basic.cc execution test
FAIL: 23_containers/vector/requirements/exception/propagation_consistent.cc
execution test
FAIL: 25_algorithms/stable_sort/mem_check.cc execution test
FAIL: 27_io/basic_istream/exceptions/char/9561.cc execution test
FAIL: 27_io/basic_istream/exceptions/wchar_t/9561.cc execution test
FAIL: 

[Bug target/71179] [7 Regression] ice fold_convert_loc, at fold-const.c:2360

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-18
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ice fold_convert_loc, at|[7 Regression] ice
   |fold-const.c:2360   |fold_convert_loc, at
   ||fold-const.c:2360
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug target/71179] New: ice fold_convert_loc, at fold-const.c:2360

[dcb314 at hotmail dot com]

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

Bug ID: 71179
   Summary: ice fold_convert_loc, at fold-const.c:2360
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

The attached C code, when compiled by gcc trunk dated 20160518
and the flags -funsafe-math-optimizations -O2  -msse4.1 does this

../../plugins/dcp/dcp-sse4.c: In function ‘render_SSE4’:
../../plugins/dcp/dcp-sse4.c:356:1: internal compiler error: in
fold_convert_loc, at fold-const.c:2360
0x901dc9 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../src/trunk/gcc/fold-const.c:2360
0xe0c79b transform_add_to_multiply
../../src/trunk/gcc/tree-ssa-reassoc.c:1815
0xe0c79b reassociate_bb
../../src/trunk/gcc/tree-ssa-reassoc.c:5190
0xe0af4f reassociate_bb
../../src/trunk/gcc/tree-ssa-reassoc.c:5278

[Bug c++/71178] New: lots of C++ exception test failures on x86_64

[msebor at gcc dot gnu.org]

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

Bug ID: 71178
   Summary: lots of C++ exception test failures on x86_64
   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: ---

I'm seeing lots of C++ execution tests fail ox x86_64 with today's trunk,
similar to (or the same as) those reported here for revision 236373:

https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg01935.html

The following build of revision 236357 looks much better:
https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg01923.html

A small subset of the failures I'm seeing is below:

FAIL: g++.old-deja/g++.eh/vbase1.C  -std=c++14 execution test
FAIL: g++.old-deja/g++.eh/vbase2.C  -std=c++14 execution test
FAIL: g++.old-deja/g++.jason/thunk3.C  -std=c++14 execution test
FAIL: g++.old-deja/g++.robertl/eh990323-5.C  -std=c++14 execution test
FAIL: g++.dg/cpp0x/bad_array_new2.C  -std=c++14 execution test
FAIL: g++.dg/eh/ctor1.C  -std=c++14 execution test
FAIL: g++.dg/eh/delete1.C  -std=c++14 execution test
FAIL: g++.dg/eh/uncaught4.C  -std=c++14 execution test
FAIL: g++.dg/eh/unexpected1.C  -std=c++14 execution test
FAIL: g++.dg/init/ctor1.C  -std=c++14 execution test
FAIL: g++.old-deja/g++.eh/fntry1.C  -std=c++14 execution test
FAIL: g++.dg/cpp0x/initlist90.C  -std=c++14 execution test
FAIL: g++.dg/init/array5.C  -std=c++14 execution test
FAIL: g++.old-deja/g++.eh/spec2.C  -std=c++14 execution test
FAIL: g++.old-deja/g++.eh/spec3.C  -std=c++14 execution test
FAIL: g++.old-deja/g++.other/singleton.C  -std=c++14 execution test
FAIL: g++.old-deja/g++.other/init7.C  -std=c++14 execution test
FAIL: g++.old-deja/g++.robertl/eh990323-1.C  -std=c++14 execution test

[Bug c++/70505] [4.9/5 Regression] Constexpr failure when template type specified

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed May 18 17:40:49 2016
New Revision: 236420

URL: https://gcc.gnu.org/viewcvs?rev=236420=gcc=rev
Log:
PR c++/70505 - partial instantiation of template-id

* pt.c (tsubst_baselink): Give the new TEMPLATE_ID_EXPR
unknown_type_node, too.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-template10.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/pt.c

[Bug tree-optimization/71031] [6/7 Regression] ICE in extract_range_from_binary_expr_1, at tree-vrp.c:2535 w/ -Os

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
To expand a bit on Comment 4: we have [1, od_5] + UINT_MAX on type unsigned and
are in extract_range_from_binary_expr_1.  We combine the lower bounds, which is
1 + UINT_MAX = 0(OVF).  We  then combine the upper bounds, because the max_op0
is not a constant, the result of that is UINT_MAX.  So WMIN is 0(OVF) and WMAX
is UINT_MAX.  These are equal to TYPE_MIN and TYPE_MAX, respectively.  What to
do with that, drop to VR_VARYING if we have min overflow or max underflow?

Richi/Jakub, any ideas?  I'm kinda stuck here :(.

[Bug c++/70466] [ICE on invalid code in tree check: expected constructor, have parm_decl in convert_like_real, at cp/call.c:6371 with -std=c++11

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  ---
Fixed for 6.2 too.

[Bug c++/70466] [ICE on invalid code in tree check: expected constructor, have parm_decl in convert_like_real, at cp/call.c:6371 with -std=c++11

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed May 18 17:17:03 2016
New Revision: 236419

URL: https://gcc.gnu.org/viewcvs?rev=236419=gcc=rev
Log:
/cp
2016-05-18  Paolo Carlini  

PR c++/70466
* call.c (convert_like_real): Check that we are actually converting
from an init list.

/testsuite
2016-05-18  Paolo Carlini  

PR c++/70466
* g++.dg/template/pr70466-1.C: New.
* g++.dg/template/pr70466-2.C: Likewise.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/template/pr70466-1.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/template/pr70466-2.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/call.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug ipa/69708] ipa inline not working for function reference in static const struct

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Jambor  ---
We should now be inlining as desired in the testcase.

[Bug ipa/69708] ipa inline not working for function reference in static const struct

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  ---
Author: jamborm
Date: Wed May 18 16:44:08 2016
New Revision: 236418

URL: https://gcc.gnu.org/viewcvs?rev=236418=gcc=rev
Log:
Allow constant global VAR_DECLs in constant jump functions

2016-05-18  Martin Jambor  

PR ipa/69708
* ipa-cp.c (ipa_get_jf_pass_through_result): Allow non-ip constant
input for NOP_EXPR pass-through functions.
* ipa-prop.c (ipa_compute_jump_functions_for_edge): Allow
aggregate global constant VAR_DECLs in constant jump functions.

testsuite/
* gcc.dg/ipa/iinline-cstagg-2.c: New test.
* gcc.dg/ipa/ipcp-cstagg-5.c: Likewise.
* gcc.dg/ipa/ipcp-cstagg-6.c: Likewise.
* gcc.dg/ipa/ipcp-cstagg-7.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.dg/ipa/iinline-cstagg-2.c
trunk/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-5.c
trunk/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-6.c
trunk/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/ipa-prop.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/69708] ipa inline not working for function reference in static const struct

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  ---
Author: jamborm
Date: Wed May 18 16:41:19 2016
New Revision: 236417

URL: https://gcc.gnu.org/viewcvs?rev=236417=gcc=rev
Log:
Const parameters are always unmodified

2016-05-18  Martin Jambor  

PR ipa/69708
* ipa-prop.c (parm_preserved_before_stmt_p): Return true for loads
from TREE_READONLY parameters.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c

[Bug ipa/69708] ipa inline not working for function reference in static const struct

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  ---
Author: jamborm
Date: Wed May 18 16:38:56 2016
New Revision: 236416

URL: https://gcc.gnu.org/viewcvs?rev=236416=gcc=rev
Log:
Indirect inlining of targets from references of global constants

2016-05-18  Martin Jambor  

PR ipa/69708
* cgraph.h (cgraph_indirect_call_info): New field
guaranteed_unmodified.
* ipa-cp.c (ipa_get_indirect_edge_target_1): Also pass parameter value
to ipa_find_agg_cst_for_param, check guaranteed_unmodified when
appropriate.
* ipa-inline-analysis.c (evaluate_conditions_for_known_args): Also
pass the parameter value to ipa_find_agg_cst_for_param.
* ipa-prop.c (ipa_load_from_parm_agg): New parameter
guaranteed_unmodified, store AA results there instead of bailing out
if present.
(ipa_note_param_call): Also initialize guaranteed_unmodified flag.
(ipa_analyze_indirect_call_uses): Also set guaranteed_unmodified flag.
(find_constructor_constant_at_offset): New function.
(ipa_find_agg_cst_from_init): Likewise.
(ipa_find_agg_cst_for_param): Also seearch for aggregate values in
static initializers of contants, report back through a new paameter
from_global_constant if that was the case.
(try_make_edge_direct_simple_call): Also pass parameter value to
ipa_find_agg_cst_for_param, check guaranteed_unmodified when
appropriate.
(ipa_write_indirect_edge_info): Stream new flag guaranteed_unmodified.
(ipa_read_indirect_edge_info): Likewise.
* ipa-prop.h (ipa_find_agg_cst_for_param): Update declaration.
(ipa_load_from_parm_agg): Likewise.

testsuite/
* gcc.dg/ipa/iinline-cstagg-1.c: New test.
* gcc.dg/ipa/ipcp-cstagg-1.c: Likewise.
* gcc.dg/ipa/ipcp-cstagg-2.c: Likewise.
* gcc.dg/ipa/ipcp-cstagg-3.c: Likewise.
* gcc.dg/ipa/ipcp-cstagg-4.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.dg/ipa/iinline-cstagg-1.c
trunk/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-1.c
trunk/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-2.c
trunk/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-3.c
trunk/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.h
trunk/gcc/ipa-cp.c
trunk/gcc/ipa-inline-analysis.c
trunk/gcc/ipa-prop.c
trunk/gcc/ipa-prop.h
trunk/gcc/testsuite/ChangeLog

[Bug c++/69793] ICE on invalid code in "cp_lexer_peek_nth_token"

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  ---
Fixed in trunk.

[Bug c++/69793] ICE on invalid code in "cp_lexer_peek_nth_token"

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed May 18 16:26:35 2016
New Revision: 236414

URL: https://gcc.gnu.org/viewcvs?rev=236414=gcc=rev
Log:
/cp
2016-05-18  Paolo Carlini  

PR c++/69793
* parser.c (cp_parser_template_id): Don't call cp_lexer_peek_nth_token
when the previous cp_lexer_peek_token returns CPP_EOF.

/testsuite
2016-05-18  Paolo Carlini  

PR c++/69793
* g++.dg/template/crash122.C: New.

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

[Bug middle-end/71177] New: [6 Regression] Spurious -Waggressive-loop-optimizations warning

[tavianator at gmail dot com]

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

Bug ID: 71177
   Summary: [6 Regression] Spurious
-Waggressive-loop-optimizations warning
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tavianator at gmail dot com
  Target Milestone: ---

Created attachment 38516
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38516=edit
Reduced testcase

The following use of boost::container::string gives a warning since GCC 6:

$ cat stringbug.cpp
#include 

using boost::container::string;

string normalize(string token)
{
  if (token.length() >= 2) {
token.resize(token.length() - 2);
  }
  return token;
}
$ g++ -Wall -O3 -c stringbug.cpp
In function ‘boost::container::string normalize(boost::container::string)’:
cc1plus: warning: iteration 9223372036854775807 invokes undefined behavior
[-Waggressive-loop-optimizations]
In file included from stringbug.cpp:1:0:
/usr/include/boost/container/string.hpp:2608:10: note: within this loop
  for (; first != last; ++dest, ++first, ++constructed){
  ^~~
cc1plus: warning: iteration 9223372036854775807 invokes undefined behavior
[-Waggressive-loop-optimizations]
/usr/include/boost/container/string.hpp:2626:7: note: within this loop
   for ( ; first != last; ++first, ++result)
   ^~~

What's happening is that resize() is implemented like this:

   void resize(size_type n, CharT c)
   {
  if (n <= this->size())
 this->erase(this->begin() + n, this->end());
  else
 this->append(n - this->size(), c);
   }

After inlining/constant propagation, the else block contains undefined
behaviour for resize(length - 2).  But the else block is also unreachable due
to the if (length >= 2) check.

Reduced testcase attached.

[Bug target/71161] [7 Regression] Lots of ASAN and libgo runtime FAILs after r236090

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords|wrong-code  |
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|7.0 |4.9.4

--- Comment #18 from Uroš Bizjak  ---
Fixed everywhere.

[Bug target/71161] [7 Regression] Lots of ASAN and libgo runtime FAILs after r236090

[uros at gcc dot gnu.org]

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

--- Comment #17 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed May 18 16:00:43 2016
New Revision: 236412

URL: https://gcc.gnu.org/viewcvs?rev=236412=gcc=rev
Log:
PR target/71161
* elf.c (phdr_callback) [__i386__]: Add
__attribute__((__force_align_arg_pointer__)).


Modified:
branches/gcc-4_9-branch/libbacktrace/ChangeLog
branches/gcc-4_9-branch/libbacktrace/elf.c

[Bug c++/70505] [4.9/5 Regression] Constexpr failure when template type specified

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed May 18 15:59:19 2016
New Revision: 236411

URL: https://gcc.gnu.org/viewcvs?rev=236411=gcc=rev
Log:
PR c++/70505 - partial instantiation of template-id

* pt.c (tsubst_baselink): Give the new TEMPLATE_ID_EXPR
unknown_type_node, too.

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

[Bug c++/70494] [5 regression] Internal Compiler Error: Capturing an array of vectors in a lambda

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed May 18 15:59:13 2016
New Revision: 236410

URL: https://gcc.gnu.org/viewcvs?rev=236410=gcc=rev
Log:
PR c++/70494 - lambda capture of array

* decl.c (cxx_maybe_build_cleanup): Handle non-decls.
* typeck2.c (split_nonconstant_init_1): Use it.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-array2.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/decl.c
branches/gcc-5-branch/gcc/cp/typeck2.c

[Bug c++/70095] [C++14] Link error on partially specialized variable template

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed May 18 15:58:54 2016
New Revision: 236407

URL: https://gcc.gnu.org/viewcvs?rev=236407=gcc=rev
Log:
PR c++/70095 - variable template partial specialization

* pt.c (instantiate_decl): Fix call to variable_template_p.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ50.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/pt.c

[Bug c++/70353] [5 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function

[jason at gcc dot gnu.org]

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

--- Comment #22 from Jason Merrill  ---
Author: jason
Date: Wed May 18 15:59:00 2016
New Revision: 236408

URL: https://gcc.gnu.org/viewcvs?rev=236408=gcc=rev
Log:
PR c++/70353 - __func__ and constexpr

gcc/
* tree-inline.c (remap_decls): Don't add_local_decl if
cfun is null.
gcc/cp/
* decl.c (make_rtl_for_nonlocal_decl): Don't defer local statics
in constexpr functions.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-__func__2.C
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/decl.c
branches/gcc-5-branch/gcc/tree-inline.c

[Bug c++/70648] [6 Regression] adplug-xmms fails to compile

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed May 18 15:59:05 2016
New Revision: 236409

URL: https://gcc.gnu.org/viewcvs?rev=236409=gcc=rev
Log:
PR c++/70648 - constexpr empty list-initialization

* constexpr.c (cxx_eval_store_expression): Also copy
CONSTRUCTOR_NO_IMPLICIT_ZERO.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-initlist10.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/constexpr.c

[Bug libstdc++/68739] FAIL: 30_threads/call_once/constexpr.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I suspect the problem might be that the definition of PTHREAD_MUTEX_INITIALIZER
causes a narrowing conversion, but it's hard to know because the diagnostic
seems to be missing the reason.

[Bug c++/71147] [6 Regression] Flexible array member wrongly rejected in template

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #3 from Martin Sebor  ---
There is code to handle this case in instantiate_class_template_1 but it's not
quite correct.  It assumes that the the array element type has been completed
which in this case isn't a safe assumption.  Let me fix this.

A slightly simpler test case is below:

$ cat xx.cpp && gcc -S -Wall -Wextra -Wpedantic xx.cpp
template 
struct container
{
  struct elem {
unsigned u;
  };
  struct incomplete {
int x;
elem array[];
  };
};

unsigned f (container::incomplete* i)
{
  return i->array [0].u;
}
xx.cpp: In instantiation of ‘struct container::incomplete’:
xx.cpp:15:11:   required from here
xx.cpp:9:16: error: ‘container<  >::incomplete::array’
has incomplete type
 elem array[];
^
xx.cpp:9:16: error: invalid use of array with unspecified bounds

[Bug target/71161] [7 Regression] Lots of ASAN and libgo runtime FAILs after r236090

[uros at gcc dot gnu.org]

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

--- Comment #16 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed May 18 15:45:08 2016
New Revision: 236404

URL: https://gcc.gnu.org/viewcvs?rev=236404=gcc=rev
Log:
PR target/71161
* elf.c (phdr_callback) [__i386__]: Add
__attribute__((__force_align_arg_pointer__)).


Modified:
branches/gcc-5-branch/libbacktrace/ChangeLog
branches/gcc-5-branch/libbacktrace/elf.c

[Bug c/71176] New: trunk/fixincludes/fixincl.c:162: bad % specifier

[dcb314 at hotmail dot com]

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

Bug ID: 71176
   Summary: trunk/fixincludes/fixincl.c:162: bad % specifier
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

trunk/fixincludes/fixincl.c:162]: (warning) %d in format string (no. 2)
requires 'int' but the argument type is 'size_t {aka unsigned long}'.

Source code is

tSCC zFmt[] =
  "\
Processed %5d files containing %d bytes\n\
Applying  %5d fixes to %d files\n\
Altering  %5d of them\n";

fprintf (stderr, zFmt, process_ct, ttl_data_size, apply_ct,
 fixed_ct, altered_ct);

Suggest use %lu for size_t, not %d.

[Bug target/69857] gcc/config/arm/arm.c:15949: return in strange place ?

[ktkachov at gcc dot gnu.org]

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

--- Comment #9 from ktkachov at gcc dot gnu.org ---
(In reply to David Binderman from comment #8)
> (In reply to ktkachov from comment #7)
> > Yes, that's an approach that can be taken. Once such a case is found, you
> > could also try using a reducer program like creduce to create a small
> > testcase appropriate for the testsuite.
> > 
> > Removing the return there would probably be an optimisation, which is why I
> > recommended it for GCC 7. GCC 6 is now in a regression fixing stage, so for
> > it to go in now we would need to find a testcase where we were performing an
> > optimisation before r197530 and after r197530 (with the bogus return) we
> > stopped doing. Considering that r197530 was supposed to introduce that
> > optimisation, it's unlikely that such a case can be found.
> 
> GCC 6 has been produced. Time to remove this return ?

Yes, would you like to propose a patch to gcc-patches?
Or shall I do it?

[Bug target/71175] trunk/gcc/config/arm/arm.c: 2 * minor printf problems ?

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||easyhack
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-18
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed, should be trivial to fix.

[Bug target/69857] gcc/config/arm/arm.c:15949: return in strange place ?

[dcb314 at hotmail dot com]

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

--- Comment #10 from David Binderman  ---
(In reply to ktkachov from comment #9)
> Yes, would you like to propose a patch to gcc-patches?

No thanks.

> Or shall I do it?

I would very much prefer that.

[Bug c++/71174] [concepts] Segmentation fault while processing concepts error

[t at sharklasers dot com]

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

--- Comment #3 from JD  ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=local/gcc6.1/lib/gcc/x86_64-pc-linux-gnu/6.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-6.1.0/configure --prefix=local/gcc6.1
--enable-languages=c,c++,fortran --enable-gold=yes --enable-ld=yes --enable-lto
--enable-bootstrap --disable-multilib
Thread model: posix
gcc version 6.1.0 (GCC)

[Bug target/71175] New: trunk/gcc/config/arm/arm.c: 2 * minor printf problems ?

[dcb314 at hotmail dot com]

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

Bug ID: 71175
   Summary: trunk/gcc/config/arm/arm.c: 2 * minor printf problems
?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

1.

[trunk/gcc/config/arm/arm.c:22753]: (warning) %u in format string (no. 2)
requires 'unsigned int' but the argument type is 'int'.

Source code is

 sprintf (buf, "%s.%.5u",
   is_ctor ? ".init_array" : ".fini_array",
   priority);

but

arm_elf_asm_cdtor (rtx symbol, int priority, bool is_ctor)

2.

[trunk/gcc/config/arm/arm.c:26983]: (warning) %d in format string (no. 1)
requires 'int' but the argument type is 'unsigned int'.

Source code is 

fprintf (asm_out_file, "\t.pad #%d\n", padfirst);

but

  unsigned padfirst = 0, padlast = 0;

[Bug c++/71174] segmentation fault

[t at sharklasers dot com]

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

--- Comment #2 from JD  ---
$ g++ -std=c++1z -Wall -Wextra -fconcepts bug.cpp
bug.cpp:10:32: error: concept ‘constexpr bool InputIterator(T)’ declared with
function parameters
 concept bool InputIterator(T it) {
^
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug target/69857] gcc/config/arm/arm.c:15949: return in strange place ?

[dcb314 at hotmail dot com]

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

--- Comment #8 from David Binderman  ---
(In reply to ktkachov from comment #7)
> Yes, that's an approach that can be taken. Once such a case is found, you
> could also try using a reducer program like creduce to create a small
> testcase appropriate for the testsuite.
> 
> Removing the return there would probably be an optimisation, which is why I
> recommended it for GCC 7. GCC 6 is now in a regression fixing stage, so for
> it to go in now we would need to find a testcase where we were performing an
> optimisation before r197530 and after r197530 (with the bogus return) we
> stopped doing. Considering that r197530 was supposed to introduce that
> optimisation, it's unlikely that such a case can be found.

GCC 6 has been produced. Time to remove this return ?

[Bug c++/71174] segmentation fault

[t at sharklasers dot com]

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

--- Comment #1 from JD  ---
Created attachment 38515
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38515=edit
Short example

[Bug c++/71166] [6/7 Regression] ICE with nested constexpr/initializer

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Created attachment 38514
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38514=edit
slightly more reduced test case

We're invoking constexpr evaluation machinery after parsing is complete --
fini_constexpt has already been called.  This occurs during the emission of
BarContainer's constructor, after we've destructively gimplified MakeFoo.  We
end up in

0xa05bf2 maybe_constant_init(tree_node*, tree_node*)
../../../src/gcc/cp/constexpr.c:4457
0x929ce6 build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int)
../../../src/gcc/cp/init.c:4178
0x9db06b cp_gimplify_expr(tree_node**, gimple**, gimple**)
../../../src/gcc/cp/cp-gimplify.c:592

and from there we have const_expr_eval (Bar) -> const_expr_eval (MakeFoo) ->
ICE
The object we're gimplifying is a vec_init_expr

[Bug c++/71174] New: segmentation fault

[t at sharklasers dot com]

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

Bug ID: 71174
   Summary: segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t at sharklasers dot com
  Target Milestone: ---

[Bug target/70670] Duplicate code in rs6000_secondary_reload_direct_move in rs6000.c

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #2 from Michael Meissner  ---
Fixed in subversion id 236394.

[Bug target/70915] Improve loading 0/-1 in VSX registers on PowerPC

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org

--- Comment #2 from Michael Meissner  ---
Fixed in subversion id 236394.

[Bug c++/71173] New: [6 regression] Qualified name lookup

[Casey at Carter dot net]

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

Bug ID: 71173
   Summary: [6 regression] Qualified name lookup
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

This program should compile without error:

namespace foo {
  namespace bar {
class foo {};
  }
  class baz {};
}
using namespace foo::bar;
::foo::baz mybaz;

but GCC 6 reports (http://melpon.org/wandbox/permlink/2n9QQUT0UIXog2Cj):

prog.cc:9:8: error: 'baz' in 'class foo::bar::foo' does not name a type
 ::foo::baz mybaz;
^~~

The name `::foo` should refer to the namespace `::foo`, not to the class
`::foo::bar::foo` per [namespace.qual]/2:

For a namespace X and name m, the namespace-qualified lookup set S(X,m) is
defined as follows: Let S0(X,m) be the set of all declarations of m in X and
the inline namespace set of X (7.3.1). If S0(X,m) is not empty, S(X,m) is
S0(X,m); otherwise, S(X,m) is the union of S(Ni,m) for all namespaces Ni
nominated by using-directives in X and its inline namespace set.

S0(::,foo) is not empty, so namespaces nominated by using-directives should
never be examined.

[Bug target/71161] [7 Regression] Lots of ASAN and libgo runtime FAILs after r236090

[uros at gcc dot gnu.org]

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

--- Comment #15 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed May 18 14:48:40 2016
New Revision: 236398

URL: https://gcc.gnu.org/viewcvs?rev=236398=gcc=rev
Log:
PR target/71161
* elf.c (phdr_callback) [__i386__]: Add
__attribute__((__force_align_arg_pointer__)).


Modified:
branches/gcc-6-branch/libbacktrace/ChangeLog
branches/gcc-6-branch/libbacktrace/elf.c

[Bug middle-end/71172] [7 Regression] FAIL: gcc.dg/tree-ssa/slsr-30.c (internal compiler error)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-18
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
This happens on x86-64.

[Bug target/71161] [7 Regression] Lots of ASAN and libgo runtime FAILs after r236090

[uros at gcc dot gnu.org]

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

--- Comment #14 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed May 18 14:40:54 2016
New Revision: 236397

URL: https://gcc.gnu.org/viewcvs?rev=236397=gcc=rev
Log:
PR target/71161
* elf.c (phdr_callback) [__i386__]: Add
__attribute__((__force_align_arg_pointer__)).


Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/elf.c

[Bug debug/71171] [6/7 Regression] Conditional jump or move depends on uninitialised value(s) in can_be_stored_compactly_p (line-map.c:148)

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-18
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug rtl-optimization/71150] [7 Regression] ICE on valid code at -O1 and above in 64-bit mode on x86_64-linux-gnu in lra_eliminate_reg_if_possible, at lra-eliminations.c:1402

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

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

--- Comment #4 from Jiong Wang  ---
fixed.