[Bug tree-optimization/95906] New: Failure to recognize max pattern with mask

[gabravier at gmail dot com]

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

Bug ID: 95906
   Summary: Failure to recognize max pattern with mask
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

typedef int8_t v16i8 __attribute__((__vector_size__ (16)));

v16i8 f(v16i8 a, v16i8 b)
{
v16i8 cmp = (a > b);
return (cmp & a) | (~cmp & b);
}

int f2(int a, int b)
{
int cmp = -(a > b);
return (cmp & a) | (~cmp & b);
}

f can be optimized to `__builtin_ia32_pmaxsb128` (on x86 with `-msse4`) (the
`pmax` instructions can be used for the same pattern with similar types) and
`f2` can be optimized to using `MAX_EXPR` (they're essentially the same but
I've included the pattern for vectorized types because I originally found this
in a function (which was made before SSE4) made for SSE). LLVM does these
transformations, but GCC does not.

[Bug target/95905] Failure to optimize _mm_unpacklo_epi8 with 0 as right operand to _mm_cvtepu8_epi16

[gabravier at gmail dot com]

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

--- Comment #1 from Gabriel Ravier  ---
The same pattern with _mm_unpacklo_epi16/32 and the corresponding SSE4
intrinsics can also be optimized in the same way.

[Bug target/95905] New: Failure to optimize _mm_unpacklo_epi8 with 0 as right operand to _mm_cvtepu8_epi16

[gabravier at gmail dot com]

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

Bug ID: 95905
   Summary: Failure to optimize _mm_unpacklo_epi8 with 0 as right
operand to _mm_cvtepu8_epi16
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

__m128i f(__m128i a)
{
return _mm_unpacklo_epi8(a, _mm_setzero_si128());
}

This can be optimized to `return _mm_cvtepu8_epi16(a);` (with -msse4`). LLVM
does this transformation, but GCC does not.

[Bug libstdc++/95904] Improve the diagnostic for conflicting return types in std::visit

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-06-26
 Status|UNCONFIRMED |NEW

[Bug libstdc++/95904] New: Improve the diagnostic for conflicting return types in std::visit

[rs2740 at gmail dot com]

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

Bug ID: 95904
   Summary: Improve the diagnostic for conflicting return types in
std::visit
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

std::variant x;
std::visit([] (auto i) { return i; }, x);

produces a less than ideal error with libstdc++:

In file included from :1:

/opt/compiler-explorer/gcc-trunk-20200625/include/c++/11.0.0/variant: In
instantiation of 'static constexpr auto
std::__detail::__variant::__gen_vtable_impl, std::integer_sequence >::_S_apply() [with _Result_type =
std::__detail::__variant::__deduce_visit_result; _Visitor =
main()::&&; _Variants = {std::variant&}; long
unsigned int ...__indices = {1}]':

/opt/compiler-explorer/gcc-trunk-20200625/include/c++/11.0.0/variant:962:56:  
required from 'static constexpr void
std::__detail::__variant::__gen_vtable_impl, std::integer_sequence >::_S_apply_single_alt(_Tp&, _Tp*) [with bool
__do_cookie = false; long unsigned int __index = 1; _Tp =
std::__detail::__variant::_Multi_array
(*)(main()::&&, std::variant&)>; _Result_type =
std::__detail::__variant::__deduce_visit_result; _Visitor =
main()::&&; long unsigned int ...__dimensions = {2}; _Variants
= {std::variant&}; long unsigned int ...__indices = {}]'

/opt/compiler-explorer/gcc-trunk-20200625/include/c++/11.0.0/variant:941:48:  
required from 'constexpr const _Array_type
std::__detail::__variant::__gen_vtable,
main()::&&, std::variant&>::_S_vtable'

/opt/compiler-explorer/gcc-trunk-20200625/include/c++/11.0.0/variant:1685:45:  
required from 'constexpr decltype(auto) std::__do_visit(_Visitor&&, _Variants&&
...) [with _Result_type = std::__detail::__variant::__deduce_visit_result;
_Visitor = main()::; _Variants = {std::variant&}]'

/opt/compiler-explorer/gcc-trunk-20200625/include/c++/11.0.0/variant:1704:35:  
required from 'constexpr decltype(auto) std::visit(_Visitor&&, _Variants&& ...)
[with _Visitor = main()::; _Variants = {std::variant&}]'

:5:43:   required from here

/opt/compiler-explorer/gcc-trunk-20200625/include/c++/11.0.0/variant:1028:67:  
in 'constexpr' expansion of
'std::__detail::__variant::__gen_vtable_impl
(*)(main()::&&, std::variant&), 2>,
std::integer_sequence >::_S_apply()'

/opt/compiler-explorer/gcc-trunk-20200625/include/c++/11.0.0/variant:926:19:  
in 'constexpr' expansion of
'std::__detail::__variant::__gen_vtable_impl
(*)(main()::&&, std::variant&), 2>,
std::integer_sequence >::_S_apply_all_alts<0, 1>(__vtable,
(std::make_index_sequence<2>(), std::make_index_sequence<2>()))'

/opt/compiler-explorer/gcc-trunk-20200625/include/c++/11.0.0/variant:1017:43:
error: invalid conversion from 'std::__success_type::type
(*)(main()::&&, std::variant&)' {aka 'long int
(*)(main()::&&, std::variant&)'} to
'std::__detail::__variant::_Multi_array
(*)(main()::&&, std::variant&)>::__untag_result
(*)(main()::&&, std::variant&)>::element_type'
{aka 'int (*)(main()::&&, std::variant&)'}
[-fpermissive]

 1017 |   { return _Array_type{&__visit_invoke}; }

  |   ^

  |   |

  |   std::__success_type::type (*)(main()::&&, std::variant&) {aka
long int (*)(main()::&&, std::variant&)}

Not only is the error about type mismatch in some function pointer conversion
deep in the guts of the library, but it even offers a "helpful" option to
suppress it with -fpermissive...

Both MSVC and libc++ handle this case with a nice static_assert.

[Bug c++/90333] [9 Regression] Can't apply attributes to lambdas with trailing returns

[ttimo at valvesoftware dot com]

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

--- Comment #9 from Timothee Besset  ---
First test case is still a problem in 9.3 and 10:

[]() __attribute__((always_inline)) -> int { return 0; }

Fix proposed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95883

[Bug c++/89640] [9 Regression] g++ chokes on lambda with __attribute__

[ttimo at valvesoftware dot com]

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

--- Comment #13 from Timothee Besset  ---
Fix proposed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95883

[Bug c++/95883] Attributes on lambdas appear to be parsed in the wrong place

[ttimo at valvesoftware dot com]

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

--- Comment #2 from Timothee Besset  ---
Created attachment 48787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48787=edit
Add a parse for gnu attributes before CPP_DEREF, fixes regression

Proposed patch. Add a parsing for gnu attributes before the CPP_DEREF (->)
parsing.

[Bug middle-end/95903] New: gcc 10: wrong code with -fwrapv

[markus at oberhumer dot com]

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

Bug ID: 95903
   Summary: gcc 10: wrong code with -fwrapv
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus at oberhumer dot com
  Target Milestone: ---

Link at Compiler Explorer: https://godbolt.org/z/VgNLcX


The following 2 functions should generate identical code when using "-fwrapv",
but
the second function is missing the sign extension after the add.


// compile with: gcc-10 -m64 -O2 -fwrapv

char get_byte_use_add(const char* ptr, int off)
{
off += 1;
return ptr[off];
}

char get_byte_use_plus(const char* ptr, int off)
{
return ptr[off + 1]; // gcc: BUG
}

[Bug c++/91104] auto... in lambda expression reorders parameters

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/91104] auto... in lambda expression reorders parameters

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:08ca2d744d50d0d5a341530031e6bbb82831109f

commit r11-1668-g08ca2d744d50d0d5a341530031e6bbb82831109f
Author: Marek Polacek 
Date:   Thu Jun 25 19:04:06 2020 -0400

c++: Add test for c++/91104

Fixed by r271705.

gcc/testsuite/ChangeLog:

PR c++/91104
* g++.dg/cpp1y/lambda-generic-variadic21.C: New test.

[Bug c++/89640] [9 Regression] g++ chokes on lambda with __attribute__

[ttimo at valvesoftware dot com]

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

Timothee Besset  changed:

   What|Removed |Added

 CC||ttimo at valvesoftware dot com

--- Comment #12 from Timothee Besset  ---
This is still a problem in 9.3 and 10 when using a return type:

void test() {
[]() __attribute__((noinline)) -> int {
  return 0;
}();
}

[Bug c++/91416] ICE in cp_check_const_attributes, at cp/decl2.c:1408

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
*** Bug 95902 has been marked as a duplicate of this bug. ***

[Bug c++/95902] [10/11 Regression] ICE: tree check: expected tree_list, have ggc_freed in get_attribute_name, at attribs.c:841

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #3 from Marek Polacek  ---
Actually even GCC 4.8 ICEs.  It is a dup of bug 91416.  Which is assigned to
me.

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

[Bug c++/95902] [10/11 Regression] ICE: tree check: expected tree_list, have ggc_freed in get_attribute_name, at attribs.c:841

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Reminds me of 91416.  Annoyingly, the ICE goes away with -save-temps, but can
be reproduced with --param ggc-min-expand=0 --param ggc-min-heapsize=0.

[Bug c++/95902] [10/11 Regression] ICE: tree check: expected tree_list, have ggc_freed in get_attribute_name, at attribs.c:841

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-on-valid-code,
   ||needs-reduction
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-25
 CC||mpolacek at gcc dot gnu.org
Summary|ICE: tree check: expected   |[10/11 Regression] ICE:
   |tree_list, have ggc_freed   |tree check: expected
   |in get_attribute_name, at   |tree_list, have ggc_freed
   |attribs.c:841   |in get_attribute_name, at
   ||attribs.c:841
   Target Milestone|--- |10.2

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

[Bug fortran/93423] [8/9/10/11 Regression] ICE on invalid with argument list for module procedure

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2020-June/054620.html

[Bug c++/95902] New: ICE: tree check: expected tree_list, have ggc_freed in get_attribute_name, at attribs.c:841

[p.vanhoof at oma dot be]

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

Bug ID: 95902
   Summary: ICE: tree check: expected tree_list, have ggc_freed in
get_attribute_name, at attribs.c:841
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p.vanhoof at oma dot be
  Target Milestone: ---

Created attachment 48786
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48786=edit
Code that triggers the ICE

% g++ --version
g++ (GCC) 11.0.0 20200604 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

With this compiler, the attached code generates an ICE:

% g++ -g -c bug.cc
bug.cc:53:3: internal compiler error: tree check: expected tree_list, have
ggc_freed in get_attribute_name, at attribs.c:841
   53 | } ql;
  |   ^~
0x7ecec1 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-git/gcc/tree.c:9685
0x6c8201 tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc-git/gcc/tree.h:3552
0x6c8201 get_attribute_name(tree_node const*)
../../gcc-git/gcc/attribs.c:841
0xab8c79 private_lookup_attribute(char const*, unsigned long, tree_node*)
../../gcc-git/gcc/attribs.c:1812
0x932338 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc-git/gcc/attribs.h:179
0x93e188 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc-git/gcc/cp/decl.c:5231
0x9eae3d cp_parser_init_declarator
../../gcc-git/gcc/cp/parser.c:20817
0x9cc6c2 cp_parser_simple_declaration
../../gcc-git/gcc/cp/parser.c:13785
0x9f5916 cp_parser_declaration
../../gcc-git/gcc/cp/parser.c:13484
0x9f605a cp_parser_translation_unit
../../gcc-git/gcc/cp/parser.c:4761
0x9f605a c_parse_file()
../../gcc-git/gcc/cp/parser.c:44034
0xb0b81b c_common_parse_file()
../../gcc-git/gcc/c-family/c-opts.c:1190

With older g++ versions like 10.1.0, 9.3.0, and 8.4.0 it compiles correctly, so
this seems to be a regression.

Adding -save-temps to the command line makes the ICE go away, so unfortunately
the preprocessed source is not useful... I hope you can reproduce it without
this. The -g flag is essential to trigger the ICE.

[Bug c/95901] New: [C, C++] OpenACC, OpenMP executable directives wrongly refused after labels

[tschwinge at gcc dot gnu.org]

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

Bug ID: 95901
   Summary: [C, C++] OpenACC, OpenMP executable directives wrongly
refused after labels
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48785=edit
'pr.c'

..., or am I confused?  (It's late.)

  switch (argc)
{
case 4:
#pragma acc update self(argc) // { dg-bogus "may only be used in compound
statements" }
  break;

Etc., see attached 'pr.c'

[Bug fortran/95877] [8/9 regression] ICE in test case gfortran.dg/pr95689.f90 after r9-8693

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #3 from Bill Seurer  ---
Yup.  I saw them succeed on a round of testing this morning.

[Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2020-June/054619.html

[Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Seems to be fixed by:

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 2b760efe8d7..48f81d89a74 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -2277,6 +2277,9 @@ gfc_find_derived_vtab (gfc_symbol *derived)
   if (!derived)
 return NULL;

+  if (!derived->name)
+return NULL;
+
   /* Find the gsymbol for the module of use associated derived types.  */
   if ((derived->attr.use_assoc || derived->attr.used_in_submodule)
&& !derived->attr.vtype && !derived->attr.is_class)

[Bug fortran/95827] ICE in gfc_get_string, at fortran/iresolve.c:70

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:69240fb9428513687d451af19fb762687fe65786

commit r10-8370-g69240fb9428513687d451af19fb762687fe65786
Author: Harald Anlauf 
Date:   Wed Jun 24 21:03:47 2020 +0200

PR fortran/95827 - Buffer overflows with submodules and coarrays

With submodules and coarrays, name mangling results in long internal
symbols.  Enlarge internal buffer.

gcc/fortran/
PR fortran/95827
* iresolve.c (gfc_get_string): Enlarge internal buffer used in
generating the mangled name.

(cherry picked from commit a16d0924f18046704ef9a4b6d9593718594677f1)

[Bug fortran/95877] [8/9 regression] ICE in test case gfortran.dg/pr95689.f90 after r9-8693

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from anlauf at gcc dot gnu.org ---
The backport was reverted on 8- and 9-branch, since not a critical regression,
and a clean backport would need a manual backport of a series of other fixes.

The error should be gone now.  If you have confirmed this, please close
this PR.

[Bug fortran/95689] [8/9/10/11 Regression] ICE in check_sym_interfaces, at fortran/interface.c:2015

[anlauf at gcc dot gnu.org]

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
Reverted on 8- and 9-branch, since not a critical regression, and a clean
backport would need a manual backport of a series of other fixes.

[Bug fortran/95828] ICE in resolve_select_rank, at fortran/resolve.c:9774

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:77d455ee81ec3a23f8b20259a31ab963716f8e82

commit r11-1667-g77d455ee81ec3a23f8b20259a31ab963716f8e82
Author: Harald Anlauf 
Date:   Thu Jun 25 20:34:48 2020 +0200

PR fortran/95828 - Buffer overflows with SELECT RANK

With SELECT RANK, name mangling results in long internal symbols that
overflows internal buffers.  Fix that.

gcc/fortran/
PR fortran/95828
* match.c (select_rank_set_tmp): Enlarge internal buffer used in
generating a mangled name.
* resolve.c (resolve_select_rank): Likewise.

[Bug fortran/95826] ICE in gfc_match_decl_type_spec, at fortran/decl.c:4290

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:35a335a159216548fc77263ac5df71ff29d3f448

commit r11-1666-g35a335a159216548fc77263ac5df71ff29d3f448
Author: Harald Anlauf 
Date:   Thu Jun 25 20:32:13 2020 +0200

PR fortran/95826 - Buffer overflows with PDTs and long symbols

With PDTs (parameterized derived types), name mangling results in variably
long internal symbols.  Use a dynamic buffer instead of a fixed-size one.

gcc/fortran/
PR fortran/95826
* decl.c (gfc_match_decl_type_spec): Replace a fixed size
buffer by a pointer and reallocate if necessary.

[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order

[vmakarov at gcc dot gnu.org]

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

--- Comment #13 from Vladimir Makarov  ---
(In reply to Tamar Christina from comment #12)
> (In reply to Vladimir Makarov from comment #11)
> >   I just expressed my point of view to the bottom-up approach.  If somebody
> > implements any new RA approach which at least does not hurt credible
> > benchmarks (e.g. SPEC) and improve some benchmarks and does not complicate
> > existing RA too much, nobody will have legitimate arguments not to include
> > the new code into GCC.
> > 
> >   I think that may be for some cases bottom-up approach could work better. 
> > Probably this is code for number crunching (with a lot of loop iterations). 
> > For some cases top-down approach works better for loops with smaller number
> > iterations  (e.g. most loops in GCC itself).
> > 
> 
> I don't know much about the current RA implementation, but would it be
> possible you think to have this be heuristics driven? or do you think it
> would be too expensive to try multiple strategies and keep the one that
> works best?

Probably trying multiple strategies will be too expensive.  Also compile-time
evaluation of allocation cost is not that accurate, especially taking into
account that the local register allocator can change global RA decisions and
the changes are unpredictable.

  If the top-down algorithm works better for some cases, we could get some
experience when it works and try to find heuristics to choose the right
algorithm.  I think it would be more realistic approach.  It sounds like a case
for ML but I am sure ML will not work.  It is not a smooth function, besides ML
create a lot of problems with GCC building (benchmark set, costly building,
valdiation and using ML model etc).  So heuristics built on understanding is a
way to go.  But I speculated too much because there is no bottom-up RA
implementation with finding its advantages (if there are any) and its
disadvantages.

[Bug c++/95888] [9/10/11 Regression] Regression in 9.3. GCC freezes when compiling code using boost::poly_collection::segment

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug testsuite/95900] New: New test case gcc.dg/vect/bb-slp-pr95866.c in r11-1647 fails

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95900
   Summary: New test case gcc.dg/vect/bb-slp-pr95866.c in r11-1647
fails
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:86ce59b4f05d8f68ec4d9a14a7732acb370412db, r11-1647

Saw this on powerpc64 both BE and LE.

make -k check-gcc RUNTESTFLAGS=vect.exp=gcc.dg/vect/bb-slp-pr95866.c

FAIL: gcc.dg/vect/bb-slp-pr95866.c scan-tree-dump slp2 "BIT_FIELD_REF"
FAIL: gcc.dg/vect/bb-slp-pr95866.c -flto -ffat-lto-objects  scan-tree-dump slp2
"BIT_FIELD_REF"

# of expected passes4
# of unexpected failures2

[Bug middle-end/95899] -funroll-loops does not duplicate accumulators when calculating reductions, failing to break up dependency chains

[elrodc at gmail dot com]

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

--- Comment #2 from Chris Elrod  ---
Interesting. Compiling with:

gcc -march=native -fvariable-expansion-in-unroller -Ofast -funroll-loops -S
dot.c -o dot.s

Yields:

```
.L4:
vmovupd (%rdi,%r11), %zmm9
vmovupd 64(%rdi,%r11), %zmm10
vfmadd231pd (%rsi,%r11), %zmm9, %zmm0
vfmadd231pd 64(%rsi,%r11), %zmm10, %zmm1
vmovupd 128(%rdi,%r11), %zmm11
vmovupd 192(%rdi,%r11), %zmm12
vmovupd 256(%rdi,%r11), %zmm13
vfmadd231pd 128(%rsi,%r11), %zmm11, %zmm0
vfmadd231pd 192(%rsi,%r11), %zmm12, %zmm1
vmovupd 320(%rdi,%r11), %zmm14
vmovupd 384(%rdi,%r11), %zmm15
vmovupd 448(%rdi,%r11), %zmm4
vfmadd231pd 256(%rsi,%r11), %zmm13, %zmm0
vfmadd231pd 320(%rsi,%r11), %zmm14, %zmm1
vfmadd231pd 384(%rsi,%r11), %zmm15, %zmm0
vfmadd231pd 448(%rsi,%r11), %zmm4, %zmm1
addq$512, %r11
cmpq%r8, %r11
jne .L4
```

So the dependency chain has now been split in 2.
4 would be ideal. I'll try running benchmarks later to see how it does.
FWIW, the original ran at between 20 and 25 GFLOPS from roughly N = 80 through
N = 1024.
The fastest versions I benchmarked climbed from around 20 to 50 GFLOPS over
this range. So perhaps just splitting the dependency once can get it much of
the way there.

Out of curiosity, what's the reason for this being off by default for
everything but ppc?
Seems like it should turned on with `-funroll-loops`, given that breaking
dependency chains are one of the primary ways unrolling can actually help
performance.

[Bug d/95075] gcc/d/dmd/dscope.c: 2 * strange assignments ?

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Iain Buclaw  ---
Done.

[Bug d/95173] [D] ICE on some architecture targets when trying to use unknown attribute

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:62e02c8729a75c4a859edc18e0bcafb87d717f46

commit r11-1658-g62e02c8729a75c4a859edc18e0bcafb87d717f46
Author: Iain Buclaw 
Date:   Tue Jun 23 16:25:29 2020 +0200

d: Fix ICE in uda_attribute_p when looking up unknown attribute

The target attribute table is not guaranteed to be set in all backends.

gcc/d/ChangeLog:

PR d/95173
* d-attribs.cc (uda_attribute_p): Don't search target attribute
table
if NULL.

gcc/testsuite/ChangeLog:

PR d/95173
* gdc.dg/pr95173.d: New test.

[Bug d/95075] gcc/d/dmd/dscope.c: 2 * strange assignments ?

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:1b7b352a8379dbdd74c962d11951982e21e20f13

commit r11-1662-g1b7b352a8379dbdd74c962d11951982e21e20f13
Author: Iain Buclaw 
Date:   Wed Jun 24 08:35:58 2020 +0200

d: Merge upstream dmd 4be011355.

Fixes self-assignment warnings seen when compiling with clang.

Reviewed-on: https://github.com/dlang/dmd/pull/11315

gcc/d/ChangeLog:

PR d/95075
* dmd/MERGE: Merge upstream dmd 4be011355.

[Bug d/95250] [D] ICE instead of error when trying to use bad template type inside template

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:1d19c9cd3dd99ba8885c0fc93223918399f73939

commit r11-1661-g1d19c9cd3dd99ba8885c0fc93223918399f73939
Author: Iain Buclaw 
Date:   Tue Jun 23 22:43:27 2020 +0200

d: Merge upstream dmd 90450f3ef.

Fixes a regression caused by an incomplete backport of converting the
Expression semantic pass to a Visitor.

Reviewed-on: https://github.com/dlang/dmd/pull/11314

gcc/d/ChangeLog:

PR d/95250
* dmd/MERGE: Merge upstream dmd 90450f3ef.

gcc/testsuite/ChangeLog:

PR d/95250
* gdc.dg/pr95250.d: New test.

[Bug middle-end/95899] -funroll-loops does not duplicate accumulators when calculating reductions, failing to break up dependency chains

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Is this -fvariable-expansion-in-unroller ? (off by default for everything but
powerpc)

[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  ---
Submitted patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548920.html

[Bug middle-end/95899] New: -funroll-loops does not duplicate accumulators when calculating reductions, failing to break up dependency chains

[elrodc at gmail dot com]

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

Bug ID: 95899
   Summary: -funroll-loops does not duplicate accumulators when
calculating reductions, failing to break up dependency
chains
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: elrodc at gmail dot com
  Target Milestone: ---

Created attachment 48784
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48784=edit
cc -march=skylake-avx512 -mprefer-vector-width=512 -Ofast -funroll-loops -S
dot.c -o dot.s

Sample code:

```
double dot(double* a, double* b, long N){
  double s = 0.0;
  for (long n = 0; n < N; n++){
s += a[n] * b[n];
  }
  return s;
}
```

Relevant part of the asm:
```
.L4:
vmovupd (%rdi,%r11), %zmm8
vmovupd 64(%rdi,%r11), %zmm9
vfmadd231pd (%rsi,%r11), %zmm8, %zmm0
vmovupd 128(%rdi,%r11), %zmm10
vmovupd 192(%rdi,%r11), %zmm11
vmovupd 256(%rdi,%r11), %zmm12
vmovupd 320(%rdi,%r11), %zmm13
vfmadd231pd 64(%rsi,%r11), %zmm9, %zmm0
vmovupd 384(%rdi,%r11), %zmm14
vmovupd 448(%rdi,%r11), %zmm15
vfmadd231pd 128(%rsi,%r11), %zmm10, %zmm0
vfmadd231pd 192(%rsi,%r11), %zmm11, %zmm0
vfmadd231pd 256(%rsi,%r11), %zmm12, %zmm0
vfmadd231pd 320(%rsi,%r11), %zmm13, %zmm0
vfmadd231pd 384(%rsi,%r11), %zmm14, %zmm0
vfmadd231pd 448(%rsi,%r11), %zmm15, %zmm0
addq$512, %r11
cmpq%r8, %r11
jne .L4

```

Skylake-AVX512's vfmaddd should have a throughput of 2/cycle, but a latency of
4 cycles.

Because each unrolled instance accumulates into `%zmm0`, we are limited by the
dependency chain to 1 fma every 4 cycles.

It should use separate accumulators.

Additionally, if the loads are aligned, it would have a throughput of 2
loads/cycle. Because we need 2 loads per fma, that limits us to only 1 fma per
cycle. If the dependency chain were the primary motivation for unrolling, we'd
only want to unroll by 4, not 8. 4 cycles of latency, 1 fma per cycle -> 4
simultaneous / OoO fmas.

Something like a sum (1 load per add) would perform better with the 8x
unrolling seen here (at least, from 100 or so elements until it becomes memory
bound).

[Bug fortran/95837] derived-type components of character kind=4 – wrong code with component access (kind=4 ignored)

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #7 from Tobias Burnus  ---
FIXED on mainline = GCC 11.

[Bug fortran/95837] derived-type components of character kind=4 – wrong code with component access (kind=4 ignored)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r11-1654-gf48bffe70cba310461ec19ffcd07c573a6b86575
Author: Tobias Burnus 
Date:   Thu Jun 25 16:57:08 2020 +0200

Fortran: Fix character-kind=4 substring resolution (PR95837)

Testing showed that it is always set and its value matches
always ts->kind (if available) or otherwise, if it is a variable,
the sym->ts.kind.

gcc/fortran/ChangeLog:

PR fortran/95837
* resolve.c (gfc_resolve_substring_charlen): Remove
bogus ts.kind setting for the expression.

gcc/testsuite/ChangeLog:

PR fortran/95837
* gfortran.dg/char4-subscript.f90: New test.

[Bug tree-optimization/95839] Failure to optimize addition of vector elements to vector addition

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
OK, I have a patch doing BIT_FIELD_REFs.

[Bug debug/95898] New: Wrong backtrace infromation at Og

[massarelli at diag dot uniroma1.it]

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

Bug ID: 95898
   Summary: Wrong backtrace infromation at Og
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: massarelli at diag dot uniroma1.it
  Target Milestone: ---

When line 5 is hit for the second time gdb shows function b in the top of the
backtrace while line 5 belong to function main. 

$ cat -n a.c
 1  int a;
 2  void b() { printf("%X\n"); }
 3  int main() {
 4a = 1;
 5b();
 6  }

$ cat a.c
int a;
void b() { printf("%X\n"); }
int main() {
  a = 1;
  b();
}

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/tmp/gcc_build --disable-multilib
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200624 (experimental) (GCC) 

$ gcc -O3 -g -o out a.c

$ gdb out 
Breakpoint 1, main () at a.c:4
4 a = 1;
(gdb) bt
#0  main () at a.c:4
(gdb) s
5 b();
(gdb) bt
#0  main () at a.c:5
(gdb) s
b () at a.c:5
5 b();
(gdb) bt
#0  b () at a.c:5
#1  main () at a.c:5
(gdb) s
E668
0x77a05b97 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
(gdb)

[Bug fortran/95869] ICE when "target parallel" construct used with "if" clause in Fortran

[kcy at codesourcery dot com]

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

Kwok Yeung  changed:

   What|Removed |Added

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

--- Comment #4 from Kwok Yeung  ---
The issue has now been fixed by the patch.

[Bug c++/95895] internal compiler error: in captures_temporary, at cp/coroutines.cc:2717

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
   Keywords||ice-on-valid-code
   Target Milestone|--- |10.2

--- Comment #4 from Iain Sandoe  ---
thanks for the report.

[Bug tree-optimization/95897] New: [11 regression] gfortran.dg/graphite/pr40982.f90 fails with ICE starting with r11-1649

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95897
   Summary: [11 regression]  gfortran.dg/graphite/pr40982.f90
fails with ICE starting with r11-1649
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:d2adb79eac663874593a28387db593fb4bb2995f, r11-1649

make -k check-gcc RUNTESTFLAGS=graphite.exp=gfortran.dg/graphite/pr40982.f90

FAIL: gfortran.dg/graphite/pr40982.f90   -O  (internal compiler error)
FAIL: gfortran.dg/graphite/pr40982.f90   -O  (test for excess errors)

spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/graphite/pr40982.f90
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -O -O3 -fgraphite-identity -floop-nest-optimize -S -o
pr40982.s
during GIMPLE pass: vect
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/graphite/pr40982.f90:17:0:
internal compiler error: in compute_live_loop_exits, at
tree-ssa-loop-manip.c:247
0x10deb517 compute_live_loop_exits
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop-manip.c:247
0x10deb517 add_exit_phis_var
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop-manip.c:334
0x10deb517 add_exit_phis
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop-manip.c:356
0x10deb517 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int,
loop*)
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop-manip.c:678
0x10f9d8c7 vectorize_loops()
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.c:1260
0x10e0f7a7 execute
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop.c:414

[Bug tree-optimization/95839] Failure to optimize addition of vector elements to vector addition

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:628b78f9794a2eefcbc578011806bfa8e09b9ef7

commit r11-1653-g628b78f9794a2eefcbc578011806bfa8e09b9ef7
Author: Richard Biener 
Date:   Thu Jun 25 12:47:20 2020 +0200

tree-optimization/95839 - allow CTOR vectorization without loads

This removes a premature check for enough datarefs in a basic-block
before we consider vectorizing it which leaves basic-blocks with
just vectorizable vector constructors unvectorized.  The check
is effectively done by the following check for store groups
which then also include constructors.

2020-06-25  Richard Biener  

PR tree-optimization/95839
* tree-vect-slp.c (vect_slp_analyze_bb_1): Remove premature
check on the number of datarefs.

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

[Bug c++/95809] GCC treats inline namespace declaration as "ambiguous"

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
yup, dr2061 made that ill-formed.  

p1701 (wg21.link/p1701) documents the behaviour and it appears EWG is exploring
another avenue to resolve the underlying problem 2061 was attempting to fix.

[Bug c++/95477] [coroutines] coroutine result object not properly freed

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #5 from Iain Sandoe  ---
fixed for master and 10.2

[Bug c++/95477] [coroutines] coroutine result object not properly freed

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
:

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

commit r10-8369-gd9b3aa517bdab280bbde2a80a80a77ad7333a0cb
Author: Iain Sandoe 
Date:   Thu Jun 25 14:33:23 2020 +0100

coroutines: Add a cleanup expression for g-r-o when needed [PR95477].

The PR reports that we fail to destroy the object initially created from
the get-return-object call.  Fixed by adding a cleanup when the DTOR is
non-trivial.  In addition, to meet the specific wording that the call to
get_return_object creates the glvalue for the return, we must construct
that in-place in the return object to avoid a second copy/move CTOR.

gcc/cp/ChangeLog:

PR c++/95477
* coroutines.cc (morph_fn_to_coro): Apply a cleanup to
the get return object when the DTOR is non-trivial.

gcc/testsuite/ChangeLog:

PR c++/95477
* g++.dg/coroutines/pr95477.C: New test.
* g++.dg/coroutines/void-gro-non-class-coro.C: New test.

(cherry picked from commit 788b962aa00959e861b45767c5c88ec41ca30c21)

[Bug tree-optimization/95896] [11 regression] ICE in mask_load_slp_1 since r11-1621-gd32708e796504eaeaad7d19990909204d74f9ba3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
It did (just checked the rev before where it ICEs).

[Bug tree-optimization/95896] [11 regression] ICE in mask_load_slp_1 since r11-1621-gd32708e796504eaeaad7d19990909204d74f9ba3

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Hmm, it doesn't ICE for me but it uses  and I'm funneling in
x86_64-linux host includes, but the systems should be reasonably compatible.
Did g:d2adb79eac663874593a28387db593fb4bb2995f possibly fix the issue?

[Bug c++/95895] internal compiler error: in captures_temporary, at cp/coroutines.cc:2717

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Reduced test-case:

cat x.ii
namespace std {
template  struct remove_reference;
template  struct remove_reference<_Tp &> { typedef _Tp type; };
template  remove_reference<_Tp>::type move(_Tp &&);
template  class optional {
public:
  _Tp *operator->();
};
class vector {
public:
  int begin();
  int end();
};
} // namespace std
template  class future { future(future &&); };
namespace internal {
struct extract_values_from_futures_vector {
  using future_type = future<>;
  static future_type current_exception_as_future();
};
} // namespace internal
template 
auto when_all_succeed(FutureIterator, FutureIterator) {
  using result_transform = internal::extract_values_from_futures_vector;
  return result_transform::current_exception_as_future();
}
namespace std {
template  struct coroutine_traits;
template  struct coroutine_handle;
template <> struct coroutine_handle<> {};
template  struct coroutine_handle : coroutine_handle<> {};
struct suspend_never {
  void await_ready();
  void await_suspend(coroutine_handle<>);
  void await_resume();
};
} // namespace std
namespace internal {
class coroutine_traits_base {
public:
  class promise_type {
  public:
std::suspend_never initial_suspend();
std::suspend_never final_suspend();
  };
};
struct awaiter {
  future<> _future;
  void await_ready();
  template  void await_suspend(std::coroutine_handle);
  void await_resume();
};
} // namespace internal
auto operator co_await(future<> f) { return internal::awaiter(std::move(f)); }
namespace std {
template 
class coroutine_traits, Args...>
: public internal::coroutine_traits_base {};
class server {
  struct leader_state {
vector _replicatoin_fibers;
  };
  optional _leader_state;
  future<> drop_leadership();
};
future<> server::drop_leadership() {
  co_await when_all_succeed(_leader_state->_replicatoin_fibers.begin(),
_leader_state->_replicatoin_fibers.end());

[Bug tree-optimization/95896] [11 regression] ICE in mask_load_slp_1 since r11-1621-gd32708e796504eaeaad7d19990909204d74f9ba3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
Version|10.0|11.0
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-25
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug fortran/95869] ICE when "target parallel" construct used with "if" clause in Fortran

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Kwok Yeung :

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

commit r11-1651-gf530bac8a11da9c85bdd8e58d589747f9825e38d
Author: Kwok Cheung Yeung 
Date:   Thu Jun 25 04:40:53 2020 -0700

fortran: Fix ICE when 'if' clause used with 'target parallel' (PR95869)

2020-06-25  Tobias Burnus  
Kwok Cheung Yeung  

gcc/fortran/

PR fortran/95869
* trans-openmp.c (gfc_trans_omp_target): Use correct scoping block.

gcc/testsuite/

PR fortran/95869
* gfortran.dg/gomp/combined-if.f90 (test_target_parallel):
Re-enable.
* gfortran.dg/gomp/pr95869.f90: New.

[Bug c++/95883] Attributes on lambdas appear to be parsed in the wrong place

[ttimo at valvesoftware dot com]

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

--- Comment #1 from Timothee Besset  ---
Known to fail: 9.3, 10.0

Putting the full link to the original bug so it gets linked:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333

[Bug tree-optimization/95896] New: [11 regression] ICE in mask_load_slp_1 since r11-1621-gd32708e796504eaeaad7d19990909204d74f9ba3

[clyon at gcc dot gnu.org]

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

Bug ID: 95896
   Summary: [11 regression] ICE in mask_load_slp_1 since
r11-1621-gd32708e796504eaeaad7d19990909204d74f9ba3
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

Since r11-1621-gd32708e796504eaeaad7d19990909204d74f9ba3
I have noticed:
FAIL: gcc.target/aarch64/sve/mask_load_slp_1.c -march=armv8.2-a+sve (internal
compiler error)
FAIL: gcc.target/aarch64/sve/mask_load_slp_1.c -march=armv8.2-a+sve (test for
excess errors)
Excess errors:
/gcc/testsuite/gcc.target/aarch64/sve/mask_load_slp_1.c:8:1: error: definition
in block 3 follows the use
for SSA_NAME: mask_patt_58.126_186 in statement:
vec_mask_and_190 = mask_patt_58.126_186 & loop_mask_189;
during GIMPLE pass: vect
/gcc/testsuite/gcc.target/aarch64/sve/mask_load_slp_1.c:8:1: internal compiler
error: verify_ssa failed
0x10144f3 verify_ssa(bool, bool)
/gcc/tree-ssa.c:1208
0xc8e653 execute_function_todo
/gcc/passes.c:1992
0xc8ef35 execute_todo
/gcc/passes.c:2039

[Bug c++/95895] internal compiler error: in captures_temporary, at cp/coroutines.cc:2717

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-25
 Ever confirmed|0   |1
 CC||iains at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #2 from Martin Liška  ---
Confirmed, I'm bisecting that..

[Bug c++/95809] GCC treats inline namespace declaration as "ambiguous"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
This changed with r248521

Implement DR2061

gcc/
Implement DR2061
* name-lookup.c (push_inline_namespaces): New.
(push_namespace): Look inside inline namespaces.

testsuite/
* g++.dg/cpp0x/dr2061.C: New.
* g++.dg/parse/namespace-alias-1.C: Add more test.

I'm not sure the code is valid, but I'll let Nathan comment.

[Bug target/95874] CLWB isn't supported on Icelake client

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from H.J. Lu  ---
Fixed for GCC 11, GCC 10.2, GCC 9.4 and GCC 8.5

[Bug target/95874] CLWB isn't supported on Icelake client

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-8 branch has been updated by H.J. Lu :

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

commit r8-10329-ge39a8763c4dead0f448981d9488d7b264db9da55
Author: H.J. Lu 
Date:   Wed Jun 24 09:12:47 2020 -0700

x96: Remove PTA_CLWB from PTA_ICELAKE_CLIENT

CLWB isn't supported on Ice Lake client.  But Ice Lake server support it.
Move PTA_CLWB to PTA_ICELAKE_SERVER.

PR target/95874
* config/i386/i386.c (PTA_ICELAKE_CLIENT): Remove PTA_CLWB.
(PTA_ICELAKE_SERVER): Add PTA_CLWB.

(cherry picked from commit c422e5f81f42a0fc197f0715f4fcd81f1be90bff)

[Bug c++/95895] internal compiler error: in captures_temporary, at cp/coroutines.cc:2717

[gleb at scylladb dot com]

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

--- Comment #1 from Gleb Natapov  ---
Created attachment 48783
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48783=edit
File that gcc asked to attach

[Bug c++/95895] New: internal compiler error: in captures_temporary, at cp/coroutines.cc:2717

[gleb at scylladb dot com]

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

Bug ID: 95895
   Summary: internal compiler error: in captures_temporary, at
cp/coroutines.cc:2717
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gleb at scylladb dot com
  Target Milestone: ---

Got an internal compile error:
raft/raft.cc: In member function ‘seastar::future<>
raft::server::drop_leadership(raft::server::state)’:
raft/raft.cc:173:1: internal compiler error: in captures_temporary, at
cp/coroutines.cc:2717
  173 | }
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccdd6MK7.out file, please attach this to
your bugreport.
ninja: build stopped: subcommand failed.

[Bug target/95874] CLWB isn't supported on Icelake client

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-9 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:12cdfdd5b143866406c0d2ba4e67e9409b5cf341

commit r9-8698-g12cdfdd5b143866406c0d2ba4e67e9409b5cf341
Author: H.J. Lu 
Date:   Wed Jun 24 09:12:47 2020 -0700

x96: Remove PTA_CLWB from PTA_ICELAKE_CLIENT

CLWB isn't supported on Ice Lake client.  But Ice Lake server support it.
Move PTA_CLWB to PTA_ICELAKE_SERVER.

PR target/95874
* config/i386/i386.h (PTA_ICELAKE_CLIENT): Remove PTA_CLWB.
(PTA_ICELAKE_SERVER): Add PTA_CLWB.

(cherry picked from commit c422e5f81f42a0fc197f0715f4fcd81f1be90bff)

[Bug rtl-optimization/95891] Missing optimization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-25
 Status|UNCONFIRMED |NEW

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

[Bug fortran/95893] pr95690.f90 fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
This.

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

[Bug testsuite/95706] New test case gfortran.dg/pr95690.f90 fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|11.0|10.1.1
  Known to fail||10.1.1, 11.0

--- Comment #6 from Richard Biener  ---
Now also on the branch.

[Bug testsuite/95706] New test case gfortran.dg/pr95690.f90 fails

[rguenth at gcc dot gnu.org]

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

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

[Bug fortran/95893] pr95690.f90 fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Richard Biener  ---
There's a duplicate for this, the issue is that somehow the error appears on
different lines depending on the target :/

[Bug target/95874] CLWB isn't supported on Icelake client

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-10 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:9085b9c926be56ae9ca84c021e4bfde0ab75d083

commit r10-8368-g9085b9c926be56ae9ca84c021e4bfde0ab75d083
Author: H.J. Lu 
Date:   Wed Jun 24 09:12:47 2020 -0700

x96: Remove PTA_CLWB from PTA_ICELAKE_CLIENT

CLWB isn't supported on Ice Lake client.  But Ice Lake server and Tiger
Lake support it.  Move PTA_CLWB to PTA_ICELAKE_SERVER and PTA_TIGERLAKE.

PR target/95874
* config/i386/i386.h (PTA_ICELAKE_CLIENT): Remove PTA_CLWB.
(PTA_ICELAKE_SERVER): Add PTA_CLWB.
(PTA_TIGERLAKE): Add PTA_CLWB.

(cherry picked from commit c422e5f81f42a0fc197f0715f4fcd81f1be90bff)

[Bug c/95800] DJGPP 9.3.1 doesn't parse C files correctly

[andris at gcc dot gnu.org]

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

Andris Pavenis  changed:

   What|Removed |Added

 CC||andris at gcc dot gnu.org

--- Comment #4 from Andris Pavenis  ---
Failed to reproduce with 10.1.0 on Arch Linux (gcc build
https://aur.archlinux.org/packages/djgpp-gcc/).

Perhaps preprocessed source could help to diagnose the problem

[Bug tree-optimization/95839] Failure to optimize addition of vector elements to vector addition

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
I am testing a patch to remove the premature check.  For the original testcase
you'd still have to disable cost modeling so handling of BIT_FIELD_REFs of
vectors is still missing (but I think we have duplicate PRs about that).

[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests

[andrea.corallo at arm dot com]

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

--- Comment #9 from Andrea Corallo  ---
"clyon at gcc dot gnu.org"  writes:

> I guess that's the "testglue" object file added by Dejagnu when
> needs_status_wrapper is set in the .exp file.

Yep, is set in libs in proc 'gcc_target_compile'

If I print all $options in 'gcc_target_compile' I've:

{additional_flags=-fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never 
-fdiagnostics-urls=never } additional_flags=-mthumb libs=gcc_tg.o
{ldflags=-Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort}
timeout=300 {compiler=.../gcc/xgcc -B.../gcc/}

[Bug target/95874] CLWB isn't supported on Icelake client

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1648-gc422e5f81f42a0fc197f0715f4fcd81f1be90bff
Author: H.J. Lu 
Date:   Wed Jun 24 09:12:47 2020 -0700

x96: Remove PTA_CLWB from PTA_ICELAKE_CLIENT

CLWB isn't supported on Ice Lake client.  But Ice Lake server and Tiger
Lake support it.  Move PTA_CLWB to PTA_ICELAKE_SERVER and PTA_TIGERLAKE.

PR target/95874
* config/i386/i386.h (PTA_ICELAKE_CLIENT): Remove PTA_CLWB.
(PTA_ICELAKE_SERVER): Add PTA_CLWB.
(PTA_TIGERLAKE): Add PTA_CLWB.

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

[rguenth at gcc dot gnu.org]

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

Bug 95866 Summary: vectorized shift with scalar argument not correctly costed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95866

   What|Removed |Added

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

[Bug tree-optimization/95866] vectorized shift with scalar argument not correctly costed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Now fixed.

[Bug tree-optimization/95866] vectorized shift with scalar argument not correctly costed

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:86ce59b4f05d8f68ec4d9a14a7732acb370412db

commit r11-1647-g86ce59b4f05d8f68ec4d9a14a7732acb370412db
Author: Richard Biener 
Date:   Thu Jun 25 11:21:20 2020 +0200

tree-optimization/95866 - avoid using scalar ops for vectorized shift

This avoids using the original scalar SSA operand when vectorizing
a shift with a vectorized shift operand where we know all vector
components have the same value and thus we can use a vector by
scalar shift.  Using the scalar SSA operand causes a possibly
long chain of scalar computation to be retained so it's better
to simply extract lane zero from the available vectorized shift
operand.

2020-06-25  Richard Biener  

PR tree-optimization/95866
* tree-vect-stmts.c (vectorizable_shift): Reject incompatible
vectorized shift operands.  For scalar shifts use lane zero
of a vectorized shift operand.

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

[Bug fortran/95869] ICE when "target parallel" construct used with "if" clause in Fortran

[kcy at codesourcery dot com]

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

--- Comment #2 from Kwok Yeung  ---
Tobias has a small fix for the ICE at:

https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548864.html

I will get this committed after checking for regressions.

[Bug target/95894] vector shift by lane zero generates inter unit move

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-* i?86-*-*
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
clang generates

xorps   %xmm1, %xmm1
movss   %xmm0, %xmm1# xmm1 = xmm0[0],xmm1[1,2,3]
pslld   %xmm1, %xmm0

[Bug target/95894] New: vector shift by lane zero generates inter unit move

[rguenth at gcc dot gnu.org]

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

Bug ID: 95894
   Summary: vector shift by lane zero generates inter unit move
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

typedef int v4si __attribute__((vector_size(16)));
v4si foo (v4si x)
{
  return x << x[0];
}

generates

foo:
.LFB0:
.cfi_startproc
movd%xmm0, %eax
cltq
movq%rax, %xmm1
pslld   %xmm1, %xmm0
ret

while we could use sth like

 pxor %xmm1, %xmm1
 punpckldq %xmm0, %xmm1
 pslld %xmm1, %xmm0

to zero-extend x[0] to DImode in a SSE reg.  Unfortunately even

typedef long v2di __attribute__((vector_size(16)));
v2di bar (v2di x)
{
  return x << x[0];
}

shows this behavior useless behavior:

bar:
.LFB1:
.cfi_startproc
movq%xmm0, %rax
cltq
movq%rax, %xmm1
psllq   %xmm1, %xmm0
ret

because the gimplifier casts the shift amount to unsigned int :(

[Bug fortran/95893] New: pr95690.f90 fails

[clyon at gcc dot gnu.org]

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

Bug ID: 95893
   Summary: pr95690.f90 fails
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

The new testcase pr95690.f90 fails on arm and aarch64 (and powerpc, s390
accordng to gcc-testresults).
compiler exited with status 1
FAIL: gfortran.dg/pr95690.f90   -O   (test for errors, line 5)
FAIL: gfortran.dg/pr95690.f90   -O  (test for excess errors)
Excess errors:
/gcc/testsuite/gfortran.dg/pr95690.f90:6:0: Error: initializer for floating
value is not a floating constant

[Bug c++/95892] New: Wrong line number in "-Wsign-conversion" warning message

[haoxintu at gmail dot com]

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

Bug ID: 95892
   Summary: Wrong line number in "-Wsign-conversion" warning
message
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This code, bug.cc, GCC might give the wrong line number in -Wsign-conversion
warning message.

$cat bug.cc
unsigned int var = 10;
void foo ( 
int a = var, 
int b = var,
int c = var )   
{}

$g++ -c -Wsign-conversion bug.cc 
bug.cc:5:17: warning: conversion to 'int' from 'unsigned int' may change the
sign of the result [-Wsign-conversion]
5 | int c = var )
  | ^
bug.cc:5:17: warning: conversion to 'int' from 'unsigned int' may change the
sign of the result [-Wsign-conversion]
bug.cc:5:17: warning: conversion to 'int' from 'unsigned int' may change the
sign of the result [-Wsign-conversion]

While in clang
$clang++ -c -Wsign-conversion bug.cc 
bug.cc:3:13: warning: implicit conversion changes signedness: 'unsigned int' to
'int' [-Wsign-conversion]
int a = var, 
  ~ ^~~
bug.cc:4:13: warning: implicit conversion changes signedness: 'unsigned int' to
'int' [-Wsign-conversion]
int b = var,
  ~ ^~~
bug.cc:5:13: warning: implicit conversion changes signedness: 'unsigned int' to
'int' [-Wsign-conversion]
int c = var )   
  ~ ^~~
3 warnings generated.

My GCC version is
$g++ --version
g++ (GCC) 11.0.0 20200605 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #8 from Christophe Lyon  ---
(In reply to Alexandre Oliva from comment #5)
> that's because of the second input gcc_tg.o
> 
> can you tell where that comes from?

I guess that's the "testglue" object file added by Dejagnu when
needs_status_wrapper is set in the .exp file.

[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order

[tnfchris at gcc dot gnu.org]

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

--- Comment #12 from Tamar Christina  ---
(In reply to Vladimir Makarov from comment #11)
> (In reply to Tamar Christina from comment #10)
> > Hi Vlad,
> > 
> > Just curious if you had a chance to think about an approach to this that
> > would be acceptable.
> 
>   Sorry for not working on this issue more although I thought about the
> problem for some time w/o finding any possible small code changes could
> solve the problem.
> 

Ah, hmm that's too bad but thanks for looking into it!

>   I just expressed my point of view to the bottom-up approach.  If somebody
> implements any new RA approach which at least does not hurt credible
> benchmarks (e.g. SPEC) and improve some benchmarks and does not complicate
> existing RA too much, nobody will have legitimate arguments not to include
> the new code into GCC.
> 
>   I think that may be for some cases bottom-up approach could work better. 
> Probably this is code for number crunching (with a lot of loop iterations). 
> For some cases top-down approach works better for loops with smaller number
> iterations  (e.g. most loops in GCC itself).
> 

I don't know much about the current RA implementation, but would it be possible
you think to have this be heuristics driven? or do you think it would be too
expensive to try multiple strategies and keep the one that works best?

[Bug ipa/95859] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

[tobi at gcc dot gnu.org]

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

--- Comment #4 from Tobias Schlüter  ---
This is a regression. 9.3 works, producing this assembly with -O2 -m32:
func34(m34):
fld DWORD PTR [esp+8]
mov eax, DWORD PTR [esp+4]
fstpQWORD PTR [eax]
fld DWORD PTR [esp+24]
fstpQWORD PTR [eax+8]
fld DWORD PTR [esp+40]
fstpQWORD PTR [eax+16]
fld DWORD PTR [esp+12]
fstpQWORD PTR [eax+24]
fld DWORD PTR [esp+28]
fstpQWORD PTR [eax+32]
fld DWORD PTR [esp+44]
fstpQWORD PTR [eax+40]
fld DWORD PTR [esp+16]
fstpQWORD PTR [eax+48]
fld DWORD PTR [esp+32]
fstpQWORD PTR [eax+56]
fld DWORD PTR [esp+48]
fstpQWORD PTR [eax+64]
fld DWORD PTR [esp+20]
fstpQWORD PTR [eax+72]
fld DWORD PTR [esp+36]
fstpQWORD PTR [eax+80]
fld DWORD PTR [esp+52]
fstpQWORD PTR [eax+88]
ret 4

I've also thrown some other simple Eigen codes at the compiler, and 10.1 and
trunk consistently keep the asserts in place.

[Bug rtl-optimization/95891] New: Missing optimization

[jm at bourguet dot org]

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

Bug ID: 95891
   Summary: Missing optimization
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jm at bourguet dot org
  Target Milestone: ---

I'm sorry, this is perhaps not the correct component but my knowledge of gcc
internals does not allow me to do more than guess.

For all version of gcc I've tried, the following code:

struct point {
int x, y;
};

bool f(point a, point b) {
return a.x == b.x && a.y == b.y;
}

bool f(unsigned long long a, unsigned long long b) {
return a == b;
}

is compiled to

f(point, point):
xor eax, eax
cmp edi, esi
je  .L5
ret
.L5:
sar rdi, 32
sar rsi, 32
cmp edi, esi
seteal
ret
f(unsigned long long, unsigned long long):
cmp rdi, rsi
seteal
ret

I'd expect f(point, point) to have the same assembly as f(unsigned long long,
unsigned long long).

Yours,

-- Jean-Marc Bourguet

[Bug c++/95888] [9/10/11 Regression] Regression in 9.3. GCC freezes when compiling code using boost::poly_collection::segment

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #4 from Martin Liška  ---
Reduced test-case:

cat pr95888.ii
template  class local_iterator_impl {
  using const_segment_map_iterator =
  typename PolyCollection::const_segment_map_iterator;
  template 
  local_iterator_impl(const_segment_map_iterator, Iterator);
  template  friend class local_iterator_impl;
  friend PolyCollection;
};
template  class poly_collection {
  template  using enable_if_acceptable = int *;
  using segment_map = int;
  using const_segment_map_iterator = segment_map;
  template  friend class local_iterator_impl;
  template 
  using local_iterator_impl = local_iterator_impl;
public:
  template  using const_local_iterator = local_iterator_impl;
  template  class const_segment_info {
  public:
const_local_iterator begin() { return {it, 0}; }
const_segment_map_iterator it;
  };
  template  = nullptr>
  const_segment_info segment();
};

int
main() {
  poly_collection n;
  n.segment().begin();
}

[Bug c++/95888] [9/10/11 Regression] Regression in 9.3. GCC freezes when compiling code using boost::poly_collection::segment

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
I'm reducing that right now..

[Bug debug/95890] New: Probably wrong Line Information at Og

[massarelli at diag dot uniroma1.it]

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

Bug ID: 95890
   Summary: Probably wrong Line Information at Og
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: massarelli at diag dot uniroma1.it
  Target Milestone: ---

$ cat a.c
int a;
void b() {
short l_196 = a = 0;
a+1;
}
int main() { b(); }

$ cat -n a.c
1 int a;
2 void b() {
3 short l_196 = a = 0;
4 a+1;
5 }
6 int main() { b(); }
7

When compiled with gcc trunk and flag -Og -g, gdb 9.2 shows a step over line 4,
while the add instruction does not exist in the assembly. When compiled with
-O0 it correctly jumps to line 5, never showing the step over line 4.
Even in the non optimized binary the add at line 4 is not translated in
assembly.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/tmp/gcc_build --disable-multilib
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib

$ gcc -Og -g a.c -o a.out

$ gdb a.out
GNU gdb (GDB) 9.2
Reading symbols from a.out...
(gdb) b main
Breakpoint 1 at 0x400491: file a.c, line 6.
(gdb) r
Starting program: /home/stepping/output/a.out
Breakpoint 1, main () at a.c:6
6 int main() { b(); }
(gdb) s
b () at a.c:3
3 short l_196 = a = 0;
(gdb) s
4 a+1;
(gdb) disassemble
Dump of assembler code for function b:
0x00400486 <+0>: movl $0x0,0x200b9c(%rip) # 0x60102c
=> 0x00400490 <+10>: retq
End of assembler dump.

[Bug c++/95888] [9/10/11 Regression] Regression in 9.3. GCC freezes when compiling code using boost::poly_collection::segment

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.4
Summary|Regression in 9.3. GCC  |[9/10/11 Regression]
   |freezes when compiling code |Regression in 9.3. GCC
   |using   |freezes when compiling code
   |boost::poly_collection::seg |using
   |ment|boost::poly_collection::seg
   ||ment

[Bug target/95885] LOCAL_DECL_ALIGNMENT macro documentation is incorrect.

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
The documentation is correct, the x86 implementation is not.  Note the
documentation says "One use of this macro...", so clearly it's documentation
can be improved by explicitely constraining the macro to increase alignment.

[Bug fortran/95877] [8/9 regression] ICE in test case gfortran.dg/pr95689.f90 after r9-8693

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
Summary|[9 regression] ICE in test  |[8/9 regression] ICE in
   |case|test case
   |gfortran.dg/pr95689.f90 |gfortran.dg/pr95689.f90
   |after r9-8693   |after r9-8693

[Bug fortran/95880] [9/10/11 Regression] ICE in gfc_add_type, at fortran/symbol.c:2030 since r11-524-geb069ae8819c3a84

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.4

[Bug fortran/95882] [9/10/11 Regression] ICE in gfc_get_derived_type, at fortran/trans-types.c:2729

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |9.4

[Bug fortran/95881] [9/10/11 Regression] ICE in resolve_symbol, at fortran/resolve.c:15175 since r7-5348-g6479f45b31c13f30

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.4
   Priority|P3  |P4

[Bug fortran/95879] [10/11 Regression] ICE in gfc_resolve_formal_arglist, at fortran/resolve.c:313

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.2

[Bug preprocessor/95889] corrupt size vs. prev_size and hang when using __has_include with -traditional-cpp

[dev-zero at gentoo dot org]

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

--- Comment #1 from Tiziano Müller  ---
Unfortunately `__has_include` is even being parsed (in traditional-cpp mode) if
enclosed in a `if 0 ... endif`:

snip
#if 0
#if __has_include()
#endif
#endif
snip

which gives:

snip
# 32 "" 2
# 1 "test2.h"
test2.h:3: error: missing '(' before "__has_include" operand
3 | #if __has_include()
  | 
test2.h:3: error: operator "__has_include" requires a header-name
*** Error in
`/data/tiziano/cp2k/tools/toolchain/install/gcc-10.1.0/lib/gcc/x86_64-pc-linux-gnu/10.1.0/cc1':
corrupted size vs. prev_size: 0x0249a7e0 ***
test2.h:1: confused by earlier errors, bailing out
snip

while enclosing it in parenthesis at least fixes that, such that the following
parses fine:

snip
#if 0
#if (__has_include())
#endif
#endif
snip

[Bug c++/95888] Regression in 9.3. GCC freezes when compiling code using boost::poly_collection::segment

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||10.1.0, 9.3.0
Version|unknown |9.3.0
   Keywords||compile-time-hog
  Known to work||9.2.0
 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
The problem started with r10-7007-6b3302da9ef26aa11940f8c0dc92bec19e15c09b:

PR c++/90505 - mismatch in template argument deduction.
* pt.c (tsubst): Don't reduce the template level of template
parameters when tf_partial.

[Bug fortran/95869] ICE when "target parallel" construct used with "if" clause in Fortran

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-25
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started to ICE with r7-4447-gb4c3a85be9658537, it was rejected before the
revision:

Error: Unclassifiable OpenMP directive at (1)
pr95869.f90:13:10:

 !$omp end target parallel
  1
Error: Unclassifiable OpenMP directive at (1)

[Bug c++/95888] Regression in 9.3. GCC freezes when compiling code using boost::poly_collection::segment

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Jonathan Wakely  ---
You were asked to read https://gcc.gnu.org/bugs/ when creating a new bug
report. Please read it and provide what's missing.

[Bug fortran/95879] [10/11 Regression] ICE in gfc_resolve_formal_arglist, at fortran/resolve.c:313

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-25
 Status|UNCONFIRMED |NEW

--- Comment #2 from Martin Liška  ---
All releases I have (4.8.0+) fail.