[Bug c++/99223] [modules] stdl header-unit ICE

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

Alexander Lelyakin  changed:

   What|Removed |Added

 CC||alexander.lelyakin@googlema
   ||il.com

--- Comment #1 from Alexander Lelyakin  ---
The first sequence is probably duplicate of 99241:  ICE in install_entity

The second is probably duplicate of 99239: ICE in duplicate_decls

[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #15 from Liu Hao  ---
Thanks. The 'Final fix' looks good to me.

I applied it locally and built GCC. With a debugger, I verified that after the
try-catch statement, all non-volatile XMM registers (6-15) had been restored
properly.



```
// x86_64-w64-mingw32-g++ -O2 -fno-omit-frame-pointer test.cc

__attribute__((__noinline__)) void clobber_xmm6()
  {
__asm__ volatile ("xorpd %%xmm6, %%xmm6" ::: "xmm6");
throw 42;   // remove this to get expected result
  }

int main()
  {
static const double xmm5  =  5.123456;
static const double xmm6  =  6.123456;
static const double xmm7  =  7.123456;
static const double xmm8  =  8.123456;
static const double xmm9  =  9.123456;
static const double xmm10 = 10.123456;
static const double xmm11 = 11.123456;
static const double xmm12 = 12.123456;
static const double xmm13 = 13.123456;
static const double xmm14 = 14.123456;
static const double xmm15 = 15.123456;
__asm__ volatile ("movsd %0, %%xmm5 " :: "m"(xmm5 ));
__asm__ volatile ("movsd %0, %%xmm6 " :: "m"(xmm6 ));
__asm__ volatile ("movsd %0, %%xmm7 " :: "m"(xmm7 ));
__asm__ volatile ("movsd %0, %%xmm8 " :: "m"(xmm8 ));
__asm__ volatile ("movsd %0, %%xmm9 " :: "m"(xmm9 ));
__asm__ volatile ("movsd %0, %%xmm10" :: "m"(xmm10));
__asm__ volatile ("movsd %0, %%xmm11" :: "m"(xmm11));
__asm__ volatile ("movsd %0, %%xmm12" :: "m"(xmm12));
__asm__ volatile ("movsd %0, %%xmm13" :: "m"(xmm13));
__asm__ volatile ("movsd %0, %%xmm14" :: "m"(xmm14));
__asm__ volatile ("movsd %0, %%xmm15" :: "m"(xmm15));

try {
  clobber_xmm6();
}
catch(...) { }

double value;
__asm__ volatile ("movsd %%xmm6, %0" : "=x"(value));
__builtin_printf("value = %g\n", value);  // expect `123.456`
  }


```

[Bug lto/41767] assertion in tree-sra.c

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Richard Biener  ---
Fixed.  With improved type-merging these kind of errors no longer happen.

[Bug c++/99223] [modules] stdl header-unit ICE

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #2 from Alexander Lelyakin  ---
This bug have gone in version 20210225.

[Bug c++/99237] [modules] internal compiler error: in write_macro_maps

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #2 from Alexander Lelyakin  ---
This bug have gone in version 20210225.

[Bug c++/99223] [modules] stdl header-unit ICE

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #3 from Alexander Lelyakin  ---
(In reply to Alexander Lelyakin from comment #2)
> This bug have gone in version 20210225.

Sorry this wrong, this comment was for 99237

[Bug c++/99246] [modules] ICE in write_location, at cp/module.cc:15687

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #1 from Alexander Lelyakin  ---
This bug have disappeared in version 20210225

[Bug c++/99281] internal compiler error: in assign_temp, at function.c:984

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Posted a patch.

[Bug c++/99283] New: [modules] ICE in assert_definition, at cp/module.cc:4608

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

Bug ID: 99283
   Summary: [modules] ICE in assert_definition, at
cp/module.cc:4608
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.lelyakin at googlemail dot com
  Target Milestone: ---

g++ -std=c++20 -fmodules-ts -x c++-system-header stdexcept
g++ -std=c++20 -fmodules-ts -x c++-system-header scoped_allocator
g++ -std=c++20 -fmodules-ts -x c++-system-header exception
g++ -std=c++20 -fmodules-ts -x c++-system-header cerrno
g++ -std=c++20 -fmodules-ts -x c++-system-header numbers
g++ -std=c++20 -fmodules-ts -x c++-system-header sstream

In file included from /usr/local/include/c++/11.0.1/bits/ios_base.h:46,
 from /usr/local/include/c++/11.0.1/ios:42,
 from /usr/local/include/c++/11.0.1/istream:38,
 from /usr/local/include/c++/11.0.1/sstream:38:
/usr/local/include/c++/11.0.1/system_error:68:14: internal compiler error: in
assert_definition, at cp/module.cc:4608
   68 | : public true_type { };
  |  ^
0x6df83a trees_in::assert_definition(tree_node*, bool)
../../gcc/gcc/cp/module.cc:4608
0xa591e0 trees_in::odr_duplicate(tree_node*, bool)
../../gcc/gcc/cp/module.cc:11489
0xa69e8f trees_in::read_function_def(tree_node*, tree_node*)
../../gcc/gcc/cp/module.cc:11569
0xa6c2a9 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14957
0xa6c96d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18148
0xa6ca2f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18800
0xa66c70 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9762
0xa65d79 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9301
0xa67807 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6651
0xa63ed7 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7175
0xa63ed7 trees_in::decl_value()
../../gcc/gcc/cp/module.cc:8070
0xa65e07 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9251
0xa6c5c3 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14948
0xa6c96d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18148
0xa6d008 lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*)
../../gcc/gcc/cp/module.cc:18833
0xa7ce8e name_lookup::search_namespace_only(tree_node*)
../../gcc/gcc/cp/name-lookup.c:924
0xa7e5eb name_lookup::search_unqualified(tree_node*, cp_binding_level*)
../../gcc/gcc/cp/name-lookup.c:1155
0xa813e4 lookup_name_1
../../gcc/gcc/cp/name-lookup.c:7868
0xa815aa lookup_name(tree_node*, LOOK_where, LOOK_want)
../../gcc/gcc/cp/name-lookup.c:7888
0xa902c2 lookup_name(tree_node*, LOOK_want)
../../gcc/gcc/cp/name-lookup.h:412
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

g++ (GCC) 11.0.1 20210225 (experimental)
Copyright (C) 2021 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 c++/99284] New: [modules] ICE in key_mergeable, at cp/module.cc:10441

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

Bug ID: 99284
   Summary: [modules] ICE in key_mergeable, at cp/module.cc:10441
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.lelyakin at googlemail dot com
  Target Milestone: ---

g++ -std=c++20 -fmodules-ts -x c++-system-header thread
g++ -std=c++20 -fmodules-ts -x c++-system-header cerrno
g++ -std=c++20 -fmodules-ts -x c++-system-header ostream
g++ -std=c++20 -fmodules-ts -x c++-system-header cwchar
g++ -std=c++20 -fmodules-ts -x c++-system-header regex

/usr/local/include/c++/11.0.1/regex: internal compiler error: in key_mergeable,
at cp/module.cc:10441
0x6e22aa trees_out::key_mergeable(int, merge_kind, tree_node*, tree_node*,
tree_node*, depset*)
../../gcc/gcc/cp/module.cc:10441
0xa5a401 trees_out::decl_value(tree_node*, depset*)
../../gcc/gcc/cp/module.cc:7769
0xa620d3 depset::hash::find_dependencies(module_state*)
../../gcc/gcc/cp/module.cc:13237
0xa62738 module_state::write(elf_out*, cpp_reader*)
../../gcc/gcc/cp/module.cc:17652
0xa63bbc finish_module_processing(cpp_reader*)
../../gcc/gcc/cp/module.cc:19920
0x9f730b c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:5175
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

g++ (GCC) 11.0.1 20210225 (experimental)
Copyright (C) 2021 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 c++/99285] New: [modules] ICE canonical types differ for identical types ‘std::common_type...

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

Bug ID: 99285
   Summary: [modules] ICE canonical types differ for identical
types ‘std::common_type...
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.lelyakin at googlemail dot com
  Target Milestone: ---

g++ -std=c++20 -fmodules-ts -x c++-system-header atomic
g++ -std=c++20 -fmodules-ts -x c++-system-header locale
g++ -std=c++20 -fmodules-ts -x c++-system-header stop_token

In file included from
/usr/local/include/c++/11.0.1/bits/atomic_timed_wait.h:40,
 from /usr/local/include/c++/11.0.1/bits/semaphore_base.h:37,
 from /usr/local/include/c++/11.0.1/semaphore:35,
 from /usr/local/include/c++/11.0.1/stop_token:37:
/usr/local/include/c++/11.0.1/chrono:665:64: internal compiler error: canonical
types differ for identical types ‘std::common_type<_Rep1, _Rep2>’ and
‘std::common_type<_Tp1, _Tp2>’
  665 |  typename _CRep = typename common_type<_Rep1, _Rep2>::type>
  |^
0xb7c74f comptypes(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.c:1540
0xb473b2 fixup_template_type
../../gcc/gcc/cp/semantics.c:3477
0xb473b2 finish_template_type(tree_node*, tree_node*, int)
../../gcc/gcc/cp/semantics.c:3510
0xab96c1 cp_parser_template_id
../../gcc/gcc/cp/parser.c:17397
0xab98ab cp_parser_class_name
../../gcc/gcc/cp/parser.c:24624
0xab0e3a cp_parser_qualifying_entity
../../gcc/gcc/cp/parser.c:6994
0xab0e3a cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:6676
0xabfc5f cp_parser_nested_name_specifier
../../gcc/gcc/cp/parser.c:6920
0xabfc5f cp_parser_elaborated_type_specifier
../../gcc/gcc/cp/parser.c:19372
0xaa5395 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:18398
0xab70f3 cp_parser_type_specifier_seq
../../gcc/gcc/cp/parser.c:23299
0xab5774 cp_parser_type_id_1
../../gcc/gcc/cp/parser.c:23102
0xab5a04 cp_parser_type_id
../../gcc/gcc/cp/parser.c:23195
0xab5a04 cp_parser_default_type_template_argument
../../gcc/gcc/cp/parser.c:16843
0xac350f cp_parser_type_parameter
../../gcc/gcc/cp/parser.c:17079
0xac27af cp_parser_template_parameter
../../gcc/gcc/cp/parser.c:16930
0xac27af cp_parser_template_parameter_list
../../gcc/gcc/cp/parser.c:16563
0xad17f2 cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:30257
0xad3fd9 cp_parser_declaration
../../gcc/gcc/cp/parser.c:14000
0xad3579 cp_parser_toplevel_declaration
../../gcc/gcc/cp/parser.c:14098
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

g++ (GCC) 11.0.1 20210225 (experimental)
Copyright (C) 2021 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 target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Eric Botcazou  ---
> I applied it locally and built GCC. With a debugger, I verified that after
> the try-catch statement, all non-volatile XMM registers (6-15) had been
> restored properly.

Great, thanks!  I'm putting it through as much automatic testing as I can.

[Bug target/93353] ICE: in final_scan_insn_1, at final.c:3073 (error: could not split insn)

[andrew.goodbody at linaro dot org via Gcc-bugs]

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

andrew.goodbody at linaro dot org changed:

   What|Removed |Added

 CC||andrew.goodbody at linaro dot 
org

--- Comment #1 from andrew.goodbody at linaro dot org ---
gcc 10.2.0 built from tarball running native on aarch64 shows the same
behaviour. I will attach the pre-processed source if I can although its over
9MB.

In file included from
external/eigen_archive/unsupported/Eigen/CXX11/Tensor:144,
 from ./third_party/eigen3/unsupported/Eigen/CXX11/Tensor:1,
 from ./tensorflow/core/framework/numeric_types.h:20,
 from ./tensorflow/core/framework/allocator.h:26,
 from ./tensorflow/core/framework/op_kernel.h:25,
 from ./tensorflow/core/kernels/histogram_op.h:19,
 from tensorflow/core/kernels/histogram_op.cc:20:
external/eigen_archive/unsupported/Eigen/CXX11/src/Tensor/TensorExecutor.h: In
static member function 'static void Eigen::internal::EvalRange::run(Evaluator*, StorageIndex, StorageIndex) [with
Evaluator = Eigen::TensorEvaluator, 16,
Eigen::MakePointer>, const Eigen::TensorConversionOp,
const
Eigen::TensorCwiseUnaryOp >, const Eigen::TensorConversionOp, const
Eigen::TensorCwiseBinaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer>, const
Eigen::TensorCwiseNullaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer> > >, const
Eigen::TensorCwiseNullaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer> > > > >, const
Eigen::TensorCwiseNullaryOp, const
Eigen::TensorCwiseUnaryOp >, const Eigen::TensorConversionOp, const
Eigen::TensorCwiseBinaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer>, const
Eigen::TensorCwiseNullaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer> > >, const
Eigen::TensorCwiseNullaryOp, const Eigen::TensorMap, 16, Eigen::MakePointer> > > > > > > > >, Eigen::ThreadPoolDevice>;
StorageIndex = long int]':
external/eigen_archive/unsupported/Eigen/CXX11/src/Tensor/TensorExecutor.h:349:3:
error: could not split insn
  349 |   }
  |   ^
(insn 1615 2102 1433 (set (reg:VNx4SF 34 v2 [orig:554 _1597 ] [554])
(unspec:VNx4SF [
(reg:VNx4BI 72 p4 [orig:376 vec_mask_and_1413 ] [376])
(unspec:VNx4SF [
(reg:VNx4BI 78 p10 [orig:376 vec_mask_and_1413 ] [376])
(const_int 1 [0x1])
(reg:VNx4SF 49 v17 [2017])
(reg:VNx4SF 32 v0 [2049])
] UNSPEC_COND_FADD)
(reg:VNx4SF 39 v7 [orig:392 vect__ifc__887.8029 ] [392])
] UNSPEC_SEL)) 5628 {*cond_addvnx4sf_any}
 (expr_list:REG_DEAD (reg:VNx4BI 78 p10 [orig:376 vec_mask_and_1413 ]
[376])
(expr_list:REG_DEAD (reg:VNx4BI 72 p4 [orig:376 vec_mask_and_1413 ]
[376])
(expr_list:REG_DEAD (reg:VNx4SF 39 v7 [orig:392 vect__ifc__887.8029
] [392])
(expr_list:REG_EQUAL (unspec:VNx4SF [
(reg:VNx4BI 78 p10 [orig:376 vec_mask_and_1413 ]
[376])
(unspec:VNx4SF [
(reg:VNx4BI 78 p10 [orig:376
vec_mask_and_1413 ] [376])
(const_int 1 [0x1])
(reg:VNx4SF 49 v17 [2017])
(const_vector:VNx4SF [
(const_double:SF -6.103515625e-5
[-0x0.8p-13])
])
] UNSPEC_COND_FADD)
(subreg:VNx4SF (reg:VNx4SI 39 v7 [orig:392
vect__ifc__887.8029 ] [392]) 0)
] UNSPEC_SEL)
(nil))
during RTL pass: final
external/eigen_archive/unsupported/Eigen/CXX11/src/Tensor/TensorExecutor.h:349:3:
internal compiler error: in final_scan_insn_1, at final.c:3073
0x69255f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/rtl-error.c:108
0x9debcf final_scan_insn_1
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/final.c:3073
0x9dede3 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/final.c:3152
0x9df0a7 final_1
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/final.c:2020
0x9df823 rest_of_handle_final
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/final.c:4658
0x9df823 execute
/home/builder/src/gcc/10.2.0/gcc-10.2.0/gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/99101] optimization bug with -ffinite-loops

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #20 from Richard Biener  ---
(In reply to Michael Matz from comment #19)
> (In reply to Michael Matz from comment #18)
> > But there are other blocks control dependend on bb4, namely bb5 and bb9.
> > To see this observe that bb9 doesn't pdom bb4, but there's a path from bb4 
> > to
> > bb9 (e.g. bb4 -> bb5 -> bb9), where one node in that path that isn't bb4 is
> 
> ... where _each_ node in that path that isn't bb4 ...  Sorry.
> 
> (Essentially this captures the idea that the path-start node that is the
> control
> node is the _latest_ node that determines (non)execution of the path-end,
> i.e. all
> further nodes after the control node unavoidably pass through path-end).

Yes, bb5 and bb9 are control dependent on bb4.

But nothing in bb5 or bb9 ends up necessary (so the IV 'i' is elminated as
well).
We start with obviously necessary stmts

Marking useful stmt: __builtin_puts (&"1"[0]);

Marking useful stmt: xx.0_1 ={v} xx;

Marking useful stmt: __builtin_abort ();

And the only thing we deem necessary is

Marking useful stmt: if (xx.0_1 != 0)

because we mark this due to the self control-dependence of bb6 to itself
when processing the necessary call.  If we didn't do that we'd end up
optimizing
the testcase to just

int main()
{
  __builtin_puts ("1");
  xx;
  abort ();
}

hmm, actually when removing the if (xx) stmt we end up redirecting the
incoming edge to the loop latch and so we'd produce

   :
  __builtin_puts (&"1"[0]);
  xx.0_1 ={v} xx;
  goto ; [100.00%]

because we're using yet another idea of post-dominance, that by
inverted_post_order_compute and it's kludge how to handle backwards
unreachable blocks ... (it produces 7, 5, 9, 0, 2, 12, 3, 11, 4, 6, 1)
At one point the code used to walk immediate post-dominators.  This
was changed for PR65337 in g:e4dbb0d449e778bc810d0d627a5aaefd0d7847b1

[Bug target/93353] ICE: in final_scan_insn_1, at final.c:3073 (error: could not split insn)

[andrew.goodbody at linaro dot org via Gcc-bugs]

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

--- Comment #2 from andrew.goodbody at linaro dot org ---
Created attachment 50260
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50260&action=edit
Pre-processed source showing bug

Sorry its an archive but its too big as plain text. Produced along with the
output from the previous comment.

[Bug c++/95451] [8/9/10/11 regression] ICE for lambda capturing this and calling operator() since r8-2720-gf44a8dd56f5bfbd0

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:27f9a87886d48448f83e0e559dcf028b1a4a4ec6

commit r11-7418-g27f9a87886d48448f83e0e559dcf028b1a4a4ec6
Author: Jakub Jelinek 
Date:   Fri Feb 26 10:43:28 2021 +0100

c++: Fix operator() lookup in lambdas [PR95451]

During name lookup, name-lookup.c uses:
if (!(!iter->type && HIDDEN_TYPE_BINDING_P (iter))
&& (bool (want & LOOK_want::HIDDEN_LAMBDA)
|| !is_lambda_ignored_entity (iter->value))
&& qualify_lookup (iter->value, want))
  binding = iter->value;
Unfortunately as the following testcase shows, this doesn't work in
generic lambdas, where we on the auto b = ... lambda ICE and on the
auto d = lambda reject it even when it should be valid.  The problem
is that the binding doesn't have a FUNCTION_DECL with
LAMBDA_FUNCTION_P for the operator(), but an OVERLOAD with
TEMPLATE_DECL for such FUNCTION_DECL.

The following patch fixes that in is_lambda_ignored_entity, other
possibility would be to do that before calling is_lambda_ignored_entity
in name-lookup.c.

2021-02-26  Jakub Jelinek  

PR c++/95451
* lambda.c (is_lambda_ignored_entity): Before checking for
LAMBDA_FUNCTION_P, use OVL_FIRST.  Drop FUNCTION_DECL check.

* g++.dg/cpp1y/lambda-generic-95451.C: New test.

[Bug target/93353] ICE: in final_scan_insn_1, at final.c:3073 (error: could not split insn)

[andrew.goodbody at linaro dot org via Gcc-bugs]

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

--- Comment #3 from andrew.goodbody at linaro dot org ---
Command line used was this

/usr/local/bin/gcc-U_FORTIFY_SOURCE -Wall
-Wunused-but-set-parameter -Wno-free-nonheap-object
-fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG 
   -ffunction-sections -fdata-sections '-std=c++0x'-MD -MF
bazel-out/aarch64-opt/bin/tensorflow/core/kernels/_objs/histogram_op/histogram_op.pic.d
   
'-frandom-seed=bazel-out/aarch64-opt/bin/tensorflow/core/kernels/_objs/histogram_op/histogram_op.pic.o'
-fPIC -D__CLANG_SUPPORT_DYN_ANNOTATION__ -DEIGEN_MPL2_ONLY
'-DEIGEN_MAX_ALIGN_BYTES=64' '-DEIGEN_HAS_TYPE_TRAITS=0'
-DEIGEN_USE_BLAS -DEIGEN_USE_LAPACK -iquote . -iquote
bazel-out/aarch64-opt/bin -iquote external/com_google_absl -iquote 
   bazel-out/aarch64-opt/bin/external/com_google_absl-iquote
external/eigen_archive -iquote
bazel-out/aarch64-opt/bin/external/eigen_archive -iquote
external/local_config_sycl -iquote
bazel-out/aarch64-opt/bin/external/local_config_sycl -iquote
external/nsync -iquote bazel-out/aarch64-opt/bin/external/nsync
-iquote external/com_googlesource_code_re2 -iquote
bazel-out/aarch64-opt/bin/external/com_googlesource_code_re2 -iquote
external/gif -iquote bazel-out/aarch64-opt/bin/external/gif -iquote
external/libjpeg_turbo -iquote
bazel-out/aarch64-opt/bin/external/libjpeg_turbo -iquote
external/com_google_protobuf -iquote
bazel-out/aarch64-opt/bin/external/com_google_protobuf -iquote
external/farmhash_archive -iquote
bazel-out/aarch64-opt/bin/external/farmhash_archive -iquote
external/fft2d -iquote bazel-out/aarch64-opt/bin/external/fft2d
-iquote external/highwayhash -iquote
bazel-out/aarch64-opt/bin/external/highwayhash -iquote
external/zlib_archive -iquote
bazel-out/aarch64-opt/bin/external/zlib_archive -isystem
third_party/eigen3/mkl_include -isystem
bazel-out/aarch64-opt/bin/third_party/eigen3/mkl_include -isystem
external/eigen_archive-isystem
bazel-out/aarch64-opt/bin/external/eigen_archive -isystem
external/nsync/public -isystem
bazel-out/aarch64-opt/bin/external/nsync/public -isystem external/gif  
  -isystem bazel-out/aarch64-opt/bin/external/gif -isystem
external/com_google_protobuf/src -isystem
bazel-out/aarch64-opt/bin/external/com_google_protobuf/src -isystem
external/farmhash_archive/src -isystem
bazel-out/aarch64-opt/bin/external/farmhash_archive/src -isystem
external/zlib_archive -isystem
bazel-out/aarch64-opt/bin/external/zlib_archive '-march=armv8.2-a+sve'
-O3 '-std=c++14' '-march=armv8.2-a+sve' -O3
'-D_GLIBCXX_USE_CXX11_ABI=0' -DEIGEN_AVOID_STL_ARRAY
-Iexternal/gemmlowp -Wno-sign-compare '-ftemplate-depth=900'
-fno-exceptions '-DINTEL_MKL=1' -DEIGEN_USE_VML
-DINTEL_MKL_DNN_ONLY -DENABLE_MKL -pthread '-DINTEL_MKL=1'
-DINTEL_MKL_DNN_ONLY -DENABLE_MKL -fno-canonical-system-headers
-Wno-builtin-macro-redefined '-D__DATE__="redacted"'
'-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c
tensorflow/core/kernels/histogram_op.cc -o
bazel-out/aarch64-opt/bin/tensorflow/core/kernels/_objs/histogram_op/histogram_op.pic.o

[Bug c++/95451] [8/9/10 regression] ICE for lambda capturing this and calling operator() since r8-2720-gf44a8dd56f5bfbd0

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10/11 regression] ICE  |[8/9/10 regression] ICE for
   |for lambda capturing this   |lambda capturing this and
   |and calling operator()  |calling operator() since
   |since   |r8-2720-gf44a8dd56f5bfbd0
   |r8-2720-gf44a8dd56f5bfbd0   |

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

[Bug c++/98942] [C++23] Implement P1102R2 - Down with ()!

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
https://gcc.gnu.org/g:0f161cc8494cf7283a16fa9ebbcf8fd121bab68d

commit r11-7419-g0f161cc8494cf7283a16fa9ebbcf8fd121bab68d
Author: Jakub Jelinek 
Date:   Fri Feb 26 10:44:52 2021 +0100

c++: Implement P1102R2 - Down with ()!

The following patch implements P1102R2.
For attributes, we have already attribute parsing before the parameter
declarations and so when that is omitted, if the attributes are first we
already accept it.

2021-02-26  Jakub Jelinek  

* parser.c (cp_parser_lambda_declarator_opt): Implement
P1102R2 - Down with ()! Make ()s optional before lambda specifiers
for -std={c,gnu}++2b or with pedwarn in earlier versions.

* g++.dg/cpp23/lambda-specifiers1.C: New test.

Feature test macro not added yet.
https://github.com/cplusplus/draft/pull/4513 doesn't mention anything.

[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from Jakub Jelinek  ---
(In reply to Liu Hao from comment #15)
> Thanks. The 'Final fix' looks good to me.
> 
> I applied it locally and built GCC. With a debugger, I verified that after
> the try-catch statement, all non-volatile XMM registers (6-15) had been
> restored properly.
> 
> 
> 
> ```
> // x86_64-w64-mingw32-g++ -O2 -fno-omit-frame-pointer test.cc
> 
> __attribute__((__noinline__)) void clobber_xmm6()
>   {
> __asm__ volatile ("xorpd %%xmm6, %%xmm6" ::: "xmm6");
> throw 42;   // remove this to get expected result
>   }
> 
> int main()
>   {
> static const double xmm5  =  5.123456;
> static const double xmm6  =  6.123456;
> static const double xmm7  =  7.123456;
> static const double xmm8  =  8.123456;
> static const double xmm9  =  9.123456;
> static const double xmm10 = 10.123456;
> static const double xmm11 = 11.123456;
> static const double xmm12 = 12.123456;
> static const double xmm13 = 13.123456;
> static const double xmm14 = 14.123456;
> static const double xmm15 = 15.123456;
> __asm__ volatile ("movsd %0, %%xmm5 " :: "m"(xmm5 ));

That would certainly need : "xmm5" in clobbers (etc.).
And isn't really portable anyway, the compiler can choose to put
anything into %xmm6 in between that and the asm before printf.
But, loading the value from memory into some double temporary (with "=x" for
many of them)
in an asm and then e.g. just "+x" them in empty asms and then comparing values
will likely reproduce it too.

> __asm__ volatile ("movsd %0, %%xmm6 " :: "m"(xmm6 ));
> __asm__ volatile ("movsd %0, %%xmm7 " :: "m"(xmm7 ));
> __asm__ volatile ("movsd %0, %%xmm8 " :: "m"(xmm8 ));
> __asm__ volatile ("movsd %0, %%xmm9 " :: "m"(xmm9 ));
> __asm__ volatile ("movsd %0, %%xmm10" :: "m"(xmm10));
> __asm__ volatile ("movsd %0, %%xmm11" :: "m"(xmm11));
> __asm__ volatile ("movsd %0, %%xmm12" :: "m"(xmm12));
> __asm__ volatile ("movsd %0, %%xmm13" :: "m"(xmm13));
> __asm__ volatile ("movsd %0, %%xmm14" :: "m"(xmm14));
> __asm__ volatile ("movsd %0, %%xmm15" :: "m"(xmm15));
> 
> try {
>   clobber_xmm6();
> }
> catch(...) { }
> 
> double value;
> __asm__ volatile ("movsd %%xmm6, %0" : "=x"(value));
> __builtin_printf("value = %g\n", value);  // expect `123.456`

You mean 6.123456 ?  And in any case, I'd suggest whatever.625 or other
constants which won't suffer from rounding etc.

[Bug fortran/99254] ICE in select_rank_set_tmp, at fortran/match.c:6568

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Started with r10-2912-g70570ec192745095.

[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #18 from Liu Hao  ---
(In reply to Jakub Jelinek from comment #17)
> 
> That would certainly need : "xmm5" in clobbers (etc.).
> And isn't really portable anyway, the compiler can choose to put
> anything into %xmm6 in between that and the asm before printf.
> But, loading the value from memory into some double temporary (with "=x" for
> many of them)
> in an asm and then e.g. just "+x" them in empty asms and then comparing
> values will likely reproduce it too.
> 

Yes this needs to be polished a bit for automated testing.

As explained above, I was using a debugger, so all I wanted to do was to tell
the compiler XMM5-XMM15 were clobbered, then it would generate a handler that
could recover them (XMM5 is caller-saved so no need to recover it).

[Bug tree-optimization/99286] New: ivopts don't select the best candidates with -Os

[gengqi at linux dot alibaba.com via Gcc-bugs]

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

Bug ID: 99286
   Summary: ivopts don't select the best candidates with -Os
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gengqi at linux dot alibaba.com
  Target Milestone: ---

Created attachment 50261
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50261&action=edit
-c -march=rv32imafdc -mabi=ilp32d -Os ivopt_os.c -fdump-tree-ivopts-details

I have compared the assembly files and object files generated by different
versions of the gcc.

One is:
$ /lhome/gengq/riscv64-linux-mastertest/bin/riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/lhome/gengq/riscv64-linux-mastertest/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/lhome/gengq/riscv64-linux-mastertest/libexec/gcc/riscv64-unknown-linux-gnu/11.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with:
/lhome/gengq/riscv-gnu-toolchain-master/riscv-gnu-toolchain/riscv-gcc/configure
--target=riscv64-unknown-linux-gnu
--prefix=/lhome/gengq/riscv64-linux-mastertest
--with-sysroot=/lhome/gengq/riscv64-linux-mastertest/sysroot --with-system-zlib
--enable-shared --enable-tls --enable-languages=c,c++,fortran
--disable-libmudflap --disable-libssp --disable-libquadmath
--disable-libsanitizer --disable-nls --disable-bootstrap --src=.././riscv-gcc
--disable-multilib --with-abi=lp64d --with-arch=rv64gc 'CFLAGS_FOR_TARGET=-O2  
-mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2   -mcmodel=medlow'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20210209 (experimental) (GCC)

cmd is:
/lhome/gengq/riscv64-linux-mastertest/bin/riscv64-unknown-linux-gnu-gcc
-march=rv32imafdc -mabi=ilp32d -Os ivopt_os.c -c

The other is：
$ /lhome/gengq/riscv64-linux-810test/bin/riscv32-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/lhome/gengq/riscv64-linux-810test/bin/riscv32-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/lhome/gengq/riscv64-linux-810test/libexec/gcc/riscv32-unknown-linux-gnu/8.1.0/lto-wrapper
Target: riscv32-unknown-linux-gnu
Configured with:
/lhome/gengq/riscv-gnu-toolchain-master/riscv-gnu-toolchain/riscv-gcc/configure
--target=riscv32-unknown-linux-gnu --prefix=/lhome/gengq/riscv64-linux-810test
--with-sysroot=/lhome/gengq/riscv64-linux-810test/sysroot --with-newlib
--without-headers --disable-shared --disable-threads --with-system-zlib
--enable-tls --enable-languages=c --disable-libatomic --disable-libmudflap
--disable-libssp --disable-libquadmath --disable-libgomp --disable-nls
--disable-bootstrap --src=.././riscv-gcc --with-pkgversion= --disable-multilib
--with-abi=ilp32d --with-arch=rv32gc 'CFLAGS_FOR_TARGET=-O2  -mcmodel=medlow'
'CXXFLAGS_FOR_TARGET=-O2  -mcmodel=medlow' CC=gcc CXX=g++
Thread model: single
gcc version 8.1.0 ()

cmd is：
/lhome/gengq/riscv64-linux-810test/bin/riscv32-unknown-linux-gnu-gcc
-march=rv32imafdc -mabi=ilp32d -Os ivopt_os.c -fdump-tree-all-details -c

The code generated by gcc11.0 is worse than by gcc8.1.0. I have done some
analysis and I think the difference due to 'ivopts'.

It seems that gcc11.0 has done a more detailed job in 'ivopts'. For
gcc11.0，there are 2 best candidate sets：
One is equivalent to what gcc8.0 used.
Another one is the final choice of gcc11.0. And its 'cost' is very close to the
other one.
I noticed that: The second set include more invariants and less induction
varibles. The code implementation prefers to use iv. And this preference can
sway the final choice as the differences are minimal.
So,why prefer iv? Is there any better treatment here? What I can think of from
my experience is that the inv variables are more atomic and have more potential
to be optimized. But this also means that the inv may generate more
intermediate variables if it is not optimised. Like this case, we chose to use
more invs and also created more intermediate variables, which ended up
overflowing the registers.

I'm not sure I've hit the nail on the head with my analysis, and I'd like to
try to find a better solution.

[Bug inline-asm/99282] Emit .cfi_sections without arguments for -fno-asynchronous-unwind-tables

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
There is the __GCC_HAVE_DWARF2_CFI_ASM predefined macro that tells if .cfi*
directives are used or not.  And, inline asm that wishes to be usable in both
can use that.

[Bug c++/99281] internal compiler error: in assign_temp, at function.c:984

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-7420-gc173346aac4a66ad3747f380f2f0c97d2dbf8973
Author: Richard Biener 
Date:   Fri Feb 26 08:45:36 2021 +0100

middle-end/99281 - avoid bitfield stores into addressable types

This avoids doing bitfield stores into the return object of calls
when using return-slot optimization and the type is addressable.
Instead we have to pass down the original target RTX to the call
expansion which otherwise tries to create a new temporary.

2021-02-26  Richard Biener  

PR middle-end/99281
* expr.c (store_field): For calls with return-slot optimization
and addressable return type expand the store directly.

* g++.dg/pr99218.C: New testcase.

[Bug c++/99281] internal compiler error: in assign_temp, at function.c:984

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.0
  Known to fail|11.0|

--- Comment #4 from Richard Biener  ---
Fixed on trunk, it's not a regression, the testcase is still rejected by GCC
6.5
and it ICEs with 7.1.0 already (at -O0).  I'm still leaving this open for
eventual backporting to at least GCC 10 where it was reported against.

[Bug rtl-optimization/90319] [C++17] aggregate initialization of base: ICE in assign_temp

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail|10.0, 9.0   |10.1.0, 10.2.0, 9.3.1
  Known to work||10.2.1, 11.0

--- Comment #2 from Richard Biener  ---
Seems to be fixed on the GCC 10 branch and trunk.  Re-confirmed on the GCC 9
branch.  Maybe we have a dup somewhere pointing at the fix.

[Bug middle-end/71812] gcc6/c++/functional:1726:40: internal compiler error: in assign_temp, at function.c:961

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/98891] [10/11 regression] Neon logical operations not vectorized in DImode since g:cdfc0e863a03698a80c74896cbdc9f5c8c652e64

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|11.0|10.3
Summary|[11 regression] Neon|[10/11 regression] Neon
   |logical operations not  |logical operations not
   |vectorized in DImode since  |vectorized in DImode since
   |g:cdfc0e863a03698a80c74896c |g:cdfc0e863a03698a80c74896c
   |bdc9f5c8c652e64 |bdc9f5c8c652e64
   Priority|P3  |P2

[Bug inline-asm/99123] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6710

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.0
   Priority|P3  |P2
   Keywords||ice-on-valid-code, ra
Summary|[8/9/10/11 Regression] ICE  |[8/9/10 Regression] ICE in
   |in  |decompose_normal_address,
   |decompose_normal_address,   |at rtlanal.c:6710
   |at rtlanal.c:6710   |

--- Comment #4 from Richard Biener  ---
Fixed on trunk I suppose.

[Bug ipa/99194] [11 Regression] ICE in force_constant_size, at gimplify.c:733 since r11-38-g375a77925c320a27

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug rtl-optimization/99199] [9/10/11 Regression] Very large boolean expression leads to quite a few return statements

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug debug/99090] gsplit-dwarf broken on riscv64-linux

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Is there any reason why can't .{u,s}leb128 be supported in .debug* sections
when referring to labels in .debug* sections (where I don't see how aggressive
linker relaxation should apply to those sections, those sections heavily rely
on no linker relaxation)?
So essentially have partial as leb128 support instead of none at all?

[Bug middle-end/95757] [11 regression] missing warning in gcc.dg/Wstringop-overflow-25.c since r11-1517

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||85316
 CC||amacleod at redhat dot com
   Priority|P3  |P1

--- Comment #7 from Richard Biener  ---
So the warning machinery (or likely the range machinery) is confused about

  size_t r_1_2 = UR (1, 2);
  size_t r_2_3 = UR (2, 3);

  T (char, S (2), r_1_2);   // { dg-warning "\\\[-Wstringop-overflow"
"pr92814" }

  T (char, S (0), r_2_3);

but it treats the case well when the second T is elided or when the size
computation is moved before the Ts like with

diff --git a/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c
b/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c
index bc609587575..116fbf600a6 100644
--- a/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c
+++ b/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c
@@ -367,16 +367,16 @@ struct Flex
 NOIPA void test_strcpy_malloc_flexarray (void)
 {
   size_t r_0_1 = UR (0, 1);
-  size_t r_1_2 = UR (1, 2);
-  size_t r_2_3 = UR (2, 3);

   T (char, S (0), r_0_1);
   T (char, S (1), r_0_1);   // { dg-warning "\\\[-Wstringop-overflow"
"pr92814" }

+  size_t r_1_2 = UR (1, 2);
   T (char, S (0), r_1_2);
   T (char, S (1), r_1_2);
   T (char, S (2), r_1_2);   // { dg-warning "\\\[-Wstringop-overflow"
"pr92814" }

+  size_t r_2_3 = UR (2, 3);
   T (char, S (0), r_2_3);
   T (char, S (2), r_2_3);
   T (char, S (3), r_2_3);   // { dg-warning "\\\[-Wstringop-overflow"
"pr92814" }


Martin, is there any harm in changing the testcase this way?  The issue
reproduces with a cross and the two-line snippet at the top (just prune
the rest from the testcase).  In case you want to have a closer look
why the warning is not issued on ppc64le (where I tested) vs. x86_64.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
[Bug 85316] [meta-bug] VRP range propagation missed cases

[Bug sanitizer/97490] [10/11 Regression] false-positive -Wstringop-overflow= with address sanitizer since r10-5451-gef29b12cfbb4979a

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/97679] [10/11 Regression] [concepts] ICE with CTAD for a nested class template with constrained constructor

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug testsuite/97680] [11 Regression] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Target|powerpc64*-linux-gnu,powerp |arm
   |c-apple-darwin, arm |

--- Comment #9 from Richard Biener  ---
Meanwhile the testcase has

/* { dg-skip-if "not implemented" { powerpc*-*-* } } */

but it will still fail on all targets but x86_64 (and now powerpc).  Qinzhao,
what's the list of targets this is supported?

We could add a

/* { dg-final { dg-message "sorry, unimplemented" { target { ! {  } } } }
*/

or so to make the sorry expected.

[Bug testsuite/97680] [11 Regression] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug libstdc++/99277] [11 Regression] C++2a synchronisation is inefficient in GCC 11 and can't be fixed later

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Regarding 32-bit vs. 64-bit futex, I guess it depends on what the 64-bit object
holds, if it holds a counter, the usual way how to handle it is to do futex on
the least significant half of the counter.

[Bug bootstrap/98338] [10/11 Regression] profiledbootstrap failure on x86_64-linux

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #18 from Jakub Jelinek  ---
Honza, any progress with this?
If you want, I can test the patch too...

[Bug bootstrap/98318] [11 Regression] libcody breaks DragonFly bootstrap

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #17 from Richard Biener  ---
The bootstrap issue is fixed.  Please move unrelated issues to new bugs.

[Bug pch/98527] [11 Regression] ICE in handle_pragma_pop_options

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-02-26
 Status|UNCONFIRMED |WAITING

--- Comment #2 from Richard Biener  ---
waiting for testcase

[Bug c++/98528] [11 Regression] g++.dg/modules/hello-1 FAILs

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Richard Biener  ---
Any update?

[Bug other/98533] [8/9/10/11 Regression] ICE: 'verify_type' failed

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/99287] New: std::source_location::function_name breaks constexpr

[nickgray0 at brown dot edu via Gcc-bugs]

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

Bug ID: 99287
   Summary: std::source_location::function_name breaks constexpr
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickgray0 at brown dot edu
  Target Milestone: ---

the following code seems to break constexpr-ness for std::string_view::find

#include 
#include 

template
consteval auto f() {
return std::string_view{
std::source_location::current().function_name() };
}

auto main()->int {
constexpr auto s = f();
constexpr auto x = s.find("int");
}



error message: In file included from
/opt/compiler-explorer/gcc-trunk-20210226/include/c++/11.0.1/string_view:781,
 from :2:
/opt/compiler-explorer/gcc-trunk-20210226/include/c++/11.0.1/bits/string_view.tcc:
In function 'int main()':
:11:30:   in 'constexpr' expansion of
's.std::basic_string_view::find(((const char*)"int"), 0)'
/opt/compiler-explorer/gcc-trunk-20210226/include/c++/11.0.1/string_view:384:26:
  in 'constexpr' expansion of '((const
std::basic_string_view*)this)->std::basic_string_view::find(__str,
__pos, std::char_traits::length(__str))'
/opt/compiler-explorer/gcc-trunk-20210226/include/c++/11.0.1/bits/string_view.tcc:62:20:
error: '(((std::basic_string_view::size_type)((&"consteval auto f() [with
 = int]"[56]) - ((&"consteval auto f() [with
 = int]"[21]) + 1))) > 2)' is not a constant expression
   62 |   while (__len >= __n)
  |  ~~^~



Replacing std::source_location with the legacy
std::experimental::source_location seems to fix the problem.

[Bug bootstrap/98590] [11 regression] Bootstrap failure with Ada on Cygwin since switch to C++11

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from Richard Biener  ---
Looks like the fix was approved here
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564929.html but not yet
committed.

[Bug rtl-optimization/98782] [11 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|11.0|12.0
   Priority|P3  |P2

--- Comment #5 from Richard Biener  ---
Re-targeting to GCC 12.

[Bug c++/98800] [8/9/10/11 Regression] ICE on invalid use of non-static member function in trailing return type since r8-2724

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/98803] [10/11 Regression] [C++20] ICE on invalid code with checked build [in synthesize_implicit_template_parm, at cp/parser.c:45335]

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug target/98827] [11 regression] gcc.target/powerpc/vsx-builtin-7.c assembler counts off after r11-6857

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
I assume fixed.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #35 from Richard Biener  ---
So this doesn't just affect bootstrap but any executable built by GCC 11 with
the new -gdwarf-5 default.

[Bug sanitizer/98920] [10/11 Regression] uses regexec without support for REG_STARTEND with -fsanitize=address

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[ssbssa at yahoo dot de via Gcc-bugs]

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

--- Comment #36 from Hannes Domani  ---
Note: This is a binutils/ld bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=27268

And I've sent a patch there:
https://sourceware.org/pipermail/binutils/2021-February/115434.html

[Bug c++/99237] [modules] internal compiler error: in write_macro_maps

[nathan at gcc dot gnu.org via Gcc-bugs]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Most likely is a dup then

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

[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files

[nathan at gcc dot gnu.org via Gcc-bugs]

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

Bug 99237 Summary: [modules] internal compiler error: in write_macro_maps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99237

   What|Removed |Added

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

[Bug c++/98718] [modules] use of partitions causes ICE in write_macro_maps

[nathan at gcc dot gnu.org via Gcc-bugs]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||alexander.lelyakin@googlema
   ||il.com

--- Comment #5 from Nathan Sidwell  ---
*** Bug 99237 has been marked as a duplicate of this bug. ***

[Bug c++/99246] [modules] ICE in write_location, at cp/module.cc:15687

[nathan at gcc dot gnu.org via Gcc-bugs]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
I suspect also as a result of 98718

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

[Bug c++/98718] [modules] use of partitions causes ICE in write_macro_maps

[nathan at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Nathan Sidwell  ---
*** Bug 99246 has been marked as a duplicate of this bug. ***

[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files

[nathan at gcc dot gnu.org via Gcc-bugs]

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

Bug 99246 Summary: [modules] ICE in write_location, at cp/module.cc:15687
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99246

   What|Removed |Added

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

[Bug rtl-optimization/98973] [11 regression] Wrong code with gcse store motion pass

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Richard Biener  ---
Btw, this is likely a latent issue, the store-motion code didn't change since
ages and the bisected rev. likely just changed the input to the pass.

So the dump difference is

-(note 76 75 217 19 [bb 19] NOTE_INSN_BASIC_BLOCK)
-(insn 217 76 78 19 (set (reg:SI 3 %r3 [133])
-(reg:SI 2 %r2 [orig:69 ivtmp.24+4 ] [69])) "t.c":11:19 1467
{*movsi_zarch}
- (nil))
-(insn 78 217 218 19 (parallel [
-(set (reg:SI 3 %r3 [133])
-(plus:SI (reg:SI 3 %r3 [133])
-(const_int -1 [0x])))
-(clobber (reg:CC 33 %cc))
-]) "t.c":11:19 1821 {*addsi3}
- (nil))
-(insn 218 78 79 19 (set (mem/c:SI (reg/f:DI 8 %r8 [103]) [1 c+0 S4 A32])
-(reg:SI 3 %r3 [133])) "t.c":11:19 1467 {*movsi_zarch}
- (nil))
-(insn 79 218 83 19 (parallel [
-(set (reg:DI 2 %r2 [orig:69 ivtmp.24 ] [69])
-(plus:DI (reg:DI 2 %r2 [orig:69 ivtmp.24 ] [69])
+(note 76 75 79 19 [bb 19] NOTE_INSN_BASIC_BLOCK)
+(insn 79 76 83 19 (parallel [
+(set (reg:DI 3 %r3 [orig:69 ivtmp.24 ] [69])
+(plus:DI (reg:DI 3 %r3 [orig:69 ivtmp.24 ] [69])
 (const_int -1 [0x])))
 (clobber (reg:CC 33 %cc))
 ]) "t.c":11:12 1820 {*adddi3}
  (nil))
 (insn 83 79 84 19 (set (reg:CCS 33 %cc)
-(compare:CCS (reg:SI 2 %r2 [orig:69 ivtmp.24+4 ] [69])
+(compare:CCS (reg:SI 3 %r3 [orig:69 ivtmp.24+4 ] [69])
 (const_int 2 [0x2]))) "t.c":11:12 1415 {*cmpsi_ccs}

where you can see that %r2 is no longer decremented but the store
(sunk) after the loop still uses %r2:

(insn 175 105 218 23 (set (mem/c:SI (reg/f:DI 8 %r8 [103]) [1 c+0 S4 A32])
(reg:SI 2 %r2 [orig:110 c ] [110])) 1467 {*movsi_zarch}
 (nil))

--

scanning new insn with uid = 175.
STORE_MOTION  insert store at start of BB 26:
(insn 175 105 0 26 (set (mem/c:SI (reg/f:DI 103) [1 c+0 S4 A32])
(reg:SI 110 [ c ])) -1
 (nil))

I'll note the gcse dumps are after RA but the store-motion dump is pre-RA.

[Bug fortran/98979] [11 regression] ICE in several tests cases after r11-7112

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #8 from Richard Biener  ---
Has this been fixed?

[Bug libstdc++/99277] C++2a synchronisation is inefficient in GCC 11 and can't be fixed later

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[11 Regression] C++2a   |C++2a synchronisation is
   |synchronisation is  |inefficient in GCC 11 and
   |inefficient in GCC 11 and   |can't be fixed later
   |can't be fixed later|

--- Comment #3 from Jonathan Wakely  ---
I already replied on the mailing list. These are inline specifically so we
don't tie ourselves to symbols exported from the DSO before the features are
stable.

They aren't going to be considered stable for GCC 11 so your suggestion is to
disable everything, get no usage experience to help improve it, then at some
point re-enable it when it's no more mature than it is now. I don't see how
that helps anything.

We've done things this way for years. When C++20 support is no longer
experimental is when the ABI will be fixed.

[Bug c++/98528] [modules] g++.dg/modules/hello-1 FAILs

[nathan at gcc dot gnu.org via Gcc-bugs]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
Summary|[11 Regression] |[modules]
   |g++.dg/modules/hello-1  |g++.dg/modules/hello-1
   |FAILs   |FAILs
 Ever confirmed|0   |1
   Last reconfirmed||2021-02-26
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org

[Bug ada/98996] [11 Regression] mips64 ada ftbfs

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/99180] [10/11 Regression] ICE with alias template and empty parameter pack

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Richard Biener  ---
I guess cris-elf simply has different type sizes / bitfield layout here.  The
dumps hint at sizeof (ubits) == 1 for cris.  So you should eventually get
the same on x86_64 when you use unsigned char : ...; bitfields in ubits.

[Bug debug/99230] [11 Regression] gcc.dg/pr83527.c excess errors: '-fcompare-debug' failure (length)

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug testsuite/99233] [11 regression] new test case gcc.target/powerpc/pr96264.c in r11-7285 fails

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/98979] [11 regression] ICE in several tests cases after r11-7112

[burnus at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Tobias Burnus  ---
(In reply to Richard Biener from comment #8)
> Has this been fixed?

The XFAIL of comment 7 should have fixed the intermittent fails.

 * * *

The proper fix was:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565250.html (+ next two
emails)

Committed on Feb 21, 2021:

https://gcc.gnu.org/g:d28f3da11d8c0aed9b746689d723022a9b5ec04c
openacc: Fix lowering for derived-type mappings through array elements

https://gcc.gnu.org/g:366cf1127a547ff77024a551abb01bb1a6e963cd
openacc: Strided array sections and components of derived-type arrays


Can you confirmed that it is now fixed for powerpc64*-linux-gnu,
x86_64-apple-darwin20.3.0, powerpc*-aix ?

[Bug middle-end/97855] [11 regression] Bogus warning locations during lto-bootstrap

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
 CC||dmalcolm at gcc dot gnu.org
   Last reconfirmed||2021-02-26

--- Comment #2 from Richard Biener  ---
Confirmed.  The issue seems to be that in diagnostic_report_diagnostic () we do

1244  pp_format (context->printer, &diagnostic->message);
1245  (*diagnostic_starter (context)) (context, diagnostic);

where the first call ends up with the %qD part of "%qD may be used
uninitialized in this function" still in the pretty-printers buffer which then
the
diagnostic_starter will use without resetting it.

For the specific message the expression is formatted via default_tree_printer
and dump_generic_node (we have sth usable in DECL_DEBUG_EXPR).

The following seems to fix it but I'm not sure what the actual mistake in
using the diagnostic provided pretty-printer is.  The dump_generic_node
doesn't cause any flushing.

diff --git a/gcc/tree-diagnostic.c b/gcc/tree-diagnostic.c
index 95b8ef30070..f124e627aad 100644
--- a/gcc/tree-diagnostic.c
+++ b/gcc/tree-diagnostic.c
@@ -300,7 +300,11 @@ default_tree_printer (pretty_printer *pp, text_info *text,
const char *spec,
   pp_string (pp, n);
 }
   else
-dump_generic_node (pp, t, 0, TDF_SLIM, 0);
+{
+  pretty_printer buffer;
+  dump_generic_node (&buffer, t, 0, TDF_SLIM, 0);
+  pp_string (pp, pp_formatted_text (&buffer));
+}

   return true;
 }

This then issues

/home/rguenther/src/trunk/gcc/calls.c: In function 'expand_call':
/home/rguenther/src/trunk/gcc/dojump.c:118:28: warning: 'MEM[(struct poly_int
*)&save].D.6750.coeffs[0]' may be used uninitialized in this function
[-Wmaybe-uninitialized]
  118 |   pending_stack_adjust = save->x_pending_stack_adjust;
  |^
/home/rguenther/src/trunk/gcc/calls.c:4150:34: note: 'MEM[(struct poly_int
*)&save].D.6750.coeffs[0]' was declared here
 4150 |   saved_pending_stack_adjust save;
  |  ^
/home/rguenther/src/trunk/gcc/dojump.c:119:27: warning: 'MEM[(struct poly_int
*)&save + 8B].D.6750.coeffs[0]' may be used uninitialized in this function
[-Wmaybe-uninitialized]
  119 |   stack_pointer_delta = save->x_stack_pointer_delta;
  |   ^
/home/rguenther/src/trunk/gcc/calls.c:4150:34: note: 'MEM[(struct poly_int
*)&save + 8B].D.6750.coeffs[0]' was declared here
 4150 |   saved_pending_stack_adjust save;
  |  ^

instead of the broken

/home/rguenther/src/trunk/gcc/calls.c: In function 'expand_call':
D.6750.coeffs[0]'/home/rguenther/src/trunk/gcc/dojump.c:118:28: warning:  may
be used uninitialized in this function [-Wmaybe-uninitialized]
  118 |   pending_stack_adjust = save->x_pending_stack_adjust;
  |^
D.6750.coeffs[0]'/home/rguenther/src/trunk/gcc/calls.c:4150:34: note:  was
declared here
 4150 |   saved_pending_stack_adjust save;
  |  ^
D.6750.coeffs[0]'/home/rguenther/src/trunk/gcc/dojump.c:119:27: warning:  may
be used uninitialized in this function [-Wmaybe-uninitialized]
  119 |   stack_pointer_delta = save->x_stack_pointer_delta;
  |   ^
D.6750.coeffs[0]'/home/rguenther/src/trunk/gcc/calls.c:4150:34: note:  was
declared here
 4150 |   saved_pending_stack_adjust save;
  |  ^

for the ltrans unit I was am investigating.  I put this to more testing
but as said, I don't understand why or how it goes wrong at all ...

[Bug c/99288] New: xgettext does not get HOST_WIDE_INT_PRINT_UNSIGNED

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 99288
   Summary: xgettext does not get HOST_WIDE_INT_PRINT_UNSIGNED
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

gcse.c says:
> warning (OPT_Wdisabled_optimization,
>  "%s: %d basic blocks and %d registers; "
>  "increase %<--param max-gcse-memory%> above "
>  HOST_WIDE_INT_PRINT_UNSIGNED,
>  pass, n_basic_blocks_for_fn (cfun), max_reg_num (),
>  memory_request / 1024);

HOST_WIDE_INT_PRINT_UNSIGNED is a host-dependent string literal that is
resolved by the C preprocessor. When xgettext scans the source code, it does
not notice this and generates:

> msgid ""
> "%s: %d basic blocks and %d registers; increase %<--param max-gcse-memory%> "
> "above "

The placeholder at the end of the sentence is missing, which means that this
message cannot be translated into other languages right now.

[Bug c/99288] xgettext does not get HOST_WIDE_INT_PRINT_UNSIGNED

[roland.illig at gmx dot de via Gcc-bugs]

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

--- Comment #1 from Roland Illig  ---
same in ipa-devirt.c:
> inform (this_enum.vals[j].locus,
> "name %qs is defined to " HOST_WIDE_INT_PRINT_DEC

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from David Malcolm  ---
Possibly a dumb question, but how am I meant to get at the size in bits of a
bitfield?  TYPE_SIZE appears to be expressed in bytes, rather than bits (or
maybe I messed up when debugging?)

On a 1-bit unsigned bitfield I'm seeing:

(gdb) call debug_tree(m_type)
  constant 8>
unit-size  constant 1>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea7a83f0 precision:1 min  max >

On a 3-bit unsigned bitfield I'm seeing:
(gdb) call debug_tree(m_type)
  constant 8>
unit-size  constant 1>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea7a8498 precision:3 min  max >

so it looks like the "precision" is what I should be using for such types (but
when?)

Is there an equivalent to int_size_in_bytes for bits that I'm missing?  Thanks

[Bug libstdc++/99289] New: Process safety issues of libstdc++ verbose

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 99289
   Summary: Process safety issues of libstdc++ verbose
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

We get problematic chaos error logging when multiple processes throw EH at the
same time.

I propose to use writev(2) syscall to fix the problem.

[Bug libstdc++/99289] Process safety issues of libstdc++ verbose

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
On windows, it should get emulated with LockFile win32 api to lock files. Or it
is trash.

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from David Malcolm  ---
Answering my own question:
  https://gcc.gnu.org/onlinedocs/gccint/Types.html

INTEGER_TYPE

Used to represent the various integral types, including char, short, int,
long, and long long. This code is not used for enumeration types, nor for the
bool type. The TYPE_PRECISION is the number of bits used in the representation,
represented as an unsigned int. (Note that in the general case this is not the
same value as TYPE_SIZE; suppose that there were a 24-bit integer type, but
that alignment requirements for the ABI required 32-bit alignment. Then,
TYPE_SIZE would be an INTEGER_CST for 32, while TYPE_PRECISION would be 24.)
The integer type is unsigned if TYPE_UNSIGNED holds; otherwise, it is signed.

[Bug libstdc++/99290] New: std::filesystem::copy does not always report errors for recursion

[fabian--- via Gcc-bugs]

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

Bug ID: 99290
   Summary: std::filesystem::copy does not always report errors
for recursion
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fab...@ritter-vogt.de
  Target Milestone: ---

For the case where a directory is copied to another directory with either
copy_options::recursive or copy_options::none, fs_copy.cc has this in
std::filesystem::copy:

  for (const directory_entry& x : directory_iterator(from))
copy(x.path(), to/x.path().filename(), options, ec);

This does not check the value of "ec" after each call to copy. As successful
invocations of copy clear the error, only the last call to copy influences the
error code. As the order of entries returned by directory_iterator is
unspecified, it's also unspecified whether an error is reported if recursive
copying fails.

Test program:

#include 

int main(int argc, char *argv[])
{
std::filesystem::copy(std::filesystem::path{argv[1]},
  std::filesystem::path{argv[2]},
  std::filesystem::copy_options::none);
}

Compile and run like this:

> g++ fstest.cpp -std=c++17 -o fstest # Compile
> mkdir source dest
> mkdir source/emptydir dest/emptydir # Empty directories, noop for fs::copy
> touch source/file; echo "dst" > dest/file # Conflicting files to make 
> fs::copy fail
> ./fstest source dest # Doesn't fail, because the empty directories overwrote 
> the error code
> rmdir source/emptydir dest/emptydir # Drop the empty directories
> ./fstest source dest # Now it fails
terminate called after throwing an instance of
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: cannot copy: File exists [source] [dest]

Whether you see the same effect is highly dependent on your (file) system.

[Bug c++/99287] std::source_location::function_name breaks constexpr

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-02-26

--- Comment #1 from Jakub Jelinek  ---
To me this looks like type inconsistency somewhere.
The error is because fold_binary doesn't simplify
POINTER_DIFF_EXPR with ptrdiff_type and following 2 args:
 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea06b3f0 precision:8 min  max

pointer_to_this  reference_to_this
>
public unsigned type_6 DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea06b498
pointer_to_this >
constant
arg:0 

arg:0 
readonly constant static "consteval auto f() [with
 = int]\000">
arg:1 
   
/home/jakub/src/gcc/obj36i/usr/local/include/c++/11.0.1/bits/string_view.tcc:59:43
start:
/home/jakub/src/gcc/obj36i/usr/local/include/c++/11.0.1/bits/string_view.tcc:59:36
finish:
/home/jakub/src/gcc/obj36i/usr/local/include/c++/11.0.1/bits/string_view.tcc:59:50>
   
/home/jakub/src/gcc/obj36i/usr/local/include/c++/11.0.1/bits/string_view.tcc:59:43
start:
/home/jakub/src/gcc/obj36i/usr/local/include/c++/11.0.1/bits/string_view.tcc:59:36
finish:
/home/jakub/src/gcc/obj36i/usr/local/include/c++/11.0.1/bits/string_view.tcc:59:50>

and

 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea06b3f0 precision:8 min  max

pointer_to_this  reference_to_this
>
public unsigned type_6 DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea06b498
pointer_to_this >
constant
arg:0 
public unsigned type_6 DI size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea06b498>
constant
arg:0 
constant
arg:0 

arg:0 
readonly constant static "consteval auto f() [with
 = int]\000">
arg:1 
   
/home/jakub/src/gcc/obj36i/usr/local/include/c++/11.0.1/bits/char_traits.h:183:22
start:
/home/jakub/src/gcc/obj36i/usr/local/include/c++/11.0.1/bits/char_traits.h:183:18
finish:
/home/jakub/src/gcc/obj36i/usr/local/include/c++/11.0.1/bits/char_traits.h:183:26>
   
/home/jakub/src/gcc/obj36i/usr/local/include/c++/11.0.1/bits/char_traits.h:183:22
start:
/home/jakub/src/gcc/obj36i/usr/local/include/c++/11.0.1/bits/char_traits.h:183:18
finish:
/home/jakub/src/gcc/obj36i/usr/local/include/c++/11.0.1/bits/char_traits.h:183:26>>
arg:1 >

and that seems to be because cxx_fold_pointer_plus_expression didn't do its job
as it only optimizes ADDR_EXPR ... plus constant, but in this case
we have NOP_EXPR of ADDR_EXPR ... plus constant.
As can be seen, the POINTER_PLUS_EXPR type is pointer to const char, but its
first operand does have a different type, pointer to char_type, i.e.
  constant 8>
unit-size  constant 1>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea06b3f0 precision:8 min  max

pointer_to_this  reference_to_this
>
vs.
  constant 8>
unit-size  constant 1>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea06b3f0 precision:8 min  max

pointer_to_this  reference_to_this
>
difference (the first one is the normal const char).

That char_type is in particular:
  template
struct char_traits
{
  typedef _CharTchar_type;
from bits/char_traits.h.

I thought in the FE we require that binary expressions other than
shifts/rotates etc. have really the same types rather than just compatible
types.

I see the problematic MODIFY_EXPR with lhs VIEW_CONVERT_EXPR(__first) with the pointer to const char type and rhs
std::char_traits::find (VIEW_CONVERT_EXPR(__first),
(VIEW_CONVERT_EXPR(__len) - VIEW_CONVERT_EXPR(__n)) + 1,
(const char_type &) &__elem0); (with the pointer to char_type type) created in
tsubst_copy_and_build:
19973   warning_sentinel s(warn_div_by_zero);
19974   tree lhs = RECUR (TREE_OPERAND (t, 0));
19975   tree rhs = RECUR (TREE_OPERAND (t, 2));
19976   tree r = build_x_modify_expr
19977 (EXPR_LOCATION (t), lhs, TREE_CODE (TREE_OPERAND (t, 1)),
rhs,
19978  complain|decltype_flag);
19979   /* TREE_NO_WARNING must be set if either the expression was
19980  parenthesized or it uses an operator such as >>= rather
19981  than plain assignment.  In the former case, it was already
19982   

[Bug libstdc++/99290] std::filesystem::copy does not always report errors for recursion

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-02-26
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug c++/99287] std::source_location::function_name breaks constexpr

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
That t (MODOP_EXPR) is in the source:
  // Find the first occurrence of __elem0:
  __first = traits_type::find(__first, __len - __n + 1, __elem0);

[Bug testsuite/97680] [11 Regression] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors

[qing.zhao at oracle dot com via Gcc-bugs]

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

--- Comment #10 from Qing Zhao  ---
> but it will still fail on all targets but x86_64 (and now powerpc).  Qinzhao,
> what's the list of targets this is supported?

I believe that the targets that currently support this feature are:
x86-64
aarch64
sparc

The original patch supported x86-64 and aarch64, later the following patch
https://gcc.gnu.org/pipermail/gcc-cvs/2020-December/338342.html


Support sparc

[Bug other/99288] xgettext does not get HOST_WIDE_INT_PRINT_UNSIGNED

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
  Component|c   |other
 Ever confirmed|0   |1
   Last reconfirmed||2021-02-26

[Bug other/99288] xgettext does not get HOST_WIDE_INT_PRINT_UNSIGNED

[jakub at gcc dot gnu.org via Gcc-bugs]

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

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

Untested fix.

[Bug c/99291] New: maybe_warn_pass_by_reference uses outdated format string

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 99291
   Summary: maybe_warn_pass_by_reference uses outdated format
string
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

tree-ssa-uninit.c says:
> inform (loc, "in a call to %qD declared with "
> "attribute %<%s%> here", fndecl, access_str);

This format string uses the sequence %<%s%>, for which there is the shortcut
%qs.

Using the %<%s%> should be detected and prevented by check_plain in c-format.c.

Is that check not active by default?

[Bug debug/99090] gsplit-dwarf broken on riscv64-linux

[wilson at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jim Wilson  ---
Yes we could have partial uleb128 support.  There is only a problem if at least
one label is in the code section.

There is another proposed solution to add special relaxable relocations for
uleb128 but the initial proposal had flaws, and no one has reviewed the second
proposal yet.

Or we could change the -gsplit-dwarf support to work even when there is no
uleb128 support.

[Bug testsuite/99292] New: FAIL: gcc.c-torture/compile/pr98096.c -O0 (test for excess errors)

[danglin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99292
   Summary: FAIL: gcc.c-torture/compile/pr98096.c   -O0  (test for
excess errors)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr98096.c
-f
diagnostics-plain-output -O0 -w -S -o pr98096.s
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr98096.c: In
functio
n 'f':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr98096.c:6:3:
error:
 the target does not support 'asm goto' with outputs in 'asm'
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr98096.c:8:3:
error:
 the target does not support 'asm goto' with outputs in 'asm'
compiler exited with status 1
FAIL: gcc.c-torture/compile/pr98096.c   -O0  (test for excess errors)

Needs a skip on hppa*-*-*.

[Bug middle-end/99293] New: Built-in vec_splat generates sub-optimal code for -mcpu=power10

[munroesj at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99293
   Summary: Built-in vec_splat generates sub-optimal code for
-mcpu=power10
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: munroesj at gcc dot gnu.org
  Target Milestone: ---

Created attachment 50263
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50263&action=edit
Simplified test case

While adding code to Power Vector Library (PVECLIB), for the POWER10 target, I
see strange code generation for Altivec built-in vec_splat for the vector long
long type. I would expect a xxpermdi (xxspltd) based on the "Power Vector
Intrinsic Programming Reference".

But I see the following generated:

0300 :
 300:   67 02 69 7c mfvsrld r9,vs35
 304:   67 4b 09 7c mtvsrdd vs32,r9,r9
 308:   05 00 42 10 vrlqv2,v2,v0
 30c:   20 00 80 4e blr

While these seems to functionally correct, the trip through the GPR seems
unnecessary. It requires two serially dependent instructions where a single
xxspltd would do. I expected:

0300 :
 300:   57 1b 63 f0 xxspltd vs35,vs35,1
 304:   05 18 42 10 vrlqv2,v2,v3
 308:   20 00 80 4e blr


The compiler was:

Compiler: gcc version 10.2.1 20210104 (Advance-Toolchain 14.0-2) [2093e873bb6c]
(GCC)

[Bug middle-end/99293] Built-in vec_splat generates sub-optimal code for -mcpu=power10

[munroesj at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Steven Munroe  ---
Created attachment 50264
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50264&action=edit
Compile test for simplied test case

Download vec_dummy.c and vec_int128_ppc.h into a local directory and compile

gcc -O3 -mcpu=power10 -m64 -c vec_dummy.c

[Bug bootstrap/98338] [10/11 Regression] profiledbootstrap failure on x86_64-linux

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #19 from Jan Hubicka  ---
> Honza, any progress with this?
> If you want, I can test the patch too...
Sorry, it bootstrapped, so I will commit it.

Honza

[Bug bootstrap/98338] [10/11 Regression] profiledbootstrap failure on x86_64-linux

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #20 from Jakub Jelinek  ---
FYI, I have today bootstrapped it as well in rpm build on
{x86_64,i686,powerpc64le}-linux, both your patch and just trunk without the
workaround I've been using before.  The latter failed to bootstrap on i686
and passed it on x86_64 and powerpc64le, the former passed bootstrap on all
arches.  make check is still ongoing...

Re: [Bug bootstrap/98338] [10/11 Regression] profiledbootstrap failure on x86_64-linux

[Jan Hubicka]

> FYI, I have today bootstrapped it as well in rpm build on
> {x86_64,i686,powerpc64le}-linux, both your patch and just trunk without the
> workaround I've been using before.  The latter failed to bootstrap on i686
> and passed it on x86_64 and powerpc64le, the former passed bootstrap on all
> arches.  make check is still ongoing...
Good, so it fixes i686 bootstrap, right?

Honza

[Bug bootstrap/98338] [10/11 Regression] profiledbootstrap failure on x86_64-linux

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #21 from Jan Hubicka  ---
> FYI, I have today bootstrapped it as well in rpm build on
> {x86_64,i686,powerpc64le}-linux, both your patch and just trunk without the
> workaround I've been using before.  The latter failed to bootstrap on i686
> and passed it on x86_64 and powerpc64le, the former passed bootstrap on all
> arches.  make check is still ongoing...
Good, so it fixes i686 bootstrap, right?

Honza

[Bug fortran/98979] [11 regression] ICE in several tests cases after r11-7112

[seurer at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from seurer at gcc dot gnu.org ---
I looked at the most recent powerpc64 runs (all varieties) and it is no longer
failing there.

[Bug bootstrap/98338] [10/11 Regression] profiledbootstrap failure on x86_64-linux

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #22 from Jakub Jelinek  ---
Yes.  https://kojipkgs.fedoraproject.org//work/tasks/2451/62722451/build.log
is the failed i686 bootstrap and
https://kojipkgs.fedoraproject.org//work/tasks/2553/62722553/build.log is one
with your patch.

[Bug debug/99090] gsplit-dwarf broken on riscv64-linux

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jakub Jelinek  ---
Making it work is desirable in any case.  But, the emitted debug sections will
be in various spots less compact when .uleb128/.sleb128 don't support
non-constant operands.
Though, I'm afraid the
  /* FIXME: This will ICE ifndef HAVE_AS_LEB128.
 For that case we probably need to emit DW_LLE_startx_endx,
 but we'd need 2 .debug_addr entries rather than just one.  */
  dw2_asm_output_delta_uleb128 (curr->end, curr->begin,
"Location list length (%s)",
list_head->ll_symbol);
case is actually code addresses and not .debug section labels, sorry for
confusion.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||jyong at gcc dot gnu.org,
   ||ktietz70 at googlemail dot com,
   ||lh_mouse at 126 dot com

--- Comment #37 from Jakub Jelinek  ---
Adding some CCs.  While a patch has been posted, we haven't seen an explanation
what exactly is going on and why.

[Bug debug/99090] gsplit-dwarf broken on riscv64-linux

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-02-26
 Status|UNCONFIRMED |ASSIGNED

--- Comment #4 from Jakub Jelinek  ---
Created attachment 50265
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50265&action=edit
gcc11-pr99090.patch

Untested fix.

[Bug fortran/93340] [8/9/10/11 Regression] ICE in check_constant_initializer, at fortran/trans-decl.c:5450

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r10-9391-gc5ba7770768ed0a7b5d61a3a2fa1625d98be351f
Author: Harald Anlauf 
Date:   Thu Jan 14 20:25:33 2021 +0100

PR fortran/93340 - fix missed substring simplifications

Substrings were not reduced early enough for use in initializations,
such as DATA statements.  Add an early simplification for substrings
with constant starting and ending points.

gcc/fortran/ChangeLog:

* gfortran.h (gfc_resolve_substring): Add prototype.
* primary.c (match_string_constant): Simplify substrings with
constant starting and ending points.
* resolve.c: Rename resolve_substring to gfc_resolve_substring.
(gfc_resolve_ref): Use renamed function gfc_resolve_substring.

gcc/testsuite/ChangeLog:

* substr_10.f90: New test.
* substr_9.f90: New test.

(cherry picked from commit bdd1b1f55529da00b867ef05a53a08fbfc3d1c2e)

[Bug fortran/93340] [8/9/10/11 Regression] ICE in check_constant_initializer, at fortran/trans-decl.c:5450

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:2259e712a6348bd23586dde06cc874a35fdc53c3

commit r9-9252-g2259e712a6348bd23586dde06cc874a35fdc53c3
Author: Harald Anlauf 
Date:   Thu Jan 14 20:25:33 2021 +0100

PR fortran/93340 - fix missed substring simplifications

Substrings were not reduced early enough for use in initializations,
such as DATA statements.  Add an early simplification for substrings
with constant starting and ending points.

gcc/fortran/ChangeLog:

* gfortran.h (gfc_resolve_substring): Add prototype.
* primary.c (match_string_constant): Simplify substrings with
constant starting and ending points.
* resolve.c: Rename resolve_substring to gfc_resolve_substring.
(gfc_resolve_ref): Use renamed function gfc_resolve_substring.

gcc/testsuite/ChangeLog:

* substr_10.f90: New test.
* substr_9.f90: New test.

(cherry picked from commit bdd1b1f55529da00b867ef05a53a08fbfc3d1c2e)

[Bug libstdc++/99277] C++2a synchronisation is inefficient in GCC 11

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #4 from Thiago Macieira  ---
(In reply to Jonathan Wakely from comment #3)
> We've done things this way for years. When C++20 support is no longer
> experimental is when the ABI will be fixed.

Based on the discussion, I've removed the "can't be fixed later" part of the
summary.

(In reply to Jakub Jelinek from comment #2)
> Regarding 32-bit vs. 64-bit futex, I guess it depends on what the 64-bit
> object holds, if it holds a counter, the usual way how to handle it is to do
> futex on the least significant half of the counter.

But if it holds a pointer value, then we can't do that trick. We'd need to do a
pointer+counter (generation) trick, which requires a 16-byte compare-exchange
to update, with the futex pointing to the lower half of the counter portion.
I'm just saying that we may have sufficient argument now to change Linus' mind
on having a 64-bit futex support. 

Whether that applies to 32-bit architectures or not, I don't know and is not in
my interest area to research.