[Bug c++/84608] New: Hang in cxx_eval_constant_expression() with -fsanitize=undefined

[vegard.nossum at gmail dot com]

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

Bug ID: 84608
   Summary: Hang in cxx_eval_constant_expression() with
-fsanitize=undefined
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

Created attachment 43525
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43525=edit
GDB stack trace

Input:

void f(void) {
return { 00 + 0 << 101 >> 2 + 0 >> 0 >> ~010 + 0 << 0 >> ~~00 << 1 <<
~~0 + ~010 + 0 << 0 << 0 + 0 + 0 >> 0 + ~0 << ~0 + 22 + 2120 + ~0 >> 200 << 01
>> 10 << ~0 + 0 >> 0 << 0 >> 210 >> 0 << ~100 + 0 >> 0 << 1021 + 10 >> 02 >> 0
>> 2 + 20 };
}

Output:

$ xgcc -x c++ -fsanitize=undefined -c -
: In function 'void f()':
:2:21: warning: left shift count >= width of type
[-Wshift-count-overflow]
:2:49: warning: right shift count is negative [-Wshift-count-negative]
:2:85: warning: left shift count is negative [-Wshift-count-negative]
:2:113: warning: right shift count is negative [-Wshift-count-negative]
:2:136: warning: left shift count >= width of type
[-Wshift-count-overflow]
:2:141: warning: right shift count >= width of type
[-Wshift-count-overflow]
:2:165: warning: left shift count is negative [-Wshift-count-negative]
:2:180: warning: right shift count >= width of type
[-Wshift-count-overflow]
[hang]

Version:

xgcc (GCC) 8.0.1 20180204 (experimental)

built from git fdae6180ad24fa6303fa046114f3e4b66b8db34d

It seems to have been introduced somewhere between 5.5.0 and 6.1.0.

Please see attachment for gdb stack trace.

[Bug c++/84593] [6/7/8 Regression] internal compiler error: Segmentation fault (non_type_check())

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #2 from Alexandre Oliva  ---
Created attachment 43524
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43524=edit
candidate patch

Mine, here's what I'm testing

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=30334

--- Comment #11 from Eric Gallager  ---
(In reply to Xi Ruoyao from comment #8)
> (In reply to Xi Ruoyao from comment #7)
> 
> > We should make a new PR requesting for clang -Warray-bounds as well.  It's
> > a part of meta-bug PR30334.
> 
> Sorry. We have -Warray-bounds, but not as well as clang's.  For example clang
> warns for "aa"[4], but GCC doesn't.

In that case it's a different meta-bug, PR56456

[Bug c++/84492] [8 Regression] ICE with statement expression

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #3 from Alexandre Oliva  ---
Created attachment 43523
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43523=edit
candidate patch

Mine.  Here's the patch I'm testing.

[Bug middle-end/84443] powerpc suboptimal code generation (shrink wrap unlikely path) for Linux spinlocks

[npiggin at gmail dot com]

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

--- Comment #3 from Nicholas Piggin  ---
(In reply to Segher Boessenkool from comment #2)
> If you want some specific machine code for something complex like this, it
> is much easier to write the machine code than to fight the compiler.

Yes, understood. This may be the way we go eventually.

I thought the test case could be interesting for reference. Often times we do
juggle around the C/inline asm code to get a good pattern, which can be a bit
easier than writing it completely in asm. It does not have to be absolutely
optimal of course.

Thanks for taking a look and providing some explanation of the problem. Any
improvement would be great.

> 
> That said:
> 
> 1) "flags" is stored in the same register everywhere.  This is a problem in
> expand: it puts the return value in the same pseudo in the whole function.
> This is a bad idea because (if it did not) after optimisation the return
> value is just a hard register (r3) and putting all _other_ uses in the same
> register is a pessimisation; like here (and in many other cases, there are
> other PRs for this!) it causes that pseudo to be put in a callee-save
> register (r30).
> 
> 2) That should be fixed in expand (to enable other optimisations with the
> return pseudo), but IRA should also be smarter about live-range splitting
> for shrink-wrapping.
> 
> 3) Separate shrink-wrapping should deal with CRFs.  I have a prototype,
> it has a few small problems (we need to handle things a little differently
> for pretty much every ABI, sigh), and it does not help very much until the
> other problems are solved; GCC 9 work);
> 
> 4) Shrink-wrapping itself could also do more live-range splitting than it
> currently does.

[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  ---
I guess this is a case of adding xfails or target requirements to the dg
comments, but I'm not sufficiently familiar with the various vector-related
pseudo-target names to tell which ones would be right, so I'm leaving this for
someone else who does to address.

[Bug target/66433] Arm NEON postincrement optimization missed

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug target/66433] Arm NEON postincrement optimization missed

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
This seems to have been fixed some time ago.  I see autoincs when I test this
on the trunk.

[Bug c++/79005] Use of a captured variable within nested generic lambdas provokes internal compiler error.

[lesliezhai at llvm dot org.cn]

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

Leslie Zhai  changed:

   What|Removed |Added

 CC||lesliezhai at llvm dot org.cn

--- Comment #7 from Leslie Zhai  ---
(In reply to Paolo Carlini from comment #6)
> Fixed in trunk.

Hi Paolo,

Could you please show me which commit fixed the issue in trunk? gcc 5/6/7
branches are still able to reproduce the issue.

Regards,
Leslie Zhai

[Bug tree-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #25 from Alexandre Oliva  ---
Fixed

[Bug tree-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization

[aoliva at gcc dot gnu.org]

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

--- Comment #24 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Feb 28 05:25:34 2018
New Revision: 258053

URL: https://gcc.gnu.org/viewcvs?rev=258053=gcc=rev
Log:
[PR81611] turn inc-and-use-of-dead-orig into auto-inc

When the addressing modes available on the machine don't allow offsets
in addresses, odds are that post-increments will be represented in
trees and RTL as:

  y <= x + 1
  ... *(x) ...
  x <= y

so deal with it by turning such RTL as:

  (set y (plus x n))
  ... (mem x) ...

without intervening uses of y into

  (set y x)
  ... (mem (post_add y n)) ...

so as to create auto-inc addresses that we'd otherwise miss.


for  gcc/ChangeLog

PR rtl-optimization/81611
* auto-inc-dec.c (attempt_change): Move dead note from
mem_insn if it's the next use of regno
(find_address): Take address use of reg holding
non-incremented value.  Add parm to limit search to the named
reg only.
(merge_in_block): Attempt to use a mem insn that is the next
use of the original regno.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/auto-inc-dec.c

[Bug target/82248] probe_stack can generate unpredictable STR on arm

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #7 from Jeffrey A. Law  ---
Fixed by Ramana's patch on the trunk.

[Bug rtl-optimization/82982] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 5) in ready_sort_real in haifa scheduler

[asolokha at gmx dot com]

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

--- Comment #7 from Arseny Solokha  ---
OK, the original issue still reproduces for the powerpc-e500v2-linux-gnuspe
target as of r257975, so the change that affected this issue must have been
local to the rs6000 backend.

[Bug c/84607] New: Side effects discarded in address computation inside 'if'

[stephen.dolan at cl dot cam.ac.uk]

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

Bug ID: 84607
   Summary: Side effects discarded in address computation inside
'if'
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stephen.dolan at cl dot cam.ac.uk
  Target Milestone: ---

This program should print "hello" and "goodbye", but only prints "goodbye":

#include 
int a[10];
int foo() {
  puts("hello");
  return 0;
}
int main() {
  if ([foo()])
puts("goodbye");
  return 0;
}

I tested locally with gcc 7.2.0 (Debian 7.2.0-19). I also tried the program
with the various gcc versions on godbolt.org, and the problem seems to exist in
all versions since gcc 6 (gcc 5.5 is unaffected). The presence or absence of
-O3 doesn't seem to make a difference.

[Bug c++/84604] False positive "may be used uninitialized in this function" due to variable initialization eliminated as dead code

[cas43 at cs dot stanford.edu]

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

--- Comment #2 from Craig Schroeder  ---
I was under the impression I was allowed to call the destructor just like any
other function.  On further investigation, this is undefined behavior, so this
bug report is invalid.

[Bug c++/66944] ICE on static thread_local member in class template

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Last reconfirmed|2015-12-16 00:00:00 |2018-2-28

--- Comment #8 from Marc Glisse  ---
c_parse_final_cleanups calls handle_tls_init several times in the "do ...
while(reconsider)" loop. With a single static thread_local, we get lucky and
the second time prune_vars_needing_no_initialization returns NULL for an early
exit. Otherwise, the function really doesn't look ready for a second call.
static_aggregates has a more complicated handling than tls_aggregates.

[Bug c++/84604] False positive "may be used uninitialized in this function" due to variable initialization eliminated as dead code

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
(In reply to Craig Schroeder from comment #0)
> this->~S();
> a=b+2;

What do you expect this to do? You destruct the object, then access its member
b...

[Bug c++/84606] internal compiler error: Segmentation fault (enclosing_instantiation_of())

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-27
 CC||msebor at gcc dot gnu.org
  Known to work||7.3.0
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from Martin Sebor  ---
Bisected to r257093 (gcc 8.0.1):

r257093 | jason | 2018-01-26 10:25:23 -0500 (Fri, 26 Jan 2018) | 8 lines

PR c++/82514 - ICE with local class in generic lambda.

Before that GCC rejected it with:

pr84606.C: In lambda function:
pr84606.C:5:46: error: expected unqualified-id before ‘}’ token
 void __attribute__((common([] { struct d }))) g();
  ^
pr84606.C: In instantiation of ‘struct s::’:
pr84606.C:6:5:   required from ‘struct s’
pr84606.C:9:8:   required from here
pr84606.C:5:51: error: wrong number of arguments specified for ‘common’
attribute
 void __attribute__((common([] { struct d }))) g();
   ^

[Bug c++/84606] New: internal compiler error: Segmentation fault (enclosing_instantiation_of())

[vegard.nossum at gmail dot com]

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

Bug ID: 84606
   Summary: internal compiler error: Segmentation fault
(enclosing_instantiation_of())
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

Input:

template
struct s {
  struct {
void __attribute__((common([] { struct d }))) g();
  } f;
};

s a {};

Output:

$ xgcc -x c++ -std=c++14 -O3 -c -
: In lambda function:
:4:46: error: expected unqualified-id before '}' token
: In instantiation of 'struct s::':
:5:5:   required from 'struct s'
:8:8:   required from here
:4:33: internal compiler error: Segmentation fault
0x3138779 crash_signal
/home/vegard/git/gcc/gcc/toplev.c:325
0x104b080 enclosing_instantiation_of
/home/vegard/git/gcc/gcc/cp/pt.c:12691
0x117abb3 tsubst_function_decl
/home/vegard/git/gcc/gcc/cp/pt.c:12245
0x11514e5 tsubst_decl
/home/vegard/git/gcc/gcc/cp/pt.c:12729
0x11034de tsubst(tree_node*, tree_node*, int, tree_node*)
/home/vegard/git/gcc/gcc/cp/pt.c:13624
0x1164e71 lookup_template_class_1
/home/vegard/git/gcc/gcc/cp/pt.c:8893
0x1174dce lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/vegard/git/gcc/gcc/cp/pt.c:9168
0x1174dce tsubst_aggr_type
/home/vegard/git/gcc/gcc/cp/pt.c:12074
0x1104a1d tsubst(tree_node*, tree_node*, int, tree_node*)
/home/vegard/git/gcc/gcc/cp/pt.c:13707
0x1155593 tsubst_decl
/home/vegard/git/gcc/gcc/cp/pt.c:13003
0x11034de tsubst(tree_node*, tree_node*, int, tree_node*)
/home/vegard/git/gcc/gcc/cp/pt.c:13624
0x10c53d1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/vegard/git/gcc/gcc/cp/pt.c:16118
0x10ba0da tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/vegard/git/gcc/gcc/cp/pt.c:16322
0x10ba0da tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/vegard/git/gcc/gcc/cp/pt.c:16322
0x11d759b tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
/home/vegard/git/gcc/gcc/cp/pt.c:17057
0x10f3373 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/vegard/git/gcc/gcc/cp/pt.c:18346
0x10f1376 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/vegard/git/gcc/gcc/cp/pt.c:18027
0x10bb79c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/vegard/git/gcc/gcc/cp/pt.c:16838
0x116144f tsubst_attribute
/home/vegard/git/gcc/gcc/cp/pt.c:10172
0x1171600 apply_late_template_attributes
/home/vegard/git/gcc/gcc/cp/pt.c:10274


Version:

xgcc (GCC) 8.0.1 20180204 (experimental)

built from git fdae6180ad24fa6303fa046114f3e4b66b8db34d

Version 7.3.0 don't seem to be affected AFAICS.

Test case was reduced by C-Reduce.

[Bug c++/84605] internal compiler error: in xref_basetypes, at cp/decl.c:13818

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-27
 CC||msebor at gcc dot gnu.org
  Known to work||6.4.0
 Ever confirmed|0   |1
  Known to fail||7.3.0, 8.0

--- Comment #1 from Martin Sebor  ---
Bisection points to r245587 (gcc 7.0.1):

r245587 | jason | 2017-02-20 01:05:08 -0500 (Mon, 20 Feb 2017) | 4 lines

PR c++/79580 - ICE with compound literal

* parser.c (cp_parser_class_head): If we're in the middle of an
expression, use ts_within_enclosing_non_class.

Before then, GCC would reject the code with:

pr84605.C:3:11: error: expected identifier before ‘(’ token
 x(((struct b {})));
   ^
pr84605.C:3:20: error: ‘b::b’ has the same name as the class in which it is
declared
 x(((struct b {})));
^
pr84605.C:3:26: error: ISO C++ forbids declaration of ‘x’ with no type
[-fpermissive]
 x(((struct b {})));
  ^

[Bug c++/84605] New: internal compiler error: in xref_basetypes, at cp/decl.c:13818

[vegard.nossum at gmail dot com]

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

Bug ID: 84605
   Summary: internal compiler error: in xref_basetypes, at
cp/decl.c:13818
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

Input:

struct b {
x(((struct b {})));
};

Output:

$ xgcc -x c++ -std=c++14 -O3 -c -
:2:4: error: expected identifier before '(' token
:2:13: internal compiler error: in xref_basetypes, at cp/decl.c:13818
0xb675a7 xref_basetypes(tree_node*, tree_node*)
/home/vegard/git/gcc/gcc/cp/decl.c:13818
0xf172df cp_parser_class_head
/home/vegard/git/gcc/gcc/cp/parser.c:23181
0xf172df cp_parser_class_specifier_1
/home/vegard/git/gcc/gcc/cp/parser.c:22388
0xf1fcbb cp_parser_class_specifier
/home/vegard/git/gcc/gcc/cp/parser.c:22702
0xf1fcbb cp_parser_type_specifier
/home/vegard/git/gcc/gcc/cp/parser.c:16708
0xf8520a cp_parser_decl_specifier_seq
/home/vegard/git/gcc/gcc/cp/parser.c:13573
0xfb3e8d cp_parser_parameter_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:21440
0xfb67da cp_parser_parameter_declaration_list
/home/vegard/git/gcc/gcc/cp/parser.c:21252
0xfb9470 cp_parser_parameter_declaration_clause
/home/vegard/git/gcc/gcc/cp/parser.c:21173
0xf555ef cp_parser_direct_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19926
0xf5ca20 cp_parser_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19800
0xf56eda cp_parser_direct_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:20019
0xf5ca20 cp_parser_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19800
0xfb4103 cp_parser_parameter_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:21500
0xfb67da cp_parser_parameter_declaration_list
/home/vegard/git/gcc/gcc/cp/parser.c:21252
0xfb9470 cp_parser_parameter_declaration_clause
/home/vegard/git/gcc/gcc/cp/parser.c:21173
0xf555ef cp_parser_direct_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19926
0xf9b858 cp_parser_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19800
0xfdc2e6 cp_parser_member_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:23696
0xf10d9b cp_parser_member_specification_opt
/home/vegard/git/gcc/gcc/cp/parser.c:23308

Version:

xgcc (GCC) 8.0.1 20180204 (experimental)

built from git fdae6180ad24fa6303fa046114f3e4b66b8db34d

Version 7.3.0 don't seem to be affected AFAICS.

Test case was reduced using C-Reduce.

[Bug c++/84604] New: False positive "may be used uninitialized in this function" due to variable initialization eliminated as dead code

[cas43 at cs dot stanford.edu]

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

Bug ID: 84604
   Summary: False positive "may be used uninitialized in this
function" due to variable initialization eliminated as
dead code
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cas43 at cs dot stanford.edu
  Target Milestone: ---

WHAT HAPPENS:

The compiler eliminates a=0; and b=0; from the code below during the dce2
optimization pass, resulting in a warning for use of uninitialized variable. 
Curiously, the generate code seems to be okay.

OFFENDING CODE:

void f();

struct S
{
int a;
int b;

S() 
{
a=0;
b=0;
} 

~S()
{
}

void g(int) 
{
if(a<10)
{
f();
for(int i=0;i<b;i++){}
this->~S();
a=b+2;
}
} 
};

int foo() 
{
S s;
s.g(0);
s.g(0);
return s.a+s.b;
}

OPTIMIZED RESULT: (via -fdump-tree-all)

;; Function foo (_Z3foov, funcdef_no=7, decl_uid=2398, cgraph_uid=7,
symbol_order=7)

foo ()
{
  int s$b;
  int _5;
  int _16;

   [local count: 1073741825]:
  f ();
  _16 = s$b_12(D) + 2;
  if (_16 <= 9)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 1073741827]:
  _5 = s$b_12(D) + _16;
  return _5;

   [local count: 354334802]:
  f ();
  goto ; [100.00%]

}

GENERATED ASM:

.file   "prog.cpp"
.text
.p2align 4,,15
.globl  _Z3foov
.type   _Z3foov, @function
_Z3foov:
.LFB7:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
call_Z1fv
call_Z1fv
movl$2, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE7:
.size   _Z3foov, .-_Z3foov
    .ident  "GCC: (GNU) 8.0.1 20180227 (experimental)"
.section.note.GNU-stack,"",@progbits

COMPILER VERSION:

Using built-in specs.
COLLECT_GCC=/home/craig/new-gcc/i-trunk/bin/g++
COLLECT_LTO_WRAPPER=/home/craig/new-gcc/i-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../s-trunk/configure --prefix=/home/craig/new-gcc/i-trunk
--disable-multilib
Thread model: posix
gcc version 8.0.1 20180227 (experimental) (GCC) 

COMPILATION FLAGS:

g++ prog.cpp -Wall -c -O2

OTHER VERSIONS that give false positev:

4.9.3 (Ubuntu 4.9.3-13ubuntu2)
5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)

[Bug c++/84158] [6/7 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|6.5 |8.0

--- Comment #8 from Martin Sebor  ---
Jason agrees with not backporting, so setting target milestone to 8.0.

[Bug c++/84158] [6/7 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
Summary|[6/7/8 Regression] missing  |[6/7 Regression] missing
   |-Wreturn-type due to|-Wreturn-type due to
   |incorrect handling of   |incorrect handling of
   |attributes for template |attributes for template
   |specializations |specializations

--- Comment #7 from Martin Sebor  ---
Fixed by r258045.  I don't think the fix is safe to backport.

[Bug c++/84158] [6/7/8 Regression] missing -Wreturn-type due to incorrect handling of attributes for template specializations

[msebor at gcc dot gnu.org]

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

Bug 83871 Summary: wrong code for attribute const and pure on distinct template 
specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83871

   What|Removed |Added

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

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #21 from Martin Sebor  ---
Fixed via r258045.

[Bug c++/83871] wrong code for attribute const and pure on distinct template specializations

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #4 from Martin Sebor  ---
Fixed via r258045.

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[msebor at gcc dot gnu.org]

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

Bug 83871 Summary: wrong code for attribute const and pure on distinct template 
specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83871

   What|Removed |Added

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

[Bug c++/83871] wrong code for attribute const and pure on distinct template specializations

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Tue Feb 27 22:28:21 2018
New Revision: 258045

URL: https://gcc.gnu.org/viewcvs?rev=258045=gcc=rev
Log:
PR c++/83871 - wrong code for attribute const and pure on distinct template
specializations
PR c++/83503 - [8 Regression] bogus -Wattributes for const and pure on function
template specialization

gcc/ChangeLog:

PR c++/83871
* gcc/doc/invoke.texi (-Wmissing-attributes): New option.
* gcc/print-tree.c (print_node): Handle DECL_UNINLINABLE.

gcc/c-family/ChangeLog:

PR c++/83871
* c.opt (-Wmissing-attributes): New option.

gcc/cp/ChangeLog:

PR c++/83871
PR c++/83503
* cp-tree.h (warn_spec_missing_attributes): New function.
((check_explicit_specialization): Add an argument.  Call the above
function.
* decl.c (duplicate_decls): Avoid applying primary function template's
attributes to its explicit specializations.
cp/pt.c (warn_spec_missing_attributes): Define.

gcc/testsuite/ChangeLog:

PR c++/83871
PR c++/83503
* g++.dg/Wmissing-attributes.C: New test.
* g++.dg/ext/attr-const-pure.C: New test.
* g++.dg/ext/attr-const.C: New test.
* g++.dg/ext/attr-deprecated-2.C: New test.
* g++.dg/ext/attr-malloc-2.C: New test.
* g++.dg/ext/attr-malloc.C: New test.
* g++.dg/ext/attr-noinline-2.C: New test.
* g++.dg/ext/attr-noinline.C: New test.
* g++.dg/ext/attr-nonnull.C: New test.
* g++.dg/ext/attr-noreturn-2.C: New test.
* g++.dg/ext/attr-noreturn.C: New test.
* g++.dg/ext/attr-nothrow-2.C: New test.
* g++.dg/ext/attr-nothrow.C: New test.
* g++.dg/ext/attr-optimize.C: New test.
* g++.dg/ext/attr-pure.C: New test.
* g++.dg/ext/attr-returns-nonnull.C: New test.
* g++.dg/ext/attr-warning.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/Wmissing-attributes.C
trunk/gcc/testsuite/g++.dg/ext/attr-const-pure.C
trunk/gcc/testsuite/g++.dg/ext/attr-const.C
trunk/gcc/testsuite/g++.dg/ext/attr-deprecated-2.C
trunk/gcc/testsuite/g++.dg/ext/attr-malloc-2.C
trunk/gcc/testsuite/g++.dg/ext/attr-malloc.C
trunk/gcc/testsuite/g++.dg/ext/attr-noinline-2.C
trunk/gcc/testsuite/g++.dg/ext/attr-noinline.C
trunk/gcc/testsuite/g++.dg/ext/attr-nonnull.C
trunk/gcc/testsuite/g++.dg/ext/attr-noreturn-2.C
trunk/gcc/testsuite/g++.dg/ext/attr-noreturn.C
trunk/gcc/testsuite/g++.dg/ext/attr-nothrow-2.C
trunk/gcc/testsuite/g++.dg/ext/attr-nothrow.C
trunk/gcc/testsuite/g++.dg/ext/attr-optimize.C
trunk/gcc/testsuite/g++.dg/ext/attr-pure.C
trunk/gcc/testsuite/g++.dg/ext/attr-returns-nonnull.C
trunk/gcc/testsuite/g++.dg/ext/attr-warning.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/doc/invoke.texi
trunk/gcc/print-tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[msebor at gcc dot gnu.org]

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

--- Comment #20 from Martin Sebor  ---
Author: msebor
Date: Tue Feb 27 22:28:21 2018
New Revision: 258045

URL: https://gcc.gnu.org/viewcvs?rev=258045=gcc=rev
Log:
PR c++/83871 - wrong code for attribute const and pure on distinct template
specializations
PR c++/83503 - [8 Regression] bogus -Wattributes for const and pure on function
template specialization

gcc/ChangeLog:

PR c++/83871
* gcc/doc/invoke.texi (-Wmissing-attributes): New option.
* gcc/print-tree.c (print_node): Handle DECL_UNINLINABLE.

gcc/c-family/ChangeLog:

PR c++/83871
* c.opt (-Wmissing-attributes): New option.

gcc/cp/ChangeLog:

PR c++/83871
PR c++/83503
* cp-tree.h (warn_spec_missing_attributes): New function.
((check_explicit_specialization): Add an argument.  Call the above
function.
* decl.c (duplicate_decls): Avoid applying primary function template's
attributes to its explicit specializations.
cp/pt.c (warn_spec_missing_attributes): Define.

gcc/testsuite/ChangeLog:

PR c++/83871
PR c++/83503
* g++.dg/Wmissing-attributes.C: New test.
* g++.dg/ext/attr-const-pure.C: New test.
* g++.dg/ext/attr-const.C: New test.
* g++.dg/ext/attr-deprecated-2.C: New test.
* g++.dg/ext/attr-malloc-2.C: New test.
* g++.dg/ext/attr-malloc.C: New test.
* g++.dg/ext/attr-noinline-2.C: New test.
* g++.dg/ext/attr-noinline.C: New test.
* g++.dg/ext/attr-nonnull.C: New test.
* g++.dg/ext/attr-noreturn-2.C: New test.
* g++.dg/ext/attr-noreturn.C: New test.
* g++.dg/ext/attr-nothrow-2.C: New test.
* g++.dg/ext/attr-nothrow.C: New test.
* g++.dg/ext/attr-optimize.C: New test.
* g++.dg/ext/attr-pure.C: New test.
* g++.dg/ext/attr-returns-nonnull.C: New test.
* g++.dg/ext/attr-warning.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/Wmissing-attributes.C
trunk/gcc/testsuite/g++.dg/ext/attr-const-pure.C
trunk/gcc/testsuite/g++.dg/ext/attr-const.C
trunk/gcc/testsuite/g++.dg/ext/attr-deprecated-2.C
trunk/gcc/testsuite/g++.dg/ext/attr-malloc-2.C
trunk/gcc/testsuite/g++.dg/ext/attr-malloc.C
trunk/gcc/testsuite/g++.dg/ext/attr-noinline-2.C
trunk/gcc/testsuite/g++.dg/ext/attr-noinline.C
trunk/gcc/testsuite/g++.dg/ext/attr-nonnull.C
trunk/gcc/testsuite/g++.dg/ext/attr-noreturn-2.C
trunk/gcc/testsuite/g++.dg/ext/attr-noreturn.C
trunk/gcc/testsuite/g++.dg/ext/attr-nothrow-2.C
trunk/gcc/testsuite/g++.dg/ext/attr-nothrow.C
trunk/gcc/testsuite/g++.dg/ext/attr-optimize.C
trunk/gcc/testsuite/g++.dg/ext/attr-pure.C
trunk/gcc/testsuite/g++.dg/ext/attr-returns-nonnull.C
trunk/gcc/testsuite/g++.dg/ext/attr-warning.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c
trunk/gcc/doc/invoke.texi
trunk/gcc/print-tree.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/82982] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 5) in ready_sort_real in haifa scheduler

[willschm at gcc dot gnu.org]

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

--- Comment #6 from Will Schmidt  ---
(In reply to Will Schmidt from comment #4)
> Tried to re-create locally, I've gotten two ICE's using the provided
> testcode snippet, neither look quite like the originally reported issue. 
> (thus I don't know if this is actually the same issue).
> 
> Neither of these require the -fgraphite-identity option be specified.  -m32
> or -m64 doesn't seem to matter for me. 
><...>


(In reply to Arseny Solokha from comment #5)
> (In reply to Will Schmidt from comment #4)
> > Tried to re-create locally, I've gotten two ICE's using the provided
> > testcode snippet, neither look quite like the originally reported issue. 
> 
> You are right. I also cannot reproduce the original issue anymore w/ r257975.

Today I cannot get any ICE's out of this test.  Wonder if things were fixed up
in the mean-time, or if I tickled a config option and managed to hide the
issue(s).   Going to try a few more runs with older trees to see if I can
verify things are fixed.

[Bug translation/84207] Hard coded plural in gimple-fold.c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed via r258044.

[Bug translation/84207] Hard coded plural in gimple-fold.c

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Tue Feb 27 22:06:03 2018
New Revision: 258044

URL: https://gcc.gnu.org/viewcvs?rev=258044=gcc=rev
Log:
PR translation/84207 - Hard coded plural in gimple-fold.c

gcc/ChangeLog:

PR translation/84207
* diagnostic-core.h (warning_n, error_n, inform_n): Change
n argument to unsigned HOST_WIDE_INT.
* diagnostic.c (warning_n, error_n, inform_n): Ditto.
(diagnostic_n_impl): Ditto.  Handle arguments in excess of LONG_MAX.
* gimple-ssa-sprintf.c (format_directive): Simplify inform_n call.
* tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Use warning_n.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic-core.h
trunk/gcc/diagnostic.c
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/tree-ssa-strlen.c

[Bug testsuite/84597] [8 regression] test case g++.dg/ext/timevar2.C fails starting with r258029

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #2 from Nathan Sidwell  ---
Seeing this on x86_64-linux too FWIW

[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?

[jakub at gcc dot gnu.org]

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

--- Comment #31 from Jakub Jelinek  ---
Thanks for the hint.

So:
#include 

struct S {
  int a : 2;
  __declspec(align(8)) int b : 2;
  int c : 28;
  __declspec(align(16)) int d : 2;
  int e : 30;
} s;
int a = sizeof (struct S);
void f1 (int x) { s.a = x; }
void f2 (int x) { s.b = x; }
void f3 (int x) { s.c = x; }
void f4 (int x) { s.d = x; }
void f5 (int x) { s.e = x; }

void
printme (void)
{
int i;
for (i = 0; i < sizeof (s); ++i)
printf ("%02x, ", ((unsigned char *) )[i]);
printf ("\n");
}

int
main ()
{
printf ("%d\n", (int) sizeof (s));
s.a = -1; printme ();
s.a = 0; s.b = -1; printme ();
s.b = 0; s.c = -1; printme ();
s.c = 0; s.d = -1; printme ();
s.d = 0; s.e = -1; printme ();
return 0;
}

matches what GCC with the patch emits (that is the bf-ms-layout-5.c test),
and so does:
#include 

#ifdef _WIN32
# ifdef _MSC_VER
#  define PACK(typeDec) __pragma( pack(push, 1) ) typeDec __pragma( pack(pop) )
# else
#  define PACK(typeDec) typeDec __attribute__((__packed__,ms_struct))
# endif
#else
# define PACK(typeDec) typeDec __attribute__((__packed__))
#endif

#ifdef _MSC_VER
# define ALIGN(typeDec, n) __declspec(align(n)) typeDec
#else
# define ALIGN(typeDec, n) typeDec __attribute__((aligned(n)))
#endif

#define assert_cc(expr) extern char c[(expr) ? 1 : -1]

PACK(struct test_sp1 {
int a;
short b;
int c;
char d;
});

assert_cc(sizeof(struct test_sp1) == 11);
assert_cc(offsetof(struct test_sp1, a) == 0);
assert_cc(offsetof(struct test_sp1, b) == 4);
assert_cc(offsetof(struct test_sp1, c) == 6);
assert_cc(offsetof(struct test_sp1, d) == 10);

PACK(struct test_sp3 {
int a;
ALIGN(short b, 8);
int c;
char d;
});

assert_cc(sizeof(struct test_sp3) == 16);
assert_cc(offsetof(struct test_sp3, a) == 0);
assert_cc(offsetof(struct test_sp3, b) == 8);
assert_cc(offsetof(struct test_sp3, c) == 10);
assert_cc(offsetof(struct test_sp3, d) == 14);

struct test_s4 {
int a;
short b;
int c:15;
char d;
};

#ifdef _WIN32
assert_cc(sizeof(struct test_s4) == 16);
assert_cc(offsetof(struct test_s4, a) == 0);
assert_cc(offsetof(struct test_s4, b) == 4);
assert_cc(offsetof(struct test_s4, d) == 12);
#else
assert_cc(sizeof(struct test_s4) == 12);
assert_cc(offsetof(struct test_s4, a) == 0);
assert_cc(offsetof(struct test_s4, b) == 4);
assert_cc(offsetof(struct test_s4, d) == 8);
#endif

int main () { return 0; }

(bf-ms-layout-4.c).
So does:
#define _TEST_MS_LAYOUT
#include 
#include 

extern void abort();

#pragma pack(8)

struct one {
  int d;
  unsigned char a;
  unsigned short b:7;
  char c;
} ;

struct two {
  int d;
  unsigned char a;
  unsigned int b:7;
  char c;
} ;

struct three {
  short d;
  unsigned short a:3;
  unsigned short b:9;
  unsigned char c:7;
} ;


/* Bitfields of size 0 have some truly odd behaviors. */

struct four {
  unsigned short a:3;
  unsigned short b:9;
  unsigned int :0;  /* forces struct alignment to int */
  unsigned char c:7;
} ;

struct five {
  char a;
  int :0;/* ignored; prior field is not a bitfield. */
  char b;
  char c;
} ;

struct six {
  char a :8;
  int :0;   /* not ignored; prior field IS a bitfield, causes
   struct alignment as well. */
  char b;
  char c;
} ;

struct seven {
  char a:8;
  char :0;
  int  :0;  /* Ignored; prior field is zero size bitfield. */
  char b;
  char c;
} ;

struct eight { /* ms size 4 */
  short b:3;
  char  c;
} ;

#ifdef _MSC_VER
#define LONGLONG __int64
#else
#define LONGLONG long long
#endif

union nine {   /* ms size 8 */
  LONGLONG a:3;
  char  c;
} ;

struct ten {   /* ms size 16 */
  LONGLONG a:3;
  LONGLONG b:3;
  char  c;
} ;


#define val(s,f) (s.f)

#define check_struct(_X) \
{ \
  if (sizeof (struct _X) != exp_sizeof_##_X )   \
abort();\
  memcpy(_##_X, filler, sizeof(test_##_X));\
  if (val(test_##_X,c) != exp_##_X##_c) \
 abort();   \
}

#define check_union(_X) \
{ \
  if (sizeof (union _X) != exp_sizeof_##_X )\
abort();\
  memcpy(_##_X, filler, sizeof(test_##_X));\
  if (val(test_##_X,c) != exp_##_X##_c) \
 abort();   \
}

#define check_struct_size(_X) \
{ \
  if (sizeof (struct _X) != exp_sizeof_##_X )   \
abort();\
}

#define check_struct_off(_X) \
{ \
  memcpy(_##_X, filler, sizeof(test_##_X));\
  if (val(test_##_X,c) != exp_##_X##_c) \
abort();\
}

#define check_union_size(_X) \
{ \
  if (sizeof (union _X) != exp_sizeof_##_X )\
abort();\
}

#define check_union_off(_X) \
{ \
  memcpy(_##_X, filler, sizeof(test_##_X));\
  if (val(test_##_X,c) != exp_##_X##_c) \
abort();\
}

int main(){

  unsigned char filler[16];
  

[Bug c++/84489] [6/7 Regression] Non-type template parameter dependency

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[6/7/8 Regression] Non-type |[6/7 Regression] Non-type
   |template parameter  |template parameter
   |dependency  |dependency
  Known to fail|8.0 |

--- Comment #3 from Jason Merrill  ---
Fixed on trunk so far.

[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower

[glisse at gcc dot gnu.org]

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

--- Comment #19 from Marc Glisse  ---
(In reply to Aldy Hernandez from comment #16)
> It seems tree-ssa-reassoc.c avoids reassociating most non-bit expressions by
> design (because of signed overflows):
[...]
> So instead of whacking tree-ssa-reassoc.c to handle POINTER_PLUS_EXPR and
> PLUS_EXPR, etc,

There have been suggestions that we should do reassoc after some kind of
lowering, where all integer operations wrap, maybe pointer operations are
replaced with integer operations, etc.

[Bug c++/71546] lambda capture fails with "was not declared in this scope"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #2 from Jason Merrill  ---
Fixed for GCC 8.

[Bug target/84534] [8 regression] several powerpc test cases fail starting with r257915

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-27
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Peter Bergner  ---
Actually, I see the vec-setup-be-long.c FAIL even using the revision before
Vlad's commit.  The problem seems to be related to PR78303, which is basically
-maltivec=be has issues on LE and instead of fixing them, we've decided to
deprecate -maltivec=be when targeting LE and -maltivec=le when targeting BE, so
I'll look at XFAILing the test on LE.

I agree with Vlad the others are not compiler bugs, but instead are test case
bugs.  I haven't decided yet whether to just update the counts or whether to
just remove the scan for xxlor all together, since I doubt we're really
interested in that we generated them at all versus some of the other insns.

[Bug c++/54367] [meta-bug] lambda expressions

[jason at gcc dot gnu.org]

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

Bug 71546 Summary: lambda capture fails with "was not declared in this scope"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71546

   What|Removed |Added

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

[Bug c++/71546] lambda capture fails with "was not declared in this scope"

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Tue Feb 27 20:57:35 2018
New Revision: 258043

URL: https://gcc.gnu.org/viewcvs?rev=258043=gcc=rev
Log:
PR c++/71546 - lambda init-capture with qualified-id.

* parser.c (cp_parser_lambda_introducer): Clear scope after
each lambda capture.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-init17.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower

[law at redhat dot com]

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

--- Comment #18 from Jeffrey A. Law  ---
A couple more notes.  It could also well be the case that reassociating in a
way that encourages lea could be good for x86, but bad for other targets.

I also suspect this is closely related to other BZs in the database where we've
regressed due to poor addressing mode selections.  If you're able to make
progress here I'll dig them out and we can cross-check your patch against those
other bugs.

[Bug c++/84426] [8 Regression] ICE with conflicting class member names

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Fixed r258042.

[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower

[law at redhat dot com]

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

--- Comment #17 from Jeffrey A. Law  ---
It could well end up being a case where we need to look to see if the
expressions are likely to CSE to determine which is better.

I'm not sure if reassoc has that kind of capability.

[Bug c++/84426] [8 Regression] ICE with conflicting class member names

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Author: nathan
Date: Tue Feb 27 20:52:15 2018
New Revision: 258042

URL: https://gcc.gnu.org/viewcvs?rev=258042=gcc=rev
Log:
[PR c++/84426] ICE after conflicting member decl

https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01529.html
PR c++/84426
* name-lookup.h (get_member_slot): Rename ...
(find_member_slot): ... here.
(add_member_slot): New.
* name-lookup.c (member_vec_linear_search): No need to check for
NULL slot.
(get_member_slot): Rename ...
(find_member_slot): ... here.  Don't add slot for incomplete class.
(add_member_slot): New.
* class.c (add_method): Adjust get_member_slot rename.  Bail out
if push_class_level_binding fails.  Create slot and grok
properties once we're committed to insertion.

PR c++/84426
* g++.dg/lookup/pr84426.C: New.

Added:
trunk/gcc/testsuite/g++.dg/lookup/pr84426.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/name-lookup.h
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/84595] Add __builtin_break() built-in for a breakpointing mechanism

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #6 from David Malcolm  ---
Compare with e.g. the G_BREAKPOINT macro within GNOME's GLib library, which has
accumulated a collection of platform-specific logic for C/C++ code that wants
to inject a breakpoint:
  http://git.gnome.org/browse/glib/tree/glib/gbacktrace.h
(LGPLv2+ licensed)

I had a go at adding something similar to CPython:
  https://bugs.python.org/issue9635
(albeit for fewer platforms)

It seems useful to have this in either the compiler or in GNU libc.

[Bug c++/84602] [8 Regression] internal compiler error: in search_anon_aggr, at cp/name-lookup.c:1218

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/84602] [8 Regression] internal compiler error: in search_anon_aggr, at cp/name-lookup.c:1218

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-27
 CC||dmalcolm at gcc dot gnu.org,
   ||nathan at acm dot org
Summary|internal compiler error: in |[8 Regression] internal
   |search_anon_aggr, at|compiler error: in
   |cp/name-lookup.c:1218   |search_anon_aggr, at
   ||cp/name-lookup.c:1218
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed.  Started with r252005.

[Bug middle-end/84603] New: -finline-limit not accepted in attribute and #pragma optimize

[msebor at gcc dot gnu.org]

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

Bug ID: 84603
   Summary: -finline-limit not accepted in attribute and #pragma
optimize
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In testing my patch for bug 83871 I tried to verify that
DECL_DISREGARD_INLINE_LIMITS() is being handled as expected by
duplicate_decls().  I found out that even though the C and C++ front ends try
to handle the limits the -finline-limit option itself is not recognized by
either attribute optimize or #pragma GCC optimize.

Debugging the code shows that the warning is issued by parse_optimize_options()
in response to options that aren't tagged as optimization options.  Sure
enough, common.opt doesn't specify Optimization for the option:

  finline-limit-
  Common RejectNegative Joined Alias(finline-limit=)

  finline-limit=
  Common RejectNegative Joined UInteger
  -finline-limit=   Limit the size of inlined functions to
.

$ cat b.c && gcc -O1 -S -Wall -Wextra -finline-limit=16 b.c
#pragma GCC optimize ("inline-functions")

void f0 (void);

#pragma GCC optimize ("align-loops=32")

void f1 (void);

#pragma GCC optimize ("inline-limit=32")

void f2 (void);

void __attribute__ ((optimize ("inline-functions")))
f3(void);

void __attribute__ ((optimize ("inline-limit=100")))
f4 (void);
b.c:9:9: warning: bad option ‘-finline-limit=32’ to pragma ‘optimize’
[-Wpragmas]
 #pragma GCC optimize ("inline-limit=32")
 ^~~
b.c:11:1: warning: bad option ‘-finline-limit=32’ to attribute ‘optimize’
[-Wattributes]
 void f2 (void);
 ^~~~
b.c:14:1: warning: bad option ‘-finline-limit=32’ to attribute ‘optimize’
[-Wattributes]
 f3(void);
 ^~
b.c:17:1: warning: bad option ‘-finline-limit=32’ to attribute ‘optimize’
[-Wattributes]
 f4 (void);
 ^~
b.c:17:1: warning: bad option ‘-finline-limit=100’ to attribute ‘optimize’
[-Wattributes]

[Bug c++/84602] New: internal compiler error: in search_anon_aggr, at cp/name-lookup.c:1218

[vegard.nossum at gmail dot com]

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

Bug ID: 84602
   Summary: internal compiler error: in search_anon_aggr, at
cp/name-lookup.c:1218
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

Input:

struct {
  struct {
class a;
  }; : a
} x;

Output:

$ xgcc -x c++ -std=c++14 -O3 -c - 2>&1
:4:8: internal compiler error: in search_anon_aggr, at
cp/name-lookup.c:1218
0xe0afdb search_anon_aggr(tree_node*, tree_node*)
/home/vegard/git/gcc/gcc/cp/name-lookup.c:1218
0xe0a503 fields_linear_search
/home/vegard/git/gcc/gcc/cp/name-lookup.c:1177
0xe0bba0 get_class_binding_direct(tree_node*, tree_node*, int)
/home/vegard/git/gcc/gcc/cp/name-lookup.c:1280
0x1222866 lookup_field_r
/home/vegard/git/gcc/gcc/cp/search.c:977
0x1228797 dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*),
tree_node* (*)(tree_node*, void*), void*)
/home/vegard/git/gcc/gcc/cp/search.c:1410
0x1228797 lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
/home/vegard/git/gcc/gcc/cp/search.c:1134
0x9d0a20 maybe_note_name_used_in_class(tree_node*, tree_node*)
/home/vegard/git/gcc/gcc/cp/class.c:8232
0xf45322 cp_parser_class_name
/home/vegard/git/gcc/gcc/cp/parser.c:22358
0xf45bf9 cp_parser_type_name
/home/vegard/git/gcc/gcc/cp/parser.c:17284
0xf2af69 cp_parser_type_name
/home/vegard/git/gcc/gcc/cp/parser.c:17266
0xf2af69 cp_parser_simple_type_specifier
/home/vegard/git/gcc/gcc/cp/parser.c:17138
0xf734e6 cp_parser_postfix_expression
/home/vegard/git/gcc/gcc/cp/parser.c:6947
0xf26fa7 cp_parser_unary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:8281
0xebcdba cp_parser_cast_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9049
0xebf3e6 cp_parser_binary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9150
0xec8900 cp_parser_constant_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9713
0xfdb3ef cp_parser_member_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:23623
0xf10d9b cp_parser_member_specification_opt
/home/vegard/git/gcc/gcc/cp/parser.c:23308
0xf10d9b cp_parser_class_specifier_1
/home/vegard/git/gcc/gcc/cp/parser.c:22450
0xf1fcbb cp_parser_class_specifier
/home/vegard/git/gcc/gcc/cp/parser.c:22702

Version:

xgcc (GCC) 8.0.1 20180204 (experimental)

built from git fdae6180ad24fa6303fa046114f3e4b66b8db34d

Bug doesn't seem present in 7.3.

Test case reduced by C-Reduce.

[Bug c/84600] function inlining is confused by char * type cast

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
char** and char* are distant types and different with respect to aliasing.  So
storing as char* and then loading as char** is undefined behavior.  void* is
treated as being able to alias with any other pointer type (like accessing via
the character types).

[Bug libstdc++/84601] [8 Regression] std::optional<std::pair<int, int>> is not assignment copyable

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #1 from Ville Voutilainen  ---
Mine.

[Bug middle-end/84443] powerpc suboptimal code generation (shrink wrap unlikely path) for Linux spinlocks

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
If you want some specific machine code for something complex like this, it
is much easier to write the machine code than to fight the compiler.

That said:

1) "flags" is stored in the same register everywhere.  This is a problem in
expand: it puts the return value in the same pseudo in the whole function.
This is a bad idea because (if it did not) after optimisation the return
value is just a hard register (r3) and putting all _other_ uses in the same
register is a pessimisation; like here (and in many other cases, there are
other PRs for this!) it causes that pseudo to be put in a callee-save
register (r30).

2) That should be fixed in expand (to enable other optimisations with the
return pseudo), but IRA should also be smarter about live-range splitting
for shrink-wrapping.

3) Separate shrink-wrapping should deal with CRFs.  I have a prototype,
it has a few small problems (we need to handle things a little differently
for pretty much every ABI, sigh), and it does not help very much until the
other problems are solved; GCC 9 work);

4) Shrink-wrapping itself could also do more live-range splitting than it
currently does.

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[kargl at gcc dot gnu.org]

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

--- Comment #20 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #18)
> > After several people including have gone down rabbit
> > holes trying to fix this bug, I have found a patch!
> 
> The patch at https://gcc.gnu.org/ml/fortran/2018-02/msg00181.html fixes
> several tests in this PR, but not the ones in comment 14

The code in comment 13 is irrelevant.  You get can the same
backtrace without transfer


  type t
character :: z
  end type t
  type(t), parameter :: s(5) = t('a')
  if (s%z /= 'a') stop 1
  end

f951: internal compiler error: Segmentation fault
0xcf8d7f crash_signal
../../gcc/gcc/toplev.c:325
0x1607d70 splay_tree_min
../../gcc/libiberty/splay-tree.c:484
0x75bd7d gfc_constructor_first(splay_tree_s*)
../../gcc/gcc/fortran/constructor.c:234
0x77b03f find_component_ref
../../gcc/gcc/fortran/expr.c:1356
0x77b03f simplify_const_ref
../../gcc/gcc/fortran/expr.c:1795
0x77b42d simplify_const_ref
../../gcc/gcc/fortran/expr.c:1740
0x77bbad gfc_simplify_expr(gfc_expr*, int)
../../gcc/gcc/fortran/expr.c:2004
0x77bccd simplify_parameter_variable
../../gcc/gcc/fortran/expr.c:1869
0x77bb8e gfc_simplify_expr(gfc_expr*, int)
../../gcc/gcc/fortran/expr.c:1976

[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?

[dev at benjarobin dot fr]

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

--- Comment #30 from Benjamin Robin  ---
The test cases bf-ms-layout.c and bf-ms-layout-2.c are valid.
You can test it with an online compiler, for example:
http://rextester.com/l/c_online_compiler_visual

[Bug fortran/84594] Warning: Use of the NUMERIC_STORAGE_SIZE named constant from intrinsic module ISO_FORTRAN_ENV at (1) is incompatible with option -fdefault-integer-8

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #0)
> Compiling gfortran.dg/iso_fortran_env_1.f90 with -fdefault-integer-8 gives:
> 
> Warning: Use of the NUMERIC_STORAGE_SIZE named constant from intrinsic
> module ISO_FORTRAN_ENV at (1) is incompatible with option -fdefault-integer-8
> 

This is expected.  This PR should be closed as INVALID.

[Bug libstdc++/84601] [8 Regression] std::optional<std::pair<int, int>> is not assignment copyable

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-27
 Ever confirmed|0   |1

[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #16 from Aldy Hernandez  ---
> Coming out of SSA for hand_benchmark_cache_ronly(), we seem to be
> calculating:
> 
> ((index + 1) * 8) + x
> ((index + 2) * 8) + x
> ((index + 3) * 8) + x
> etc
> 
> After slsr we have:
> 
> (index * 8) + x
> (((index * 8) + 8) + x)
> index * 8) + 8) + 8) + x)
> 
> And finally after forwprop4:
> 
> (index * 8) + x
> (((index * 8) + 8) + x)
> (((index * 8) + 16) + x)
> 
> Are you suggesting we reassociate the above as:
> 
> ((index * 8) + CONSTANT) + x

Err, what I meant is that we should reassociate as (index * 8 + x) + CONSTANT.

It seems tree-ssa-reassoc.c avoids reassociating most non-bit expressions by
design (because of signed overflows):

  /* For non-bit or min/max operations we can't associate
 all types.  Verify that here.  */

(After the following:

PR tree-optimization/45232
* tree-ssa-reassoc.c (can_reassociate_p): Disable re-association
for types with undefined overflow.
(reassociate_bb): Allow re-associating of bit and min/max
operations for types with undefined overflow.
* tree-ssa-forwprop.c (associate_plusminus): New function.
)

The code that introduced the above, moved some arithmetic reassociation to 
reassociate_plusminus() in forwprop, which eventually landed in match.md.  So
instead of whacking tree-ssa-reassoc.c to handle POINTER_PLUS_EXPR and
PLUS_EXPR, etc, perhaps we can reassociate from match.pd early in the
compilation process.

So, reassociate:

(ind + 3) * 8 + x

into:

(8*ind + x) + 24

And pray for the best.  I'll take a look.

[Bug testsuite/84597] [8 regression] test case g++.dg/ext/timevar2.C fails starting with r258029

[seurer at gcc dot gnu.org]

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

--- Comment #1 from seurer at gcc dot gnu.org ---
I missed that timevar1.C is also failing.

> FAIL: g++.dg/ext/timevar1.C  -std=gnu++11 (test for excess errors)
> FAIL: g++.dg/ext/timevar1.C  -std=gnu++14 (test for excess errors)
> FAIL: g++.dg/ext/timevar1.C  -std=gnu++98 (test for excess errors)
> FAIL: g++.dg/ext/timevar2.C  -std=gnu++11 (test for excess errors)
> FAIL: g++.dg/ext/timevar2.C  -std=gnu++14 (test for excess errors)
> FAIL: g++.dg/ext/timevar2.C  -std=gnu++98 (test for excess errors)

[Bug c++/39751] ICE in cp_lexer_new_from_tokens, at cp/parser.c:342

[vegard.nossum at gmail dot com]

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

Vegard Nossum  changed:

   What|Removed |Added

 CC||vegard.nossum at gmail dot com

--- Comment #10 from Vegard Nossum  ---
Original test case still causes a crash in trunk (8.0.1 20180227), here 8.0.1
20180204:

:5:1: error: types may not be defined in template arguments
:6:4: error: ISO C++ forbids declaration of 'f' with no type
[-fpermissive]
:6:6: error: expected '}' at end of input
:5:1: note: to match this '{'
:6:6: error: expected template-argument at end of input
:6:6: error: expected '>' at end of input
:4:1: error: expected unqualified-id at end of input
:4:1: error: expected '}' at end of input
:3:1: note: to match this '{'
:4:1: internal compiler error: in cp_lexer_new_from_tokens, at
cp/parser.c:689
0xe8d9df cp_lexer_new_from_tokens
/home/vegard/git/gcc/gcc/cp/parser.c:689
0xe8d9df cp_parser_push_lexer_for_tokens
/home/vegard/git/gcc/gcc/cp/parser.c:3946
0xf9ae96 cp_parser_late_parsing_for_member
/home/vegard/git/gcc/gcc/cp/parser.c:27507
0xf14765 cp_parser_class_specifier_1
/home/vegard/git/gcc/gcc/cp/parser.c:22676
0xf1fcbb cp_parser_class_specifier
/home/vegard/git/gcc/gcc/cp/parser.c:22702
0xf1fcbb cp_parser_type_specifier
/home/vegard/git/gcc/gcc/cp/parser.c:16708
0xf8520a cp_parser_decl_specifier_seq
/home/vegard/git/gcc/gcc/cp/parser.c:13573
0xf9fe9f cp_parser_single_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:27017
0xfc2718 cp_parser_template_declaration_after_parameters
/home/vegard/git/gcc/gcc/cp/parser.c:26706
0xfc0d1b cp_parser_explicit_template_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:26944
0xfc0d1b cp_parser_template_declaration_after_export
/home/vegard/git/gcc/gcc/cp/parser.c:26962
0xffbd51 cp_parser_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12673
0xff298b cp_parser_declaration_seq_opt
/home/vegard/git/gcc/gcc/cp/parser.c:12600
0xff3fb3 cp_parser_translation_unit
/home/vegard/git/gcc/gcc/cp/parser.c:4559
0xff3fb3 c_parse_file()
/home/vegard/git/gcc/gcc/cp/parser.c:38820
0x15a0525 c_common_parse_file()
/home/vegard/git/gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug libstdc++/84601] New: std::optional<std::pair<int, int>> is not assignment copyable

[romain.geissler at amadeus dot com]

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

Bug ID: 84601
   Summary: std::optional> is not assignment
copyable
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

I am having trouble with this simple code snippet:

<

using pair_t = std::pair;
using opt_t = std::optional;

static_assert(std::is_copy_constructible_v);
static_assert(std::is_copy_assignable_v);

static_assert(std::is_copy_assignable_v); // assertion fails.

class A
{
void f(const opt_t& opt)
{
_opt = opt; // compilation failure here. 
}

opt_t _opt;
};
EOF

Compiled with:  -std=gnu++17

gcc 8 says:
<); // assertion fails.
   ^~~
file.cpp: In member function ‘void A::f(const opt_t&)’:
file.cpp:15:16: error: use of deleted function ‘std::optional >& std::optional >::operator=(const
std::optional >&)’
 _opt = opt; // compilation failure here.
^~~
In file included from file.cpp:1:
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4.0.14/include/c++/8.0.1/optional:612:11:
note: ‘std::optional >& std::optional
>::operat
or=(const std::optional >&)’ is implicitly deleted because
the default definition would be ill-formed:
 class optional
   ^~~~
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4.0.14/include/c++/8.0.1/optional:612:11:
error: use of deleted function ‘std::_Optional_base<_Tp, true, true>&
std::_Optional_ba
se<_Tp, true, true>::operator=(const std::_Optional_base<_Tp, true, true>&)
[with _Tp = std::pair]’
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4.0.14/include/c++/8.0.1/optional:560:23:
note: ‘std::_Optional_base<_Tp, true, true>& std::_Optional_base<_Tp, true,
true>::oper
ator=(const std::_Optional_base<_Tp, true, true>&) [with _Tp = std::pair]’ is implicitly deleted because the default definition would be
ill-formed:
   _Optional_base& operator=(const _Optional_base&) = default;
   ^~~~
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4.0.14/include/c++/8.0.1/optional:560:23:
error: use of deleted function ‘std::_Optional_payload,
true>& std:
:_Optional_payload, true>::operator=(const
std::_Optional_payload, true>&)’
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4.0.14/include/c++/8.0.1/optional:105:12:
note: ‘std::_Optional_payload, true>&
std::_Optional_payload, true>::operator=(const std::_Optional_payload, true>&)’ is implicitly deleted because the default definition would be
ill-formed:
 struct _Optional_payload
^
/remote/tools/Linux/2.6/1A/toolchain/x86_64-2.6.32-v4.0.14/include/c++/8.0.1/optional:159:24:
error: union member ‘std::_Optional_payload,
true>::
::_M_payload’ with non-trivial ‘std::pair<_T1, _T2>& std::pair<_T1,
_T2>::operator=(typename
std::conditional,
std::is_copy_assignable<_T2>
>::value, const std::pair<_T1, _T2>&, const std::__nonesuch_no_braces&>::type) 
>[with _T1 = int; _T2 = int; typename 
>std::conditional, std::i
s_copy_assignable<_T2> >::value, const std::pair<_T1, _T2>&, const
std::__nonesuch_no_braces&>::type = const std::pair&]’
   _Stored_type _M_payload;
^~
GCC_ERROR

Clang 6 fails with similar reason (non trivial copy assignment operator on
union member):

<'
static_assert(std::is_copy_assignable_v); // assertion fails.
^ 
file.cpp:15:14: error: object of type 'std::optional >'
cannot be assigned because its copy assignment operator is implicitly deleted
_opt = opt; // compilation failure here.
 ^
/opt/1A/toolchain/x86_64-2.6.32-v4.0.14/lib64/gcc/x86_64-1a-linux-gnu/8.0.1/../../../../include/c++/8.0.1/optional:613:7:
note: copy assignment operator of 'optional >' is implicitly deleted because base class '_Optional_base >' has a deleted copy assignment operator
: private _Optional_base<_Tp>,
  ^
/opt/1A/toolchain/x86_64-2.6.32-v4.0.14/lib64/gcc/x86_64-1a-linux-gnu/8.0.1/../../../../include/c++/8.0.1/optional:560:23:
note: explicitly defaulted function was implicitly deleted
 here
  _Optional_base& operator=(const _Optional_base&) = default;
  ^
/opt/1A/toolchain/x86_64-2.6.32-v4.0.14/lib64/gcc/x86_64-1a-linux-gnu/8.0.1/../../../../include/c++/8.0.1/optional:584:30:
note: copy 

[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?

[jakub at gcc dot gnu.org]

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

--- Comment #29 from Jakub Jelinek  ---
Created attachment 43522
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43522=edit
gcc8-pr52991.patch

Full untested patch (except for
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} dg.exp=attr-ms*'
on x86_64-linux), though this really needs to be double-checked against what VC
does, on all the changed testcases.

[Bug c++/84599] following code gives different output for normal compilation and -O2 compiler.

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Without optimization, -fsanitize=undefined shows:

/tmp/t.c:13:22: runtime error: signed integer overflow: 968551222 * 3 cannot be
represented in type 'int'

With -O2, -fsanitize=undefined shows:

/tmp/t.c:13:22: runtime error: signed integer overflow: 968551222 * 3 cannot be
represented in type 'int'
/tmp/t.c:13:22: runtime error: signed integer overflow: 1143237676 * 3 cannot
be represented in type 'int'

Looks like it's the * 3 within:
   mSeed = mSeed * 3 + 1;
and hence the code is relying on the behavior of that overflow, which
optimization is allowed to change.

[Bug c++/84598] internal compiler error: Segmentation fault (cp_default_conversion())

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-27
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed.

ICE started with -std=c++14 with r208404.
ICE started with -std=c++11 with r207436.

[Bug testsuite/83983] FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8)

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #4 from Eric Botcazou  ---
This also fails on SPARC64/Linux:

/home/ebotcazou/src/gcc/testsuite/g++.dg/lto/pr83121_0.C:6:8: warning: type
'st\
ruct Environment' violates the C++ One Definition Rule [-Wodr]^M
/home/ebotcazou/src/gcc/testsuite/g++.dg/lto/pr83121_1.C:1:8: note: a type
with\
 different size is defined in another translation unit^M
PASS: g++.dg/lto/pr83121  (test for LTO warnings, pr83121_0.C line 6)
FAIL: g++.dg/lto/pr83121  (test for LTO warnings, pr83121_0.C line 8)
FAIL: g++.dg/lto/pr83121  (test for LTO warnings, pr83121_1.C line 2)
FAIL: g++.dg/lto/pr83121  (test for LTO warnings, pr83121_1.C line 3)
PASS: g++.dg/lto/pr83121 cp_lto_pr83121_0.o-cp_lto_pr83121_1.o link, -O0 -flto

[Bug c++/84582] [8 Regression] Rejected valid C++ code since r257961

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
(In reply to Marek Polacek from comment #6)
> So do you think that we don't want the patch in Comment 3?

Correct, that patch is wrong.

[Bug c++/84489] [6/7/8 Regression] Non-type template parameter dependency

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue Feb 27 17:26:47 2018
New Revision: 258039

URL: https://gcc.gnu.org/viewcvs?rev=258039=gcc=rev
Log:
PR c++/84489 - dependent default template argument

* pt.c (type_unification_real): Handle early substitution failure.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug target/84534] [8 regression] several powerpc test cases fail starting with r257915

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
Actually, it is not a failure.  I believe it is an improvement.  We have less
move insns now.  The easiest way to fix is to change the expected move insns to
the current number.

I'd prefer changing the exact counts to less or equal number of the counts. 
But I don't know how to write it using dejagnu test directives.

[Bug c/84600] New: function inlining is confused by char * type cast

[popinet at basilisk dot fr]

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

Bug ID: 84600
   Summary: function inlining is confused by char * type cast
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: popinet at basilisk dot fr
  Target Milestone: ---

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

The attached code fails when run using:

gcc -Wall -Wextra -O2 test.c -o test && ./test

using -O1 or -fno-strict-aliasing or not using inlining fixes the problem.
Switching to gcc versions < 6 or to clang 3.8.1 also fixes the problem, as do
the various modifications suggested as comments in the code.

The fact that uncommenting the (always true) condition fixes the problem is
particularly curious.

Thank you for your attention.

[Bug target/84534] [8 regression] several powerpc test cases fail starting with r257915

[seurer at gcc dot gnu.org]

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

--- Comment #2 from seurer at gcc dot gnu.org ---
xxlor counting failures are really common for powerpc test cases.  Perhaps we
should look at all the ones that do that to see if those xxlor count checks are
actually testing for anything useful?

[Bug c++/84582] [8 Regression] Rejected valid C++ code since r257961

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
(In reply to Jason Merrill from comment #5)
> (In reply to Jakub Jelinek from comment #2)
> > Given:
> > class C {
> >   static const long b = 0;
> >   static const unsigned c = (b);
> > };
> > class D {
> >   static const long b = 0;
> >   static const unsigned c = b;
> > };
> > template  class A {
> >   static const long b = 0;
> >   static const unsigned c = (b);
> > };
> > template  class B {
> >   static const long b = 0;
> >   static const unsigned c = b;
> > };
> > 
> > we only reject the A case.
> > For D and B there is just INTEGER_CST, and for C and A we have:
> > (unsigned int) (long int) *(const long int &) 
> > because of the parens.
> > The reason why it is accepted outside of template and not inside of it is
> > that
> > cxx_constant_init calls is_nondependent_static_init_expression which calls
> > instantiation_dependent_expression_p and that is true in A::c.
> 
> Right, because  is value-dependent.  I guess force_paren_expr can't do
> that transformation in a template.

So do you think that we don't want the patch in Comment 3?

[Bug c++/84599] following code gives different output for normal compilation and -O2 compiler.

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Did you try -fsanitize=undefined before reporting?

[Bug c++/84599] New: following code gives different output for normal compilation and -O2 compiler.

[sushvish1 at gmail dot com]

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

Bug ID: 84599
   Summary: following code gives different output for normal
compilation and -O2 compiler.
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sushvish1 at gmail dot com
  Target Milestone: ---

Created attachment 43520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43520=edit
Giving different output for same code base ideally it should give same output
for normal g++ compilation and g++ -O2 compilatio

[Bug c++/84582] [8 Regression] Rejected valid C++ code since r257961

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #2)
> Given:
> class C {
>   static const long b = 0;
>   static const unsigned c = (b);
> };
> class D {
>   static const long b = 0;
>   static const unsigned c = b;
> };
> template  class A {
>   static const long b = 0;
>   static const unsigned c = (b);
> };
> template  class B {
>   static const long b = 0;
>   static const unsigned c = b;
> };
> 
> we only reject the A case.
> For D and B there is just INTEGER_CST, and for C and A we have:
> (unsigned int) (long int) *(const long int &) 
> because of the parens.
> The reason why it is accepted outside of template and not inside of it is
> that
> cxx_constant_init calls is_nondependent_static_init_expression which calls
> instantiation_dependent_expression_p and that is true in A::c.

Right, because  is value-dependent.  I guess force_paren_expr can't do that
transformation in a template.

[Bug c++/84578] [6/7/8 Regression] ICE with flexible array member and constexpr

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code

--- Comment #2 from Martin Sebor  ---
I think the code should be rejected in constexpr contexts, as Clang does. 
Otherwise the size of A::x is zero, which would make it an invalid object.  I'm
changing it to ice-on-invalid-code but please let me know if you know of an
argument for accepting it.

[Bug c++/84598] New: internal compiler error: Segmentation fault (cp_default_conversion())

[vegard.nossum at gmail dot com]

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

Bug ID: 84598
   Summary: internal compiler error: Segmentation fault
(cp_default_conversion())
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

Input (I know... don't ask):

template __attribute__ a([] { class c,
__attribute__(vector_size(operator+( d;

Output:

$ xgcc -x c++ -std=c++14 -O3 -c -
:1:31: error: expected '(' before 'a'
:1:31: error: expected '(' before 'a'
: In lambda function:
:1:45: error: expected unqualified-id before ',' token
:1:61: error: expected '(' before 'vector_size'
:1:73: error: there are no arguments to 'operator+' that depend on a
template parameter, so a declaration of 'operator+' must be available
[-fpermissive]
:1:73: note: (if you use '-fpermissive', G++ will accept your code, but
allowing the use of an undeclared name is deprecated)
:1:88: internal compiler error: Segmentation fault
0x3138779 crash_signal
/home/vegard/git/gcc/gcc/toplev.c:325
0x13c5f60 cp_default_conversion
/home/vegard/git/gcc/gcc/cp/typeck.c:2134
0x1632c0b handle_vector_size_attribute
/home/vegard/git/gcc/gcc/c-family/c-attribs.c:3026
0x1466155 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/home/vegard/git/gcc/gcc/attribs.c:670
0xbf7838 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
/home/vegard/git/gcc/gcc/cp/decl.c:10905
0xc14e88 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
/home/vegard/git/gcc/gcc/cp/decl.c:4952
0xf9 cp_parser_init_declarator
/home/vegard/git/gcc/gcc/cp/parser.c:19534
0xfa2a97 cp_parser_simple_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:13009
0xfa8c88 cp_parser_block_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12827
0xfab154 cp_parser_declaration_statement
/home/vegard/git/gcc/gcc/cp/parser.c:12420
0xef6e13 cp_parser_statement
/home/vegard/git/gcc/gcc/cp/parser.c:10869
0xefb1eb cp_parser_statement_seq_opt
/home/vegard/git/gcc/gcc/cp/parser.c:11218
0xfcca31 cp_parser_lambda_body
/home/vegard/git/gcc/gcc/cp/parser.c:10632
0xfcca31 cp_parser_lambda_expression
/home/vegard/git/gcc/gcc/cp/parser.c:10137
0xf31764 cp_parser_primary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:5257
0xf7373b cp_parser_postfix_expression
/home/vegard/git/gcc/gcc/cp/parser.c:7026
0xf26fa7 cp_parser_unary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:8281
0xebcdba cp_parser_cast_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9049
0xebf3e6 cp_parser_binary_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9150
0xec2eba cp_parser_assignment_expression
/home/vegard/git/gcc/gcc/cp/parser.c:9437
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Version:

xgcc (GCC) 8.0.1 20180204 (experimental)

built from git fdae6180ad24fa6303fa046114f3e4b66b8db34d

Bug doesn't seem present in 7.3.

Test case reduced by C-Reduce, unfortunately I lost the original non-reduced
source.

[Bug testsuite/84597] New: [8 regression] test case g++.dg/ext/timevar2.C fails starting with r258029

[seurer at gcc dot gnu.org]

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

Bug ID: 84597
   Summary: [8 regression] test case g++.dg/ext/timevar2.C fails
starting with r258029
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I think you need to update the timevar2.C test case for the format changes.

Executing on host:
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/ext/timevar2.C 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=gnu++98 -ftime-report  -S   -o timevar2.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/ext/timevar2.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -ftime-report -S -o timevar2.s

Time variable  usr  sys wall   
  GGC
 phase setup:   0.01 (100%)   0.00 ( 0%)   0.00 ( 0%)  
 1971 kB (75%)
 phase opt and generate :   0.00 ( 0%)   0.00 ( 0%)   0.01 (100%)  
   57 kB ( 2%)
 dominance computation  :   0.00 ( 0%)   0.00 ( 0%)   0.01 (100%)  
0 kB ( 0%)
 TOTAL  :   0.01 0.00 0.01 
2633 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.
output is:

Time variable  usr  sys wall   
  GGC
 phase setup:   0.01 (100%)   0.00 ( 0%)   0.00 ( 0%)  
 1971 kB (75%)
 phase opt and generate :   0.00 ( 0%)   0.00 ( 0%)   0.01 (100%)  
   57 kB ( 2%)
 dominance computation  :   0.00 ( 0%)   0.00 ( 0%)   0.01 (100%)  
0 kB ( 0%)
 TOTAL  :   0.01 0.00 0.01 
2633 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.

FAIL: g++.dg/ext/timevar2.C  -std=gnu++98 (test for excess errors)
Excess errors:
 phase setup:   0.01 (100%)   0.00 ( 0%)   0.00 ( 0%)  
 1971 kB (75%)
 phase opt and generate :   0.00 ( 0%)   0.00 ( 0%)   0.01 (100%)  
   57 kB ( 2%)
 dominance computation  :   0.00 ( 0%)   0.00 ( 0%)   0.01 (100%)  
0 kB ( 0%)

Executing on host:
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/ext/timevar2.C 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=gnu++11 -ftime-report  -S   -o timevar2.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/ext/timevar2.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++11 -ftime-report -S -o timevar2.s

Time variable  usr   

[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?

[jakub at gcc dot gnu.org]

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

--- Comment #28 from Jakub Jelinek  ---
Trying:
--- gcc/stor-layout.c.jj2018-02-22 14:35:33.135216198 +0100
+++ gcc/stor-layout.c   2018-02-27 17:32:17.934820133 +0100
@@ -1038,7 +1038,7 @@ update_alignment_for_field (record_layou
 the type, except that for zero-size bitfields this only
 applies if there was an immediately prior, nonzero-size
 bitfield.  (That's the way it is, experimentally.) */
-  if ((!is_bitfield && !DECL_PACKED (field))
+  if (!is_bitfield
  || ((DECL_SIZE (field) == NULL_TREE
   || !integer_zerop (DECL_SIZE (field)))
  ? !DECL_PACKED (field)
@@ -1047,7 +1047,10 @@ update_alignment_for_field (record_layou
 && ! integer_zerop (DECL_SIZE (rli->prev_field)
{
  unsigned int type_align = TYPE_ALIGN (type);
- type_align = MAX (type_align, desired_align);
+ if (!is_bitfield && DECL_PACKED (field))
+   type_align = desired_align;
+ else
+   type_align = MAX (type_align, desired_align);
  if (maximum_field_alignment != 0)
type_align = MIN (type_align, maximum_field_alignment);
  rli->record_align = MAX (rli->record_align, type_align);
@@ -1303,7 +1306,9 @@ place_field (record_layout_info rli, tre

   /* Does this field automatically have alignment it needs by virtue
  of the fields that precede it and the record's own alignment?  */
-  if (known_align < desired_align)
+  if (known_align < desired_align
+  && (! targetm.ms_bitfield_layout_p (rli->t)
+ || rli->prev_field == NULL))
 {
   /* No, we need to skip space before this field.
 Bump the cumulative size to multiple of field alignment.  */
@@ -1331,8 +1336,6 @@ place_field (record_layout_info rli, tre

   if (! TREE_CONSTANT (rli->offset))
rli->offset_align = desired_align;
-  if (targetm.ms_bitfield_layout_p (rli->t))
-   rli->prev_field = NULL;
 }

   /* Handle compatibility with PCC.  Note that if the record has any
@@ -1505,6 +1508,31 @@ place_field (record_layout_info rli, tre
   as if the prior field was not a bitfield.  */
prev_saved = NULL;

+ /* Does this field automatically have alignment it needs by
virtue
+of the fields that precede it and the record's own alignment? 
*/
+ if (known_align < desired_align)
+   {
+ /* If the alignment is still within offset_align, just align
+the bit position.  */
+ if (desired_align < rli->offset_align)
+   rli->bitpos = round_up (rli->bitpos, desired_align);
+ else
+   {
+ /* First adjust OFFSET by the partial bits, then align. 
*/
+ tree d = size_binop (CEIL_DIV_EXPR, rli->bitpos,
+  bitsize_unit_node);
+ rli->offset = size_binop (PLUS_EXPR, rli->offset,
+   fold_convert (sizetype, d));
+ rli->bitpos = bitsize_zero_node;
+
+ rli->offset = round_up (rli->offset,
+ desired_align / BITS_PER_UNIT);
+   }
+
+ if (! TREE_CONSTANT (rli->offset))
+   rli->offset_align = desired_align;
+   }
+
  /* Cause a new bitfield to be captured, either this time (if
 currently a bitfield) or next time we see one.  */
  if (!DECL_BIT_FIELD_TYPE (field)
@@ -1530,7 +1558,7 @@ place_field (record_layout_info rli, tre
   if (!DECL_BIT_FIELD_TYPE (field)
  || (prev_saved != NULL
  ? !simple_cst_equal (TYPE_SIZE (type), TYPE_SIZE (prev_type))
- : !integer_zerop (DECL_SIZE (field)) ))
+ : !integer_zerop (DECL_SIZE (field
{
  /* Never smaller than a byte for compatibility.  */
  unsigned int type_align = BITS_PER_UNIT;
@@ -1555,7 +1583,8 @@ place_field (record_layout_info rli, tre
}

  /* Now align (conventionally) for the new type.  */
- type_align = TYPE_ALIGN (TREE_TYPE (field));
+ if (! DECL_PACKED (field))
+   type_align = TYPE_ALIGN (TREE_TYPE (field));

  if (maximum_field_alignment != 0)
type_align = MIN (type_align, maximum_field_alignment);

fixes this testcase, but breaks bf-ms-layout.c and bf-ms-layout-2.c.
The tests were adjusted in r186880 and r184519, but perhaps those were just
bogus changes.  I guess what matters more is whether the layout in those tests
and in the above tests match what VC does.

[Bug c++/84588] internal compiler error: Segmentation fault (contains_struct_check())

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Both testcases used to ICE with -std=c++11, but that was fixed sometime between
r218865 (ICE) and r218948 (no ICE).

Both testcases ICE on trunk with -std=c++14, in both cases starting with
r208426.

[Bug tree-optimization/84595] __builtin_trap() causes optimizer to remove code

[danielgutson at gmail dot com]

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

--- Comment #5 from Daniel Gutson  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Daniel Gutson from comment #3)
> > OK. That was my second suggested alternative.
> > BTW I didn't see __builtin_trap documented as noreturn in the documentation.
> 
> Depends on the reading of __builtin_trap documentation.
> My reading says it does not return.
> 
> "This function causes the program to exit abnormally.  GCC implements this
> function by using a target-dependent mechanism (such as intentionally
> executing an illegal instruction) or by calling abort."
> 
> Since the documentation talks about calling abort, I would assume
> __built_trap should be treated almost the same as calling abort.

OK. I'll leave this issue as a feature request for __builtin_break(). Maybe the
component should be changed to something more appropriate?

[Bug tree-optimization/84485] [6/7 Regression] Vectorising zero-stride rmw operation

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug tree-optimization/84595] __builtin_trap() causes optimizer to remove code

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Daniel Gutson from comment #3)
> OK. That was my second suggested alternative.
> BTW I didn't see __builtin_trap documented as noreturn in the documentation.

Depends on the reading of __builtin_trap documentation.
My reading says it does not return.

"This function causes the program to exit abnormally.  GCC implements this
function by using a target-dependent mechanism (such as intentionally executing
an illegal instruction) or by calling abort."

Since the documentation talks about calling abort, I would assume __built_trap
should be treated almost the same as calling abort.

[Bug c++/84588] internal compiler error: Segmentation fault (contains_struct_check())

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-27
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
(In reply to Vegard Nossum from comment #0)
> Please let me know if it is useful to continue submitting new bugs or if I
> should post new findings under the same bug number even though the
> crash/input looks different.

Thanks for filing this (and the other bugs!).

Please open separate bug reports when the crash/input look different: if they
are duplicates we can mark them as such, but if they aren't, having them under
the same bug number makes it harder to talk about them.

Confirmed.

The "-O3" isn't necessary to trigger the crash.

The first testcase crashes here:

#1  0x009e7ec5 in cp_parser_ctor_initializer_opt_and_function_body
(parser=0x77ffbbd0, in_function_try_block=false)
at ../../src/gcc/cp/parser.c:21770
21770DECL_CONSTRUCTOR_P (current_function_decl)

due to "current_function_decl" being NULL.

The crash in cp_parser_ctor_initializer_opt_and_function_body started in
r251433 (with -std=c++14), but I'm able to reproduce a crash with the first
testcase within start_lambda_scope with -std=c++11, which started with r204714.


The second testcase is a different crash; it's a failure of this assertion:

970   gcc_checking_assert (length () > 0);

(gdb) bt
#0  fancy_abort (file=0x20fcd7c "../../src/gcc/vec.h", line=970, 
function=0x20fd5f7 ::pop()::__FUNCTION__>
"pop") at ../../src/gcc/diagnostic.c:1500
#1  0x0082f972 in vec::pop
(this=0x71a09028) at ../../src/gcc/vec.h:970
#2  0x00bd5b1c in pop_stmt_list (t=) at
../../src/gcc/c-family/c-semantics.c:60
#3  0x00ac2e6c in finish_cond (cond_p=0x718b90c0,
expr=)
at ../../src/gcc/cp/semantics.c:561
#4  0x00ac3753 in finish_if_stmt_cond (cond=, if_stmt=)
at ../../src/gcc/cp/semantics.c:740
#5  0x009d2bba in cp_parser_selection_statement (parser=0x77ffbbd0,
if_p=0x0, chain=0x0)
at ../../src/gcc/cp/parser.c:11379

This one started with r208426.

[Bug tree-optimization/84595] __builtin_trap() causes optimizer to remove code

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
https://github.com/scottt/debugbreak

[Bug tree-optimization/84595] __builtin_trap() causes optimizer to remove code

[danielgutson at gmail dot com]

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

--- Comment #3 from Daniel Gutson  ---
(In reply to Andrew Pinski from comment #1)
> What you want is __builtin_breakpoint (if that existed).  Trap is considered
> as noreturn just like abort/exit.

OK. That was my second suggested alternative.
BTW I didn't see __builtin_trap documented as noreturn in the documentation.

[Bug tree-optimization/84595] __builtin_trap() causes optimizer to remove code

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
What you want is __builtin_breakpoint (if that existed).  Trap is considered as
noreturn just like abort/exit.

[Bug target/84528] [8 Regression] gcc.c-torture/execute/960419-2.c -O3 fails with -fno-omit-frame-pointer

[rsandifo at gcc dot gnu.org]

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
(In reply to rsand...@gcc.gnu.org from comment #5)
> Created attachment 43519 [details]
> Alternative fix
> 
> Here's an alternative fix that I'll run through multi-target testing.
> It's more conservative than the cselib.c patch linked above.

Oops, that's the wrong place to check -- will do it in init_alias_analysis
instead.

[Bug target/84528] [8 Regression] gcc.c-torture/execute/960419-2.c -O3 fails with -fno-omit-frame-pointer

[rsandifo at gcc dot gnu.org]

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Created attachment 43519
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43519=edit
Alternative fix

Here's an alternative fix that I'll run through multi-target testing.
It's more conservative than the cselib.c patch linked above.

[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #27 from Jakub Jelinek  ---
The #c26 tests in a single testcase:

#ifdef _WIN32
# ifdef _MSC_VER
#  define PACK(typeDec) __pragma( pack(push, 1) ) typeDec __pragma( pack(pop) )
# else
#  define PACK(typeDec) typeDec __attribute__((__packed__,ms_struct))
# endif
#else
# define PACK(typeDec) typeDec __attribute__((__packed__))
#endif

#ifdef _MSC_VER
# define ALIGN(typeDec, n) __declspec(align(n)) typeDec
#else
# define ALIGN(typeDec, n) typeDec __attribute__((aligned(n)))
#endif

#define assert_cc(expr) extern char c[(expr) ? 1 : -1]
#define offsetof(x, y) __builtin_offsetof (x, y)

PACK(struct test_sp1 {
int a;
short b;
int c;
char d;
});

assert_cc(sizeof(struct test_sp1) == 11);
assert_cc(offsetof(struct test_sp1, a) == 0);
assert_cc(offsetof(struct test_sp1, b) == 4);
assert_cc(offsetof(struct test_sp1, c) == 6);
assert_cc(offsetof(struct test_sp1, d) == 10);

PACK(struct test_sp3 {
int a;
ALIGN(short b, 8);
int c;
char d;
});

assert_cc(sizeof(struct test_sp3) == 16);
assert_cc(offsetof(struct test_sp3, a) == 0);
assert_cc(offsetof(struct test_sp3, b) == 8);
assert_cc(offsetof(struct test_sp3, c) == 10);
assert_cc(offsetof(struct test_sp3, d) == 14);

struct test_s4 {
int a;
short b;
int c:15;
char d;
};

#ifdef _WIN32
assert_cc(sizeof(struct test_s4) == 16);
assert_cc(offsetof(struct test_s4, a) == 0);
assert_cc(offsetof(struct test_s4, b) == 4);
assert_cc(offsetof(struct test_s4, d) == 12);
#else
assert_cc(sizeof(struct test_s4) == 12);
assert_cc(offsetof(struct test_s4, a) == 0);
assert_cc(offsetof(struct test_s4, b) == 4);
assert_cc(offsetof(struct test_s4, d) == 8);
#endif

but rather with r114364 which revamped the ms bitfield layout completely.
See https://gcc.gnu.org/ml/gcc-patches/2006-04/msg01064.html for more info.
The above testcase indeed passes with -D_WIN32 -mms-bitfields when built with
GCC 4.1 or earlier.

Ignoring the type_align bump in place_field for DECL_PACKED fields sounds
reasonable, just the formatting is wrong (needs a space in between DECL_PACKED
and (field)).

In the second hunk, the formatting is also wrong (e.g. a single statement body
of else shouldn't be wrapped with {}s around it), but more importantly it is
unclear why that would be the right thing, e.g. why is ignoring
maximum_field_alignment the right thing etc.

So, for the first two hunks in #c26 I'd go with:
--- gcc/stor-layout.c.jj2018-02-22 14:35:33.135216198 +0100
+++ gcc/stor-layout.c   2018-02-27 15:14:03.271387867 +0100
@@ -1038,7 +1038,7 @@ update_alignment_for_field (record_layou
 the type, except that for zero-size bitfields this only
 applies if there was an immediately prior, nonzero-size
 bitfield.  (That's the way it is, experimentally.) */
-  if ((!is_bitfield && !DECL_PACKED (field))
+  if (!is_bitfield
  || ((DECL_SIZE (field) == NULL_TREE
   || !integer_zerop (DECL_SIZE (field)))
  ? !DECL_PACKED (field)
@@ -1047,7 +1047,10 @@ update_alignment_for_field (record_layou
 && ! integer_zerop (DECL_SIZE (rli->prev_field)
{
  unsigned int type_align = TYPE_ALIGN (type);
- type_align = MAX (type_align, desired_align);
+ if (!is_bitfield && DECL_PACKED (field))
+   type_align = desired_align;
+ else
+   type_align = MAX (type_align, desired_align);
  if (maximum_field_alignment != 0)
type_align = MIN (type_align, maximum_field_alignment);
  rli->record_align = MAX (rli->record_align, type_align);
@@ -1555,7 +1558,8 @@ place_field (record_layout_info rli, tre
}

  /* Now align (conventionally) for the new type.  */
- type_align = TYPE_ALIGN (TREE_TYPE (field));
+ if (! DECL_PACKED (field))
+   type_align = TYPE_ALIGN (TREE_TYPE (field));

  if (maximum_field_alignment != 0)
type_align = MIN (type_align, maximum_field_alignment);

instead.

The #c26 third hunk is I presume instead something that was probably broken
only in GCC 4.6 with r184409 aka PR52238 fix.  That 
if (targetm.ms_bitfield_layout_p (rli->t))
  rli->prev_field = NULL;
in that patch looks wrong to me, you lose all the special handling of
rli->prev_field that way.

Before trying to deal with that, I think it is important to figure out what VC
does for the case when a bitfield is followed by another bitfield with the same
underlying type size, but higher alignment.

E.g. how is:
struct S {
  int a : 2;
  __declspec(align(8)) int b : 2;
  int c : 28;
  __declspec(align(16)) int d : 2;
  int e : 30;
} s;
int a = sizeof (struct S);
void f1 (int x) { s.a = x; }
void f2 (int 

[Bug c/84563] GCC interpretation of C11 atomics (DR 459)

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from torvald at gcc dot gnu.org ---
Closing after further discussion.

[Bug target/84534] [8 regression] several powerpc test cases fail starting with r257915

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #1 from Peter Bergner  ---
I'll have a look at the ICE.

I do question ever counting the number of xxlor's in our code, since the
backend will generate them for doing register copies, which can fluctuate given
changes in the RTL, phases of the moon, etc.

[Bug tree-optimization/84470] test for address of member being null not eliminated

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
When p is null p->a is not valid if it's evaluated.  offsetof (along with
sizeof and alignof and the like) don't evaluate their operands so they are
exempt.

[Bug target/84528] [8 Regression] gcc.c-torture/execute/960419-2.c -O3 fails with -fno-omit-frame-pointer

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug c++/84496] [6 Regression] Internal compiler error with lambda, static and auto since r236615

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Depends on||81045
Summary|[6/7 Regression] Internal   |[6 Regression] Internal
   |compiler error with lambda, |compiler error with lambda,
   |static and auto since   |static and auto since
   |r236615 |r236615

--- Comment #4 from Jason Merrill  ---
Fixed for 7.4 as well.  The fix depends on earlier patches that aren't on the 6
branch, so I'm inclined to leave it unfixed there.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81045
[Bug 81045] [7/8 Regression] return type deduction causes dependent types?

[Bug c++/84596] [8 Regression] internal compiler error: unexpected expression '(bool)c' of kind implicit_conv_expr (cxx_eval_constant_expression)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #2 from Marek Polacek  ---
I'm looking into the same kind of ICE
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582#c4) but this one is
invalid.

[Bug c++/84596] [8 Regression] internal compiler error: unexpected expression '(bool)c' of kind implicit_conv_expr (cxx_eval_constant_expression)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-27
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|internal compiler error:|[8 Regression] internal
   |unexpected expression   |compiler error: unexpected
   |'(bool)c' of kind   |expression '(bool)c' of
   |implicit_conv_expr  |kind implicit_conv_expr
   |(cxx_eval_constant_expressi |(cxx_eval_constant_expressi
   |on) |on)
 Ever confirmed|0   |1

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

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org]

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

Bug 84512 Summary: [8 Regression] Missed optimization: should be precalculated 
in compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84512

   What|Removed |Added

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

[Bug tree-optimization/84512] [8 Regression] Missed optimization: should be precalculated in compile-time

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/84482] 437.leslie3d regresses on Haswell and SandyBridge at -O3 and -Ofast with generic march and tuning

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
So we vectorize less.  Given the caused revision I wonder if this is the same
issue as in PR84512 where I just committed a fix for?  So ... fixed?

[Bug fortran/51434] ICE with scalar init of an array parameter, used in DT default init with transfer

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #19 from Steve Kargl  ---
On Tue, Feb 27, 2018 at 01:54:11PM +, dominiq at lps dot ens.fr wrote:
> 
> In addition, I don't understand why
> 
>   type t
> character :: z
>   end type t
>   type(t), parameter :: s(5) = t('a')
>   type b
>   character :: y(5) = transfer('abcde', s(1)%z)
>   end type
>   type(b) :: zz
>   print *, zz
>   print *, s(1)%z
>   end
> 
> prints
> 
>  a
>  a
> 
> Should not it be
> 
>  abcde
>  a
> 

No.

Case (i): If MOLD is a scalar and SIZE is absent, the result is a scalar.

print *. s(1)%z, rank(s(1)%z) gives

 a   0