[Bug c++/94673] [concepts] What is the return type of local parameters of requires expressions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94673
gcc-bugs at marehr dot dialup.fu-berlin.de changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFIRMED |RESOLVED
--- Comment #5 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
(In reply to Patrick Palka from comment #4)
> Don't we already do this with -fconcepts-diagnostics-depth=2 ?
You are right, sorry! Haven't checked that again thoroughly, and it seems that
you do.
> -fconcepts-diagnostics-depth=2
will produce
```
:18:15: error: static assertion failed
18 | static_assert(foo); // fails with clang
| ^~~
:18:15: note: constraints not satisfied
:9:9: required by the constraints of 'template concept foo'
:9:15: in requirements with 't v' [with t = int&&]
:11:6: note: 'v' does not satisfy return-type-requirement, because
11 | {v} -> std::same_as;
| ~^~~
:11:6: error: deduced expression type does not satisfy placeholder
constraints
:11:6: note: constraints not satisfied
In file included from
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/compare:39,
from
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/bits/stl_pair.h:65,
from
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/utility:70,
from :1:
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/concepts:57:15: required
for the satisfaction of '__same_as<_Tp, _Up>' [with _Tp = int&&; _Up = int&]
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/concepts:62:13: required
for the satisfaction of 'same_as, t&>], t&>' [with decltype(auto) [requires
std::same_as<, t&>] = int&&; t = int&&]
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/concepts:57:32: note: the
expression 'is_same_v<_Tp, _Up> [with _Tp = int&&; _Up = int&]' evaluated to
'false'
57 | concept __same_as = std::is_same_v<_Tp, _Up>;
|
```
It seems that the behaviour changed again in gcc-11:
```
template
concept foo = requires(t v)
{
{v} -> same_as;
};
static_assert(foo); // true in gcc-10, false in gcc-11
```
Thank you again, from my POV can be closed.
[Bug c++/94673] [concepts] What is the return type of local parameters of requires expressions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94673
--- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
I think this bug should be changed to a request to improve the diagnostics.
The diagnostic says:
```
:13:15: note: constraints not satisfied
:8:9: required by the constraints of 'template concept foo'
:8:15: in requirements with 't v' [with t = int]
:10:6: note: 'v' does not satisfy return-type-requirement
10 | {v} -> same_as;
| ^
```
If you don't know that `{v}` should be read as `{(v)}`, it is confusing that
the diagnostic says that `'t v' [with t = int]` does not satisfy that the type
of the expression `{ v }` is `t`.
I think the diagnostic for the return-type-requirement should add the reason /
diagnostic why it isn't fulfilled, so basically the same reason that
`static_assert(std::same_as);` would give.
> note: the expression 'is_same_v<_Tp, _Up> [with _Tp = int&; _Up = int]'
> evaluated to 'false'
> 57 | concept __same_as = std::is_same_v<_Tp, _Up>;
> | ~^~~
[Bug libstdc++/96416] to_address() is broken by static_assert in pointer_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416 gcc-bugs at marehr dot dialup.fu-berlin.de changed: What|Removed |Added CC||gcc-bugs at marehr dot dialup.fu-b ||erlin.de --- Comment #19 from gcc-bugs at marehr dot dialup.fu-berlin.de --- > I guess that's a reasonable thing to wish for, given I'm not the first > falling for it; I hope I'll be the last :) > Unfortunately not, I ran into the same issue :( But thanks to the thread, I got some insight into the question: Should every type with an "operator->()" really be considered a pointer?
[Bug c++/100205] [11/12 Regression] error: invalid use of non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205 --- Comment #11 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Awesome, thank you, Jason!
[Bug libstdc++/100587] std::ranges::empty_view is not a view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100587 gcc-bugs at marehr dot dialup.fu-berlin.de changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Sorry for the noise
[Bug libstdc++/100587] New: std::range::empty_view is not a view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100587 Bug ID: 100587 Summary: std::range::empty_view is not a view Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de Target Milestone: --- The following snippet does not compile: ```c++ #include static_assert(std::ranges::view); ``` https://godbolt.org/z/3qanzdrb5 The standard says that https://eel.is/c++draft/range.empty#overview-1: > empty_view produces a view of no elements of a particular type. empty_view is defined as inheriting from view_interface, the std::ranges::view expects an inheritance from view_base per default. Furthermore, https://eel.is/c++draft/ranges.syn does not specify > template > inline constexpr bool enable_view> = true; So I guess the standard is inconsistent here.
[Bug libstdc++/95983] `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983 --- Comment #11 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Thank you so much!
[Bug libstdc++/100233] New: [10/11/12] std::views::elements only accepts types that are defined on std::get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100233
Bug ID: 100233
Summary: [10/11/12] std::views::elements only accepts types
that are defined on std::get
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hi gcc-team,
the following code will not work on custom tuples that don't add a get overload
within the std namespace. These tuples work in structured bindings, but not
within std::views::elements.
```cpp
#include
#include
namespace my_namespace
{
template
struct S
{
int x{};
};
} // namespace my_namespace
namespace std
{
template typename t, typename ...types>
requires std::is_base_of_v, t>
struct tuple_size> : public std::integral_constant
{};
template typename t, typename ...types>
requires (i < sizeof...(types)) &&
std::is_base_of_v, t>
struct tuple_element>
{
using type = int;
};
} // namespace std
namespace my_namespace
{
template
int & get(my_namespace::S & e) noexcept
{
return e.x;
}
} // my_namespace
#if !DO_FAIL
namespace std
{
using my_namespace::get;
} // namespace std
#endif
#include
int main()
{
// does work with / without defining get within std
using tripplet_t = my_namespace::S;
tripplet_t tuple{};
auto & [a, b, c] = tuple;
// only works when defining within std
std::vector vec(10);
// std::views::elements<0>(vec);
using elements_view_t =
std::ranges::elements_view, 0>;
}
```
https://godbolt.org/z/n315fednc
```
> g++-10 --std=c++2a -DDO_FAIL=1
:56:93: error: template constraint failure for 'template requires (input_range<_Vp>) && ((view<_Vp>) &&
(__has_tuple_element)()))>::type>::type,
std::indirectly_readable_traits)()))>::type>::type>
>::__iter_traits)()))>::type>::type,
std::indirectly_readable_traits)()))>::type>::type>
>::value_type, _Nm>) && (__has_tuple_element)()))&>)())>::type,
_Nm>) &&
(__returnable_element)()))&>)()),
_Nm>)) class std::ranges::elements_view'
56 | using elements_view_t =
std::ranges::elements_view, 0>;
|
^
:56:93: note: constraints not satisfied
In file included from :44:
/opt/compiler-explorer/gcc-trunk-20210423/include/c++/12.0.0/ranges: In
substitution of 'template requires
(input_range<_Vp>) && ((view<_Vp>) && (__has_tuple_element)()))>::type>::type,
std::indirectly_readable_traits)()))>::type>::type>
>::__iter_traits)()))>::type>::type,
std::indirectly_readable_traits)()))>::type>::type>
>::value_type, _Nm>) && (__has_tuple_element)()))&>)())>::type,
_Nm>) &&
(__returnable_element)()))&>)()),
_Nm>)) class std::ranges::elements_view [with _Vp =
std::ranges::ref_view > >;
long unsigned int _Nm = 0]':
:56:93: required from here
/opt/compiler-explorer/gcc-trunk-20210423/include/c++/12.0.0/ranges:3306:13:
required for the satisfaction of
'__has_tuple_element, _Nm>' [with _Vp =
std::ranges::ref_view,
std::allocator > > >; _Nm = 0]
/opt/compiler-explorer/gcc-trunk-20210423/include/c++/12.0.0/ranges:3306:35:
in requirements with '_Tp __t' [with _Nm = 0; _Tp = my_namespace::S]
/opt/compiler-explorer/gcc-trunk-20210423/include/c++/12.0.0/ranges:3311:24:
note: the required expression 'get<_Nm>(__t)' is invalid
3311 | { std::get<_Nm>(__t) }
| ~^
```
The standard defines the `get-element` call as
```cpp
if constexpr (is_reference_v>) {
return get(*i);
} else {
using E = remove_cv_t>>;
return static_cast(get(*i));
}
```
https://eel.is/c++draft/range.elements#iterator-3
With some good-will you could say that `get` should be called unqualified :)
I know that it isn't stated explicitly, but with how the whole ADL thing with
range adaptors work, it is unexpected that it does not work here too.
Thank you!
[Bug c++/100205] [11 Regression] error: invalid use of non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205 --- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de --- To be more precise my gcc build is: ``` > gcc-git -v Using built-in specs. COLLECT_GCC=/opt/gcc/gcc-git//bin/g++ COLLECT_LTO_WRAPPER=/opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/marehr/Packages/gcc-git/src/gcc/configure --prefix=/opt/gcc/gcc-git --libdir=/opt/gcc/gcc-git/lib --libexecdir=/opt/gcc/gcc-git/lib --mandir=/opt/gcc/gcc-git/share/man --infodir=/opt/gcc/gcc-git/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++ --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror --disable-bootstrap Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.1 20210421 (prerelease) (GCC) COMPILER_PATH=/opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/11.0.1/:/opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/11.0.1/:/opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/:/opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/11.0.1/:/opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/ LIBRARY_PATH=/opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/11.0.1/:/opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a.' /opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/11.0.1/collect2 -plugin /opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/11.0.1/liblto_plugin.so -plugin-opt=/opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper -plugin-opt=-fresolution=/tmp/cchzTpvd.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie /lib/../lib/Scrt1.o /lib/../lib/crti.o /opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/11.0.1/crtbeginS.o -L/opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/11.0.1 -L/opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../.. -rpath /opt/gcc/gcc-git//lib -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /opt/gcc/gcc-git/lib/gcc/x86_64-pc-linux-gnu/11.0.1/crtendS.o /lib/../lib/crtn.o /usr/bin/ld: /lib/../lib/Scrt1.o: in function `_start': (.text+0x24): undefined reference to `main' collect2: error: ld returned 1 exit status ``` The build gcc-git-11.0.1.r184220.be8d5f99f50 did work, but the newer build gcc-git-11.0.1.r184427.e826f7355af doesn't any more.
[Bug c++/100205] [11 Regression] error: invalid use of non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205 --- Comment #2 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Yeah, it compiled for me with a build from two weeks ago, too. I should have mentioned that :)
[Bug c++/100205] New: [11 Regression] error: invalid use of non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205
Bug ID: 100205
Summary: [11 Regression] error: invalid use of non-static data
member
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hi gcc-team,
the following code compiles with gcc-10, but does not compile with gcc-11 any
more:
```cpp
#include
struct coordinate_matrix {
using index_t = size_t;
struct convert_to_matrix_coordinate {
index_t column_id;
index_t operator()(index_t) { return column_id; }
};
using iota_view_t = decltype(std::views::iota(0, 1));
index_t column_id;
// does not work
using value_type =
decltype(std::declval() |
std::views::transform(convert_to_matrix_coordinate{column_id}));
// does not work
using value_type2 =
decltype(std::views::transform(std::declval(),
convert_to_matrix_coordinate{column_id}));
// does work
using value_type3 =
decltype(std::views::transform(std::declval(),
([](index_t)
{
return [](index_t) -> index_t
{
return 0;
};
})(column_id)));
// does work
using value_type4 =
decltype(std::views::transform(std::declval(),
convert_to_matrix_coordinate{0u}));
// does work
using value_type5 = decltype(column_id);
};
int main()
{
// works:
using index_t = size_t;
auto view = std::views::iota(0, 1);
using iota_view_t = decltype(std::views::iota(0, 1));
index_t column_id = 0;
view |
std::views::transform(coordinate_matrix::convert_to_matrix_coordinate{column_id});
using value_type = decltype(std::declval() |
std::views::transform(coordinate_matrix::convert_to_matrix_coordinate{column_id}));
}
```
https://godbolt.org/z/EPoP3jvab
with the following error:
```
:14:97: error: invalid use of non-static data member
'coordinate_matrix::column_id'
14 | decltype(std::declval() |
std::views::transform(convert_to_matrix_coordinate{column_id}));
|
^
:10:11: note: declared here
10 | index_t column_id;
| ^
```
I know how to work around this, but I'm a bit confused why in some cases it
allows using column_id and some cases don't.
Thank you!
[Bug libstdc++/100146] __cpp_lib_to_chars not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100146 --- Comment #10 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Thank you!
[Bug libstdc++/95983] `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983 --- Comment #4 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Hi Patrick, thank you for that patch. I guess that it also fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96070. Will this patch be backported to gcc-10? Great work!
[Bug libstdc++/100146] New: __cpp_lib_to_chars not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100146
Bug ID: 100146
Summary: __cpp_lib_to_chars not defined
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hi gcc-team,
it seems that you implemented the float variants of in gcc-11.
Is there a reason that you did not define `__cpp_lib_to_chars`?
The following code:
```cpp
#include
#ifndef __cpp_lib_to_chars
#warning("__cpp_lib_to_chars NOT defined")
#endif
#include
#ifndef __cpp_lib_to_chars
#warning("__cpp_lib_to_chars NOT defined")
#endif
#include
int main()
{
float value;
std::string_view view{"5.55"};
std::from_chars(view.begin(), view.end(), value);
}
```
throws warnings.
https://godbolt.org/z/WK7qs84Th
Thank you!
[Bug libstdc++/100139] New: std::views::{take, drop} don't type erase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100139
Bug ID: 100139
Summary: std::views::{take, drop} don't type erase
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hello gcc-team,
the following code:
```cpp
#include
#include
#include
#include
static_assert(std::same_as,
decltype(std::views::take(std::span{}, 2))>);
static_assert(std::same_as);
```
does not compile (yet).
https://godbolt.org/z/6Mq7x8zaj
AFAIK this should be
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1739r0.md that was
merged by https://github.com/cplusplus/draft/pull/3777.
There was a rather amusing error report at stackoverflow [1].
I tried to find that proposal in [2] but couldn't and wanted to ask if I looked
at the wrong place. If you have time to implement this, that would be awesome!
Thank you!
[1]
https://stackoverflow.com/questions/61867635/recursive-application-of-c20-range-adaptor-causes-a-compile-time-infinite-loop
[2] https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2020
[Bug libstdc++/99433] [11 Regression] custom friend pipe-operator| conflicts with range adaptor?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99433
--- Comment #7 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Thank you for the quick analysis!
> views::drop(E, F) is specified to be expression-equivalent to the braced
> init ranges::drop_view{E, F}
Is not completely true, right? As the narrowing warning shows:
```
libstdc++-v3/include/std/ranges:2101:24: warning: narrowing conversion of
‘std::declval()’ from ‘long unsigned int’ to
‘std::ranges::range_difference_t
> >’ {aka ‘long int’} [-Wnarrowing]
```
There is some `std::views::all` involved.
But the following expressions
```
#include
#include
int main()
{
std::list list;
// std::views::drop(list, 0ull); // does not compile
std::ranges::drop_view{list, 0ull}; // does compile without warnings
std::ranges::drop_view{std::views::all(list), 0ull}; // does compile without
warnings
}
```
do compile without any warnings when using `g++-11 -std=c++2a -pedantic -Wall
-Wextra`!
Even when adding `-Wsystem-headers` there is no "narrowing" warning found in
those expressions.
Thank you for your incredible help!
[Bug libstdc++/99433] [11 Regression] custom friend pipe-operator| conflicts with range adaptor?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99433
--- Comment #5 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Thank you for the fix, but the following code does not compile any more:
```c++
#include
#include
int main()
{
std::list list;
constexpr auto drop = [](urng_t &&
urange, size_t drop_size)
{
// does not work:
return std::forward(urange) | std::views::drop(drop_size);
// does work:
// return std::forward(urange) | std::views::drop(0);
};
drop(list, 0);
}
```
Should I open a new issue?
[Bug c++/99599] [11 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599 --- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Hi Jason, as you linked to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97704, I'm interested if your suggestion would allow that, too? > But that's a matter for the committee Will such issues be forwarded, or do we need to submit a paper / regression / idea? I wouldn't know how to proceed here and / or what needs to be done. Thank you!
[Bug libstdc++/99433] [11 Regression] custom friend pipe-operator| conflicts with range adaptor?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99433
gcc-bugs at marehr dot dialup.fu-berlin.de changed:
What|Removed |Added
Summary|custom friend |[11 Regression] custom
|pipe-operator| conflicts|friend pipe-operator|
|with range adaptor? |conflicts with range
||adaptor?
Component|c++ |libstdc++
--- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Hello gcc-team,
I got the code more recuced to:
```c++
namespace std
{
template _Up __declval(int);
template auto declval() noexcept -> decltype(__declval<_Tp>(0));
} // namespace std
namespace std::ranges
{
struct view_base {};
template
class view_interface : public view_base {};
} // namespace std::ranges
namespace std::ranges::views::__adaptor
{
template
struct _RangeAdaptorClosure;
template
struct _RangeAdaptor
{
_Callable _M_callable;
constexpr _RangeAdaptor(const _Callable & __callable)
: _M_callable{__callable}
{}
template
constexpr auto operator()(_Args &&...__args) const
{
auto __closure = [... __args(__args)](_Range &&__r) {
return _Callable{}(__r, __args...);
};
using _ClosureType = decltype(__closure);
return _RangeAdaptorClosure{__closure};
}
};
template
struct _RangeAdaptorClosure : public _RangeAdaptor<_Callable>
{
template
requires requires {declval<_Callable>()(declval<_Range>());}
friend constexpr auto operator|(_Range &&__r, const _RangeAdaptorClosure
&__o);
};
template
_RangeAdaptorClosure(_Callable) -> _RangeAdaptorClosure<_Callable>;
} // namespace std::ranges::views::__adaptor
namespace std::ranges
{
template
class transform_view : public view_interface> {};
} // namespace std::ranges
namespace std::ranges::views
{
inline constexpr __adaptor::_RangeAdaptor transform =
[](auto &&__r, auto &&__f)
{
return transform_view{__r, __f};
};
} // namespace std::ranges::views
namespace std
{
namespace views = ranges::views;
template class vector {};
} // namespace std
template
struct deep
{
underlying_adaptor_t adaptor;
template
friend auto operator|(range_t &range, deep const &me) {
return 0;
}
};
template
deep(underlying_adaptor_t && adaptor) -> deep;
inline auto const complement = deep{std::views::transform([]() {})};
std::vector> foo;
auto v = foo | complement;
```
See https://godbolt.org/z/51d9da
AFAIS the problem is that
```c++
template
requires requires {declval<_Callable>()(declval<_Range>());}
std::ranges::views::__adaptor::_RangeAdaptorClosure::operator|(_Range &&__r,
const _RangeAdaptorClosure &__o)
```
does not constraint the second argument to be `_RangeAdaptorClosure &__o`.
If I see this correctly, this is the same issue as in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97704 (which was marked invalid).
Just that this time your std-lib implementation is at fault. I still find it
insane that a non-template argument that does not fit is somehow considered in
a requires expression, since this effectively forbids to use constraints on non
template or partial template functions, but it is as it is, and it would be
cool if the std-lib implementation plays by the same rules.
(Why isn't a constraint with the type added implicitly to the requires clause
in these cases? That seems to be a workaround anyway...)
[Bug c++/99433] New: custom friend pipe-operator| conflicts with range adaptor?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99433
Bug ID: 99433
Summary: custom friend pipe-operator| conflicts with range
adaptor?
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hello gcc-team,
the following code does not compile with gcc-11 any more, but did with gcc-10.
```c++
#include
#include
template
struct deep {
underlying_adaptor_t adaptor;
template
friend auto operator|(range_t &range, deep const &me)
{
return me.adaptor(range[0]);
}
};
inline auto const complement = deep{std::views::transform([](auto const nucl) {
return nucl + ' '; })};
std::vector> foo{};
auto v = foo | complement;
```
https://godbolt.org/z/9oEj9T
Thank you!
[Bug rtl-optimization/99320] constexpr defined arrays within constexpr functions would benefit from lookup-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99320 --- Comment #2 from gcc-bugs at marehr dot dialup.fu-berlin.de --- You are right, it seems to be the same issue except that my function is constexpr, and I can't use `static constexpr ...` within the function, but Barry mentioned that use case already. You mentioned something that gcc needs to prove that this is safe, but I think my use case is "safe" since it is constexpr :)
[Bug rtl-optimization/99320] New: constexpr defined arrays within constexpr functions would benefit from lookup-tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99320
Bug ID: 99320
Summary: constexpr defined arrays within constexpr functions
would benefit from lookup-tables
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hi gcc-team,
first of all, sorry if this is the wrong component, but I guess that this is a
"missed-optimization" issue rather than a regular C++ issue, so I wasn't sure
which component fit the most.
I have the following code (which can be further reduced, but I kept it as
original as possible to reflect my use case):
```c++
#include
struct foo
{
static constexpr char bar(unsigned idx)
{
constexpr std::array lookup_table
{
[] () constexpr
{
std::array ret{};
// reverse mapping for characters and their lowercase
for (unsigned rnk = 0u; rnk < 15; ++rnk)
{
ret[rnk + 'A'] = rnk;
}
// set U equal to T
ret['U'] = ret['T']; ret['u'] = ret['t'];
// iupac characters get special treatment, because there is no N
ret['R'] = ret['A']; ret['r'] = ret['A']; // A or G
ret['Y'] = ret['C']; ret['y'] = ret['C']; // C or T
ret['S'] = ret['C']; ret['s'] = ret['C']; // C or G
ret['W'] = ret['A']; ret['w'] = ret['A']; // A or T
ret['K'] = ret['G']; ret['k'] = ret['G']; // G or T
ret['M'] = ret['A']; ret['m'] = ret['A']; // A or T
ret['B'] = ret['C']; ret['b'] = ret['C']; // C or G or T
ret['D'] = ret['A']; ret['d'] = ret['A']; // A or G or T
ret['H'] = ret['A']; ret['h'] = ret['A']; // A or C or T
ret['V'] = ret['A']; ret['v'] = ret['A']; // A or C or G
return ret;
}()
};
return lookup_table[idx];
}
};
int main(int argc, char const ** argv)
{
return foo::bar(argc);
}
```
I wanted to switch from defining that lookup-table within the class (e.g.
`static constexpr ... lookup_table = ...`) to define the lookup-table within
the function directly, and I noticed that I had some performance regression in
my benchmarks. Some micro benchmarks went from ~80ns to ~3000ns, but I also saw
an impact on more "realistic" macro benchmarks.
After looking at the assembly https://godbolt.org/z/n9bo7W, I noticed that the
table is "constructed" on each function call rather than a single
lookup-instruction.
So I compared it to what clang does, and it seems that they are actually
generating a static lookup table.
I know that this use case is quite niche, but it would be cool to have it
nevertheless :)
Thank you!
[Bug c++/99318] New: [10/11 Regression] -Wdeprecated-declarations where non-should be?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99318
Bug ID: 99318
Summary: [10/11 Regression] -Wdeprecated-declarations where
non-should be?
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hello gcc-team,
since gcc 10 the following code throws a deprecation warning, even though it
doesn't use any deprecated code.
```c++
template
class alphabet_base
{
[[deprecated("message")]] unsigned char_to_rank_table(char const chr)
{
using index_t = unsigned;
return derived_type::char_to_rank[static_cast(chr)];
}
};
```
gives the following warning:
```
: In member function 'unsigned int
alphabet_base::char_to_rank_table(char)':
:7:55: warning: 'unsigned int
alphabet_base::char_to_rank_table(char)' is deprecated: message
[-Wdeprecated-declarations]
7 | return derived_type::char_to_rank[static_cast(chr)];
| ^~~
:4:40: note: declared here
4 | [[deprecated("message")]] unsigned char_to_rank_table(char const
chr)
|^~
Compiler returned: 0
```
See https://godbolt.org/z/4cWzMr
Thank you!
[Bug c++/97745] [10 Regression] ICE in tsubst_decl, at cp/pt.c:14666
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97745 --- Comment #2 from gcc-bugs at marehr dot dialup.fu-berlin.de --- This bug is fixed and can be closed. This ICE was reduced from our code base (https://github.com/seqan/seqan3/issues/2236#issuecomment-723194705).
[Bug c++/97704] [11 Regression][concepts] Not working with explicit types in function signatures?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97704 --- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Thank you, Marek Polacek for finding that revision. I checked out the master branch and reverted the commit f1612b8ae8a60f62cf5456b3357a341550534a7e and now everything compiles again. So that, regression is definitely coming from that commit.
[Bug libstdc++/97759] Could std::has_single_bit be faster?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759 --- Comment #10 from gcc-bugs at marehr dot dialup.fu-berlin.de --- And maybe a related question: I know that an arithmetic implementation might auto-vectorize, but would a popcount implementation do that too? Since AVX512_BITALG (https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=popcnt&expand=4350) retro-introduced popcount for smaller vector lengths, what is with instruction sets like AVX2 and lower?
[Bug libstdc++/97759] Could std::has_single_bit be faster?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759 --- Comment #9 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Thank you for so many responses (In reply to Thomas Koenig from comment #1) > Could you post the benchmark and the exact architecture where the arithmetic > version is faster? ``` > cat /proc/cpuinfo rocessor: 0 vendor_id : GenuineIntel cpu family : 6 model : 158 model name : Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz stepping: 9 microcode : 0xd6 cpu MHz : 3489.761 cache size : 8192 KB physical id : 0 siblings: 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d vmx flags : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple shadow_vmcs pml ept_mode_based_exec bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds bogomips: 5802.42 clflush size: 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: ``` I added the sources. You can execute it by putting it into one folder and execute ``` > cmake -DCMAKE_BUILD_TYPE=Release ./ > make VERBOSE=1 /usr/bin/c++ -I/benchmark/_deps/gbenchmark_fetch_content-src/src/../include -O3 -DNDEBUG -std=gnu++2a -o CMakeFiles/has_single_bit_benchmark.dir/has_single_bit_benchmark.cpp.o -c /benchmark/has_single_bit_benchmark.cpp ``` ``` > ./has_single_bit_benchmark --benchmark_repetitions=9 --benchmark_min_time=2 2020-11-10T00:32:52+01:00 Running ./has_single_bit_benchmark Run on (8 X 3900 MHz CPU s) CPU Caches: L1 Data 32 KiB (x4) L1 Instruction 32 KiB (x4) L2 Unified 256 KiB (x4) L3 Unified 8192 KiB (x1) Load Average: 0.57, 0.82, 1.35 ***WARNING*** CPU scaling is enabled, the benchmark real time measurements may be noisy and will incur extra overhead. --- Benchmark Time CPU Iterations --- has_single_bit_arithmetic_mean 6.45 ns 6.44 ns9 has_single_bit_arithmetic_median 6.44 ns 6.44 ns9 has_single_bit_arithmetic_stddev 0.113 ns0.111 ns9 has_single_bit_popcount_mean 8.84 ns 8.82 ns9 has_single_bit_popcount_median 8.84 ns 8.82 ns9 has_single_bit_popcount_stddev0.060 ns0.061 ns9 has_single_bit_std_mean9.23 ns 9.21 ns9 has_single_bit_std_median 9.23 ns 9.20 ns9 has_single_bit_std_stddev 0.046 ns0.048 ns9 ``` I thought about it and tried the same again with `-march=native` and noticed that popcount was now (slightly) more efficient. Some more testing showed that `-mpopcnt` is everything needed to make this test fly. --- Benchmark Time CPU Iterations --- has_single_bit_arithmetic_mean 6.81 ns 6.81 ns9 has_single_bit_arithmetic_median 6.81 ns 6.80 ns9 has_single_bit_arithmetic_stddev 0.201 ns0.200 ns9 has_single_bit_popcount_mean 6.47 ns 6.47 ns9 has_single_bit_popcount_median 6.46 ns 6.46 ns9 has_single_bit_popcount_stddev0.043 ns0.042 ns9 has_single_bit_std_mean6.50 ns 6.50 ns9 has_single_bit_std_median 6.51 ns 6.50 ns9 has_single_bit_std_stddev 0.031 ns0.031 ns9 So the use case would be generic builds like debian binaries.
[Bug libstdc++/97759] Could std::has_single_bit be faster?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759 --- Comment #7 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Created attachment 49530 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49530&action=edit CMakeLists.txt
[Bug libstdc++/97759] Could std::has_single_bit be faster?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759 --- Comment #8 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Created attachment 49531 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49531&action=edit has_single_bit_benchmark.cpp
[Bug libstdc++/97759] New: Could std::has_single_bit implementation be faster?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759 Bug ID: 97759 Summary: Could std::has_single_bit implementation be faster? Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de Target Milestone: --- Hello gcc-team, we are thrilled that C++20 offers some efficient bit implementation and that we could exchange some of our own implementation with the standardized ones, making the code more accessible. I replaced our implementation and noticed that `std::has_single_bit` was slower than what we had before by around 30%. (The other functions matched our timings.) Additionally, we have a (micro-)benchmark that compares the standard arithmetic bit trick (https://graphics.stanford.edu/~seander/bithacks.html#DetermineIfPowerOf2) with the implementation where popcount == 1. We decided to use the arithmetic version, because we measured that it was faster than popcount on our machines (mostly intel processors). Interestingly, it seems that the popcount benchmark matches the std::has_single_bit time-wise, so I guess that std::has_single_bit is implemented via popcount. Those timings could be reproduced at an unknown location https://quick-bench.com/q/Y28keu_mSh25WwhO05T4SKrbHpk I don't know how to fix this, but I would expect that the optimizer would recognize popcount=1 and knows that there is a more efficient version. Or change the implementation to arithmetic, where again the optimizer could decide to replace that by a popcount if that is more efficient on some architecture? Thank you!
[Bug c++/97704] [11 Regression][concepts] Not working with explicit types in function signatures?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97704
--- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
I forgot to add the error message:
```
: In instantiation of 'auto hard_error(t) [with t = int]':
:11:35: required by substitution of 'template requires
requires{hard_error({});} constexpr auto foo(t, non_exisiting) [with t = int]'
:19:17: required from here
:6:19: error: non-constant condition for static assertion
6 | static_assert(in, "Failure");
| ^~
:6:19: error: 'in' is not a constant expression
```
(For some reasons godbolt shows everything in the compliance view as green,
this link https://godbolt.org/z/Go8Mc5 should also show the compiler error)
[Bug c++/96872] [11 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96872 --- Comment #2 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Thank you; was fixed!
[Bug c++/97704] New: [11 Regression][concepts] Not working with explicit types in function signatures?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97704
Bug ID: 97704
Summary: [11 Regression][concepts] Not working with explicit
types in function signatures?
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hi gcc-team,
consider the following program:
```c++
struct non_exisiting {};
template
auto hard_error(t in)
{
static_assert(in, "Failure");
return;
}
template
requires requires { hard_error(t{}); }
constexpr auto foo(t, non_exisiting);
template
constexpr auto foo(t, bool) { return false; };
int main()
{
foo(0, false);
};
```
This worked since at least g++-7 up until g++-10.2, works with clang (11 and
trunk), as well as msvc.
I would expect that `foo(t, non_exisiting)` will not be considered, because it
would not be meaningful in this case (`bool` is not of type `non_exisiting` and
there is no conversion sequence from `bool` to `non_exisiting`).
See https://godbolt.org/z/3W5eG8
I hope this is a bug and not intended behaviour, because I encountered this
problem by using a range adaptor from the stdlib inside a templated class which
all of a sudden found `operator|` (a hidden friend of that range adaptor) by
ADL even though that operator did not match signature-wise.
If this is intended behaviour, what in world is the type of the second
parameter of `foo(t, non_exisiting)`?
Thank you!
