[Bug c++/66467] New: [6 Regression] ICE: Error reporting routines re-entered.

[trippels at gcc dot gnu.org]

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

Bug ID: 66467
   Summary: [6 Regression] ICE: Error reporting routines
re-entered.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

trippels@gcc2-power8 tools % cat test.ii
template  struct A { typedef int type; };
struct B {
  static const int value = 0;
};
template  struct C { typedef int type; };
template  struct F : B {};
class D {
  template 
  typename A::type>::value || B::value>::type
  operator=(Expr);
};
void fn1() {
  D opt;
  opt = 0;
}

trippels@gcc2-power8 tools % g++ -c test.ii
‘
Internal compiler error: Error reporting routines re-entered.
0x10438cbf warn_logical_operator(unsigned int, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*)
../../gcc/gcc/c-family/c-common.c:1848
0x1018967f build_new_op_1
../../gcc/gcc/cp/call.c:5669
0x1018a58f build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc/gcc/cp/call.c:5738
0x1030af83 build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
../../gcc/gcc/cp/typeck.c:3811
0x10218eef tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14776
0x101f667b tsubst_expr
../../gcc/gcc/cp/pt.c:14398
0x1020b22f tsubst_template_arg
../../gcc/gcc/cp/pt.c:9684
0x10204cbb tsubst_template_args
../../gcc/gcc/cp/pt.c:10246
0x1020e423 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:10443
0x1020826b tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12412
0x10298287 dump_template_bindings
../../gcc/gcc/cp/error.c:353
0x10298287 dump_substitution
../../gcc/gcc/cp/error.c:1432
0x102a911b decl_to_string
../../gcc/gcc/cp/error.c:2894
0x102a911b cp_printer
../../gcc/gcc/cp/error.c:3475
0x111a3393 pp_format(pretty_printer*, text_info*)
../../gcc/gcc/pretty-print.c:613
0x1119fa13 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/gcc/diagnostic.c:916
0x111a051f error(char const*, ...)
../../gcc/gcc/diagnostic.c:1187
0x1016d07f enforce_access(tree_node*, tree_node*, tree_node*, int)
../../gcc/gcc/cp/call.c:6049
0x10365b03 perform_or_defer_access_check(tree_node*, tree_node*, tree_node*,
int)
../../gcc/gcc/cp/semantics.c:343
0x10173bcf build_over_call
../../gcc/gcc/cp/call.c:7139
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug debug/66468] New: [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[marxin at gcc dot gnu.org]

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

Bug ID: 66468
   Summary: [6 Regression] ICE in in check_die, at
dwarf2out.c:5719
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 35721
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35721&action=edit
Source files

Hello.

Starting from Aldy's merge of debug-early branch (r224161) I see following ICE:

c.ii:12:5: internal compiler error: in check_die, at dwarf2out.c:5719
 }
 ^
0x809612 check_die
../../gcc/dwarf2out.c:5715
0x82bcc0 dwarf2out_decl
../../gcc/dwarf2out.c:21886
0x82bcdd dwarf2out_function_decl
../../gcc/dwarf2out.c:21894
0x89df28 rest_of_handle_final
../../gcc/final.c:4505
0x89e094 execute
../../gcc/final.c:4547

Reproduction:
./build.sh

Thanks,
Martin

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 35722
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35722&action=edit
Build script

[Bug c++/66467] [6 Regression] ICE: Error reporting routines re-entered.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I think this is a dup of PR65882.  A patch for that one was posted:
.

[Bug tree-optimization/66396] [6 regression] FAIL: gcc.dg/graphite/run-id-pr47593.c execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Tue Jun  9 07:51:24 2015
New Revision: 224266

URL: https://gcc.gnu.org/viewcvs?rev=224266&root=gcc&view=rev
Log:
2015-06-09  Richard Biener  

PR tree-optimization/66396
* graphite-isl-ast-to-gimple.c (graphite_regenerate_ast_isl):
Rename virtual operands.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c

[Bug c++/66467] [6 Regression] ICE: Error reporting routines re-entered.

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Marek Polacek from comment #1)
> I think this is a dup of PR65882.  A patch for that one was posted:
> .

Thanks. The patch fixes the issue.

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

[Bug c++/65882] [5/6 Regression] Internal compiler error: Error reporting routines re-entered

[trippels at gcc dot gnu.org]

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

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

[Bug tree-optimization/66413] [6 Regression] ICE at -Os and above with -g enabled on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Jun  9 08:06:17 2015
New Revision: 224267

URL: https://gcc.gnu.org/viewcvs?rev=224267&root=gcc&view=rev
Log:
2015-06-09  Richard Biener  

PR middle-end/66413
* tree-inline.c (insert_init_debug_bind): Unshare value.

* gcc.dg/torture/pr66413.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr66413.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c

[Bug target/66469] New: config/rl78/rl78.c:679: possible bad array index ?

[dcb314 at hotmail dot com]

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

Bug ID: 66469
   Summary: config/rl78/rl78.c:679: possible bad array index ?
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

[trunk/gcc/config/rl78/rl78.c:679]: (style) Array index 'regno' is used before
limits check.

   if (!crtl->is_leaf && call_used_regs[regno] && regno < 22)

Possible minor tidy up to put the sanity check before the use.

[Bug target/61074] internal compiler error: in extract_insn, at recog.c:2109

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Marek Polacek  ---
Feedback not coming.

[Bug tree-optimization/66396] [6 regression] FAIL: gcc.dg/graphite/run-id-pr47593.c execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
Fixed.

[Bug tree-optimization/66419] [6 regression] FAIL: gcc.target/aarch64/aapcs64/va_arg-6.c execution, -O3 -g

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Jun  9 08:22:20 2015
New Revision: 224271

URL: https://gcc.gnu.org/viewcvs?rev=224271&root=gcc&view=rev
Log:
2015-06-09  Richard Biener  

PR tree-optimization/66419
* tree-vect-slp.c (vect_supported_load_permutation_p): Properly
consider GROUP_GAP when detecting a perfect subchain.

* gcc.dg/vect/bb-slp-37.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-37.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"

[rguenth at gcc dot gnu.org]

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

Bug 66396 Summary: [6 regression] FAIL: gcc.dg/graphite/run-id-pr47593.c 
execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66396

   What|Removed |Added

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

[Bug tree-optimization/66413] [4.8/4.9/5 Regression] ICE at -Os and above with -g enabled on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
   Target Milestone|6.0 |4.8.5
Summary|[6 Regression] ICE at -Os   |[4.8/4.9/5 Regression] ICE
   |and above with -g enabled   |at -Os and above with -g
   |on x86_64-linux-gnu |enabled on x86_64-linux-gnu

--- Comment #5 from Richard Biener  ---
Fixed on trunk - I'm going to schedule this for a backport as such issues can
cause strange GC related issues.  It should be latent everywhere.

[Bug tree-optimization/66419] [6 regression] FAIL: gcc.target/aarch64/aapcs64/va_arg-6.c execution, -O3 -g

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug tree-optimization/66422] [5 Regression] -Warray-bounds false positive with -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[5/6 Regression]|[5 Regression]
   |-Warray-bounds false|-Warray-bounds false
   |positive with -O3   |positive with -O3
  Known to fail||5.1.0

--- Comment #7 from Richard Biener  ---
Fixed on trunk sofar.

[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
> Created attachment 35718
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35718&action=edit
> Tentative patch for issue #3

The patch does not fix the

../../work/gcc/ipa-pure-const.c:1636:1: error:
'{anonymous}::pass_ipa_pure_const::pass_ipa_pure_const(gcc::context*)' defined
but not used [-Werror=unused-function]

issue.

[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161

[aldyh at redhat dot com]

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

--- Comment #10 from Aldy Hernandez  ---
It's not supposed to. It's for issue three as stated.

On Jun 9, 2015 4:36 AM, "dominiq at lps dot ens.fr" 
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448 
>
> --- Comment #9 from Dominique d'Humieres  --- 
> > Created attachment 35718 
> >   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35718&action=edit 
> > Tentative patch for issue #3 
>
> The patch does not fix the 
>
> ../../work/gcc/ipa-pure-const.c:1636:1: error: 
> '{anonymous}::pass_ipa_pure_const::pass_ipa_pure_const(gcc::context*)' 
> defined 
> but not used [-Werror=unused-function] 
>
> issue. 
>
> -- 
> You are receiving this mail because: 
> You are on the CC list for the bug.

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #2 from Markus Trippelsdorf  ---
The testcase is invalid:

markus@x4 testc % g++ -r -nostdlib a.ii c.ii e.ii -g -O2 -flto
a.ii:21:8: warning: ‘Run’ violates the C++ One Definition Rule  [-Wodr]
   void Run (Point &) const;
^
e.ii:25:1: note: return value type mismatch
 Optimizer::Run (Point &) const
 ^
e.ii:25:1: note: type ‘float’ should match type ‘void’
e.ii:25:1: note: ‘Run’ was previously declared here
e.ii: In member function ‘__base_dtor ’:
e.ii:28:1: internal compiler error: in check_die, at dwarf2out.c:5712
 }
 ^

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Markus Trippelsdorf from comment #2)
> The testcase is invalid:
> 
> markus@x4 testc % g++ -r -nostdlib a.ii c.ii e.ii -g -O2 -flto
> a.ii:21:8: warning: ‘Run’ violates the C++ One Definition Rule  [-Wodr]
>void Run (Point &) const;
> ^
> e.ii:25:1: note: return value type mismatch
>  Optimizer::Run (Point &) const
>  ^
> e.ii:25:1: note: type ‘float’ should match type ‘void’
> e.ii:25:1: note: ‘Run’ was previously declared here
> e.ii: In member function ‘__base_dtor ’:
> e.ii:28:1: internal compiler error: in check_die, at dwarf2out.c:5712
>  }
>  ^

You are right. However, I guess we should not ICE?

Martin

[Bug libstdc++/66030] [5.1.0] std::codecvt_byname missing from libstdc++ DLL

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
Author: redi
Date: Tue Jun  9 08:50:00 2015
New Revision: 224273

URL: https://gcc.gnu.org/viewcvs?rev=224273&root=gcc&view=rev
Log:
PR libstdc++/66030
* config/abi/pre/gnu.ver: Export codecvt_byname and codecvt symbols
for mingw32.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/pre/gnu.ver

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #4 from Markus Trippelsdorf  ---
Yeah. It is also easily fixed:


markus@x4 testc % cat 1.ii
namespace std
{
template  class allocator;
template  > class vector
{
public:
  ~vector () {}
};
vector b;
}

template  class A
{
public:
  typedef _Tp reference;
};

template  > class B
{
public:
  typename _Alloc::reference operator[](int);
};

namespace MosesTuning
{
class Point
{
};
class Optimizer
{
public:
  float Run (Point &) const;
};
}
using namespace MosesTuning;
class C
{
public:
  C (Point) { m_optimizer.Run (m_point); }
  Optimizer m_optimizer;
  Point m_point;
};

main ()
{
  B a;
  (C (a[0]));
}

markus@x4 testc % cat 2.ii
namespace std
{
template  class allocator;
struct _Vector_base
{
  ~_Vector_base ();
};
template  > class vector : _Vector_base
{
};
}

namespace MosesTuning
{
class Point;
class Optimizer
{
  float Run (Point &) const;
};
}
using namespace std;
namespace MosesTuning
{
float
Optimizer::Run (Point &) const
{
  vector a;
}
}

markus@x4 testc % /var/tmp/gcc_test/usr/local/bin/g++ -r -nostdlib 1.ii 2.ii -g
-O2 -flto
2.ii: In member function ‘__base_dtor ’:
2.ii:28:1: internal compiler error: in check_die, at dwarf2out.c:5712

[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
(In reply to Aldy Hernandez from comment #10)
> It's not supposed to. It's for issue three as stated.

indeed;
state as of now is that (with both proposed patches in place and
--disable-werror), the multiple DWARF entity ld64 warnings are gone from my
bootstrap log.  The test suite is running - was going to wait to report until
that's done …

[Bug c++/33661] template methods forget explicit local reg vars

[krebbel at gcc dot gnu.org]

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

--- Comment #13 from Andreas Krebbel  ---
Created attachment 35723
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35723&action=edit
Experimental fix

The attached patch fixes the problem for me.

There appear to be two problems:

1. When parsing a template function cp_finish_decl returns before the asmspec
is set in a var decl.
2. When expanding the template function the assembler_name is zeroed out.

[Bug target/66470] New: [4.8/4.9/5/6 Regression] TLS ICE due to ix86_split_long_move

[jakub at gcc dot gnu.org]

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

Bug ID: 66470
   Summary: [4.8/4.9/5/6 Regression] TLS ICE due to
ix86_split_long_move
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

extern __thread unsigned long long a[10];
unsigned long long foo (int b) { return a[b]; }

or

extern __thread struct S { int a, b; } a[10];
struct S foo (int b) { return a[b]; }

ICE on x86_64-linux/i686-linux with -m32, all optimization levels.  This worked
in GCC 3.3.6.
The bug is in ix86_split_long_move, when trying to split:
(insn 7 15 13 2 (set (reg:DI 0 ax [92])
(mem:DI (plus:SI (plus:SI (mult:SI (reg/v:SI 1 dx [orig:89 b ] [89])
(const_int 8 [0x8]))
(unspec:SI [
(const_int 0 [0])
] UNSPEC_TP))
(reg:SI 0 ax [91])) [1 a S8 A64])) rh1212265.i:2 85
{*movdi_internal}
 (nil))
which, while offsettable, has collisions == 2 (the MEM uses both dx and ax in
the addressing and loads the ax:dx pair).  The splitter assumes it can just use
a lea, but lea can't support %gs: (UNSPEC_TP).  So, either it has to load from
%gs:0 first, then do lea, or better yet just move UNSPEC_TP part to the
individual memory loads.

[Bug target/66470] [4.8/4.9/5/6 Regression] TLS ICE due to ix86_split_long_move

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #37 from Eric Botcazou  ---
The patch severely breaks on SPARC though:

int foo (char c)
{
  return (int) c;
}

eric@polaris:~/build/gcc/sparc-sun-solaris2.10> gcc/xgcc -Bgcc -S -O t.c
t.c: In function 'foo':
t.c:1:5: internal compiler error: in assign_parm_setup_reg, at function.c:3120
 int foo (char c)
 ^
0xa335d0 assign_parm_setup_reg
/home/eric/svn/gcc/gcc/function.c:3120
0xa3660f assign_parms
/home/eric/svn/gcc/gcc/function.c:3778
0xa3a9fd expand_function_start(tree_node*)
/home/eric/svn/gcc/gcc/function.c:5215
0x838716 execute
/home/eric/svn/gcc/gcc/cfgexpand.c:6127
Please submit a full bug report,

[Bug target/66470] [4.8/4.9/5/6 Regression] TLS ICE due to ix86_split_long_move

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.5

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug libstdc++/66464] codecvt_utf16 max_length returning incorrect value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-06-09
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Leo Carreon from comment #0)
> I just noticed that codecvt_utf16::max_length() is returning 3.
> 
> This appears to be the wrong value because a surrogate pair is composed of 4
> bytes therefore max_length() should at least be returning 4.

Agreed, I think that's just a mistake.

I wrote this comment in the code:

int
codecvt::do_max_length() const throw()
{
  // Any valid UTF-8 sequence of 3 bytes fits in a single 16-bit code unit,
  // whereas 4 byte sequences require two 16-bit code units.
  return 3;
}

But that reasoning (even if it's correct!) doesn't apply to
codecvt_utf16.

> I'm also wondering whether the BOM should be taken into account.  If it so
> happens that at the beginning of a UTF-16 string which has a BOM and it so
> happens to start with a surrogate pair, 6 bytes have to be consumed to
> generate a single UCS-4 character.
> 
> Should the same thing be considered with
> codecvt_utf8::max_length() which currently returns 4.  Taking into
> account the BOM and the longest UTF-8 character below 0x10, shouldn't
> max_length() return 7.
> 
> I'm not really sure if the BOM should be taken into account because the
> standard's definition for do_max_length() simply says the maximum number of
> input characters that needs to be consumed to generate a single output
> character.

That's a very good question.

[Bug c++/57709] -Wshadow is too strict / has false positives

[gael.guennebaud at gmail dot com]

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

Gael Guennebaud  changed:

   What|Removed |Added

 CC||gael.guennebaud at gmail dot 
com

--- Comment #15 from Gael Guennebaud  ---
-Wshadow still trigger false positive when a base member functions is imported
with the "using" keyword, as in the following example (tested with gcc 5.1):

template struct BaseClass {
  BaseClass(int size) : m_size(size) {}
  int size() { return m_size; }
  int m_size;
};

template struct Foo : BaseClass {
  typedef BaseClass Base;
  Foo(int size) : Base(size) {}
  using Base::size;
};

$ g++-mp-5 gcc_shadow.cpp -c  -Wshadow 
gcc_shadow.cpp: In constructor 'Foo::Foo(int)':
gcc_shadow.cpp:9:17: warning: declaration of 'size' shadows a member of
'Foo' [-Wshadow]
   Foo(int size) : Base(size) {}
 ^
gcc_shadow.cpp:10:15: note: shadowed declaration is here
   using Base::size;


Note that clang does not warn in this case, so it should be possible to figure
out that in this case, the imported "size" symbol is a function and not a
variable.

[Bug c++/57709] -Wshadow is too strict / has false positives

[manu at gcc dot gnu.org]

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

--- Comment #16 from Manuel López-Ibáñez  ---
(In reply to Gael Guennebaud from comment #15)
> -Wshadow still trigger false positive when a base member functions is
> imported with the "using" keyword, as in the following example (tested with
> gcc 5.1):

Please open a new PR. This one is fixed.

> Note that clang does not warn in this case, so it should be possible to
> figure out that in this case, the imported "size" symbol is a function and
> not a variable.

Sure, probably TREE_CODE (member) != FUNCTION_DECL but there must be a way to
check that it does represent a function_decl (or member-function). Run gcc
under gdb in your testcase and break at the call to warning_at and use "p
debug_tree(member)" to understand what member is in your testcase.

[Bug c/45780] Warning for arithmetic operations involving C99 _Bool variable

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
I think -Wbool-arith makes sense as a separate option.  While -Wc90-c99-compat
warns about any use of bool (in a declaration, cast, ...), -Wbool-arith would
only warn about suspicious uses of boolean vars.

[Bug target/66470] [4.8/4.9/5/6 Regression] TLS ICE due to ix86_split_long_move

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 35724
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35724&action=edit
gcc6-pr66470.patch

Untested fix.

[Bug bootstrap/66471] New: BITMAP is a reserved keyword on MinGW

[ismail at donmez dot ws]

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

Bug ID: 66471
   Summary: BITMAP is a reserved keyword on MinGW
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ismail at donmez dot ws
  Target Milestone: ---

gcc/mem-stats-traits.h has:

/* Memory allocation origin.  */
   enum mem_alloc_origin
   {
 HASH_TABLE,
 HASH_MAP,
 HASH_SET,
 VEC,
 BITMAP,
 GGC,
 ALLOC_POOL,
 MEM_ALLOC_ORIGIN_LENGTH
   };

and this fails to compile on mingw-w64 with:


In file included from
/usr/x86_64-w64-mingw32/sys-root/mingw/include/windows.h:71:0,
 from ../../combined-6.0.0/gcc/config/i386/host-mingw32.c:29:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/wingdi.h:467:5: error: 'typedef
struct tagBITMAP BITMAP' redeclared as different kind of symbol
   } BITMAP,*PBITMAP,*NPBITMAP,*LPBITMAP;
 ^
In file included from ../../combined-6.0.0/gcc/hash-table.h:204:0,
 from ../../combined-6.0.0/gcc/coretypes.h:310,
 from ../../combined-6.0.0/gcc/config/i386/host-mingw32.c:22:
../../combined-6.0.0/gcc/mem-stats-traits.h:11:3: note: previous declaration
'mem_alloc_origin BITMAP'
   BITMAP,
   ^
In file included from
/usr/x86_64-w64-mingw32/sys-root/mingw/include/windows.h:71:0,
 from ../../combined-6.0.0/gcc/config/i386/host-mingw32.c:29:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/wingdi.h:2688:55: error:
'BITMAP' does not name a type
   WINGDIAPI HBITMAP WINAPI CreateBitmapIndirect(CONST BITMAP *pbm);
   ^
In file included from
/usr/x86_64-w64-mingw32/sys-root/mingw/include/windows.h:71:0,
 from ../../combined-6.0.0/gcc/config/i386/host-mingw32.c:29:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/wingdi.h:3218:5: error: 'BITMAP'
does not name a type
 BITMAP dsBm;
 ^
../../combined-6.0.0/gcc/config/i386/x-mingw32:30: recipe for target
'host-mingw32.o' failed

Renaming "BITMAP" enum should ne enough.

[Bug c++/66472] New: -Wshadow gets confused by using statements in template classes

[gael.guennebaud at gmail dot com]

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

Bug ID: 66472
   Summary: -Wshadow gets confused by using statements in template
classes
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gael.guennebaud at gmail dot com
  Target Milestone: ---

This is a followup to bug 57709 that disabled shadow warnings between variables
and class functions. However, -Wshadow still trigger false positive when a base
member functions is imported with the "using" keyword, as in the following
example (tested with gcc 5.1):


template struct BaseClass {
  BaseClass(int size) : m_size(size) {}
  int size() { return m_size; }
  int m_size;
};

template struct Foo : BaseClass {
  typedef BaseClass Base;
  Foo(int size) : Base(size) {}
  using Base::size;
};



$ g++-mp-5 gcc_shadow.cpp -c  -Wshadow 
gcc_shadow.cpp: In constructor 'Foo::Foo(int)':
gcc_shadow.cpp:9:17: warning: declaration of 'size' shadows a member of
'Foo' [-Wshadow]
   Foo(int size) : Base(size) {}
 ^
gcc_shadow.cpp:10:15: note: shadowed declaration is here
   using Base::size;



Note that clang does not warn in this case, so it should be possible to figure
out that in this case, the imported "size" symbol is a function and not a
variable.

As suggested there https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709#c16, I
tried to break at the call to warning_at to give you more input, but with no
luck, as if warning_at was not called at all. (I also tried to break at any
*warning* symbol with same result).

[Bug bootstrap/66471] BITMAP is a reserved keyword on MinGW

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 35725
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35725&action=edit
Patch

May I ask you for testing the patch?

Thanks,
Martin

[Bug bootstrap/66471] BITMAP is a reserved keyword on MinGW

[ismail at donmez dot ws]

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

--- Comment #2 from İsmail Dönmez  ---
(In reply to Martin Liška from comment #1)
> Created attachment 35725 [details]
> Patch
> 
> May I ask you for testing the patch?

Fixes the bootstrap for me, thanks.

[Bug bootstrap/66471] BITMAP is a reserved keyword on MinGW

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to İsmail Dönmez from comment #2)
> (In reply to Martin Liška from comment #1)
> > Created attachment 35725 [details]
> > Patch
> > 
> > May I ask you for testing the patch?
> 
> Fixes the bootstrap for me, thanks.

Thanks for testing, I am going to re-spin my regression tests
and I'm going to send the patch to ML.

Martin

[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161

[iains at gcc dot gnu.org]

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

--- Comment #12 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #11)
> (In reply to Aldy Hernandez from comment #10)
> > It's not supposed to. It's for issue three as stated.
> 
> The test suite is running - was going to wait to report
> until that's done …

NOTE: I have bootstrapped and tested c,c++,objc,objc++,fortran,ada,lto - but
NOT Java.

So .. things are *very* much improved, thanks!
(at least no reports during bootstrap),
but there's still quite a bit of fallout in the testsuite (many more failing
tests than listed below, these are just examples):

FAIL: gcc.c-torture/execute/20020412-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/execute/20040308-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/execute/20070919-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/pr8081.c   -O3 -g  (test for excess errors)


(usually several) instances of:
warning: invalid DWARF generated by the compiler: DIE 0x018b has multiple 
AT_decl_file attributes in
'/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccSyKR0x.o'.

warning: invalid DWARF generated by the compiler: DIE 0x015d has multiple 
AT_decl_line attributes in
'/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//kVUY.o'.

FAIL: c-c++-common/cilk-plus/CK/cilk-for-2.c  -g  (test for excess errors)
FAIL: c-c++-common/cilk-plus/CK/cilk-fors.c  -g  (test for excess errors)
FAIL: c-c++-common/cilk-plus/CK/cilk_for_grain.c  -g  (test for excess errors)
FAIL: c-c++-common/cilk-plus/CK/cilk_for_ptr_iter.c  -g  (test for excess
errors)
FAIL: c-c++-common/cilk-plus/CK/nested_cilk_for.c  -g  (test for excess errors)

also plugin tests.

(many) instances of:
warning: invalid DWARF generated by the compiler: DIE 0x0176 has multiple 
AT_artificial attributes in
'/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccNJ6qak.o'.

===

looks like c++ only has fails of the form:

has multiple  AT_artificial attributes

=

no errors of this kind recorded in acats

=

gnat has all three forms

=

fortran seems to have only:
 AT_artificial attributes 

==

target lib tests seem dominated by 
has multiple  AT_artificial attributes
(I didn't see any other cases in a quick grep)

[Bug tree-optimization/66423] [6 Regression] a % (1 << b) no longer gets folded to a & (1 << b) for unsigned a

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug tree-optimization/66423] [6 Regression] a % (1 << b) no longer gets folded to a & (1 << b) for unsigned a

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Jun  9 12:31:43 2015
New Revision: 224279

URL: https://gcc.gnu.org/viewcvs?rev=224279&root=gcc&view=rev
Log:
2015-06-09  Richard Biener  

PR middle-end/66423
* match.pd: Handle A % (unsigned)(1 << B).

* gcc.dg/fold-modpow2.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/fold-modpow2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug c++/66472] -Wshadow gets confused by using statements in template classes

[chtz at informatik dot uni-bremen.de]

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

Christoph Hertzberg  changed:

   What|Removed |Added

 CC||chtz at informatik dot 
uni-bremen.
   ||de

--- Comment #1 from Christoph Hertzberg  
---
Wouldn't this actually be a valid warning if BaseClass had a constructor taking
a function pointer/member function pointer?

struct BaseClass {
  BaseClass(int) { std::cout << "int\n"; }
  BaseClass(int () ) { std::cout << "int()\n"; }
  BaseClass(int (BaseClass::*)()) {std::cout << "int (BaseClass::*)()\n"; }
  static int size() { return 0;}
  int size2() { return 0; }
};

struct Foo : public BaseClass {
  using BaseClass::size;
  using BaseClass::size2;

  // size shadows BaseClass::size!
  Foo(int size) : BaseClass(size) {}
  Foo() : BaseClass(size) {}  // uses BaseClass::size
  Foo(char) : BaseClass(size2) {} // uses BaseClass::size2
};

[Bug c++/66472] -Wshadow gets confused by using statements in template classes

[gael.guennebaud at gmail dot com]

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

--- Comment #2 from Gael Guennebaud  ---
But with the same reasoning you would end up reintroducing shadow warnings
between local variables and *any* functions, not only the ones visible from a
using statement. It has been recognized that triggering a warning in such a
case was too much:
 - gcc 4.8 removed them for free functions
 - gcc 5.0 removed them for member functions
and I think that it thus make sense to remove them for member functions visible
through  "using". Did I miss something special regarding the use of "using"?

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Fixing all sanitizer issues in Firefox helped me to successfully built FF with
LTO. The binary does not segfault :)

Martin

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #12 from Martin Liška  ---
Resolved as invalid.

[Bug c++/66472] -Wshadow gets confused by using statements in template classes

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-09
 Ever confirmed|0   |1

[Bug c++/66472] -Wshadow gets confused by using statements in template classes

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
(In reply to Gael Guennebaud from comment #0)
> As suggested there https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709#c16, I
> tried to break at the call to warning_at to give you more input, but with no
> luck, as if warning_at was not called at all. (I also tried to break at any
> *warning* symbol with same result).

I compile with g++ -wrapper gdb,--args ... where this gcc was compile with -O0
-g. Breaking on warning_at shows that member is a using_decl.

[Bug c++/66472] -Wshadow gets confused by using statements in template classes

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
> As suggested there https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709#c16, I
> tried to break at the call to warning_at to give you more input, but with no
> luck, as if warning_at was not called at all. (I also tried to break at any
> *warning* symbol with same result).

Probably because you are debugging the driver instead of the compiler proper:
https://gcc.gnu.org/wiki/DebuggingGCC

Sorry, I should have mentioned that.

[Bug c++/66472] -Wshadow gets confused by using statements in template classes

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Marc Glisse from comment #3)
> I compile with g++ -wrapper gdb,--args ... where this gcc was compile with
> -O0 -g. Breaking on warning_at shows that member is a using_decl.

Is there anyway to tell what the using_decl is actually representing? Perhaps
via its type?

I think this is one of those cases where false negatives are more annoying than
false positives are dangerous, thus maybe the warning should be silent for all
using_decl.

[Bug c++/66472] -Wshadow gets confused by using statements in template classes

[chtz at informatik dot uni-bremen.de]

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

--- Comment #6 from Christoph Hertzberg  
---
Ok, good point on shadowing free functions.
Next pathological example: If you have a template specialization of your Base
with a static member variable called `size`, wouldn't the warning make sense?

template 
struct Base {
  Base(int y) {std::cout << "y=" <
struct Bar : Base {
  using Base::size;
  Bar(int size) : Base(size) {}
  Bar() : Base(size) {} // only works for T==int
};

// Specialization, probably not visible when Bar is defined:
template<>
struct Base {
  Base(int x) {std::cout << "x=" <

[Bug bootstrap/66471] BITMAP is a reserved keyword on MinGW

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Just as a quick observation from looking at host-mingw32.c:

#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "hosthooks.h"
#include "hosthooks-def.h"
#include "diagnostic.h"


#define WIN32_LEAN_AND_MEAN  /* Not so important if we have windows.h.gch.  */
#include 
#include 



stdlib.h is already included from system.h and system headers should be
included _before_ (well, in...) system.h (or at least directly after it).

Probably doesn't fix the issue though.

[Bug target/66473] New: ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f

[andrew.n.senkevich at gmail dot com]

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

Bug ID: 66473
   Summary: ICE: in extract_insn, at recog.c:2343 (unrecognizable
insn) with -mavx512f
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew.n.senkevich at gmail dot com
  Target Milestone: ---

-bash-4.2$ cat ./test_vlen8.c
#include 

extern __m512d _ZGVeN8v_func (__m512d);

double func_vlen8 (double x) {
__m512d mx;
mx[0] = mx[1] = mx[2] = mx[3] = mx[4] = mx[5] = mx[6] = mx[7] = x;
__m512d mr = _ZGVeN8v_func (mx);

return ((double) mr[0]);
}

gcc-5.1.0_install/bin/gcc -c ./test_vlen8.c -mavx512f -O2
./test_vlen8.c: In function ‘func_vlen8’:
./test_vlen8.c:11:1: error: unrecognizable insn:
 }
 ^
(insn 7 6 8 2 (set (reg:QI 94)
(const_int 128 [0x80])) ./test_vlen8.c:7 -1
 (nil))
./test_vlen8.c:11:1: internal compiler error: in extract_insn, at recog.c:2343
0x965018 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-5.1.0_src/gcc/rtl-error.c:110
0x965049 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-5.1.0_src/gcc/rtl-error.c:118
0x935129 extract_insn(rtx_insn*)
../../gcc-5.1.0_src/gcc/recog.c:2343
0x7a1c43 instantiate_virtual_regs_in_insn
../../gcc-5.1.0_src/gcc/function.c:1598
0x7a1c43 instantiate_virtual_regs
../../gcc-5.1.0_src/gcc/function.c:1966
0x7a1c43 execute
../../gcc-5.1.0_src/gcc/function.c:2015

[Bug c++/66383] [5/6 Regression] ICE in gimplify_expr on this passed in inline initialization

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Tue Jun  9 14:13:22 2015
New Revision: 224282

URL: https://gcc.gnu.org/viewcvs?rev=224282&root=gcc&view=rev
Log:
PR c++/66383
* tree.c (replace_placeholders_r): Handle placeholders for an
outer object.
* typeck2.c (store_init_value): Only replace_placeholders for
objects of class type.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck2.c

[Bug tree-optimization/66299] more optimize opportunity

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Tue Jun  9 14:24:04 2015
New Revision: 224283

URL: https://gcc.gnu.org/viewcvs?rev=224283&root=gcc&view=rev
Log:
PR tree-optimization/66299
* match.pd ((CST1 << A) == CST2 -> A == ctz (CST2) - ctz (CST1)
((CST1 << A) != CST2 -> A != ctz (CST2) - ctz (CST1)): New
patterns.

* gcc.dg/pr66299-1.c: New test.
* gcc.dg/pr66299-2.c: New test.
* gcc.dg/pr66299-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr66299-1.c
trunk/gcc/testsuite/gcc.dg/pr66299-2.c
trunk/gcc/testsuite/gcc.dg/pr66299-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/66299] more optimize opportunity

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
This one should be done.

[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays

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

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

--- Comment #11 from Gerhard Steinmetz  
---
Created attachment 35726
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35726&action=edit
test case pr66193_1_real.f90

[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays

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

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

--- Comment #12 from Gerhard Steinmetz  
---
Created attachment 35727
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35727&action=edit
test case pr66193_2_integer.f90

[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays

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

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

--- Comment #13 from Gerhard Steinmetz  
---
Created attachment 35728
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35728&action=edit
test case pr66193_3_diverse.f90

[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays

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

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

--- Comment #14 from Gerhard Steinmetz  
---
Attached some prepared test files.
Added more test cases for integer and real.

Added new test case for logical :
  subroutine s2
logical(8), parameter :: z1(2) = .true. .or. [ logical(8) :: [ logical(4)
:: ], .false., .false. ]
logical(8) :: z2(2) = .true. .or. [ logical(8) :: [ logical(4) :: ],
.false., .false. ]
logical(8) :: z3(2)
z3 = .true. .or. [ logical(8) :: [ logical(4) :: ], .false., .false. ]
if ( (.not. z1(1)) .and. (.not. z1(2)) ) call abort
if ( (.not. z2(1)) .and. (.not. z2(2)) ) call abort
if ( (.not. z3(1)) .and. (.not. z3(2)) ) call abort
  end subroutine s2

[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Aldy Hernandez  ---
Jason, this behavior exists prior to the debug-early work.

For the 1.ii/2.ii testcase in comment 4 we are generating a DIE for a
__base_dtor.  First we retrofit the declaration with force_decl_die,
and use this DIE as the basis for a DW_AT_specification variant.
Eventually dwarf2out_abstract_function() gets called on this
DW_AT_specification variant and we annotate it with DW_AT_inline.
This DW_AT_specification variant, already has location info which is
why we fail the assert.

It was my understanding that DW_AT_inline cannot appear in conjunction
with location info.

I added the check_die() code to a branch of mainline immediately
before my work, and it ICEs similarly to current mainline with a
problematic DIE of:

DIE0: DW_TAG_subprogram (0x703885a0)
  abbrev id: 0 offset: 0 mark: 0
  DW_AT_specification: die -> 0 (0x703884b0)
  DW_AT_low_pc: label: *.LFB0
  DW_AT_high_pc: label: *.LFE0
  DW_AT_frame_base: location descriptor:
(0x703885f0) DW_OP_call_frame_cfa 0, 0

  DW_AT_GNU_all_call_sites: 1
  DW_AT_inline: 2

Could you please take a look at this, since it is broken behavior
prior to early debug?  Perhaps it is expected behavior and we can
remove the DW_AT_inline + location check?

[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161

[jason at gcc dot gnu.org]

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

--- Comment #13 from Jason Merrill  ---
Author: jason
Date: Tue Jun  9 14:51:30 2015
New Revision: 224285

URL: https://gcc.gnu.org/viewcvs?rev=224285&root=gcc&view=rev
Log:
PR bootstrap/66448
* toplev.c (check_global_declaration): Don't warn about a clone.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wunused-function1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/toplev.c

[Bug c++/65815] brace elision doesn't work in NSDMI

[paolo at gcc dot gnu.org]

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

--- Comment #9 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Jun  9 14:59:08 2015
New Revision: 224286

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

PR c++/65815
* typeck2.c (digest_nsdmi_init): On aggregates use reshape_init.
* init.c (expand_default_init): Likewise.

/testsuite
2015-06-09  Paolo Carlini  

PR c++/65815
* g++.dg/cpp0x/nsdmi-aggr1.C: New.
* g++.dg/cpp0x/mem-init-aggr1.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/mem-init-aggr1.C
trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-aggr1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/65815] brace elision doesn't work in NSDMI

[paolo.carlini at oracle dot com]

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

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|--- |6.0

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

[Bug c++/58616] [meta-bug] nsdmi

[paolo.carlini at oracle dot com]

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

Bug 65815 Summary: brace elision doesn't work in NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65815

   What|Removed |Added

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

[Bug libstdc++/64504] Invalid free() with _GLIBCXX_DEBUG and -fwhole-program

[andrey.vihrov at gmail dot com]

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

--- Comment #6 from Andrey Vihrov  ---
Thanks for your reply. You have a point: using -fwhole-program introduces more
effects than needed, as evidenced by this bug report, so an anonymous namespace
is safer and cleaner.

In any case, in this bug report we have a program that produces unexpected
results with GCC. If this usage is supported, then it is a bug. If this usage
is unsupported, then it would be nice to explicitly document cases when
-fwhole-program can be used in GCC. For example, GCC documentation might say
something like

   Note: -fwhole-program can be specified for programs that link only to the
standard C/C++ library (or link to nothing at all), and do not use any template
class or function from the standard C++ library.

[Bug c++/66387] [5/6 Regression] ICE in make_decl_rtl with lambda

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Jun  9 15:27:01 2015
New Revision: 224287

URL: https://gcc.gnu.org/viewcvs?rev=224287&root=gcc&view=rev
Log:
PR c++/66387
* semantics.c (process_outer_var_ref): Make sure the value is
actually constant before returning it.
* typeck.c (cp_build_array_ref): Allow subscripting non-lvalue
array.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/cp/typeck.c

[Bug c++/65966] [5/6 Regression] [C++14] "sorry, unimplemented: unexpected AST of kind try_block" when initializing a 2D array

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-09
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |5.2
Summary|"sorry, unimplemented:  |[5/6 Regression] [C++14]
   |unexpected AST of kind  |"sorry, unimplemented:
   |try_block" when |unexpected AST of kind
   |initializing a 2D array |try_block" when
   ||initializing a 2D array
 Ever confirmed|0   |1

[Bug target/66473] ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-09
   Target Milestone|--- |5.2
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Confirmed. I have a patch.

[Bug target/66473] ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
Created attachment 35729
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35729&action=edit
Proposed patch

Patch that fixes the failure.

[Bug target/66473] ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
Ops, Kirill is already looking at this.

Kirill, you have much better facilities for testing, do you want to take the
proposed patch from here?

[Bug target/66473] ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||x86
 Status|NEW |ASSIGNED
 CC||ubizjak at gmail dot com

[Bug rtl-optimization/66306] ICE in reload

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-06-09
   Assignee|unassigned at gcc dot gnu.org  |krebbel at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Andreas Krebbel  ---
Created attachment 35730
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35730&action=edit
Experimental fix

When preparing the operands for using an alternative with swapped operands
reload does not swap the information about match_dups in recog_data.

[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

--- Comment #38 from David Edelsohn  ---
It also broke ARM and PowerPC.  This patch should have been tested on all of
the config-list.mk targets.

[Bug target/66474] New: Document the use of %x in powerpc asm statements

[meissner at gcc dot gnu.org]

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

Bug ID: 66474
   Summary: Document the use of %x in powerpc asm statements
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
 Build: powerpc64-unknown-linux-gnu

A user that was trying to use PowerPC VSX instructions reported that we never
documented that you need to use %x in PowerPC asm statements if the register
could be a VSX register (as opposed to traditional FPR or Altivec register).

[Bug target/66474] Document the use of %x in powerpc asm statements

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-06-09
 CC||bergner at gcc dot gnu.org,
   ||dje at gcc dot gnu.org,
   ||munroesj at us dot ibm.com
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/66475] New: Access checking in templates circumvented with 'using' (C++11)

[zerolo at gmail dot com]

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

Bug ID: 66475
   Summary: Access checking in templates circumvented with 'using'
(C++11)
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zerolo at gmail dot com
  Target Milestone: ---

Created attachment 35731
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35731&action=edit
repo that compiles with g++-4.9.2 -std=c++11

This is a variant of the various access checking problems when using templates,
but I don't think it's a duplicate of any of the existing ones in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002 , as this one is only
triggered with the `using` directive in C++11 mode, but not when employing the
supposedly identical typedef.

Code that accesses a type that should be private compiles, even though it
shouldn't be able to. When either a) the using directive "using Base = Foo"
is replaced by the equivalent typedef, or b) later no other type from Base is
publicized, then access is correctly prohibited and the example fails to
compile.

// g++-4.9.2 -std=c++11 t.cpp
template
struct Foo
{
  using type = T;
};

template
class Bar : public Foo
{
  using Base = Foo; // the combination of this and the public export of a
type from Base below, causes this example to compile even though it shouldn't
  // typedef Foo Base; // when using typedef instead of using, it correctly
fails to compile
public:
  // without this public export, Base is correctly recognized as private, maybe
it erroneously make Base itself public?

  // whether written as 'typedef' or 'using' doesn't matter
  using type = typename Base::type;
};

Bar::Base x; // shouldn't compile, Base is private

int main()
{
  return 0;
}

[Bug c++/66476] New: Erroneous initializer_list lifetime extension from temporary initializer_list

[ed at catmur dot co.uk]

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

Bug ID: 66476
   Summary: Erroneous initializer_list lifetime extension from
temporary initializer_list
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot co.uk
  Target Milestone: ---

#include 
#include 
struct S { S(int) { puts("S(int)"); } ~S() { puts("~S()"); } };
int main() {
  std::initializer_list ss({42});  // note extra parentheses
  puts("main");
}

Expected output (clang 3.7, MSVC 18.00.21005.1):
S(int)
~S()
main

Observed output (gcc 5.1.0):
S(int)
main
~S()

The same behaviour is observed when the temporary initializer_list is made
explicit:
  std::initializer_list ss = std::initializer_list{42};


Again, gcc lifetime-extends the backing array; MSVC and clang do not.

[Bug c++/66476] Erroneous initializer_list lifetime extension from temporary initializer_list

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/66475] Access checking in templates circumvented with 'using' (C++11)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-09
 Blocks||59002
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002
[Bug 59002] [meta-bug] Access checking in templates

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[hubicka at ucw dot cz]

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

--- Comment #13 from Jan Hubicka  ---
Great, do you have patch?
Honza

[Bug libstdc++/64504] Invalid free() with _GLIBCXX_DEBUG and -fwhole-program

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-09
 Ever confirmed|0   |1

--- Comment #7 from Jonathan Wakely  ---
I agree the docs should be clear on what's supported.

[Bug c++/51747] [DR 1467] [C++11] cannot call defaulted copy constructor using list-initialization

[jason at gcc dot gnu.org]

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

--- Comment #16 from Jason Merrill  ---
Author: jason
Date: Tue Jun  9 16:56:12 2015
New Revision: 224289

URL: https://gcc.gnu.org/viewcvs?rev=224289&root=gcc&view=rev
Log:
DR 1467
PR c++/51747
* typeck2.c (digest_init_r): Replace previous change with
gcc_unreachable.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck2.c

[Bug c++/66383] [5/6 Regression] ICE in gimplify_expr on this passed in inline initialization

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Tue Jun  9 17:19:12 2015
New Revision: 224291

URL: https://gcc.gnu.org/viewcvs?rev=224291&root=gcc&view=rev
Log:
PR c++/66383
* tree.c (replace_placeholders_r): Handle placeholders for an
outer object.
* typeck2.c (store_init_value): Only replace_placeholders for
objects of class type.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr3.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/tree.c
branches/gcc-5-branch/gcc/cp/typeck2.c

[Bug c++/66387] [5/6 Regression] ICE in make_decl_rtl with lambda

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Tue Jun  9 17:19:18 2015
New Revision: 224292

URL: https://gcc.gnu.org/viewcvs?rev=224292&root=gcc&view=rev
Log:
PR c++/66387
* semantics.c (process_outer_var_ref): Make sure the value is
actually constant before returning it.
* typeck.c (cp_build_array_ref): Allow subscripting non-lvalue
array.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const5.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/semantics.c
branches/gcc-5-branch/gcc/cp/typeck.c

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

[glisse at gcc dot gnu.org]

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

Bug 15350 Summary: [tree-ssa] Convert if ((1 << a) & 1) into if (a == 0).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15350

   What|Removed |Added

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

[Bug tree-optimization/15350] [tree-ssa] Convert if ((1 << a) & 1) into if (a == 0).

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||5.1.0
 Resolution|--- |FIXED
  Known to fail||4.9.2

--- Comment #5 from Marc Glisse  ---
This was fixed in gcc-5.

[Bug target/66473] ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f

[kyukhin at gcc dot gnu.org]

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

--- Comment #4 from Kirill Yukhin  ---
Sure, I'll report tomorrow.

[Bug target/66474] Document the use of %x in powerpc asm statements

[meissner at gcc dot gnu.org]

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

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

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška  ---
(In reply to Jan Hubicka from comment #13)
> Great, do you have patch?
> Honza

Yes, I've suggested a patch here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1167119

Let's see if it will be accepted by Mozilla folks.
Anyway, the GCC revision where you made VRP more aggressive works, but there's
a different revision that causes a segfault. I will bisect it.

Martin

[Bug c++/66477] New: [constexpr] accepts-invalid with constexpr member call on non-constant reference

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 66477
   Summary: [constexpr] accepts-invalid with constexpr member call
on non-constant reference
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

GCC accepts this invalid code:

  struct a { constexpr int size() const { return 3; } };
  void f(a &r) { static_assert(r.size() == 3, "error"); }

The static_assert condition is non-constant because it mentions the reference
'r' whose referent is not known within that constant expression.

[Bug c++/66478] New: [constexpr] accepts-invalid with read of non-constant variable as discarded value

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 66478
   Summary: [constexpr] accepts-invalid with read of non-constant
variable as discarded value
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

GCC accepts this ill-formed code:

  void f(int n) { static_assert((+n, true), ""); }

This is invalid because it reads the variable 'n', whose value is not known
within the constant expression.

[Bug c++/58074] [C++11] __is_trivial intrinsic fails for deleted members and for non-trivial copy-c'tors

[richard-gccbugzilla at metafoo dot co.uk]

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

Richard Smith  changed:

   What|Removed |Added

 CC||richard-gccbugzilla@metafoo
   ||.co.uk

--- Comment #3 from Richard Smith  ---
This bug results in GCC failing to follow the Itanium C++ ABI when passing such
types to/from functions; see llvm.org/PR23764 for a user complaint of
cross-vendor ABI incompatibility.

[Bug middle-end/66479] New: -fstack-check doesn't prevent stack allocation with size -1

[jann at thejh dot net]

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

Bug ID: 66479
   Summary: -fstack-check doesn't prevent stack allocation with
size -1
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jann at thejh dot net
  Target Milestone: ---

[I hope I filed this in the correct place? Sorry, I'm not very familiar with
gcc internals.]

It looks like -fstack-check doesn't prevent stack allocations with size
(unsigned long)-1 and values close to that. Repro code:

$ cat stackalloc.c
#include 
#include 

int main(void) {
  unsigned long size = -1;
  char buf2[] = "hello world";
  char buf[size];
  strlcpy(buf, "asdfasdf1234", size);
  puts(buf2);
  return 0;
}
$ gcc -o stackalloc stackalloc.c -fstack-check -lbsd -m32 -ggdb -Wall -Wextra
$ ./stackalloc
1234
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jann/tmp/gccroot/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/home/jann/tmp/gccroot
--disable-bootstrap
Thread model: posix
gcc version 5.1.0 (GCC) 

This might be a security problem if an application decides to perform stack
allocations with completely attacker-controlled sizes.

[Bug tree-optimization/65460] parloops transforms offloaded functions

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
Author: vries
Date: Tue Jun  9 21:14:46 2015
New Revision: 224303

URL: https://gcc.gnu.org/viewcvs?rev=224303&root=gcc&view=rev
Log:
Mark offloaded functions as parallelized

2015-06-09  Tom de Vries  

PR tree-optimization/65460
* omp-low.c (expand_omp_target): Set parallelized_function on
cgraph_node for child_fn.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c

[Bug tree-optimization/65460] parloops transforms offloaded functions

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from vries at gcc dot gnu.org ---
patch committed to trunk, marking resolved fixed.

[Bug middle-end/66479] -fstack-check doesn't prevent stack allocation with size -1

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-06-09
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
What's your 'ulimit -s' setting?

[Bug middle-end/66479] -fstack-check doesn't prevent stack allocation with size -1

[jann at thejh dot net]

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

--- Comment #2 from Jann Horn  ---
$ ulimit -s
8192

[Bug middle-end/66479] -fstack-check doesn't prevent stack allocation with size -1

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Eric Botcazou  ---
Then this probably wraps around, including the stack allocation.

[Bug libstdc++/66464] codecvt_utf16 max_length returning incorrect value

[lcarreon at bigpond dot net.au]

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

--- Comment #2 from Leo Carreon  ---
Just clarifying that my comments are to do with codecvt_utf16 and
codecvt_utf8.

The way I understand it, codecvt_utf16 should be converting between
UTF-16 and UCS-4.  UTF-16 uses 2 bytes for characters in the BMP (characters in
the range 0x to 0x) and 4 bytes (surrogate pairs) for characters above
the BMP (0x01 to 0x10).  UCS-4 uses 4 byte values.  Therefore,
codecvt_utf16::max_length() should be returning 4 if the BOM is not
taken into account.

codecvt_utf8 converts between UTF-8 and UCS-4.  UTF-8 can use up to 4
bytes for characters up to the range 0x10.  Therefore,
codecvt_utf8::max_length() should be returning 4 if the BOM is not
taken into account.

As I said in my previous post, I'm not sure if the BOM should be accounted for
in max_length().  If I'm not mistaken, the purpose of this function is to allow
a user to estimate how many bytes are required to fit a UCS-4 string when
converted to either UTF-16 or UTF-8.  And my guess, the BOM can be taken into
account separately when doing the estimation.  For example, when
wstring_convert estimates the length of the std::string to be generated by
wstring_convert::to_bytes().  It should be the number of UCS-4 characters
multiplied by max_length() and then add the size of the BOM if required.  The
resulting std::string can be resized after the conversion to eliminate the
unused bytes.

Note that the comment you mentioned in your reply probably only applies to
codecvt_utf8_utf16 which converts between UTF-8 and UTF-16 directly without
going thru the UCS-4 conversion.