Re: [PATCH v2 1/2] libstdc++: Handle extended alignment in std::get_temporary_buffer [PR105258]

[Stephan Bergmann]

On 6/3/24 22:22, Jonathan Wakely wrote:

Pushed to trunk now.


Just a heads-up that this started to cause Clang (at least 18/19) to 
emit a -Wdeprecated-declarations now,



$ cat test.cc
#include 
void f(int * p1, int * p2) { std::stable_sort(p1, p2); }



$ clang++ 
--gcc-install-dir=/home/sberg/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/15.0.0 
-fsyntax-only test.cc
In file included from test.cc:1:
In file included from 
/home/sberg/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/15.0.0/../../../../include/c++/15.0.0/algorithm:61:
In file included from 
/home/sberg/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/15.0.0/../../../../include/c++/15.0.0/bits/stl_algo.h:69:
/home/sberg/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/15.0.0/../../../../include/c++/15.0.0/bits/stl_tempbuf.h:207:11:
 warning: 'get_temporary_buffer' is deprecated [-Wdeprecated-declarations]
  207 | std::get_temporary_buffer(__original_len));
  |  ^
/home/sberg/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/15.0.0/../../../../include/c++/15.0.0/bits/stl_tempbuf.h:323:40:
 note: in instantiation of member function 
'std::_Temporary_buffer<__gnu_cxx::__normal_iterator>, 
int>::_Impl::_Impl' requested here
  323 | : _M_original_len(__original_len), _M_impl(__original_len)
  |^
/home/sberg/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/15.0.0/../../../../include/c++/15.0.0/bits/stl_algo.h:4948:15:
 note: in instantiation of member function 
'std::_Temporary_buffer<__gnu_cxx::__normal_iterator>, 
int>::_Temporary_buffer' requested here
 4948 |   _TmpBuf __buf(__first, (__last - __first + 1) / 2);
  |   ^
/home/sberg/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/15.0.0/../../../../include/c++/15.0.0/bits/stl_algo.h:4993:23:
 note: in instantiation of function template specialization 
'std::__stable_sort<__gnu_cxx::__normal_iterator>, 
__gnu_cxx::__ops::_Iter_less_iter>' requested here
 4993 |   _GLIBCXX_STD_A::__stable_sort(__first, __last,
  |   ^
test.cc:3:37: note: in instantiation of function template specialization 
'std::stable_sort<__gnu_cxx::__normal_iterator>>' 
requested here
3 | void f(std::vector & v) { std::stable_sort(v.begin(), v.end()); }
  | ^
/home/sberg/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/15.0.0/../../../../include/c++/15.0.0/bits/stl_tempbuf.h:141:5:
 note: 'get_temporary_buffer' has been explicitly marked deprecated here
  141 | _GLIBCXX17_DEPRECATED
  | ^
/home/sberg/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/15.0.0/../../../../include/c++/15.0.0/x86_64-pc-linux-gnu/bits/c++config.h:123:34:
 note: expanded from macro '_GLIBCXX17_DEPRECATED'
  123 | # define _GLIBCXX17_DEPRECATED [[__deprecated__]]
  |  ^
1 warning generated.


which could be silenced with


--- a/libstdc++-v3/include/bits/stl_tempbuf.h
+++ b/libstdc++-v3/include/bits/stl_tempbuf.h
@@ -203,8 +203,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
explicit
_Impl(ptrdiff_t __original_len)
{
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
  pair __p(
std::get_temporary_buffer(__original_len));
+#pragma GCC diagnostic pop
  _M_len = __p.second;
  _M_buffer = __p.first;
}


(There already is another such pragma diagnostic ignored a bit further 
down in that file, so I assume that's the way to go there?)

Re: [PATCH v2] c++: direct-init of an array of class type [PR59465]

[Stephan Bergmann]

On 3/25/24 13:07, Jakub Jelinek wrote:

On Mon, Mar 25, 2024 at 12:36:46PM +0100, Stephan Bergmann wrote:

This started to break


$ cat test.cc
struct S1 { S1(); };
struct S2 {
 S2() {}
 S1 a[1] {};
};



$ g++ -fsyntax-only test.cc
test.cc: In constructor ‘S2::S2()’:
test.cc:3:10: error: invalid initializer for array member ‘S1 S2::a [1]’
 3 | S2() {}
   |  ^


https://gcc.gnu.org/PR114439 ?


yes, sorry, missed that already-existing bugracker issue

Re: [PATCH v2] c++: direct-init of an array of class type [PR59465]

[Stephan Bergmann]

On 3/21/24 10:28 PM, Jason Merrill wrote:

On 3/21/24 16:48, Marek Polacek wrote:

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?


OK.


This started to break


$ cat test.cc
struct S1 { S1(); };
struct S2 {
S2() {}
S1 a[1] {};
};



$ g++ -fsyntax-only test.cc
test.cc: In constructor ‘S2::S2()’:
test.cc:3:10: error: invalid initializer for array member ‘S1 S2::a [1]’
3 | S2() {}
  |  ^

Re: [PATCH][_GLIBCXX_DEBUG] Fix std::__niter_base behavior

[Stephan Bergmann]

On 2/17/24 15:14, François Dumont wrote:

Thanks for the link, tested and committed.


I assume this is the cause for the below failure now,


$ cat test.cc
#include 
#include 
void f(std::vector &v, void const * p) {
std::erase(v, p);
}



$ ~/gcc/inst/bin/g++ -std=c++20 -D_GLIBCXX_DEBUG -fsyntax-only test.cc
In file included from ~/gcc/inst/include/c++/14.0.1/algorithm:60,
 from test.cc:1:
~/gcc/inst/include/c++/14.0.1/bits/stl_algobase.h: In instantiation of ‘constexpr _From std::__niter_wrap(_From, _To) [with 
_From = __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >, __debug::vector, random_access_iterator_tag>; _To = 
__gnu_cxx::__normal_iterator > >]’:
~/gcc/inst/include/c++/14.0.1/vector:144:29:   required from ‘constexpr typename std::__debug::vector<_Tp, 
_Allocator>::size_type std::erase(__debug::vector<_Tp, _Alloc>&, const _Up&) [with _Tp = const 
void*; _Alloc = allocator; _Up = const void*; typename __debug::vector<_Tp, 
_Allocator>::size_type = long unsigned int]’
  144 |   __cont.erase(__niter_wrap(__cont.begin(), __removed),
  |^~~
test.cc:4:15:   required from here
4 | std::erase(v, p);
  | ~~^~
~/gcc/inst/include/c++/14.0.1/bits/stl_algobase.h:347:30: error: no match for ‘operator-’ 
(operand types are ‘__gnu_cxx::__normal_iterator > >’ and ‘const void**’)
  347 | { return __from + (__res - std::__niter_base(__from)); }
  |   ~~~^~~~
In file included from ~/gcc/inst/include/c++/14.0.1/bits/stl_algobase.h:67:
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:1148:7: note: candidate: ‘constexpr 
__gnu_cxx::__normal_iterator<_Iterator, _Container> __gnu_cxx::__normal_iterator<_Iterator, 
_Container>::operator-(difference_type) const [with _Iterator = const void**; _Container = 
std::__cxx1998::vector >; difference_type = long 
int]’ (near match)
 1148 |   operator-(difference_type __n) const _GLIBCXX_NOEXCEPT
  |   ^~~~
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:1148:7: note:   conversion of 
argument 1 would be ill-formed:
~/gcc/inst/include/c++/14.0.1/bits/stl_algobase.h:347:49: error: invalid conversion from ‘const 
void**’ to ‘__gnu_cxx::__normal_iterator > >::difference_type’ {aka ‘long int’} [-fpermissive]
  347 | { return __from + (__res - std::__niter_base(__from)); }
  |~^~~~
  | |
  | const void**
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:618:5: note: candidate: ‘template constexpr decltype ((__y.base() - __x.base())) std::operator-(const 
reverse_iterator<_IteratorL>&, const reverse_iterator<_IteratorR>&)’
  618 | operator-(const reverse_iterator<_IteratorL>& __x,
  | ^~~~
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:618:5: note:   template 
argument deduction/substitution failed:
~/gcc/inst/include/c++/14.0.1/bits/stl_algobase.h:347:30: note:   
‘__gnu_cxx::__normal_iterator > >’ is not derived from ‘const 
std::reverse_iterator<_IteratorL>’
  347 | { return __from + (__res - std::__niter_base(__from)); }
  |   ~~~^~~~
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:1789:5: note: candidate: ‘template constexpr decltype ((__x.base() - __y.base())) std::operator-(const 
move_iterator<_IteratorL>&, const move_iterator<_IteratorR>&)’
 1789 | operator-(const move_iterator<_IteratorL>& __x,
  | ^~~~
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:1789:5: note:   template 
argument deduction/substitution failed:
~/gcc/inst/include/c++/14.0.1/bits/stl_algobase.h:347:30: note:   
‘__gnu_cxx::__normal_iterator > >’ is not derived from ‘const 
std::move_iterator<_IteratorL>’
  347 | { return __from + (__res - std::__niter_base(__from)); }
  |   ~~~^~~~
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:1312:5: note: candidate: ‘template constexpr decltype ((__lhs.base() - __rhs.base())) 
__gnu_cxx::operator-(const __normal_iterator<_IteratorL, _Container>&, const 
__normal_iterator<_IteratorR, _Container>&)’
 1312 | operator-(const __normal_iterator<_IteratorL, _Container>& __lhs,
  | ^~~~
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:1312:5: note:   template 
argument deduction/substitution failed:
~/gcc/inst/include/c++/14.0.1/bits/stl_algobase.h:347:30: note:   mismatched types 
‘const __gnu_cxx::__normal_iterator<_IteratorR, _Container>’ and ‘const void**’
  347 | { return __from + (__res - std::__niter_base(__from)); }
  |   ~~~^~~~
~/gcc/inst/include/c++/14.0.1/bits/stl_iterator.h:1325:5: note: candidate: ‘template constexpr typename __gnu_cxx::__normal_iterator<_Iterator, _Container>

Re: [committed] libstdc++: Define std::numeric_limits<_FloatNN> before C++23

[Stephan Bergmann]

On 8/17/23 22:32, Jonathan Wakely via Libstdc++ wrote:

Tested x86_64-linux. Pushed to trunk.

-- >8 --

The extended floating-point types such as _Float32 are supported by GCC
prior to C++23, you just can't use the standard-conforming names from
 to refer to them. This change defines the specializations of
std::numeric_limits for those types for older dialects, not only for
C++23.

libstdc++-v3/ChangeLog:

* include/bits/c++config (__gnu_cxx::__bfloat16_t): Define
whenever __BFLT16_DIG__ is defined, not only for C++23.
* include/std/limits (numeric_limits): Likewise.
(numeric_limits<_Float16>, numeric_limits<_Float32>)
(numeric_limits<_Float64>): Likewise for other extended
floating-point types.
---
  libstdc++-v3/include/bits/c++config |   4 +-
  libstdc++-v3/include/std/limits | 194 +++-
  2 files changed, 103 insertions(+), 95 deletions(-)


[...]

diff --git a/libstdc++-v3/include/std/limits b/libstdc++-v3/include/std/limits
index 52b19ef8264..7a59e7520eb 100644
--- a/libstdc++-v3/include/std/limits
+++ b/libstdc++-v3/include/std/limits
@@ -1890,189 +1890,197 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

[...]

  __glibcxx_float_n(64)
  #endif
-#ifdef __STDCPP_FLOAT128_T__
+#ifdef __FLT128_DIG__
  __glibcxx_float_n(128)
  #endif
  #undef __glibcxx_float_n

[...]

The above change (from __STDCPP_FLOAT128_T__ to __FLT128_DIG__) now 
started to cause issues with Clang on Clang 18 trunk:


* Clang does not support a _Float128 type.

* Clang does not predefine __STDCPP_FLOAT128_T__.

* But since 
 
"[clang] Predefined macros for float128 support (#67196)", Clang 18 
trunk does predefine __FLT128_DIG__ now.  Which causes



$ cat test.cc
#include 



$ clang++ -fsyntax-only test.cc
In file included from test.cc:1:
/home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../include/c++/14.0.0/limits:1995:1:
 error: use of undeclared identifier '_Float128'
 1995 | __glibcxx_float_n(128)
  | ^
/home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../include/c++/14.0.0/limits:1903:27:
 note: expanded from macro '__glibcxx_float_n'
 1903 | struct numeric_limits<_Float##BITSIZE>  
\
  |   ^
:36:1: note: expanded from here
   36 | _Float128
  | ^
1 error generated.


(I don't know whether or not it is useful for Clang to predefine 
__FLT128_DIG__ when not providing a _Float128 type.  I assume 
 "ISO/IEC TS 18661-3:2015", as 
referenced by the C++ standard, might be relevant here, but don't know 
that document.  I added Pranav, the author of the relevant Clang commit, 
in cc here.)

Re: [pushed] c++: avoid initializer_list [PR105838]

[Stephan Bergmann via Gcc-patches]

On 12/8/22 19:41, Jason Merrill via Gcc-patches wrote:

Tested x86_64-pc-linux-gnu, applying to trunk.


Bisecting shows this started to break


$ cat test.cc
#include 
template struct ConstCharArrayDetector;
template struct ConstCharArrayDetector { using Type = 
int; };
struct OUString {
template OUString(T &, typename ConstCharArrayDetector::Type 
= 0);
};
std::vector f() { return {""}; }



$ g++ -fsyntax-only test.cc
In file included from .../include/c++/13.0.0/vector:65,
 from test.cc:1:
.../include/c++/13.0.0/bits/stl_uninitialized.h: In instantiation of ‘constexpr 
bool std::__check_constructible() [with _ValueType = OUString; _Tp = const char* 
const&]’:
.../include/c++/13.0.0/bits/stl_uninitialized.h:182:4:   required from 
‘_ForwardIterator std::uninitialized_copy(_InputIterator, _InputIterator, 
_ForwardIterator) [with _InputIterator = const char* const*; _ForwardIterator = 
OUString*]’
.../include/c++/13.0.0/bits/stl_uninitialized.h:373:37:   required from ‘_ForwardIterator 
std::__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator, 
allocator<_Tp>&) [with _InputIterator = const char* const*; _ForwardIterator = 
OUString*; _Tp = OUString]’
.../include/c++/13.0.0/bits/stl_vector.h:1690:33:   required from ‘void std::vector<_Tp, 
_Alloc>::_M_range_initialize(_ForwardIterator, _ForwardIterator, 
std::forward_iterator_tag) [with _ForwardIterator = const char* const*; _Tp = OUString; 
_Alloc = std::allocator]’
.../include/c++/13.0.0/bits/stl_vector.h:706:23:   required from ‘std::vector<_Tp, 
_Alloc>::vector(_InputIterator, _InputIterator, const allocator_type&) [with _InputIterator = const 
char* const*;  = void; _Tp = OUString; _Alloc = 
std::allocator; allocator_type = std::allocator]’
test.cc:7:39:   required from here
.../include/c++/13.0.0/bits/stl_uninitialized.h:90:56: error: static assertion 
failed: result type must be constructible from input type
   90 |   static_assert(is_constructible<_ValueType, _Tp>::value,
  |^
.../include/c++/13.0.0/bits/stl_uninitialized.h:90:56: note: 
‘std::integral_constant::value’ evaluates to false

Re: [pushed] c++: build initializer_list in a loop [PR105838]

[Stephan Bergmann via Gcc-patches]

On 08/12/2022 19:45, Jason Merrill via Gcc-patches wrote:

Tested x86_64-pc-linux-gnu, applying to trunk.


Bisecting shows this started to break


$ cat test.cc
#include 
template struct ConstCharArrayDetector;
template struct ConstCharArrayDetector { using Type = 
int; };
struct OUString {
template OUString(T &, typename ConstCharArrayDetector::Type 
= 0);
};
struct Sequence { Sequence(std::initializer_list); };
Sequence f() { return {""}; }



$ g++ -fsyntax-only test.cc
test.cc: In function ‘Sequence f()’:
test.cc:8:26: error: no matching function for call to ‘OUString::OUString(const 
char* const)’
8 | Sequence f() { return {""}; }
  |  ^
test.cc:5:26: note: candidate: ‘template OUString::OUString(T&, typename 
ConstCharArrayDetector::Type)’
5 | template OUString(T &, typename 
ConstCharArrayDetector::Type = 0);
  |  ^~~~
test.cc:5:26: note:   template argument deduction/substitution failed:
test.cc: In substitution of ‘template OUString::OUString(T&, typename 
ConstCharArrayDetector::Type) [with T = const char* const]’:
test.cc:8:26:   required from here
test.cc:5:26: error: invalid use of incomplete type ‘struct 
ConstCharArrayDetector’
test.cc:2:27: note: declaration of ‘struct ConstCharArrayDetector’
2 | template struct ConstCharArrayDetector;
  |   ^~
test.cc:4:8: note: candidate: ‘constexpr OUString::OUString(const OUString&)’
4 | struct OUString {
  |^~~~
test.cc:4:8: note:   no known conversion for argument 1 from ‘const char* const’ to 
‘const OUString&’
test.cc:4:8: note: candidate: ‘constexpr OUString::OUString(OUString&&)’
test.cc:4:8: note:   no known conversion for argument 1 from ‘const char* const’ to 
‘OUString&&’
test.cc:8:26: error: conversion from ‘const char* const’ to non-scalar type 
‘const OUString’ requested
8 | Sequence f() { return {""}; }
  |  ^

Re: [PATCH] libstdc++: Make chrono::hh_mm_ss more compact

[Stephan Bergmann via Gcc-patches]

On 12/12/2022 12:18, Jonathan Wakely wrote:

If Clang already treats __is_signed as a conditionally-active
built-in, it should do the same for __is_unsigned.


Wasn't aware of that special handling of __is_signed.  Filed 
 "Also allow __is_unsigned to be used 
as an identifier" now (just in case, even if the use in libstdc++ is 
already gone again).

Re: [PATCH] libstdc++: Make chrono::hh_mm_ss more compact

[Stephan Bergmann via Gcc-patches]

On 11/21/22 21:43, Jonathan Wakely via Libstdc++ wrote:

+   static constexpr bool __is_unsigned
+ = __and_v,
+   is_unsigned>;


Using `__is_unsigned` as an identifier here causes compilation issues 
with Clang, which predefines that as a builtin predicate.

Re: [PATCH (pushed)] sphinx: fix building if sphinx-build is missing

[Stephan Bergmann via Gcc-patches]

On 11/13/22 20:26, Martin Liška wrote:

The patch is fine, please send it to gcc-patches ML and install it.


I sent a patch now, but don't have commit rights.

[PATCH] sphinx: more build fixing if sphinx-build is missing

[Stephan Bergmann via Gcc-patches]

...similar to 1f9c79367e136e0ca5b775562e6111e1a0d0046f "sphinx: fix 
building if

sphinx-build is missing"

gcc/ChangeLog:

* fortran/Make-lang.in: Build info pages conditionally.
---
 gcc/fortran/Make-lang.in | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/fortran/Make-lang.in b/gcc/fortran/Make-lang.in
index 48acbed1754..852b6f3327f 100644
--- a/gcc/fortran/Make-lang.in
+++ b/gcc/fortran/Make-lang.in
@@ -161,7 +161,9 @@ fortran.install-pdf: $(F95_PDFFILES)
 F95_MANFILES = doc/gfortran/man/man/gfortran.1

 doc/gfortran/man/man/gfortran.1: $(SPHINX_FILES)
-	+ make -C $(srcdir)/../doc man 
SOURCEDIR=$(abs_srcdir)/fortran/doc/gfortran 
BUILDDIR=$(objdir)/doc/gfortran/man SPHINXBUILD=$(SPHINX_BUILD)

+   + if [ x$(HAS_SPHINX_BUILD) = xhas-sphinx-build ]; then \
+	  make -C $(srcdir)/../doc man 
SOURCEDIR=$(abs_srcdir)/fortran/doc/gfortran 
BUILDDIR=$(objdir)/doc/gfortran/man SPHINXBUILD=$(SPHINX_BUILD) \

+   else true; fi

 fortran.man: $(F95_MANFILES)

--
2.38.1

Re: [committed] libstdc++: Avoid redundant checks in std::use_facet [PR103755]

[Stephan Bergmann via Gcc-patches]

On 11/12/22 03:47, Jonathan Wakely wrote:

On Fri, 11 Nov 2022 at 21:00, Stephan Bergmann  wrote:


On 11/11/22 06:30, Jonathan Wakely via Gcc-patches wrote:

As discussed in the PR, this makes it three times faster to construct
iostreams objects.

Tested x86_64-linux. Pushed to trunk.


I haven't yet tried to track down what's going on, but with various
versions of Clang (e.g. clang-15.0.4-1.fc37.x86_64):


$ cat test.cc
#include 
int main(int, char ** argv) {
 std::regex_traits().transform(argv[0], argv[0] + 1);
}



$ clang++ --gcc-toolchain=... -fsanitize=undefined -O2 test.cc
/usr/bin/ld: /tmp/test-c112b1.o: in function `std::__cxx11::basic_string, std::allocator > 
std::__cxx11::regex_traits::transform(char*, char*) const':
test.cc:(.text._ZNKSt7__cxx1112regex_traitsIcE9transformIPcEENS_12basic_stringIcSt11char_traitsIcESaIcEEET_S9_[_ZNKSt7__cxx1112regex_traitsIcE9transformIPcEENS_12basic_stringIcSt11char_traitsIcESaIcEEET_S9_]+0x1b):
 undefined reference to `std::__cxx11::collate const* 
std::__try_use_facet >(std::locale const&)'
clang-15: error: linker command failed with exit code 1 (use -v to see 
invocation)


That should be present, andis present in my builds:

_ZSt15__try_use_facetINSt7__cxx117collateIcEEEPKT_RKSt6locale
std::__cxx11::collate const*
std::__try_use_facet >(std::locale const&)
version status: compatible
GLIBCXX_3.4.31
type: function
status: added

Was this a clean build, or incremental? I'm guessing the latter.


Yes, indeed.  And a full rebuild fixed the issue for me.

Sorry for the noise.

Re: [PATCH (pushed)] sphinx: fix building if sphinx-build is missing

[Stephan Bergmann via Gcc-patches]

On 11/9/22 10:09, Martin Liška wrote:

I noticed I modified Makefile.in files in the Sphinx series. While I was
supposed to modifiky Makefile.am and use automake. I'm going to fix that soon.


A recent master build against (apparently too old) 
python3-sphinx-5.0.2-2.fc37.noarch failed for me with


[...]

make -C ../../src/gcc/../doc man 
SOURCEDIR=.../build/gcc/../../src/gcc/fortran/doc/gfortran 
BUILDDIR=.../build/gcc/doc/gfortran/man SPHINXBUILD=sphinx-build
make[3]: Entering directory '.../src/doc'
sphinx-build -b "man" -d .../build/gcc/doc/gfortran/man/doctrees  -q  
.../build/gcc/../../src/gcc/fortran/doc/gfortran ".../build/gcc/doc/gfortran/man/man"

Sphinx version error:
This project needs at least Sphinx v5.3 and therefore cannot be built with this 
version.
make[3]: *** [Makefile:100: man] Error 2
make[3]: Leaving directory '.../src/doc'
make[2]: *** [../../src/gcc/fortran/Make-lang.in:164: 
doc/gfortran/man/man/gfortran.1] Error 2
make[2]: Leaving directory '.../build/gcc'
make[1]: *** [Makefile:5300: install-gcc] Error 2
make[1]: Leaving directory '.../build'
make: *** [Makefile:2576: install] Error 2


which would be fixed by


diff --git a/gcc/fortran/Make-lang.in b/gcc/fortran/Make-lang.in
index 48acbed1754..852b6f3327f 100644
--- a/gcc/fortran/Make-lang.in
+++ b/gcc/fortran/Make-lang.in
@@ -161,7 +161,9 @@ fortran.install-pdf: $(F95_PDFFILES)
 F95_MANFILES = doc/gfortran/man/man/gfortran.1
 
 doc/gfortran/man/man/gfortran.1: $(SPHINX_FILES)

-   + make -C $(srcdir)/../doc man 
SOURCEDIR=$(abs_srcdir)/fortran/doc/gfortran 
BUILDDIR=$(objdir)/doc/gfortran/man SPHINXBUILD=$(SPHINX_BUILD)
+   + if [ x$(HAS_SPHINX_BUILD) = xhas-sphinx-build ]; then \
+ make -C $(srcdir)/../doc man 
SOURCEDIR=$(abs_srcdir)/fortran/doc/gfortran 
BUILDDIR=$(objdir)/doc/gfortran/man SPHINXBUILD=$(SPHINX_BUILD) \
+   else true; fi
 
 fortran.man: $(F95_MANFILES)
 

Re: [committed] libstdc++: Avoid redundant checks in std::use_facet [PR103755]

[Stephan Bergmann via Gcc-patches]

On 11/11/22 06:30, Jonathan Wakely via Gcc-patches wrote:

As discussed in the PR, this makes it three times faster to construct
iostreams objects.

Tested x86_64-linux. Pushed to trunk.


I haven't yet tried to track down what's going on, but with various 
versions of Clang (e.g. clang-15.0.4-1.fc37.x86_64):



$ cat test.cc
#include 
int main(int, char ** argv) {
std::regex_traits().transform(argv[0], argv[0] + 1);
}



$ clang++ --gcc-toolchain=... -fsanitize=undefined -O2 test.cc
/usr/bin/ld: /tmp/test-c112b1.o: in function `std::__cxx11::basic_string, std::allocator > 
std::__cxx11::regex_traits::transform(char*, char*) const':
test.cc:(.text._ZNKSt7__cxx1112regex_traitsIcE9transformIPcEENS_12basic_stringIcSt11char_traitsIcESaIcEEET_S9_[_ZNKSt7__cxx1112regex_traitsIcE9transformIPcEENS_12basic_stringIcSt11char_traitsIcESaIcEEET_S9_]+0x1b):
 undefined reference to `std::__cxx11::collate const* 
std::__try_use_facet >(std::locale const&)'
clang-15: error: linker command failed with exit code 1 (use -v to see 
invocation)

Re: [PATCH v4] eliminate mutex in fast path of __register_frame

[Stephan Bergmann via Gcc-patches]

On 19/09/2022 17:33, Thomas Neumann wrote:
Can you try if the patch below fixes the problem? It keeps the data 
structures alive at shutdown, though, which will probably make some leak 
detectors unhappy.


Alternatively we could simply remove the gcc_assert (ob) in line 285 of 
that file. As far as I can see in crt-begin nothing bad happens if we 
return nullptr at shutdown.


Yes, thanks, each of those two alternative approaches would appear to 
fix that LibreOffice build of mine.

Re: [PATCH v4] eliminate mutex in fast path of __register_frame

[Stephan Bergmann via Gcc-patches]

On 19/09/2022 15:55, Thomas Neumann wrote:
Apparently a registered frame is not found when deregistering, which 
triggers an assert. I will debug this. Could you send me a script or a 
description on how to reproduce the issue?


Thanks a lot!  I'm in the process of checking whether a more generic 
LibreOffice build scenario will also exhibit this, and will let you know 
about a (hopefully less demanding) reproducer scenario.

Re: [PATCH v4] eliminate mutex in fast path of __register_frame

[Stephan Bergmann via Gcc-patches]

On 16/09/2022 12:19, Thomas Neumann via Gcc-patches wrote:

The __register_frame/__deregister_frame functions are used to register
unwinding frames from JITed code in a sorted list. That list itself
is protected by object_mutex, which leads to terrible performance
in multi-threaded code and is somewhat expensive even if single-threaded.
There was already a fast-path that avoided taking the mutex if no
frame was registered at all.

This commit eliminates both the mutex and the sorted list from
the atomic fast path, and replaces it with a btree that uses
optimistic lock coupling during lookup. This allows for fully parallel
unwinding and is essential to scale exception handling to large
core counts.


I haven't debugged this in any way, nor checked whether it only impacts 
exactly my below scenario, but noticed the following:


At least when building LibreOffice with Clang (16 trunk) with ASan and 
UBsan enabled against libstdc++ (with --gcc-toolchain and 
LD_LIBRARY_PATH to pick up a libstdc++ trunk build including this change 
at build and run-time), at least one of the LibreOffice tests executed 
during the build started to fail with



Thread 1 "cppunittester" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=, signo=signo@entry=6, 
no_tid=no_tid@entry=0)Downloading 0.00 MB source file 
/usr/src/debug/glibc-2.36-4.fc37.x86_64/nptl/pthread_kill.c
 at 
~/.cache/debuginfod_client/a6572cd46182057d3dbacf1685a12edab0e2eda1/source##usr##src##debug##glibc-2.36-4.fc37.x86_64##nptl##pthread_kill.c:44
44return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO 
(ret) : 0;
(gdb) bt
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at 
~/.cache/debuginfod_client/a6572cd46182057d3dbacf1685a12edab0e2eda1/source##usr##src##debug##glibc-2.36-4.fc37.x86_64##nptl##pthread_kill.c:44
#1  0x76dcdd33 in __pthread_kill_internal (signo=6, threadid=) at 
~/.cache/debuginfod_client/a6572cd46182057d3dbacf1685a12edab0e2eda1/source##usr##src##debug##glibc-2.36-4.fc37.x86_64##nptl##pthread_kill.c:78
#2  0x76d7daa6 in __GI_raise (sig=sig@entry=6) at 
~/.cache/debuginfod_client/a6572cd46182057d3dbacf1685a12edab0e2eda1/source##usr##src##debug##glibc-2.36-4.fc37.x86_64##signal##..##sysdeps##posix##raise.c:26
#3  0x76d677fc in __GI_abort () at 
~/.cache/debuginfod_client/a6572cd46182057d3dbacf1685a12edab0e2eda1/source##usr##src##debug##glibc-2.36-4.fc37.x86_64##stdlib##abort.c:79
#4  0x76f377e8 in __deregister_frame_info_bases (begin=) 
at ~/gcc/trunk/src/libgcc/unwind-dw2-fde.c:285
#5  __deregister_frame_info_bases (begin=) at 
~/gcc/trunk/src/libgcc/unwind-dw2-fde.c:223
#6  0x7fffc7c3b53f in __do_fini () at 
~/lo/core/instdir/program/libcairo.so.2
#7  0x77fcda9e in _dl_fini () at 
~/.cache/debuginfod_client/653dfb54d6e6d9c27c349f698a8af1ab86d5501d/source##usr##src##debug##glibc-2.36-4.fc37.x86_64##elf##dl-fini.c:142
#8  0x76d7ff35 in __run_exit_handlers (status=0, listp=0x76f13840 
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, 
run_dtors=run_dtors@entry=true) at 
~/.cache/debuginfod_client/a6572cd46182057d3dbacf1685a12edab0e2eda1/source##usr##src##debug##glibc-2.36-4.fc37.x86_64##stdlib##exit.c:113
#9  0x76d800b0 in __GI_exit (status=) at 
~/.cache/debuginfod_client/a6572cd46182057d3dbacf1685a12edab0e2eda1/source##usr##src##debug##glibc-2.36-4.fc37.x86_64##stdlib##exit.c:143
#10 0x76d68517 in __libc_start_call_main (main=main@entry=0x556c9ef0 
, argc=argc@entry=24, argv=argv@entry=0x7ffefbf8) at 
~/.cache/debuginfod_client/a6572cd46182057d3dbacf1685a12edab0e2eda1/source##usr##src##debug##glibc-2.36-4.fc37.x86_64##csu##..##sysdeps##nptl##libc_start_call_main.h:74
#11 0x76d685c9 in __libc_start_main_impl (main=0x556c9ef0 , 
argc=24, argv=0x7ffefbf8, init=, fini=, 
rtld_fini=, stack_end=0x7ffefbe8) at 
~/.cache/debuginfod_client/a6572cd46182057d3dbacf1685a12edab0e2eda1/source##usr##src##debug##glibc-2.36-4.fc37.x86_64##csu##..##csu##libc-start.c:381
#12 0x555f1575 in _start ()


and which went away again when locally reverting this 
 
"eliminate mutex in fast path of __register_frame".

Re: [PATCH] c++: Extend -Wpessimizing-move to other contexts

[Stephan Bergmann via Gcc-patches]

On 16/08/2022 14:27, Marek Polacek via Gcc-patches wrote:

Ping.  (The other std::move patches depend on this one.)


 
"c++: Extend -Wpessimizing-move to other contexts" started to cause 
false positive



$ cat test.cc
#include 
struct S1 {
S1();
S1(S1 const &) = delete;
S1(S1 &&);
S1 operator =(S1 const &) = delete;
S1 operator =(S1 &&);
};
struct S2 { S2(S1); };
S2 f() {
S1 s;
return { std::move(s) };
}

$ g++ -fsyntax-only -Wredundant-move test.cc
test.cc: In function ‘S2 f()’:
test.cc:12:27: warning: redundant move in return statement [-Wredundant-move]
   12 | return { std::move(s) };
  |   ^
test.cc:12:27: note: remove ‘std::move’ call

Re: [PATCH] c++: Add __reference_con{struc,ver}ts_from_temporary [PR104477]

[Stephan Bergmann via Gcc-patches]

On 7/15/22 22:25, Marek Polacek via Gcc-patches wrote:

Yeah, I guess so.  But I've already pushed the patch.


This commit obviously breaks using libstdc++ with Clang (in -std=c++2b 
mode), which doesn't implement those new builtins.  Something like the 
below would fix that,



diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index b1a1deecf66..a6e028b42ec 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -3505,6 +3505,7 @@ template
   template
 inline constexpr bool is_scoped_enum_v = is_scoped_enum<_Tp>::value;
 
+#if __has_builtin(__reference_constructs_from_temporary) && __has_builtin(__reference_converts_from_temporary)

 #define __cpp_lib_reference_from_temporary 202202L
 
   /// True if _Tp is a reference type, a _Up value can be bound to _Tp in

@@ -3544,6 +3545,7 @@ template
   template
 inline constexpr bool reference_converts_from_temporary_v
   = reference_converts_from_temporary<_Tp, _Up>::value;
+#endif
 #endif // C++23
 
 #if _GLIBCXX_HAVE_IS_CONSTANT_EVALUATED

diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 5edca2f3007..7c4b7f7cc6d 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -304,7 +304,9 @@
 #define __cpp_lib_byteswap 202110L
 #define __cpp_lib_constexpr_typeinfo 202106L
 #define __cpp_lib_is_scoped_enum 202011L
+#if __has_builtin(__reference_constructs_from_temporary) && 
__has_builtin(__reference_converts_from_temporary)
 #define __cpp_lib_reference_from_temporary 202202L
+#endif
 
 #if _GLIBCXX_HOSTED

 #define __cpp_lib_adaptor_iterator_pair_constructor 202106L

Re: [pushed] c++: Include -Woverloaded-virtual in -Wall [PR87729]

[Stephan Bergmann via Gcc-patches]

On 01/07/2022 22:30, Stephan Bergmann wrote:

On 6/25/22 00:26, Jason Merrill via Gcc-patches wrote:

This seems like a good warning to have in -Wall, as requested.  But as
pointed out in PR20423, some users want a warning only when a derived
function doesn't override any base function.  So let's put that lesser
version in -Wall (and -Woverloaded-virtual=1) while leaving the semantics
for the existing option the same.


This now causes

[...]

moved that to a comment at 
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87729#c10> "Please include 
-Woverloaded-virtual in -Wall" now

Re: [pushed] c++: Include -Woverloaded-virtual in -Wall [PR87729]

[Stephan Bergmann via Gcc-patches]

On 6/25/22 00:26, Jason Merrill via Gcc-patches wrote:

This seems like a good warning to have in -Wall, as requested.  But as
pointed out in PR20423, some users want a warning only when a derived
function doesn't override any base function.  So let's put that lesser
version in -Wall (and -Woverloaded-virtual=1) while leaving the semantics
for the existing option the same.


This now causes


$ cat test.cc
struct S1 {};
struct S2: S1 { virtual ~S2(); };
struct S3 { virtual ~S3(); };
struct S4: S2, S3 { virtual ~S4(); };



$ g++ -Woverloaded-virtual -fsyntax-only test.cc
test.cc:3:21: warning: ‘virtual S3::~S3()’ was hidden [-Woverloaded-virtual=]
3 | struct S3 { virtual ~S3(); };
  | ^
test.cc:4:29: note:   by ‘virtual S4::~S4()’
4 | struct S4: S2, S3 { virtual ~S4(); };
  | ^
test.cc:3:21: warning: ‘virtual S3::~S3()’ was hidden [-Woverloaded-virtual=]
3 | struct S3 { virtual ~S3(); };
  | ^
test.cc:4:29: note:   by ‘virtual S4::~S4()’
4 | struct S4: S2, S3 { virtual ~S4(); };
  | ^
test.cc:3:21: warning: ‘virtual S3::~S3()’ was hidden [-Woverloaded-virtual=]
3 | struct S3 { virtual ~S3(); };
  | ^
test.cc:4:29: note:   by ‘virtual S4::~S4()’
4 | struct S4: S2, S3 { virtual ~S4(); };
  | ^

Re: PING 4 [PATCH v2 2/2] add -Wdangling-pointer [PR #63272]

[Stephan Bergmann via Gcc-patches]

On 17/01/2022 20:14, Martin Sebor wrote:

I tried to set up OpenOffice for testing with the latest GCC but
couldn't get the build to finish (it failed downloading some
unavailable prerequisites).  I don't remember what problem I ran
into with LibreOffice; it was before I upgraded to Fedora 35 just
a couple of weeks ago.  Let me retry again (the build is still
downloading tarballs).

In the meantime, do you have any tips or suggestions getting it
set up that aren't on the instructions page below?  (Especially
for using an alternate compiler and non-default options.)

https://wiki.documentfoundation.org/Development/BuildingOnLinux#Fedora.2FRedHat 


Building LibreOffice from source should be relatively easy these days, 
esp. on Linux.  Let me know if you have any specific issues.  What I do 
to build against a GCC other than the system one is to include the two lines


CC=/path/to/gcc
CXX=/path/to/g++

in autogen.input.

(And if you have any issues building LibreOffice, I guess you would have 
an even worse experience trying to build OpenOffice.  I for one never 
looked back.)

Re: PING 4 [PATCH v2 2/2] add -Wdangling-pointer [PR #63272]

[Stephan Bergmann via Gcc-patches]

On 10/01/2022 22:51, Martin Sebor via Gcc-patches wrote:

Last ping for this stage 1 feature before stage 3 ends:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585819.html


This hits somewhat unexpectedly at (test case reduced from a hit in 
LibreOffice)



$ cat test.cc
#include 
struct S1 {
S1(int);
~S1();
};
struct S2 { S2(std::initializer_list); };
S2 f1();
S2 f2(bool b) { return b ? f1() : S2{0}; }



$ g++ -Wdangling-pointer -c test.cc
test.cc: In function ‘S2 f2(bool)’:
test.cc:8:42: warning: dangling pointer to an unnamed temporary may be used 
[-Wdangling-pointer=]
8 | S2 f2(bool b) { return b ? f1() : S2{0}; }
  |  ^
test.cc:8:39: note: unnamed temporary defined here
8 | S2 f2(bool b) { return b ? f1() : S2{0}; }
  |   ^
test.cc:8:42: warning: dangling pointer to an unnamed temporary may be used 
[-Wdangling-pointer=]
8 | S2 f2(bool b) { return b ? f1() : S2{0}; }
  |  ^
test.cc:8:39: note: unnamed temporary defined here
8 | S2 f2(bool b) { return b ? f1() : S2{0}; }
  |   ^

Re: [PATCH] libstdc++: Implement C++20 atomic and atomic

[Stephan Bergmann via Gcc-patches]

On 1/17/22 01:12, Jonathan Wakely via Libstdc++ wrote:

Here's the finished version of that patch, which is all inline in the
header, and performs faster too.

Tested powerpc64le-linux and x86_64-linux.
Pushed to trunk.


FYI, recent Clang still requires typename in two places to compile 
 with -std=c++20,



diff --git a/libstdc++-v3/include/bits/shared_ptr_atomic.h 
b/libstdc++-v3/include/bits/shared_ptr_atomic.h
index 900499bae32..50aa46370ca 100644
--- a/libstdc++-v3/include/bits/shared_ptr_atomic.h
+++ b/libstdc++-v3/include/bits/shared_ptr_atomic.h
@@ -456,8 +456,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   typename _Tp::element_type* _M_ptr;
   _Atomic_count _M_refcount;
 
-  static _Atomic_count::pointer

-  _S_add_ref(_Atomic_count::pointer __p)
+  static typename _Atomic_count::pointer
+  _S_add_ref(typename _Atomic_count::pointer __p)
   {
if (__p)
  {

Re: [PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

[Stephan Bergmann via Gcc-patches]

On 14/01/2022 14:28, Marek Polacek wrote:

On Fri, Jan 14, 2022 at 10:23:16AM +0100, Stephan Bergmann wrote:

On 30/11/2021 16:27, Marek Polacek wrote:

I guess we were concerned with programs that generate other programs.
Maybe UCNs should be ignored by default.  There's still time to adjust
the behavior.


Is there any update on this?  Shall I file a bug?  As-is, -Wbidi-chars is
unusable for building LibreOffice and (esp. in combination with
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431> "C++ preprocessor
ignores #pragma GCC diagnostic") has to be explicitly disabled globally.


No update, it wasn't clear to me what the action should be here.

Please do file a bug.  I think I'll just have to adjust the warning to ignore
UCNs.


<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104030> "-Wbidi-chars 
should not warn about UCNs"

Re: [PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

[Stephan Bergmann via Gcc-patches]

On 30/11/2021 16:27, Marek Polacek wrote:

I guess we were concerned with programs that generate other programs.
Maybe UCNs should be ignored by default.  There's still time to adjust
the behavior.


Is there any update on this?  Shall I file a bug?  As-is, -Wbidi-chars 
is unusable for building LibreOffice and (esp. in combination with 
 "C++ preprocessor 
ignores #pragma GCC diagnostic") has to be explicitly disabled globally.

Re: [committed] libstdc++: Reduce template instantiations in

[Stephan Bergmann via Gcc-patches]

On 05/01/2022 14:47, Jonathan Wakely via Libstdc++ wrote:

Tested powerpc64le-linux, pushed to trunk.


This moves the last two template parameters of __regex_algo_impl to be
runtime function parameters instead, so that we don't need four
different instantiations for the possible ways to call it. Most of the
function (and what it instantiates) is the same in all cases, so making
them compile-time choices doesn't really have much benefit.

Use  'if constexpr' for conditions that check template parameters, so
that when we do depend on a compile-time condition we only instantiate
what we need to.

libstdc++-v3/ChangeLog:

* include/bits/regex.h (__regex_algo_impl): Change __policy and
__match_mode template parameters to be function parameters.
(regex_match, regex_search): Pass policy and match mode as
function arguments.
* include/bits/regex.tcc (__regex_algo_impl): Change template
parameters to function parameters.
* include/bits/regex_compiler.h (_RegexTranslatorBase): Use
'if constexpr' for conditions using template parameters.
(_RegexTranslator): Likewise.
* include/bits/regex_executor.tcc (_Executor::_M_handle_accept):
Likewise.
* testsuite/util/testsuite_regex.h (regex_match_debug)
(regex_search_debug): Move template arguments to function
arguments.
---
  libstdc++-v3/include/bits/regex.h | 33 +--
  libstdc++-v3/include/bits/regex.tcc   |  8 ++---
  libstdc++-v3/include/bits/regex_compiler.h|  9 ++---
  libstdc++-v3/include/bits/regex_executor.tcc  |  2 +-
  libstdc++-v3/testsuite/util/testsuite_regex.h | 24 +++---
  5 files changed, 37 insertions(+), 39 deletions(-)


Clang now fails #include  with


In file included from 
gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/regex:66:
gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/regex.h:799:9:
 error: unknown type name '_RegexExecutorPolicy'; did you mean 
'__detail::_RegexExecutorPolicy'?
_RegexExecutorPolicy, bool);
^
gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/regex.h:45:14:
 note: '__detail::_RegexExecutorPolicy' declared here
  enum class _RegexExecutorPolicy : int { _S_auto, _S_alternate };
 ^
gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/regex.h:2070:9:
 error: unknown type name '_RegexExecutorPolicy'; did you mean 
'__detail::_RegexExecutorPolicy'?
_RegexExecutorPolicy, bool);
^
gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/regex.h:45:14:
 note: '__detail::_RegexExecutorPolicy' declared here
  enum class _RegexExecutorPolicy : int { _S_auto, _S_alternate };
 ^


and


diff --git a/libstdc++-v3/include/bits/regex.h 
b/libstdc++-v3/include/bits/regex.h
index 7480b0a5f97..46c168010bf 100644
--- a/libstdc++-v3/include/bits/regex.h
+++ b/libstdc++-v3/include/bits/regex.h
@@ -796,7 +796,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
__detail::__regex_algo_impl(_Bp, _Bp, match_results<_Bp, _Ap>&,
const basic_regex<_Cp, _Rp>&,
regex_constants::match_flag_type,
-   _RegexExecutorPolicy, bool);
+   __detail::_RegexExecutorPolicy, bool);
 
   template

friend class __detail::_Executor;
@@ -2067,7 +2067,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
__detail::__regex_algo_impl(_Bp, _Bp, match_results<_Bp, _Ap>&,
const basic_regex<_Cp, _Rp>&,
regex_constants::match_flag_type,
-   _RegexExecutorPolicy, bool);
+   __detail::_RegexExecutorPolicy, bool);
 
   // Reset contents to __size unmatched sub_match objects

   // (plus additional objects for prefix, suffix and unmatched sub).


would fix that.

Re: [PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

[Stephan Bergmann via Gcc-patches]

On 30/11/2021 14:26, Marek Polacek wrote:

On Tue, Nov 30, 2021 at 09:38:57AM +0100, Stephan Bergmann wrote:

On 15/11/2021 18:28, Marek Polacek via Gcc-patches wrote:

On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote:

Ping, can we conclude on the name?   IMHO, -Wbidirectional is just fine,
but changing the name is a trivial operation.


Here's a patch with a better name (suggested by Jonathan W.).  Otherwise no
changes.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
  From a link below:
"An issue was discovered in the Bidirectional Algorithm in the Unicode
Specification through 14.0. It permits the visual reordering of
characters via control sequences, which can be used to craft source code
that renders different logic than the logical ordering of tokens
ingested by compilers and interpreters. Adversaries can leverage this to
encode source code for compilers accepting Unicode such that targeted
vulnerabilities are introduced invisibly to human reviewers."

More info:
https://nvd.nist.gov/vuln/detail/CVE-2021-42574
https://trojansource.codes/

This is not a compiler bug.  However, to mitigate the problem, this patch
implements -Wbidi-chars=[none|unpaired|any] to warn about possibly
misleading Unicode bidirectional characters the preprocessor may encounter.

The default is =unpaired, which warns about improperly terminated
bidirectional characters; e.g. a LRE without its appertaining PDF.  The
level =any warns about any use of bidirectional characters.

This patch handles both UCNs and UTF-8 characters.  UCNs designating
bidi characters in identifiers are accepted since r204886.  Then r217144
enabled -fextended-identifiers by default.  Extended characters in C/C++
identifiers have been accepted since r275979.  However, this patch still
warns about mixing UTF-8 and UCN bidi characters; there seems to be no
good reason to allow mixing them.


I wonder what the rationale is to warn about UCNs, like in


 aText = u"\u202D" + aText;


(as found in the LibreOffice source code).


Is this line mixing a UCN and a UTF-8?  Or is it just that you're
prepending a LRO to aText?  We warn because the LRO is not "closed"
in the context of its string literal, which was part of the Trojan
source attack.  So "\u202D ... \u202C" would not warn.

I'm not sure what workaround I could offer.  Maybe provide an option not to
warn about UCNs at all, though even that is potentially dangerous -- while
you can see UCNs in the source code, if you print strings containing them,
they won't be visible anymore.


I'm not sure what you mean with "mixing a UCN and a UTF-8", but what the 
code apparently does is programmatically constructing a larger piece of 
text by prepending LRO to an existing piece of text.


My understanding is that Trojan Source is concerned with presentation of 
program source code and not with properties of Unicode text constructed 
during the execution of such a program, and from the documentation 
quoted above I understand that -Wbidi-chars is meant to address Trojan 
Source, so I don't understand why you're concerned here with what 
happens "if you print strings containing [UCNs in the source code]".


Short of a source code viewer that interprets UCNs in C/C++ source code 
and renders them in the same way as their corresponding Unicode 
characters, I don't think that UCNs are relevant for Trojan Source, and 
don't understand why -Wbidi-chars would warn about them.


(Also, I noticed that it doesn't work to silence -Werror=bidi-chars= with a


#pragma GCC diagnostic ignored "-Wbidi-chars"


?)

Re: [PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]

[Stephan Bergmann via Gcc-patches]

On 15/11/2021 18:28, Marek Polacek via Gcc-patches wrote:

On Mon, Nov 08, 2021 at 04:33:43PM -0500, Marek Polacek wrote:

Ping, can we conclude on the name?   IMHO, -Wbidirectional is just fine,
but changing the name is a trivial operation.


Here's a patch with a better name (suggested by Jonathan W.).  Otherwise no
changes.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
 From a link below:
"An issue was discovered in the Bidirectional Algorithm in the Unicode
Specification through 14.0. It permits the visual reordering of
characters via control sequences, which can be used to craft source code
that renders different logic than the logical ordering of tokens
ingested by compilers and interpreters. Adversaries can leverage this to
encode source code for compilers accepting Unicode such that targeted
vulnerabilities are introduced invisibly to human reviewers."

More info:
https://nvd.nist.gov/vuln/detail/CVE-2021-42574
https://trojansource.codes/

This is not a compiler bug.  However, to mitigate the problem, this patch
implements -Wbidi-chars=[none|unpaired|any] to warn about possibly
misleading Unicode bidirectional characters the preprocessor may encounter.

The default is =unpaired, which warns about improperly terminated
bidirectional characters; e.g. a LRE without its appertaining PDF.  The
level =any warns about any use of bidirectional characters.

This patch handles both UCNs and UTF-8 characters.  UCNs designating
bidi characters in identifiers are accepted since r204886.  Then r217144
enabled -fextended-identifiers by default.  Extended characters in C/C++
identifiers have been accepted since r275979.  However, this patch still
warns about mixing UTF-8 and UCN bidi characters; there seems to be no
good reason to allow mixing them.


I wonder what the rationale is to warn about UCNs, like in


aText = u"\u202D" + aText;


(as found in the LibreOffice source code).


We warn in different contexts: comments (both C and C++-style), string
literals, character constants, and identifiers.  Expectedly, UCNs are ignored
in comments and raw string literals.  The bidirectional characters can nest
so this patch handles that as well.

I have not included nor tested this at all with Fortran (which also has
string literals and line comments).

Dave M. posted patches improving diagnostic involving Unicode characters.
This patch does not make use of this new infrastructure yet.

PR preprocessor/103026

[...]

std::basic_string<_Tp> constructor point of instantiation woes?

[Stephan Bergmann via Gcc-patches]

When using recent libstc++ trunk with Clang in C++20 mode, 
std::u16string literals as in



#include 
int main() {
  using namespace std::literals;
  u""s;
}


started to cause linker failures due to undefined


_ZNSt7__cxx1112basic_stringIDsSt11char_traitsIDsESaIDsEE12_M_constructIPKDsEEvT_S8_St20forward_iterator_tag


After some head scratching, I found the more insightful


$ cat test.cc
#include 
constexpr std::string s("", 0);



$ clang++ -std=c++20 -fsyntax-only test.cc
test.cc:2:23: error: constexpr variable 's' must be initialized by a constant 
expression
constexpr std::string s("", 0);
  ^~~~
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/basic_string.h:620:2:
 note: undefined function '_M_construct' cannot be used in a 
constant expression
_M_construct(__s, __s + __n, std::forward_iterator_tag());
^
test.cc:2:23: note: in call to 'basic_string(&""[0], 0, std::allocator())'
constexpr std::string s("", 0);
  ^
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/basic_string.h:331:9:
 note: declared here
_M_construct(_FwdIterator __beg, _FwdIterator __end,
^
1 error generated.


and after some more head scratching found Clang to complain about the 
reduced



template struct S {
constexpr void f();
constexpr S() { f(); };
};
S s1;
template constexpr void S::f() {}
constexpr S s2;


(about which GCC does not complain).  Not entirely sure who is right, 
but what would help Clang is to move the definitions of the literal 
operators in basic_string.h (which implicitly instantiate the 
corresponding std::basic_string<_Tp> constructor) past the definition of 
_M_construct (which is called from the constructor) in basic_string.tcc; 
something like



diff --git a/libstdc++-v3/include/bits/basic_string.h 
b/libstdc++-v3/include/bits/basic_string.h
index 6e7de738308..871ca89e16e 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -4304,55 +4304,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 struct __is_fast_hash> : std::false_type
 { };
 
-#if __cplusplus >= 201402L

-
-#define __cpp_lib_string_udls 201304
-
-  inline namespace literals
-  {
-  inline namespace string_literals
-  {
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wliteral-suffix"
-
-#if __cpp_lib_constexpr_string >= 201907L
-# define _GLIBCXX_STRING_CONSTEXPR constexpr
-#else
-# define _GLIBCXX_STRING_CONSTEXPR
-#endif
-
-_GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
-inline basic_string
-operator""s(const char* __str, size_t __len)
-{ return basic_string{__str, __len}; }
-
-_GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
-inline basic_string
-operator""s(const wchar_t* __str, size_t __len)
-{ return basic_string{__str, __len}; }
-
-#ifdef _GLIBCXX_USE_CHAR8_T
-_GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
-inline basic_string
-operator""s(const char8_t* __str, size_t __len)
-{ return basic_string{__str, __len}; }
-#endif
-
-_GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
-inline basic_string
-operator""s(const char16_t* __str, size_t __len)
-{ return basic_string{__str, __len}; }
-
-_GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
-inline basic_string
-operator""s(const char32_t* __str, size_t __len)
-{ return basic_string{__str, __len}; }
-
-#undef _GLIBCXX_STRING_CONSTEXPR
-#pragma GCC diagnostic pop
-  } // inline namespace string_literals
-  } // inline namespace literals
-
 #if __cplusplus >= 201703L
   namespace __detail::__variant
   {
@@ -4369,7 +4320,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { };
   }  // namespace __detail::__variant
 #endif // C++17
-#endif // C++14
 
 _GLIBCXX_END_NAMESPACE_VERSION

 } // namespace std
diff --git a/libstdc++-v3/include/bits/basic_string.tcc 
b/libstdc++-v3/include/bits/basic_string.tcc
index 6f619a08f70..2fd607ef50a 100644
--- a/libstdc++-v3/include/bits/basic_string.tcc
+++ b/libstdc++-v3/include/bits/basic_string.tcc
@@ -1123,6 +1123,57 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif // _GLIBCXX_USE_WCHAR_T
 #endif // _GLIBCXX_EXTERN_TEMPLATE
 
+#if __cplusplus >= 201402L

+
+#define __cpp_lib_string_udls 201304
+
+  inline namespace literals
+  {
+  inline namespace string_literals
+  {
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wliteral-suffix"
+
+#if __cpp_lib_constexpr_string >= 201907L
+# define _GLIBCXX_STRING_CONSTEXPR constexpr
+#else
+# define _GLIBCXX_STRING_CONSTEXPR
+#endif
+
+_GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
+inline basic_string
+operator""s(const char* __str, size_t __len)
+{ return basic_string{__str, __len}; }
+
+_GLIBCXX_DEFAULT_ABI_TAG _GLIBCXX_STRING_CONSTEXPR
+inline basic_string
+operator""s(const wchar_t* __str, size_t __len)
+{ return basic_string{__str, __len}; }
+
+#ifdef _GLIBCX

Re: trunk -D_GLIBCXX_DEBUG #include fails

[Stephan Bergmann via Gcc-patches]

On 09/08/2021 16:42, Jonathan Wakely via Gcc-patches wrote:

This is what I'm testing.


Thanks, that worked fine for my build of LibreOffice.

trunk -D_GLIBCXX_DEBUG #include fails

[Stephan Bergmann via Gcc-patches]

Not sure why I started to experience this now with a recent 
GCC/libstdc++ trunk build:



$ cat test.cc
#include 



$ gcc/trunk/inst/bin/g++ -D_GLIBCXX_DEBUG -fsyntax-only test.cc
In file included from 
/home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.h:401,
 from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/regex:60,
 from test.cc:1:
/home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.tcc: In member 
function ‘std::__detail::_StateSeq<_TraitsT> 
std::__detail::_StateSeq<_TraitsT>::_M_clone()’:
/home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_automaton.tcc:197:12:
 error: ‘map’ is not a member of ‘std’
  197 |   std::map<_StateIdT, _StateIdT> __m;
  |^~~

[...]

In file included from /home/sbergman/gcc/trunk/inst/include/c++/12.0.0/regex:62,
 from test.cc:1:
/home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_compiler.h: At 
global scope:
/home/sbergman/gcc/trunk/inst/include/c++/12.0.0/bits/regex_compiler.h:541:12: 
error: ‘vector’ in namespace ‘std’ does not name a template type
  541 |   std::vector<_CharT>   _M_char_set;
  |^~

[...]

where neither the use of std::map in bits/regex_automaton.tcc nor the 
use of std::vector in bits/regex_compiler.h are in _GLIBCXX_DEBUG-only 
code (but compiling without -D_GLIBCXX_DEBUG succeeded).


Anyway, what would apparently fix it for me is


diff --git a/libstdc++-v3/include/std/regex b/libstdc++-v3/include/std/regex
index 04fb8b2d971..29fd2956fd0 100644
--- a/libstdc++-v3/include/std/regex
+++ b/libstdc++-v3/include/std/regex
@@ -42,6 +42,11 @@
 #include 
 #include 
 
+#if defined _GLIBCXX_DEBUG

+#include 
+#include 
+#endif
+
 #include 
 #include 
 #include 

Re: [committed] libstdc++: Use __libc_single_threaded for locale initialization

[Stephan Bergmann via Gcc-patches]

On 24/11/2020 15:59, Jonathan Wakely via Gcc-patches wrote:

Most initialization of locales and facets happens before main() during
startup, when the program is likely to only have one thread. By using
the new __gnu_cxx::__is_single_threaded() function instead of checking
__gthread_active_p() we can avoid using pthread_once or atomics for the
common case.

That said, I'm not sure why we don't just use a local static variable
instead, as __cxa_guard_acquire() already optimizes for the
single-threaded case:

   static const bool init = (_S_initialize_once(), true);

I'll revisit that for GCC 12.

libstdc++-v3/ChangeLog:

* src/c++98/locale.cc (locale::facet::_S_get_c_locale())
(locale::id::_M_id() const): Use __is_single_threaded.
* src/c++98/locale_init.cc (locale::_S_initialize()):
Likewise.

Tested powerpc64le-linux. Committed to trunk.


I now started to get weird crashes when running LibreOffice test code at 
least with Clang -fsanitize=address and latest libstdc++, where the 
Clang ASan machinery SEGVs while it wants to report some malloc/free 
issue.  That goes away when reverting this commit, and I think the root 
cause is that locale::facet::_S_initialize_once() now gets called twice: 
 First during __cxx_global_var_init when the process is still single 
threaded (so


  if (!__gnu_cxx::__is_single_threaded())

in locale::facet::_S_get_c_locale, reading __libc_single_threaded, is 
false, whereas


  if (__gthread_active_p())

would have been true even if the process still only had a single 
thread).  And again after the process has spawned further threads via 
pthread_create (flipping __libc_single_threaded) and calls 
std::ostringstream() -> ... std::locale() -> ..., at which point


  if (!__gnu_cxx::__is_single_threaded())

in locale::facet::_S_get_c_locale is true now.

Re: [PATCH] libstdc++: Add C++2a synchronization support

[Stephan Bergmann via Gcc-patches]

On 20/11/2020 23:44, Thomas Rodgers wrote:

Tested x86_64-pc-linux-gnu, committed.


...and there are multiple definition complaints from the linker because 
of two missing "include":



index 7b2682a577e..23ab2018ca8 100644
--- a/libstdc++-v3/include/bits/atomic_wait.h
+++ b/libstdc++-v3/include/bits/atomic_wait.h
@@ -223,7 +223,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { _M_w._M_do_wait(_M_version); }
 };
 
-void

+inline void
 __thread_relax() noexcept
 {
 #if defined __i386__ || defined __x86_64__
@@ -233,7 +233,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif
 }
 
-void

+inline void
 __thread_yield() noexcept
{
 #if defined _GLIBCXX_USE_SCHED_YIELD

Re: [PATCH] libstdc++: Add C++2a synchronization support

[Stephan Bergmann via Gcc-patches]

On 20/11/2020 23:44, Thomas Rodgers wrote:

Tested x86_64-pc-linux-gnu, committed.


Clang complains:


$ cat test.cc
#include 

$ clang++ --gcc-toolchain=~/gcc/trunk/inst -std=c++20 -fsyntax-only test.cc
In file included from test.cc:1:
In file included from 
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/semaphore:36:
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/semaphore_base.h:145:22:
 error: no viable conversion from 'std::chrono::system_clock::time_point' (aka 
'time_point>>') 
to 'const std::__platform_semaphore::__clock_t' (aka 'const std::chrono::system_clock')
const __clock_t __s_entry = __clock_t::now();
^   
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/chrono:1101:12: 
note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 
'std::chrono::system_clock::time_point' (aka 'time_point>>') to 'const std::chrono::system_clock &' for 
1st argument
struct system_clock
   ^
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/chrono:1101:12: note: 
candidate constructor (the implicit move constructor) not viable: no known conversion from 
'std::chrono::system_clock::time_point' (aka 'time_point>>') to 'std::chrono::system_clock &&' for 1st argument
1 error generated.


which


diff --git a/libstdc++-v3/include/bits/semaphore_base.h 
b/libstdc++-v3/include/bits/semaphore_base.h
index 78a0b6ba26e..f25c9fdb325 100644
--- a/libstdc++-v3/include/bits/semaphore_base.h
+++ b/libstdc++-v3/include/bits/semaphore_base.h
@@ -142,7 +142,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
else
  {
const typename _Clock::time_point __c_entry = _Clock::now();
-   const __clock_t __s_entry = __clock_t::now();
+   const __clock_t::time_point __s_entry = __clock_t::now();
const auto __delta = __atime - __c_entry;
const auto __s_atime = __s_entry + __delta;
if (_M_try_acquire_until_impl(__s_atime))
~


would fix.

Re: [PATCH] libstdc++: Implement C++20 features for

[Stephan Bergmann via Gcc-patches]

On 07/10/2020 18:55, Thomas Rodgers wrote:

From: Thomas Rodgers 

New ctors and ::view() accessor for -
   * basic_stingbuf
   * basic_istringstream
   * basic_ostringstream
   * basic_stringstreamm

New ::get_allocator() accessor for basic_stringbuf.
I found that this 
 
"libstdc++: Implement C++20 features for " changed the behavior of



$ cat test.cc
#include 
#include 
#include 
int main() {
  std::stringstream s("a");
  std::istreambuf_iterator i(s);
  if (i != std::istreambuf_iterator()) std::cout << *i << '\n';
}

$ g++ -std=c++20 test.cc
$ ./a.out


from printing "a" to printing nothing.  (The `i != ...` comparison 
appears to change i from pointing at "a" to pointing to null, and 
returns false.)


I ran into this when building LibreOffice, and I hope test.cc is a 
faithfully minimized reproducer.  However, I know little about 
std::istreambuf_iterator, so it may well be that the code isn't even valid.

Re: [committed] libstdc++: Allow Lemire's algorithm to be used in more cases

[Stephan Bergmann via Gcc-patches]

On 03/11/2020 23:25, Jonathan Wakely wrote:

On 03/11/20 22:28 +0100, Stephan Bergmann via Libstdc++ wrote:

On 29/10/2020 15:59, Jonathan Wakely via Gcc-patches wrote:

This extends the fast path to also work when the URBG's range of
possible values is not the entire range of its result_type. Previously,
the slow path would be used for engines with a uint_fast32_t result type
if that type is actually a typedef for uint64_t rather than uint32_t.
After this change, the generator's result_type is not important, only
the range of possible value that generator can produce. If the
generator's range is exactly UINT64_MAX then the calculation will be
done using 128-bit and 64-bit integers, and if the range is UINT32_MAX
it will be done using 64-bit and 32-bit integers.

In practice, this benefits most of the engines and engine adaptors
defined in [rand.predef] on x86_64-linux and other 64-bit targets. This
is because std::minstd_rand0 and std::mt19937 and others use
uint_fast32_t, which is a typedef for uint64_t.

The code now makes use of the recently-clarified requirement that the
generator's min() and max() functions are usable in constant
expressions (see LWG 2154).

libstdc++-v3/ChangeLog:

* include/bits/uniform_int_dist.h (_Power_of_two): Add
constexpr.
(uniform_int_distribution::_S_nd): Add static_assert to ensure
the wider type is twice as wide as the result type.
(uniform_int_distribution::__generate_impl): Add static_assert
and declare variables as constexpr where appropriate.
(uniform_int_distribution:operator()): Likewise. Only consider
the uniform random bit generator's range of possible results
when deciding whether _S_nd can be used, not the __uctype type.

Tested x86_64-linux. Committed to trunk.


At least with recent Clang trunk, this causes e.g.


$ cat test.cc
#include 
void f(std::default_random_engine e) { 
std::uniform_int_distribution{0, 1}(e); }


to fail with

$ clang++ --gcc-toolchain=~/gcc/trunk/inst -std=c++17 -fsyntax-only 
test.cc

In file included from test.cc:1:
In file included from 
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/random:40: 

In file included from 
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/string:52: 

In file included from 
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/stl_algo.h:66: 

~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/uniform_int_dist.h:281:17: 
error: static_assert expression is not an integral constant expression

   static_assert( __urng.min() < __urng.max(),
  ^~~
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/uniform_int_dist.h:190:24: 
note: in instantiation of function template specialization 
'std::uniform_int_distribution::operator()long, 16807, 0, 2147483647>>' requested here

   { return this->operator()(__urng, _M_param); }
  ^
test.cc:2:80: note: in instantiation of function template 
specialization 
'std::uniform_int_distribution::operator()long, 16807, 0, 2147483647>>' requested here
void f(std::default_random_engine e) { 
std::uniform_int_distribution{0, 1}(e); }
  
^
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/uniform_int_dist.h:281:17: 
note: function parameter '__urng' with unknown value cannot be used 
in a constant expression

   static_assert( __urng.min() < __urng.max(),
  ^
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/uniform_int_dist.h:194:41: 
note: declared here

   operator()(_UniformRandomBitGenerator& __urng,
  ^
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/uniform_int_dist.h:284:21: 
error: constexpr variable '__urngmin' must be initialized by a 
constant expression

   constexpr __uctype __urngmin = __urng.min();
  ^   
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/uniform_int_dist.h:284:33: 
note: function parameter '__urng' with unknown value cannot be used 
in a constant expression

   constexpr __uctype __urngmin = __urng.min();
  ^
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/uniform_int_dist.h:194:41: 
note: declared here

   operator()(_UniformRandomBitGenerator& __urng,
  ^
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/uniform_int_dist.h:285:21: 
error: constexpr

Re: [committed] libstdc++: Allow Lemire's algorithm to be used in more cases

[Stephan Bergmann via Gcc-patches]

On 29/10/2020 15:59, Jonathan Wakely via Gcc-patches wrote:

This extends the fast path to also work when the URBG's range of
possible values is not the entire range of its result_type. Previously,
the slow path would be used for engines with a uint_fast32_t result type
if that type is actually a typedef for uint64_t rather than uint32_t.
After this change, the generator's result_type is not important, only
the range of possible value that generator can produce. If the
generator's range is exactly UINT64_MAX then the calculation will be
done using 128-bit and 64-bit integers, and if the range is UINT32_MAX
it will be done using 64-bit and 32-bit integers.

In practice, this benefits most of the engines and engine adaptors
defined in [rand.predef] on x86_64-linux and other 64-bit targets. This
is because std::minstd_rand0 and std::mt19937 and others use
uint_fast32_t, which is a typedef for uint64_t.

The code now makes use of the recently-clarified requirement that the
generator's min() and max() functions are usable in constant
expressions (see LWG 2154).

libstdc++-v3/ChangeLog:

* include/bits/uniform_int_dist.h (_Power_of_two): Add
constexpr.
(uniform_int_distribution::_S_nd): Add static_assert to ensure
the wider type is twice as wide as the result type.
(uniform_int_distribution::__generate_impl): Add static_assert
and declare variables as constexpr where appropriate.
(uniform_int_distribution:operator()): Likewise. Only consider
the uniform random bit generator's range of possible results
when deciding whether _S_nd can be used, not the __uctype type.

Tested x86_64-linux. Committed to trunk.


At least with recent Clang trunk, this causes e.g.


$ cat test.cc
#include 
void f(std::default_random_engine e) { std::uniform_int_distribution{0, 
1}(e); }


to fail with


$ clang++ --gcc-toolchain=~/gcc/trunk/inst -std=c++17 -fsyntax-only test.cc
In file included from test.cc:1:
In file included from 
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/random:40:
In file included from 
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/string:52:
In file included from 
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/stl_algo.h:66:
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/uniform_int_dist.h:281:17:
 error: static_assert expression is not an integral constant expression
static_assert( __urng.min() < __urng.max(),
   ^~~
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/uniform_int_dist.h:190:24:
 note: in instantiation of function template specialization 
'std::uniform_int_distribution::operator()>' requested here
{ return this->operator()(__urng, _M_param); }
   ^
test.cc:2:80: note: in instantiation of function template specialization 
'std::uniform_int_distribution::operator()>' requested here
void f(std::default_random_engine e) { std::uniform_int_distribution{0, 
1}(e); }
   ^
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/uniform_int_dist.h:281:17:
 note: function parameter '__urng' with unknown value cannot be used in a 
constant expression
static_assert( __urng.min() < __urng.max(),
   ^
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/uniform_int_dist.h:194:41:
 note: declared here
operator()(_UniformRandomBitGenerator& __urng,
   ^
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/uniform_int_dist.h:284:21:
 error: constexpr variable '__urngmin' must be initialized by a constant 
expression
constexpr __uctype __urngmin = __urng.min();
   ^   
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/uniform_int_dist.h:284:33:
 note: function parameter '__urng' with unknown value cannot be used in a 
constant expression
constexpr __uctype __urngmin = __urng.min();
   ^
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/uniform_int_dist.h:194:41:
 note: declared here
operator()(_UniformRandomBitGenerator& __urng,
   ^
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/uniform_int_dist.h:285:21:
 error: constexpr variable '__urngmax' must be initialized by a constant 
expression
constexpr __uctype __urngmax = __urng.max();
   ^   
~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../incl

Re: [committed] libstdc++: Simplify std::shared_ptr construction from std::weak_ptr

[Stephan Bergmann via Gcc-patches]

On 21/10/2020 22:14, Jonathan Wakely via Gcc-patches wrote:

The _M_add_ref_lock() and _M_add_ref_lock_nothrow() members of
_Sp_counted_base are very similar, except that the former throws an
exception when the use count is zero and the latter returns false. The
former (and its callers) can be implemented in terms of the latter.
This results in a small reduction in code size, because throwing an
exception now only happens in one place.

libstdc++-v3/ChangeLog:

* include/bits/shared_ptr.h (shared_ptr(const weak_ptr&, nothrow_t)):
Add noexcept.
* include/bits/shared_ptr_base.h (_Sp_counted_base::_M_add_ref_lock):
Remove specializations and just call _M_add_ref_lock_nothrow.
(__shared_count, __shared_ptr): Use nullptr for null pointer
constants.
(__shared_count(const __weak_count&)): Use _M_add_ref_lock_nothrow
instead of _M_add_ref_lock.
(__shared_count(const __weak_count&, nothrow_t)): Add noexcept.
(__shared_ptr::operator bool()): Add noexcept.
(__shared_ptr(const __weak_ptr&, nothrow_t)): Add noexcept.

Tested powerpc64le-linux. Committed to trunk.


Clang now complains about


~gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/shared_ptr_base.h:230:5:
 error: '_M_add_ref_lock_nothrow' is missing exception specification 'noexcept'
_M_add_ref_lock_nothrow()
^
~gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/shared_ptr_base.h:158:7:
 note: previous declaration is here
  _M_add_ref_lock_nothrow() noexcept;
  ^
~gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/shared_ptr_base.h:241:5:
 error: '_M_add_ref_lock_nothrow' is missing exception specification 'noexcept'
_M_add_ref_lock_nothrow()
^
~gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/shared_ptr_base.h:158:7:
 note: previous declaration is here
  _M_add_ref_lock_nothrow() noexcept;
  ^
~gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/shared_ptr_base.h:255:5:
 error: '_M_add_ref_lock_nothrow' is missing exception specification 'noexcept'
_M_add_ref_lock_nothrow()
^
~gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/shared_ptr_base.h:158:7:
 note: previous declaration is here
  _M_add_ref_lock_nothrow() noexcept;
  ^
~gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/shared_ptr_base.h:876:5:
 error: exception specification in declaration does not match previous 
declaration
__shared_count(const __weak_count<_Lp>& __r, std::nothrow_t) noexcept
^
~gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../include/c++/11.0.0/bits/shared_ptr_base.h:696:16:
 note: previous declaration is here
  explicit __shared_count(const __weak_count<_Lp>& __r, std::nothrow_t);
   ^
4 errors generated.


which would be fixed with


diff --git a/libstdc++-v3/include/bits/shared_ptr_base.h 
b/libstdc++-v3/include/bits/shared_ptr_base.h
index a9e1c9bb1d5..10c9c831411 100644
--- a/libstdc++-v3/include/bits/shared_ptr_base.h
+++ b/libstdc++-v3/include/bits/shared_ptr_base.h
@@ -227,7 +227,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template<>
 inline bool
 _Sp_counted_base<_S_single>::
-_M_add_ref_lock_nothrow()
+_M_add_ref_lock_nothrow() noexcept
 {
   if (_M_use_count == 0)
return false;
@@ -238,7 +238,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template<>
 inline bool
 _Sp_counted_base<_S_mutex>::
-_M_add_ref_lock_nothrow()
+_M_add_ref_lock_nothrow() noexcept
 {
   __gnu_cxx::__scoped_lock sentry(*this);
   if (__gnu_cxx::__exchange_and_add_dispatch(&_M_use_count, 1) == 0)
@@ -252,7 +252,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template<>
 inline bool
 _Sp_counted_base<_S_atomic>::
-_M_add_ref_lock_nothrow()
+_M_add_ref_lock_nothrow() noexcept
 {
   // Perform lock-free add-if-not-zero operation.
   _Atomic_word __count = _M_get_use_count();
@@ -693,7 +693,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   explicit __shared_count(const __weak_count<_Lp>& __r);
 
   // Does not throw if __r._M_get_use_count() == 0, caller must check.

-  explicit __shared_count(const __weak_count<_Lp>& __r, std::nothrow_t);
+  explicit __shared_count(const __weak_count<_Lp>& __r, std::nothrow_t) 
noexcept;
 
   ~__shared_count() noexcept

   {

Re: [PATCH] libstdc++: Diagnose visitors with different return types [PR95904]

[Stephan Bergmann via Gcc-patches]

On 08/10/2020 16:27, Jonathan Wakely via Gcc-patches wrote:

On 05/10/20 22:35 +0300, Ville Voutilainen via Libstdc++ wrote:

On Mon, 5 Oct 2020 at 01:15, Ville Voutilainen
 wrote:

The patch is borked, doesn't pass tests, fixing...


Unborked, ok for trunk if full testsuite passes?


Assuming it has passed by now, OK. Thanks.


Clang (with -std=c++17/20) now complains about


include/c++/11.0.0/variant:1032:10: error: no matching constructor for 
initialization of 'std::__nonesuch'
return __nonesuch{};
   ^ ~~
include/c++/11.0.0/type_traits:2953:5: note: candidate constructor not viable: 
requires 1 argument, but 0 were provided
__nonesuch(__nonesuch const&) = delete;
^


upon #include .  (And I think legitimately so, as __nonsuch is 
not dependent?)

Re: [PATCH] c++: Fix up default initialization with consteval default ctor [PR96994]

[Stephan Bergmann via Gcc-patches]

On 15/09/2020 09:57, Jakub Jelinek via Gcc-patches wrote:

The following testcase is miscompiled (in particular the a and i
initialization).  The problem is that build_special_member_call due to
the immediate constructors (but not evaluated in constant expression mode)
doesn't create a CALL_EXPR, but returns a TARGET_EXPR with CONSTRUCTOR
as the initializer for it, and then expand_default_init just emits
the returned statement, but this one doesn't have any side-effects and does
nothing.  There is an if to handle constexpr ctors which emits an INIT_EXPR
but constexpr ctors still show up as CALL_EXPR and need to be manually
evaluated to constant expressions (if possible).

The following patch fixes that, though I'm not sure about several things.
One is that the earlier if also has expr == true_exp && in the condition,
not sure if we want it in this case or not.
Another is that for delegating constructors, we emit two separate calls
and build_if_in_charge them together.  Not sure if consteval could come into
play in that case.


(Just reporting that with this patch applied, my build of LibreOffice 
using consteval, cf. 
 
"Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", 
works fine.)

Re: [PATCH] libstdc++: P0769R2 Add shift to

[Stephan Bergmann]

On 21/02/2020 20:29, Patrick Palka wrote:

diff --git a/libstdc++-v3/include/bits/ranges_algo.h 
b/libstdc++-v3/include/bits/ranges_algo.h
index 7de1072abf0..c36afc6e19b 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -3683,6 +3683,54 @@ namespace ranges
inline constexpr __prev_permutation_fn prev_permutation{};
  
  } // namespace ranges

+
+  template
+constexpr ForwardIterator
+shift_left(ForwardIterator __first, ForwardIterator __last,
+  typename iterator_traits::difference_type __n)
+{
+  __glibcxx_assert(__n >= 0);
+  if (__n == 0)
+   return __last;
+
+  auto __mid = ranges::next(__first, __n, __last);
+  if (__mid == __last)
+   return __first;
+  return std::move(std::move(__mid), std::move(__last), 
std::move(__first));
+}
+
+  template
+constexpr ForwardIterator
+shift_right(ForwardIterator __first, ForwardIterator __last,
+   typename iterator_traits::difference_type __n)
+{
+  __glibcxx_assert(__n >= 0);
+  if (__n == 0)
+   return __first;
+
+  using _Cat = iterator_traits::iterator_category;


^ FYI, the above line causes recent Clang 10 trunk with -std=c++20 to 
fail due to a "missing" typedef



+  if constexpr (derived_from<_Cat, bidirectional_iterator_tag>)
+   {
+ auto __mid = ranges::next(__last, -__n, __first);
+ if (__mid == __first)
+   return __last;
+ return std::move_backward(std::move(__first), std::move(__mid),
+   std::move(__last));
+   }
+  else
+   {
+ auto __result = ranges::next(__first, __n, __last);
+ if (__result == __last)
+   return __last;
+ auto __dest = __result;
+ do
+   __dest = ranges::swap_ranges(__first, __result,
+std::move(__dest), __last).in2;
+ while (__dest != __last);
+ return __result;
+   }
+}
+
  _GLIBCXX_END_NAMESPACE_VERSION
  } // namespace std
  #endif // concepts

Re: [PATCH] avoid issuing -Wredundant-tags in shared C/C++ code in headers (PR 93804)

[Stephan Bergmann]

On 19/02/2020 01:02, Martin Sebor wrote:

PR 93804 points out that issuing -Wredundant-tags for declarations
in C headers included in C++ isn't helpful because the tags cannot
be removed without breaking C programs that depend on the headers.

Attached is a patch that avoids the warning in these cases tested
on x86_64-linux.  While strictly not a regression (and even though
I initially considered it a GCC 11 enhancement), since most C++
code includes some C headers, without the patch the warning would
likely cause too much noise to be widely useful.


Warnings about redundant enum tags in shared C/C++ code should likewise 
be suppressed.  Something like the attached patch.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 2c6f5522bf3..fda2a6f3d5c 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -30828,6 +30828,20 @@ cp_parser_maybe_warn_enum_key (cp_parser *parser, location_t key_loc,
  itself.  */
   if (decl == type_decl)
 {
+  if (current_lang_name != lang_name_cplusplus
+  && current_namespace == global_namespace)
+{
+  /* Avoid issuing the diagnostic for apparently redundant struct
+and union class-keys in shared C/C++ code in files (such as
+headers) included in the main source file.  */
+  const line_map_ordinary *map = NULL;
+  linemap_resolve_location (line_table, key_loc,
+   LRK_MACRO_DEFINITION_LOCATION,
+   &map);
+  if (!MAIN_FILE_P (map))
+   return;
+}
+
   gcc_rich_location richloc (key_loc);
   richloc.add_fixit_remove (key_loc);
   warning_at (&richloc, OPT_Wredundant_tags,

Re: [PATCH 3/3] libstdc++: Implement C++20 range adaptors

[Stephan Bergmann]

On 18/02/2020 12:56, Jonathan Wakely wrote:

Does this solve the problem, and work with both compilers?

diff --git a/libstdc++-v3/include/std/ranges 
b/libstdc++-v3/include/std/ranges

index b9ac528fdff..481ba75ee5e 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -1102,6 +1102,9 @@ namespace views
   }
    };

+    template
+  _RangeAdaptor(_Callable) -> _RangeAdaptor<_Callable>;
+
  template
    struct _RangeAdaptorClosure : public _RangeAdaptor<_Callable>
    {


With this deduction guide CTAD should work, without having to consider
the constraints on the constructors.


Yes, that indeed compiles with both GCC and Clang.

Re: [PATCH] add -Wmismatched-tags (PR 61339)

[Stephan Bergmann]

On 03/12/2019 22:49, Martin Sebor wrote:

I added another warning: -Wredundant-tags to point out instances
where the class-key or enum-key can safely be dropped. Both warnings
are off by default.


I think -Wredundant-tags would be more useful if it did not warn about 
occurrences within extern "C" (at least not within included files), as a 
heuristic to filter out code that is shared between C and C++ and where 
the tags are thus necessary.

Re: [PATCH 3/3] libstdc++: Implement C++20 range adaptors

[Stephan Bergmann]

On 18/02/2020 02:20, Patrick Palka wrote:

On Mon, 17 Feb 2020, Stephan Bergmann wrote:

On 04/02/2020 03:07, Patrick Palka wrote:

This patch implements [range.adaptors].  It also includes the changes from
P3280
and P3278 and P3323, without which many standard examples won't work.


I see that with this
<https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commit;h=cba9ef069e58eac00f30489d3ef21390caee6e45>
"libstdc++: Implement C++20 range adaptors", compiling  with recent
Clang trunk (which appears to mostly implement C++20 concepts now) in
-std=c++2a mode fails as below (besides also failing due to some "missing"
typenames, where Clang apparently doesn't yet implement P0634R3).  And I'm not
sure which of Clang vs. GCC is right here.

The failure is


gcc/trunk/inst/include/c++/10.0.1/ranges:1512:47: error: ambiguous deduction
for template arguments of '_RangeAdaptor'
 inline constexpr __adaptor::_RangeAdaptor filter
   ^
gcc/trunk/inst/include/c++/10.0.1/ranges:1073:2: note: candidate function
[with _Callable = std::ranges::views::(lambda at
gcc/trunk/inst/include/c++/10.0.1/ranges:1513:9)]
 _RangeAdaptor(const _Callable& = {})
 ^
gcc/trunk/inst/include/c++/10.0.1/ranges:1078:2: note: candidate function
[with _Callable = std::ranges::views::(lambda at
gcc/trunk/inst/include/c++/10.0.1/ranges:1513:9)]
 _RangeAdaptor(_Callable __callable)
 ^


and a stripped-down reproducer is


template struct S {
   S(T const &) requires true;
   S(T) requires false;
};
S s = 0;


(Clang accepts this when the last line is replaced with


S s = 0;


and thus no class template argument deduction needs to be done.)

I think what is relevant here is [over.match.class.deduct]/1 in the current
spec, which specifies a helper set of hypothetical function templates based on
a class' constructors for class template argument deduction.  It details the
function templates' template parameters, function parameters, and return
types, but does not mention requires-clauses.  From my superficial
understanding of concepts and class template argument deduction it would thus
look like the constructors' requires-clauses should indeed not be taken into
account here?


Thanks for letting me know about this issue.  That would be my
interpretation of the spec, too.  Maybe someone else could shed light on
this question?

The following patch simplifies _RangeAdaptor's constructors to no longer
need to be constrained and should resolve the deduction ambiguity error
reported by Clang?  Unfortunately the patch triggers an ICE in GCC,
which I'll look into tomorrow.


Thanks, I can confirm that patch works fine with Clang.

Btw, the "missing" typenames for Clang I mentioned above would be fixed 
with the following patch.  I don't know whether you would want to do 
that, as technically the current C++20-only code is fine, but here it is 
anyway:



diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 970e904bddd..c487dd612c2 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -1326,7 +1326,7 @@ namespace views
static constexpr auto
_S_iter_cat()
{
- using _Cat = iterator_traits>::iterator_category;
+ using _Cat = typename 
iterator_traits>::iterator_category;
  if constexpr (derived_from<_Cat, bidirectional_iterator_tag>)
return bidirectional_iterator_tag{};
  else if constexpr (derived_from<_Cat, forward_iterator_tag>)
@@ -1549,7 +1549,7 @@ namespace views
  static constexpr auto
  _S_iter_cat()
  {
-   using _Cat = iterator_traits>::iterator_category;
+   using _Cat = typename 
iterator_traits>::iterator_category;
if constexpr (derived_from<_Cat, contiguous_iterator_tag>)
  return random_access_iterator_tag{};
else
@@ -2294,9 +2294,9 @@ namespace views
  _S_iter_cat()
  {
using _OuterCat
- = iterator_traits>::iterator_category;
+ = typename iterator_traits>::iterator_category;
using _InnerCat
- = iterator_traits>>
+ = typename iterator_traits>>
 ::iterator_category;
if constexpr (_S_ref_is_glvalue
  && derived_from<_OuterCat, bidirectional_iterator_tag>
@@ -2765,7 +2765,7 @@ namespace views
  static constexpr auto
  _S_iter_cat()
  {
-   using _Cat = iterator_traits>::iterator_category;
+   using _Cat = typename 
iterator_traits>::iterator_category;
if constexpr (derived_from<_Cat, forward_iterator_tag>)
  return forward_iterator_tag{};
else

Re: [PATCH 3/3] libstdc++: Implement C++20 range adaptors

[Stephan Bergmann]

On 04/02/2020 03:07, Patrick Palka wrote:

This patch implements [range.adaptors].  It also includes the changes from P3280
and P3278 and P3323, without which many standard examples won't work.


I see that with this 
 
"libstdc++: Implement C++20 range adaptors", compiling  with 
recent Clang trunk (which appears to mostly implement C++20 concepts 
now) in -std=c++2a mode fails as below (besides also failing due to some 
"missing" typenames, where Clang apparently doesn't yet implement 
P0634R3).  And I'm not sure which of Clang vs. GCC is right here.


The failure is


gcc/trunk/inst/include/c++/10.0.1/ranges:1512:47: error: ambiguous deduction 
for template arguments of '_RangeAdaptor'
inline constexpr __adaptor::_RangeAdaptor filter
  ^
gcc/trunk/inst/include/c++/10.0.1/ranges:1073:2: note: candidate function [with 
_Callable = std::ranges::views::(lambda at 
gcc/trunk/inst/include/c++/10.0.1/ranges:1513:9)]
_RangeAdaptor(const _Callable& = {})
^
gcc/trunk/inst/include/c++/10.0.1/ranges:1078:2: note: candidate function [with 
_Callable = std::ranges::views::(lambda at 
gcc/trunk/inst/include/c++/10.0.1/ranges:1513:9)]
_RangeAdaptor(_Callable __callable)
^


and a stripped-down reproducer is


template struct S {
  S(T const &) requires true;
  S(T) requires false;
};
S s = 0;


(Clang accepts this when the last line is replaced with


S s = 0;


and thus no class template argument deduction needs to be done.)

I think what is relevant here is [over.match.class.deduct]/1 in the 
current spec, which specifies a helper set of hypothetical function 
templates based on a class' constructors for class template argument 
deduction.  It details the function templates' template parameters, 
function parameters, and return types, but does not mention 
requires-clauses.  From my superficial understanding of concepts and 
class template argument deduction it would thus look like the 
constructors' requires-clauses should indeed not be taken into account here?

Re: [PATCH] libstdc++: Define std::lexicographical_compare_three_way for C++20

[Stephan Bergmann]

On 05/12/2019 13:46, Jonathan Wakely wrote:

commit 5012548fd62526fdf5e04aeacee2b127efbac0e0
Author: Jonathan Wakely 
Date:   Thu Dec 5 12:23:53 2019 +

libstdc++: Define std::lexicographical_compare_three_way for C++20

* include/bits/stl_algobase.h (lexicographical_compare_three_way):

Define for C++20.
* testsuite/25_algorithms/lexicographical_compare_three_way/1.cc: 
New
test.
* testsuite/25_algorithms/lexicographical_compare_three_way/
constexpr.cc: New test.

diff --git a/libstdc++-v3/include/bits/stl_algobase.h 
b/libstdc++-v3/include/bits/stl_algobase.h
index 98d324827ed..a2fd306e6d0 100644
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h

[...]

@@ -1456,6 +1459,104 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
 __gnu_cxx::__ops::__iter_comp_iter(__comp));
 }
 
+#if __cpp_lib_three_way_comparison

+#if __cpp_lib_concepts
+  // Iter points to a contiguous range of unsigned narrow character type
+  // or std::byte, suitable for comparison by memcmp.
+  template
+concept __is_byte_iter = contiguous_iterator<_Iter>
+  && __is_byte>::__value != 0
+  && !__gnu_cxx::__numeric_traits>::__is_signed;
+
+  // Return a struct with two members, initialized to the smaller of x and y
+  // (or x if they compare equal) and the result of the comparison x <=> y.
+  template
+constexpr auto
+__min_cmp(_Tp __x, _Tp __y)
+{
+  struct _Res {
+   _Tp _M_min;
+   decltype(__x <=> __y) _M_cmp;
+  };
+  auto __c = __x <=> __y;
+  if (__c > 0)
+   return _Res{__y, __c};
+  return _Res{__x, __c};
+}
+#endif

[...]

+
+  template
+constexpr auto
+lexicographical_compare_three_way(_InputIter1 __first1,
+ _InputIter1 __last1,
+ _InputIter2 __first2,
+ _InputIter2 __last2)
+{
+  return std::lexicographical_compare_three_way(__first1, __last1,
+   __first2, __last2,
+   compare_three_way{});


FYI, the above fails with -std=c++2a and recent Clang trunk after 
 
"Mark the major papers for C++20 consistent comparisons as 'done', and 
start publishing the corresponding feature-test macro":  Clang now 
defines __cpp_impl_three_way_comparison (so 
libstdc++-v3/include/std/version defines __cpp_lib_three_way_comparison) 
but still doesn't define __cpp_lib_concepts, so 
libstdc++-v3/libsupc++/compare doesn't define compare_three_way.


I locally managed that for now with extending the surrounding

 #if __cpp_lib_three_way_comparison

with

 && __cpp_lib_concepts


+}
+#endif // three_way_comparison

Re: [PATCH][_GLIBCXX_DEBUG] Improve valid_range check

[Stephan Bergmann]

On 26/11/2019 20:07, François Dumont wrote:
However I wasn't sure about this syntax before the commit so I had run 
the new 2_neg.cc with:


make CXXFLAGS=-std=c++98 check-debug

and it worked fine and still is !

I also try -std=gnu++98 and made sure that pch had been updated by 
re-building libstdc++ first. I just can't get the expected compilation 
error.


Maybe I need to rebuild the whole stuff to get an error...


I saw the error with recent Clang and -std=gnu++98.  Recent GCC indeed 
seems to give at most a warning.

Re: [PATCH][_GLIBCXX_DEBUG] Improve valid_range check

[Stephan Bergmann]

On 22/11/2019 18:59, Jonathan Wakely wrote:

On 22/11/19 18:38 +0100, François Dumont wrote:
    I noticed that we are not checking that iterators are not singular 
in valid_range. Moreover __check_singular signature for pointers is 
not intercepting all kind of pointers in terms of qualification.


    I'd like to commit it next week but considering we are in stage 3 
I need proper acceptance.


    * include/debug/functions.h: Remove  include.
    (__check_singular_aux, __check_singular): Move...
    * include/debug/helper_functions.h:
    (__check_singular_aux, __check_singular): ...here.
    (__valid_range_aux): Adapt to use latter.
    * testsuite/25_algorithms/copy/debug/2_neg.cc: New.

Tested under Linux x86_64 normal and debug modes.


OK for trunk, thanks.


The curly braces...


diff --git a/libstdc++-v3/include/debug/helper_functions.h 
b/libstdc++-v3/include/debug/helper_functions.h
index c3e7478f649..5a858754875 100644
--- a/libstdc++-v3/include/debug/helper_functions.h
+++ b/libstdc++-v3/include/debug/helper_functions.h

[...]

@@ -138,14 +156,23 @@ namespace __gnu_debug
 inline bool
 __valid_range_aux(_InputIterator __first, _InputIterator __last,
  std::input_iterator_tag)
-{ return true; }
+{
+  if (__first != __last)
+   return !__check_singular(__first) && !__check_singular(__last);
+
+  return true;
+}
 
   template

 _GLIBCXX_CONSTEXPR
 inline bool
 __valid_range_aux(_InputIterator __first, _InputIterator __last,
  std::random_access_iterator_tag)
-{ return __first <= __last; }
+{
+  return
+   __valid_range_aux(__first, __last, std::input_iterator_tag{})


...^^^ here...


+   && __first <= __last;
+}
 
   /** We have iterators, so figure out what kind of iterators they are

*  to see if we can check the range ahead of time.
@@ -167,6 +194,9 @@ namespace __gnu_debug
  typename _Distance_traits<_InputIterator>::__type& __dist,
  std::__false_type)
 {
+  if (!__valid_range_aux(__first, __last, std::input_iterator_tag{}))


...and ^^^ here are not allowed pre C++11.  Replacing those with

  std::input_iterator_tag()

should fix it.


+   return false;
+
   __dist = __get_distance(__first, __last);
   switch (__dist.second)
{

Re: [PATCH] libstdc++: Define C++20 range utilities and range factories

[Stephan Bergmann]

On 17/11/2019 02:07, Jonathan Wakely wrote:

This adds another chunk of the  header.

The changes from P1456R1 (Move-only views) and P1862R1 (Range adaptors
for non-copyable iterators) are included, but not the changes from
P1870R1 (forwarding-range is too subtle).

The tests for subrange and iota_view are poor and should be improved.


At least with recent Clang trunk, with -std=c++2a this causes failures like


In file included from 
gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/set:61:
gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/stl_set.h:1057:48:
 error: default initialization of an object of const type 'const bool'
  template inline constexpr bool __enable_view_impl;
   ^
In file included from 
gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/set:62:
gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/stl_multiset.h:1045:48:
 error: redefinition of '__enable_view_impl'
  template inline constexpr bool __enable_view_impl;
   ^
gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/stl_set.h:1057:48:
 note: previous definition is here
  template inline constexpr bool __enable_view_impl;
   ^


and I'm not sure whether this is legal C++20 code that Clang is just not 
capable of handling?

Re: [PATCH] PR c++/91369 Implement P0784R7 changes to allocation and construction

[Stephan Bergmann]

On 23/10/2019 21:27, Jonathan Wakely wrote:

This patch is the first part of library support for constexpr
std::vector and std::string. This only includes the changes to
std::allocator, std::allocator_traits, std::construct_at,
std::destroy_at, std::destroy and std::destroy_n.

[...]

Tested x86_64-linux and powerpc64le-linux, for every -std=gnu++NN
mode.


Clang (trunk, at least) with -std=c++11 now complains about some of the 
constexpr (because they return void, or don't have a return statement) 
when including .


What fixed it for me locally:


diff --git a/libstdc++-v3/include/bits/alloc_traits.h 
b/libstdc++-v3/include/bits/alloc_traits.h
index 26d6d26ae48..61d3c1b794b 100644
--- a/libstdc++-v3/include/bits/alloc_traits.h
+++ b/libstdc++-v3/include/bits/alloc_traits.h
@@ -241,13 +241,20 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  = typename __construct_helper<_Tp, _Args...>::type;
 
   template

-   static constexpr _Require<__has_construct<_Tp, _Args...>>
+   static
+#if __cplusplus >= 201402L
+  constexpr
+#endif
+_Require<__has_construct<_Tp, _Args...>>
_S_construct(_Alloc& __a, _Tp* __p, _Args&&... __args)
noexcept(noexcept(__a.construct(__p, std::forward<_Args>(__args)...)))
{ __a.construct(__p, std::forward<_Args>(__args)...); }
 
   template

-   static constexpr
+   static
+#if __cplusplus >= 201402L
+  constexpr
+#endif
_Require<__and_<__not_<__has_construct<_Tp, _Args...>>,
   is_constructible<_Tp, _Args...>>>
_S_construct(_Alloc&, _Tp* __p, _Args&&... __args)
@@ -256,14 +263,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{ std::_Construct(__p, std::forward<_Args>(__args)...); }
 
   template

-   static constexpr auto
+   static
+#if __cplusplus >= 201402L
+  constexpr
+#endif
+auto
_S_destroy(_Alloc2& __a, _Tp* __p, int)
noexcept(noexcept(__a.destroy(__p)))
-> decltype(__a.destroy(__p))
{ __a.destroy(__p); }
 
   template

-   static constexpr void
+   static
+#if __cplusplus >= 201402L
+  constexpr
+#endif
+void
_S_destroy(_Alloc2&, _Tp* __p, ...)
noexcept(noexcept(__p->~_Tp()))
{ std::_Destroy(__p); }
@@ -562,7 +577,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif
 
   template

-constexpr void
+#if __cplusplus >= 201402L
+constexpr
+#endif
+  void
 __alloc_on_copy(_Alloc& __one, const _Alloc& __two)
 {
   typedef allocator_traits<_Alloc> __traits;
@@ -594,7 +612,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif
 
   template

-constexpr void
+#if __cplusplus >= 201402L
+constexpr
+#endif
+  void
 __alloc_on_move(_Alloc& __one, _Alloc& __two)
 {
   typedef allocator_traits<_Alloc> __traits;
@@ -621,7 +642,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif
 
   template

-constexpr void
+#if __cplusplus >= 201402L
+constexpr
+#endif
+  void
 __alloc_on_swap(_Alloc& __one, _Alloc& __two)
 {
   typedef allocator_traits<_Alloc> __traits;
diff --git a/libstdc++-v3/include/bits/stl_construct.h 
b/libstdc++-v3/include/bits/stl_construct.h
index a16196ffe74..ed9b72b7327 100644
--- a/libstdc++-v3/include/bits/stl_construct.h
+++ b/libstdc++-v3/include/bits/stl_construct.h
@@ -137,7 +137,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* Destroy the object pointed to by a pointer type.
*/
   template
-_GLIBCXX_CONSTEXPR inline void
+#if __cplusplus >= 201402L
+_GLIBCXX_CONSTEXPR
+#endif
+   inline void
 _Destroy(_Tp* __pointer)
 {
 #if __cplusplus > 201703L
diff --git a/libstdc++-v3/include/ext/alloc_traits.h 
b/libstdc++-v3/include/ext/alloc_traits.h
index 052d811ec01..ddeda66b57a 100644
--- a/libstdc++-v3/include/ext/alloc_traits.h
+++ b/libstdc++-v3/include/ext/alloc_traits.h
@@ -76,7 +76,11 @@ template
   public:
 // overload construct for non-standard pointer types
 template
-  static constexpr std::__enable_if_t<__is_custom_pointer<_Ptr>::value>
+  static
+#if __cplusplus >= 201402L
+ constexpr
+#endif
+   std::__enable_if_t<__is_custom_pointer<_Ptr>::value>
   construct(_Alloc& __a, _Ptr __p, _Args&&... __args)
   noexcept(noexcept(_Base_type::construct(__a, std::__to_address(__p),
  std::forward<_Args>(__args)...)))
@@ -87,7 +91,11 @@ template
 
 // overload destroy for non-standard pointer types

 template
-  static constexpr std::__enable_if_t<__is_custom_pointer<_Ptr>::value>
+  static
+#if __cplusplus >= 201402L
+ constexpr
+#endif
+   std::__enable_if_t<__is_custom_pointer<_Ptr>::value>
   destroy(_Alloc& __a, _Ptr __p)
   noexcept(noexcept(_Base_type::destroy(__a, std::__to_address(__p
   { _Base_type::destroy(__

[WIP PATCH] PR71102: Make #pragma GCC error/warning concat strings

[Stephan Bergmann]

(I think this is my first patch submission here, so please bear with me.)

As discussed at  
"_Pragma("GCC warning ...") should concatenate string literals", it 
would be useful if #pragma GCC error/warning behaved like #pragma 
message and consumed multiple (macro-expanded) string literal tokens.


The below patch gets close, but:

* I don't know how to get a location_t that spans all the tokens, see 
the TODO in the patch.  (If that's hard to get right, an alternative 
might be to instead highlight the "error" resp. "warning" token, in the 
same way as #pragma message highlights the "message" token.)


* Additional tokens that are not (ordinary) string literals keep being 
ignored (to be exact, the first such non--string-literal and all 
remaining tokens are ignored).  That's in line with existing behavior 
for those pragmas, where they ignored everything following the first 
(necessarily string-literal) token (but unlike #pragma message, which 
emits "warning: junk at end of '#pragma message' [-Wpragmas]"). 
Something of a corner case happens when such a non--string-literal token 
is the result of macro expansion as in


  #define FOO "2" 3
  #pragma GCC error "1" FOO

emitting a message of "12".  (My naive understanding of how 
cpp_get_token works in do_pragma_warnign_or_error is that the end of the 
#pragma line is represented by a CPP_EOF token.)


* I have left the documentation in gcc/doc/extend.texi alone, as it 
didn't specify any details of how the #pragma message string is parsed, 
either.



diff --git a/gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-1.c 
b/gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-1.c

index 9867c94a8dd..53bae44e210 100644
--- a/gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-1.c
+++ b/gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-1.c
@@ -9,3 +9,6 @@
 char a[CONST1]; // { dg-warning warn-c }
 char b[CONST2]; // { dg-error err-d }

+#define EXPAND "exp-"
+#pragma GCC warning "warn-" EXPAND "e" // { dg-warning warn-exp-e }
+#pragma GCC error "err-" EXPAND "f" // { dg-error err-exp-f }
diff --git a/libcpp/directives.c b/libcpp/directives.c
index 61f1fef9489..4d06a2d2934 100644
--- a/libcpp/directives.c
+++ b/libcpp/directives.c
@@ -1740,19 +1740,49 @@ do_pragma_dependency (cpp_reader *pfile)
 static void
 do_pragma_warning_or_error (cpp_reader *pfile, bool error)
 {
-  const cpp_token *tok = _cpp_lex_token (pfile);
+  size_t count = 0;
+  obstack str_ob;
+  obstack_specify_allocation (&str_ob, 0, 0, xmalloc, free);
+  location_t loc;
+  location_t loc_end;
+  gcc_assert (pfile->state.prevent_expansion > 0);
+  pfile->state.prevent_expansion--;
+  for (;; ++count)
+{
+  const cpp_token *tok = cpp_get_token (pfile);
+  if (tok->type != CPP_STRING)
+   break;
+  if (count == 0)
+   loc = tok->src_loc;
+  obstack_grow (&str_ob, &tok->val.str, sizeof (cpp_string));
+  loc_end = tok->src_loc;
+}
+  pfile->state.prevent_expansion++;
+  if (count == 0)
+{
+  cpp_error (pfile, CPP_DL_ERROR, "invalid \"#pragma GCC %s\" 
directive",

+error ? "error" : "warning");
+  return;
+}
+  cpp_string * strs = (cpp_string *) obstack_finish (&str_ob);
   cpp_string str;
-  if (tok->type != CPP_STRING
-  || !cpp_interpret_string_notranslate (pfile, &tok->val.str, 1, &str,
-   CPP_STRING)
-  || str.len == 0)
+  bool combine = cpp_interpret_string_notranslate (pfile, strs, count,
+  &str, CPP_STRING);
+  obstack_free (&str_ob, 0);
+  if (!combine || str.len == 0)
 {
   cpp_error (pfile, CPP_DL_ERROR, "invalid \"#pragma GCC %s\" 
directive",

 error ? "error" : "warning");
   return;
 }
-  cpp_error (pfile, error ? CPP_DL_ERROR : CPP_DL_WARNING,
-"%s", str.text);
+  if (count != 1)
+{
+  //TODO: combine loc, loc_end into
+  // loc = COMBINE_LOCATION_DATA (pfile->line_table, ..., ..., NULL);
+  (void)loc_end;
+}
+  cpp_error_at (pfile, error ? CPP_DL_ERROR : CPP_DL_WARNING, loc,
+   "%s", str.text);
   free ((void *)str.text);
 }

Re: PR libstdc++/90945 Patch to have pretty printer for std::vector return bool intead of int for elements

[Stephan Bergmann]

On 19/06/2019 21:54, Jonathan Wakely wrote:

On 19/06/19 21:49 +0200, Michael Weghorn wrote:

On 19/06/2019 21.37, Jonathan Wakely wrote:

+  std::vector vb;
+  vb.reserve(100);
+  vb.push_back(true);
+  vb.push_back(true);
+  vb.push_back(false);
+  vb.push_back(false);
+  vb.push_back(true);
+  vb.erase(vb.begin());
+// { dg-final { regexp-test vb {std::(__debug::)?vector of length 4, 
capacity 100 = \\{true, false, false, true\\}} } }

+


This inserts 5 elements, so I'd expect that either "vector of length 5"
and an additional "true" element at the beginning need to be added for
the expected result or one of the two first 'vb.push_back(true)' needs
to be removed.


It inserts five then erases one, the test is right.


Just one thought that occurred to me while idly browsing this thread: 
Wouldn't it be better in general to have non-symmetric content to test 
against, to check that the printer doesn't print it in reverse?

Re: [PATCH] Define std::__invoke_r for INVOKE

[Stephan Bergmann]

On 14/05/2019 17:25, Jonathan Wakely wrote:

 * include/bits/invoke.h (__invoke_r): Define new function implementing
 the INVOKE pseudo-function.
 * testsuite/20_util/function_objects/invoke/1.cc: Add more tests.
 * testsuite/20_util/function_objects/invoke/2.cc: New test.

Tested powerpc64le-linux, committed to trunk.



diff --git a/libstdc++-v3/include/bits/invoke.h 
b/libstdc++-v3/include/bits/invoke.h
index a5278a59f0c..59e22da84d4 100644
--- a/libstdc++-v3/include/bits/invoke.h
+++ b/libstdc++-v3/include/bits/invoke.h
@@ -96,6 +96,65 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
std::forward<_Args>(__args)...);
 }
 
+#if __cplusplus >= 201703L

+  // INVOKE: Invoke a callable object and convert the result to R.
+  template
+constexpr enable_if_t, _Res>
+__invoke_r(_Callable&& __fn, _Args&&... __args)
+noexcept(is_nothrow_invocable_r_v<_Res, _Callable, _Args...>)
+{
+  using __result = __invoke_result<_Callable, _Args...>;
+  using __type = typename __result::type;
+  using __tag = typename __result::__invoke_type;
+  if constexpr (is_void_v<_Res>)
+   std::__invoke_impl<__type>(__tag{}, std::forward<_Callable>(__fn),
+   std::forward<_Args>(__args)...);
+  else
+   return std::__invoke_impl<__type>(__tag{},
+ std::forward<_Callable>(__fn),
+ std::forward<_Args>(__args)...);
+}
+#else // C++11
+  template
+using __can_invoke_as_void = __enable_if_t<
+  __and_, __is_invocable<_Callable, _Args...>>::value,
+  _Res
+>;
+
+  template
+using __can_invoke_as_nonvoid = __enable_if_t<
+  __and_<__not_>,
+is_convertible::type,
+   _Res>
+  >::value,
+  _Res
+>;
+
+  // INVOKE: Invoke a callable object and convert the result to R.
+  template
+constexpr __can_invoke_as_nonvoid<_Res, _Callable, _Args...>
+__invoke_r(_Callable&& __fn, _Args&&... __args)
+{
+  using __result = __invoke_result<_Callable, _Args...>;
+  using __type = typename __result::type;
+  using __tag = typename __result::__invoke_type;
+  return std::__invoke_impl<__type>(__tag{}, std::forward<_Callable>(__fn),
+   std::forward<_Args>(__args)...);
+}
+
+  // INVOKE when R is cv void
+  template
+constexpr __can_invoke_as_void<_Res, _Callable, _Args...>
+__invoke_r(_Callable&& __fn, _Args&&... __args)


I think this is a problem with -std=c++11 (but not -std=c++14) where 
void is not yet a literal type, so this function can't be constexpr?


(I came across this with Clang -std=c++11 upon #include  
producing an odd



In file included from 
/home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/memory:81:
In file included from 
/home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/unique_ptr.h:37:
In file included from 
/home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/tuple:41:
/home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/invoke.h:148:5:
 error: no return statement in constexpr function
__invoke_r(_Callable&& __fn, _Args&&... __args)
^


I first reduced that to a broken reproducer and misclassified it as a 
Clang bug,  "Bogus 'error: 
no return statement in constexpr function' when void return type is 
'templated'".  But what apparently happens is that since Clang knows 
that the constexpr function must have a literal return type (which can't 
be void for -std=c++11), it just issues that error whenever it comes a 
constexpr function that lacks a return type.)



+{
+  using __result = __invoke_result<_Callable, _Args...>;
+  using __type = typename __result::type;
+  using __tag = typename __result::__invoke_type;
+  std::__invoke_impl<__type>(__tag{}, std::forward<_Callable>(__fn),
+std::forward<_Args>(__args)...);
+}
+#endif // C++11
+
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
 

Re: [PATCH] Use _GLIBCXX_NOEXCEPT_IF for std::swap

[Stephan Bergmann]

On 03/05/2019 00:30, Jonathan Wakely wrote:

On 02/05/19 21:33 +0100, Jonathan Wakely wrote:

This was also reported as https://gcc.gnu.org/PR90314


And here's what I've tested and committed.


Thanks, that fixes things for me.

Re: [PATCH] Use _GLIBCXX_NOEXCEPT_IF for std::swap

[Stephan Bergmann]

On 29/04/2019 15:26, Jonathan Wakely wrote:

 * include/bits/move.h (swap(T&, T&), swap(T (&)[N], T (&)[N])): Use
 _GLIBCXX_NOEXCEPT_IF to simplify declarations.

This just avoids having to repeat the name and parameter-list of the
functions.


libstdc++-v3/include/std/type_traits still has


  template
inline
typename enable_if<__and_<__not_<__is_tuple_like<_Tp>>,
  is_move_constructible<_Tp>,
  is_move_assignable<_Tp>>::value>::type
swap(_Tp&, _Tp&)
noexcept(__and_,
is_nothrow_move_assignable<_Tp>>::value);


using noexcept instead of _GLIBCXX_NOEXPECT_IF, and at least during 
configure of building LibreOffice with Clang, that causes failure



.../gcc/trunk/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/bits/move.h:185:5:
 error: exception specification in declaration does not match previous 
declaration
swap(_Tp& __a, _Tp& __b)
^
.../gcc/trunk/lib/gcc/x86_64-pc-linux-gnu/10.0.0/../../../../include/c++/10.0.0/type_traits:2531:5:
 note: previous declaration is here
swap(_Tp&, _Tp&)
^


I didn't try to track down under what conditions _GLIBCXX_NOEXCEPT_IF 
would not expand to noexcept, but I assume that just type_traits needs 
adapting, too?

Documentation: -gsplit-dwarf missing from Option Summary

[Stephan Bergmann]

Cannot identify what sorting is used for that list (if any), so putting 
it at the end (and -gsplit-dwarf also follows -fvar-tracking-assignments 
in the "Options for Debugging Your Program" section).



Author: Stephan Bergmann 
Date:   Tue Jun 26 15:04:54 2018 +0200

Documentation: -gsplit-dwarf missing from Option Summary

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index f231da3cde2..3f74b9ac336 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -360,7 +360,7 @@ Objective-C and Objective-C++ Dialects}.
 -femit-struct-debug-detailed@r{[}=@var{spec-list}@r{]} @gol
 -feliminate-unused-debug-symbols  -femit-class-debug-always @gol
 -fno-merge-debug-strings  -fno-dwarf2-cfi-asm @gol
--fvar-tracking  -fvar-tracking-assignments}
+-fvar-tracking  -fvar-tracking-assignments -gsplit-dwarf}

 @item Optimization Options
 @xref{Optimize Options,,Options that Control Optimization}.

Re: [PATCH] Default special members of regex types and add noexcept

[Stephan Bergmann]

On 08/06/18 13:01, Jonathan Wakely wrote:

Nothing very exciting, just adding noexcept and defaulting some
members.

 * include/bits/regex.h (sub_match): Add noexcept to default
 constructor and length observer.
 (match_results): Add noexcept to default constructor and observers
 with no preconditions. Define destructor as defaulted.
 (operator==, operator!=, swap): Add noexcept.
 (regex_iterator): Add default member initializers and define default
 constructor and destructor as defaulted. Add noexcept to equality
 and dereference operators.

Tested powerpc64le-linux, committed to trunk.


Looks like that forgot to also add noexcept to the definition of


regex_iterator<_Bi_iter, _Ch_type, _Rx_traits>::
operator==(const regex_iterator& __rhs) const


in libstdc++-v3/include/bits/regex.tcc?

[PATCH] Missing noexcept in string_view::find_first_of declaration

[Stephan Bergmann]

 >From 0a75fbb0c16e216892d16f1ba3448471e33f61bb Mon Sep 17 00:00:00 2001
From: Stephan Bergmann 
Date: Fri, 24 Nov 2017 18:04:30 +0100
Subject: [PATCH] Missing noexcept in string_view::find_first_of declaration

cf. definition in libstdc++-v3/include/bits/string_view.tcc that does have the
noexcept (like all the other overloads defined inline in
libstdc++-v3/include/std/string_view do).
---
 libstdc++-v3/include/std/string_view | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/string_view b/libstdc++-v3/include/std/string_view
index fa834002726..68b4b08f8f4 100644
--- a/libstdc++-v3/include/std/string_view
+++ b/libstdc++-v3/include/std/string_view
@@ -323,7 +323,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { return this->find(__c, __pos); }
 
   constexpr size_type
-  find_first_of(const _CharT* __str, size_type __pos, size_type __n) const;
+  find_first_of(const _CharT* __str, size_type __pos, size_type __n) const noexcept;
 
   constexpr size_type
   find_first_of(const _CharT* __str, size_type __pos = 0) const noexcept
-- 
2.13.6

[PATCH] Fix typo in unordered_map deduction guide, missing "typename ="

[Stephan Bergmann]

Otherwise, at least recent Clang trunk with -std=gnu++17 complains


In file included from 
lib/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../include/c++/8.0.0/functional:60:
In file included from 
lib/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../include/c++/8.0.0/unordered_map:47:
lib/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../include/c++/8.0.0/bits/unordered_map.h:1197:5:
 error: deduction guide template contains a template parameter that cannot be 
deduced
unordered_map(initializer_list>, _Allocator)
^
lib/gcc/x86_64-pc-linux-gnu/8.0.0/../../../../include/c++/8.0.0/bits/unordered_map.h:1196:34:
 note: non-deducible template parameter (anonymous)
   _RequireAllocator<_Allocator>>
^
1 error generated.


>From 0ecb03c59b9318b3f47e49daa2f45dd513035d55 Mon Sep 17 00:00:00 2001
From: Stephan Bergmann 
Date: Fri, 24 Nov 2017 17:55:38 +0100
Subject: [PATCH] Fix typo in unordered_map deduction guide, missing "typename
 ="

...as correctly appears in all the other deduction guides in these files.
---
 libstdc++-v3/include/bits/unordered_map.h | 2 +-
 libstdc++-v3/include/debug/unordered_map  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/include/bits/unordered_map.h b/libstdc++-v3/include/bits/unordered_map.h
index cb5bcb89a16..27c89f172e1 100644
--- a/libstdc++-v3/include/bits/unordered_map.h
+++ b/libstdc++-v3/include/bits/unordered_map.h
@@ -1193,7 +1193,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 -> unordered_map<_Key, _Tp, hash<_Key>, equal_to<_Key>, _Allocator>;
 
   template>
+	   typename = _RequireAllocator<_Allocator>>
 unordered_map(initializer_list>, _Allocator)
 -> unordered_map<_Key, _Tp, hash<_Key>, equal_to<_Key>, _Allocator>;
 
diff --git a/libstdc++-v3/include/debug/unordered_map b/libstdc++-v3/include/debug/unordered_map
index c5734304846..c68ccaa3372 100644
--- a/libstdc++-v3/include/debug/unordered_map
+++ b/libstdc++-v3/include/debug/unordered_map
@@ -679,7 +679,7 @@ namespace __debug
 -> unordered_map<_Key, _Tp, hash<_Key>, equal_to<_Key>, _Allocator>;
 
   template>
+	   typename = _RequireAllocator<_Allocator>>
 unordered_map(initializer_list>, _Allocator)
 -> unordered_map<_Key, _Tp, hash<_Key>, equal_to<_Key>, _Allocator>;
 
-- 
2.13.6

Re: [PATCH] PR libstdc++/80624 satisfy invariant for char_traits::eof()

[Stephan Bergmann via gcc-patches]

On 05/05/2017 07:05 PM, Jonathan Wakely wrote:

As discussed at http://stackoverflow.com/q/43769773/981959 (and kinda
hinted at by http://wg21.link/lwg1200) there's a problem with
char_traits::eof() because it returns int_type(-1) which is
the same value as u'\u', a valid UTF-16 code point.

i.e. because all values of int_type are also valid values of char_type
we cannot meet the requirement that:

"The member eof() shall return an implementation-defined constant
that cannot appear as a valid UTF-16 code unit."

I've reported this as a defect, suggesting that the wording above
needs to change.

One consequence is that basic_streambuf::sputc(u'\u')
always returns the same value, whether it succeeds or not. On success
it returns to_int_type(u'\u') and on failure it returns eof(),
which is the same value. I think that can be solved with the attached
change, which preserves the invariant in [char.traits.require] that
eof() returns:

"a value e such that X::eq_int_type(e,X::to_int_type(c)) is false for
all values c."

This can be true if we ensure that to_int_type never returns the eof()
value. http://www.unicode.org/faq/private_use.html#nonchar10 suggests
doing something like this.

It means that when writing u'\u' to a streambuf we write that
character successfully, but return u'\uFFFD' instead; and when reading
u'\u' from a streambuf we return u'\uFFFD' instead. This is
asymmetrical, as we can write that character but not read it back.  It
might be better to refuse to write u'\u' and write it as the
replacement character instead, but I think I prefer to write the right
character when possible. It also doesn't require any extra changes.

All tests pass with this, does anybody see any problems with this
approach?


Sounds scary to me.  As an application programmer, I'd expect to be able 
to use chart16_t based streams to read and write arbitrary sequences of 
Unicode code points (encoded as sequences of UTF-16 code units).  (Think 
of an application temporarily storing internal strings to a disk file.)


Also, I'd be surprised to find this asymmetric behavior only for U+ 
and not for other noncharacters, and only for char16_t and not for char32_t.


To me, the definition of char16_t's int_type and eof() sounds like a bug 
that needs fixing, not working around?

Re: [PATCH] missing return in debug/vector _Safe_vector::operator=

[Stephan Bergmann]

On 04/28/2015 02:38 PM, Jonathan Wakely wrote:

[CCing gcc-patches]

On 28/04/15 14:32 +0200, Stephan Bergmann wrote:

broken on GCC 5 and trunk


Ouch.

OK for trunk and the branch, do you have commit privs?


No, I don't; would be great if you can push that.