[Bug c++/105418] debug_tree does not support well for std::construct_at

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

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

Jiu Fu Guo  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

[Bug c++/105418] debug_tree does not support well for std::construct_at

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

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

--- Comment #6 from Jiu Fu Guo  ---
(In reply to Jiu Fu Guo from comment #5)
...
> This issue happens when calling debug_tree/decl_as_string manually inside
> FE.  At where overloaded functions (::new) are not resolved yet, and then
> cause 'tsubst' to be called. 
> I see, it is not a good place to use debug_tree.
Or add something in FE for it (not a must :)

[Bug c++/105418] debug_tree does not support well for std::construct_at

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

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

--- Comment #5 from Jiu Fu Guo  ---
0x1089f887 dump_substitution
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/error.cc:1654
0x108a1c2f dump_function_decl
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/error.cc:1817
0x1089e187 dump_decl
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/error.cc:1385
0x108aa8df decl_as_string(tree_node*, int)
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/error.cc:3146
0x1094d6ef trees_out::insert(tree_node*, walk_kind)
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/module.cc:4801
0x1096300f trees_out::decl_node(tree_node*, walk_kind)
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/module.cc:8582
0x10965da3 trees_out::tree_node(tree_node*)
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/module.cc:9104
0x109542c7 trees_out::core_vals(tree_node*)
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/module.cc:5924
0x10959d4f trees_out::tree_node_vals(tree_node*)
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/module.cc:7074
0x10964dab trees_out::tree_value(tree_node*)
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/module.cc:8911
0x10965ddf trees_out::tree_node(tree_node*)
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/module.cc:9109
0x109542c7 trees_out::core_vals(tree_node*)
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/module.cc:5924
0x10959d4f trees_out::tree_node_vals(tree_node*)
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/module.cc:7074
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


Hi Andrew and Richard,

Thanks a lot! 
This issue happens when calling debug_tree/decl_as_string manually inside FE. 
At where overloaded functions (::new) are not resolved yet, and then cause
'tsubst' to be called. 
I see, it is not a good place to use debug_tree.

[Bug tree-optimization/105431] New: ICE: SIGSEGV in powi_as_mults_1 (tree-ssa-math-opts.cc:1512) with -Ofast and __builtin_pow()

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 105431
   Summary: ICE: SIGSEGV in powi_as_mults_1
(tree-ssa-math-opts.cc:1512) with -Ofast and
__builtin_pow()
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 52903
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52903=edit
reduced testcase

This might be related to PR105368; on 11-branch and older, the other PR is
triggered. The failing address is also very similar to the other PR.

This fails for me only with a bootstrapped compiler; there might be another UB
that is exploited only when bootstrapping.

$ x86_64-pc-linux-gnu-gcc -Ofast testcase.c -wrapper valgrind,-q
==24694== Invalid read of size 1
==24694==at 0x158683D: powi_as_mults_1(gimple_stmt_iterator*, unsigned int,
tree_node*, long, tree_node**) (tree-ssa-math-opts.cc:1512)
==24694==by 0x158B56E: powi_as_mults(gimple_stmt_iterator*, unsigned int,
tree_node*, long) (tree-ssa-math-opts.cc:1551)
==24694==by 0x158C8B1: gimple_expand_builtin_pow(gimple_stmt_iterator*,
unsigned int, tree_node*, tree_node*) (tree-ssa-math-opts.cc:2049)
==24694==by 0x158CF59: (anonymous
namespace)::pass_cse_sincos::execute(function*) (tree-ssa-math-opts.cc:2317)
==24694==by 0x12EB49A: execute_one_pass(opt_pass*) (passes.cc:2638)
==24694==by 0x12EBD5F: execute_pass_list_1(opt_pass*) (passes.cc:2738)
==24694==by 0x12EBD71: execute_pass_list_1(opt_pass*) (passes.cc:2739)
==24694==by 0x12EBD98: execute_pass_list(function*, opt_pass*)
(passes.cc:2749)
==24694==by 0xF15F75: expand (cgraphunit.cc:1835)
==24694==by 0xF15F75: cgraph_node::expand() (cgraphunit.cc:1788)
==24694==by 0xF17536: expand_all_functions (cgraphunit.cc:1999)
==24694==by 0xF17536: symbol_table::compile() [clone .part.0]
(cgraphunit.cc:2349)
==24694==by 0xF1A117: compile (cgraphunit.cc:2262)
==24694==by 0xF1A117: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2530)
==24694==by 0x13F3E1F: compile_file() (toplev.cc:479)
==24694==  Address 0x828ce240 is not stack'd, malloc'd or (recently)
free'd
==24694== 
during GIMPLE pass: sincos
testcase.c: In function 'foo':
testcase.c:2:1: internal compiler error: Segmentation fault
2 | foo (int i)
  | ^~~
0x13f3b5f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:322
0x158683d powi_as_mults_1
/repo/gcc-trunk/gcc/tree-ssa-math-opts.cc:1512
0x158b56e powi_as_mults(gimple_stmt_iterator*, unsigned int, tree_node*, long)
/repo/gcc-trunk/gcc/tree-ssa-math-opts.cc:1551
0x158c8b1 gimple_expand_builtin_pow
/repo/gcc-trunk/gcc/tree-ssa-math-opts.cc:2049
0x158cf59 execute
/repo/gcc-trunk/gcc/tree-ssa-math-opts.cc:2317
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-trunk-r13-21-20220428204650-g9ae8b993cd3-checking-yes-rtl-df-extra-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-21-20220428204650-g9ae8b993cd3-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-21-20220428204650-g9ae8b993cd3-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220428 (experimental) (GCC)

[Bug target/105428] compilation never (?) finishes with __builtin_casinl() and __builtin_csqrtl() with -O -mlong-double-128

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #2 from Zdenek Sojka  ---
(In reply to jos...@codesourcery.com from comment #1)
> What MPC version are you using?

Thank you for the reply. If I understand the backtrace correctly I am using the
libraries downloaded by the contrib/download_prerequisites script: mpc-1.2.1,
mpfr-4.1.0; the same behavior can be observed with system libraries as well,
which are the same version + gentoo patches.

> There have been a few fixes for slowness 
> in the MPC inverse trigonometric and hyperbolic functions over the years, 
> though there may still be scope for substantial further improvements by 
> choosing different algorithms for different ranges of inputs.  If you're 
> using current MPC then this case should probably be reported to the MPC 
> maintainers.

Similar to PR105384 and PR105385 - if you tell me to open a PR against MPC /
MPRF, I will try to do. But I can't tell if this is a bug in the library, or
expected behavior and gcc shouldn't use the library to evaluate the value at
compilation time.

[Bug c++/102651] [9/10/11/12/13 Regression] typeid(X**) instantiates X caused by r0-109856

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

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

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

https://gcc.gnu.org/g:97b30a399ef561f6f37a2c08c830fdf3141bb504

commit r13-24-g97b30a399ef561f6f37a2c08c830fdf3141bb504
Author: Jason Merrill 
Date:   Fri Apr 15 00:11:00 2022 -0400

c++: typeid and instantiation [PR102651]

PR49387 was a problem with initially asking for a typeid for a class
template specialization before it was complete, and later actually filling
in the descriptor when the class was complete, and thus disagreeing on the
form of the descriptor.  I fixed that by forcing the class to be complete,
but this testcase shows why that approach is problematic.  So instead let's
adjust the type of the descriptor later if needed.

PR c++/102651
PR c++/49387

gcc/cp/ChangeLog:

* rtti.cc (get_tinfo_decl_direct): Don't complete_type.
(emit_tinfo_decl): Update tdesc type if needed.

gcc/testsuite/ChangeLog:

* g++.dg/rtti/typeid-complete1.C: New test.

[Bug c++/49387] t.cxx:140: error: too many initializers for ‘const __class_type_info_pseudo’

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

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

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

https://gcc.gnu.org/g:97b30a399ef561f6f37a2c08c830fdf3141bb504

commit r13-24-g97b30a399ef561f6f37a2c08c830fdf3141bb504
Author: Jason Merrill 
Date:   Fri Apr 15 00:11:00 2022 -0400

c++: typeid and instantiation [PR102651]

PR49387 was a problem with initially asking for a typeid for a class
template specialization before it was complete, and later actually filling
in the descriptor when the class was complete, and thus disagreeing on the
form of the descriptor.  I fixed that by forcing the class to be complete,
but this testcase shows why that approach is problematic.  So instead let's
adjust the type of the descriptor later if needed.

PR c++/102651
PR c++/49387

gcc/cp/ChangeLog:

* rtti.cc (get_tinfo_decl_direct): Don't complete_type.
(emit_tinfo_decl): Update tdesc type if needed.

gcc/testsuite/ChangeLog:

* g++.dg/rtti/typeid-complete1.C: New test.

[Bug c++/25689] missed diagnostic about assignment used as truth value.

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

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

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

https://gcc.gnu.org/g:654f6978cdc85a3970ff2c478d4df3e55cf4d3ab

commit r13-23-g654f6978cdc85a3970ff2c478d4df3e55cf4d3ab
Author: Zhao Wei Liew 
Date:   Tue Feb 15 17:44:29 2022 +0800

c++: Add diagnostic when operator= is used as truth cond [PR25689]

When compiling the following code with g++ -Wparentheses, GCC does not
warn on the if statement. For example, there is no warning for this code:

struct A {
A& operator=(int);
operator bool();
};

void f(A a) {
if (a = 0); // no warning
}

This is because a = 0 is a call to operator=, which GCC does not handle.

This patch fixes this issue by handling calls to operator= when deciding
to warn.

Bootstrapped and regression tested on x86_64-pc-linux-gnu.

PR c++/25689

gcc/cp/ChangeLog:

* call.cc (extract_call_expr): Return a NULL_TREE on failure
instead of asserting.
(build_new_method_call): Suppress -Wparentheses diagnostic for
MODIFY_EXPR.
* semantics.cc (is_assignment_op_expr_p): Add function to check
if an expression is a call to an op= operator expression.
(maybe_convert_cond): Handle the case of a op= operator expression
for the -Wparentheses diagnostic.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wparentheses-31.C: New test.

Signed-off-by: Zhao Wei Liew 

[Bug c/105430] [11/12/13 Regression] [DR 413] Change in value for "Partial overriding of constant struct/union initializers with designated initializers"

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

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

--- Comment #1 from Andrew Pinski  ---
I Assume here this is using a GNU extension of allowing the const struct copy
in a constant expression.

[Bug c/105430] New: [11/12/13 Regression] [DR 413] Change in value for "Partial overriding of constant struct/union initializers with designated initializers"

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

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

Bug ID: 105430
   Summary: [11/12/13 Regression] [DR 413] Change in value for
"Partial overriding of constant struct/union
initializers with designated initializers"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
  Target Milestone: ---

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

This bug is different to PR63944 where the description says "This bug is
specific to initializers of objects with automatic storage duration" but where
comments mention problems with static duration, so it's apparently part of a
set of related problems or same base problem: here we have a constant static
object.

Also, part of this sub-problem is that the initialized value changed between
gcc-10 and gcc-11, which does not appear to be the case for the code in
PR63944.

The test-case in this PR shows a regression since gcc-10 (and earlier
releasess) behaves correctly; only the overridden field changed value, as
intended.

It manifests for all targets.

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 91278 Summary: equal comparison of local arrays (with offset) inside 
constexpr is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91278

   What|Removed |Added

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

[Bug c++/91278] equal comparison of local arrays (with offset) inside constexpr is rejected

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Fixed by r12-6382-g51d464b608b38b

[Bug sanitizer/90347] [UBSAN] __attribute__((weak))__ results in "declared weak after being used" error

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug target/105325] power10: Error: operand out of range

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

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

Segher Boessenkool  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/86515] [9/10 Regression] std::initializer_list constructor is not a constant expression

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
I don't expect backports to 9 or 10, so fixed.

[Bug c++/84930] Brace-closed initialization of cstring (i.e."abcdefghi") to coresponding aggregate types fails in certain situation

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/87656] Useful flags to enable with -Wall or -Wextra

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

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

--- Comment #14 from Eric Gallager  ---
(In reply to David Binderman from comment #11)
> -Wold-style-definition
> 
> KnR style function definitions have been deprecated for about 35 years.
> 
> Yes, there is a warning for it in gcc, but that warning isn't in either
> -Wall or -Wextra. 
> 
> Also, switching on -std=c2x only makes it a warning, not an error. 
> That doesn't sound correct to me. AFAIK KnR is removed from c2x.

Related: Bug 82922 for -Wstrict-prototypes, which warns in some of the same
cases as -Wold-style-definition
(82922 is already in the "Depends On" field)

[Bug testsuite/105427] [12 regression] gcc.target/powerpc/pr92398.p9-.c fails after r12-8265-gad56a60f58c1ed

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

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

--- Comment #2 from Segher Boessenkool  ---
Maybe it needs a dg-skip-if for the has_arch_XXX, instead of in the dg-do
target clause?

[Bug c++/71424] std::initializer_list

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed by r12-6329-g4f6bc28fc7dd86, will add the test.

[Bug testsuite/105427] [12 regression] gcc.target/powerpc/pr92398.p9-.c fails after r12-8265-gad56a60f58c1ed

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

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

--- Comment #1 from Segher Boessenkool  ---
mtvsrdd requires ISA 3.0 though (i.e. power9).

[Bug target/105428] compilation never (?) finishes with __builtin_casinl() and __builtin_csqrtl() with -O -mlong-double-128

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #1 from joseph at codesourcery dot com  ---
What MPC version are you using?  There have been a few fixes for slowness 
in the MPC inverse trigonometric and hyperbolic functions over the years, 
though there may still be scope for substantial further improvements by 
choosing different algorithms for different ranges of inputs.  If you're 
using current MPC then this case should probably be reported to the MPC 
maintainers.

[Bug analyzer/105366] [11 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer since r11-4511-gf635f0ce87d687b1

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #6 from David Malcolm  ---
Should be fixed for gcc 11.4 by the above commit; closing.

[Bug analyzer/105365] [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -fanalyzer since r12-2337-g33255ad3ac14e395

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by David Malcolm
:

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

commit r11-9950-g7f6033735bf5174f19ef0ab8efd92b075bcb277d
Author: David Malcolm 
Date:   Thu Apr 28 17:42:44 2022 -0400

analyzer: fix ICEs on complex constants [PR105365,105366]

gcc/analyzer/ChangeLog:
PR analyzer/105365
PR analyzer/105366
* svalue.cc
(cmp_cst): Rename to...
(cmp_csts_same_type): ...this.  Convert all recursive calls to
calls to...
(cmp_csts_and_types): this new function.
(svalue::cmp_ptr): Update for renaming of cmp_cst

gcc/testsuite/ChangeLog:
PR analyzer/105365
PR analyzer/105366
* gcc.dg/analyzer/pr105365.c: New test.
* gcc.dg/analyzer/pr105366.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/105366] [11 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer since r11-4511-gf635f0ce87d687b1

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by David Malcolm
:

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

commit r11-9950-g7f6033735bf5174f19ef0ab8efd92b075bcb277d
Author: David Malcolm 
Date:   Thu Apr 28 17:42:44 2022 -0400

analyzer: fix ICEs on complex constants [PR105365,105366]

gcc/analyzer/ChangeLog:
PR analyzer/105365
PR analyzer/105366
* svalue.cc
(cmp_cst): Rename to...
(cmp_csts_same_type): ...this.  Convert all recursive calls to
calls to...
(cmp_csts_and_types): this new function.
(svalue::cmp_ptr): Update for renaming of cmp_cst

gcc/testsuite/ChangeLog:
PR analyzer/105365
PR analyzer/105366
* gcc.dg/analyzer/pr105365.c: New test.
* gcc.dg/analyzer/pr105366.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/105252] [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer -fnon-call-exceptions since r12-1931-ge61ffa201403e381

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:03e7ac9021361cfee6cb55ca08638bbb0dab12a9

commit r11-9949-g03e7ac9021361cfee6cb55ca08638bbb0dab12a9
Author: David Malcolm 
Date:   Thu Apr 28 17:42:07 2022 -0400

analyzer: fix ICE comparing VECTOR_CSTs [PR105252]

gcc/analyzer/ChangeLog:
PR analyzer/105252
* svalue.cc (cmp_cst): When comparing VECTOR_CSTs, compare the
types of the encoded elements before calling cmp_cst on them.

gcc/testsuite/ChangeLog:
PR analyzer/105252
* gcc.dg/analyzer/pr105252.c: New test.

Signed-off-by: David Malcolm 

[Bug middle-end/105424] Bogus -Wstringop-overread with non-overread condition

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug middle-end/105424] Bogus -Wstringop-overread with non-overread condition

[byteslice at airmail dot cc via Gcc-bugs]

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

--- Comment #3 from Liam White  ---
Compile with c++ -std=gnu++20 -O1 -Werror=stringop-overread to reproduce.

[Bug middle-end/105424] Bogus -Wstringop-overread with non-overread condition

[byteslice at airmail dot cc via Gcc-bugs]

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

Liam White  changed:

   What|Removed |Added

  Attachment #52897|0   |1
is obsolete||

--- Comment #2 from Liam White  ---
Created attachment 52901
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52901=edit
Preprocessed source

[Bug middle-end/105424] Bogus -Wstringop-overread with non-overread condition

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2022-04-28

--- Comment #1 from Andrew Pinski  ---
> long n(end_raw - beg_raw);
> if (n < 4)

This means n could be negative which then converted to unsigned would be a
large #.

The code here is reduced too much though:
  value_type *dest_raw, *beg_raw = movelib::iterator_to_raw_pointer(f),
*end_raw = 0;

So basically you have (long)(beg_raw) < 4. Which might be true if the upper bit
is set.

Please attach the original preprocessed source as I have shown it was reduced
too much.


Plus I suspect adding a check for "n >= 0" will fix the warning too.

[Bug c++/67048] [9/10/11/12/13 Regression] GCC rejects well-formed program using empty anonymous enum specifier in a variable declaration

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

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #3 from Marek Polacek  ---
Started with r197742.  I'll take a look.

[Bug target/105429] Unnecessary moves generated with _mm_crc32_u64

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug other/105429] New: Unnecessary moves generated by the compiler.

[mareksz1958 at wp dot pl via Gcc-bugs]

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

Bug ID: 105429
   Summary: Unnecessary moves generated by the compiler.
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mareksz1958 at wp dot pl
  Target Milestone: ---

The following C code:

>>>
#include 
#include 
uint32_t crc(uint32_t current, const uint8_t *buffer, size_t size) {
for(size_t i = 0; i < size; i++)
current = _mm_crc32_u64(current, buffer[i]);
return current;
}
<<<

Generates inefficient assembly on all optimisation presets due to the extra
`mov eax, eax' - Os and O3 below:

>>>
crc:
movl%edi, %eax
xorl%ecx, %ecx
.L2:
cmpq%rdx, %rcx
je  .L5
movzbl  (%rsi,%rcx), %edi
movl%eax, %eax
incq%rcx
crc32q  %rdi, %rax
jmp .L2
.L5:
ret

crc:
movl%edi, %eax
testq   %rdx, %rdx
je  .L6
leaq(%rsi,%rdx), %rcx
.L3:
movzbl  (%rsi), %edx
movl%eax, %eax
addq$1, %rsi
crc32q  %rdx, %rax
cmpq%rsi, %rcx
jne .L3
.L6:
ret
<<<

The problem seems to be present in all GCC versions I have access to. The
redundant move greatly worsens the performance of the generated code. When
`_mm_crc32_u64' is replaced by any other function, the problem seems to
disappear.

[Bug target/105428] New: compilation never (?) finishes with __builtin_casinl() and __builtin_csqrtl() with -O -mlong-double-128

[zsojka at seznam dot cz via Gcc-bugs]

ile (this=0x77a1f000) at
/repo/gcc-trunk/gcc/cgraphunit.cc:2262
#30 symbol_table::finalize_compilation_unit (this=0x77a1f000) at
/repo/gcc-trunk/gcc/cgraphunit.cc:2530
#31 0x01405890 in compile_file () at /repo/gcc-trunk/gcc/toplev.cc:479
#32 0x00d5b7ae in do_compile (no_backend=false) at
/repo/gcc-trunk/gcc/toplev.cc:2168
#33 toplev::main (this=this@entry=0x7fffd65e, argc=,
argc@entry=18, argv=, argv@entry=0x7fffd7a8) at
/repo/gcc-trunk/gcc/toplev.cc:2320
#34 0x00d5d6ef in main (argc=18, argv=0x7fffd7a8) at
/repo/gcc-trunk/gcc/main.cc:39


(gdb) fini
Run till exit from #0  0x77d91d00 in __memset_avx2_unaligned_erms ()
from /lib64/libc.so.6
mpfr_add1 (a=a@entry=0x7fffc780, b=0x7fffc7c0, c=,
rnd_mode=MPFR_RNDA) at /repo/gcc-trunk/mpfr/src/add1.c:152
152   difn = cn;
(gdb) fini
Run till exit from #0  mpfr_add1 (a=a@entry=0x7fffc780, b=0x7fffc7c0,
c=, rnd_mode=MPFR_RNDA) at /repo/gcc-trunk/mpfr/src/add1.c:152
0x02764e5c in mpc_sqr (rop=rop@entry=0x7fffc880,
op=op@entry=0x7fffc990, rnd=rnd@entry=0) at
/repo/gcc-trunk/mpc/src/sqr.c:270
270| mpfr_sub (v, x, mpc_imagref (op), MPFR_RNDA);
Value returned is $1 = 0
(gdb) 
Run till exit from #0  0x02764e5c in mpc_sqr
(rop=rop@entry=0x7fffc880, op=op@entry=0x7fffc990, rnd=rnd@entry=0) at
/repo/gcc-trunk/mpc/src/sqr.c:270

Program terminated with signal SIGKILL, Killed.
The program no longer exists.

(consumed memory is ~80GiB)


$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-7-20220428134959-g00c4405cd7f-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-7-20220428134959-g00c4405cd7f-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220428 (experimental) (GCC)

[Bug c++/103236] [9/10/11/12/13 Regression] ICE: in tsubst_pack_expansion, at cp/pt.c:13162

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed by r12-8258-g65735d21ac4104

[Bug target/103938] [9/10/11/12/13 Regression] ICE with __builtin_prefetch and vectors

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Alex Coplan from comment #7)
> A bisect shows this started with
> r12-2288-g8695bf78dad1a42636775843ca832a2f4dba4da3 :
> 
> commit 8695bf78dad1a42636775843ca832a2f4dba4da3
> Author: Jonathan Wright 
> Date:   Wed Jun 2 16:55:00 2021 +0100
> 
> gcc: Add vec_select -> subreg RTL simplification
> 
> which makes it a [12/13 Regression], unless I'm missing something? Should it
> be a P1?

It only ices for checking and does not produce wrong code when release checking
so it would be a p2 in my mind.
Plus it was latent before that patch as I could reproduce on a gcc 10 (maybe I
have some other optimizations added which expose it in gcc 10).

[Bug c++/105373] miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor

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

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

--- Comment #12 from Iain Sandoe  ---
(In reply to Avi Kivity from comment #8)
> Hoping this is a duplicate of PR105287. Checking.

I doubt it, it would seem more likely that the temporary value representing the
non-coroutine lambda object is not being promoted to a frame copy.  The
additional tightening of constraints in the PR105287 fix (which I've now made a
patch to back out of) could well be the cause of the earlier fails you now see.

[Bug c++/105426] [wrong-code][regression][coroutines] range-for temporaries are not persisted in coroutines

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
   Last reconfirmed||2022-04-28
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Iain Sandoe  ---
So the fix for PR105287 was too ambitious - and reveals that we are missing to
name some variables that should be promoted.

Rather than delay for a second fix, the proposal would be a partial reversion
of r12-8308-g15a176a833f23e, like so (which would be more suitable for the
branch).  This does fix the new issue (and still fixes the analyser one) in my
local testing.


diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 551ddc9cc41..2e393b2cddc 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -3973,6 +3973,9 @@ register_local_var_uses (tree *stmt, int *do_subtree,
void *d)
  else if (lvname != NULL_TREE)
buf = xasprintf ("%s_%u_%u", IDENTIFIER_POINTER (lvname),
 lvd->nest_depth, lvd->bind_indx);
+ else
+   buf = xasprintf ("_D%u_%u_%u", DECL_UID (lvar), lvd->nest_depth,
+lvd->bind_indx);
  /* TODO: Figure out if we should build a local type that has any
 excess alignment or size from the original decl.  */
  if (buf)

[Bug c++/105425] [12/13 Regression] ambiguous template instantiation with hana::when

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick Palka  ---
Fixed.

[Bug c++/105425] [12/13 Regression] ambiguous template instantiation with hana::when

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:38bdf2dccf6a239598ef808ed11a904e5f2a186e

commit r12-8317-g38bdf2dccf6a239598ef808ed11a904e5f2a186e
Author: Patrick Palka 
Date:   Thu Apr 28 13:10:56 2022 -0400

c++: partial ordering and dependent operator expr [PR105425]

Here ever since r12-6022-gbb2a7f80a98de3 we stopped deeming the partial
specialization #2 to be more specialized than #1 ultimately because
dependent operator expressions now have a DEPENDENT_OPERATOR_TYPE type
instead of an empty type, and this made unify stop deducing T(2) == 1
for K during partial ordering for #1 and #2.

This minimal patch fixes this by making the relevant logic in unify
treat DEPENDENT_OPERATOR_TYPE like an empty type.

PR c++/105425

gcc/cp/ChangeLog:

* pt.cc (unify) : Treat
DEPENDENT_OPERATOR_TYPE like an empty type.

gcc/testsuite/ChangeLog:

* g++.dg/template/partial-specialization13.C: New test.

(cherry picked from commit 509fd16da8528444dccc98cef57a18a295c3f1b4)

[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

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

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

--- Comment #11 from David Malcolm  ---
Should be fixed on trunk for GCC 13 by the above commit.

I hope to backport this to GCC 12; keeping this open until that's done.

[Bug modula2/105388] [12/13 regression] Conflicting trunc decls in mc-boot/Gdecl.c etc. on Solaris

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #2 from Gaius Mulley  ---
Thanks for the patch - ah yes the list of C functions/macros/reserved words to
be avoided needed to be extended.

The list of reserved words/functions/macros to be avoided in mc are contained
in:
gcc/m2/mc/keyc.mod


diff --git a/gcc/m2/mc/keyc.mod b/gcc/m2/mc/keyc.mod
index 2cf06790d93..a6584f49a9f 100644
--- a/gcc/m2/mc/keyc.mod
+++ b/gcc/m2/mc/keyc.mod
@@ -1033,6 +1033,7 @@ BEGIN
add (macros, 'cos') ;
add (macros, 'tan') ;
add (macros, 'log10') ;
+   add (macros, 'trunc') ;
add (macros, 'I') ;
add (macros, 'csqrt') ;
add (macros, 'strlen') ;

to recreate the C version of mc - which updates the C version of mc in the
source tree you can perform:

cd build-devel-modula2-enabled# your build directory
cd gcc
export PATH=$HOME/opt/bin:$PATH   # the install bin for the current gm2
make mc-help
make mc-maintainer# builds a new C version of mc (checking
  # that the C and m2 versions produce the
  # same output.
make mc-verify# and double check that the new version from 
  # the source tree builds
  # cleanly and produces the same output.


I've added the patch above, remade mc on the gcc-12 branch and re-tested
building gcc from bootstrap on amd64.

[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:00c4405cd7f6a144d0a439e4d848d246920e6ff3

commit r13-7-g00c4405cd7f6a144d0a439e4d848d246920e6ff3
Author: David Malcolm 
Date:   Thu Apr 28 13:49:59 2022 -0400

analyzer: handle repeated accesses after init of unknown size [PR105285]

PR analyzer/105285 reports a false positive from
-Wanalyzer-null-dereference on git.git's reftable/reader.c.

A reduced version of the problem can be seen in test_1a of
gcc.dg/analyzer/symbolic-12.c in the following:

void test_1a (void *p, unsigned next_off)
{
  struct st_1 *r = p;

  external_fn();

  if (next_off >= r->size)
return;

  if (next_off >= r->size)
/* We should have already returned if this is the case.  */
__analyzer_dump_path (); /* { dg-bogus "path" } */
}

where the analyzer erroneously considers this path, where
(next_off >= r->size) is both false and then true:

symbolic-12.c: In function âtest_1aâ:
symbolic-12.c:22:5: note: path
   22 | __analyzer_dump_path (); /* { dg-bogus "path" } */
  | ^~~
  âtest_1aâ: events 1-5
|
|   17 |   if (next_off >= r->size)
|  |  ^
|  |  |
|  |  (1) following âfalseâ branch...
|..
|   20 |   if (next_off >= r->size)
|  |  ~~~~
|  |  | |
|  |  | (2) ...to here
|  |  (3) following âtrueâ branch...
|   21 | /* We should have already returned if this is the case. 
*/
|   22 | __analyzer_dump_path (); /* { dg-bogus "path" } */
|  | ~~~
|  | |
|  | (4) ...to here
|  | (5) here
|

The root cause is that, at the call to the external function, the
analyzer considers the cluster for *p to have been touched, binding it
to a conjured_svalue, but because p is void * no particular size is
known for the write, and so the cluster is bound using a symbolic key
covering the base region.  Later, the accesses to r->size are handled by
binding_cluster::get_any_binding, but binding_cluster::get_binding fails
to find a match for the concrete field lookup, due to the key for the
binding being symbolic, and reaching this code:

1522  /* If this cluster has been touched by a symbolic write, then the
content
1523 of any subregion not currently specifically bound is "UNKNOWN". 
*/
1524  if (m_touched)
1525{
1526  region_model_manager *rmm_mgr = mgr->get_svalue_manager ();
1527  return rmm_mgr->get_or_create_unknown_svalue (reg->get_type ());
1528}

Hence each access to r->size is an unknown svalue, and thus the
condition (next_off >= r->size) isn't tracked, leading to the path with
contradictory conditions being treated as satisfiable.

In the original reproducer in git's reftable/reader.c, the call to the
external fn is:
  reftable_record_type(rec)
which is considered to possibly write to *rec, which is *tab, where tab
is the void * argument to reftable_reader_seek_void, and thus after the
call to reftable_record_type some arbitrary amount of *rec could have
been written to.

This patch fixes things by detecting the "this cluster has been 'filled'
with a conjured value of unknown size" case, and handling
get_any_binding on it by returning a sub_svalue of the conjured_svalue,
so that repeated accesses to r->size give the same symbolic value, so
that the constraint manager rejects the bogus execution path, fixing the
false positive.

gcc/analyzer/ChangeLog:
PR analyzer/105285
* store.cc (binding_cluster::get_any_binding): Handle accessing
sub_svalues of clusters where the base region has a symbolic
binding.

gcc/testsuite/ChangeLog:
PR analyzer/105285
* gcc.dg/analyzer/symbolic-12.c: New test.

Signed-off-by: David Malcolm 

[Bug c++/87656] Useful flags to enable with -Wall or -Wextra

[schwab--- via Gcc-bugs]

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

--- Comment #13 from Andreas Schwab  ---
Like bash.

[Bug analyzer/105285] False positive with -Wanalyzer-null-dereference in git.git's reftable/reader.c

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r13-6-gd8586b00dd00a1783862da5f0c8811a740400074
Author: David Malcolm 
Date:   Thu Apr 28 13:46:15 2022 -0400

analyzer: add .fpath.txt dumps to -fdump-analyzer-feasibility

I found this extension to -fdump-analyzer-feasibility very helpful when
debugging PR analyzer/105285.

gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (epath_finder::process_worklist_item):
Call dump_feasible_path when a path that reaches the the target
enode is found.
(epath_finder::dump_feasible_path): New.
* engine.cc (feasibility_state::dump_to_pp): New.
* exploded-graph.h (feasibility_state::dump_to_pp): New decl.
* feasible-graph.cc (feasible_graph::dump_feasible_path): New.
* feasible-graph.h (feasible_graph::dump_feasible_path): New
decls.
* program-point.cc (function_point::print): Fix missing trailing
newlines.
* program-point.h (program_point::print_source_line): Remove
unimplemented decl.

gcc/ChangeLog:
* doc/invoke.texi (-fdump-analyzer-feasibility): Mention the
fpath.txt output.

Signed-off-by: David Malcolm 

[Bug c++/63164] unnecessary calls to __dynamic_cast

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #6 from Avi Kivity  ---
I already owe you many beers, but this one is special.

[Bug c++/63164] unnecessary calls to __dynamic_cast

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

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

--- Comment #5 from Jonathan Wakely  ---
Avi, in the BZ Preferences you can set "After changing a bug" to "Show the
updated bug" instead of jumping to the next one in the list.

[Bug target/103938] [9/10/11/12/13 Regression] ICE with __builtin_prefetch and vectors

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

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

Alex Coplan  changed:

   What|Removed |Added

 CC||jonathan.wright at arm dot com

--- Comment #7 from Alex Coplan  ---
A bisect shows this started with
r12-2288-g8695bf78dad1a42636775843ca832a2f4dba4da3 :

commit 8695bf78dad1a42636775843ca832a2f4dba4da3
Author: Jonathan Wright 
Date:   Wed Jun 2 16:55:00 2021 +0100

gcc: Add vec_select -> subreg RTL simplification

which makes it a [12/13 Regression], unless I'm missing something? Should it be
a P1?

[Bug c++/105373] miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #11 from Avi Kivity  ---
Created attachment 52899
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52899=edit
simple(r) reproducer

I was able to reduce it to something simple (102 lines), but I was only able to
verify that wrong code is generated on the gimple level (where my understanding
is very limited). Still, to my inexperienced eyes it looks like an object with
a copy constructor is being copied bitwise.

Compile with (gcc 11.3.1)

g++ -Wfatal-errors -w -std=gnu++20  -march=westmere -fvisibility=hidden  -c
-o table.o table.i -fdump-tree-gimple -g 

and observe in table.i.006t.gimple:

struct lw_shared_ptr D.2740 [value-expr: frame_ptr->D.2740_4_5];

and then

frame_ptr->D.2741_4_5.__old4 = frame_ptr->D.2740_4_5;


in other places, variables of the same type are copied using the copy
constructor.

[Bug c++/105425] [12/13 Regression] ambiguous template instantiation with hana::when

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

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

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

https://gcc.gnu.org/g:509fd16da8528444dccc98cef57a18a295c3f1b4

commit r13-5-g509fd16da8528444dccc98cef57a18a295c3f1b4
Author: Patrick Palka 
Date:   Thu Apr 28 13:10:56 2022 -0400

c++: partial ordering and dependent operator expr [PR105425]

Here ever since r12-6022-gbb2a7f80a98de3 we stopped deeming the partial
specialization #2 to be more specialized than #1 ultimately because
dependent operator expressions now have a DEPENDENT_OPERATOR_TYPE type
instead of an empty type, and this made unify stop deducing T(2) == 1
for K during partial ordering for #1 and #2.

This minimal patch fixes this by making the relevant logic in unify
treat DEPENDENT_OPERATOR_TYPE like an empty type.

PR c++/105425

gcc/cp/ChangeLog:

* pt.cc (unify) : Treat
DEPENDENT_OPERATOR_TYPE like an empty type.

gcc/testsuite/ChangeLog:

* g++.dg/template/partial-specialization13.C: New test.

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

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |11.4

--- Comment #5 from Jonathan Wakely  ---
Fixed for 11.4 and 21.1

[Bug testsuite/105427] New: [12 regression]

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

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

Bug ID: 105427
   Summary: [12 regression]
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:ad56a60f58c1ed662deaf60d5736c332ec2caabb, r12-8265-gad56a60f58c1ed
make  -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/pr92398.p9-.c"
FAIL: gcc.target/powerpc/pr92398.p9-.c scan-assembler-times \\mnot\\M 2
FAIL: gcc.target/powerpc/pr92398.p9-.c scan-assembler-times \\mstd\\M 2
# of expected passes1
# of unexpected failures2

This fails on power 9 and power 10.  It used to be not run.


commit ad56a60f58c1ed662deaf60d5736c332ec2caabb (HEAD, refs/bisect/bad)
Author: Segher Boessenkool 
Date:   Tue Apr 26 11:26:09 2022 +

rs6000: Make the has_arch target selectors actually work


The assembler output isn't very long:

seurer@rain6p1:~/gcc/git/build/gcc-test$
/home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr92398.p9-.c
-fdiagnostics-plain-output -O2 -mvsx -ffat-lto-objects -fno-ident -S -o
pr92398.p9-.s
seurer@rain6p1:~/gcc/git/build/gcc-test$ cat pr92398.p9-.s 
.file   "pr92398.p9-.c"
.machine power10
.abiversion 2
.section".text"
.align 2
.p2align 4,,15
.globl bar
.type   bar, @function
bar:
.LFB0:
.cfi_startproc
.localentry bar,1
mtvsrdd 0,5,4
xxlnor 0,0,0
stxv 0,0(3)
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.cfi_endproc
.LFE0:
.size   bar,.-bar
.section.note.GNU-stack,"",@progbits

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

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

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

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

https://gcc.gnu.org/g:9821d286bce3edf1d36168f129bfc7fe99c15fc3

commit r11-9948-g9821d286bce3edf1d36168f129bfc7fe99c15fc3
Author: Jonathan Wakely 
Date:   Thu Apr 28 13:06:31 2022 +0100

libstdc++: Fix error reporting in filesystem::copy [PR99290]

The recursive calls to filesystem::copy should stop if any of them
reports an error.

libstdc++-v3/ChangeLog:

PR libstdc++/99290
* src/c++17/fs_ops.cc (fs::copy): Pass error_code to
directory_iterator constructor, and check on each iteration.
* src/filesystem/ops.cc (fs::copy): Likewise.
* testsuite/27_io/filesystem/operations/copy.cc: Check for
errors during recursion.
* testsuite/experimental/filesystem/operations/copy.cc:
Likewise.

(cherry picked from commit 4e117418fb71f508c479e0144500f4da9cc92520)

[Bug c++/87656] Useful flags to enable with -Wall or -Wextra

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

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

--- Comment #12 from Segher Boessenkool  ---
(In reply to David Binderman from comment #11)
> -Wold-style-definition
> 
> KnR style function definitions have been deprecated for about 35 years.

+1

> Yes, there is a warning for it in gcc, but that warning isn't in either
> -Wall or -Wextra. 
> 
> Also, switching on -std=c2x only makes it a warning, not an error. 
> That doesn't sound correct to me. AFAIK KnR is removed from c2x.

It can stay there as a GCC extension no problem.  If there is a warning for it
it is not a problem anymore, esp. if that warning is in -Wall or on by default
even.

The only reason to remove support for this is if it actually simplifies the
compiler code itself, which means we have to completely not support it anymore.
So let's first have a default warning, and then see if anything in the wild
still uses old-style functions defs?

[Bug preprocessor/105412] [10/11/12/13 Regression] Missing phony target with -MP for first include when compiling from stdin

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-04-28
 CC||jakub at gcc dot gnu.org
   Keywords|needs-bisection |
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r10-205-g61145d937ba07e368d8251fd0ffe0b987b50a7b5

[Bug target/95381] [11 Regression]: Build fails with --disable-bootstrap on m68k with ICE: in operator[], at vec.h:867

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

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

Eric Gallager  changed:

   What|Removed |Added

Summary|[11/12/13 Regression]:  |[11 Regression]: Build
   |Build fails with|fails with
   |--disable-bootstrap on m68k |--disable-bootstrap on m68k
   |with ICE: in operator[], at |with ICE: in operator[], at
   |vec.h:867   |vec.h:867
 CC||egallager at gcc dot gnu.org
   Keywords||build

--- Comment #21 from Eric Gallager  ---
(In reply to John Paul Adrian Glaubitz from comment #20)
> JIT definitely works with 12 on m68k again - and probably 13. So, the title
> is misleading.

ok, retitled

[Bug ada/88200] [9/10/11 Regression] ada bootstrap failure on alpha-linux-gnu (raised STORAGE_ERROR : stack overflow or erroneous memory access)

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

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||build
Summary|[9/10/11/12/13 Regression]  |[9/10/11 Regression] ada
   |ada bootstrap failure on|bootstrap failure on
   |alpha-linux-gnu (aised  |alpha-linux-gnu (raised
   |STORAGE_ERROR : stack   |STORAGE_ERROR : stack
   |overflow or erroneous   |overflow or erroneous
   |memory access)  |memory access)
 CC||egallager at gcc dot gnu.org

--- Comment #8 from Eric Gallager  ---
(In reply to John Paul Adrian Glaubitz from comment #7)
> This has been fixed on 12 and presumably also on 13. So, the title is
> misleading.

Taking your word for it and retitling

[Bug target/98341] [11 Regression] Ada bootstrap fails with erroneous memory access on m68k

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
Summary|[11/12/13 Regression] Ada   |[11 Regression] Ada
   |bootstrap fails with|bootstrap fails with
   |erroneous memory access on  |erroneous memory access on
   |m68k|m68k

--- Comment #22 from Eric Gallager  ---
(In reply to John Paul Adrian Glaubitz from comment #21)
> This issue is fixed in 12 and presumably also in version 13. So the title is
> misleading.

It is? OK, I'll retitle then...

[Bug analyzer/105287] [12/13 Regression] ICE in analyzer get_region_for_local on C++ await cond_var

[avi at scylladb dot com via Gcc-bugs]

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

Avi Kivity  changed:

   What|Removed |Added

 CC||avi at scylladb dot com

--- Comment #10 from Avi Kivity  ---
This causes a wrong-code regression, PR105426.

[Bug c++/105426] [wrong-code][regression][coroutines] range-for temporaries are not persisted in coroutines

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #1 from Avi Kivity  ---
Created attachment 52898
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52898=edit
reproducer

[Bug c++/105426] New: [wrong-code][regression][coroutines] range-for temporaries are not persisted in coroutines

[avi at scylladb dot com via Gcc-bugs]

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

Bug ID: 105426
   Summary: [wrong-code][regression][coroutines] range-for
temporaries are not persisted in coroutines
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: avi at scylladb dot com
  Target Milestone: ---

The attached reproducer, compiled with:


g++ --std=c++20 coroutine-unpersisted-range-for-temporary.cc -g -O3


generates correct results for gcc before 15a176a833f and for clang, but
incorrect results in 15a176a833f and later.

[Bug c++/105425] [12/13 Regression] ambiguous template instantiation with hana::when

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
Untested fix:

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 3cf1d7af8d2..cf24d482488 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -24276,7 +24276,8 @@ unify (tree tparms, tree targs, tree parm, tree arg,
int strict,
}
}

-  if (!TREE_TYPE (arg))
+  if (!TREE_TYPE (arg)
+ || TREE_CODE (TREE_TYPE (arg)) == DEPENDENT_OPERATOR_TYPE)
/* Template-parameter dependent expression.  Just accept it for now.
   It will later be processed in convert_template_argument.  */
;

[Bug c++/105425] ambiguous template instantiation with hana::when

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |12.0
 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Last reconfirmed||2022-04-28
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Keywords||rejects-valid

--- Comment #1 from Marek Polacek  ---
Started with r12-6022-gbb2a7f80a98de3

[Bug c++/105386] [11 Regression] Tuple in unevaluated context is instantiated; creates reference to void

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #6 from Patrick Palka  ---
Fixed for GCC 11.4/12, thanks for the bug report.

[Bug c++/105386] [11 Regression] Tuple in unevaluated context is instantiated; creates reference to void

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:8969d00bf16a8f4de79306010fca8f14f91c171d

commit r11-9947-g8969d00bf16a8f4de79306010fca8f14f91c171d
Author: Patrick Palka 
Date:   Tue Apr 26 10:53:38 2022 -0400

c++: decltype of non-dependent call of class type [PR105386]

We need to pass tf_decltype when instantiating a non-dependent decltype
operand, like tsubst does in the dependent case, so that we don't force
completion of a prvalue operand's class type.

PR c++/105386

gcc/cp/ChangeLog:

* semantics.c (finish_decltype_type): Pass tf_decltype to
instantiate_non_dependent_expr_sfinae.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/decltype81.C: New test.

(cherry picked from commit b6a48401da51e9042b6f0822d532b3b472492658)

[Bug c++/105304] [10/11 Regression] ICE segfault using ad-hoc concept with -Wall since r10-7441-ga7ea3d2ced786c45

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:992dd9a071c16b94a616ab7242390b6581fa6001

commit r11-9946-g992dd9a071c16b94a616ab7242390b6581fa6001
Author: Patrick Palka 
Date:   Mon Apr 25 21:49:00 2022 -0400

c++: ICE with requires-expr and -Wsequence-point [PR105304]

Here we're crashing from verify_sequence_points for this requires-expr
condition because it contains a templated CAST_EXPR with empty operand,
and verify_tree doesn't ignore this empty operand only because the
manual tail recursion that it performs for unary expression trees skips
the NULL test.

PR c++/105304

gcc/c-family/ChangeLog:

* c-common.c (verify_tree) [restart]: Move up to before the
NULL test.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-requires30.C: New test.

(cherry picked from commit c83b9c54d9dee2dce5d8268472a745b013d166cc)

[Bug c++/105289] [11 Regression] ICE on partial specialization

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

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

commit r11-9945-gc4332c785c8e993104a4d76d86c737b51a636aee
Author: Patrick Palka 
Date:   Mon Apr 25 21:46:56 2022 -0400

c++: partial ordering with dependent NTTP type [PR105289]

Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing
on (respectively) two testcases that we used to accept in C++17 mode
since r8-1437-g3da557ec145823.  Both testcases declare a partial
specialization of a primary template that has an NTTP with dependent
type, and the validity of these partial specializations is unclear and
the subject of PR86193 / CWG 455.

So for now, this minimal patch just aims to fix the crash in the second
testcase.  During deduction, when checking whether the type of an NTTP
uses still-undeduced parameters, we were incorrectly substituting into
the previously substituted type instead of into its original type.

In passing this patch also downgrades the "not more specialized"
diagnostic from a permerror to a pedwarn.

PR c++/105289
PR c++/86193

gcc/cp/ChangeLog:

* pt.c (process_partial_specialization): Downgrade "partial
specialization isn't more specialized" diagnostic from permerror
to an on-by-default pedwarn.
(unify) : When substituting into the
NTTP type a second time, use the original type not the
substituted type.

gcc/testsuite/ChangeLog:

* g++.dg/template/partial-specialization11.C: New test.
* g++.dg/template/partial-specialization12.C: New test.

(cherry picked from commit 288e4c64f6b4806358aabc9b99b2fba72bf04bf6)

[Bug c++/86193] [DR455] Partial ordering of non-type template parameters with dependent types

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

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

commit r11-9945-gc4332c785c8e993104a4d76d86c737b51a636aee
Author: Patrick Palka 
Date:   Mon Apr 25 21:46:56 2022 -0400

c++: partial ordering with dependent NTTP type [PR105289]

Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing
on (respectively) two testcases that we used to accept in C++17 mode
since r8-1437-g3da557ec145823.  Both testcases declare a partial
specialization of a primary template that has an NTTP with dependent
type, and the validity of these partial specializations is unclear and
the subject of PR86193 / CWG 455.

So for now, this minimal patch just aims to fix the crash in the second
testcase.  During deduction, when checking whether the type of an NTTP
uses still-undeduced parameters, we were incorrectly substituting into
the previously substituted type instead of into its original type.

In passing this patch also downgrades the "not more specialized"
diagnostic from a permerror to a pedwarn.

PR c++/105289
PR c++/86193

gcc/cp/ChangeLog:

* pt.c (process_partial_specialization): Downgrade "partial
specialization isn't more specialized" diagnostic from permerror
to an on-by-default pedwarn.
(unify) : When substituting into the
NTTP type a second time, use the original type not the
substituted type.

gcc/testsuite/ChangeLog:

* g++.dg/template/partial-specialization11.C: New test.
* g++.dg/template/partial-specialization12.C: New test.

(cherry picked from commit 288e4c64f6b4806358aabc9b99b2fba72bf04bf6)

[Bug c++/98995] [11/12/13 Regression] Copy elision not applied to members declared with [[no_unique_address]]

[davidfromonline at gmail dot com via Gcc-bugs]

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

David Stone  changed:

   What|Removed |Added

 CC||davidfromonline at gmail dot 
com

--- Comment #6 from David Stone  ---
Until we get that ABI break, it would be nice if the error message explained
why this doesn't work.

[Bug c++/105425] New: ambiguous template instantiation with hana::when

[ed at catmur dot uk via Gcc-bugs]

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

Bug ID: 105425
   Summary: ambiguous template instantiation with hana::when
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

Simplified:

template struct when;
template constexpr int B = 1;
template struct A;
template struct A> {}; // fallback
template struct A == 1>> {};
A> a;

"B<0> == 1" is sufficiently complex (?) to trigger the bug (it doesn't need to
be dependent on C) but "B<0>" on its own isn't.

This affects hana since it uses the when pattern heavily.

Per godbolt 11.3.0 is good, 12.0.1 20220426 is bad.

[Bug analyzer/105287] [12/13 Regression] ICE in analyzer get_region_for_local on C++ await cond_var

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #9 from David Malcolm  ---
I've confirmed the fix of the ICE, which happened immediately before the branch
for gcc 12; closing.

Thanks for fixing this.

Let's use PR 105382 for the remaining "analyzer doesn't understand C++
coroutines" issues.

[Bug target/95381] [11/12/13 Regression]: Build fails with --disable-bootstrap on m68k with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #20 from John Paul Adrian Glaubitz  ---
JIT definitely works with 12 on m68k again - and probably 13. So, the title is
misleading.

[Bug ada/88200] [9/10/11/12/13 Regression] ada bootstrap failure on alpha-linux-gnu (aised STORAGE_ERROR : stack overflow or erroneous memory access)

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #7 from John Paul Adrian Glaubitz  ---
This has been fixed on 12 and presumably also on 13. So, the title is
misleading.

[Bug target/98341] [11/12/13 Regression] Ada bootstrap fails with erroneous memory access on m68k

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #21 from John Paul Adrian Glaubitz  ---
This issue is fixed in 12 and presumably also in version 13. So the title is
misleading.

[Bug c++/105373] miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #10 from Avi Kivity  ---
I have something like this:

│ 2680  future<> system_keyspace_make(distributed&
dist_db, distributed& dist_ss,
sharded& dist_gossiper, db::config& cfg) {   │
...
   
│
│ 2687  for (auto&& table : system_keyspace::all_tables(db_config)) {   

...

│ 2695  co_await db.create_keyspace(ksm,
dist_ss.local().get_erm_factory(), true,
replica::database::system_keyspace::yes);   


And I see a crash as if the std::vector returned by all_tables() is not
persisted. This worked in previous gcc versions and works in clang.

I don't now what the standard says, but it really should persist temporaries in
range for that contains a suspension point, or a lot of buggy code will be
written.

[Bug c++/63164] unnecessary calls to __dynamic_cast

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #4 from Avi Kivity  ---
Oops, last comment intended for a separate bug. Curse the bug list thing.

[Bug c++/63164] unnecessary calls to __dynamic_cast

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #3 from Avi Kivity  ---
I have something like this:

│ 2680  future<> system_keyspace_make(distributed&
dist_db, distributed& dist_ss,
sharded& dist_gossiper, db::config& cfg) {   │
│ 2681  register_virtual_tables(dist_db, dist_ss, dist_gossiper, cfg);  
...
   
│
│ 2687  for (auto&& table : system_keyspace::all_tables(db_config)) {   

...

│ 2695  co_await db.create_keyspace(ksm,
dist_ss.local().get_erm_factory(), true,
replica::database::system_keyspace::yes);   


And I see a crash as if the std::vector returned by all_tables() is not
persisted. This worked in previous gcc versions and works in clang.

I don't now what the standard says, but it really should persist temporaries in
range for that contains a suspension point, or a lot of buggy code will be
written.

[Bug c++/105373] miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #9 from Avi Kivity  ---
I think it makes it worse, now seeing similar crashes, but earlier.

[Bug c++/105373] miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #8 from Avi Kivity  ---
Hoping this is a duplicate of PR105287. Checking.

[Bug lto/105399] [12 Regression] -O2/-Ofast -flto ICEs as internal compiler error: verify_cgraph_node failed

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug lto/105399] [12 Regression] -O2/-Ofast -flto ICEs as internal compiler error: verify_cgraph_node failed

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

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

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

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

commit r12-8312-gb85e79dce149df68b92ef63ca2a40ff1dfa61396
Author: Jakub Jelinek 
Date:   Thu Apr 28 15:45:33 2022 +0200

cgraph: Don't verify semantic_interposition flag for aliases [PR105399]

The following testcase ICEs, because the ctors during cc1plus all have
!opt_for_fn (decl, flag_semantic_interposition) - they have NULL
DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl) and optimization_default_node
is for -Ofast and so has flag_semantic_interposition cleared.
During free lang data, we set DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl)
for the ctor which has body (or for thunks), but don't touch it for
aliases.
During lto1 optimization_default_node reflects the lto1 flags which
are -O2 rather than -Ofast and so has flag_semantic_interposition
set, for the ctor which has body that makes no difference, but as the
alias doesn't still have DECL_FUNCTION_SPECIFIC_OPTIMIZATION (decl) set,
we now trigger this verification check.

The following patch just doesn't verify it for aliases during lto1.
Another possibility would be to set DECL_FUNCTION_SPECIFIC_OPTIMIZATION
(decl)
during free lang data even for aliases.

2022-04-28  Jakub Jelinek  

PR lto/105399
* cgraph.cc (cgraph_node::verify_node): Don't verify
semantic_interposition flag against
opt_for_fn (decl, flag_semantic_interposition) for aliases in lto1.

* g++.dg/lto/pr105399_0.C: New test.

[Bug c++/105424] New: Bogus -Wstringop-overread with non-overread condition

[byteslice at airmail dot cc via Gcc-bugs]

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

Bug ID: 105424
   Summary: Bogus -Wstringop-overread with non-overread condition
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: byteslice at airmail dot cc
  Target Milestone: ---

Created attachment 52897
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52897=edit
Cvised example

On gcc 12.0.1 20220413 (Fedora 36 Beta), with c++ -std=c++20 -O1
-Werror=stringop-overread, the attachment fails to compile, with the following
message:

In function 'void boost::memmove(I, F) [with I = move_iterator; F =
int]',
inlined from 'F boost::uninitialized_copy_alloc(Allocator, I, F) [with
Allocator = vector_alloc_holder; I = move_iterator; F = int]' at
:67:10,
inlined from 'void
boost::vector::priv_uninitialized_construct_at_end(InpIt, InpIt) [with InpIt =
boost::move_iterator]' at :91:45,
inlined from 'void boost::vector::assign(FwdIt, FwdIt) [with FwdIt =
boost::move_iterator]' at :87:42,
inlined from 'boost::small_vector::small_vector(boost::small_vector&&)' at
:106:11,
inlined from 'Stack::Stack(Stack&&)' at :113:8,
inlined from 'pair<_T2>::pair(_U1, _U2) [with _U1 = int; _U2 = Stack; _T2 =
Stack]' at :5:24,
inlined from 'pair Stack::Pop() const' at :118:67:
:63:14: error: 'void* memmove(void*, const void*, long unsigned int)'
reading 9 or more bytes from a region of size 4 [-Werror=stringop-overread]
   63 | ::memmove(dest_raw, beg_raw, n);
  | ~^~
: In member function 'pair Stack::Pop() const':
:103:9: note: source object '__trans_tmp_4' of size 4
  103 | int __trans_tmp_4;
  | ^
cc1plus: some warnings being treated as errors
Compiler returned: 1

This warning is bogus because the memmove is guarded by a condition that
prevents the size from being more than 4. The bogus warning does not appear in
older versions of GCC.

Adding -fno-inline to options allows compilation to succeed.

[Bug modula2/105391] gm2 doesn't heed --with-gmp*

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #2 from Gaius Mulley  ---
Many thanks for the patch, now applied to the branch.  Ah yes, I will refactor
the Make-lang.in and reduce the number of similar rules.

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

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||m...@msc-ge.com

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

[Bug libstdc++/105422] filesystem::copy does not throw exceptions when a subdirectory exists

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I fixed this earlier today.

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

[Bug tree-optimization/105423] New: Bogus -Werror=maybe-uninitialized with definitely initialized variable

[byteslice at airmail dot cc via Gcc-bugs]

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

Bug ID: 105423
   Summary: Bogus -Werror=maybe-uninitialized with definitely
initialized variable
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: byteslice at airmail dot cc
  Target Milestone: ---

Created attachment 52896
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52896=edit
Cvised example

On gcc 12.0.1 20220413 (Fedora 36 Beta), with c++ -O1
-Werror=maybe-uninitialized, the attachment fails to compile, with the
following message:

In member function 'void std::Trans_NS___cxx11_basic_string<_CharT,
,  >::_S_copy(_CharT*) [with
_CharT = char; _Traits = std::char_traits;  = char]',
inlined from 'constexpr std::Trans_NS___cxx11_basic_string<_CharT, _Traits,
_Alloc>& std::Trans_NS___cxx11_basic_string<_CharT, ,
 >::_M_replace(const _CharT*, long int) [with _CharT =
char; _Traits = std::char_traits;  = char]' at
:49:12,
inlined from 'void std::Trans_NS___cxx11_basic_string<_CharT,
,  >::operator=(const _CharT*)
[with _CharT = char; _Traits = std::char_traits;  =
char]' at :40:15,
inlined from 'void Shuffle()' at :55:8:
:36:46: error: '((char*)((char*) +
offsetof(std::Trans_NS___cxx11_basic_string,std::Trans_NS___cxx11_basic_string::)))[2]' may be used uninitialized [-Werror=maybe-uninitialized]
   36 |   void _S_copy(_CharT *__s) { _Traits::assign(_S_copy___d, *__s); }
  |   ~~~^~~
: In function 'void Shuffle()':
:54:44: note: 'mask' declared here
   54 |   std::Trans_NS___cxx11_basic_string mask{};
  |^~~~
In member function 'void std::Trans_NS___cxx11_basic_string<_CharT,
,  >::_S_copy(_CharT*) [with
_CharT = char; _Traits = std::char_traits;  = char]',
inlined from 'constexpr std::Trans_NS___cxx11_basic_string<_CharT, _Traits,
_Alloc>& std::Trans_NS___cxx11_basic_string<_CharT, ,
 >::_M_replace(const _CharT*, long int) [with _CharT =
char; _Traits = std::char_traits;  = char]' at
:49:12,
inlined from 'void std::Trans_NS___cxx11_basic_string<_CharT,
,  >::operator=(const _CharT*)
[with _CharT = char; _Traits = std::char_traits;  =
char]' at :40:15,
inlined from 'void Shuffle()' at :55:8:
:36:47: error:
'mask.std::Trans_NS___cxx11_basic_string::_S_copy___d' may be used
uninitialized [-Werror=maybe-uninitialized]
   36 |   void _S_copy(_CharT *__s) { _Traits::assign(_S_copy___d, *__s); }
  |   ^~~
: In function 'void Shuffle()':
:54:44: note: 'mask' declared here
   54 |   std::Trans_NS___cxx11_basic_string mask{};
  |^~~~
cc1plus: some warnings being treated as errors
Compiler returned: 1

This warning is bogus because the variable mask is default brace-initialized
and thus its member _S_copy___d is also initialized. The bogus warning does not
appear in older versions of GCC.

Adding -fno-inline to options allows compilation to succeed.

[Bug libstdc++/105422] New: filesystem::copy does not throw exceptions when a subdirectory exists

[mpie--- via Gcc-bugs]

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

Bug ID: 105422
   Summary: filesystem::copy does not throw exceptions when a
subdirectory exists
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m...@msc-ge.com
  Target Milestone: ---

Created attachment 52895
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52895=edit
Example file to reproduce behaviour

Hi,

in Ubuntu 21.10 a recursive filesystem::copy() does correctly throw an
exception if a file can't be read. But it will not throw an exception if there
is an empty subdirectory. The destination will therefore miss a file without a
report. Also the error code will be empty.

See the output of the attached copy_bug.cpp

$ c++ copy_bug.cpp -o copy_bug --std=c++17
$ ./copy_bug

Copytest with withSubDir=0
Exception: filesystem error: cannot copy: Permission denied [test/source]
[test/dest]
Error code: Permission denied
Copytest with withSubDir=1

$ tree -p test   
test
├── [drwxrwxr-x]  dest
│   └── [drwxrwxr-x]  subdir
├── [drwxrwxr-x]  dest_ec
│   └── [drwxrwxr-x]  subdir
└── [drwxrwxr-x]  source
├── [drwxrwxr-x]  subdir
└── [--]  test.txt

[Bug target/105421] New: GCN offloading, raised '-mgang-private-size': 'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION'

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

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

Bug ID: 105421
   Summary: GCN offloading, raised '-mgang-private-size':
'HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION'
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
Target: GCN

As discussed in
,
after commit r12-8252-gb2202431910e30d8505c94d1cb9341cac7080d10 "fortran: Fix
up gfc_trans_oacc_construct [PR104717]", we need commit
r12-8311-g2a570f11a2fecf23998d7fe1d5cabad62cfe5cec "Fix up
'libgomp.oacc-fortran/print-1.f90' GCN offloading compilation [PR104717]",
however:

> That only works with the default GCN multilib '-march=fiji', testing
> on gfx803 amdfury2 system.  For all of '-march=gfx900' (amdnano2),
> '-march=gfx906' (amd_ryzen3), '-march=gfx908' (amd-instinct1), I get:
> 
> libgomp: GCN fatal error: Asynchronous queue error
> Runtime message: HSA_STATUS_ERROR_MEMORY_APERTURE_VIOLATION: The agent 
> attempted to access memory beyond the largest legal address.
> 
> ..., and I still get that if lowering the allocation to the minimum,
> '-foffload-options=amdgcn-amdhsa=-mgang-private-size=560'.
> 
> This is a really simple OpenACC 'parallel' construct:
> 
> !$acc parallel
>   write (0, '("The answer is ", I2)') var
> !$acc end parallel
> 
> ..., which ought to launch a 1-gang x 1-worker x 1-vector GPU kernel, so
> I'd assume '-mgang-private-size=560' (or '-mgang-private-size=13579' in
> fact) is not a problem?

[Bug fortran/104717] [9/10/11 Regression] ICE: verify_ssa failed (Error: type mismatch between an SSA_NAME and its symbol)

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

https://gcc.gnu.org/g:2a570f11a2fecf23998d7fe1d5cabad62cfe5cec

commit r12-8311-g2a570f11a2fecf23998d7fe1d5cabad62cfe5cec
Author: Thomas Schwinge 
Date:   Tue Apr 26 18:41:23 2022 +0200

Fix up 'libgomp.oacc-fortran/print-1.f90' GCN offloading compilation
[PR104717]

That got broken by recent commit b2202431910e30d8505c94d1cb9341cac7080d10
"fortran: Fix up gfc_trans_oacc_construct [PR104717]".

PR fortran/104717
libgomp/
* testsuite/libgomp.oacc-fortran/print-1.f90: Add OpenACC
privatization scanning.  For GCN offloading compilation, raise
'-mgang-private-size'.

[Bug tree-optimization/105420] New: Bogus -Warray-bounds with non-compile time-constant variable

[byteslice at airmail dot cc via Gcc-bugs]

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

Bug ID: 105420
   Summary: Bogus -Warray-bounds with non-compile time-constant
variable
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: byteslice at airmail dot cc
  Target Milestone: ---

Created attachment 52894
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52894=edit
Reduced example

On gcc 12.0.1 20220413 (Fedora 36 Beta), with c++ -O1 -fexpensive-optimizations
-ftree-vrp -Werror=array-bounds, the attachment fails to compile, with the
following message:

: In function 'void Initialize(int)':
:9:53: error: array subscript -1 is below array bounds of 'int [8]'
[-Werror=array-bounds]
9 |   int phys_core = VirtualToPhysicalCoreMap[virt_core];
  |   ~~^
:2:5: note: while referencing 'VirtualToPhysicalCoreMap'
2 | int VirtualToPhysicalCoreMap[8];
  | ^~~~
cc1plus: some warnings being treated as errors
Compiler returned: 1

virt_core does not have a compile time-constant evaluation, so this warning is
bogus. The bogus warning does not appear in older versions of GCC.

Removing either -fexpensive-optimizations or -ftree-vrp allows compilation to
succeed.

[Bug libstdc++/105417] [11/12 Regression] powerpc64le-linux abilist changes based on --with-long-double-format=

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

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

--- Comment #3 from Jakub Jelinek  ---
>From what I can see, the --with-long-double-format=ibm libstdc++.a has
following _M_extract_int symbols (for simplicity only listing Ij symbols,
I[lmtxy] are present/absent next to it:
compatibility-ldbl-alt128.o:
 W
_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
 W
_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
cxx11-locale-inst.o:
 W
_ZNKSt17__gnu_cxx_ldbl1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
cxx11-wlocale-inst.o:
 W
_ZNKSt17__gnu_cxx_ldbl1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
locale-inst.o:
 W
_ZNKSt17__gnu_cxx_ldbl1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
 W
_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_
wlocale-inst.o:
 W
_ZNKSt17__gnu_cxx_ldbl1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
 W
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intIjEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_

while --with-long-double-format=ieee libstdc++.a has:
compatibility-ldbl-alt128.o:
 W
_ZNKSt17__gnu_cxx_ldbl1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
 W
_ZNKSt17__gnu_cxx_ldbl1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
 W
_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_
 W
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intIjEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_
cxx11-locale-inst.o:
 W
_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
cxx11-wlocale-inst.o:
 W
_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
locale-inst.o:
 W
_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
wlocale-inst.o:
 W
_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intIjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_

Now, the symbols in compatibility-ldbl-alt128.o and {,w}locale-inst.o match
between the 2 builds, basically for each narrow and wide we export all of
std::num_get, std::__gnu_cxx_ldbl128::num_get and
std::__gnu_cxx_ieee128::num_get symbols.
But the cxx11 ABI symbols are not.
On x86_64, I see we have
_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_
in cxx11-locale-inst.o and
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES3_S3_S3_RSt8ios_baseRSt12_Ios_IostateRT_
in cxx11-wlocale-inst.o, but we don't export those, similarly we don't export
those
_ZNKSt17__gnu_cxx_ldbl1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
and
_ZNKSt17__gnu_cxx_ldbl1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_
on targets which switched long double from double to something wider in the
past (including powerpc64*), but we do export the __gnu_cxx_ieee128 ones, which
is
why we get those extra symbols on --with-long-double-format=ieee builds.
Are those cxx11 symbols never needed and so it was a mistake that they've been
exported?
Or is it an omission that they are not exported?

[Bug c++/104051] [coroutines] ICE: tree check: expected target_expr, have call_expr in coro_diagnose_throwing_final_aw_expr, at cp/coroutines.cc:880 since r11-7528-g9ee91079fd5879cb

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

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

--- Comment #3 from Iain Sandoe  ---
fixed for gcc-12, backports TBD.

[Bug c++/105301] [11 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'overload' in coro_promise_type_found_p, at cp/coroutines.cc:516

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

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

Iain Sandoe  changed:

   What|Removed |Added

Summary|[11/12 Regression] ICE: |[11 Regression] ICE: tree
   |tree check: expected tree   |check: expected tree that
   |that contains 'decl |contains 'decl minimal'
   |minimal' structure, have|structure, have 'overload'
   |'overload' in   |in
   |coro_promise_type_found_p,  |coro_promise_type_found_p,
   |at cp/coroutines.cc:516 |at cp/coroutines.cc:516

--- Comment #5 from Iain Sandoe  ---
fixed for gcc-12 so far.

[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var

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

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

--- Comment #8 from Iain Sandoe  ---
so the ICE should be fixed for gcc-12, and given tracking the issues in PR
105382  this could be closed now, I'd think.

[Bug c++/103868] ICE at end of coroutine when using asio

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

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

Iain Sandoe  changed:

   What|Removed |Added

   Target Milestone|--- |11.4

--- Comment #7 from Iain Sandoe  ---
fixed for gcc-12, back port pending for 11.4.

[Bug c++/104051] [coroutines] ICE: tree check: expected target_expr, have call_expr in coro_diagnose_throwing_final_aw_expr, at cp/coroutines.cc:880 since r11-7528-g9ee91079fd5879cb

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

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

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

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

commit r12-8310-g7b96274a340bc0e9bcaef9baff3a44ec2f12c3df
Author: Iain Sandoe 
Date:   Mon Apr 18 16:23:30 2022 +0100

c++, coroutines: Improve check for throwing final await [PR104051].

We check that the final_suspend () method returns a sane type (i.e. a class
or structure) but, unfortunately, that check has to be later than the one
for a throwing case.  If the use returns some nonsensical type from the
method, we need to handle that in the checking for noexcept.

Signed-off-by: Iain Sandoe 

PR c++/104051

gcc/cp/ChangeLog:

* coroutines.cc (coro_diagnose_throwing_final_aw_expr): Handle
non-target expression inputs.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr104051.C: New test.

[Bug c++/105301] [11/12 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'overload' in coro_promise_type_found_p, at cp/coroutines.cc:516

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:6cae3bb65c873a2191613f7888fe949553a21f9e

commit r12-8309-g6cae3bb65c873a2191613f7888fe949553a21f9e
Author: Iain Sandoe 
Date:   Mon Apr 18 09:21:52 2022 +0100

c++, coroutines: Account for overloaded promise return_value() [PR105301].

Whether it was intended or not, it is possible to define a coroutine
promise
with multiple return_value() methods [which need not even have the same
type].

We were not accounting for this possibility in the check to see whether
both
return_value and return_void are specifier (which is prohibited by the
standard).  Fixed thus and provided an adjusted diagnostic for the case
that
multiple return_value() methods are present.

Signed-off-by: Iain Sandoe 

PR c++/105301

gcc/cp/ChangeLog:

* coroutines.cc (coro_promise_type_found_p): Account for possible
mutliple overloads of the promise return_value() method.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr105301.C: New test.

[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:15a176a833f23e64ad38690a678bf938227ce46f

commit r12-8308-g15a176a833f23e64ad38690a678bf938227ce46f
Author: Iain Sandoe 
Date:   Sun Apr 17 20:58:28 2022 +0100

c++, coroutines: Make sure our temporaries are in a bind expr [PR105287]

There are a few cases where we can generate a temporary that does not need
to be added to the coroutine frame (i.e. these are genuinely ephemeral). 
The
intent was that unnamed temporaries should not be 'promoted' to coroutine
frame entries.  However there was a thinko and these were not actually ever
added to the bind expressions being generated for the expanded awaits. 
This
meant that they were showing in the global namspace, leading to an empty
DECL_CONTEXT and the ICE reported.

Signed-off-by: Iain Sandoe 

PR c++/105287

gcc/cp/ChangeLog:

* coroutines.cc (maybe_promote_temps): Ensure generated temporaries
are added to the bind expr.
(add_var_to_bind): Fix local var naming to use portable
punctuation.
(register_local_var_uses): Do not add synthetic names to unnamed
temporaries.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr105287.C: New test.

[Bug c++/103868] ICE at end of coroutine when using asio

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:9cb1f565a91e2dd57098c43593954b57c065a19b

commit r12-8307-g9cb1f565a91e2dd57098c43593954b57c065a19b
Author: Nathan Sidwell 
Date:   Sun Apr 3 11:35:03 2022 +0100

c++, coroutines: Avoid expanding within templates [PR103868]

This is a forward-port of a patch by Nathan (against 10.x) which fixes an
open
PR.

We are ICEing because we ended up tsubst_copying something that had already
been tsubst, leading to an assert failure (mostly such repeated tsubsting
is
harmless).

We had a non-dependent co_await in a non-dependent-type template fn, so we
processed it at definition time, and then reprocessed at instantiation
time.
We fix this here by deferring substitution while processing templates.

Additional observations (for a better future fix, in the GCC13 timescale):

Exprs only have dependent type if at least one operand is dependent which
was
what the current code was intending to do.  Coroutines have the additional
wrinkle, that the current fn's type is an implicit operand.

So, if the coroutine function's type is not dependent, and the operand is
not
dependent, we should determine the type of the co_await expression using
the
DEPENDENT_EXPR wrapper machinery.  That allows us to determine the
subexpression type, but leave its operand unchanged and then instantiate it
later.

PR c++/103868

gcc/cp/ChangeLog:

* coroutines.cc (finish_co_await_expr): Do not process
non-dependent
coroutine expressions at template definition time.
(finish_co_yield_expr): Likewise.
(finish_co_return_stmt): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr103868.C: New test.

Co-Authored-by: Iain Sandoe 

[Bug c++/90107] [9/10 Regression] rejects-valid on global-namespace-qualified variable declared after class definition

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

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
Summary|[9/10/11/12 Regression] |[9/10 Regression]
   |rejects-valid on|rejects-valid on
   |global-namespace-qualified  |global-namespace-qualified
   |variable declared after |variable declared after
   |class definition|class definition
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Marek Polacek  ---
Fixed for 11.4 and GCC 12.

[Bug c++/90107] [9/10/11/12 Regression] rejects-valid on global-namespace-qualified variable declared after class definition

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:940bf20cd337df5d044c59771a28d18bea595ec9

commit r11-9944-g940bf20cd337df5d044c59771a28d18bea595ec9
Author: Marek Polacek 
Date:   Wed Apr 27 18:17:54 2022 -0400

c++: global-namespace-qualified var after class def [PR90107]

Here we wrongly reject the definition of "::N::a"

  struct A;
  namespace N { extern A a; }
  struct A {} ::N::a;

because our code to diagnose a missing ; after a class definition doesn't
realize that :: can follow a class definition.

PR c++/90107

gcc/cp/ChangeLog:

* parser.c (cp_parser_class_specifier_1): Accept :: after a class
definition.

gcc/testsuite/ChangeLog:

* g++.dg/parse/qualified6.C: New test.

(cherry picked from commit 851031b2fcd5210b96769c440db10130478d273c)