[Bug fortran/105371] The result of the merge function is different when it's type of parameters is the extensions type of derived type

[xudong.luo--- via Gcc-bugs]

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

--- Comment #7 from luoxudong  ---
(In reply to Steve Kargl from comment #5)
> On Wed, Apr 27, 2022 at 07:51:10PM +, anlauf at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105371
> > 
> > --- Comment #4 from anlauf at gcc dot gnu.org ---
> > The following untested hackish patch leads to the same answer for both 
> > cases:
> > 
> > diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
> > index 233cc42137f..abd93956217 100644
> > --- a/gcc/fortran/simplify.cc
> > +++ b/gcc/fortran/simplify.cc
> > @@ -4946,7 +4946,8 @@ gfc_simplify_merge (gfc_expr *tsource, gfc_expr 
> > *fsource,
> > gfc_expr *mask)
> >  {
> >result = gfc_copy_expr (mask->value.logical ? tsource : fsource);
> >/* Parenthesis is needed to get lower bounds of 1.  */
> > -  result = gfc_get_parentheses (result);
> > +  if (result->rank)
> > +   result = gfc_get_parentheses (result);
> >gfc_simplify_expr (result, 1);
> >return result;
> >  }
> > 
> > Thing is, I have to find a compiler that gives the result the reporter 
> > expects.
> > E.g. Intel 2021.5 prints
> > 
> >1
> > 
> > for both cases.
> > 
> 
> Harald,  thanks for looking at this!
> 
> I don't use polymorphism in my codes.
> 
> The "class(t) :: x, y, r" declaration clearly gives x, y, r the
> type type(t).  I assume that the assignments "x = t2(1,-1)" and
> "y = t2(2,-2)" now change the dynamic type of x and y to type(t2).
> When "r = merge(x,y,...)" is evaluated and assigned the dynamic
> type of r becomes type(t2).  So, the output should be
> 
> 1 -1
> 
> But, again, I'm not polymorphic.

But I still have a question, why does gfortran's code support polymorphic merge
when the mask is a logical variable? What is this code? I hope you can answer
it. Thank you very much

[Bug tree-optimization/105414] constant folding for fmin/max(snan, snan) is wrong

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
I think you want

 (if (!tree_expr_maybe_signaling_nan_p (@0))
...

instead.

[Bug pch/105403] [Bug] Buffer overflow can happen when reading pchf_data from file

[liftdat at protonmail dot com via Gcc-bugs]

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

--- Comment #2 from liftdat at protonmail dot com ---
(In reply to Geoff Keating from comment #1)
> A PCH file is a trusted input, so this really shouldn’t happen, and there
> are surely many other ways to trigger arbitrary code execution if you can
> craft one.  However a sanity check would do no harm, this code is not
> performance relevant.

Hi, I think it could also be the case when we have a ridiculously large PCH
file, which means the file itself is legal but still contains a really large
count value.
In that extreme case, the input is still considered "trusted" but we still have
a problem.

[Bug debug/105415] [10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.4

[Bug target/104375] [x86] Failure to recognize bzhi pattern when shr is present

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
backend has 

16550(define_insn "*bmi2_bzhi_3_2"
16551  [(set (match_operand:SWI48 0 "register_operand" "=r")
16552(and:SWI48
16553  (plus:SWI48
16554(ashift:SWI48 (const_int 1)
16555  (match_operand:QI 2 "register_operand" "r"))
16556(const_int -1))
16557  (match_operand:SWI48 1 "nonimmediate_operand" "rm")))
16558   (clobber (reg:CC FLAGS_REG))]
16559  "TARGET_BMI2"
16560  "bzhi\t{%2, %1, %0|%0, %1, %2}"
16561  [(set_attr "type" "bitmanip")
16562   (set_attr "prefix" "vex")
16563   (set_attr "mode" "")])


But there's extra zero_extend in pattern match.

315Failed to match this instruction:
316(parallel [
317(set (reg:DI 90)
318(zero_extend:DI (and:SI (plus:SI (reg:SI 91)
319(const_int -1 [0x]))
320(subreg:SI (reg:DI 95) 0
321(clobber (reg:CC 17 flags))
322])

[Bug debug/105415] [10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Bisecting that right now..

[Bug tree-optimization/105414] constant folding for fmin/max(snan, snan) is wrong

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Yeah, TREE_REAL_CST can't be used on @0 if it isn't a REAL_CST which nothing
guarantees.

[Bug tree-optimization/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx

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

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

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

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

commit r12-8297-gf27848a5dc4d3b16cd4112bddcb59e0916eba623
Author: Richard Biener 
Date:   Wed Apr 27 14:06:12 2022 +0200

tree-optimization/105219 - bogus max iters for vectorized epilogue

The following makes sure to take into account prologue peeling
when trying to narrow down the maximum number of iterations
computed for the vectorized epilogue.  A similar issue exists when
peeling for gaps.

2022-04-27  Richard Biener  

PR tree-optimization/105219
* tree-vect-loop.cc (vect_transform_loop): Disable
special code narrowing the vectorized epilogue max
iterations when peeling for alignment or gaps was in effect.

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

[Bug tree-optimization/105414] constant folding for fmin/max(snan, snan) is wrong

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

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

--- Comment #6 from HaoChen Gui  ---
(In reply to Richard Biener from comment #4)
> I think you want
> 
>  (if (!tree_expr_maybe_signaling_nan_p (@0))
> ...
> 
> instead.

Thanks so much for comments. Do we have a way to return a NaN directly in
match.pd when both arguments are sNaN?

[Bug tree-optimization/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx

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

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

--- Comment #20 from Richard Biener  ---
Should be fixed - please verify on the aarch64 testcase and consider adding it
to the aarch64 specific parts of the testsuite.

[Bug tree-optimization/105414] constant folding for fmin/max(snan, snan) is wrong

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

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

--- Comment #7 from Jakub Jelinek  ---
Sure, but you don't want to do that at least if flag_trapping_math.
Otherwise, the predicate would be tree_expr_signaling_nan_p and real_nan
function with "", 1 as the middle 2 arguments can create it.  But note that
nothing in match.pd does that right now, so I don't think we should do it in
this case either.

[Bug debug/105415] [9/10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[10/11/12 Regression]   |[9/10/11/12 Regression]
   |'-fcompare-debug' failure   |'-fcompare-debug' failure
   |w/ -O2  |w/ -O2
   |-ftree-parallelize-loops=2  |-ftree-parallelize-loops=2
   ||since
   ||r7-4900-g59ec925b1199f9
 CC||rsandifo at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
With -fno-common, started with r7-4900-g59ec925b1199f9.

[Bug libstdc++/105417] New: [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

Bug ID: 105417
   Summary: [11/12 Regression] powerpc64le-linux abilist changes
based on --with-long-double-format=
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

If I build on glibc 2.34 powerpc64le-linux gcc with
--enable-languages=c,c++ --disable-libsanitizer --disable-multilib
--with-long-double-format=ibm --with-long-double-128 --disable-bootstrap
vs.
--enable-languages=c,c++ --disable-libsanitizer --disable-multilib
--with-long-double-format=ieee --with-long-double-128 --disable-bootstrap
I get a different set of exported symbols.
In current releases/gcc-11 (i.e. 11.3.1) the difference from the former to the
latter is:
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11ItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
-_ZSt8to_charsPcS_u9__ieee128@@GLIBCXX_IEEE128_3.4.29 FUNC GLOBAL DEFAULT
-_ZSt8to_charsPcS_u9__ieee128St12chars_format@@GLIBCXX_IEEE128_3.4.29 FUNC
GLOBAL DEFAULT
-_ZSt8to_charsPcS_u9__ieee128St12chars_formati@@GLIBCXX_IEEE128_3.4.29 FUNC
GLOBAL DEFAULT

and on latest trunk the difference is just:
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
FUNC WEAK DEFAULT
+_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extra

[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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2022-04-28
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Target Milestone|--- |11.4

[Bug other/105404] new version of zlib

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||mliska at suse dot cz

--- Comment #4 from David Binderman  ---
(In reply to Jonathan Wakely from comment #3)
> No, because we don't use the buggy Z_FIXED feature.

Righto. Presumably the upgrade can be postponed until after the current
version of gcc trunk is released.

I note with interest that there is a lot of old K'n'R style code in the zlib
library 
which clang warns won't compile with c2x.

It might be worth adding an extra filter to file 
contrib/filter-clang-warnings.py to remove such warnings.

Pattern /zlib/.*-Wdeprecated-non-prototype would probably work.

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

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #0)
> The removed symbols for the ieee configuration in 11.3 got fixed on the
> trunk,

That was r12-7225-g813415650235b8

[Bug other/105404] new version of zlib

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
> 
> Pattern /zlib/.*-Wdeprecated-non-prototype would probably work.

Sure, I can add that. I haven't seen the warning as I'm using system zlib
library.

[Bug d/103528] [12 regression] d21 doesn't build on Solaris

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

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Rainer Orth :

https://gcc.gnu.org/g:4e4f550a5bc588a76452941cb3fb887a20f8a6cc

commit r12-8298-g4e4f550a5bc588a76452941cb3fb887a20f8a6cc
Author: Rainer Orth 
Date:   Thu Apr 28 10:27:32 2022 +0200

doc: Document Solaris D bootstrap requirements [PR 103528]

This patch documents the Solaris-specific D bootstrap requirements.

Tested by building and inspecting gccinstall.{pdf,info}.


2022-03-16  Rainer Orth  

gcc:
PR d/103528
* doc/install.texi (Tools/packages necessary for building GCC)
(GDC): Document libphobos requirement.
(Host/target specific installation notes for GCC, *-*-solaris2*):
Document libphobos and GDC specifics.

[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 #2 from Jakub Jelinek  ---
So I think we want that backported to 11.4.  And I think we just should export
the other symbols with the 3.4.29 version, adding 3.4.30 aliases for those
wouldn't improve things.

[Bug libstdc++/96850] format missing from std

[paul.f.fee at gmail dot com via Gcc-bugs]

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

Paul Fee  changed:

   What|Removed |Added

 CC||paul.f.fee at gmail dot com

--- Comment #3 from Paul Fee  ---
Duplicate of bug 104166.

I'd change the status, but I don't have the necessary bugzilla privileges.

[Bug libstdc++/96850] format missing from std

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
.

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

[Bug libstdc++/104166] Implement C++20 std::format

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||michel at lebihan dot pl

--- Comment #2 from Jakub Jelinek  ---
*** Bug 96850 has been marked as a duplicate of this bug. ***

[Bug sanitizer/105405] missed buffer-overflow in -O0

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

--- Comment #4 from Li Shaohua  ---
@Jakub, I agree with you that the above test case may access too far from the
red zone. However, for the below test case, I cannot figure out why -O0 again
did not report anything. As a user, I would think that *j[5][1]* did not reach
too far from the red zone although it might do according to your explanation.

$cat a.c
struct a {
  int b[9];
  long h
};
int i;
struct a j[6][1];
main() {
if (j[5][1].h) {
char k[4];
k;
}
}
$

[Bug sanitizer/105405] missed buffer-overflow in -O0

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
j[5][1].h is 36 after the end of a array, that is definitely too far.
Red zone can be 16 bytes or even less in certain cases (e.g. in the PR105396
case it is 12 bytes in between d and b variables).
ASan mostly protects against buffer overflows, something accesses the last byte
of a variable, then the byte after it, ... (or similarly the first byte of a
variable, then the byte before it, ...).
-fsanitize=undefined on the other side includes the bounds sanitizer that
verifies array indexes by comparing them against the number of elements the
array has.

[Bug c++/105418] New: 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

Bug ID: 105418
   Summary: debug_tree does not support well for std::construct_at
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guojiufu at gcc dot gnu.org
  Target Milestone: ---

During debug GCC, when call "debug_tree" inside gdb, I found "debug_tree" fail
on "std::construct_at". It fails from "decl_as_string"

To reproduce this issue quicker, the below patch could be used. 
---
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index cebf9c35c1d..ead4112dd37 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -4793,10 +4793,12 @@ trees_out::get_tag (tree t)
 }

 /* Insert T into the map, return its tag number.*/
-
+const char* decl_as_string(tree, int);//void debug_tree(tree);
 int
 trees_out::insert (tree t, walk_kind walk)
 {
+  if (TREE_CODE (t) == FUNCTION_DECL)
+decl_as_string (t,TFF_DECL_SPECIFIERS);//debug_tree (t);
   gcc_checking_assert (walk != WK_normal || !TREE_VISITED (t));
   int tag = --ref_num;
   bool existed;
--
configure the GCC with below command:
$ configure --enable-languages=c,c++ --with-cpu=native --enable-checking
--with-long-double-128
--prefix=/home/guojiufu/gcc/install/gcc-mainline-base-debug --disable-bootstrap

Using test case: t.cc
---
#include 

struct S {
int x;
float y;
double z;

S(int x, float y, double z) : x{x}, y{y}, z{z} { }

};

void foo()
{
alignas(S) unsigned char storage[sizeof(S)];

S* ptr = std::construct_at(reinterpret_cast(storage), 42, 2.71828f,
3.1415);

std::destroy_at(ptr);
}


$ g++ -fmodule-header t.cc -std=gnu++20
In file included from
/home/guojiufu/gcc/build/gcc-mainline-base-debug/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/stl_iterator.h:85,
 from
/home/guojiufu/gcc/build/gcc-mainline-base-debug/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:67,
 from
/home/guojiufu/gcc/build/gcc-mainline-base-debug/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/memory:63,
 from t.cc:1:
/home/guojiufu/gcc/build/gcc-mainline-base-debug/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/stl_construct.h:96:17:
internal compiler error: in perform_overload_resolution, at cp/call.cc:4710
   96 | -> decltype(::new((void*)0) _Tp(std::declval<_Args>()...))
  | ^
0x106b32cb perform_overload_resolution
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/call.cc:4710
0x106b3d9f build_operator_new_call(tree_node*, vec**, tree_node**, tree_node**, tree_node*, tree_node*, tree_node**,
int)
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/call.cc:4929
0x108d0743 build_new_1
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/init.cc:3412
0x108d300f build_new(unsigned int, vec**,
tree_node*, tree_node*, vec**, int, int)
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/init.cc:4014
0x10b210ef tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/pt.cc:20557
0x10b01ddf tsubst(tree_node*, tree_node*, int, tree_node*)
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/pt.cc:16306
0x10896f6b dump_template_bindings
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/error.cc:486
0x1089f887 dump_substitution
/home/guojiufu/gcc/gcc-mainline-base/gcc/cp/error.cc:1654

[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

   Priority|P3  |P5

--- Comment #1 from Jiu Fu Guo  ---
Since this just occurs during debugging GCC on the corner case, I put it a low
priority.

[Bug sanitizer/105405] missed buffer-overflow in -O0

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

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

--- Comment #6 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #5)
> j[5][1].h is 36 after the end of a array, that is definitely too far.

Yes. Just a small note that clang emits there a bit bigger red-zone:

=>0x801c50a0: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9[f9]f9 f9
  0x801c50b0: 04 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00

and thus catches that.

> Red zone can be 16 bytes or even less in certain cases (e.g. in the PR105396
> case it is 12 bytes in between d and b variables).
> ASan mostly protects against buffer overflows, something accesses the last
> byte of a variable, then the byte after it, ... (or similarly the first byte
> of a variable, then the byte before it, ...).
> -fsanitize=undefined on the other side includes the bounds sanitizer that
> verifies array indexes by comparing them against the number of elements the
> array has.

gcc-11 pr105405.c -fsanitize=undefined && ./a.out
pr105405.c:10:13: runtime error: index 1 out of bounds for type 'a [1]'

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

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

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

--- Comment #2 from Andrew Pinski  ---
I wonder if this is because the tree is jot fully constructed yet. Nor the
scope. So this issue might not be a bug.

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|enhancement |trivial

[Bug ipa/100413] [11/12 Regression] ICE: failed to reclaim unneeded function with custom flags since r11-4267-g0e590b68fa374365

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

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

--- Comment #7 from Martin Jambor  ---
I proposed the aforementioned fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593732.html

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

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

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

--- Comment #3 from Andrew Pinski  ---
Debug_tree really only works post frontend in many cases. Especially when
things like overload sets are not resolved and all. You are better just to look
at the contents of the tree itself.

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug libstdc++/104167] Implement C++20 std::chrono::utc_clock, std::chrono::tzdb etc.

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug debug/105415] [9/10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
What I see is that for the n variable we create a varpool_node during the FE
finish_decl, then during symbol_table::remove_unreachable_nodes it is removed,
but with -g (and only with that, not with -g0) we create yet another
varpool_node for the same variable during sched1 pass because we have:
(debug_insn 7 6 8 3 (var_location:SI D#1 (mem/c:SI (symbol_ref:DI ("n") [flags
0x82]  ) [1 n+0 S4 A32])) "pr105415.c":11:9 -1
 (nil))
as the only reference to n and in:
#0  varpool_node::get_create (decl=) at
../../gcc/varpool.cc:153
#1  0x00c7cfb9 in symtab_node::get_create (node=) at ../../gcc/cgraph.h:3362
#2  0x00c77730 in compare_base_symbol_refs (x_base=0x7fffea2c8a78,
y_base=0x7fffea2c8a28, distance=0x0) at ../../gcc/alias.cc:2223
#3  0x00c77b67 in base_alias_check (x=0x7fffea2cc1e0,
x_base=0x7fffea2c8a28, y=0x7fffea2c8a78, y_base=0x7fffea2c8a78,
x_mode=E_SImode, y_mode=E_SImode)
at ../../gcc/alias.cc:2309
#4  0x00c7b066 in write_dependence_p (mem=0x7fffea2cc000,
x=0x7fffea2c5a38, x_mode=E_VOIDmode, x_addr=0x7fffea2cc1e0,
mem_canonicalized=false, x_canonicalized=false, 
writep=false) at ../../gcc/alias.cc:3156
#5  0x00c7b285 in anti_dependence (mem=0x7fffea2cc000,
x=0x7fffea2c5a38) at ../../gcc/alias.cc:3183
#6  0x02652e29 in sched_analyze_1 (deps=0x7fffd240,
x=0x7fffea2c5ca8, insn=0x7fffea3efac0) at ../../gcc/sched-deps.cc:2501
#7  0x0265407c in sched_analyze_insn (deps=0x7fffd240,
x=0x7fffea2c5ca8, insn=0x7fffea3efac0) at ../../gcc/sched-deps.cc:2931
#8  0x02656c52 in deps_analyze_insn (deps=0x7fffd240,
insn=0x7fffea3efac0) at ../../gcc/sched-deps.cc:3683
#9  0x0265723d in sched_analyze (deps=0x7fffd240,
head=0x7fffea3ef880, tail=0x7fffea3efac0) at ../../gcc/sched-deps.cc:3829
#10 0x01375306 in compute_block_dependences (bb=0) at
../../gcc/sched-rgn.cc:2733
#11 0x01377154 in sched_rgn_compute_dependencies (rgn=1) at
../../gcc/sched-rgn.cc:3360
#12 0x0137677c in schedule_region (rgn=1) at
../../gcc/sched-rgn.cc:3113
#13 0x0137797f in schedule_insns () at ../../gcc/sched-rgn.cc:3518
#14 0x01378224 in rest_of_handle_sched () at
../../gcc/sched-rgn.cc:3722
create the varpool node again.  Which shifts the node->order of later created
cgraph or varpool nodes.

[Bug debug/105415] [9/10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9

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

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

--- Comment #4 from Jakub Jelinek  ---
Wonder about:
--- gcc/alias.cc.jj 2022-02-21 16:51:50.261232505 +0100
+++ gcc/alias.cc2022-04-28 11:57:18.940425126 +0200
@@ -2219,8 +2219,10 @@ compare_base_symbol_refs (const_rtx x_ba
  || (!TREE_STATIC (x_decl) && !TREE_PUBLIC (x_decl)))
return 0;

-  symtab_node *x_node = symtab_node::get_create (x_decl)
-   ->ultimate_alias_target ();
+  symtab_node *x_node = symtab_node::get (x_decl);
+  if (x_node == NULL)
+   return 0;
+  x_node = x_node->ultimate_alias_target ();
   /* External variable cannot be in section anchor.  */
   if (!x_node->definition)
return 0;
It would surprise me if we needed to create varpool nodes so late, if they
don't exist, with the exception of DEBUG_INSNs referencing already removed
symbols I don't see the reason why the varpool nodes wouldn't be present.
Another option would be for the x_node == NULL case to use x_decl rather than
x_node->decl, i.e. just assume x_decl isn't an alias if it doesn't have a
varpool node.

[Bug c++/105419] New: [11 Regression] std::initializer_list constructor invalid in C++20 mode

[whisperity at gmail dot com via Gcc-bugs]

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

Bug ID: 105419
   Summary: [11 Regression] std::initializer_list constructor
invalid in C++20 mode
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: whisperity at gmail dot com
  Target Milestone: ---

The following code is rejected when compiled with `-std=c++20` if using G++
11.y. `-std=c++17` accepts it.

G++ 10.y accepts in both C++17 and C++20 version.


#include 

template 
struct C
{
C(std::initializer_list L) {}
};

int main()
{
C Cont = {1, 2};
}

Platform: X86_64 (amd64) Linux (specifically Ubuntu 20.04 LTS)
Godbolt: http://godbolt.org/z/rrbae9P5d

Compiler versions: 

Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-10.3.0/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-10.3.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,go,d --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (Compiler-Explorer-Build) 
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s'
'-masm=intel' '-S' '-std=c++17' '-v' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'

/opt/compiler-explorer/gcc-10.3.0/bin/../libexec/gcc/x86_64-linux-gnu/10.3.0/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-10.3.0/bin/../lib/gcc/x86_64-linux-gnu/10.3.0/
-D_GNU_SOURCE  -quiet -dumpbase example.cpp -masm=intel -mtune=generic
-march=x86-64 -auxbase-strip /app/output.s -g -std=c++17 -version
-fdiagnostics-color=always -o /app/output.s
GNU C++17 (Compiler-Explorer-Build) version 10.3.0 (x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP



Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-11.3.0/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-11.3.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,go,d --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build-gcc--binutils-2.36.1
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.3.0 (Compiler-Explorer-Build-gcc--binutils-2.36.1) 
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s'
'-masm=intel' '-S' '-std=c++20' '-v' '-shared-libgcc' '-mtune=generic'
'-march=x86-64' '-dumpdir' '/app/'

/opt/compiler-explorer/gcc-11.3.0/bin/../libexec/gcc/x86_64-linux-gnu/11.3.0/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-11.3.0/bin/../lib/gcc/x86_64-linux-gnu/11.3.0/
-D_GNU_SOURCE  -quiet -dumpdir /app/ -dumpbase output.cpp -dumpbase-ext
.cpp -masm=intel -mtune=generic -march=x86-64 -g -std=c++20 -version
-fdiagnostics-color=always -o /app/output.s
GNU C++20 (Compiler-Explorer-Build-gcc--binutils-2.36.1) version 11.3.0
(x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.6,
MPC version 1.0.3, isl version isl-0.18-GMP

[Bug c++/105419] [11 Regression] std::initializer_list constructor invalid in C++20 mode

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

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

--- Comment #1 from Andrew Pinski  ---
C is the cause of the problems.  Changing it to just C works.

[Bug c++/105419] [11 Regression] std::initializer_list constructor invalid in C++20 mode

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=97202

--- Comment #2 from Andrew Pinski  ---
C++ DR 2237 changes this to be invalid code for C++20. GCC is correctly
rejecting it.

This is a dup of bug 103593.

Note the diagnostic issue on describing why this is now invalid is PR 97202.

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

[Bug c++/103593] [11/12 Regression] Naming the constructor of a template class without using the injected-class-name causes parse error with C++20

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||whisperity at gmail dot com

--- Comment #5 from Andrew Pinski  ---
*** Bug 105419 has been marked as a duplicate of this bug. ***

[Bug target/105331] [11/12 Regression] -Wmaybe-uninitialized warning on va_arg with double _Complex on va_list pointer

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

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

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

https://gcc.gnu.org/g:89dbf9a5f55e0f7565865d1b38e681ef7d76afaf

commit r12-8301-g89dbf9a5f55e0f7565865d1b38e681ef7d76afaf
Author: Jakub Jelinek 
Date:   Thu Apr 28 12:33:59 2022 +0200

i386: Fix up ix86_gimplify_va_arg [PR105331]

On the following testcase we emit a bogus
'va_arg_tmp.5' may be used uninitialized
warning.  The reason is that when gimplifying the addr = &temp;
statement, the va_arg_tmp temporary var for which we emit ADDR_EXPR
is not TREE_ADDRESSABLE, prepare_gimple_addressable emits some extra
code to initialize the newly addressable var from its previous value,
but it is a new variable which hasn't been initialized yet and will
be later, so we end up initializing it with uninitialized SSA_NAME:
  va_arg_tmp.6 = va_arg_tmp.5_14(D);
  addr.2_16 = &va_arg_tmp.6;
  _17 = MEM[(double *)sse_addr.4_13];
  MEM[(double * {ref-all})addr.2_16] = _17;
and with -O1 we actually don't DSE it before the warning is emitted.
If we make the temp TREE_ADDRESSABLE before the gimplification, then
this prepare_gimple_addressable path isn't taken and we effectively
omit the first statement above and so the bogus warning is gone.

I went through other backends and didn't find another instance of this
problem.

2022-04-28  Jakub Jelinek  

PR target/105331
* config/i386/i386.cc (ix86_gimplify_va_arg): Mark va_arg_tmp
temporary TREE_ADDRESSABLE before trying to gimplify ADDR_EXPR
of it.

* gcc.dg/pr105331.c: New test.

[Bug target/105331] [11 Regression] -Wmaybe-uninitialized warning on va_arg with double _Complex on va_list pointer

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12 Regression]  |[11 Regression]
   |-Wmaybe-uninitialized   |-Wmaybe-uninitialized
   |warning on va_arg with  |warning on va_arg with
   |double _Complex on va_list  |double _Complex on va_list
   |pointer |pointer

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

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

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
you don't include enough of the backtrace to see where debug_tree comes into
the picture (or decl_as_string FWIW).

Certainly we shouldn't tsubst from debug_tree, so maybe there's something that
can be done in the C++ FE here.

[Bug testsuite/105095] gcc.dg/vect/complex/fast-math-complex-* tests are not executed

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Tamar Christina
:

https://gcc.gnu.org/g:73ceece5363b1a06196191aa6a7254ceab5b9cf4

commit r11-9943-g73ceece5363b1a06196191aa6a7254ceab5b9cf4
Author: Tamar Christina 
Date:   Thu Apr 28 12:32:26 2022 +0100

testsuite: Backport testsuite changes from GCC 12 to GCC 11

This backports the testsuite changes from mainline to GCC 11.
This enables some tests that were not running and fix some
unresolved cases. The test output are adjusted to what GCC 11 could detect.

gcc/testsuite/ChangeLog:

PR testsuite/105095
* gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-float.c: Update
for
codegen.
* gcc.dg/vect/complex/fast-math-complex-add-double.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-half-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-pattern-double.c:
Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-pattern-float.c:
Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-pattern-half-float.c:
Likewise.
* gcc.dg/vect/complex/fast-math-complex-mla-half-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mls-double.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mls-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mls-half-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mul-double.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mul-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mul-half-float.c: Likewise.
* gcc.dg/vect/vect.exp: Add extra letter to filter.

[Bug testsuite/105095] gcc.dg/vect/complex/fast-math-complex-* tests are not executed

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

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

Tamar Christina  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #9 from Tamar Christina  ---
.

[Bug debug/105415] [9/10/11/12 Regression] '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 since r7-4900-g59ec925b1199f9

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

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

--- Comment #5 from Jakub Jelinek  ---
I've included debug printouts into the if (x_node == NULL) body before return
0;
and sort -u of the dump shows in powerpc64le-linux bootstrap so far (still
ongoing) shows:
../../gcc/fortran/decl.cc match_attr_spec *.LC320
../../gcc/fortran/decl.cc match_attr_spec *.LC455
../../gcc/fortran/decl.cc match_attr_spec *.LC456
../../gcc/fortran/decl.cc match_attr_spec *.LC457
../../gcc/fortran/decl.cc match_attr_spec *.LC458
../../gcc/fortran/decl.cc match_attr_spec *.LC459
../../gcc/fortran/decl.cc match_attr_spec *.LC460
../../gcc/fortran/decl.cc match_attr_spec *.LC461
../../gcc/fortran/decl.cc match_attr_spec *.LC462
../../gcc/fortran/decl.cc match_attr_spec *.LC463
../../gcc/fortran/decl.cc match_attr_spec *.LC464
../../gcc/fortran/decl.cc match_attr_spec *.LC465
../../gcc/fortran/decl.cc match_attr_spec *.LC466
../../gcc/fortran/decl.cc match_attr_spec *.LC467
../../gcc/fortran/decl.cc match_attr_spec *.LC468
../../gcc/fortran/decl.cc match_attr_spec *.LC469
../../gcc/fortran/decl.cc match_attr_spec *.LC470
../../gcc/fortran/decl.cc match_attr_spec *.LC471
../../gcc/fortran/decl.cc match_attr_spec *.LC472
../../gcc/fortran/decl.cc match_attr_spec *.LC473
../../gcc/fortran/decl.cc match_attr_spec *.LC474
../../gcc/fortran/decl.cc match_attr_spec *.LC475
../../gcc/fortran/decl.cc match_attr_spec *.LC476
../../gcc/fortran/parse.cc next_statement *.LC704
../../gcc/fortran/scanner.cc gfc_next_char_literal *.LC52
../../gcc/fortran/scanner.cc gfc_next_char_literal *.LC53
../../gcc/fortran/scanner.cc gfc_next_char_literal *.LC57
../../gcc/fortran/scanner.cc load_file *.LC102
so seems decls without varpool nodes are mostly constant pool decls.
So perhaps
--- gcc/alias.cc.jj 2022-04-28 12:33:15.169434009 +0200
+++ gcc/alias.cc2022-04-28 13:47:34.402456905 +0200
@@ -2219,12 +2219,19 @@ compare_base_symbol_refs (const_rtx x_ba
  || (!TREE_STATIC (x_decl) && !TREE_PUBLIC (x_decl)))
return 0;

-  symtab_node *x_node = symtab_node::get_create (x_decl)
-   ->ultimate_alias_target ();
-  /* External variable cannot be in section anchor.  */
-  if (!x_node->definition)
+  symtab_node *x_node = symtab_node::get (x_decl);
+  tree x_decl2 = x_decl;
+  if (x_node != NULL)
+   {
+ x_node = x_node->ultimate_alias_target ();
+ /* External variable cannot be in section anchor.  */
+ if (!x_node->definition)
+   return 0;
+ x_decl2 = x_node->decl;
+   }
+  else if (DECL_EXTERNAL (x_decl))
return 0;
-  x_base = XEXP (DECL_RTL (x_node->decl), 0);
+  x_base = XEXP (DECL_RTL (x_decl2), 0);
   /* If not in anchor, we can disambiguate.  */
   if (!SYMBOL_REF_HAS_BLOCK_INFO_P (x_base))
return 0;
might be better.

[Bug c/78155] missing warning on invalid usage of functions/macros from (isalpha et al.)

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

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

Eric Gallager  changed:

   What|Removed |Added

Summary|missing warning on invalid  |missing warning on invalid
   |isalpha et al.  |usage of functions/macros
   ||from  (isalpha et
   ||al.)

--- Comment #7 from Eric Gallager  ---
retitling to help me find it more easily again later

[Bug c/99950] Option -Wchar-subscripts leads to wrong fixes when used with functions from

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

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

Eric Gallager  changed:

   What|Removed |Added

Summary|Option -Wchar-subscripts|Option -Wchar-subscripts
   |leads to wrong fixes|leads to wrong fixes when
   ||used with functions from
   ||

--- Comment #3 from Eric Gallager  ---
retitling for searchability purposes

[Bug tree-optimization/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[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 #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:4e117418fb71f508c479e0144500f4da9cc92520

commit r12-8303-g4e117418fb71f508c479e0144500f4da9cc92520
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.

[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 #4 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:851031b2fcd5210b96769c440db10130478d273c

commit r12-8304-g851031b2fcd5210b96769c440db10130478d273c
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.cc (cp_parser_class_specifier_1): Accept :: after a class
definition.

gcc/testsuite/ChangeLog:

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

[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)

[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++/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 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++/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 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++/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 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++/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 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 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 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&action=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 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 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 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&action=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 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&action=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*)&mask +
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] 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 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 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 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&action=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 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 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 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 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++/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++/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++/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 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 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/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 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 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 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++/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++/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++/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++/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++/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++/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++/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++/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++/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&action=edit
reproducer

[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 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 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/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 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 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 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 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