[Bug c++/67825] [concepts] expression constraint bug when taking address of a member function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Last reconfirmed||2020-04-04
 Ever confirmed|0   |1

[Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318

[cvs-commit at gcc dot gnu.org]

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

--- Comment #46 from CVS Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:7f26e60c2600f0a676fc9370390ebf0a3c78f31c

commit r10-7548-g7f26e60c2600f0a676fc9370390ebf0a3c78f31c
Author: Jeff Law 
Date:   Fri Apr 3 17:47:18 2020 -0600

Fix stdarg-3 regression on xstormy16 port

PR rtl-optimization/92264
* config/stormy16/stormy16.c (xstormy16_preferred_reload_class):
Handle
reloading of auto-increment addressing modes.

[Bug c++/94477] ICE in tsubst_expr, at cp/pt.c:18181

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/94482] New: Inserting into vector with optimization enabled on x86 generates incorrect result

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

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

Bug ID: 94482
   Summary: Inserting into vector with optimization enabled on x86
generates incorrect result
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e...@coeus-group.com
  Target Milestone: ---

Created attachment 48193
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48193=edit
Test case

I'm tyring to implement _mm_insert_epi64 without relying on intrinsics.  The
GCC-generated executable fails on x86 (but not x86_64) at -O2 and above. 
AFAICT it works on every other architecture and optimiaztion level I've tried. 
It happens on every version of GCC I've tested (7 - 9.3.0), in both C and C++
modes.

I've attached a test case (generated with C-Reduce, slightly modified to remove
some unnecessary macros) which reproduces the issue.  Line 4 is interesting;
the j field isn't used anywhere but if you remove it the code works
(unfortunately not an option in my project).

Please let me know if you need any additional information.

[Bug c++/94477] ICE in tsubst_expr, at cp/pt.c:18181

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:0c809f727cd2a6c70c307d9dd53d26dc84bf292a

commit r10-7547-g0c809f727cd2a6c70c307d9dd53d26dc84bf292a
Author: Jakub Jelinek 
Date:   Sat Apr 4 00:35:41 2020 +0200

openmp: Fix ICE on #pragma omp parallel master in template [PR94477]

The following testcase ICEs, because for parallel combined with some
other construct we initialize the omp_parallel_combined_clauses pointer
and expect the construct combined with it to clear it after it no longer
needs it, but OMP_MASTER didn't do that.

2020-04-04  Jakub Jelinek  

PR c++/94477
* pt.c (tsubst_expr) : Clear
omp_parallel_combined_clauses.

* g++.dg/gomp/pr94477.C: New test.

[Bug libbacktrace/92916] elf_add freeing strtab_view in fail, even though it shouldn't

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #2 from Ian Lance Taylor  ---
I've been postponing a merge from the GitHub repo to the GCC repo because GCC
development is in stage 4 (only changes that fix significant bugs).

[Bug libbacktrace/92916] elf_add freeing strtab_view in fail, even though it shouldn't

[marc.streckfuss at gmail dot com]

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

--- Comment #1 from Marc Streckfuß  ---
This is fixed in https://github.com/ianlancetaylor/libbacktrace, if the changes
are also upstream, this bug can be closed.

[Bug c++/94481] New: ICE: Segmentation fault (in cp_parser_placeholder_type_specifier)

[asolokha at gmx dot com]

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

Bug ID: 94481
   Summary: ICE: Segmentation fault (in
cp_parser_placeholder_type_specifier)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.1-alpha20200329 snapshot (g:60c254b279e8e8443b8ad26cc46b9e4084cff66c)
ICEs when compiling the following testcase, extracted from
test/Parser/cxx2a-placeholder-type-constraint.cpp from the clang 10.0.0 test
suite, w/ -std=c++2a:

template
concept C = true;

void foo() {
  C decltype a19 = 1;
}

% g++-10.0.1 -std=c++2a -c siabxbp8.cpp
siabxbp8.cpp: In function 'void foo()':
siabxbp8.cpp:5:5: internal compiler error: Segmentation fault
5 |   C decltype a19 = 1;
  | ^~~~
0xfe238f crash_signal
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/toplev.c:328
0x980d5d cp_parser_placeholder_type_specifier
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:18381
0x9b39d7 cp_parser_simple_type_specifier
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:18247
0x996e45 cp_parser_type_specifier
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:17784
0x997fb5 cp_parser_decl_specifier_seq
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:14356
0x998a54 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:13610
0x99a8fa cp_parser_declaration_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:13163
0x99b56f cp_parser_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:11469
0x99c4d8 cp_parser_statement_seq_opt
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:11835
0x99c5b8 cp_parser_compound_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:11785
0x9b4855 cp_parser_function_body
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:23062
0x9b4855 cp_parser_ctor_initializer_opt_and_function_body
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:23113
0x9b7cf6 cp_parser_function_definition_after_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:28988
0x9b8d89 cp_parser_function_definition_from_specifiers_and_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:28904
0x9b8d89 cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:20669
0x998b56 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:13731
0x9c3302 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:13430
0x9c3a9f cp_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:4731
0x9c3a9f c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:43944
0xadbadb c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/c-family/c-opts.c:1186

[Bug c++/94480] New: ICE in cp_parser_abort_tentative_parse, at cp/parser.c:31858

[asolokha at gmx dot com]

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

Bug ID: 94480
   Summary: ICE in cp_parser_abort_tentative_parse, at
cp/parser.c:31858
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.1-alpha20200329 snapshot (g:60c254b279e8e8443b8ad26cc46b9e4084cff66c)
ICEs when compiling the following testcase, extracted from
test/CXX/expr/expr.prim/expr.prim.req/requires-expr.cpp from the clang 10.0.0
test suite, w/ -fconcepts:

template
constexpr bool is_same_v = false;

static_assert(is_same_v);

% g++-10.0.1 -fconcepts -c nn8nrioc.cpp
nn8nrioc.cpp:4:60: note: the expression 'false' evaluated to 'false'
4 | static_assert(is_same_v);
  |   ~^
nn8nrioc.cpp:4:67: internal compiler error: in cp_parser_abort_tentative_parse,
at cp/parser.c:31858
4 | static_assert(is_same_v);
  |   ^
0x63c536 cp_parser_abort_tentative_parse
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:31858
0x63c536 cp_parser_abort_tentative_parse
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:31856
0x9a9b4f cp_parser_decltype_expr
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:14832
0x9a9b4f cp_parser_decltype
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:14920
0x9b34ef cp_parser_simple_type_specifier
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:18008
0x996e45 cp_parser_type_specifier
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:17784
0x9aca80 cp_parser_type_specifier_seq
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:22385
0x9a53c7 cp_parser_type_id_1
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:22202
0x9a82e3 cp_parser_template_type_arg
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:22293
0x9acc1f cp_parser_template_argument
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:17181
0x9acc1f cp_parser_template_argument_list
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:17092
0x9acc1f cp_parser_enclosed_template_argument_list
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:29761
0x9adf60 cp_parser_template_id
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:16664
0x9ae62a cp_parser_class_name
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:23696
0x9aa385 cp_parser_qualifying_entity
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:6773
0x9aa385 cp_parser_nested_name_specifier_opt
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:6455
0x9b2f59 cp_parser_simple_type_specifier
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:18126
0x9a83ea cp_parser_postfix_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:7173
0x98a669 cp_parser_binary_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:9554
0x98c31e cp_parser_assignment_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:9859

[Bug tree-optimization/93435] [8/9 Regression] Hang with -O2 on innocuous looking code with GCC 8.3

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor  ---
The problematic behavior of SRA is now fixed on master and both opened
release branches so I consider my work done here.

I'm leaving the bug opened in case Jeff wants to add some DSE limiter
like he wrote in comment #5.

[Bug c++/94453] [10 Regression] ICE in make_decl_rtl since r10-3591

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/91966] [8 Regression] pack expansion for Cartesian product breaks if certain indirections are involved since r6-1487-g1a4cd2cd7e7266b0

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9 Regression] pack   |[8 Regression] pack
   |expansion for Cartesian |expansion for Cartesian
   |product  breaks if certain  |product  breaks if certain
   |indirections are involved   |indirections are involved
   |since   |since
   |r6-1487-g1a4cd2cd7e7266b0   |r6-1487-g1a4cd2cd7e7266b0

--- Comment #5 from Jason Merrill  ---
Fixed for 9.4/10.  Does anyone care about fixing this in GCC 8?

[Bug tree-optimization/93435] [8/9 Regression] Hang with -O2 on innocuous looking code with GCC 8.3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Martin Jambor
:

https://gcc.gnu.org/g:b445ceec81ba3f4afad8c3ead1e58f14f1c2e146

commit r8-10163-gb445ceec81ba3f4afad8c3ead1e58f14f1c2e146
Author: Martin Jambor 
Date:   Fri Apr 3 22:01:17 2020 +0200

gcc-8 sra: Cap number of sub-access propagations with a param (PR 93435)

This is non-trivial but rather straightforward backport of
29f23ed79b60949fc60f6fdbbd931bd58090b241 from master.  See
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542390.html for
more information.

Bootstrapped and tested on gcc-8 branch.

2020-04-03  Martin Jambor  

PR tree-optimization/93435
* params.def (PARAM_SRA_MAX_PROPAGATIONS): New parameter.
* tree-sra.c (propagation_budget): New variable.
(budget_for_propagation_access): New function.
(propagate_subaccesses_across_link): Use it.
(propagate_all_subaccesses): Set up and destroy propagation_budget.
* doc/invoke.texi (sra-max-propagations): New.

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

[Bug c++/94477] ICE in tsubst_expr, at cp/pt.c:18181

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-04-03
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 48192
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48192=edit
gcc10-pr94477.patch

Untested fix.

[Bug c++/94476] NSDMI deferred parse

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|ASSIGNED|SUSPENDED

--- Comment #1 from Nathan Sidwell  ---
this caused by the as_base creation code copying the field_decl, deferred NSDMI
and all.  That doesn't affect trunk's behaviour so is harmless.  But we should
get it right.  Fixed on modules 2c6b4bd9ab0

Can push to trunk once stage 1 opens up.

PR c++/94476
gcc/cp/
* class.c (layout_class_type): Zap NSDMI of as_base fields.
gcc/testsuite/
* g++.dg/modules/nsdmi-2.C: New.

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[wdijkstr at arm dot com]

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

--- Comment #10 from Wilco  ---
(In reply to Christophe Lyon from comment #6)
> Created attachment 48184 [details]
> GCC passes dumps

So according to that, in 105t.vrp1 it removes the branch and unconditionally
calls abort:

Folding statement: _4 = _3 == 0B;
Matching expression match.pd:1737, gimple-match.c:708
Matching expression match.pd:1740, gimple-match.c:772
Matching expression match.pd:1747, gimple-match.c:826
Not folded
Folding statement: if (_5 == 0)
gimple_simplified to if (1 != 0)
Folded into: if (1 != 0)

Folding statement: return;
Not folded
Folding statement: __builtin_abort ();
Not folded
Removing dead stmt _5 = __builtin_constant_p (_4);


It doesn't make sense, these are the VRP ranges:

_1: short int * * VARYING
_2: short int * * VARYING
_3: short int * VARYING
_4: bool VARYING
_5: int [0, 0]
_10: struct a * VARYING

So somehow it decides that __builtin_constant_p (VARYING) == [0,0]???

[Bug c/94479] New: NetBSD: internal compiler error: in recompute_tree_invariant_for_addr_expr

[tk at giga dot or.at]

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

Bug ID: 94479
   Summary: NetBSD: internal compiler error: in
recompute_tree_invariant_for_addr_expr
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tk at giga dot or.at
  Target Milestone: ---

When compiling git-2.26.0 with gcc 8.3.0, 8.4.0, or 9.3.0 on NetBSD/amd64 with
-fstack-check, I see (output from 8.4.0):


builtin/rebase.c: In function 'cmd_rebase__interactive':
builtin/rebase.c:473:41: internal compiler error: in
recompute_tree_invariant_for_addr_expr, at tree.c:4487
   { OPTION_CALLBACK, 'k', "keep-empty", , NULL,
 ^~~~

I used creduce to get a minimal test case, save the following to rebase.i and
run:
# gcc -o rebase.o -c -fstack-check rebase.i

 begin 
int a;
struct b {
  char c;
  void *d;  
};
struct b e() {
  struct b f[] = {{}, "", f, a};
}
 end 

I tried running this in 8.3.0 and 9.3.0 on https://godbolt.org/ (where I had to
add -fpermissive for it to compile) but it doesn't seem to trigger the problem
there. So perhaps it's fine on Linux.

[Bug c++/91966] [8/9 Regression] pack expansion for Cartesian product breaks if certain indirections are involved since r6-1487-g1a4cd2cd7e7266b0

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:70ae61692245b5002f32454c8447655ad65a8535

commit r9-8450-g70ae61692245b5002f32454c8447655ad65a8535
Author: Jason Merrill 
Date:   Thu Apr 2 23:40:46 2020 -0400

c++: alias template and parameter packs (PR91966).

In this testcase, when we do a pack expansion of count_better_mins,
nums appears both in the definition of count_better_mins and as its
template
argument.  The intent is that we get a expansion over pairs of elements of
the pack, i.e. less<2,2>, less<2,7>, less<7,2>,   But if we substitute
into the definition of count_better_mins when parsing the template, we end
up with sum...>, which never gives us less<2,7>.  We could
deal with this by somehow marking up the use of 'nums' as an argument for
'num', but it's simpler to mark the alias as complex, so we need to
instantiate it later with all its arguments rather than replace it early
with its expansion.

gcc/cp/ChangeLog
2020-04-03  Jason Merrill  

PR c++/91966
* pt.c (complex_pack_expansion_r): New.
(complex_alias_template_p): Use it.

[Bug target/94467] [10 Regression] wrong code with -mavx and ssse3 builtins

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #8 from H.J. Lu  ---
Fixed for GCC 10.

[Bug target/94467] [10 Regression] wrong code with -mavx and ssse3 builtins

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:bbcdf9bb3fd04adc59f41e4e1ff6293c84cbecc4

commit r10-7545-gbbcdf9bb3fd04adc59f41e4e1ff6293c84cbecc4
Author: H.J. Lu 
Date:   Fri Apr 3 11:49:10 2020 -0700

x86: Mark scratch operand in ssse3_pshufbv8qi3 as earlyclobber

commit 16ed2601ad0a4aa82f11e9df86ea92183f94f979
Author: H.J. Lu 
Date:   Wed May 15 15:26:19 2019 +

i386: Emulate MMX pshufb with SSE version

has

+(define_insn_and_split "ssse3_pshufbv8qi3"
+  [(set (match_operand:V8QI 0 "register_operand" "=y,x,Yv")
+  (unspec:V8QI [(match_operand:V8QI 1 "register_operand" "0,0,Yv")
+   (match_operand:V8QI 2 "register_mmxmem_operand" "ym,x,Yv")]
+  UNSPEC_PSHUFB))
+   (clobber (match_scratch:V4SI 3 "=X,x,Yv"))]
   ^^^  There are earlyclobber.
+  "(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3"
+  "@
+   pshufb\t{%2, %0|%0, %2}
+   #
+   #"
+  "TARGET_MMX_WITH_SSE && reload_completed"
+  [(set (match_dup 3) (match_dup 5))
+   (set (match_dup 3)
+  (and:V4SI (match_dup 3) (match_dup 2)))
+   (set (match_dup 0)
+  (unspec:V16QI [(match_dup 1) (match_dup 4)] UNSPEC_PSHUFB))]

If input register operand 2 is dead after this insn, RA may choose it
as scratch operand.  Since it isn't marked as earlyclobber, operand 2
becomes unused after split and then it gets optimized out.  Mark scratch
operand as earlyclobber fixes the issue.

gcc/

PR target/94467
* config/i386/sse.md (ssse3_pshufbv8qi3): Mark scratch operand
as earlyclobber.

gcc/testsuite/

PR target/94467
* gcc.target/i386/pr94467-1.c: New test.
* gcc.target/i386/pr94467-2.c: Likewise.

[Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318

[cvs-commit at gcc dot gnu.org]

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

--- Comment #45 from CVS Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:b949f8e2acb49273b2f08ecaa3bc7128baaad850

commit r10-7544-gb949f8e2acb49273b2f08ecaa3bc7128baaad850
Author: Jeff Law 
Date:   Fri Apr 3 12:46:13 2020 -0600

Fix va-arg-22.c at -O1 on m32r.

PR rtl-optimization/92264
* config/m32r/m32r.c (m32r_output_block_move): Properly account for
post-increment addressing of source operands as well as residuals
when computing any adjustments to the input pointer.

[Bug target/94461] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_ia32_pmuludq() and -mno-sse2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/94461] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_ia32_pmuludq() and -mno-sse2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:a13d6ec867e750169af95649235a6681f410464a

commit r10-7543-ga13d6ec867e750169af95649235a6681f410464a
Author: Jakub Jelinek 
Date:   Fri Apr 3 20:33:17 2020 +0200

i386: Fix up handling of OPTION_MASK_ISA_MMX builtins [PR94461]

In https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00576.html the builtin
handling was changed so that OPTION_MASK_ISA_MMX | OPTION_MASK_ISA_SSE
etc. in i386-builtin.def means we require both mmx and sse, not just one of
those, and later on for other option combinations very similar rule has
been clarified, with a few exceptions that ix86_expand_builtin lists
(SSE | 3DNOW_A, SSE4_2 | CRC32 and FMA | FMA4 are one or the other).
The above mentioned patch also added OPTION_MASK_ISA_MMX to a few insns
that in the ISA documents are documented e.g. only requiring SSE2 or SSSE3
etc. CPUID, but because those builtins take or return V2SI or similar
MMX-ish arguments, we can't really support those builtins in functions that
have MMX disabled.
Now, during the TARGET_MMX_WITH_SSE changes,
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01479.html
and
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01084.html
actually changed this; it added | OPTION_MASK_ISA_SSE2 to builtins
that were formerly OPTION_MASK_ISA_MMX only, but didn't touch the builtins
that were already using OPTION_MASK_ISA_SSE2 | OPTION_MASK_ISA_MMX
for something different (both options must be enabled).
This causes e.g. ICE on the following testcase, because the builtins are
now enabled even with just -mmmx -mno-sse2, even when they (those changed
in
2017) require SSE2.
The following patch instead reverts the above two 2019-ish changes (except
for header/testsuite changes), and instead treats OPTION_MASK_ISA_MMX
requirement in bdesc/.isa specially, as being satisfied by either
TARGET_MMX (no changes really needed for that), or by TARGET_MMX_WITH_SSE.
This achieves what the two 2019-ish patches want to do, that the
OPTION_MASK_ISA_MMX only builtins are enabled not just with -mmmx, but also
with -m64 -msse2, and for the other builtins that require MMX and something
else will either require -mmmx and that some other ISA, or -m64 -msse2 and
that other ISA, but -mmmx will not enable builtins that need something more
than OPTION_MASK_ISA_MMX only.
The i386-builtins.c changes that aren't reversion of the two patches try to
make sure that in .isa we still record OPTION_MASK_ISA_MMX for builtins
that
have that requirement, so that it is in the end only ix86_expand_builtin
that decides if the builtin is ok or not and the rest of code just decides
if it is the right time to declare the builtin already or if it should be
deferred.

2020-04-03  Jakub Jelinek  

PR target/94461
* config/i386/i386-expand.c (ix86_expand_builtin): If
TARGET_MMX_WITH_SSE without TARGET_MMX and bisa contains
OPTION_MASK_ISA_MMX, clear OPTION_MASK_ISA_MMX and set
OPTION_MASK_ISA_SSE2 in bisa.  Revert 2019-05-17 and 2019-05-15
changes.
* config/i386/i386-builtins.c (def_builtin): If mask includes
OPTION_MASK_ISA_MMX and TARGET_MMX_WITH_SSE, consider it satisfied.
(ix86_add_new_builtins): For TARGET_64BIT, consider
OPTION_MASK_ISA_SSE2 enabled in isa as satisfying
OPTION_MASK_ISA_MMX
requirement.
(ix86_init_tm_builtins): If TARGET_MMX_WITH_SSE consider
OPTION_MASK_ISA_MMX as satisfied.
(bdesc_tm): Revert 2019-05-15 changes.
(ix86_init_mmx_sse_builtins): Likewise.
* config/i386/i386-builtin.def: Likewise.

* gcc.target/i386/pr94461.c: New test.

[Bug tree-optimization/93435] [8/9 Regression] Hang with -O2 on innocuous looking code with GCC 8.3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Martin Jambor
:

https://gcc.gnu.org/g:a1bb16994caed4dacf8c9ee1a33b177df140e9dc

commit r9-8449-ga1bb16994caed4dacf8c9ee1a33b177df140e9dc
Author: Martin Jambor 
Date:   Fri Apr 3 20:32:44 2020 +0200

gcc-9 sra: Cap number of sub-access propagations with a param (PR 93435)

This is non-trivial but rather straightforward backport of
29f23ed79b60949fc60f6fdbbd931bd58090b241 from master.  See
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542390.html for
more information.

2020-04-02  Martin Jambor  

PR tree-optimization/93435
* params.def (PARAM_SRA_MAX_PROPAGATIONS): New parameter.
* tree-sra.c (propagation_budget): New variable.
(budget_for_propagation_access): New function.
(propagate_subaccesses_across_link): Use it.
(propagate_all_subaccesses): Set up and destroy propagation_budget.
* doc/invoke.texi (sra-max-propagations): New.

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

[Bug c++/68394] [concepts] segfault in valid code

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #1 from Arseny Solokha  ---
Is it still an issue?

[Bug c++/94478] New: [10 Regression] ICE in comptypes, at cp/typeck.c:1486

[asolokha at gmx dot com]

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

Bug ID: 94478
   Summary: [10 Regression] ICE in comptypes, at cp/typeck.c:1486
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.1-alpha20200329 snapshot (g:60c254b279e8e8443b8ad26cc46b9e4084cff66c)
ICEs when compiling the following testcase, extracted from
test/CXX/class/class.compare/class.compare.default/p1.cpp from the clang 10.0.0
test suite, w/ -std=c++2a:

struct B {};
bool operator==(const B&, const B&) = default;

% g++-10.0.1 -std=c++2a -c kknpryrr.cpp
kknpryrr.cpp:2:39: internal compiler error: in comptypes, at cp/typeck.c:1486
2 | bool operator==(const B&, const B&) = default;
  |   ^~~
0x68caf4 comptypes(tree_node*, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/typeck.c:1486
0x965416 early_check_defaulted_comparison
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/method.c:1133
0x965416 defaultable_fn_check(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/method.c:2997
0x90e088 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/decl.c:7554
0x9b878b cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:20909
0x998b56 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:13731
0x9c3302 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:13430
0x9c3a9f cp_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:4731
0x9c3a9f c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:43944
0xadbadb c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/c-family/c-opts.c:1186

[Bug other/93641] Wrong strncmp and strncasecmp size arguments

[dominik.b.czarnota+bugzilla at gmail dot com]

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

--- Comment #8 from Dominik 'disconnect3d' Czarnota 
 ---
(In reply to Iain Sandoe from comment #7)
> if the invoke.texi entry does not need a change, then this should now be
> fixed, correct?

It would be a good practice to fix the invoke.texi case too, so the bug doesn't
get copied elsewhere, but anyway, the commits we can see above fixes all the
listed code cases.

I think the issue can then be marked as 'RESOLVED FIXED'.

Thanks!

[Bug c++/91966] [8/9/10 Regression] pack expansion for Cartesian product breaks if certain indirections are involved since r6-1487-g1a4cd2cd7e7266b0

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:bcafd8748cf9eb83a9e71bf67c4e2a7c5c8f513c

commit r10-7542-gbcafd8748cf9eb83a9e71bf67c4e2a7c5c8f513c
Author: Jason Merrill 
Date:   Thu Apr 2 23:40:46 2020 -0400

c++: alias template and parameter packs (PR91966).

In this testcase, when we do a pack expansion of count_better_mins,
nums appears both in the definition of count_better_mins and as its
template
argument.  The intent is that we get a expansion over pairs of elements of
the pack, i.e. less<2,2>, less<2,7>, less<7,2>,   But if we substitute
into the definition of count_better_mins when parsing the template, we end
up with sum...>, which never gives us less<2,7>.  We could
deal with this by somehow marking up the use of 'nums' as an argument for
'num', but it's simpler to mark the alias as complex, so we need to
instantiate it later with all its arguments rather than replace it early
with its expansion.

gcc/cp/ChangeLog
2020-04-03  Jason Merrill  

PR c++/91966
* pt.c (complex_pack_expansion_r): New.
(complex_alias_template_p): Use it.

[Bug target/94460] wrong code with __builtin_ia32_phsubw256() or __builtin_ia32_phsubd256()

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/94460] wrong code with __builtin_ia32_phsubw256() or __builtin_ia32_phsubd256()

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:b8020a5aafd02af1ccf99372d3d8052c40b59725

commit r10-7541-gb8020a5aafd02af1ccf99372d3d8052c40b59725
Author: Jakub Jelinek 
Date:   Fri Apr 3 19:44:42 2020 +0200

i386: Fix vph{add,subs?}[wd] 256-bit AVX2 RTL patterns [PR94460]

The following testcase is miscompiled, because the AVX2 patterns don't
describe correctly what the insn does.  E.g. vphaddd with %ymm* operands
(the second pattern) instruction as per:
   
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_hadd_epi32=2941
does { a0+a1, a2+a3, b0+b1, b2+b3, a4+a5, a6+a7, b4+b5, b6+b7 }
but our RTL pattern did
 { a0+a1, a2+a3, a4+a5, a6+a7, b0+b1, b2+b3, b4+b5, b6+b7 }
where the first and last 64 bits are the same and two middle 64 bits
swapped.
   
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_hadd_epi16=2939
similarly, insn does:
 { a0+a1, a2+a3, a4+a5, a6+a7, b0+b1, b2+b3, b4+b5, b6+b7,
   a8+a9, a10+a11, a12+a13, a14+a15, b8+b9, b10+b11, b12+b13, b14+b15 }
but RTL pattern did
 { a0+a1, a2+a3, a4+a5, a6+a7, a8+a9, a10+a11, a12+a13, a14+a15,
   b0+b1, b2+b3, b4+b5, b6+b7, b8+b9, b10+b11, b12+b13, b14+b15 }
again, first and last 64 bits are the same and the two middle 64 bits
swapped.

2020-04-03  Jakub Jelinek  

PR target/94460
* config/i386/sse.md (avx2_phwv16hi3,
avx2_phdv8si3): Fix up RTL pattern to do
second half of first lane from first lane of second operand and
first half of second lane from second lane of first operand.

* gcc.target/i386/avx2-pr94460.c: New test.

[Bug c++/94477] New: ICE in tsubst_expr, at cp/pt.c:18181

[asolokha at gmx dot com]

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

Bug ID: 94477
   Summary: ICE in tsubst_expr, at cp/pt.c:18181
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, openmp
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.1-alpha20200329 snapshot (g:60c254b279e8e8443b8ad26cc46b9e4084cff66c)
ICEs when compiling the following testcase, extracted from
test/OpenMP/parallel_master_taskloop_collapse_messages.cpp from the clang
10.0.0 test suite, w/ -fopenmp:

void
j3 ();

template 
void
xm ()
{
  #pragma omp parallel master
  j3 ();
}

void
s3 ()
{
   xm<0> ();
}

% g++-10.0.1 -fopenmp -c qnx2epwv.cpp
qnx2epwv.cpp: In instantiation of 'void xm() [with int  = 0]':
qnx2epwv.cpp:15:11:   required from here
qnx2epwv.cpp:8:11: internal compiler error: in tsubst_expr, at cp/pt.c:18181
8 |   #pragma omp parallel master
  |   ^~~
0x659d49 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/pt.c:18181
0x9eb63a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/pt.c:17985
0x9e97f6 instantiate_decl(tree_node*, bool, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/pt.c:25507
0xa1a4ab instantiate_pending_templates(int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/pt.c:25623
0x91fbd3 c_parse_final_cleanups()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/decl2.c:4874

[Bug c++/94476] NSDMI deferred parse

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-04-03
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org

[Bug c++/94476] New: NSDMI deferred parse

[nathan at gcc dot gnu.org]

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

Bug ID: 94476
   Summary: NSDMI deferred parse
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

This code, extracted from  leaves an unparsed NSDMI for _M_type. 
That kills the module streamer, which doesn't expect to meet such things. 
Bizarrely, removing either the 'signed char' underlying type, the ctor
declaration, or the _M_path field removes the problem.  Not sure if the
non-module compiler copes?

enum class file_type : signed char { none = 0 };

class directory_entry
{
public:
  directory_entry(int);

  int _M_path;

  file_type _M_type = file_type::none;
};

[Bug c++/94475] [9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in element_mode, at tree.c:13813

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[10 Regression] ICE: tree   |[9/10 Regression] ICE: tree
   |check: expected class   |check: expected class
   |'type', have 'exceptional'  |'type', have 'exceptional'
   |(error_mark) in |(error_mark) in
   |element_mode, at|element_mode, at
   |tree.c:13813|tree.c:13813
   Target Milestone|--- |9.4

--- Comment #2 from Marek Polacek  ---
Started with r9-4974-gdfd7fdca2ac17d8b823a16700525824ca312ade0.

[Bug c++/94475] [10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in element_mode, at tree.c:13813

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-04-03

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

[Bug tree-optimization/90356] Missed optimization for variables initialized to 0.0

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #8 from Arseny Solokha  ---
Is there some further work pending for this PR?

[Bug c++/94475] New: [10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in element_mode, at tree.c:13813

[asolokha at gmx dot com]

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

Bug ID: 94475
   Summary: [10 Regression] ICE: tree check: expected class
'type', have 'exceptional' (error_mark) in
element_mode, at tree.c:13813
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.1-alpha20200329 snapshot (g:60c254b279e8e8443b8ad26cc46b9e4084cff66c)
ICEs when compiling the following testcase, extracted from
test/std/numerics/bit/bitops.rot/rotr.pass.cpp from the libcxx 10.0.0 test
suite:

unsigned char
sr ()
{
  const unsigned char xz = EI;

  return xz - (xz >> 1);
}

% g++-10.0.1 -c ayrzmymn.cpp
ayrzmymn.cpp: In function 'unsigned char sr()':
ayrzmymn.cpp:4:28: error: 'EI' was not declared in this scope
4 |   const unsigned char xz = EI;
  |^~
ayrzmymn.cpp:6:23: internal compiler error: tree check: expected class 'type',
have 'exceptional' (error_mark) in element_mode, at tree.c:13813
6 |   return xz - (xz >> 1);
  |   ^
0x7bb6b4 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/tree.c:9787
0x7c101b tree_class_check(tree_node const*, tree_code_class, char const*, int,
char const*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/tree.h:3657
0x7c101b element_mode(tree_node const*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/tree.c:13813
0xcaacef fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/fold-const.c:10795
0xcb3749 fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/fold-const.c:13157
0xb95872 do_narrow
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/convert.c:439
0xb98936 convert_to_integer_1
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/convert.c:844
0xb99848 convert_to_integer_maybe_fold(tree_node*, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/convert.c:980
0x8d735d ocp_convert(tree_node*, tree_node*, int, int, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/cvt.c:874
0x8d007d cp_fold
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/cp-gimplify.c:2494
0x8d110c cp_fold_maybe_rvalue(tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/cp-gimplify.c:2330
0xa79958 maybe_warn_about_returning_address_of_local
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/typeck.c:9480
0xa79958 check_return_expr(tree_node*, bool*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/typeck.c:10089
0xa2c2bf finish_return_stmt(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/semantics.c:955
0x99b0d0 cp_parser_jump_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:13111
0x99b0d0 cp_parser_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:11362
0x99c4d8 cp_parser_statement_seq_opt
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:11835
0x99c5b8 cp_parser_compound_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:11785
0x9b4855 cp_parser_function_body
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:23062
0x9b4855 cp_parser_ctor_initializer_opt_and_function_body
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200329/work/gcc-10-20200329/gcc/cp/parser.c:23113

[Bug ipa/93621] [10 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.c:1443 since r10-5567

[jamborm at gcc dot gnu.org]

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

--- Comment #16 from Martin Jambor  ---
The following workaround works for the testcase but would need to be
generalized for a chain of former_decl_of's to be universal, I'm afraid:

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 6b780f80eb3..241b996151a 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -1467,7 +1467,8 @@ cgraph_edge::redirect_call_stmt_to_callee (cgraph_edge
*e)


   if (e->indirect_unknown_callee
-  || decl == e->callee->decl)
+  || decl == e->callee->decl
+  || decl == e->callee->former_clone_of)
 return e->call_stmt;

   if (flag_checking && decl)
diff --git a/gcc/ipa-inline-transform.c b/gcc/ipa-inline-transform.c
index eed992d314d..a6675768552 100644
--- a/gcc/ipa-inline-transform.c
+++ b/gcc/ipa-inline-transform.c
@@ -588,6 +588,7 @@ save_inline_function_body (struct cgraph_node *node)
   first_clone->next_sibling_clone = NULL;
   gcc_assert (!first_clone->prev_sibling_clone);
 }
+  first_clone->former_clone_of = node->decl;
   first_clone->clone_of = NULL;

   /* Now node in question has no clones.  */

[Bug debug/94450] lto abstract variable emitted as concrete decl

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu.org

--- Comment #13 from Tom de Vries  ---
(In reply to rguent...@suse.de from comment #11)

> Note that as I read the DWARF spec changing the
> early CUs to DW_TAG_partial_unit and then again importing those
> (the spec suggests you need to import DW_TAG_partial_units) would
> not reflect documented semantics either.

It's not my understanding from the spec that DW_TAG_partial_units are required
to be imported. AFAIU, it's just that in all the use-cases there using
DW_TAG_partial_unit, an import happens to be required.

OK, so lets look at the use cases described in the spec at E.1.

I. classic dwz: factor out into partial unit, add imports:
...
DW_TAG_compile_unit
  DW_AT_name cu1
L1:   DIEx
  DIEy
DW_AT_type L1
DW_TAG_compile_unit
  DW_AT_name cu2
L2:   DIEx
  DIEz
DW_AT_type L2

->

L3: DW_TAG_partial_unit
L4:   DIEx
DW_TAG_compile_unit
  DW_TAG_imported_unit
DW_AT_import L3
  DW_AT_name cu1
  DIEy
DW_AT_type L4
DW_TAG_compile_unit
  DW_TAG_imported_unit
DW_AT_import L3
  DW_AT_name cu2
  DIEz
DW_AT_type L4
...

II. dwz --devel-uni-lang --devel-gen-cu: factor out into DW_TAG_compile_unit,
no imports, exploit global namespace:
...
DW_TAG_compile_unit
  DW_AT_name cu1
L1:   DIEx
  DIEy
DW_AT_type L1
DW_TAG_compile_unit
  DW_AT_name cu2
L2:   DIEx
  DIEz
DW_AT_type L2

->

DW_TAG_compile_unit
L4:   DIEx
DW_TAG_compile_unit
  DW_AT_name cu1
  DIEy
DW_AT_type L4
DW_TAG_compile_unit
  DW_AT_name cu2
  DIEz
DW_AT_type L4
...

III. #include in namespace:
...
DW_TAG_compile_unit
  DW_AT_name cu1
  DW_TAG_namespace bla1
L1: DIEx
DIEy
  DW_AT_type L1
DW_TAG_compile_unit
  DW_AT_name cu2
  DW_TAG_namespace bla2
L2: DIEx
DIEz
  DW_AT_type L2

->

L3: DW_TAG_partial_unit
L4:   DIEx
DW_TAG_compile_unit
  DW_AT_name cu1
  DW_TAG_namespace bla1
DW_TAG_imported_unit
  DW_AT_import L3
DIEy
  DW_AT_type L4
DW_TAG_compile_unit
  DW_AT_name cu2
  DW_TAG_namespace bla2
DW_TAG_imported_unit
  DW_AT_import L3
DIEz
  DW_AT_type L4
...

So indeed, in all cases where DW_TAG_partial_unit is used, we use an import,
but that's because it's applicable to the transformation, and we're just doing
an entirely different transformation here:
...
DW_TAG_compile_unit
  DW_AT_name cu1
  DW_TAG_variable
DW_AT_name var1
DW_AT_location

->

DW_TAG_partial_unit
L1:   DW_TAG_variable
DW_AT_name var1
DW_TAG_compile_unit
  DW_AT_name cu1
  DW_TAG_variable
DW_AT_abstract_origin L1
DW_AT_location
...
We fabricate a new abstract DW_TAG_variable DIE out of thin air, then try to
hide that fact by placing it in a DW_TAG_partial_unit, much like is done at
III. Only in contrast to III, we don't want to reintroduce it in another
context, we want it to keep hidden, so there's no import.

[Bug target/94467] [10 Regression] wrong code with -mavx and ssse3 builtins

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
The bug was introduced by r10-393:

commit 16ed2601ad0a4aa82f11e9df86ea92183f94f979
Author: H.J. Lu 
Date:   Wed May 15 15:26:19 2019 +

i386: Emulate MMX pshufb with SSE version

Emulate MMX version of pshufb with SSE version by masking out the bit 3
of the shuffle control byte.  Only SSE register source operand is allowed.

PR target/89021
* config/i386/sse.md (ssse3_pshufbv8qi3): Changed to
define_insn_and_split.  Also allow TARGET_MMX_WITH_SSE.  Add
SSE emulation.

+(define_insn_and_split "ssse3_pshufbv8qi3"
+  [(set (match_operand:V8QI 0 "register_operand" "=y,x,Yv")
+  (unspec:V8QI [(match_operand:V8QI 1 "register_operand" "0,0,Yv")
+   (match_operand:V8QI 2 "register_mmxmem_operand" "ym,x,Yv")]
+  UNSPEC_PSHUFB))
+   (clobber (match_scratch:V4SI 3 "=X,x,Yv"))]  <<< This is an earlyclobber
operand.
+  "(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3"
+  "@
+   pshufb\t{%2, %0|%0, %2}
+   #
+   #"
+  "TARGET_MMX_WITH_SSE && reload_completed"
+  [(set (match_dup 3) (match_dup 5))
+   (set (match_dup 3)
+  (and:V4SI (match_dup 3) (match_dup 2)))
+   (set (match_dup 0)
+  (unspec:V16QI [(match_dup 1) (match_dup 4)] UNSPEC_PSHUFB))]

[Bug debug/94459] Missing c++ debug information for 'auto&' return type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-04-03
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 48191
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48191=edit
gcc10-pr94459.patch

Full patch I'll be testing.  Related to PR53756.

[Bug debug/94474] New: Incorrect DWARF range information for inlined function

[andrew.burgess at embecosm dot com]

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

Bug ID: 94474
   Summary: Incorrect DWARF range information for inlined function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew.burgess at embecosm dot com
  Target Milestone: ---

Created attachment 48190
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48190=edit
Bug reproducer.

Download the attached file, then:

  tar -xf gcc-ranges-bugs.tar.xz
  cd gcc-ranges-bugs
  make

The problem is described in the included README file, the contents of which I
will include below.

--

* Overview

  + The issues are present in all compilations, but v3 uses what I think
might be the "best" debug flags.

  + Tested on GCC 9.2.0 and GCC from master branch (2020-02-05).

  + These bugs were encountered when trying to improve is-stmt support
within GDB.

  + This bug report has a bit of history.  Originally there was a GCC
patch here:
   https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html
and a reply here:
   https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html

This led to a GDB patch here:
   https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html
which in turn led to a different GDB patch (adding is-stmt
support), here:
   https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01459.html

  + As suggested in the 2019-10 GCC follow up, I have tried compiling
with =-gno-statement-frontiers -gno-variable-location-views=, and
currently the debug experience is better, but if I hack GDB to
"fix" the bugs below while reading in the DWARF then I get just as
good a debug experience with GCC's default flags.

  + In the included Makefile I build the test 4 times, version 3 is
possibly the most interesting, as this explicitly switches on what
I think are the "best" features for location tracking.  However,
the same bugs are present in v1 and v2 (see Makefile for flag
differences).  Version 4 compiles with the =-gno-*= flags above, and
is included for reference.  As I've already said, these bugs are
not present there.

  + All of the analysis below references the output files =test-v3=,
=dissas-v3=, =dwarf-v3=, and =lines-v3=.

* Issue 1

  + The function =tree_check= is inlined 3 times.

  + The first =DW_TAG_inlined_subroutine= looks like this:

#+BEGIN_EXAMPLE
   <2><8db>: Abbrev Number: 38 (DW_TAG_inlined_subroutine)
  <8dc>   DW_AT_abstract_origin: <0x9cc>
  <8e0>   DW_AT_entry_pc: 0x400545
  <8e8>   Unknown AT value: 2138: 3
  <8e9>   DW_AT_ranges  : 0x30
  <8ed>   DW_AT_call_file   : 1
  <8ee>   DW_AT_call_line   : 52
  <8ef>   DW_AT_call_column : 10
  <8f0>   DW_AT_sibling : <0x92f>
#+END_EXAMPLE

This references some =.debug_ranges= data that looks like this:

#+BEGIN_EXAMPLE
  0030 00400545 00400545 (start == end)
  0030 00400549 00400553
  0030 00400430 00400435
  0030 
#+END_EXAMPLE

  + Notice that =0x400545= is /not/ part of the range for the inlined
function as the range ==0x400545= to =0x400545= is an empty range,
containing no bytes (see DWARF-4, 2.17.3: Non-Contiguous Address
Ranges).

  + The =DW_AT_entry_pc= points to =0x400545=.

  + DWARF-4, 2.18: Entry Address, says:

#+BEGIN_QUOTE
  Any debugging information entry describing an entity that has a
  range of code addresses, which includes compilation units,
  module initialization, subroutines, ordinary blocks, try/catch
  blocks, and the like, may have a DW_AT_entry_pc attribute to
  indicate the first executable instruction within that range of
  addresses.
#+END_QUOTE

I believe this means that the =DW_AT_entry_pc= should reference an
address that is within the range of addresses associated with the
inlined subroutine.

  + The particular problem this causes for GDB is that the decoded
line table (see =lines-v3=) includes:

#+BEGIN_EXAMPLE
  ./step-and-next-inline.h:[++]
  step-and-next-inline.h320x400545 
 3   x
  step-and-next-inline.h340x400545 
 4   x
#+END_EXAMPLE

GDB then stops for these lines (that are part of the inlined
function, at an address that is not part of the inlined functions
address range.

  + An idea solution for GDB would be to include the address =0x400545=
within the address range of the inlined function, and when I
earlier said I hacked GDB to "fix" this bug, this is what I did,
extending the range entry starting at =0x400549= to instead start at
=0x400545=.

* Issue 2

  + Looking at the other end of the 

[Bug c/94473] internal compiler error: verify_ssa failed

[florin.iucha at amd dot com]

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

Florin Iucha  changed:

   What|Removed |Added

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

--- Comment #2 from Florin Iucha  ---
Confirmed. 51ecad3c0327418c6e20ef47c6c5a8015bb99b2c builds correctly.

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

[Bug tree-optimization/94443] [10 Regression] 510.parest_r and 526.blender_r ICE: verify_ssa failed since r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad

[florin.iucha at amd dot com]

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

Florin Iucha  changed:

   What|Removed |Added

 CC||florin.iucha at amd dot com

--- Comment #18 from Florin Iucha  ---
*** Bug 94473 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/94468] [10 Regression] ICE in remove_useless_values, at cselib.c:735 since r10-7515-g2c0fa3ecf70d199a

[dcb314 at hotmail dot com]

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

--- Comment #5 from David Binderman  ---
I had a quick look at the untested fix and there seemed to be
about six copies of pretty much the same expression.

Would it be worthwhile to invent a new macro or small function
and call it from six different places ?

[Bug rtl-optimization/92989] [10 Regression] The mips-mti-linux-gnu fails to build after r276327

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

[Bug rtl-optimization/92989] [10 Regression] The mips-mti-linux-gnu fails to build after r276327

[rsandifo at gcc dot gnu.org]

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

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
(In reply to Jakub Jelinek from comment #9)
> Richard, could you please have a look again?

OK, I'll try to get to this early next week.

[Bug c/94473] internal compiler error: verify_ssa failed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-04-03
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Martin Liška  ---
I guess it's dup of PR94443. Can you please test current master (which should
be fixed)?

[Bug c/94473] New: internal compiler error: verify_ssa failed

[florin.iucha at amd dot com]

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

Bug ID: 94473
   Summary: internal compiler error: verify_ssa failed
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: florin.iucha at amd dot com
  Target Milestone: ---

This is a regression between these two versions:

gcc version 10.0.1 20200324 (experimental) (GCC) --- OK
gcc version 10.0.1 20200402 (experimental) (GCC) ---
25839b6af9f10b3227719db35b9e9e38320341e7 fails

It is likely the version that passed was
b599bf9d6d1e180d350b71e51e08a66a1bb1546a but I am not 100% certain.

How to reproduce:

$ git clone https://github.com/glennrp/libpng
$ cd libpng
$ git checkout v1.6.37
$ CC=/opt/gcc10-for-tng/bin/gcc-10 CXX=/opt/gcc10-for-tng/bin/g++-10
./configure
$ make
$ /opt/gcc10-for-tng/bin/gcc-10 -DPNG_INTEL_SSE_OPT=1 -I. -O3 -DNDEBUG -o
pngrutil.opt.o -c pngrutil.c
pngrutil.c: In function 'png_combine_row':
pngrutil.c:3200:1: error: missing definition
 3200 | png_combine_row(png_const_structrp png_ptr, png_bytep dp, int display)
  | ^~~
for SSA_NAME: _350 in statement:
dp32_155 = _350;
during GIMPLE pass: vect
pngrutil.c:3200:1: internal compiler error: verify_ssa failed
0xff15f2 verify_ssa(bool, bool)
../../gcc/gcc/tree-ssa.c:1208
0xd0abb5 execute_function_todo
../../gcc/gcc/passes.c:1992
0xd0b8fc do_per_function
../../gcc/gcc/passes.c:1640
0xd0b8fc execute_todo
../../gcc/gcc/passes.c:2039
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
(In reply to Jan Hubicka from comment #8)
> Do we have compile farm machine where this can be reproduced?

I guess we don't have any.

[Bug c++/93211] equivalence of dependent function calls doesn't check if the call is eligible for ADL

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90711
   Target Milestone|--- |9.4

--- Comment #2 from Patrick Palka  ---
Fixed is 9.4 and 10 by the fix for PR90711.

[Bug c++/90711] [9/10 Regression] Failing SFINAE from unrelated struct since r9-6794

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:51ecad3c0327418c6e20ef47c6c5a8015bb99b2c

commit r10-7540-g51ecad3c0327418c6e20ef47c6c5a8015bb99b2c
Author: Patrick Palka 
Date:   Fri Apr 3 11:21:56 2020 -0400

c++: Add test for PR c++/93211

The fix for PR c++/90711 also fixed this PR.

gcc/testsuite/ChangeLog:

PR c++/93211
PR c++/90711
* g++.dg/template/koenig11.C: New test.

[Bug c++/93211] equivalence of dependent function calls doesn't check if the call is eligible for ADL

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:51ecad3c0327418c6e20ef47c6c5a8015bb99b2c

commit r10-7540-g51ecad3c0327418c6e20ef47c6c5a8015bb99b2c
Author: Patrick Palka 
Date:   Fri Apr 3 11:21:56 2020 -0400

c++: Add test for PR c++/93211

The fix for PR c++/90711 also fixed this PR.

gcc/testsuite/ChangeLog:

PR c++/93211
PR c++/90711
* g++.dg/template/koenig11.C: New test.

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
Do we have compile farm machine where this can be reproduced?

[Bug other/89863] [meta-bug] Issues that static analyzers (cppcheck, clang-static-analyzer) find that gcc misses

[sripar01 at gcc dot gnu.org]

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

Bug 94317 Summary: gcc/config/arm/arm_mve.h:13907: strange assignment ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94317

   What|Removed |Added

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

[Bug target/94317] gcc/config/arm/arm_mve.h:13907: strange assignment ?

[sripar01 at gcc dot gnu.org]

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

SRINATH PARVATHANENI  changed:

   What|Removed |Added

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

--- Comment #10 from SRINATH PARVATHANENI  ---
Committed to trunk.

[Bug rtl-optimization/94468] [10 Regression] ICE in remove_useless_values, at cselib.c:735 since r10-7515-g2c0fa3ecf70d199a

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 48189
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48189=edit
gcc10-pr94468.patch

Untested fix.

[Bug libstdc++/93960] std::to_address doesn't work with past-the-end Debug Mode iterators

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for 8.5 and 9.4

[Bug libstdc++/93960] std::to_address doesn't work with past-the-end Debug Mode iterators

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:afae9879c28a2797c49bf2da51415da70cdd2b83

commit r8-10162-gafae9879c28a2797c49bf2da51415da70cdd2b83
Author: Jonathan Wakely 
Date:   Fri Apr 3 12:00:07 2020 +0100

libstdc++: Fix std::to_address for debug iterators (PR 93960)

It should be valid to use std::to_address on a past-the-end iterator,
but the debug mode iterators do a check for dereferenceable in their
operator->(). That check is generally useful, so rather than remove it
this changes std::__to_address to identify a debug mode iterator and
use base().operator->() to skip the check.

Backport from mainline
2020-04-03  Jonathan Wakely  

PR libstdc++/93960
* include/bits/ptr_traits.h (__to_address): Add special case for
debug
iterators, to avoid dereferenceable check.
* testsuite/20_util/to_address/1_neg.cc: Adjust dg-error line
number.
* testsuite/20_util/to_address/debug.cc: New test.

[Bug gcov-profile/94472] New: 400.perlbench is slower when compiled at -O2 with both PGO and LTO on AMD Zen CPUs

[jamborm at gcc dot gnu.org]

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

Bug ID: 94472
   Summary: 400.perlbench is slower when compiled at -O2 with both
PGO and LTO on AMD Zen CPUs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

400.perlbench is slower when compiled at -O2 (and generic march/mtune)
with both PGO and LTO when compiled with master (26b3e568a60) than
when built with GCC 9, on Zen2 by 13% and on Zen1 by 7%.  The
performance is comparable on Intel Cascade Lake server CPU.

I attempted bisecting the problems on the Zen2 CPU but was only
partially successful because a lot of the slowdown seemed to have
happened gradually.  The first bigger slowdown - almost 4% - came
with:

  562d1e9556777988ae46c5d1357af2636bc272ea is the first bad commit
  commit 562d1e9556777988ae46c5d1357af2636bc272ea
  Author: Jan Hubicka 
  Date:   Wed Oct 2 16:01:47 2019 +

cif-code.def (MAX_INLINE_INSNS_SINGLE_O2_LIMIT, [...]): New.


* cif-code.def (MAX_INLINE_INSNS_SINGLE_O2_LIMIT,
MAX_INLINE_INSNS_AUTO_O2_LIMIT): New.

  ...
From-SVN: r276469

About the same performance loss was then introduced by:

commit 2925cad2151842daa387950e62d989090e47c91d
Author: Jan Hubicka 
Date:   Thu Oct 3 17:08:21 2019 +0200

params.def (PARAM_INLINE_HEURISTICS_HINT_PERCENT, [...]): New.

* params.def (PARAM_INLINE_HEURISTICS_HINT_PERCENT,
PARAM_INLINE_HEURISTICS_HINT_PERCENT_O2): New.
* doc/invoke.texi (inline-heuristics-hint-percent,
inline-heuristics-hint-percent-O2): Document.
* tree-inline.c (inline_insns_single, inline_insns_auto): Add new
hint attribute.
(can_inline_edge_by_limits_p): Use it.


And finally throughout March the benchmark is quite jumpy but finally
ended again ended up about 5% slower than at the beginning of the
month.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug fortran/94471] Calling a function pointer member of a polymorphic derived type returning a pointer produces an ICE (internal compiler error).

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-04-03
 Status|UNCONFIRMED |NEW
 CC||janus at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Confirmed, started with r7-4526-gd809e15a19e63493 before that the code was
rejected:

 procedure(packageable_procedure), pointer :: proc
 1
Error: CLASS variable ‘proc’ at (1) must be dummy, allocatable or pointer

[Bug target/94396] [8/9/10 Regression] fp16 feature bits not passed on to assembler from Armv8.4-a and up.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:53161358180fdc2c2c21c8f46bbdd339a1fbb8ae

commit r10-7537-g53161358180fdc2c2c21c8f46bbdd339a1fbb8ae
Author: Tamar Christina 
Date:   Fri Apr 3 15:18:35 2020 +0100

AArch64: Fix options canonicalization for assembler

It is currently impossible to use fp16 on any architecture higher than
Armv8.3-a
due to a bug in options canonization.  This bug results in the fp16 flag
not
being emitted in the assembly when it should have been.

This is caused by a complicated architectural requirement at Armv8.4-a.  On
Armv8.2-a and Armv8.3-a fp16fml is an optional extension and turning it on
turns
on both fp and fp16.  However starting with Armv8.4-a fp16fml is mandatory
if
fp16 is available, otherwise it's optional.

In short this means that to enable fp16fml the smallest option that needs
to
passed to the assembler is Armv8.4-a+fp16.

The fix in this patch takes into account that an option may be on by
default in
an architecture, but that not all the bits required to use it are on by
default
in an architecture.  In such cases the difference between the two are still
emitted to the assembler.

gcc/ChangeLog:

PR target/94396
* common/config/aarch64/aarch64-common.c
(aarch64_get_extension_string_for_isa_flags): Handle default flags.

gcc/testsuite/ChangeLog:

PR target/94396
* gcc.target/aarch64/options_set_11.c: New test.
* gcc.target/aarch64/options_set_12.c: New test.
* gcc.target/aarch64/options_set_13.c: New test.
* gcc.target/aarch64/options_set_14.c: New test.
* gcc.target/aarch64/options_set_15.c: New test.
* gcc.target/aarch64/options_set_16.c: New test.
* gcc.target/aarch64/options_set_17.c: New test.
* gcc.target/aarch64/options_set_18.c: New test.
* gcc.target/aarch64/options_set_19.c: New test.
* gcc.target/aarch64/options_set_20.c: New test.
* gcc.target/aarch64/options_set_21.c: New test.
* gcc.target/aarch64/options_set_22.c: New test.
* gcc.target/aarch64/options_set_23.c: New test.
* gcc.target/aarch64/options_set_24.c: New test.
* gcc.target/aarch64/options_set_25.c: New test.
* gcc.target/aarch64/options_set_26.c: New test.

[Bug fortran/94471] New: Calling a function pointer member of a polymorphic derived type returning a pointer produces an ICE (internal compiler error).

[lockywolf at gmail dot com]

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

Bug ID: 94471
   Summary: Calling a function pointer member of a polymorphic
derived type returning a pointer produces an ICE
(internal compiler error).
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lockywolf at gmail dot com
  Target Milestone: ---

This is the code:

program main

  type, abstract :: scheme_object
  end type scheme_object
  type, extends(scheme_object) :: scheme_primitive_procedure
 procedure(packageable_procedure), pointer, nopass :: proc_pointer
  end type scheme_primitive_procedure

  class(scheme_object), pointer :: exp

  abstract interface
 function packageable_procedure( argl, env ) result( retval )
   import :: scheme_object
   class(scheme_object), pointer :: retval
   class(scheme_object), pointer :: argl
   class(scheme_object), pointer :: env
 end function packageable_procedure

  end interface


contains
  function low_level_read( arg ) result( retval )
class(scheme_object), pointer :: retval
class(scheme_object), pointer :: arg

  end function low_level_read

  subroutine main_loop()
procedure(packageable_procedure), pointer :: proc
class(scheme_object), pointer :: retval
exp => low_level_read( exp )
call ll_setup_global_environment()
select type( proc_holder => low_level_read(exp) )
type is (scheme_primitive_procedure)
   proc => proc_holder%proc_pointer
   retval => proc( exp, exp )
class default
   error stop "primitive procedure not a procedure"
end select

  end subroutine main_loop
end program

produces:

gfortran --save-temps -v -Wall -Wextra 2020-04-03-weird-gfortran-bug-2.f90
Driving: gfortran --save-temps -v -Wall -Wextra
2020-04-03-weird-gfortran-bug-2.f90 -l gfortran -l m -shared-libgcc
Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/9.3.0/specs
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-slackware-linux/9.3.0/lto-wrapper
Target: x86_64-slackware-linux
Configured with: ../gcc-9.3.0/configure --prefix=/usr --libdir=/usr/lib64
--mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap
--enable-languages=ada,brig,c,c++,d,fortran,go,lto,objc,obj-c++
--enable-threads=posix --enable-checking=release --enable-objc-gc
--with-system-zlib --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=new
--disable-libstdcxx-pch --disable-libunwind-exceptions --enable-__cxa_atexit
--disable-libssp --enable-gnu-unique-object --enable-plugin --enable-lto
--disable-install-libiberty --enable-gnu-indirect-function
--with-linker-hash-style=gnu --with-gnu-ld --with-isl --verbose
--with-arch-directory=amd64 --disable-gtktest --disable-werror
--enable-clocale=gnu --enable-multilib --target=x86_64-slackware-linux
--build=x86_64-slackware-linux --host=x86_64-slackware-linux
Thread model: posix
gcc version 9.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-save-temps' '-v' '-Wall' '-Wextra' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-slackware-linux/9.3.0/f951
2020-04-03-weird-gfortran-bug-2.f90 -quiet -dumpbase
2020-04-03-weird-gfortran-bug-2.f90 -mtune=generic -march=x86-64 -auxbase
2020-04-03-weird-gfortran-bug-2 -Wall -Wextra -version -fintrinsic-modules-path
/usr/lib64/gcc/x86_64-slackware-linux/9.3.0/finclude
-fpre-include=/usr/include/finclude/math-vector-fortran.h -o
2020-04-03-weird-gfortran-bug-2.s
GNU Fortran (GCC) version 9.3.0 (x86_64-slackware-linux)
compiled by GNU C version 9.3.0, GMP version 6.2.0, MPFR version 4.0.2,
MPC version 1.1.0, isl version isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 9.3.0 (x86_64-slackware-linux)
compiled by GNU C version 9.3.0, GMP version 6.2.0, MPFR version 4.0.2,
MPC version 1.1.0, isl version isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
2020-04-03-weird-gfortran-bug-2.f90:37:0:

   37 |proc => proc_holder%proc_pointer
  | 
internal compiler error: in gfc_conv_component_ref, at
fortran/trans-expr.c:2445
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The .i file has not been generated.
The .s file only contains a single line:
.file   "2020-04-03-weird-gfortran-bug-2.f90"

[Bug target/94461] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_ia32_pmuludq() and -mno-sse2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #48182|0   |1
is obsolete||
  Attachment #48187|0   |1
is obsolete||
 Status|NEW |ASSIGNED
   Assignee|hjl.tools at gmail dot com |jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
Created attachment 48188
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48188=edit
gcc10-pr94461.patch

Full patch (though tested only with i386.exp so far).

[Bug middle-end/94465] [10 Regression] fnsplit dump file ICEs

[tnfchris at gcc dot gnu.org]

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

--- Comment #4 from Tamar Christina  ---
Thanks Richard!

[Bug c++/94470] [8/9/10 Regression] Constexpr variable initialization with self-modifying constructor incorrectly rejected since r7-6728

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Priority|P3  |P2
   Keywords|ice-on-valid-code   |rejects-valid

[Bug c++/94470] [8/9/10 Regression] Constexpr variable initialization with self-modifying constructor incorrectly rejected since r7-6728

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|10.0|8.5

[Bug target/94461] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_ia32_pmuludq() and -mno-sse2

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Created attachment 48187
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48187=edit
gcc10-pr94461-wip2.patch

Here is what I have right now and it passes make check-{gcc,c++-all}
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} i386.exp'.  Just writing
ChangeLog now.

[Bug c++/94470] [8/9/10 Regression] Constexpr variable initialization with self-modifying constructor incorrectly rejected since r7-6728

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to fail||10.0, 7.5.0, 8.4.0, 9.3.0
 Ever confirmed|0   |1
   Last reconfirmed||2020-04-03
  Known to work||6.5.0
 CC||jason at gcc dot gnu.org
   Keywords||ice-on-valid-code
   Target Milestone|--- |10.0
Summary|Constexpr variable  |[8/9/10 Regression]
   |initialization with |Constexpr variable
   |self-modifying constructor  |initialization with
   |incorrectly rejected since  |self-modifying constructor
   |r7-6728 |incorrectly rejected since
   ||r7-6728

[Bug target/94461] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_ia32_pmuludq() and -mno-sse2

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
Created attachment 48186
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48186=edit
An incomplete patch

Jakub, this is an incomplete patch with 2 testcases.  Can you take it over?
I will fix PR 94467.  Thanks.

[Bug c++/94470] New: Constexpr variable initialization with self-modifying constructor incorrectly rejected since r7-6728

[ppalka at gcc dot gnu.org]

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

Bug ID: 94470
   Summary: Constexpr variable initialization with self-modifying
constructor incorrectly rejected since r7-6728
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

$ cat testcase.C
struct X
{
  int b = 0;
  int c = ((this->b=1), 1);
};

constexpr X o = { };

static_assert(o.b == 1);

$ g++ -std=c++17 testcase.C
testcase.C:7:19: error: modification of ‘o’ is not a constant expression
 constexpr X o = { };
   ^
testcase.C:9:19: error: non-constant condition for static assertion
 static_assert(o.b == 1);
   ^~~~

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[clyon at gcc dot gnu.org]

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

--- Comment #7 from Christophe Lyon  ---
Created attachment 48185
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48185=edit
qemu execution trace

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[clyon at gcc dot gnu.org]

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

--- Comment #6 from Christophe Lyon  ---
Created attachment 48184
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48184=edit
GCC passes dumps

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[clyon at gcc dot gnu.org]

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

--- Comment #5 from Christophe Lyon  ---
Created attachment 48183
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48183=edit
executable asm from objdump

[Bug middle-end/94465] [10 Regression] fnsplit dump file ICEs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/94465] [10 Regression] fnsplit dump file ICEs

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:ef6631051d4bb9519f3f0dd5f3b3eadbd67bc10a

commit r10-7536-gef6631051d4bb9519f3f0dd5f3b3eadbd67bc10a
Author: Richard Biener 
Date:   Fri Apr 3 13:46:49 2020 +0200

middle-end/94465 - handle released SSA names in array_ref_low_bound

array_ref_low_bound is used in dumping ARRAY_REFs which in turn
is called when basic blocks are deleted.  cleanup_control_flow_pre
consciously decides to remove unreachable basic-blocks in arbitrary
order so the following makes array_ref_low_bound forgiving in the
case the SSA name with the index definition has been released
already.

2020-04-03  Richard Biener  

PR middle-end/94465
* tree.c (array_ref_low_bound): Deal with released SSA names
in index position.

[Bug debug/94450] lto abstract variable emitted as concrete decl

[vries at gcc dot gnu.org]

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

--- Comment #12 from Tom de Vries  ---
(In reply to Tom de Vries from comment #10)
> I'll file the actual ada example.

PR94469 - "lto abstract variable emitted as concrete decl (ada test-case)"

[Bug ipa/93621] [10 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.c:1443 since r10-5567

[jamborm at gcc dot gnu.org]

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

--- Comment #15 from Martin Jambor  ---
It turns out that no, recursive inlining will happily put an adjusted and not
yet adjusted call into the same function which was formerly a thunk.

[Bug debug/94469] New: lto abstract variable emitted as concrete decl (ada test-case)

[vries at gcc dot gnu.org]

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

Bug ID: 94469
   Summary: lto abstract variable emitted as concrete decl (ada
test-case)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider gdb testsuite test-case gdb.ada/call_pn (
https://sourceware.org/git/?p=binutils-gdb.git;a=tree;f=gdb/testsuite/gdb.ada/call_pn;hb=HEAD
), consisting of files foo.adb, pck.adb and pck.ads.

Compiled like so:
...
$ gnatmake-10 \
  --GCC=/usr/bin/gcc-10 \
  --GNATBIND=/usr/bin/gnatbind-10 \
  --GNATLINK=/usr/bin/gnatlink-10 \
  -largs --GCC=/usr/bin/gcc-10 -margs \
  src/gdb/testsuite/gdb.ada/call_pn/foo.adb \
  -g -flto -O0 -flto-partition=none -ffat-lto-objects
...

When trying to print the value of last_node_id, we get a question which symbol
to print:
...
$ gdb foo -ex "p last_node_id"
Reading symbols from foo...
Multiple matches for last_node_id
[0] cancel
[1] pck.last_node_id at src/gdb/testsuite/gdb.ada/call_pn/pck.adb:17
[2] pck.last_node_id at src/gdb/testsuite/gdb.ada/call_pn/foo.adb:17
> 
...
where 1 gives us:
...
> 1
$1 = 
...
and 2 gives us:
...
> 2
$1 = 0
...

If we compile without lto, so just with -g, we have instead:
...
$ gdb foo -ex "p last_node_id"
$1 = 0
...

The structure of the dwarf for the lto case is:
...
 <0><15ef>: Abbrev Number: 1 (DW_TAG_compile_unit)
<15f5>   DW_AT_name: 
 <1><1611>: Abbrev Number: 2 (DW_TAG_imported_unit)
<1612>   DW_AT_import  : <0x167a>   [Abbrev Number: 1]
 <1><163f>: Abbrev Number: 5 (DW_TAG_variable)
<1640>   DW_AT_abstract_origin: <0x16d4>
<1644>   DW_AT_location: 9 byte block: 3 d4 33 63 0 0 0 0 0
(DW_OP_addr: 6333d4)
 <0><167a>: Abbrev Number: 1 (DW_TAG_compile_unit)
<1680>   DW_AT_name: src/gdb/testsuite/gdb.ada/call_pn/pck.adb
 <1><16d4>: Abbrev Number: 8 (DW_TAG_variable)
<16d5>   DW_AT_name: pck__last_node_id
...

My understanding of DWARF is that this actually declares three symbols:
- the one for DW_TAG_compile_unit pck.adb
- the one for DW_TAG_compile_unit 
- the one resulting from the import of  into DW_TAG_compile_unit
  

And, AFAIU, the way to make sure we declare just one symbol is by both:
- dropping the import, and
- changing the tag for pck.adb to DW_TAG_partial_unit.

The import was already dropped on master by commit 54af95767e8 "debug/94450 -
remove DW_TAG_imported_unit generated in LTRANS units" ( see PR 94450 comment 6
).

Note: interestingly, the foo.adb here is incorrect:
...
[1] pck.last_node_id at src/gdb/testsuite/gdb.ada/call_pn/pck.adb:17
[2] pck.last_node_id at src/gdb/testsuite/gdb.ada/call_pn/foo.adb:17
...
For now I'm assuming that's a gdb PR, filed as 
PR gdb/25771 - "Inter-cu DW_AT_abstract_origin results in wrong file".

[Bug debug/94450] lto abstract variable emitted as concrete decl

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Fri, 3 Apr 2020, vries at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450
> 
> --- Comment #10 from Tom de Vries  ---
> (In reply to rguent...@suse.de from comment #9)
> > On Fri, 3 Apr 2020, vries at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450
> > > 
> > > --- Comment #8 from Tom de Vries  ---
> > > (In reply to Richard Biener from comment #7)
> > > > The DW_TAG_imported_unit are now gone for GCC 10.  So can we consider 
> > > > this
> > > > fixed?
> > > 
> > > I'd like a PR to refer to at the to-be-added xfail in the gdb test-case 
> > > (and
> > > the PR should be open as long as that test fails with trunk gcc). It 
> > > doesn't
> > > matter for me whether that's this particular PR or a follow-up PR.
> > 
> > OK, so if you have a (single?) specific testcase that's still affected
> > please duplicate that into a new bugzilla.  It's always better to
> > have something specific to track.
> > 
> > So did the patch not change anything?
> 
> Well, the changes I asked for related to the example in comment 0 are:
> - drop the import
> - change the tag from DW_TAG_compile_unit to DW_TAG_partial unit.
> 
> AFAIU the patch only removes the import, so in that sense I do not consider 
> the
> test-case reported in comment 0 addressed.

OK, fair enough.  Note that as I read the DWARF spec changing the
early CUs to DW_TAG_partial_unit and then again importing those
(the spec suggests you need to import DW_TAG_partial_units) would
not reflect documented semantics either.  While the early CUs
represent the original TUs declarations the actual instantiation
is split into multiple late CUs.  Currently we import the early CUs
in each late CU that instantiates at least _one_ of the early CU
entities.  But as I read the SPEC importing a partial CU means
the importing CU will be an instantiation point for _all_ entities
in the imported partial CU.

So there may not be a good fit for the LTO usage where we have
"abstract" units for each TU and "concrete" units for each
LTRANS unit picking items to instantiate from various abstract CUs.

Splitting the early CUs into multiple DW_TAG_partial_units, one
for each object, and selectively only importing the instantiated
ones might make it fit better but we then likely have to force
the use of type units to carry type DIEs.  Note we'd still import
the abstract unit for a function when the function is only
instantiated inline and elsewhere instantiated concrete.

So somehow making the early CUs "abstract" might be a better
approach (not sure how gdb would like to have the DWARF represented
then).

[Bug target/94461] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_ia32_pmuludq() and -mno-sse2

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
It doesn't work as is though, looking at it now.

[Bug debug/94450] lto abstract variable emitted as concrete decl

[vries at gcc dot gnu.org]

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

--- Comment #10 from Tom de Vries  ---
(In reply to rguent...@suse.de from comment #9)
> On Fri, 3 Apr 2020, vries at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94450
> > 
> > --- Comment #8 from Tom de Vries  ---
> > (In reply to Richard Biener from comment #7)
> > > The DW_TAG_imported_unit are now gone for GCC 10.  So can we consider this
> > > fixed?
> > 
> > I'd like a PR to refer to at the to-be-added xfail in the gdb test-case (and
> > the PR should be open as long as that test fails with trunk gcc). It doesn't
> > matter for me whether that's this particular PR or a follow-up PR.
> 
> OK, so if you have a (single?) specific testcase that's still affected
> please duplicate that into a new bugzilla.  It's always better to
> have something specific to track.
> 
> So did the patch not change anything?

Well, the changes I asked for related to the example in comment 0 are:
- drop the import
- change the tag from DW_TAG_compile_unit to DW_TAG_partial unit.

AFAIU the patch only removes the import, so in that sense I do not consider the
test-case reported in comment 0 addressed.

I have not tried out the patch.  FWIW, I did try a quick dwarf-assembly
experiment (not the ada one, which will cost more time I expect, but modified
gdb testsuite test-case gdb.dwarf2/imported-unit.exp) and confirmed that
neither only removing the import nor only changing the tag is sufficient to get
only one entry in the symtab.

Anyway, I understand the example is somewhat abstract, and I'll file the actual
ada example.

[Bug target/94461] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_ia32_pmuludq() and -mno-sse2

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Created attachment 48182
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48182=edit
gcc10-pr94461-wip.patch

What I'm proposing is essentially this patch (+ the testcase of course).
Or, instead of isa |= OPTION_MASK_ISA_MMX; we could if OPTION_MASK_ISA_MMX is
set in bisa and not set in isa and TARGET_MMX_WITH_SSE is set clear
OPTION_MASK_ISA_MMX and set OPTION_MASK_ISA_SSE2.  The difference between that
would be just in what we print as suggestion on what the builtin needs.

[Bug c++/94468] [10 Regression] ICE in remove_useless_values, at cselib.c:735 since r10-7515-g2c0fa3ecf70d199a

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Minimal command line options:
$ g++ pr94468.cc -O2 -c -fPIC

[Bug c++/94468] [10 Regression] ICE in remove_useless_values, at cselib.c:735 since r10-7515-g2c0fa3ecf70d199a

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #2 from Martin Liška  ---
I reduced a test-case:

$ cat pr94468.cc
bool a();
enum b {};
class c;
template  struct d;
template  struct d {
  typedef e i;
};
class j {
public:
  j(void(int, j *, c *, void **, bool *)) {}
};
template  class m : public j {
  l ab;
  static void ac(int, j *, c *, void **, bool *);

public:
  m(l f) : j(ac), ab(f) {}
};
b ad;
class c {
public:
  template 
  void ae(typename d::i *p, n af, typename d::i *ag, o ah) {
ai(p, , ag, , new m(ah), ad, ::i::aj);
  }
  void ai(c *, void *, c *, void *, j *, b, int *);
};
class r : public c {
public:
  static int aj;
  void t();
};
class al : public c {
public:
  static int aj;
  void am();
  void ao();
  void ap();
};
class aq {
public:
  aq(const int &, const int & = int());
};
class ar : public c {
public:
  ~ar();
};
class as : public ar {
  as();
  void at();
  void au();
  void av();
};
class u : public c {
public:
  void ax();
};
class ay {
public:
  int az();
};
class ba : public c {
public:
  static int aj;
  void bb();
};
class bc : public al {
public:
  bc() {
if (a())
  am();
  }
};
as::as() {
  al *bd = new bc;
  ae(bd, ::ao, this, ::au);
  ae(bd, ::ap, this, ::av);
  r be;
  u bf;
  ae(, ::t, , ::ax);
  c bg = *bd;
  ae(static_cast(), ::bb, this, ::at);
  ay bh;
  aq am(bh.az());
}

[Bug c++/93597] [9 Regression] ICE in get_fns since r10-6219

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Yes, will do it today, thanks.

[Bug target/94461] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_ia32_pmuludq() and -mno-sse2

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #8)
> So, I believe the r10-400-gecfdb16c54ad06ac23193e5de292fc71e5958526 change
> has been incorrect.
> We should revert those i386-builtin.def changes, and instead treat builtins
> with sole OPTION_MASK_ISA_MMX (and nothing else) as being enabled also if
> TARGET_MMX_WITH_SSE, not just with TARGET_MMX.

The problem is OPTION_MASK_ISA_MMX is used for 2 different purposes:

1. Enable MMX registers.
2. Enable MMX ISA.

pcmpeq is an MMX insn, but 128bit pcmpeq is in SSE2, not SSE.

[Bug target/94461] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_ia32_pmuludq() and -mno-sse2

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
So, I believe the r10-400-gecfdb16c54ad06ac23193e5de292fc71e5958526 change has
been incorrect.
We should revert those i386-builtin.def changes, and instead treat builtins
with sole OPTION_MASK_ISA_MMX (and nothing else) as being enabled also if
TARGET_MMX_WITH_SSE, not just with TARGET_MMX.

[Bug middle-end/91858] [9/10 Regression] Compile time hog w/ complex float trigonometric functions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|NEW |RESOLVED

--- Comment #13 from Richard Biener  ---
OK, thanks for digging into this. -> mpc bug

[Bug target/94467] [10 Regression] wrong code with -mavx and ssse3 builtins

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Priority|P3  |P1

[Bug tree-optimization/91322] [10 regression] alias-4 test failure

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||avieira at gcc dot gnu.org,
   ||clyon at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
I'm adding ARM guys, I hope they can try to reproduce that.

[Bug tree-optimization/94443] [10 Regression] 510.parest_r and 526.blender_r ICE: verify_ssa failed since r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #17 from Kewen Lin  ---
(In reply to Martin Liška from comment #16)
> Can we close it as fixed?

I guess so. Although this commit should be one part of backport for PR94393, I
guess I can only leave that bug open and close this one? Please feel free to
correct me.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[linkw at gcc dot gnu.org]

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

Bug 94443 Summary: [10 Regression] 510.parest_r and 526.blender_r ICE: 
verify_ssa failed since r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443

   What|Removed |Added

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

[Bug c++/93597] [9 Regression] ICE in get_fns since r10-6219

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
@Marek: Can you please do the backport?

[Bug tree-optimization/94443] [10 Regression] 510.parest_r and 526.blender_r ICE: verify_ssa failed since r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad

[marxin at gcc dot gnu.org]

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

--- Comment #16 from Martin Liška  ---
Can we close it as fixed?

[Bug target/94467] [10 Regression] wrong code with -mavx and ssse3 builtins

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Either one has to replace the builtins manually afterwards back with
corresponding intrinsics (something I've done e.g. in the PR94460 patch), or
one could e.g. creduce on mostly preprocessed source where content of
preprocessed #include  would be replaced back with the include.

[Bug c++/94468] [10 Regression] ICE in remove_useless_values, at cselib.c:735 since r10-7515-g2c0fa3ecf70d199a

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Priority|P3  |P1
   Target Milestone|--- |10.0
  Known to work||9.3.0
Summary|ice in  |[10 Regression] ICE in
   |remove_useless_values, at   |remove_useless_values, at
   |cselib.c:735|cselib.c:735 since
   ||r10-7515-g2c0fa3ecf70d199a
  Known to fail||10.0
   Keywords||needs-reduction
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2020-04-03

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-7515-g2c0fa3ecf70d199a.

[Bug target/94467] [10 Regression] wrong code with -mavx and ssse3 builtins

[zsojka at seznam dot cz]

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

--- Comment #4 from Zdenek Sojka  ---
(In reply to Richard Biener from comment #2)
> Note using __builtin_ia32_* directly is discouraged.  A testcase using
> official intrinsics would be better.

Thanks; I just took the list from
https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html (it has some
mistakes though; I hope to list & report them 'when I have time for that'). I
assume using the intrinsics will be a bit complicated, because creduce will
probably expand/inline them by default to the __builtin_ia32_*() call.

[Bug tree-optimization/94443] [10 Regression] 510.parest_r and 526.blender_r ICE: verify_ssa failed since r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad

[linkw at gcc dot gnu.org]

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

--- Comment #15 from Kewen Lin  ---
*** Bug 94451 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/94451] [10 Regression] April 1st 2020 GCC does not compile spec 2017 gcc_r benchmark with -O3

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #7 from Kewen Lin  ---
Correct the status, looks updated mistakenly somehow.

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