[Bug pch/14940] PCH largefile test fails on various platforms

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

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

--- Comment #56 from Andrew Pinski  ---
(In reply to LIU Hao from comment #55)
> (In reply to Andrew Pinski from comment #54)
> > (In reply to LIU Hao from comment #53)
> > > The patch no longer applies to GCC 12.
> > 
> > Right because I think this issue has been fixed by r12-5855-g747380f47da0da 
> > .
> 
> No, at least not completely. In 'gcc/config/i386/host-mingw32.cc' there is
> still the 128MiB hard limit:
> 
> ```
> /* FIXME: Is this big enough?  */
> static const size_t pch_VA_max_size  = 128 * 1024 * 1024;
> ```

Right, some hosts need to be changed.
Looks like only darwin and linux was fixed.

See r12-5857-g0d5db1dd65b452 for the change done for darwin. Maybe a similar
change is needed for Mingw.

[Bug fortran/105542] New: [F03] Orthogonal standard-conforming type finalization tests

[damian at archaeologic dot codes via Gcc-bugs]

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

Bug ID: 105542
   Summary: [F03] Orthogonal standard-conforming type finalization
tests
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at archaeologic dot codes
  Target Milestone: ---

In case it's useful to gfortran developers, the Reference-Counter repository
(https://github.com/sourceryinstitute/reference-counter) contains a
test/compiler_test.f90 file that separately tests each of the scenarios in
which Fortran 2018 clause 7.5.6.3 requires type finalization to occur.  One
function tests each scenario.  A comment near the top of each such function
cites the paragraph number of the corresponding requirement.  To download and
run the tests on macOS or Linux with gfortran 12.1.0 and the Fortran Package
Manager (fpm) already installed, execute the following commands:

git clone https://github.com/sourceryinstitute/reference-counter
cd reference-counter
fpm test

for which the trailing output is


Running Tests

Test that
The compiler
finalizes a non-allocatable object on the LHS of an intrinsic
assignment
finalizes an allocated allocatable LHS of an intrinsic assignment
finalizes a target when the associated pointer is deallocated
finalizes an object upon explicit deallocation
finalizes a non-pointer non-allocatable array object at the END
statement
finalizes a non-pointer non-allocatable object at the end of a block
construct
finalizes a function reference on the RHS of an intrinsic assignment
finalizes a specification expression function result
finalizes an intent(out) derived type dummy argument
finalizes an allocatable component object
A ref_reference
does not leak when constructed, assigned, and then explicitly freed

A total of 11 test cases

Failed
Took 1.94e-4 seconds

Test that
The compiler
finalizes a non-allocatable object on the LHS of an intrinsic
assignment
Expected
|1|
but got
|0|
finalizes an allocated allocatable LHS of an intrinsic assignment
Expected
|1|
but got
|0|
finalizes a function reference on the RHS of an intrinsic assignment
Expected
|1|
but got
|0|
finalizes a specification expression function result
Expected
|1|
but got
|0|

4 of 11 cases failed
4 of 11 assertions failed

STOP 1
 Execution failed for object " reference-counter-test "
*cmd_run*:stopping due to failed executions
STOP 1

[Bug c++/105529] [13 Regression] cxx_eval_store_expression on arm because of ctor returning this since r13-160-g967cdbe6629653

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/105529] [13 Regression] cxx_eval_store_expression on arm because of ctor returning this since r13-160-g967cdbe6629653

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

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

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

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

commit r13-221-gbb2921ab84dba014f24be06663636c7fb1361474
Author: Jason Merrill 
Date:   Mon May 9 16:03:35 2022 -0400

c++: fix arm-eabi crash building libstdc++ [PR105529]

My recent change to cxx_eval_store_expression asserts that the target and
value can only end up having different types in the case of an empty base;
this was crashing arm-eabi compilers because in that ABI [cd]tors
return *this, and weren't converting it to void* first.

This also shares the 'return this' code between the three places it occurs.

Thanks to Marek for the tests.

PR c++/105529

gcc/cp/ChangeLog:

* decl.cc (maybe_return_this): Replace...
(finish_constructor_body, finish_destructor_body): ...these.
(finish_function_body): Call it.
* optimize.cc (build_delete_destructor_body): Call it.
* cp-tree.h (maybe_return_this): Declare.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/constexpr-dtor13.C: New test.
* g++.dg/cpp2a/constexpr-dtor14.C: New test.

[Bug pch/14940] PCH largefile test fails on various platforms

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #55 from LIU Hao  ---
(In reply to Andrew Pinski from comment #54)
> (In reply to LIU Hao from comment #53)
> > The patch no longer applies to GCC 12.
> 
> Right because I think this issue has been fixed by r12-5855-g747380f47da0da .

No, at least not completely. In 'gcc/config/i386/host-mingw32.cc' there is
still the 128MiB hard limit:

```
/* FIXME: Is this big enough?  */
static const size_t pch_VA_max_size  = 128 * 1024 * 1024;
```

[Bug pch/14940] PCH largefile test fails on various platforms

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

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

--- Comment #54 from Andrew Pinski  ---
(In reply to LIU Hao from comment #53)
> The patch no longer applies to GCC 12.

Right because I think this issue has been fixed by r12-5855-g747380f47da0da .

[Bug pch/14940] PCH largefile test fails on various platforms

[lh_mouse at 126 dot com via Gcc-bugs]

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

LIU Hao  changed:

   What|Removed |Added

 CC||lh_mouse at 126 dot com

--- Comment #53 from LIU Hao  ---
The patch no longer applies to GCC 12.

[Bug preprocessor/101168] gnu++14 complains about altivec types defined with using keyword in the same file with preprocessor macros

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jiu Fu Guo :

https://gcc.gnu.org/g:067fe66c8ba9b16feacf66fce9ae668091e42821

commit r13-220-g067fe66c8ba9b16feacf66fce9ae668091e42821
Author: Jiufu Guo 
Date:   Mon May 9 17:48:00 2022 +0800

rs6000: avoid peeking eof after __vector

There is a rare corner case: where vector is followed only by one
valid identifer and the ";" which is near the end of the file.

Like the case in PR101168:
using vdbl =  __vector double;
#define BREAK 1

For this case, "vector double" is followed by CPP_SEMICOLON and then
EOF.  There is no more tokens need to check for this case.

PR preprocessor/101168

gcc/ChangeLog:

* config/rs6000/rs6000-c.cc (rs6000_macro_to_expand):
Avoid empty identifier.

gcc/testsuite/ChangeLog:

* g++.target/powerpc/pr101168.C: New test.

[Bug c++/105541] ICE: Segmentation fault when template lambda in requires-clause

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
(In reply to 康桓瑋 from comment #0)
> template
> constexpr bool is_hello = false;
> 
> template 
>   requires (!is_hello)
> class Hello;
> 
> template 
>   requires (!is_hello)
> class Hello {};
> 
> static_assert(requires { []>{}; });
> 
> https://godbolt.org/z/rTM5chYf3
> 
> GCC-11 rejects this valid syntax, and GCC-12 emits ICE.

Sorry, GCC-11 compiles fine, this is a 12-regression.

[Bug c++/105541] New: ICE: Segmentation fault when template lambda in requires-clause

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 105541
   Summary: ICE: Segmentation fault when template lambda in
requires-clause
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

template
constexpr bool is_hello = false;

template 
  requires (!is_hello)
class Hello;

template 
  requires (!is_hello)
class Hello {};

static_assert(requires { []>{}; });

https://godbolt.org/z/rTM5chYf3

GCC-11 rejects this valid syntax, and GCC-12 emits ICE.

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

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

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

Bug 104565 Summary: [10 Regression] constexpr template goes wrong with class 
and call to constexpr method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104565

   What|Removed |Added

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

[Bug c++/104565] [10 Regression] constexpr template goes wrong with class and call to constexpr method

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #9 from Patrick Palka  ---
Fixed for GCC 10.4/11.3/12, thanks for the bug report.

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

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

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

Patrick Palka  changed:

   What|Removed |Added

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

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

[Bug c++/105304] [10 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 #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

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

commit r10-10605-g9a8b7edbe65ec6350a996eab51a7c26a087e6d2b
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++/103455] [9/10 Regression] internal compiler error: in dependent_type_p since r9-713-gd9338471b91bbe6e1

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

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

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

https://gcc.gnu.org/g:09ab962a42d81eff636c1ebc7de43dac7cc7a7c0

commit r10-10604-g09ab962a42d81eff636c1ebc7de43dac7cc7a7c0
Author: Patrick Palka 
Date:   Sat Mar 26 10:20:16 2022 -0400

c++: ICE when building builtin operator->* set [PR103455]

Here when constructing the builtin operator->* candidate set according
to the available conversion functions for the operand types, we end up
considering a candidate with C1=T (through B's dependent conversion
function) and C2=F, during which we crash from DERIVED_FROM_P because
dependent_type_p sees a TEMPLATE_TYPE_PARM outside of a template
context.

Sidestepping the question of whether we should be considering such a
dependent conversion function here in the first place, it seems futile
to test DERIVED_FROM_P for anything other than an actual class type, so
this patch fixes this ICE by simply guarding the DERIVED_FROM_P test
with CLASS_TYPE_P instead of MAYBE_CLASS_TYPE_P.

PR c++/103455

gcc/cp/ChangeLog:

* call.c (add_builtin_candidate) : Test
CLASS_TYPE_P instead of MAYBE_CLASS_TYPE_P.

gcc/testsuite/ChangeLog:

* g++.dg/overload/builtin6.C: New test.

(cherry picked from commit 04f19580e8dbdbc7366d0f5fd068aa0cecafdc9d)

[Bug c++/104565] [10 Regression] constexpr template goes wrong with class and call to constexpr method

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

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

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

https://gcc.gnu.org/g:22682e291ef4b5dcb6be3a12089dbbc46889002c

commit r10-10603-g22682e291ef4b5dcb6be3a12089dbbc46889002c
Author: Patrick Palka 
Date:   Thu Feb 17 08:35:23 2022 -0500

c++: double non-dep folding from finish_compound_literal [PR104565]

In finish_compound_literal, we perform non-dependent expr folding before
the call to check_narrowing ever since r9-5973.  But ever since r10-7096,
check_narrowing also performs non-dependent expr folding of its own.
This double folding means tsubst will see non-templated trees during the
second folding, which causes a spurious error in the below testcase.

This patch removes the former folding operation; it seems obviated by
the latter one.

PR c++/104565

gcc/cp/ChangeLog:

* semantics.c (finish_compound_literal): Don't perform
non-dependent expr folding before calling check_narrowing.

gcc/testsuite/ChangeLog:

* g++.dg/template/non-dependent22.C: New test.

(cherry picked from commit 6bbd8afee0036c274f5ebb5b48d6fdc2091bd046)

[Bug c++/101532] [12 Regression] ICE in finish_expr_stmt, at cp/semantics.c:859

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

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

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

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

commit r10-10602-gad0398474aff6bb7726e9117711b0a111a4b69e7
Author: Patrick Palka 
Date:   Tue Jan 25 15:04:49 2022 -0500

c++: deleted fn and noexcept inst [PR101532, PR104225]

Here when attempting to use B's implicitly deleted default constructor,
mark_used rightfully returns false, but for the wrong reason: it
tries to instantiate the synthesized noexcept specifier which then only
silently fails because get_defaulted_eh_spec suppresses diagnostics
for deleted functions.  This lack of diagnostics causes us to crash on
the first testcase below (thanks to the assert in finish_expr_stmt), and
silently accept the second testcase.

To fix this, this patch makes mark_used avoid attempting to instantiate
the noexcept specifier of a deleted function, so that we'll instead
directly reject (and diagnose) the function due to its deletedness.

PR c++/101532
PR c++/104225

gcc/cp/ChangeLog:

* decl2.c (mark_used): Don't consider maybe_instantiate_noexcept
on a deleted function.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/nsdmi-template21.C: New test.
* g++.dg/cpp0x/nsdmi-template21a.C: New test.

(cherry picked from commit bc90dd0ecf02e11d47d1af7f627e2e2acaa40106)

[Bug c++/104225] [9/10 Regression] accepts-invalid new expression that uses deleted implicit default constructor of class specialization

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

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

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

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

commit r10-10602-gad0398474aff6bb7726e9117711b0a111a4b69e7
Author: Patrick Palka 
Date:   Tue Jan 25 15:04:49 2022 -0500

c++: deleted fn and noexcept inst [PR101532, PR104225]

Here when attempting to use B's implicitly deleted default constructor,
mark_used rightfully returns false, but for the wrong reason: it
tries to instantiate the synthesized noexcept specifier which then only
silently fails because get_defaulted_eh_spec suppresses diagnostics
for deleted functions.  This lack of diagnostics causes us to crash on
the first testcase below (thanks to the assert in finish_expr_stmt), and
silently accept the second testcase.

To fix this, this patch makes mark_used avoid attempting to instantiate
the noexcept specifier of a deleted function, so that we'll instead
directly reject (and diagnose) the function due to its deletedness.

PR c++/101532
PR c++/104225

gcc/cp/ChangeLog:

* decl2.c (mark_used): Don't consider maybe_instantiate_noexcept
on a deleted function.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/nsdmi-template21.C: New test.
* g++.dg/cpp0x/nsdmi-template21a.C: New test.

(cherry picked from commit bc90dd0ecf02e11d47d1af7f627e2e2acaa40106)

[Bug libstdc++/105540] [11 Regression] gcc-11-20220506 failure to build on Cygwin due to lack of secure_getenv

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed by r11-9971, thanks for the report and sorry for the breakage.

[Bug libstdc++/104217] [12 Regression] gcc-12-20220123 failure to build on Cygwin due to lack of secure_getenv

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

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

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

https://gcc.gnu.org/g:8562fbaae9d0c06316188c4749a2171071b6b926

commit r11-9971-g8562fbaae9d0c06316188c4749a2171071b6b926
Author: Jonathan Wakely 
Date:   Tue Jan 25 10:11:36 2022 +

libstdc++: Define _GNU_SOURCE for secure_getenv on Cygwin [PR104217]

For GNU/Linux G++ defines _GNU_SOURCE automatically, but not for Cygwin.
This means secure_getenv is not declared by Cygwin's , even
though autoconf detected it is present in the library. Define it in the
source files that want to use secure_getenv.

libstdc++-v3/ChangeLog:

PR libstdc++/104217
* src/c++17/fs_ops.cc (_GNU_SOURCE): Define.
* src/filesystem/dir.cc (_GNU_SOURCE): Define.
* src/filesystem/ops.cc (_GNU_SOURCE): Define.

(cherry picked from commit e20486d508afdf22790a271e90ca76d8df5fa7a5)

[Bug libstdc++/105540] [11 Regression] gcc-11-20220506 failure to build on Cygwin due to lack of secure_getenv

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

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

--- Comment #2 from Jonathan Wakely  ---
I forgot to backport r12-6867

[Bug libstdc++/105540] [11 Regression] gcc-11-20220506 failure to build on Cygwin due to lack of secure_getenv

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-05-09
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libstdc++/105540] [11 Regression] gcc-11-20220506 failure to build on Cygwin due to lack of secure_getenv

[mckelvey at maskull dot com via Gcc-bugs]

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

--- Comment #1 from James McKelvey  ---
Created attachment 52946
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52946=edit
Config log

[Bug libstdc++/105540] [11 Regression] gcc-11-20220506 failure to build on Cygwin due to lack of secure_getenv

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=65018
Version|11.0|11.3.1
   Target Milestone|--- |11.4
Summary|gcc-11-20220506 failure to  |[11 Regression]
   |build on Cygwin due to lack |gcc-11-20220506 failure to
   |of secure_getenv|build on Cygwin due to lack
   ||of secure_getenv

[Bug c/105510] error: initializer element is not constant

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #4 from joseph at codesourcery dot com  ---
We have a documented extension:

As a GNU extension, GCC allows initialization of objects with static
storage
duration by compound literals (which is not possible in ISO C99 because
the initializer is not a constant).
It is handled as if the object were initialized only with the
brace-enclosed
list if the types of the compound literal and the object match.
The elements of the compound literal must be constant.
If the object being initialized has array type of unknown size, the size is
determined by the size of the compound literal.

So the question is whether this extension should also allow the case where 
a compound literal is used to initialize a sub-object.

[Bug libstdc++/105540] New: gcc-11-20220506 failure to build on Cygwin due to lack of secure_getenv

[mckelvey at maskull dot com via Gcc-bugs]

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

Bug ID: 105540
   Summary: gcc-11-20220506 failure to build on Cygwin due to lack
of secure_getenv
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mckelvey at maskull dot com
  Target Milestone: ---

Created attachment 52945
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52945=edit
Build.log showing error

make[6]: Entering directory
'/home/McKelvey/gcc-11-20220506/x86_64-pc-cygwin/libstdc++-v3/src/c++11'
make[6]: Nothing to be done for 'all'.
make[6]: Leaving directory
'/home/McKelvey/gcc-11-20220506/x86_64-pc-cygwin/libstdc++-v3/src/c++11'
Making all in c++17
make[6]: Entering directory
'/home/McKelvey/gcc-11-20220506/x86_64-pc-cygwin/libstdc++-v3/src/c++17'
/bin/sh ../../libtool --tag CXX --tag disable-shared   --mode=compile
/home/McKelvey/gcc-11-20220506/host-x86_64-pc-cygwin/gcc/xgcc -shared-libgcc
-B/home/McKelvey/gcc-11-20220506/host-x86_64-pc-cygwin/gcc -nostdinc++
-L/home/McKelvey/gcc-11-20220506/x86_64-pc-cygwin/libstdc++-v3/src
-L/home/McKelvey/gcc-11-20220506/x86_64-pc-cygwin/libstdc++-v3/src/.libs
-L/home/McKelvey/gcc-11-20220506/x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-pc-cygwin/bin/ -B/usr/local/x86_64-pc-cygwin/lib/ -isystem
/usr/local/x86_64-pc-cygwin/include -isystem
/usr/local/x86_64-pc-cygwin/sys-include   -fno-checking
-I/home/McKelvey/gcc-11-20220506/libstdc++-v3/../libgcc
-I/home/McKelvey/gcc-11-20220506/x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin
-I/home/McKelvey/gcc-11-20220506/x86_64-pc-cygwin/libstdc++-v3/include
-I/home/McKelvey/gcc-11-20220506/libstdc++-v3/libsupc++   -std=gnu++17
-nostdinc++ -prefer-pic -D_GLIBCXX_SHARED -fno-implicit-templates  -Wall
-Wextra -Wwrite-strings -Wcast-qual -Wabi=2  -fdiagnostics-show-location=once  
-ffunction-sections -fdata-sections  -frandom-seed=fs_ops.lo 
-fimplicit-templates -g -O2  -c -o fs_ops.lo
../../../.././libstdc++-v3/src/c++17/fs_ops.cc
libtool: compile: 
/home/McKelvey/gcc-11-20220506/host-x86_64-pc-cygwin/gcc/xgcc -shared-libgcc
-B/home/McKelvey/gcc-11-20220506/host-x86_64-pc-cygwin/gcc -nostdinc++
-L/home/McKelvey/gcc-11-20220506/x86_64-pc-cygwin/libstdc++-v3/src
-L/home/McKelvey/gcc-11-20220506/x86_64-pc-cygwin/libstdc++-v3/src/.libs
-L/home/McKelvey/gcc-11-20220506/x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-pc-cygwin/bin/ -B/usr/local/x86_64-pc-cygwin/lib/ -isystem
/usr/local/x86_64-pc-cygwin/include -isystem
/usr/local/x86_64-pc-cygwin/sys-include -fno-checking
-I/home/McKelvey/gcc-11-20220506/libstdc++-v3/../libgcc
-I/home/McKelvey/gcc-11-20220506/x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin
-I/home/McKelvey/gcc-11-20220506/x86_64-pc-cygwin/libstdc++-v3/include
-I/home/McKelvey/gcc-11-20220506/libstdc++-v3/libsupc++ -std=gnu++17
-nostdinc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=fs_ops.lo
-fimplicit-templates -g -O2 -c ../../../.././libstdc++-v3/src/c++17/fs_ops.cc
-o fs_ops.o
In file included from ../../../.././libstdc++-v3/src/c++17/fs_ops.cc:58:
../../../.././libstdc++-v3/src/c++17/../filesystem/ops-common.h: In function
‘const char* std::filesystem::get_temp_directory_from_env(std::error_code&)’:
../../../.././libstdc++-v3/src/c++17/../filesystem/ops-common.h:600:25: error:
‘::secure_getenv’ has not been declared
  600 | auto tmpdir = ::secure_getenv(env);
  | ^
make[6]: *** [Makefile:577: fs_ops.lo] Error 1

Built with gcc-12-20220507

$ uname -r
3.3.4(0.341/5/3)

[Bug fortran/105526] [Coarray] Missing checks for arguments of type TEAM_TYPE

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
   Last reconfirmed||2022-05-09

--- Comment #1 from anlauf at gcc dot gnu.org ---
Patch submitted: https://gcc.gnu.org/pipermail/fortran/2022-May/057842.html

[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?

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

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

--- Comment #3 from Andrew Pinski  ---
Not really, Fre considers the defered init as being uninitialized still and
then does optimization based on that.

[Bug c++/98940] Implement C++23 language features

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

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

Bug 103539 Summary: [C++23] P2324 - Labels at the end of compound statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103539

   What|Removed |Added

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

[Bug c++/103539] [C++23] P2324 - Labels at the end of compound statements

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Implemented in GCC 13.

[Bug c++/103539] [C++23] P2324 - Labels at the end of compound statements

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

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

--- Comment #1 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r13-217-g4b2a6628644b2ce15d877c1e85d14e314965a296
Author: Marek Polacek 
Date:   Sun May 8 17:36:34 2022 -0400

c++: Implement P2324R2, labels at the end of compound-stmts [PR103539]

This patch implements C++23 , which allows
labels at the end of a compound statement.   Its C FE counterpart was
already implemented in r11-4813.

In cp_parser_statement I rely on in_compound to determine whether we're
in a compound-statement, so that the patch doesn't accidentally allow

  void fn(int c) {
if (c)
  label:
  }

Strangely, in_compound was reset after seeing a label (this is tested in
c-c++-common/gomp/pr63326.c), so I've made a modifiable copy specific
for OpenMP #pragma purposes.

PR c++/103539

gcc/cp/ChangeLog:

* parser.cc (cp_parser_statement): Constify the in_compound
parameter.
Create a modifiable copy.  Allow labels at the end of compound
statements.

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/label1.C: New test.
* g++.dg/cpp23/label2.C: New test.

[Bug libstdc++/103853] std::forward_list::merge should check if __list != this

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #14 from Jonathan Wakely  ---
Fixed for 9.5, 10.4, 11.4 and 12.1

[Bug libstdc++/103877] libstdc++ docs give a bad recommendation for printing C++ defines

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|10.4|9.5

[Bug libstdc++/103549] Uninitialized member warning from regex header

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|10.4|9.5

--- Comment #8 from Jonathan Wakely  ---
And 9.5

[Bug fortran/105501] The statement TYPE IS without a space is accepted

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed for gcc-13.  Closing.

Thanks for the report!

[Bug fortran/105501] The statement TYPE IS without a space is accepted

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

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

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

https://gcc.gnu.org/g:8c97f7fd2382aa77f36567207e949447db90a1fb

commit r13-216-g8c97f7fd2382aa77f36567207e949447db90a1fb
Author: Harald Anlauf 
Date:   Sun May 8 22:04:27 2022 +0200

Fortran: check for non-optional spaces between adjacent keywords

In free format, spaces between adjacent keywords are not optional except
when a combination is explicitly listed (e.g. F2018: table 6.2).  The
following combinations thus require separating blanks: CHANGE TEAM,
ERROR STOP, EVENT POST, EVENT WAIT, FAIL IMAGE, FORM TEAM, SELECT RANK,
SYNC ALL, SYNC IMAGES, SYNC MEMORY, SYNC TEAM, TYPE IS.

gcc/fortran/ChangeLog:

PR fortran/105501
* match.cc (gfc_match_if): Adjust patterns used for matching.
(gfc_match_select_rank): Likewise.
* parse.cc (decode_statement): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/105501
* gfortran.dg/pr105501.f90: New test.

[Bug c/105539] -ftrivial-auto-var-init=zero happening too late?

[kees at outflux dot net via Gcc-bugs]

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

--- Comment #2 from Kees Cook  ---
https://godbolt.org/z/99Pdro9Te

[Bug c/105539] -ftrivial-auto-var-init=zero happening too late?

[kees at outflux dot net via Gcc-bugs]

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

--- Comment #1 from Kees Cook  ---
(Also this doesn't warn about y being used uninitialized.)

[Bug c/105539] New: -ftrivial-auto-var-init=zero happening too late?

[kees at outflux dot net via Gcc-bugs]

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

Bug ID: 105539
   Summary: -ftrivial-auto-var-init=zero happening too late?
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kees at outflux dot net
  Target Milestone: ---

It looks like some pass is being run before the initializers are added:

int x (int z) {
int y;
if (z)
y = 10;
return y;
}

under "gcc -ftrivial-auto-var-init=zero -Wuninitialized -O2" does not test "z":

$ gcc -ftrivial-auto-var-init=zero -Wuninitialized -O2 -S x.c -o -
...
movl$10, %eax
ret
...

This should be testing "z", e.g.:

testl   %edi, %edi
movl$10, %eax
cmovel  %edi, %eax
retq

[Bug libgomp/105538] New: [OpenMP] ALLOCA - MALLOC issue with firstprivate

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

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

Bug ID: 105538
   Summary: [OpenMP] ALLOCA - MALLOC issue with firstprivate
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: openmp, wrong-code
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

The following fails with host fallback:

character(len=:), allocatable :: x(:)

x = ["abc", "cde"]

!$omp target firstprivate(x)
  x = ["abcx", "cdel", "hhgj"]
!$omp end target
end

The problem is:

  calculate_firstprivate_requirements (mapnum, hostaddrs, sizes, kinds,
   _align, _size);
  if (tgt_align)
{
  char *tgt = gomp_alloca (tgt_size + tgt_align - 1);
  copy_firstprivate_data (tgt, mapnum, hostaddrs, sizes, kinds,
  tgt_align, tgt_size);
}

firstprivate() now points inside the  alloca  area and the realloc now fails as
it wasn't malloced.


Question: Is this code valid (I think it is). Is so:

Expected: We possibly need some way to tag memory which should be 'malloc'ed
and not alloca'ed – possibly also with a user-specified allocator (or is this
only permitted for 'private'?) And use that with firstprivate instead.

[Bug fortran/91544] When initializing allocatable character array get "Error: size of variable 'A.0' is too large"

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  ---
Reconfirmed with GCC 13. Internally, the following code is generated (for my
example, -fdump-tree-original):

  static character(kind=1) A.0[3][1:D.4246] = {"abcde", "fhji",
"klmno"};

The problem is that D.4246 is a variable and not a constant. I think the proper
solution is to create an array for max length, i.e. 5 in this example with
right padding if too short:

  static character(kind=1) A.0[3][1:5] = {"abcde", "fhji ", "klmno"};

And then in the array use, there is already some code like the following.
However, here, not only the .x (= desired length) but also the actual length
(here: 5) has to be taken into account for the memmove/memset bit, i.e. min(.x,
5). (In the example below, .x, D.4251 and D.4252 are all the same - and match
either the LHS after allocation or RHS of the assignment.)

  .x = i >= -2 ? (integer(kind=8)) (i + 2) : 0;
...
  D.4252 = .x;
  D.4253 = (void *) D.4242 + (sizetype) (((S.1 + D.4249) + D.4243) * x.span);
  D.4254 = (void *) [S.1];
  if (D.4252 > 0)
{
  if (NON_LVALUE_EXPR  < NON_LVALUE_EXPR )
{
  __builtin_memmove (D.4253, D.4254, (unsigned long) NON_LVALUE_EXPR
);
  __builtin_memset (D.4253 + (sizetype) NON_LVALUE_EXPR , 32,
(unsigned long) (NON_LVALUE_EXPR  - NON_LVALUE_EXPR ));

[Bug tree-optimization/105537] New: ICE: cannot update SSA form (error: statement uses released SSA name)

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 105537
   Summary: ICE: cannot update SSA form (error: statement uses
released SSA name)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 13.0.0 20220508 snapshot (g:a1947c92f7cda5f6cf7b8d8a9a44f6dd45352c03) ICEs
when compiling the following testcase w/ -O3 -ffast-math -fsignaling-nans
-fvar-tracking-assignments -fno-move-loop-stores:

int n;

double
ext1 (int);

void
ext2 (double);

int
sum (int v1, int v2)
{
  return v1 + v2;
}

void
bar (void)
{
  ext2 (ext1 (n));
}

__attribute__ ((optimize ("-O3"))) void
foo (int *x)
{
  static int i;

  bar ();
  for (i = 0; i != 2; i = sum (i, 1))
n = *x = 0;
}

% gcc-13.0.0 -O3 -ffast-math -fsignaling-nans -fvar-tracking-assignments
-fno-move-loop-stores -w -c sqnqheby.c
sqnqheby.c: In function 'foo':
sqnqheby.c:22:1: error: statement uses released SSA name
   22 | foo (int *x)
  | ^~~
# DEBUG v1 => _1
The use of _1 should have been replaced
during GIMPLE pass: ldist
sqnqheby.c:22:1: internal compiler error: cannot update SSA form
0xf70cc6 update_ssa(unsigned int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220508/work/gcc-13-20220508/gcc/tree-into-ssa.cc:3349
0x104f1c4 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int,
loop*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220508/work/gcc-13-20220508/gcc/tree-ssa-loop-manip.cc:642
0x104f1c4 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int,
loop*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220508/work/gcc-13-20220508/gcc/tree-ssa-loop-manip.cc:629
0xf7d869 loop_distribution::execute(function*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220508/work/gcc-13-20220508/gcc/tree-loop-distribution.cc:3865
0xf7e097 execute
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220508/work/gcc-13-20220508/gcc/tree-loop-distribution.cc:3912

[Bug c++/105529] [13 Regression] cxx_eval_store_expression on arm because of ctor returning this since r13-160-g967cdbe6629653

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Therefore, a potential fix would be:

--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -5916,8 +5916,9 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, tree
t,

   gcc_checking_assert (!*valp || (same_type_ignoring_top_level_qualifiers_p
  (TREE_TYPE (*valp), type)));
-  if (empty_base || !(same_type_ignoring_top_level_qualifiers_p
- (TREE_TYPE (init), type)))
+  if (empty_base || (CLASS_TYPE_P (TREE_TYPE (init))
+&& !(same_type_ignoring_top_level_qualifiers_p
+ (TREE_TYPE (init), type
 {
   /* For initialization of an empty base, the original target will be
*(base*)this, evaluation of which resolves to the object


This code expects code like

  D.2181 = {}

where the type of the LHS is the derived type and the type of the RHS is the
base type.

[Bug libstdc++/101870] std::lerp is missing Arithmetic overloads

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|10.4|9.5

--- Comment #8 from Jonathan Wakely  ---
Fixed for 9.5 now too.

[Bug libstdc++/103630] [9 Regression] std::make_exception_ptr(t) is ill-formed

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
And 9.5 too.

[Bug c/105536] [OpenMP] Bogus "expected ‘concurrent’ before ‘reproducible’"

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

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

--- Comment #1 from Tobias Burnus  ---
The issue occurred at real-world code (sollve_vv testcase before it was fixed).

The issue is because of:
   if (c_parser_next_token_is (parser, CPP_NAME)
  && c_parser_peek_2nd_token (parser)->type == CPP_COLON)
/* ... Parse reproducible/unconstrained ... */

  p = IDENTIFIER_POINTER (c_parser_peek_token (parser)->value);
  if (strcmp (p, "concurrent") != 0)
{
  c_parser_error (parser, "expected %");
  goto out_err;
}

And the error message is then 'expected concurrent'
   + auto-added "before "

That message is fine – except for this specific case it is somewhat misleading.

→ The question is whether we want to handle this in a different way
  (yield better error message, how?)
  OR – whether that's just too specific and close this PR as WONTFIX?

[Bug libstdc++/103650] [9 Regression] libstdc++ headers defined LT_OBJDIR and STDC_HEADERS

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for 9.5, 10.4, 11.3 and 12.1

[Bug libstdc++/102354] std::advance overloaded for path::iterator will never be called

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed for 9.5 and on later branches too.

[Bug libstdc++/100153] Undefined behavior in stl_bvector.h

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Fixed for 9.5, 10.4, 11.3 and 12.1

[Bug libstdc++/93602] [9/10 Regression] Missing reference to libiconv in 9.x libstdc++

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

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

--- Comment #24 from Jonathan Wakely  ---
Fixed for 10.4 too.

[Bug libstdc++/105502] [9/10/11 Regression] std::normal_distribution deserialization issue

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Fixed for 9.5, 10.4, 11.4 and 12.2

[Bug libstdc++/105502] [9/10/11 Regression] std::normal_distribution deserialization issue

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

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

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

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

commit r9-10066-gb005000525ab0a5116d21217c41fb1da5bd03796
Author: Jonathan Wakely 
Date:   Fri May 6 21:19:17 2022 +0100

libstdc++: Fix deserialization for std::normal_distribution [PR105502]

This fixes a regression in std::normal_distribution deserialization that
caused the object to be left unchanged if the __state_avail value read
from the stream was false.

libstdc++-v3/ChangeLog:

PR libstdc++/105502
* include/bits/random.tcc
(operator>>(basic_istream&, normal_distribution&)):
Update state when __state_avail is false.
*
testsuite/26_numerics/random/normal_distribution/operators/serialize.cc:
Check that deserialized object equals serialized one.

(cherry picked from commit 909ef4e2727ddc50a32d6ad379a1f1ccc1043c6a)

[Bug c/105536] New: [OpenMP] Bogus "expected ‘concurrent’ before ‘reproducible’"

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

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

Bug ID: 105536
   Summary: [OpenMP] Bogus "expected ‘concurrent’ before
‘reproducible’"
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: diagnostic, openmp
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

I think the message shown by C/C++ for the following is bogus:

repro.c:3:23: error: expected ‘concurrent’ before ‘reproducible’
3 | #pragma omp for order(reproducible)
  |   ^~~~

The standard requires 'order(reproducible:concurrent)' – Thus, I expect *after*
and not *before* in the error message.
Cf. https://www.openmp.org/spec-html/5.1/openmpsu47.html#x72-720002.11.3

void f(void)
{
#pragma omp for order(reproducible)
 for (int i=0; i < 1; i++)
   ;
}


Side remark: Fortran is fine as it gives the following:

1 | !$omp do order(reproducible)
  |1
Error: Expected ORDER(CONCURRENT) at (1) with optional ‘reproducible’ or
‘unconstrained’ modifier

[Bug libstdc++/103630] [9 Regression] std::make_exception_ptr(t) is ill-formed

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

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

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

https://gcc.gnu.org/g:93a621991615e943704ed1a957d934736bf8a3d3

commit r9-10063-g93a621991615e943704ed1a957d934736bf8a3d3
Author: Jonathan Wakely 
Date:   Thu Dec 9 13:54:39 2021 +

libstdc++: Fix std::exception_ptr regressions [PR103630]

This restores support for std::make_exception_ptr and for using
std::exception_ptr in C++98.

Because the new non-throwing implementation needs to use std::decay to
handle references the original throwing implementation is used for
C++98.

We also need to change the typeid expression so it doesn't yield the
dynamic type when the function parameter is a reference to a polymorphic
type. Otherwise the new exception object could be caught by any handler
matching the dynamic type, even though the actual exception object is
only a copy of the base class, sliced to the static type.

libstdc++-v3/ChangeLog:

PR libstdc++/103630
* libsupc++/exception_ptr.h (make_exception_ptr): Decay the
template parameter. Use typeid of the static type.
* testsuite/18_support/exception_ptr/103630.cc: New test.

(cherry picked from commit a1ca039fc0fe934ef36c25d8284e6e116bcaffa7)

[Bug libstdc++/93151] system_error header fails to compile with -D_XOPEN_SOURCE=600

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

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

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

https://gcc.gnu.org/g:740e1ae17770d8e4829714c689f5471d235184b7

commit r9-10062-g740e1ae17770d8e4829714c689f5471d235184b7
Author: Jonathan Wakely 
Date:   Thu Dec 17 13:27:04 2020 +

libstdc++: Test errno macros directly for all targets [PR 93151]

This applies the same changes to the djgpp and mingw versions of
error_constants.h as r11-6137 did for the generic version.

All of these constants are defined as macros by  on these
targets, so we can just test the macro directly instead of checking for
it at configure time.

libstdc++-v3/ChangeLog:

PR libstdc++/93151
* config/os/djgpp/error_constants.h: Test POSIX errno macros
directly, instead of corresponding _GLIBCXX_HAVE_EXXX macros.
* config/os/mingw32-w64/error_constants.h: Likewise.
* config/os/mingw32/error_constants.h: Likewise.

(cherry picked from commit 217d5beaff9987a9845155fc796322b5f8bb876d)

[Bug libstdc++/93151] system_error header fails to compile with -D_XOPEN_SOURCE=600

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

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

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

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

commit r9-10061-g4b5211c85aed64c7f6034dad8f57e03c0302c5ec
Author: Jonathan Wakely 
Date:   Tue Dec 15 20:28:11 2020 +

libstdc++: Test errno macros directly, not via autoconf [PR 93151]

This fixes a bug caused by a mismatch between the macros defined by
 when GCC is built and the macros defined by  when
users include . If the user code is compiled with
_XOPEN_SOURCE defined to 500 or 600, Darwin suppresses the
ENOTRECOVERABLE and EOWNERDEAD macros, which are not defined by SUSv3
(aka POSIX.1-2001).

Since POSIX requires the errno macros to be macros (and not variables or
enumerators) we can just test for them directly using the preprocessor.
That means that  will match what is actually defined when
it's included, not what was defined when GCC was built. With that change
there is no need for the GLIBCXX_CHECK_SYSTEM_ERROR configure checks and
they can be removed.

libstdc++-v3/ChangeLog:

PR libstdc++/93151
* acinclude.m4 (GLIBCXX_CHECK_SYSTEM_ERROR): Remove.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac (GLIBCXX_CHECK_SYSTEM_ERROR): Do not use.
* config/os/generic/error_constants.h: Test POSIX errno macros
directly, instead of corresponding _GLIBCXX_HAVE_EXXX macros.
* testsuite/19_diagnostics/headers/system_error/errc_std_c++0x.cc:
Likewise.
* testsuite/19_diagnostics/headers/system_error/93151.cc: New
test.

(cherry picked from commit a2c2eec183acf25c9b214fa0827718e4d2fdfc93)

[Bug libstdc++/101870] std::lerp is missing Arithmetic overloads

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

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

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

https://gcc.gnu.org/g:5ed333b0762d847ffb0096ba97e924188c766d69

commit r9-10059-g5ed333b0762d847ffb0096ba97e924188c766d69
Author: Jonathan Wakely 
Date:   Thu Aug 12 17:35:25 2021 +0100

libstdc++: Add additional overload of std::lerp [PR101870]

The [cmath.syn] p1 wording about additional overloads sufficient to
handle any arithmetic types also applies to std::lerp. This adds a new
overload of std::lerp that does the required promotions to support
arguments of arbitrary arithmetic types.

A new __promoted_t alias template is added, which the C++17 function
templates std::hypot and std::lerp can use to avoid instantiating the
__promote_3 class template.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/101870
* include/c_global/cmath (hypot): Use __promoted_t.
(lerp): Add new overload accepting any arithmetic types.
* include/ext/type_traits.h (__promoted_t): New alias template.
* testsuite/26_numerics/lerp.cc: Moved to...
* testsuite/26_numerics/lerp/1.cc: ...here.
* testsuite/26_numerics/lerp/constexpr.cc: New test.
* testsuite/26_numerics/lerp/version.cc: New test.

(cherry picked from commit 9017326e19fe278d5f62898cca4682b17f8e8e07)

[Bug libstdc++/100153] Undefined behavior in stl_bvector.h

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

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

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

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

commit r9-10058-gb4a170bf3a2b0397a5d73f7cac24f6df4298569e
Author: Jonathan Wakely 
Date:   Tue Apr 20 16:16:13 2021 +0100

libstdc++: Do not allocate a zero-size vector [PR 100153]

The vector::shrink_to_fit() implementation will allocate new
storage even if the vector is empty. That then leads to the
end-of-storage pointer being non-null and equal to the _M_start._M_p
pointer, which means that _M_end_addr() has undefined behaviour.

The fix is to stop doing a useless zero-sized allocation in
shrink_to_fit(), so that _M_start._M_p and _M_end_of_storage are both
null after an empty vector shrinks.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/100153
* include/bits/vector.tcc (vector::_M_shrink_to_fit()):
When size() is zero just deallocate and reset.

(cherry picked from commit 681707ec28d56494fa61a80c62500724d55f8586)

[Bug libstdc++/103853] std::forward_list::merge should check if __list != this

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

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

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

https://gcc.gnu.org/g:79b7b824346d3cb3101d1896f81ed16392b7471c

commit r9-10056-g79b7b824346d3cb3101d1896f81ed16392b7471c
Author: Pavel I. Kryukov 
Date:   Thu Jan 6 12:32:36 2022 +

libstdc++: Add self-merge check to std::forward_list::merge [PR103853]

This implements the proposed resolution of LWG 3088, so that x.merge(x)
is a no-op, consistent with std::list::merge.

Signed-off-by: Pavel I. Kryukov 

Co-authored-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/103853
* include/bits/forward_list.tcc (forward_list::merge): Check for
self-merge.
* testsuite/23_containers/forward_list/operations/merge.cc: New
test.

(cherry picked from commit 52ebc2be0990d6d3a46bb716164f9cef6f661021)

[Bug libstdc++/103549] Uninitialized member warning from regex header

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

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

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

https://gcc.gnu.org/g:756d1581d11c583d9cbfc2e0b7ce1a095845085e

commit r9-10055-g756d1581d11c583d9cbfc2e0b7ce1a095845085e
Author: Jonathan Wakely 
Date:   Sat Dec 4 11:38:25 2021 +

libstdc++: Initialize member in std::match_results [PR103549]

This fixes a -Wuninitialized warning for std::cmatch m1, m2; m1=m2;

Also name the template parameters in the forward declaration, to get rid
of the  noise in diagnostics.

libstdc++-v3/ChangeLog:

PR libstdc++/103549
* include/bits/regex.h (match_results): Give names to template
parameters in first declaration.
(match_results::_M_begin): Add default member-initializer.

(cherry picked from commit 87710ec7b213245ecb194b778e97ae3a6790394f)

[Bug libstdc++/103877] libstdc++ docs give a bad recommendation for printing C++ defines

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

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

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

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

commit r9-10054-gdae73190d42a8074cc393c759338942d0de8b2bd
Author: Jonathan Wakely 
Date:   Tue Jan 4 15:54:16 2022 +

libstdc++: Fix example preprocessor command in FAQ [PR103877]

libstdc++-v3/ChangeLog:

PR libstdc++/103877
* doc/xml/faq.xml: Add '-x c++' to preprocessor command.
* doc/html/faq.html: Regenerate.

(cherry picked from commit cebe875f6f44b905a0d56a2007b5a638a33a893c)

[Bug libstdc++/103650] [9 Regression] libstdc++ headers defined LT_OBJDIR and STDC_HEADERS

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

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

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

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

commit r9-10053-gde3549eb7bba1af6894b6ad781b6943b16883f2b
Author: Jonathan Wakely 
Date:   Mon Jan 17 11:24:35 2022 +

libstdc++: Rename non-reserved macros in config header [PR103650]

libstdc++-v3/ChangeLog:

PR libstdc++/103650
* include/Makefile.am: Rename LT_OBJDIR and STDC_HEADERS.
* include/Makefile.in: Regenerate.
* testsuite/17_intro/headers/c++1998/103650.cc: New test.

(cherry picked from commit fa092570fbaf3bb4202e518eb8beba146c464d9f)

[Bug libstdc++/102048] __gnu_cxx::rope.erase(size_t __p) implementation seems to be wrong

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

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

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

https://gcc.gnu.org/g:44afdb5f23ed752fb7b3ac095831ba65901c45f2

commit r9-10050-g44afdb5f23ed752fb7b3ac095831ba65901c45f2
Author: Jonathan Wakely 
Date:   Thu Apr 21 14:12:25 2022 +0100

libstdc++: Deprecate __gnu_cxx::rope::erase(size_type) [PR102048]

This function is broken, and has been removed for GCC 11 and 12.
Deprecate it for GCC 10 and GCC 9.

libstdc++-v3/ChangeLog:

PR libstdc++/102048
* include/ext/rope (rope::erase(size_type)): Deprecate broken
function.

(cherry picked from commit 05ad54a8e67b31126351b9f15e1e42ac67650d6d)

[Bug libstdc++/93602] [9/10 Regression] Missing reference to libiconv in 9.x libstdc++

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

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

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

https://gcc.gnu.org/g:8da8ed881e7cdb2d4b070d685d6d3fe8d31529c2

commit r10-10601-g8da8ed881e7cdb2d4b070d685d6d3fe8d31529c2
Author: Jonathan Wakely 
Date:   Wed Apr 13 14:09:33 2022 +0100

libstdc++: Use LTLIBICONV when linking libstdc++.so [PR93602]

This fixes missing libiconv symbols when libstdc++ is built on a system
that has libiconv installed. If the libiconv headers are found then
libstdc++ depends on libiconv_open etc instead of libc's iconv_open. But
without this fix libstdc++ is not linked to the libiconv library that
provides the definitions of those symbols.

As discussed in PR 93602 this changed means that libstdc++.so.6 might
have an rpath pointing to the location of the libiconv.so library. If
that is not desired, then GCC must be configured to link to a static
libiconv.a instead, using either --with-libiconv-type=static or an
in-tree build of libiconv.

libstdc++-v3/ChangeLog:

PR libstdc++/93602
* doc/xml/manual/prerequisites.xml: Document libiconv
workarounds.
* doc/html/manual/setup.html: Regenerate.
* src/Makefile.am (CXXLINK): Add $(LTLIBICONV).
* src/Makefile.in: Regenerate.

(cherry picked from commit c644b7df11afc818d6308c3776813e50e4ebe551)

[Bug libstdc++/105502] [9/10/11 Regression] std::normal_distribution deserialization issue

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

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

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

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

commit r10-10600-gf3a0d3a778643bcb82bdf41a67a5ddc1f95c6f53
Author: Jonathan Wakely 
Date:   Fri May 6 21:19:17 2022 +0100

libstdc++: Fix deserialization for std::normal_distribution [PR105502]

This fixes a regression in std::normal_distribution deserialization that
caused the object to be left unchanged if the __state_avail value read
from the stream was false.

libstdc++-v3/ChangeLog:

PR libstdc++/105502
* include/bits/random.tcc
(operator>>(basic_istream&, normal_distribution&)):
Update state when __state_avail is false.
*
testsuite/26_numerics/random/normal_distribution/operators/serialize.cc:
Check that deserialized object equals serialized one.

(cherry picked from commit 909ef4e2727ddc50a32d6ad379a1f1ccc1043c6a)

[Bug c++/105529] [13 Regression] cxx_eval_store_expression on arm because of ctor returning this since r13-160-g967cdbe6629653

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
We're in cxx_eval_store_expression, evaluating  = this, this is while
evaluating a CALL_EXPR allocator::~allocator ().  We're on ARM, so
cdtors return this.

init is evaluated to  [allocator *], object is  [void *].  Their
types aren't the same so we go to

  if (empty_base || !(same_type_ignoring_top_level_qualifiers_p
  (TREE_TYPE (init), type)))
{
  /* For initialization of an empty base, the original target will be
   *(base*)this, evaluation of which resolves to the object
   argument, which has the derived type rather than the base type.  In
   this situation, just evaluate the initializer and return, since
   there's no actual data to store, and we didn't build a CONSTRUCTOR.  */
  empty_base = true;
  gcc_assert (is_empty_class (TREE_TYPE (init)));

and is_empty_class will always say false for a pointer type -> ICE.  I don't
think we should have gotten into this branch.

[Bug libstdc++/91456] std::function and std::is_invocable_r do not understand guaranteed elision

[hewillk at gmail dot com via Gcc-bugs]

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

康桓瑋  changed:

   What|Removed |Added

 CC||hewillk at gmail dot com

--- Comment #6 from 康桓瑋  ---
(In reply to Jonathan Wakely from comment #5)
> Fixed for 9.3 too.

Should is_nothrow_invocable_r be fixed too?

[Bug c++/105256] [9/10 Regression] ICE compiling firefox-99

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

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

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

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

commit r13-214-gf08ea45bad43024a1458dca6e37c5c1bcc02e234
Author: Jakub Jelinek 
Date:   Mon May 9 18:21:08 2022 +0200

testsuite: Remove superfluous semicolon [PR105256]

2022-05-09  Jakub Jelinek  

PR c++/105256
* g++.dg/cpp0x/pr105256.C: Remove superfluous semicolon.

[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming

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

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

--- Comment #21 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> This will use the last matching file for the libstdc++* glob. That works
> fine for ELF targets where the matching names are:
> 
> libstdc++.a
> libstdc++.so
> libstdc++.so.6
> libstdc++.so.6.0.29
> 
> But not for MacOS with:
> 
> libstdc++.6.dylib
> libstdc++.a
> 
> Or mingw with:
> 
> libstdc++-6.dll
> libstdc++.dll.a
> 
> We need a better way to find the dynamic library, whether that's the
> so.6.0.29 or the .dylib or the .dll, that doesn't depend on the shell's
> alphabetic sort for the pattern. As the comment says, libtool doesn't give
> us that info, but we can still do better.

Hmm, this isn't fixed for mingw because the libtool libstdc++.la file has:

# The name that we can dlopen(3).
dlname='libstdc++-6.dll'

# Names of this library.
library_names='libstdc++.dll.a'

# The name of the static archive.
old_library='libstdc++.a'


This means we still choose libstdc++.dll.a-gdb.py as the hook name, which is
still wrong. Yay for libtool.

[Bug c++/96068] Extra semicolon outside of a function should be allowed after c++11?

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
I wonder if we shouldn't have a style warning for this though, if the empty
statement's ; is immediately after } in the source, tell user it is
unnecessary,
while not warning if there is some comment or newline or whitespace etc. in
between.
Ran into this while backporting PR105256 to gcc-10 branch which doesn't have
this fix and the testcase contains such a useless semicolon:
void S::Prefs::Load() {
  *this = {};
};

[Bug target/101891] Adjust -fzero-call-used-regs to always use XOR

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

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

--- Comment #3 from qinzhao at gcc dot gnu.org ---
fixed in gcc13.

[Bug target/101891] Adjust -fzero-call-used-regs to always use XOR

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Qing Zhao :

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

commit r13-213-g0b86943aca51175968e40bbb6f2662dfe3fbfe59
Author: Qing Zhao 
Date:   Mon May 9 15:34:34 2022 +

i386: Adjust -fzero-call-used-regs to always use XOR [PR101891]

Currently on i386, -fzero-call-used-regs uses a pattern of:

XOR regA,regA
MOV regA,regB
MOV regA,regC
...
RET

However, this introduces both a register ordering dependency (e.g. the CPU
cannot clear regB without clearing regA first), and while greatly reduces
available ROP gadgets, it does technically leave a set of "MOV" ROP gadgets
at the end of functions (e.g. "MOV regA,regC; RET").

This patch will switch to always use XOR on i386:

XOR regA,regA
XOR regB,regB
XOR regC,regC
...
RET

gcc/ChangeLog:

PR target/101891
* config/i386/i386.cc (zero_call_used_regno_mode): use V2SImode
as a generic MMX mode instead of V4HImode.
(zero_all_mm_registers): Use SET to zero instead of MOV for
zeroing scratch registers.
(ix86_zero_call_used_regs): Likewise.

gcc/testsuite/ChangeLog:

* gcc.target/i386/zero-scratch-regs-1.c: Add -fno-stack-protector
-fno-PIC.
* gcc.target/i386/zero-scratch-regs-10.c: Adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-13.c: Add -msse.
* gcc.target/i386/zero-scratch-regs-14.c: Adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-15.c: Add -fno-stack-protector
-fno-PIC.
* gcc.target/i386/zero-scratch-regs-16.c: Likewise.
* gcc.target/i386/zero-scratch-regs-17.c: Likewise.
* gcc.target/i386/zero-scratch-regs-18.c: Add -fno-stack-protector
-fno-PIC, adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-19.c: Add -fno-stack-protector
-fno-PIC.
* gcc.target/i386/zero-scratch-regs-2.c: Adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-20.c: Add -msse.
* gcc.target/i386/zero-scratch-regs-21.c: Add -fno-stack-protector
-fno-PIC, Adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-22.c: Adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-23.c: Likewise.
* gcc.target/i386/zero-scratch-regs-26.c: Likewise.
* gcc.target/i386/zero-scratch-regs-27.c: Likewise.
* gcc.target/i386/zero-scratch-regs-28.c: Likewise.
* gcc.target/i386/zero-scratch-regs-3.c: Add -fno-stack-protector.
* gcc.target/i386/zero-scratch-regs-31.c: Adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-4.c: Add -fno-stack-protector
-fno-PIC.
* gcc.target/i386/zero-scratch-regs-5.c: Adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-6.c: Add -fno-stack-protector.
* gcc.target/i386/zero-scratch-regs-7.c: Likewise.
* gcc.target/i386/zero-scratch-regs-8.c: Adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-9.c: Add -fno-stack-protector.

[Bug gcov-profile/105535] GCOV analysis on 16-bit target systems impossible

[peter-helfert--- via Gcc-bugs]

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

--- Comment #2 from Hans-Peter Helfert  ---
Hello Martin,
Thanks for your quick response to my bug report. 
I'm not familiar with the customs on the gcc-patches mailing list. 
Would be nice if you  might put the patch on the gcc-patches mailing list 
on my behalf.

Thank you very much!

Hans-Peter



-Ursprüngliche Nachricht-
Von: marxin at gcc dot gnu.org  
Gesendet: Montag, 9. Mai 2022 16:20
An: peter-helf...@t-online.de
Betreff: [Bug gcov-profile/105535] GCOV analysis on 16-bit target systems
impossible

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-05-09
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Thank you very much for the analysis!

Do you want to send the patch to gcc-patches mailing list or should I do that
on your behalf?

[Bug libstdc++/105502] [9/10/11 Regression] std::normal_distribution deserialization issue

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

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

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

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

commit r11-9970-geb049ef0f4651786aa49110189487e7f8bf343a6
Author: Jonathan Wakely 
Date:   Fri May 6 21:19:17 2022 +0100

libstdc++: Fix deserialization for std::normal_distribution [PR105502]

This fixes a regression in std::normal_distribution deserialization that
caused the object to be left unchanged if the __state_avail value read
from the stream was false.

libstdc++-v3/ChangeLog:

PR libstdc++/105502
* include/bits/random.tcc
(operator>>(basic_istream&, normal_distribution&)):
Update state when __state_avail is false.
*
testsuite/26_numerics/random/normal_distribution/operators/serialize.cc:
Check that deserialized object equals serialized one.

(cherry picked from commit 909ef4e2727ddc50a32d6ad379a1f1ccc1043c6a)

[Bug gcov-profile/105535] GCOV analysis on 16-bit target systems impossible

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug gcov-profile/105535] GCOV analysis on 16-bit target systems impossible

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-05-09
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Thank you very much for the analysis!

Do you want to send the patch to gcc-patches mailing list or should I do that
on your behalf?

[Bug c++/105491] [10/11/12/13 Regression] Usage of __constinit with -std=c++11 does is rejected

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

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

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

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

commit r13-211-g0c7bce0ac184c057bacad9c8e615ce82923835fd
Author: Patrick Palka 
Date:   Mon May 9 09:53:27 2022 -0400

c++: constexpr init of union sub-aggr w/ base [PR105491]

Here ever since r10-7313-gb599bf9d6d1e18, reduced_constant_expression_p
in C++11/14 is rejecting the marked sub-aggregate initializer (of type S)

  W w = {.D.2445={.s={.D.2387={.m=0}, .b=0}}};
 ^
ultimately because said initializer has CONSTRUCTOR_NO_CLEARING set,
hence the function must verify that all fields of S are initialized.
And before C++17 it doesn't expect to see base class fields (since
next_initializable_field skips over them), so the presence thereof
causes r_c_e_p to return false.

The reason r10-7313-gb599bf9d6d1e18 causes this is because in that
commit we began using CONSTRUCTOR_NO_CLEARING to precisely track whether
we're in middle of activating a union member.  This ends up affecting
clear_no_implicit_zero, which recurses into sub-aggregate initializers
only if the outer initializer has CONSTRUCTOR_NO_CLEARING set.  After
that commit, the outer union initializer above no longer has the flag
set at this point and so clear_no_implicit_zero no longer recurses into
the marked inner initializer.

But arguably r_c_e_p should be able to accept the marked initializer
regardless of whether CONSTRUCTOR_NO_CLEARING is set.  The primary bug
therefore seems to be that r_c_e_p relies on next_initializable_field
which skips over base class fields in C++11/14.  To fix this, this patch
introduces a new helper function next_subobject_field which is like
next_initializable_field except that it never skips base class fields,
and makes r_c_e_p use it.  This patch then renames next_initializable_field
to next_aggregate_field (and makes it skip over vptr fields again).

PR c++/105491

gcc/cp/ChangeLog:

* call.cc (field_in_pset): Adjust after next_initializable_field
renaming.
(build_aggr_conv): Likewise.
(convert_like_internal): Likewise.
(type_has_extended_temps): Likewise.
* class.cc (default_init_uninitialized_part): Likewise.
(finish_struct): Likewise.
* constexpr.cc (cx_check_missing_mem_inits): Likewise.
(reduced_constant_expression_p): Use next_subobject_field
instead.
* cp-gimplify.cc (get_source_location_impl_type): Adjust after
next_initializable_field renaming.
(fold_builtin_source_location): Likewise.
* cp-tree.h (next_initializable_field): Rename to ...
(next_aggregate_field): ... this.
(next_subobject_field): Declare.
* decl.cc (next_aggregate_field): Renamed from ...
(next_initializable_field): ... this.  Skip over vptr fields
again.
(next_subobject_field): Define.
(reshape_init_class): Adjust after next_initializable_field
renaming.
* init.cc (build_value_init_noctor): Likewise.
(emit_mem_initializers): Likewise.
* lambda.cc (build_capture_proxy): Likewise.
* method.cc (build_comparison_op): Likewise.
* pt.cc (maybe_aggr_guide): Likewise.
* tree.cc (structural_type_p): Likewise.
* typeck2.cc (split_nonconstant_init_1): Likewise.
(digest_init_r): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-union7.C: New test.
* g++.dg/cpp0x/constexpr-union7a.C: New test.
* g++.dg/cpp2a/constinit17.C: New test.

[Bug c++/105534] -Wmaybe-uninitialized cases shouldn't suppress -Wuninitialized warnings

[redbeard0531 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Mathias Stearn  ---
(In reply to Richard Biener from comment #2)
> Note there's
> 
>   _2 = value_1(D) * x_2;
> 
> where _2 might be effectively uninitialized iff x_2 is not zero.  When x_2
> is zero then _2 has a well-defined value.

Not according to the C++ standard. http://eel.is/c++draft/basic.indet seems
pretty clear that unless x_2 is std::byte (which doesn't support
multiplication) or an "unsigned ordinary character type", then that is UB. 

FWIW I still think I'd expect the warning on "unsigned char x, y; y = x * 0;",
but I would definitiely expect the warning for int.

[Bug c++/105534] -Wmaybe-uninitialized cases shouldn't suppress -Wuninitialized warnings

[redbeard0531 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Mathias Stearn  ---
One slightly confusing aspect is that the wording of the flag implies that the
variable may or may not be uninitialzied (because in -Wmaybe-uninitialized
maybe binds directly to uninitialized), while phrasing of the warning message
is about the usage being conditional: "may be used uninitialized". And of
course the documentation (at least the man page) uses a different phrasing:

> For an object with automatic or allocated storage duration, if there exists a 
> path from the function entry to a use of the object that is initialized, but 
> there exist some other paths for which the object is not initialized, the 
> compiler emits a warning if it cannot prove the uninitialized paths are not 
> executed at run time.

For both the initial example with count, and your example with count2, I'd say
that the "there exists a path from the function entry to a use of the object
that is initialized" bit is clearly not satisfied, so if we assume the
documentation is correct, then those cases both lack a "maybe" and the
variables are clearly uninitialized.

This would also match my intuition for -Winitialized which is that it
definitively errors if all paths from declaration to any usage result in the
variable being uninitialized.

PS - This test case is a reduced example from an actual bug that luckily was
found by coverity before release: https://jira.mongodb.org/browse/SERVER-66306.
I dug in to make a repro because I was expecting that we would have gotten a
compiler error on that code before it was even committed. I'm also exploring
whether we can stop passing -Wno-maybe-uninitialized, but it looks like we
still get false positives in third-party headers, so it doesn't seem likely.

[Bug target/105513] [9/10/11/12/13 Regression] Unnecessary SSE spill since r9-5748-g1d4b4f4979171ef0

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
Just note #c4 in pr105504 also solve this issue.

>Another possible solution is add a little bit dislike for "m" alternative(like 
>?m) to avoid potential spill.

[Bug target/105354] __builtin_shuffle for alignr generates suboptimal code unless SSSE3 is enabled

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Hongtao.liu  ---
Fixed in GCC13.

[Bug target/105354] __builtin_shuffle for alignr generates suboptimal code unless SSSE3 is enabled

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r13-210-gfcda0efccad41eba9134c1bd9d024a93d93fb82f
Author: liuhongt 
Date:   Wed Apr 27 16:24:44 2022 +0800

Implement permutation with pslldq + psrldq + por when pshufb is not
available.

pand/pandn may be used to clear upper/lower bits of the operands, in
that case there will be 4-5 instructions for permutation, and it's
still better than scalar codes.

gcc/ChangeLog:

PR target/105354
* config/i386/i386-expand.cc
(expand_vec_perm_pslldq_psrldq_por): New function.
(ix86_expand_vec_perm_const_1): Try
expand_vec_perm_pslldq_psrldq_por for both 3-instruction and
4/5-instruction sequence.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr105354-1.c: New test.
* gcc.target/i386/pr105354-2.c: New test.

[Bug c++/105534] -Wmaybe-uninitialized cases shouldn't suppress -Wuninitialized warnings

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

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

--- Comment #2 from Richard Biener  ---
Note there's

  _2 = value_1(D) * x_2;

where _2 might be effectively uninitialized iff x_2 is not zero.  When x_2
is zero then _2 has a well-defined value.  So to start thinking about this
I'd do a RPO walk recording a lattice of { UNDEF, MAY_UNDEF, DEF } where
the above would be "MAY_UNDEF".  PHIs would then simply merge.

That would be enough to better distinguish may from must in case the
must diagnostic is OK for the two different variables being returned.
Otherwise that needs to be taken into account as well, maybe by tracking
which variables a value is from.  Consider

void test (int x)
{
   int value1, value2;
   return (value1 * x) + value2;
}

where we maybe use value1 uninitialized and definitely value2.

Note this all leaves open which point to diagnose - the expression closest
to the (possibly conditional and possible multiple) computations with
value1 and value2 or the expression where the first (or last?) unconditional
use appears in?

[Bug gcov-profile/105535] New: GCOV analysis on 16-bit target systems impossible

[peter-helfert--- via Gcc-bugs]

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

Bug ID: 105535
   Summary: GCOV analysis on 16-bit target systems impossible
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter-helf...@t-online.de
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 52944
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52944=edit
Proposed Patch file for libgcc/libgcov.h

Refers to 

GCC versions:

9.3.1 (oldest version I tested)

up to current release

12.1.0

GCOV analysis on 16-bit target systems impossible.

Length divergence of struct “gcov_info” member “n_functions”.

Dear GCC team,

Currently I am using GCC and its libgcov for on-target code coverage analysis
on a 16-bit target system (TI MSP-430). Unfortunately, during my GCOV test runs
I noticed an issue which breaks  code coverage analysis on 16-bit (and possibly
other) systems when using libgcov to assemble and write coverage information
directly on the target.

The issue is caused by a length divergence between the struct member
“n_functions” in the struct “gcov_info” (as declared in “libgcov.h”) and
statically allocated memory in generated object files.  The member
“n_functions” is declared as type “unsigned” in libgcov.h. The declared size
thus depends on the target system. On 32-bit systems, the “n_functions” member
declaration is 32 bits wide. However, on a 16-bit system, the size of the
“n_functions” element usually is reduced to 16 bits (sizeof(unsigned) == 2). 

This variable length, which depends on the compilation target, is not taken
into account when constructing the GCOV information stored as constant data in
the object file, generated at compile time. This information is generated and
included for every object file instrumented for GCOV analysis.  During
compilation, GCC generates an instance of the “gcov_info” struct in the
appropriate linker input section, where its member “n_functions” has a size of
(at least) 32 bits, irrespective of the compilation target. This size is not
compatible with the size declared in struct “gcov_info” on my 16-bit target, as
declared in the libgcov.h C-headers.

In gcc, during compilation of a source code file, the “n_functions” member is
generated by invoking “get_gcov_unsigned_t()” in function
“coverage_obj_init()”. The minimum size of an element generated by
get_gcov_usigned_t() is there hard-coded to 32 bits.

The size divergence of the “gcov_info” struct member “n_functions” causes a
shift of the subsequent struct member “functions" (pointer) by 2 bytes. This in
turn leads to a malfunction as soon as the pointer is accessed at runtime on
the 16-bit target. The issue generally prevents the target software from
collecting and outputting GCOV information on 16-bit systems and therefore
seems to be a quite severe problem, especially as it usually causes
unpredictable malfunction on software instrumented for GCOV analysis.

I wonder why that problem has not been reported before. Possibly, code coverage
analysis on 16-bit targets, using libgcov on target, is still not very common
these days.

Suggested solution:

In GCC source file “libgcov.h”:
In declaration of struct “gcov_info”:

Change: 

“unsigned n_functions” 

to 

“gcov_unsigned_t n_functions”

The gcov_unsigned_t is declared:

 typedef unsgined gcov_unsigned_t __attribute__ ((mode (SI)))

which ensures a 32-bit size for this type.

Other declarations in the context of libgcov and coverage, where the same
problem would otherwise appear, have been solved in the same fashion as my
proposed fix.

A proposed patch is attached to this bug report.

Thank you for considering my report.

Best regards,

Hans-Peter Helfert

[Bug c++/105534] -Wmaybe-uninitialized cases shouldn't suppress -Wuninitialized warnings

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |12.1.0
   Last reconfirmed||2022-05-09
 Ever confirmed|0   |1
   Keywords||diagnostic
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed.  I think we are not considering that

  # count_1 = PHI 

is actually the same variable plus that count_4 can be considered an
uninitialized use even though it is (conditional)

  count_4 = count_3(D) + 1;

instead what we are keying on is the uses of count_3(D) only, of which
one is in the PHI and one in the add.  Note that after emitting one
diagnostic we're silencing the other because we mark 'count' as being
already diagnosed.

If you modify the testcase to

int test(_Bool cond) {
int count, count2;
if (cond) return ++count;
return count2;
}

you get

t2.c: In function 'test':
t2.c:3:22: warning: 'count' may be used uninitialized [-Wmaybe-uninitialized]
3 | if (cond) return ++count;
  |  ^~~
t2.c:2:9: note: 'count' was declared here
2 | int count, count2;
  | ^
t2.c:4:12: warning: 'count2' may be used uninitialized [-Wmaybe-uninitialized]
4 | return count2;
  |^~
t2.c:2:16: note: 'count2' was declared here
2 | int count, count2;
  |^~

and the IL is very similar:

   [local count: 365072224]:
  count_5 = count_4(D) + 1;

  # _1 = PHI 

you would probably agree to the "may be used" kind used here in which case
it's exactly noticing that the same variable is used on all paths into the
PHI node.

If you'd say this is also a case of an unconditional uninitialized use
(it is!) then it might be even easier to implement this since we don't
need to prove the variables returned are the same ones, just that they
have uninitialized uses.

[Bug c/105510] error: initializer element is not constant

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
(struct Test2){3, 4}
is a compound literal, see
https://en.cppreference.com/w/c/language/compound_literal
for further details, so it isn't a valid constant expression, it is like
doing
struct Test2
{
long int x;
long int y;
};

struct Test
{
long int x;
struct Test2 t;
};

struct Test2 tmp2={3, 4};
struct Test tmp1={1, tmp2};
struct Test t=tmp1;
except that the compound literals introduce unnamed, not named objects.
The above is also rejected, by both GCC and Clang.
Note, implementations may accept as constant expressions even expressions the
standard doesn't require to be constant expressions, so probably that is the
reason why Clang chooses to accept it.  Though, at least without using const
struct Test{,2} in the compound literals it is actually an unnamed object that
can be modified, so it is weird it is accepted.
The above testcase with tmp2/tmp1 is as an extension accepted by GCC when one
uses const struct Test2 or const struct Test (but rejected by Clang), though
if you use it in the compound literals, we don't accept that.

[Bug c++/105534] New: -Wmaybe-uninitialized shouldn't suppress -Wuninitialized warnings

[redbeard0531 at gmail dot com via Gcc-bugs]

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

Bug ID: 105534
   Summary: -Wmaybe-uninitialized shouldn't suppress
-Wuninitialized warnings
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

The following function emits a -Wuninitialized warning on ++count with -Wall
https://godbolt.org/z/KfaMEETY1:

int test(bool cond) {
int count;
++count;
return count;
}

Making the increment be conditional changes it to a -Wmaybe-uninitialized
warning, which is suppressed with -Wno-maybe-uninitialized.
https://godbolt.org/z/qarMrqW7E

int test(bool cond) {
int count;
if (cond) ++count;
return count;
}

This makes no sense. count is never initialized on any path through the
function, and it is returned on all paths.

We use -Wall with -Wno-maybe-uninitialized on our codebase because we were
getting too many false-positives with -Wmaybe-initialized, in particular from
third-party headers that we didn't want to modify. At the time we decided to do
that, we didn't realize that we would also be missing out on clearly
uninitialized cases like this.

[Bug c/105510] error: initializer element is not constant

[570070308 at qq dot com via Gcc-bugs]

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

--- Comment #2 from 。 <570070308 at qq dot com> ---
(In reply to Richard Biener from comment #1)
> As a workaround it works with
> 
> struct Test t=(struct Test){1, {3, 4}};
> 
> I don't think it your way of writing is actually valid though.

Yes, I'm not sure that this is a Bug. I meet this error when I'm using macro to
init a struct. For example:
```test.c
struct Test2
{
long int x;
long int y;
};

struct Test
{
long int x;
struct Test2 t;
};

#define TEST2_INIT(x, y) ((struct Test2){x, y})

#define TEST_INIT(x) ((struct Test){x, TEST2_INIT(1, 2)})

struct Test test=TEST_INIT(0);  // error
```

[Bug libstdc++/104731] 27_io/filesystem/iterators/error_reporting.cc FAILs

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #11 from Jonathan Wakely  ---
Fixed for all branches where I added that test. If I backport the test to
gcc-10 I'll try to remember to backport this too!

[Bug libstdc++/104731] 27_io/filesystem/iterators/error_reporting.cc FAILs

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

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

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

https://gcc.gnu.org/g:6190ebb07cdc2de339c19b236b67bc4106d2bb54

commit r11-9969-g6190ebb07cdc2de339c19b236b67bc4106d2bb54
Author: Jonathan Wakely 
Date:   Fri May 6 14:31:06 2022 +0100

libstdc++: Fix test that fails on Solaris [PR104731]

On Solaris the dirent::d_name member is a single char, causing this test
to fail with warnings about buffer overflow. Change the test to use a
union with additional space for writing a string to the d_name member.

libstdc++-v3/ChangeLog:

PR libstdc++/104731
* testsuite/27_io/filesystem/iterators/error_reporting.cc:
Use a trailing char array as storage for dirent::d_name.

(cherry picked from commit aa8bdfee1db818b9a56908ab0197ff02c54bf281)

[Bug tree-optimization/105517] [13 Regression] Missing diagnostic after recent optimizer improvements

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/105517] [13 Regression] Missing diagnostic after recent optimizer improvements

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

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

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

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

commit r13-205-gfaabc751d0bb7e7fe86abfe8991b0307d585874a
Author: Richard Biener 
Date:   Mon May 9 11:33:44 2022 +0200

tree-optimization/105517 - avoid offset truncation during VN

When value-numbering an address expression like
_74(D)->a1x[4294967295].a1; we are accumulating the byte offset
in an 64bit integer.  When later exploiting the duality between
that and a POINTER_PLUS_EXPR we should avoid truncating that
offset to fit in the target specific sizetype.  While such
overflows are generally undefined behavior, exploiting this
may leads to spurious missing diagnostics.

2022-05-09  Richard Biener  

PR tree-optimization/105517
* tree-ssa-sccvn.cc (vn_reference_lookup): Make sure the
accumulated
offset can be represented in the POINTER_PLUS_EXPR IL.
(vn_reference_insert): Likewise.
* poly-int.h (sext_hwi): Add poly version of sext_hwi.

[Bug libstdc++/104731] 27_io/filesystem/iterators/error_reporting.cc FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
>> It is indeed, tested on Solaris 11.3 and 11.4, SPARC and x86.
>
> Gret, thanks for checking. I'll backport to gcc-11 and gcc-12.

Excellent, thanks.

>> > ld.so.1: g++: fatal: relocation error: file
>> > /export/home/jwakely/gcc/12/bin/g++: symbol stpcpy: referenced symbol
>> > not found
>> 
>> This is weird: stpcpy is in Solaris 11 libc since 11.0.  What version of
>> Solaris exactly does this happen on?
>
> Ah, I think the problem is that $HOME is shared between the Solaris 10 and 11
> machines in the GCC compile farm, and I was probably trying to use the GCC
> built on Solaris 11 on the SOlaris 10 machine.

Makes sense: Solaris 10 indeed lacks stpcpy, but a native build (which
won't work any longer on trunk) would detect that at configure time.

[Bug libstdc++/104731] 27_io/filesystem/iterators/error_reporting.cc FAILs

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

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

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

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

commit r12-8358-gdf8e384d5f91076f35852baed0974793b37ec313
Author: Jonathan Wakely 
Date:   Fri May 6 14:31:06 2022 +0100

libstdc++: Fix test that fails on Solaris [PR104731]

On Solaris the dirent::d_name member is a single char, causing this test
to fail with warnings about buffer overflow. Change the test to use a
union with additional space for writing a string to the d_name member.

libstdc++-v3/ChangeLog:

PR libstdc++/104731
* testsuite/27_io/filesystem/iterators/error_reporting.cc:
Use a trailing char array as storage for dirent::d_name.

(cherry picked from commit aa8bdfee1db818b9a56908ab0197ff02c54bf281)

[Bug tree-optimization/105533] New: UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 105533
   Summary: UBSAN: gcc/expmed.cc:3272:26: runtime error: signed
integer overflow: -9223372036854775808 - 1 cannot be
represented in type 'long int'
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c -c
/repo/gcc-trunk/gcc/expmed.cc:3272:26: runtime error: signed integer overflow:
-9223372036854775808 - 1 cannot be represented in type 'long int'

(gdb) bt
#0  __ubsan::Diag::~Diag (this=this@entry=0x7fffc250, __in_chrg=) at /repo/gcc-trunk/libsanitizer/ubsan/ubsan_diag.cpp:343
#1  0x074e14ec in handleIntegerOverflowImpl<__ubsan::Value>
(Data=Data@entry=0x85fd8e0, LHS=LHS@entry=9223372036854775808,
Operator=Operator@entry=0x7b7c28d "-", RHS=..., Opts=...)
at /repo/gcc-trunk/libsanitizer/ubsan/ubsan_handlers.cpp:227
#2  0x074e478d in __ubsan::__ubsan_handle_sub_overflow
(Data=Data@entry=0x85fd8e0, LHS=LHS@entry=9223372036854775808, RHS=RHS@entry=1)
at /repo/gcc-trunk/libsanitizer/ubsan/ubsan_handlers.cpp:244
#3  0x01384d5d in choose_mult_variant (mode=E_DImode, val=, alg=0x7fffc6b0, variant=0x7fffc6ac, mult_cost=16) at
/repo/gcc-trunk/gcc/expmed.cc:3272
#4  0x01385946 in mult_by_coeff_cost (coeff=-9223372036854775808,
mode=E_DImode, speed=) at /repo/gcc-trunk/gcc/expmed.cc:3610
#5  0x068ae3ac in create_add_ssa_cand (gs=0x77851a50,
base_in=0x77852ea0, addend_in=, subtract_p=false,
speed=true) at /repo/gcc-trunk/gcc/gimple-ssa-strength-reduction.cc:1311
#6  0x068b4668 in slsr_process_add (speed=true, rhs2=0x77852ea0,
rhs1=, gs=) at
/repo/gcc-trunk/gcc/gimple-ssa-strength-reduction.cc:1484
#7  find_candidates_dom_walker::before_dom_children (this=,
bb=) at
/repo/gcc-trunk/gcc/gimple-ssa-strength-reduction.cc:1803
#8  0x0665b9e5 in dom_walker::walk (this=,
bb=0x776f4478) at /repo/gcc-trunk/gcc/domwalk.cc:309
#9  0x0689d07a in (anonymous
namespace)::pass_strength_reduction::execute (this=,
fun=0x7784c0b8) at
/repo/gcc-trunk/gcc/gimple-ssa-strength-reduction.cc:4039
#10 0x021af318 in execute_one_pass (pass=0xc6701b0) at
/repo/gcc-trunk/gcc/passes.cc:2638
#11 0x021b2902 in execute_pass_list_1 (pass=0xc6701b0) at
/repo/gcc-trunk/gcc/passes.cc:2738
#12 0x021b2945 in execute_pass_list_1 (pass=0xc66dcc0) at
/repo/gcc-trunk/gcc/passes.cc:2739
#13 0x021b29f9 in execute_pass_list (fn=0x7784c0b8, pass=) at /repo/gcc-trunk/gcc/passes.cc:2749
#14 0x00f8cebc in cgraph_node::expand (this=0x7784f110) at
/repo/gcc-trunk/gcc/cgraphunit.cc:1835
#15 0x00f92108 in expand_all_functions () at
/repo/gcc-trunk/gcc/cgraphunit.cc:1999
#16 symbol_table::compile (this=0x776ec000) at
/repo/gcc-trunk/gcc/cgraphunit.cc:2349
#17 0x00fa02ad in symbol_table::compile (this=0x776ec000) at
/repo/gcc-trunk/gcc/cgraphunit.cc:2262
#18 symbol_table::finalize_compilation_unit (this=0x776ec000) at
/repo/gcc-trunk/gcc/cgraphunit.cc:2530
#19 0x026d34a3 in compile_file () at /repo/gcc-trunk/gcc/toplev.cc:479
#20 0x00917d45 in do_compile (no_backend=false) at
/repo/gcc-trunk/gcc/toplev.cc:2168
#21 toplev::main (this=this@entry=0x7fffd27e, argc=,
argc@entry=17, argv=, argv@entry=0x7fffd3c8) at
/repo/gcc-trunk/gcc/toplev.cc:2320
#22 0x0091bb6b in main (argc=17, argv=0x7fffd3c8) at
/repo/gcc-trunk/gcc/main.cc:39

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

[Bug libstdc++/104731] 27_io/filesystem/iterators/error_reporting.cc FAILs

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #6)
> > --- Comment #5 from Jonathan Wakely  ---
> > This should be fixed on trunk, but I'm unable to test on Solaris right now:
> 
> It is indeed, tested on Solaris 11.3 and 11.4, SPARC and x86.

Gret, thanks for checking. I'll backport to gcc-11 and gcc-12.

> 
> > ld.so.1: g++: fatal: relocation error: file
> > /export/home/jwakely/gcc/12/bin/g++: symbol stpcpy: referenced symbol not 
> > found
> 
> This is weird: stpcpy is in Solaris 11 libc since 11.0.  What version of
> Solaris exactly does this happen on?

Ah, I think the problem is that $HOME is shared between the Solaris 10 and 11
machines in the GCC compile farm, and I was probably trying to use the GCC
built on Solaris 11 on the SOlaris 10 machine.

[Bug fortran/104228] [9/10/11 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

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

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #14 from Mikael Morin  ---
Fixed for releases 9.5, 10.4, 11.3 and 12.1.
Closing.
Thanks for the report.

[Bug sanitizer/105396] [9/10 Regression] missed stack-buffer-overflow by -O0

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11 Regression] missed |[9/10 Regression] missed
   |stack-buffer-overflow by|stack-buffer-overflow by
   |-O0 |-O0

--- Comment #9 from Jakub Jelinek  ---
Fixed for 11.4+ too.

[Bug rtl-optimization/105333] [10 Regression] ICE: in simplify_subreg, at simplify-rtx.cc:7346 with -Og -fno-tree-coalesce-vars -fno-tree-fre since r10-1094-g9919f5fe87a3def1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE: in  |[10 Regression] ICE: in
   |simplify_subreg, at |simplify_subreg, at
   |simplify-rtx.cc:7346 with   |simplify-rtx.cc:7346 with
   |-Og -fno-tree-coalesce-vars |-Og -fno-tree-coalesce-vars
   |-fno-tree-fre since |-fno-tree-fre since
   |r10-1094-g9919f5fe87a3def1  |r10-1094-g9919f5fe87a3def1

--- Comment #7 from Jakub Jelinek  ---
Fixed for 11.4 too.

[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

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

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