[Bug c++/82107] [5/6/7/8 Regression] O2 optimisation on amd64 leads to error

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug c++/82115] [8 Regression] ICE on (valid) C++11 code: Segmentation fault signal terminated program cc1plus

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Version|unknown |8.0
   Target Milestone|--- |8.0
Summary|ICE on (valid) C++11 code:  |[8 Regression] ICE on
   |Segmentation fault signal   |(valid) C++11 code:
   |terminated program cc1plus  |Segmentation fault signal
   ||terminated program cc1plus

[Bug target/82108] [7/8 Regression] Wrong vectorized code generated for x86_64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Bah.  Mine.

[Bug ipa/82107] [5/6/7/8 Regression] O2 optimisation on amd64 leads to error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Component|c++ |ipa

[Bug target/82106] [RISCV] Misaligned loads generated when doubles are split between stack and registers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||riscv
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-06
 Ever confirmed|0   |1

[Bug c++/82115] [8 Regression] ICE on (valid) C++11 code: Segmentation fault signal terminated program cc1plus

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Confirmed, but for some reason hard to bisect. Stack overflow happens here:

#15 0x007922d8 in value_dependent_expression_p (expression=) at ../../gcc/cp/pt.c:24095
#16 0x00792192 in value_dependent_expression_p (expression=) at ../../gcc/cp/pt.c:23937
#17 0x00791ce7 in value_dependent_expression_p (expression=) at ../../gcc/cp/pt.c:24011
#18 0x00791ce7 in value_dependent_expression_p (expression=) at ../../gcc/cp/pt.c:24011
#19 0x00792396 in value_dependent_expression_p (expression=) at ../../gcc/cp/pt.c:24046
#20 0x007922d8 in value_dependent_expression_p (expression=) at ../../gcc/cp/pt.c:24095
#21 0x00792192 in value_dependent_expression_p (expression=) at ../../gcc/cp/pt.c:23937
#22 0x00791ce7 in value_dependent_expression_p (expression=) at ../../gcc/cp/pt.c:24011
#23 0x00791ce7 in value_dependent_expression_p (expression=) at ../../gcc/cp/pt.c:24011
#24 0x00792396 in value_dependent_expression_p (expression=) at ../../gcc/cp/pt.c:24046
#25 0x007922d8 in value_dependent_expression_p (expression=) at ../../gcc/cp/pt.c:24095
#26 0x00792192 in value_dependent_expression_p (expression=) at ../../gcc/cp/pt.c:23937
#27 0x007949c9 in instantiation_dependent_expression_p
(expression=) at ../../gcc/cp/pt.c:24519
#28 0x00650ca7 in is_nondependent_constant_expression
(t=0x7697e7e0) at ../../gcc/cp/constexpr.c:5907
#29 0x00651113 in fold_non_dependent_expr (t=t@entry=0x7697e7e0) at
../../gcc/cp/constexpr.c:4933
#30 0x0078b712 in build_non_dependent_expr
(expr=expr@entry=0x7697e7e0) at ../../gcc/cp/pt.c:24955
#31 0x007fe848 in finish_expr_stmt (expr=expr@entry=0x7697e7e0) at
../../gcc/cp/semantics.c:693
#32 0x0074a5f5 in cp_parser_expression_statement
(parser=parser@entry=0x77feccf0,
in_statement_expr=in_statement_expr@entry=0x0) at ../../gcc/cp/parser.c:11127
#33 0x00751bd4 in cp_parser_statement
(parser=parser@entry=0x77feccf0,
in_statement_expr=in_statement_expr@entry=0x0, in_compound=,
in_compound@entry=true, if_p=if_p@entry=0x0, chain=chain@entry=0x0,
loc_after_labels=loc_after_labels@entry=0x0)
at ../../gcc/cp/parser.c:10887
#34 0x00752de1 in cp_parser_statement_seq_opt
(parser=parser@entry=0x77feccf0,
in_statement_expr=in_statement_expr@entry=0x0) at ../../gcc/cp/parser.c:11214
#35 0x00752eb8 in cp_parser_compound_statement
(parser=parser@entry=0x77feccf0,
in_statement_expr=in_statement_expr@entry=0x0, bcs_flags=bcs_flags@entry=0,
function_body=function_body@entry=true) at ../../gcc/cp/parser.c:11168
#36 0x0076c719 in cp_parser_function_body (in_function_try_block=false,
parser=0x77feccf0) at ../../gcc/cp/parser.c:21622
#37 cp_parser_ctor_initializer_opt_and_function_body
(parser=parser@entry=0x77feccf0,
in_function_try_block=in_function_try_block@entry=false) at
../../gcc/cp/parser.c:21660
#38 0x0076e07b in cp_parser_function_definition_after_declarator
(parser=parser@entry=0x77feccf0, inline_p=inline_p@entry=false) at
../../gcc/cp/parser.c:26496
#39 0x0076ed5e in
cp_parser_function_definition_from_specifiers_and_declarator
(declarator=, attributes=0x0, decl_specifiers=0x7fffd610,
parser=0x77feccf0) at ../../gcc/cp/parser.c:26410
#40 cp_parser_init_declarator (parser=parser@entry=0x77feccf0,
decl_specifiers=decl_specifiers@entry=0x7fffd610, checks=checks@entry=0x0,
function_definition_allowed_p=function_definition_allowed_p@entry=true,
member_p=member_p@entry=false, 
declares_class_or_enum=,
function_definition_p=0x7fffd60b, maybe_range_for_decl=0x0, init_loc=0x0,
auto_result=0x0) at ../../gcc/cp/parser.c:19374
#41 0x007749fb in cp_parser_single_declaration
(parser=parser@entry=0x77feccf0, checks=checks@entry=0x0,
member_p=member_p@entry=false,
explicit_specialization_p=explicit_specialization_p@entry=false,
friend_p=friend_p@entry=0x7fffd6ef)
at ../../gcc/cp/parser.c:26953
#42 0x00774bed in cp_parser_template_declaration_after_parameters
(parser=parser@entry=0x77feccf0,
parameter_list=parameter_list@entry=0x769882e0,
member_p=member_p@entry=false) at ../../gcc/cp/parser.c:26556
#43 0x00775577 in cp_parser_explicit_template_declaration
(member_p=false, parser=0x77feccf0) at ../../gcc/cp/parser.c:26792
#44 cp_parser_template_declaration_after_export
(parser=parser@entry=0x77feccf0, member_p=) at
../../gcc/cp/parser.c:26811
#45 0x00775899 in cp_parser_template_declaration
(parser=parser@entry=0x77feccf0, member_p=member_p@entry=false) at
../../gcc/cp/parser.c:14899
#46 0x0077b8ba in cp_parser_declaration
(parser=parser@entry=0x77feccf0) at ../../gcc/cp/parser.c:12652
#47 0x0077bbec in cp_parser_declaration_seq_opt
(parser=parser@entry=0x77feccf0) at ../../gcc/cp/parser.c:12

[Bug target/77308] surprisingly large stack usage for sha512 on arm

[edlinger at gcc dot gnu.org]

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

--- Comment #65 from Bernd Edlinger  ---
Author: edlinger
Date: Wed Sep  6 07:47:52 2017
New Revision: 251752

URL: https://gcc.gnu.org/viewcvs?rev=251752&root=gcc&view=rev
Log:
2017-09-06  Bernd Edlinger  

PR target/77308
* config/arm/predicates.md (arm_general_adddi_operand): Create new
non-vfp predicate.
* config/arm/arm.md (*arm_adddi3, *arm_subdi3): Use new predicates.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md
trunk/gcc/config/arm/predicates.md

[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed|2016-11-25 00:00:00 |2017-9-6
 CC||wilco at gcc dot gnu.org
Version|7.0 |8.0
 Resolution|FIXED   |---
   Target Milestone|7.0 |8.0
Summary|[7 regression]  |[8 regression]
   |libgomp.c/reduction-10.c|libgomp.c/reduction-10.c
   |and many more FAIL  |and many more FAIL

--- Comment #37 from Rainer Orth  ---
This patch

2017-09-05  Wilco Dijkstra  

* explow.c (get_dynamic_stack_size): Improve dynamic alignment.

brought the exact same set of failures back on sparc-sun-solaris2.11.

  Rainer

[Bug fortran/82064] [7/8 Regression] [OOP] multiple incompatible definitions of extended derived type via module use

[paul.richard.thomas at gmail dot com]

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

--- Comment #6 from paul.richard.thomas at gmail dot com  ---
Aaaah! I missed the point wrt separate files.

As far as I remember, we make sure that class or derived entities get
their vtable but not unreferenced type declarations.

Cheers

Paul

On 5 September 2017 at 14:25, janus at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82064
>
> --- Comment #5 from janus at gcc dot gnu.org ---
> (In reply to Paul Thomas from comment #4)
>> (In reply to janus from comment #3)
>> > It appears that the regression has been introduced by r241450, which was 
>> > the
>> > fix for PR 69834. Reverting it, in particular the changes to
>> > resolve_select_type, makes the error go away.
>>
>> Strangely, my GNU Fortran (GCC) 8.0.0 20170830 gives me two "OK"s :-)
>
> Also on the version with separate files?
>
>
>> That said, this is a repeat of another recent bug (sorry, I am rushing off
>> to work - no time to find the number). I posted a work around, which
>> translates in this case to:
>>
>> [..]
>>
>> The permanent fix is to make sure that the vtables get produced
>> unconditionally for module derived types.
>
> I thought we already did that, but probably we're still missing some cases?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c++/78269] FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #5 from Paolo Carlini  ---
Thomas, both trunk and gcc-7-brnanch seem fine to me, I'm tempted to close the
bug. Can you double check the released 7.1.0 on aarch64?

[Bug rtl-optimization/80463] [5/6/7/8 Regression] ICE with -fselective-scheduling2 and -fvar-tracking-assignments

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

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

--- Comment #3 from Andrey Belevantsev  ---
I've debugged this one a bit on a revision with an ICE.  We fail to move up a
bookkeeping copy of a debug insn because of a piece of code in sched-deps.c:

3094   /* Quite often, a debug insn will refer to stuff in the
3095  previous instruction, but the reason we want this
3096  dependency here is to make sure the scheduler doesn't
3097  gratuitously move a debug insn ahead.  This could dirty
3098  DF flags and cause additional analysis that wouldn't have
3099  occurred in compilation without debug insns, and such
3100  additional analysis can modify the generated code.  */
3101   prev = PREV_INSN (insn);
3102
3103   if (prev && NONDEBUG_INSN_P (prev)
3104 add_dependence (insn, prev, REG_DEP_ANTI);

The initial insn didn't have this dependence because it was the first in block.
We could either switch off this conditional completely for selective scheduling
or pass there the insn through which we try to move our debug insn to be used
as prev instead of completely bogus prev insn.  The former is much simple
because var-tracking doesn't play well with sel-sched anyways.

However, while experimenting with these I have found an issue with the
scheduler creating bookkeeping blocks such that the hot/cold partitioning
breaks. This one should be fixed first hopefully after some discussions with
Honza at the cauldron.

[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

[wdijkstr at arm dot com]

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

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #38 from Wilco  ---
(In reply to Rainer Orth from comment #37)
> This patch
> 
> 2017-09-05  Wilco Dijkstra  
> 
>   * explow.c (get_dynamic_stack_size): Improve dynamic alignment.
> 
> brought the exact same set of failures back on sparc-sun-solaris2.11.
> 
>   Rainer

The existing alloca code relies on STACK_BOUNDARY being set correctly. Has the
value been fixed already for the OS variants mentioned? If stack alignment
can't be guaranteed by OS/runtime/prolog, STACK_BOUNDARY should be 8.

[Bug middle-end/82095] [8 Regression] ICE in tree_nop_conversion at tree.c:11793 on ppc64le

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Sep  6 09:10:26 2017
New Revision: 251754

URL: https://gcc.gnu.org/viewcvs?rev=251754&root=gcc&view=rev
Log:
PR middle-end/82095
* varasm.c (categorize_decl_for_section): Use SECCAT_TBSS for TLS vars
with
NULL DECL_INITIAL.

* gcc.dg/tls/pr82095.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tls/pr82095.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

[ebotcazou at gcc dot gnu.org]

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

--- Comment #39 from Eric Botcazou  ---
> The existing alloca code relies on STACK_BOUNDARY being set correctly. Has
> the value been fixed already for the OS variants mentioned? If stack
> alignment can't be guaranteed by OS/runtime/prolog, STACK_BOUNDARY should be
> 8.

No, no, no, please read the ??? note I put in emit-rtl.c.  STACK_BOUNDARY is
correct, the problem is the declared alignment of the virtual registers.

[Bug sanitizer/82116] New: "nested bug in the same thread" when a bug is found while reporting another one

[mephi42 at gmail dot com]

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

Bug ID: 82116
   Summary: "nested bug in the same thread" when a bug is found
while reporting another one
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mephi42 at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 42135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42135&action=edit
minimal reproducible example

The attached program fails with

AddressSanitizer: nested bug in the same thread, aborting.

without diagnosing the stack-buffer-overflow.



In rare cases it exits correctly with the expected

AddressSanitizer: while reporting a bug found another one. Ignoring.
ERROR: AddressSanitizer: stack-buffer-overflow on address ...

[Bug tree-optimization/82078] [8 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
Thanks for a nice small testcase. I have proposed a fix on the mailing list:

https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00321.html

[Bug tree-optimization/82078] [8 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  ---
Author: jamborm
Date: Wed Sep  6 09:25:00 2017
New Revision: 251756

URL: https://gcc.gnu.org/viewcvs?rev=251756&root=gcc&view=rev
Log:
Enqueue all SRA links for write flag propagation

2017-09-06  Martin Jambor  

PR tree-optimization/82078
gcc/
* tree-sra.c (sort_and_splice_var_accesses): Move call to
add_access_to_work_queue...
(build_accesses_from_assign): ...here.
(propagate_all_subaccesses): Make sure racc is the group
representative, if there is one.

gcc/testsuite/
* gcc.dg/tree-ssa/pr82078.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr82078.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug sanitizer/82116] "nested bug in the same thread" when a bug is found while reporting another one

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
That looks like upstream libsanitizer bug or limitation.

[Bug middle-end/82117] New: [8 Regression] SPEC CPU2017 502/602 compfail (ICE)

[andrey.y.guskov at intel dot com]

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

Bug ID: 82117
   Summary: [8 Regression] SPEC CPU2017 502/602 compfail (ICE)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.y.guskov at intel dot com
  Target Milestone: ---

Since r251650, the following happens @ CPU2017 502 and 602:


during GIMPLE pass: pre
sel-sched.c: In function 'fill_vec_av_set':
sel-sched.c:3689:1: internal compiler error: Segmentation fault
 fill_vec_av_set (av_set_t av, blist_t bnds, fence_t fence,
 ^
0xc97776 crash_signal
<-->../../../gcc/gcc/toplev.c:341
0xdd527d fini_eliminate
<-->../../../gcc/gcc/tree-ssa-pre.c:4863
0xddd8a7 execute
<-->../../../gcc/gcc/tree-ssa-pre.c:5201
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.


Option set:
-m64 -march=core-avx2 -mfpmath=sse -Ofast -fno-associative-math -funroll-loops
-flto -z muldefs -std=gnu89 -fopenmp

[Bug tree-optimization/82102] [8 Regression] ICE: Segmentation fault in /home/arnd/git/gcc/gcc/tree-ssa-pre.c:4863

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||andrey.y.guskov at intel dot 
com

--- Comment #6 from Richard Biener  ---
*** Bug 82117 has been marked as a duplicate of this bug. ***

[Bug middle-end/82117] [8 Regression] SPEC CPU2017 502/602 compfail (ICE)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
   Target Milestone|--- |8.0

--- Comment #1 from Richard Biener  ---
Dup.

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

[Bug middle-end/82117] [8 Regression] SPEC CPU2017 502/602 compfail (ICE)

[andrey.y.guskov at intel dot com]

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

--- Comment #2 from Andrey Guskov  ---
Weird. I did a Bugzilla search for "r251650", but it told me that nothing was
found.

[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

[wdijkstr at arm dot com]

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

--- Comment #40 from Wilco  ---
(In reply to Eric Botcazou from comment #39)
> > The existing alloca code relies on STACK_BOUNDARY being set correctly. Has
> > the value been fixed already for the OS variants mentioned? If stack
> > alignment can't be guaranteed by OS/runtime/prolog, STACK_BOUNDARY should be
> > 8.
> 
> No, no, no, please read the ??? note I put in emit-rtl.c.  STACK_BOUNDARY is
> correct, the problem is the declared alignment of the virtual registers.

If you cannot guarantee the alignment of the pointers to STACK_BOUNDARY then
STACK_BOUNDARY is incorrect. GCC uses the STACK_BOUNDARY guarantee in
optimizations so it is essential to get this right if you want correct code
generation.

[Bug middle-end/82117] [8 Regression] SPEC CPU2017 502/602 compfail (ICE)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to Andrey Guskov from comment #2)
> Weird. I did a Bugzilla search for "r251650", but it told me that nothing
> was found.

Already fixed and closed bugs are not searched by default.

[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

[ebotcazou at gcc dot gnu.org]

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

--- Comment #41 from Eric Botcazou  ---
> If you cannot guarantee the alignment of the pointers to STACK_BOUNDARY then
> STACK_BOUNDARY is incorrect.

No, it is correct as per the definition:

 -- Macro: STACK_BOUNDARY
 Define this macro to the minimum alignment enforced by hardware
 for the stack pointer on this machine.  The definition is a C
 expression for the desired alignment (measured in bits).  This
 value is used as a default if `PREFERRED_STACK_BOUNDARY' is not
 defined.  On most machines, this should be the same as
 `PARM_BOUNDARY'.

> GCC uses the STACK_BOUNDARY guarantee in optimizations so it is essential to 
> get this right if you want correct code  generation.

No, you're interpolating, please read the entire discussion.  Your change is
based on a premise that is wrong at least on 32-bit SPARC.

[Bug c++/82115] [8 Regression] ICE on (valid) C++11 code: Segmentation fault signal terminated program cc1plus

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Why do you think it is a recent regression?
I certainly see ICE with the same issue (endless recursion in
value_dependent_expression_p) all the way back to r180013 (r18 fails to
compile it, so it must be one of r180001, r180002 or r180003 where it started
to be accepted and ICE).

[Bug c++/82115] [8 Regression] ICE on (valid) C++11 code: Segmentation fault signal terminated program cc1plus

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
It doesn't ICE with -fno-checking though.

[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

[wilco at gcc dot gnu.org]

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

--- Comment #42 from Wilco  ---
(In reply to Eric Botcazou from comment #41)
> > If you cannot guarantee the alignment of the pointers to STACK_BOUNDARY then
> > STACK_BOUNDARY is incorrect.
> 
> No, it is correct as per the definition:
> 
>  -- Macro: STACK_BOUNDARY
>  Define this macro to the minimum alignment enforced by hardware
>  for the stack pointer on this machine.  The definition is a C
>  expression for the desired alignment (measured in bits).  This
>  value is used as a default if `PREFERRED_STACK_BOUNDARY' is not
>  defined.  On most machines, this should be the same as
>  `PARM_BOUNDARY'.

Indeed, so that means alloca code can safely rely on SP being aligned to
STACK_BOUNDARY.

> > GCC uses the STACK_BOUNDARY guarantee in optimizations so it is essential 
> > to 
> > get this right if you want correct code  generation.
> 
> No, you're interpolating, please read the entire discussion.  Your change is
> based on a premise that is wrong at least on 32-bit SPARC.

Yes I did, and it is quite clear - if SPARC doesn't guarantee alignment of the
pointers, it setting of STACK_BOUNDARY is simply incorrect. Alloca will access
data below SP if SP is not aligned to STACK_BOUNDARY even before my patch. No
amount of extra padding to try hiding the bug will fix that.

[Bug c/82118] New: Instruction `lsrsne` unknown

[pmenzel+gcc at molgen dot mpg.de]

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

Bug ID: 82118
   Summary: Instruction `lsrsne` unknown
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pmenzel+gcc at molgen dot mpg.de
  Target Milestone: ---

>From the discussion of a change-set for coreboot [1], it turns out that GCC
does not understand valid instructions.

```
$ arm-linux-gnueabi-gcc-7 --version
arm-linux-gnueabi-gcc-7 (Debian 7.2.0-1) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat mov1.S
lsrsne r0, r0, #4
$ arm-linux-gnueabi-gcc-7 mov1.S -c -o mov1.gas
mov1.S: Assembler messages:
mov1.S:1: Error: bad instruction `lsrsne r0,r0,#4'
$ cat mov1.S
lsrsne r0, r0, #4
$ arm-linux-gnueabi-gcc-7 mov2.S -c -o mov2.gas
```

Julius Werner comments as below.

> FWIW, the ARMv7 A.R.M. says the S comes before the condition code, so this
> should've been MOVSNE instead of MOVNES anyway. It also doesn't explicitly
> allow a source operand shift for MOV, so LSRSNE should be the correct form. I
> bet GCC just has a few additional non-standard aliases, but I would be
> surprised if it can't recognize the official and most obvious notation
> (LSRSNE).

But there is an error in GCC.

[1] https://review.coreboot.org/21358/

[Bug hsa/82119] New: Revision 251264 caused a number of run-time HSA failures

[jamborm at gcc dot gnu.org]

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

Bug ID: 82119
   Summary: Revision 251264 caused a number of run-time HSA
failures
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: hsa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

I have tracked a number of new run-time HSA failures to r251264:

= libgomp.sum =
Tests that previously PASSED but now FAILED:

 libgomp.c/examples-4/declare_target-1.c execution test
 libgomp.c/pr66199-7.c execution test
 libgomp.c/pr66199-8.c execution test
 libgomp.c/pr66199-9.c execution test
 libgomp.c++/pr66199-7.C execution test
 libgomp.c++/pr66199-8.C execution test
 libgomp.c++/pr66199-9.C execution test
 libgomp.c++/target-9.C execution test
 libgomp.hsa.c/switch-1.c execution test
 libgomp.hsa.c/switch-branch-1.c execution test

[Bug hsa/82119] Revision 251264 caused a number of run-time HSA failures

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Jambor  ---
I will have a look at what is going on.

[Bug c/82118] Instruction `lsrsne` unknown

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #1 from Christophe Lyon  ---
The error message comes from gas (binutils package), not gcc.
You should file your bug report there:
https://sourceware.org/bugzilla/
then select the 'binutils' component.

[Bug c/82118] Instruction `lsrsne` unknown

[pmenzel+gcc at molgen dot mpg.de]

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

Paul Menzel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #2 from Paul Menzel  ---
Sorry for the noise, and thank you for the help. This is bug 22094 at the
binutils bug tracker [1].

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=22094

[Bug target/82108] [7/8 Regression] Wrong vectorized code generated for x86_64

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Wed Sep  6 12:31:52 2017
New Revision: 251790

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

PR tree-optimization/82108
* tree-vect-stmts.c (vectorizable_load): Fix pointer adjustment
for gap in the non-permutation SLP case.

* gcc.dg/vect/pr82108.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr82108.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug c++/78269] FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C

[thopre01 at gcc dot gnu.org]

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

--- Comment #6 from Thomas Preud'homme  ---
(In reply to Paolo Carlini from comment #5)
> Thomas, both trunk and gcc-7-brnanch seem fine to me, I'm tempted to close
> the bug. Can you double check the released 7.1.0 on aarch64?

Hi Paolo,

yes I can confirm g++.dg/cpp1z/noexcept-type11.C passes on both ARM and Aarch64
on trunk and latest GCC 7.

This bug can be closed.

[Bug c++/78269] FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  ---
Any idea about stock 7.1.0? Or 7.2.0? We want to add the information before
resolving it.

[Bug tree-optimization/58012] Gcc bootstrap failed with cloog-isl: undefined reference to std::istream::ignore(long)

[extermina...@forty-seven.info]

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

Markus  changed:

   What|Removed |Added

 CC||extermina...@forty-seven.in
   ||fo

--- Comment #3 from Markus  ---
I had the same issue with 5.4.0 even without isl. What solved it for me was to
remove the '--disable-static' from the configure options.

[Bug testsuite/82120] New: FAIL: gcc.dg/tree-ssa/pr81588.c

[thopre01 at gcc dot gnu.org]

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

Bug ID: 82120
   Summary: FAIL: gcc.dg/tree-ssa/pr81588.c
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

Hi,

gcc.dg/tree-ssa/pr81588.c scan-tree-dump-times fails on GCC 7 (but not on
trunk) for Arm Cortex-M0, Cortex-M3 and Cortex-M4 cores. It does work when
targeting Arm Cortex-M7 though.

For the affected target, the string searched is not found in the dump.

Best regards.

[Bug tree-optimization/81588] [7/8 Regression] Wrong code at -O2

[clyon at gcc dot gnu.org]

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

--- Comment #10 from Christophe Lyon  ---
(In reply to Christophe Lyon from comment #9)
> I've noticed that the new testcase (gcc.dg/tree-ssa/pr81588.c) fails on the
> gcc-7 branch (r251446) on arm-linux-gnueabihf --with-cpu=cortex-a5
> --with-fpu=vfpv3-d16-fp16.

Thomas has just created a new bug report for this: bug #82120

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

[Bug fortran/82121] New: Unclassifiable statement during compilation when assigning to a Character array in a derived type contained in a ASSOCIATE statement

[iain.miller at ecmwf dot int]

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

Bug ID: 82121
   Summary: Unclassifiable statement during compilation when
assigning to a Character array in a derived type
contained in a ASSOCIATE statement
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iain.miller at ecmwf dot int
  Target Milestone: ---

Created attachment 42136
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42136&action=edit
Tarball of files showing issue and corresponding .s files

A bug has been introduced in gfortran 7+ when trying to use an ASSOCIATE
construct to associate a new variable name to a Character array held within a
derived type. The correct F03 code was previously compiled without issue in
gfortran 6.3.0 and earlier.

Addressing the array verbosely without using the associate variable compiles.
Addressing character arrays not in a derived type via an associate variable
compiles as well.

Output is:

sucddh.F90:17:0:

 CADHTLS(2)='SVGTLT'

Error: Unclassifiable statement at (1)

Files to reproduce (also attached for completeness):

#= yomcddh.F90 =#

MODULE YOMCDDH

IMPLICIT NONE

SAVE

TYPE :: TCDDH
CHARACTER(len=12),ALLOCATABLE :: CADHTLS(:)
END TYPE TCDDH

CHARACTER(len=12),ALLOCATABLE :: CADHTTS(:)

TYPE(TCDDH), POINTER :: YRCDDH => NULL()

END MODULE YOMCDDH

#= end of yomcddh.F90 =#

#= sucddh.F90 =#

SUBROUTINE SUCDDH()

USE YOMCDDH  , ONLY : YRCDDH,CADHTTS

IMPLICIT NONE

ALLOCATE (YRCDDH%CADHTLS(20))

ALLOCATE (CADHTTS(20))

ASSOCIATE(CADHTLS=>YRCDDH%CADHTLS, NORMCHAR=>CADHTTS)

! Direct reference to character array compiles correctly
YRCDDH%CADHTLS(1)='SVGTLF'

! Reference to associated variable name fails to compile
CADHTLS(2)='SVGTLT'

NORMCHAR(1)='SVLTTC'

END ASSOCIATE

END SUBROUTINE SUCDDH

#= end of sucddh.F90 =#

Build using following commands:

gfortran -c yomcddh.F90
gfortran -c -I. sucddh.F90

This has been confirmed on three separate x86_64 systems, two using SLES and
gfortran 7.2.0 and one using Fedora and gfortran 7.1.1.

Build details for SLES systems:
lxg38: vsimple $ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/group/usid/bin/compilers/lxg/gcc/7.2.0/libexec/gcc/x86_64-suse-linux/7.2.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../gcc-7.2.0/configure
--prefix=/home/group/usid/bin/compilers/lxg/gcc/7.2.0
--enable-languages=c,c++,objc,fortran,obj-c++ --enable-checking=release
--enable-ssp --disable-libssp --disable-plugin --disable-libgcj
--disable-libmudflap --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --with-cpu=generic
--build=x86_64-suse-linux --enable-linker-build-id --enable-linux-futex
--without-system-libunwind --disable-multilib --with-pkgversion='ECMWF build by
usid'
Thread model: posix
gcc version 7.2.0 (ECMWF build by usid) 

Build details for Fedora system:
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 7.1.1 20170622 (Red Hat 7.1.1-3) (GCC)

[Bug libstdc++/82122] New: Overloaded operator new/delete in MinGW is not calling from .dlls

[drizt at land dot ru]

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

Bug ID: 82122
   Summary: Overloaded operator new/delete in MinGW is not calling
from .dlls
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drizt at land dot ru
  Target Milestone: ---

$ /usr/bin/i686-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-w64-mingw32/7.2.0/lto-wrapper
Target: i686-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin
--includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --with-gnu-as --with-gnu-ld --verbose
--without-newlib --disable-multilib --disable-plugin --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-languages=c,c++,objc,obj-c++,fortran
--with-bugurl=http://bugzilla.redhat.com/bugzilla --with-cloog
--enable-threads=posix --enable-libgomp --target=i686-w64-mingw32
--with-sysroot=/usr/i686-w64-mingw32/sys-root
--with-gxx-include-dir=/usr/i686-w64-mingw32/sys-root/mingw/include/c++
Thread model: posix
gcc version 7.2.0 20170814 (Fedora MinGW 7.2.0-1.fc26) (GCC) 

For MinGW targets overloading new/delete operators is not applied for .dll
files. I tested it with Fedora 26 MinGW, MinGW 4.9.2 and MinGW 4.8.2 on Windows
7. Here I show log for Fedora MinGW

Source files:

$ cat lib.cpp 
#include "lib.h"

#include 
#include   

void func(A *a)
{
std::printf("library delete called, pointer = 0x%p\n", a);
delete a;
}

$ cat lib.h
class A
{
int a;
};

void func(A *a);

$ cat main.cpp
#include "lib.h"

#include 
#include 

// replacement of a minimal set of functions:
void *operator new(std::size_t sz)
{
void *ptr = std::malloc(sz);
std::printf("global op new called, size = %zu, pointer = 0x%p\n", sz, ptr);
return ptr;
}

void operator delete(void* ptr) noexcept
{
std::printf("global op delete called, pointer = 0x%p\n", ptr);
std::free(ptr);
}

int main()
{
A *a = new A();
A *b = new A();
func(a);
delete b;
return 0;
}

Compile:
$ i686-w64-mingw32-g++  -Dlib_EXPORTS  -std=c++11 -o lib.cpp.obj -c lib.cpp
$ i686-w64-mingw32-g++ -std=c++11 -shared -o liblib.dll lib.cpp.obj
$ i686-w64-mingw32-g++ -std=c++11 -o main.cpp.obj -c main.cpp
$ i686-w64-mingw32-g++ -std=c++11 -o main.exe liblib.dll -lkernel32 -luser32
-lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
main.cpp.obj

Output:
$ ./main.exe 
fixme:winediag:start_process Wine Staging 2.15 is a testing version containing
experimental patches.
fixme:winediag:start_process Please mention your exact version when filing bug
reports on winehq.org.
global op new called, size = 4, pointer = 0x00241718
global op new called, size = 4, pointer = 0x00246268
library delete called, pointer = 0x00241718
global op delete called, pointer = 0x00246268

The same with Linux gcc output:
$ ./main 
global op new called, size = 4, pointer = 0x0x1accc20
global op new called, size = 4, pointer = 0x0x1acd050
library delete called, pointer = 0x0x1accc20
global op delete called, pointer = 0x0x1accc20
global op delete called, pointer = 0x0x1acd050

[Bug testsuite/82120] FAIL: gcc.dg/tree-ssa/pr81588.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
logica-op-short-circuit?

[Bug target/82112] internal compiler error: in fold_convert_loc, at fold-const.c:2262

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 42137
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42137&action=edit
gcc8-pr82112.patch

Untested fix.

[Bug target/82108] [7 Regression] Wrong vectorized code generated for x86_64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||8.0
Summary|[7/8 Regression] Wrong  |[7 Regression] Wrong
   |vectorized code generated   |vectorized code generated
   |for x86_64  |for x86_64
  Known to fail|8.0 |

--- Comment #4 from Richard Biener  ---
Fixed on trunk sofar, thanks for the report.

[Bug c++/78269] FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|paolo.carlini at oracle dot com|
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #8 from Paolo Carlini  ---
Confirmed that 7.1.0 is fine.

[Bug c++/78269] FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C

[thopre01 at gcc dot gnu.org]

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

--- Comment #9 from Thomas Preud'homme  ---
(In reply to Paolo Carlini from comment #8)
> Confirmed that 7.1.0 is fine.

It is indeed. As can be seen in my comment #4, this was fixed somewhere before
14th of November 2016, well before GCC 7 release.

Best regards.

[Bug testsuite/82120] FAIL: gcc.dg/tree-ssa/pr81588.c

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
This is a total mess.  I've copied a boilerplate from other tests that require
branch cost of 2.
I guess
2017-09-06  Jakub Jelinek  

PR testsuite/82120
* gcc.dg/tree-ssa/pr81588.c: Don't run on logical_op_short_circuit
targets.

--- gcc/testsuite/gcc.dg/tree-ssa/pr81588.c.jj  2017-08-02 12:10:36.0
+0200
+++ gcc/testsuite/gcc.dg/tree-ssa/pr81588.c 2017-09-06 16:09:57.373505808
+0200
@@ -1,5 +1,5 @@
 /* PR tree-optimization/81588 */
-/* { dg-do compile { target { ! "m68k*-*-* mmix*-*-* bfin*-*-* v850*-*-*
moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-* xtensa*-*-*
hppa*-*-* nios2*-*-*" } } } */
+/* { dg-do compile { target { ! { logical_op_short_circuit || { m68k*-*-*
bfin*-*-* v850*-*-* moxie*-*-* m32c*-*-* fr30*-*-* mcore*-*-* xtensa*-*-*
hppa*-*-* } } } } } */
 /* { dg-options "-O2 -fdump-tree-reassoc1-details" } */
 /* { dg-additional-options "-mbranch-cost=2" { target mips*-*-* avr-*-*
s390*-*-* i?86-*-* x86_64-*-* } } */

could fix that, but that will mean it will be untested even on mips, avr and
s390 when it could be tested there.

So perhaps better:
2017-09-06  Jakub Jelinek  

PR testsuite/82120
* gcc.dg/tree-ssa/pr81588.c: Don't run on logical_op_short_circuit
targets
except for those where -mbranch-cost=2 is supported.

--- gcc/testsuite/gcc.dg/tree-ssa/pr81588.c.jj  2017-08-02 12:10:36.0
+0200
+++ gcc/testsuite/gcc.dg/tree-ssa/pr81588.c 2017-09-06 16:17:30.563118589
+0200
@@ -1,5 +1,5 @@
 /* PR tree-optimization/81588 */
-/* { dg-do compile { target { ! "m68k*-*-* mmix*-*-* bfin*-*-* v850*-*-*
moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-* xtensa*-*-*
hppa*-*-* nios2*-*-*" } } } */
+/* { dg-do compile { target { ! { { logical_op_short_circuit && { ! "mips*-*-*
avr-*-* s390*-*-*" } } || { m68k*-*-* bfin*-*-* v850*-*-* moxie*-*-* m32c*-*-*
fr30*-*-* mcore*-*-* xtensa*-*-* hppa*-*-* } } } } } */
 /* { dg-options "-O2 -fdump-tree-reassoc1-details" } */
 /* { dg-additional-options "-mbranch-cost=2" { target mips*-*-* avr-*-*
s390*-*-* i?86-*-* x86_64-*-* } } */


Can you test it on the various arm configurations (just make check-gcc
RUNTESTFLAGS=tree-ssa.exp=pr81588.c)?
Wonder about the targets that aren't included in logical_op_short_circuit, what
they actually do and why they are in the lists in the other testcases.

[Bug c++/78269] FAIL: FAIL: g++.dg/cpp1z/noexcept-type11.C and FAIL: g++.dg/cpp1z/noexcept-type9.C

[thopre01 at gcc dot gnu.org]

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

--- Comment #10 from Thomas Preud'homme  ---
(In reply to Thomas Preud'homme from comment #9)
> (In reply to Paolo Carlini from comment #8)
> > Confirmed that 7.1.0 is fine.
> 
> It is indeed. As can be seen in my comment #4, this was fixed somewhere
> before 14th of November 2016, well before GCC 7 release.
> 
> Best regards.

Exact revision that fixed the bug on ARM is: r242026

[Bug testsuite/82120] FAIL: gcc.dg/tree-ssa/pr81588.c

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from Thomas Preud'homme  ---
(In reply to Jakub Jelinek from comment #2)
> This is a total mess.  I've copied a boilerplate from other tests that
> require branch cost of 2.
> I guess
> 2017-09-06  Jakub Jelinek  
> 
>   PR testsuite/82120
>   * gcc.dg/tree-ssa/pr81588.c: Don't run on logical_op_short_circuit 
> targets.
> 
> --- gcc/testsuite/gcc.dg/tree-ssa/pr81588.c.jj2017-08-02 
> 12:10:36.0
> +0200
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr81588.c   2017-09-06 16:09:57.373505808
> +0200
> @@ -1,5 +1,5 @@
>  /* PR tree-optimization/81588 */
> -/* { dg-do compile { target { ! "m68k*-*-* mmix*-*-* bfin*-*-* v850*-*-*
> moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-* xtensa*-*-*
> hppa*-*-* nios2*-*-*" } } } */
> +/* { dg-do compile { target { ! { logical_op_short_circuit || { m68k*-*-*
> bfin*-*-* v850*-*-* moxie*-*-* m32c*-*-* fr30*-*-* mcore*-*-* xtensa*-*-*
> hppa*-*-* } } } } } */
>  /* { dg-options "-O2 -fdump-tree-reassoc1-details" } */
>  /* { dg-additional-options "-mbranch-cost=2" { target mips*-*-* avr-*-*
> s390*-*-* i?86-*-* x86_64-*-* } } */
>  
> could fix that, but that will mean it will be untested even on mips, avr and
> s390 when it could be tested there.
> 
> So perhaps better:
> 2017-09-06  Jakub Jelinek  
> 
>   PR testsuite/82120
>   * gcc.dg/tree-ssa/pr81588.c: Don't run on logical_op_short_circuit 
> targets
>   except for those where -mbranch-cost=2 is supported.
> 
> --- gcc/testsuite/gcc.dg/tree-ssa/pr81588.c.jj2017-08-02 
> 12:10:36.0
> +0200
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr81588.c   2017-09-06 16:17:30.563118589
> +0200
> @@ -1,5 +1,5 @@
>  /* PR tree-optimization/81588 */
> -/* { dg-do compile { target { ! "m68k*-*-* mmix*-*-* bfin*-*-* v850*-*-*
> moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-* powerpc*-*-* xtensa*-*-*
> hppa*-*-* nios2*-*-*" } } } */
> +/* { dg-do compile { target { ! { { logical_op_short_circuit && { !
> "mips*-*-* avr-*-* s390*-*-*" } } || { m68k*-*-* bfin*-*-* v850*-*-*
> moxie*-*-* m32c*-*-* fr30*-*-* mcore*-*-* xtensa*-*-* hppa*-*-* } } } } } */
>  /* { dg-options "-O2 -fdump-tree-reassoc1-details" } */
>  /* { dg-additional-options "-mbranch-cost=2" { target mips*-*-* avr-*-*
> s390*-*-* i?86-*-* x86_64-*-* } } */
>  
> 
> Can you test it on the various arm configurations (just make check-gcc
> RUNTESTFLAGS=tree-ssa.exp=pr81588.c)?
> Wonder about the targets that aren't included in logical_op_short_circuit,
> what they actually do and why they are in the lists in the other testcases.

I've tested it for a variety of Arm Cortex-M and Cortex-A cores and it either
PASS or is marked as UNSUPPORTED so looks good to me, thanks.

Best regards.

[Bug testsuite/82120] FAIL: gcc.dg/tree-ssa/pr81588.c

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Sep  6 15:10:28 2017
New Revision: 251806

URL: https://gcc.gnu.org/viewcvs?rev=251806&root=gcc&view=rev
Log:
PR testsuite/82120
* gcc.dg/tree-ssa/pr81588.c: Don't run on logical_op_short_circuit
targets except for those where -mbranch-cost=2 is supported.

Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.dg/tree-ssa/pr81588.c

[Bug fortran/82121] [7/8 Regression] Unclassifiable statement during compilation when assigning to a Character array in a derived type contained in a ASSOCIATE statement

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||6.4.0
   Keywords||rejects-valid
   Last reconfirmed||2017-09-06
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Unclassifiable statement|[7/8 Regression]
   |during compilation when |Unclassifiable statement
   |assigning to a Character|during compilation when
   |array in a derived type |assigning to a Character
   |contained in a ASSOCIATE|array in a derived type
   |statement   |contained in a ASSOCIATE
   ||statement
  Known to fail||7.2.0, 8.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed, likely r241860 (pr64933).

[Bug middle-end/82123] New: [7 regression] spurious -Wformat-overflow warning for converted vars

[arnd at linaro dot org]

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

Bug ID: 82123
   Summary: [7 regression] spurious -Wformat-overflow warning for
converted vars
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

This one seems to be related to pr77721 and pr81483. The first however only
happens with -Wformat-overflow=2, and the second one has no type conversion, so
I'm opening a separate pr for this one. Reproduced with gcc-7.1.1 and gcc-8.0.0
(r251692).

$ x86_64-linux-gcc-8.0.0 -c gpiolib-acpi.c -O2 -Wformat-overflow=1
gpiolib-acpi.c: In function 'acpi_gpiochip_request_interrupt':
gpiolib-acpi.c:7:28: warning: '%02X' directive writing between 2 and 4 bytes
into a region of size 3 [-Wformat-overflow=]
   __builtin_sprintf(name, "%02X", pin);
^~~~
gpiolib-acpi.c:7:27: note: directive argument in the range [0, 65535]
   __builtin_sprintf(name, "%02X", pin);
   ^~
gpiolib-acpi.c:7:3: note: '__builtin_sprintf' output between 3 and 5 bytes into
a destination of size 3
   __builtin_sprintf(name, "%02X", pin);
   ^~~~

8<
void acpi_gpiochip_request_interrupt(unsigned short s)
{
char name[3];
unsigned int pin = s;

if (pin <= 255)
__builtin_sprintf(name, "%02X", pin);
}

[Bug c++/82067] G++ has an internal compiler error in possible_polymorphic_call_targets, at ipa-devirt.c:1557

[jupitercuso4 at gmail dot com]

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

--- Comment #5 from jupitercuso4 at gmail dot com ---
$ g++ -std=c++11 -O3 --save-temps test.i
test.cpp: In constructor
'xtsc_component::xtsc_queue_pin::xtsc_queue_pin(sc_core::sc_module_name, const
xtsc_component::xtsc_queue_pin_parms&)':
test.cpp:32:1: internal compiler error: in possible_polymorphic_call_targets,
at ipa-devirt.c:1557
 xtsc_component::xtsc_queue_pin::xtsc_queue_pin(sc_module_name module_name,
const xtsc_queue_pin_parms& queue_parms) :
 ^
0x6828cb possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, int*)
../../gcc-4.9.4/gcc/ipa-devirt.c:1557
0x665cea possible_polymorphic_call_targets(tree_node*, bool*, void**)
../../gcc-4.9.4/gcc/ipa-utils.h:142
0xc87198 gimple_fold_call
../../gcc-4.9.4/gcc/gimple-fold.c:1127
0xc87198 fold_stmt_1
../../gcc-4.9.4/gcc/gimple-fold.c:1302
0xd909b8 fold_marked_statements
../../gcc-4.9.4/gcc/tree-inline.c:4549
0xd8c2e0 optimize_inline_calls(tree_node*)
../../gcc-4.9.4/gcc/tree-inline.c:4630
0xf48b89 inline_transform(cgraph_node*)
../../gcc-4.9.4/gcc/ipa-inline-transform.c:457
0xd1b58a execute_one_ipa_transform_pass
../../gcc-4.9.4/gcc/passes.c:2066
0xd1b58a execute_all_ipa_transforms()
../../gcc-4.9.4/gcc/passes.c:2107
0xbd8abd expand_function
../../gcc-4.9.4/gcc/cgraphunit.c:1775
0xf99653 expand_all_functions
../../gcc-4.9.4/gcc/cgraphunit.c:1916
0xf99653 compile()
../../gcc-4.9.4/gcc/cgraphunit.c:2260
0xf98f17 finalize_compilation_unit()
../../gcc-4.9.4/gcc/cgraphunit.c:2337
0xb149dd cp_write_global_declarations()
../../gcc-4.9.4/gcc/cp/decl2.c:4647
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/77726] On MinGW targets, user-defined `operator delete(void *)` is not called if the sized-deallocation version is not provided in C++14 mode when libstdc++ is linked dynamically

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Replacing new/delete doesn't work properly on mingw.

[Bug libstdc++/77726] On MinGW targets, user-defined `operator delete(void *)` is not called if the sized-deallocation version is not provided in C++14 mode when libstdc++ is linked dynamically

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|major   |normal

[Bug libstdc++/82122] Overloaded operator new/delete in MinGW is not calling from .dlls

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
.

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

[Bug libstdc++/81413] overloaded new and delete might not be called when dynamically linked with libstdc++

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||drizt at land dot ru

--- Comment #2 from Jonathan Wakely  ---
*** Bug 82122 has been marked as a duplicate of this bug. ***

[Bug middle-end/78468] [8 regression] libgomp.c/reduction-10.c and many more FAIL

[wilco at gcc dot gnu.org]

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

--- Comment #43 from Wilco  ---
Author: wilco
Date: Wed Sep  6 16:34:54 2017
New Revision: 251811

URL: https://gcc.gnu.org/viewcvs?rev=251811&root=gcc&view=rev
Log:
PR78468 - add alloca alignment test

Add an alignment test to check that aligned alloca's really do get
correctly aligned.  Some targets may not ensure SP is always a multiple
of STACK_BOUNDARY (particularly with outgoing arguments), which means
aligned alloca does not get correctly aligned.  This can be fixed either
by aligning the outgoing arguments or setting STACK_BOUNDARY correctly.

testsuite/
PR middle-end/78468
* gcc.dg/pr78468.c: Add alignment test.

Added:
trunk/gcc/testsuite/gcc.dg/pr78468.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/77726] On MinGW targets, user-defined `operator delete(void *)` is not called if the sized-deallocation version is not provided in C++14 mode when libstdc++ is linked dynamically

[lh_mouse at 126 dot com]

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

--- Comment #2 from Liu Hao  ---
It isn't weired if you know how a Dynamic-Link Library (DLL) on Windows works
different than a Shared Object (SO) on Linux.

Windows does not have a dynamic linker such as `ld.so` on Linux. Symbols in a
DLL are resolved at build-time, in contrary to Linux, where symbols in a SO are
resolved at load-time. The DLL loader can resolve symbols to addresses, but it
isn't as powerful as linkers after all. Consequently, an executable cannot use
its strong symbols to override already-resolved weak ones in a DLL.

If the user does not define a sized deallocation function, the default one in
libstdc++*.dll is used, which calls the weak, default, non-sized deallocation
function in the same DLL, which is the only candidate when the DLL is built and
can't be overridden.

Possible solution:
The default sized deallocation function should not call the non-sized one
directly. We may introduce a static pointer-to-function which points to the
non-sized one initially. The default sized deallocation function should read
that pointer then call the function it points to. An executable that defines a
non-sized deallocation function should modify that pointer to point to the
user-provided non-sized deallocation function before any other code that may
allocate dynamic memory, possibly via an implicitly generated __constructor__
with high priority.

Question:
What will happen if both the executable and another DLL try to replace the
non-sized deallocation function?
It looks to me that on Linux such scenario will end up in multiple definitions.
In this case abort() or std::terminate() is possibly solution.

[Bug c++/82070] [8 Regression] inaccessible within this context in lambda rejects valid

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/81987] [8 Regression] ICE in verify_ssa with -O3 -march=skylake-avx512

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Sep  6 18:42:56 2017
New Revision: 251815

URL: https://gcc.gnu.org/viewcvs?rev=251815&root=gcc&view=rev
Log:
[gcc]

2017-09-06  Bill Schmidt  

Backport from mainline:
2017-08-30  Bill Schmidt  

PR tree-optimization/81987
* gimple-ssa-strength-reduction.c (insert_initializers): Don't
insert an initializer in a location not dominated by the stride
definition.

[gcc/testsuite]

2017-09-06  Bill Schmidt  

Backport from mainline:
2017-08-30  Bill Schmidt  

PR tree-optimization/81987
* g++.dg/torture/pr81987.C: New file.


Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr81987.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/gimple-ssa-strength-reduction.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/81987] [8 Regression] ICE in verify_ssa with -O3 -march=skylake-avx512

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Sep  6 18:44:51 2017
New Revision: 251816

URL: https://gcc.gnu.org/viewcvs?rev=251816&root=gcc&view=rev
Log:
[gcc]

2017-09-06  Bill Schmidt  

Backport from mainline:
2017-08-30  Bill Schmidt  

PR tree-optimization/81987
* gimple-ssa-strength-reduction.c (insert_initializers): Don't
insert an initializer in a location not dominated by the stride
definition.

[gcc/testsuite]

2017-09-06  Bill Schmidt  

Backport from mainline:
2017-08-30  Bill Schmidt  

PR tree-optimization/81987
* g++.dg/torture/pr81987.C: New file.


Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr81987.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gimple-ssa-strength-reduction.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/81987] [8 Regression] ICE in verify_ssa with -O3 -march=skylake-avx512

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Sep  6 18:48:50 2017
New Revision: 251817

URL: https://gcc.gnu.org/viewcvs?rev=251817&root=gcc&view=rev
Log:
[gcc]

2017-09-06  Bill Schmidt  

Backport from mainline:
2017-08-30  Bill Schmidt  

PR tree-optimization/81987
* gimple-ssa-strength-reduction.c (insert_initializers): Don't
insert an initializer in a location not dominated by the stride
definition.

[gcc/testsuite]

2017-09-06  Bill Schmidt  

Backport from mainline:
2017-08-30  Bill Schmidt  

PR tree-optimization/81987
* g++.dg/torture/pr81987.C: New file.


Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/torture/pr81987.C
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/gimple-ssa-strength-reduction.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/81987] [8 Regression] ICE in verify_ssa with -O3 -march=skylake-avx512

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #12 from Bill Schmidt  ---
Now fixed everywhere.  Thanks again for the report!

[Bug libstdc++/79433] __has_include() is true but #include gives #error when -std=old

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #24 from Jonathan Wakely  ---
The study group has approved the idea in comment 23 so I'm making that change
(on trunk only so far).

[Bug c++/82080] ICE: Segmentation fault

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
Turns out the issue was with my compiler version; after updating from an August
checkout to a September checkout, I can reproduce the ICE with both -m64 and
-m32. Confirmed.

[Bug c++/82070] [8 Regression] inaccessible within this context in lambda rejects valid

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Wed Sep  6 19:36:48 2017
New Revision: 251819

URL: https://gcc.gnu.org/viewcvs?rev=251819&root=gcc&view=rev
Log:
PR c++/82070 - error with nested lambda capture

* pt.c (tsubst_expr) [DECL_EXPR]: Register capture proxies with
register_local_specialization.

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

[Bug libgomp/82124] New: FAIL: libgomp.c++/pr69393.C (test for excess errors)

[egallager at gcc dot gnu.org]

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

Bug ID: 82124
   Summary: FAIL: libgomp.c++/pr69393.C (test for excess errors)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-apple-darwin9.8.0
Target: i386-apple-darwin9.8.0
 Build: i386-apple-darwin9.8.0

Diffing https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg00882.html and 
https://gcc.gnu.org/ml/gcc-testresults/2017-09/msg00470.html shows that a new
libgomp test failure was introduced between August and September:

 Running target unix
+FAIL: libgomp.c++/pr69393.C (test for excess errors)

=== libgomp Summary ===

-# of expected passes   1788
+# of expected passes   1789
+# of unexpected failures   1
 # of unsupported tests 208

Checking libgomp/testsuite/libgomp.log, the excess errors are:

FAIL: libgomp.c++/pr69393.C (test for excess errors)
Excess errors:
/var/tmp//ccWCqG7a.s:303:non-relocatable subtraction expression,
"_pr69393.C.a48af4a2" minus "Lsection__debug_info"
/var/tmp//ccWCqG7a.s:303:symbol: "_pr69393.C.a48af4a2" can't be undefined in a
subtraction expression
/var/tmp//ccWCqG7a.s:300:non-relocatable subtraction expression,
"_pr69393.C.a48af4a2" minus "Lsection__debug_info"
/var/tmp//ccWCqG7a.s:300:symbol: "_pr69393.C.a48af4a2" can't be undefined in a
subtraction expression
/var/tmp//ccWCqG7a.s:298:non-relocatable subtraction expression,
"_pr69393.C.a48af4a2" minus "Lsection__debug_info"
/var/tmp//ccWCqG7a.s:298:symbol: "_pr69393.C.a48af4a2" can't be undefined in a
subtraction expression
/var/tmp//ccWCqG7a.s:296:non-relocatable subtraction expression,
"_pr69393.C.a48af4a2" minus "Lsection__debug_info"
/var/tmp//ccWCqG7a.s:296:symbol: "_pr69393.C.a48af4a2" can't be undefined in a
subtraction expression
/var/tmp//ccWCqG7a.s:289:non-relocatable subtraction expression,
"_pr69393.C.a48af4a2" minus "Lsection__debug_info"
/var/tmp//ccWCqG7a.s:289:symbol: "_pr69393.C.a48af4a2" can't be undefined in a
subtraction expression
/var/tmp//ccWCqG7a.s:282:non-relocatable subtraction expression,
"_pr69393.C.a48af4a2" minus "Lsection__debug_info"
/var/tmp//ccWCqG7a.s:282:symbol: "_pr69393.C.a48af4a2" can't be undefined in a
subtraction expression
/var/tmp//ccWCqG7a.s:276:non-relocatable subtraction expression,
"_pr69393.C.a48af4a2" minus "Lsection__debug_info"
/var/tmp//ccWCqG7a.s:276:symbol: "_pr69393.C.a48af4a2" can't be undefined in a
subtraction expression
/var/tmp//ccWCqG7a.s:270:non-relocatable subtraction expression,
"_pr69393.C.a48af4a2" minus "Lsection__debug_info"
/var/tmp//ccWCqG7a.s:270:symbol: "_pr69393.C.a48af4a2" can't be undefined in a
subtraction expression
/var/tmp//ccWCqG7a.s:265:non-relocatable subtraction expression,
"_pr69393.C.a48af4a2" minus "Lsection__debug_info"
/var/tmp//ccWCqG7a.s:265:symbol: "_pr69393.C.a48af4a2" can't be undefined in a
subtraction expression
/var/tmp//ccWCqG7a.s:258:non-relocatable subtraction expression,
"_pr69393.C.a48af4a2" minus "Lsection__debug_info"
/var/tmp//ccWCqG7a.s:258:symbol: "_pr69393.C.a48af4a2" can't be undefined in a
subtraction expression
/var/tmp//ccWCqG7a.s:256:non-relocatable subtraction expression,
"_pr69393.C.a48af4a2" minus "Lsection__debug_info"
/var/tmp//ccWCqG7a.s:256:symbol: "_pr69393.C.a48af4a2" can't be undefined in a
subtraction expression
lto-wrapper: fatal error: /var/root/gcc-git/my_oddly_named_builddir/gcc/xgcc
returned 1 exit status
compilation terminated.
collect2: fatal error: lto-wrapper returned 1 exit status
compilation terminated.

I attached the full logfile. Version info:

$ /usr/local/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release,rtl
-C --with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --with-isl --disable-host-shared --enable-maintainer-mode
--disable-default-pie --with-ld64 --without-pic --enable-target-optspace
--enable-libstdcxx-debug CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++
AUTOCONF=/usr/local/bin/autoconf AUTOHEADER=/usr/local/bin/autoheader
AUTORECONF=/usr/local/bin/autoreconf AUTOM4TE=/usr/local/bin/autom4te
AUTOSCAN=/usr/local/bin/autoscan AUTOUPDATE=/usr/local/bin/autoupdate
IFNAMES=/usr/local/bin/ifnames
Thread model: posix
gcc version 8.0.0 20170905 (experimental) (GCC) 
$

[Bug libgomp/82124] FAIL: libgomp.c++/pr69393.C (test for excess errors)

[egallager at gcc dot gnu.org]

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

--- Comment #1 from Eric Gallager  ---
Created attachment 42138
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42138&action=edit
bzipped libgomp.log

Oops, the log was too big to attach on its own; trying again after compressing
it...

[Bug libgomp/82124] FAIL: libgomp.c++/pr69393.C (test for excess errors)

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
Created attachment 42139
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42139&action=edit
Full testresults diff

(attaching the full diff between the 2 test logs to remind myself to open other
bugs for the other new failures)

[Bug c++/82070] [8 Regression] inaccessible within this context in lambda rejects valid

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail

[dilfridge at gentoo dot org]

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

--- Comment #37 from Andreas K. Huettel  ---
Created attachment 42140
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42140&action=edit
gparted build log

Here's the build log from my Gentoo colleague.

If you need more, please tell me precisely what - I dont have that much
experience reporting here yet. Can't reopen the bug either.

[Bug c++/82125] New: Suboptimal error message for range-based for

[rs2740 at gmail dot com]

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

Bug ID: 82125
   Summary: Suboptimal error message for range-based for
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

void meow() {
   int a[3][4];
   for(const auto r : a)
for(auto e : r) {}
}

This emits

prog.cc: In function 'void meow()':
prog.cc:4:22: error: 'begin' was not declared in this scope
 for(auto e : r) {}
  ^
prog.cc:4:22: error: 'end' was not declared in this scope

which, while not inaccurate, isn't helpful either. There is literally no scope
in which begin/end can be looked up, because int* has no associated namespace
whatsoever.

Moreover, if some begin/end is around - say, via #include  - then we
get a list of "suggested alternatives". But that seems even less helpful since
the form of the call is hard-coded in the language and isn't something the
programmer has any control over.

[Bug c++/82053] [8 Regression] ICE on invalid code

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Sep  7 01:02:46 2017
New Revision: 251826

URL: https://gcc.gnu.org/viewcvs?rev=251826&root=gcc&view=rev
Log:
PR c++/82053 - ICE with default argument in lambda in template

* pt.c (tsubst_arg_types): Substitute default arguments for lambdas
in templates.
(retrieve_specialization): Use lambda_fn_in_template_p.
* cp-tree.h: Declare it.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-defarg7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c

[Bug c++/82053] [8 Regression] ICE on invalid code

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/81640] [8 Regression] ICE in lookup_fnfields_slot_nolazy w/ -Wshadow=compatible-local

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Jason Merrill  ---
So, fixed.

[Bug c++/70029] [8 Regression] ICE with C++11 and -flto

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/70029] [8 Regression] ICE with C++11 and -flto

[jason at gcc dot gnu.org]

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

--- Comment #13 from Jason Merrill  ---
I believe r241831 fixed the actual problem that verify_type was catching.  This
still fails because free_lang_data_in_type clears TYPE_LANG_FLAG_4 on 't' but
not 'ct'.  Should something have added TYPE_CANONICAL to fld.types?

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[daniel.black at au dot ibm.com]

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

Daniel Black  changed:

   What|Removed |Added

 CC||daniel.black at au dot ibm.com

--- Comment #25 from Daniel Black  ---
Also getting this on linux kernel 4.13 release on gcc master branch but not
gcc-7:

There are at least two locations that generate this backtrace.

gcc -O1 -c -o drivers/scsi/mpt3sas/.tmp_mpt3sas_scsih.o   ./mpt3sas_scsih.i

during GIMPLE pass: profile_estimate
drivers/scsi/mpt3sas/mpt3sas_scsih.c: In function ‘mpt3sas_scsih_issue_tm’:
drivers/scsi/mpt3sas/mpt3sas_scsih.c:9455:1: internal compiler error: in
to_reg_br_prob_base, at profile-count.h:189
 module_exit(_mpt3sas_exit);
 ^~
0x1085d55f profile_probability::to_reg_br_prob_base() const
../../gcc/profile-count.h:189
0x1085d55f estimate_bb_frequencies(bool)
../../gcc/predict.c:3570
0x10861123 tree_estimate_probability(bool)
../../gcc/predict.c:2827
0x1086165f execute
../../gcc/predict.c:3712
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Simplest ICE generation is -O1. -O0 gets to code errors.

[Bug c/54113] -Wmissing-prototypes produces false alarms for C99 inline functions

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Paul Eggert from comment #0)
> 
> The simplest way to work around the problem is to avoid
> the use of -Wmissing-prototypes, but that disables the
> diagnostic for non-inline functions, where it's useful.
> 

Note that this only works for plain C; using diagnostic pragmas (like those
expanded from gnulib's _GL_INLINE_HEADER_BEGIN) to suppress
-Wmissing-prototypes leads to the following warning in C++:

build-gnulib/../config.h:2101:5: warning: option ‘-Wmissing-prototypes’ is
valid for C/ObjC but not for C++ [-Wpragmas]
 _Pragma ("GCC diagnostic ignored \"-Wmissing-prototypes\"") \
 ^~~

[Bug middle-end/82123] [7 regression] spurious -Wformat-overflow warning for converted vars

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirmed.

[Bug c++/82110] Concept for default constructing works with new T, not with new T[1]

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-07
 CC||egallager at gcc dot gnu.org
 Blocks||67491
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed that g++ errors where you say it does:

$ /usr/local/bin/g++ -c -fconcepts -std=c++1z 82110.cc
82110.cc: In function ‘int main()’:
82110.cc:17:5: error: static assertion failed
 static_assert(!D); // error
 ^
$


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues