[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 , deep const ) {
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 , deep const )
{
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=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=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=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!
[Bug c++/96872] New: [11 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96872
Bug ID: 96872
Summary: [11 Regression] ICE: Segmentation fault
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 ices
```
template struct concat_view {
struct {
template using constify_if = int;
using concat_view_t = constify_if;
};
};
```
https://godbolt.org/z/db3qq6
with
> g++-git -std=c++2a
and outputs
```
ice.cpp: In substitution of ‘template template using constify_if
= int [with = concat_view< >;
= ]’:
ice.cpp:4:50: required from here
ice.cpp:4:50: internal compiler error: Segmentation fault
4 | using concat_view_t = constify_if;
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.archlinux.org/> for instructions.
```
[Bug c++/96863] New: [11 Regression] ICE: in output_constructor_regular_field, at varasm.c:5223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96863
Bug ID: 96863
Summary: [11 Regression] ICE: in
output_constructor_regular_field, at varasm.c:5223
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 ices:
```c++
#include
namespace seqan3 {
template struct pipeable_config_element;
template
struct pipeable_config_element {};
template struct pipeable_config_element {
value_t value;
};
struct gap_scheme {
int gap = 1;
};
template
struct configuration : std::tuple {
template
constexpr configuration(pipeable_config_element const) {}
template constexpr configuration(std::tuple<> const) {}
template
constexpr auto push_back(config_element_t) const {
return configuration{std::tuple{}};
}
};
template
configuration(pipeable_config_element const)
-> configuration;
} // namespace seqan3
namespace seqan3::align_cfg {
template
struct gap : pipeable_config_element, gap_scheme_t> {
gap() = default;
constexpr gap(gap_scheme_t const)
: pipeable_config_element() {}
};
} // namespace seqan3::align_cfg
namespace seqan3::detail {
struct method_local_tag : pipeable_config_element {};
} // namespace seqan3::detail
namespace seqan3::align_cfg {
seqan3::detail::method_local_tag method_local;
template
struct scoring_scheme : pipeable_config_element {
scoring_scheme() = default;
constexpr scoring_scheme(scoring_scheme_t) {};
};
struct aminoacid_scoring_scheme {};
template struct alignment_fixture { config_t config; };
template
alignment_fixture(config_t) -> alignment_fixture;
inline constexpr auto align_config =
seqan3::configuration{seqan3::align_cfg::method_local}.push_back(
seqan3::align_cfg::gap{seqan3::gap_scheme{}});
static auto aa27_02 = [] {
return alignment_fixture{align_config.push_back(
seqan3::align_cfg::scoring_scheme{aminoacid_scoring_scheme{}})};
}();
} // namespace seqan3::align_cfg
```
https://godbolt.org/z/M4Mh1f
with
> g++-git -std=c++2a
error:
```
ice.cpp:55:1: internal compiler error: in output_constructor_regular_field, at
varasm.c:5223
55 | } // namespace seqan3::align_cfg
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.archlinux.org/> for instructions.
```
[Bug lto/96591] New: ICE with -flto=auto and -O1: tree code ‘typename_type’ is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96591
Bug ID: 96591
Summary: ICE with -flto=auto and -O1: tree code ‘typename_type’
is not supported in LTO streams
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hi gcc-team,
I'm not sure if this is the right component.
The following code:
```c++
template
struct builtin_simd
{
using type [[gnu::vector_size(sizeof(scalar_t) * length)]] = scalar_t;
};
struct simd_traits
{
using scalar_type = int;
template
using rebind = typename builtin_simd::type;
};
template
constexpr simd_t fill(typename simd_traits::scalar_type const scalar)
{
return simd_t{scalar};
}
class Test
{
using score_type = typename builtin_simd::type;
score_type data[1]{fill(8)};
};
struct TestFactoryBase
{
virtual Test *CreateTest() = 0;
};
template
struct TestFactoryImpl : public TestFactoryBase
{
Test *CreateTest() override { return new TestClass; }
};
void MakeAndRegisterTestInfo(TestFactoryBase *factory);
int main() {
MakeAndRegisterTestInfo(new TestFactoryImpl);
}
```
https://godbolt.org/z/55xTod
produces with
> > g++ -O1 -flto=auto ice.cpp
> during IPA pass: pure-const
> ice.cpp:42:1: internal compiler error: tree code ‘typename_type’ is not
> supported in LTO streams
>42 | }
> | ^
> Please submit a full bug report, with preprocessed source if appropriate.
> See <https://bugs.archlinux.org/> for instructions.
that error.
Some notes:
* removing "using rebind = typename builtin_simd::type;" or
* removing "constexpr" from constexpr simd_t fill(typename
simd_traits::scalar_type const scalar)
will make it compile.
Thank you!
[Bug libstdc++/95322] std::list | take | transform, expression does not work cbegin() == end()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322 --- Comment #15 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Thank you!
[Bug c++/95497] [11 Regression] ICE: concepts with a fully known / complete type in requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95497 --- Comment #4 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Thank you for fixing!
[Bug libstdc++/96113] std::vector | std::views::drop_while, cbegin does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96113 gcc-bugs at marehr dot dialup.fu-berlin.de changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Ah, thank you, you are right! I always forget that they are cached in the view when calling begin and not when constructing the view. This makes the view strictly speaking still not amortized constant, but helps to reduce the runtime on multiple invocations of `begin`. The question is if `std::views::reverse_view`, which basically makes it a common range, can recover the const-iterability. Like it can do for sized-ranges. I have just seen that `std::views::reverse_view` requires a common_range for const overloads of begin/end, this might be my original use case, because I have a const-iterable, bi-directional view with a sentinel. But since the standard explicitly drops the const-iterability when using `drop_while` / non-common views for `reverse_view`, I think this issue can be closed. Thank you!
[Bug libstdc++/96113] std::vector | std::views::drop_while, cbegin does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96113
gcc-bugs at marehr dot dialup.fu-berlin.de changed:
What|Removed |Added
Summary|std::vector | |std::vector |
|std::views::drop_while ||std::views::drop_while,
|std::views::reverse, cbegin |cbegin does not work
|does not work |
--- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Sorry, we have a view which is similar to `std::views::drop_while` where I
could just replace the name and it gave me the same error, but using
`std::views::drop_while` gives me the error already without the reverse. So I
changed the ticket.
```c++
#include
#include
int main()
{
std::vector text1{};
auto drop_none = [](auto const &) constexpr { return false; };
auto accept_any = [](auto const &) constexpr { return true; };
auto && view1 = text1 | std::views::reverse;
auto && view2 = text1 | std::views::drop_while(drop_none);
auto && view3 = text1 | std::views::take_while(accept_any);
auto && view4 = text1 | std::views::filter(accept_any);
std::ranges::cbegin(view1);
std::ranges::cbegin(view2); // does not work
std::ranges::cbegin(view3);
std::ranges::cbegin(view4); // does not work
}
```
(https://godbolt.org/z/E97_Tq)
[Bug libstdc++/96113] New: std::vector | std::views::drop_while | std::views::reverse, cbegin does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96113
Bug ID: 96113
Summary: std::vector | std::views::drop_while |
std::views::reverse, cbegin does not work
Product: gcc
Version: 10.1.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 does not compile:
```
#include
#include
int main()
{
std::vector text1{};
auto && view = text1
| std::views::drop_while([](auto const &){ return false; })
| std::views::reverse;
std::ranges::cbegin(view);
}
```
with `g++-10 -std=c++2a` (see https://godbolt.org/z/adxYy-)
Thank you!
[Bug libstdc++/96070] New: std::views::* won't work with non-legacy iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96070
Bug ID: 96070
Summary: std::views::* won't work with non-legacy iterators
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,
not long ago a filed a bug-report[1] that
`std::ranges::basic_istream_view::iterator` has no `std::iterator_traits`
entry.
> Your mistake is thinking that the iterators of views are like the iterators
> you're used to.
It seems that not only I had that problem, because this has some interesting
consequences for the standard, for example the
`std::ranges::filter_view::iterator` is described as [2]:
> 3 iterator::iterator_category is defined as follows:
> (3.1) Let C denote the type
> iterator_traits>::iterator_category.
> (3.2) If C models derived_from, then
> iterator_category denotes bidirectional_iterator_tag.
> (3.3) Otherwise, if C models derived_from, then
> iterator_category denotes forward_iterator_tag.
> (3.4) Otherwise, iterator_category denotes C.
This assumes that `iterator_traits>::iterator_category` is
defined which is not true for all iterators, like
`std::ranges::basic_istream_view::iterator`.
A quick check with the gcc stdlib implementation:
```c++
#include
#include
#include
int main()
{
// using input_view_t = std::vector &; // works
using input_view_t = std::ranges::basic_istream_view>; // does not work
auto accept_all = [](auto &&){return true;};
using filter_input_view_t = decltype(std::declval() |
std::views::filter(accept_all));
using filter_iterator_t = std::ranges::iterator_t;
}
```
https://godbolt.org/z/Uozktw
And yes it does not work.
Since I don't know of a generic way to conditionally include/exclude `using
iterator_category = some_tag`, I think the easiest way would to allow
`iterator_category = void`.
We would need to change the behaviour of `std::iterator_traits`. We should not
only check whether all 4 members are available, but also that
`iterator_category` is at least an input_iterator_tag or an
output_iterator_tag. Or alternatively check that `iterator_category` is
non-void.
I don't know how to create a LWG issue and if this problem was already
reported, but I hope you can create one like in my last finding [3].
If this defect was not reported yet, it would be nice to at least link back to
this issue and not just write "A user reported that this doesn't compile: ".
[1] - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94674
[2] - https://eel.is/c++draft/range.filter.iterator#3
[3] - https://cplusplus.github.io/LWG/issue3448
[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96042 --- Comment #2 from gcc-bugs at marehr dot dialup.fu-berlin.de --- I think this is too easy to say that this is not a "bug", we can also weaken the terminology and say "potential-inconsistency". Technically you are right, but only because there seems to be a specific "exception" for the implementation does not mean that this is the right thing to do. I personally don't understand why the standard allows exceptions outside it's echo-system, I guess the stdlib implementers understand the subject better when forming the standard, and are lobbing harder for their necessities which is sometimes different from the needs / expectation of the end-user. Can you help me figure out in which cases `-std=c++2a` would produce this type? Or asked differently: In which cases, other than this, do I encounter a `__int128` from using only types and functions defined in the standard? I have the feeling from your answer that this type is an everyday type. Looking at https://eel.is/c++draft/range.iota#view-1, and if I read it correctly, this is case 3: > Otherwise, IOTA-DIFF-T(W) is an unspecified signed-integer-like type > ([iterator.concept.winc]) of width not less than the width of W. > > [Note: It is unspecified whether this type satisfies > weakly_incrementable. — end note] It means it would be totally fine to return the signed version of `size_t`, because it has at least the same width. (This would be a valid option, too) Thank you for your time!
[Bug libstdc++/96042] New: Reference type of std::ranges::iota is __int128 with -std=c++2a?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96042 Bug ID: 96042 Summary: Reference type of std::ranges::iota is __int128 with -std=c++2a?! Product: gcc Version: 10.1.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: --- The following code ```c++ #include using iota_view = std::ranges::iota_view; using reference_t = std::ranges::range_difference_t; static_assert(std::same_as); // why? // but std::numeric_limits is not specialised which indicates that we use __STRICT_ANSI__ using t = std::numeric_limits<__int128>; static_assert(t::is_specialized); ``` https://godbolt.org/z/-XFyYN I don't fully understand what `__int128` and `__STRICT_ANSI__` means, but I think it is unexpected that I get a type that is not described in the standard. I know that `std::indirectly_readable` allows (compiler) implementation defined signed integer types, but from what I have seen, `__int128` is normally only supported / exposed in the gnu standard library if `__STRICT_ANSI__` is not defined. Since `-std=c++2a` does not provide a specialisation for `std::numeric_limits`, I assume that this means, that `__STRICT_ANSI__` is not defined in that mode, and I think this is inconsistent behaviour. Related issues in the range-v3 library: * https://github.com/ericniebler/range-v3/issues/1514 * https://github.com/ericniebler/range-v3/issues/1516
[Bug libstdc++/95578] std::ranges::copy and std::views::take_while don't want to play together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95578 --- Comment #5 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Thank you for the quick response and quick fix :)
[Bug c++/95578] New: std::ranges::copy and std::views::take_while don't want to play together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95578
Bug ID: 95578
Summary: std::ranges::copy and std::views::take_while don't
want to play together
Product: gcc
Version: 10.1.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 does not compile (10.1.0 and trunk)
```c++
#include
#include
int main()
{
std::vector v{};
// auto && rng = v; // does work
auto && rng = v | std::views::take_while([](auto &&){return true;}); //
does not work
std::vector rng_copy{};
std::ranges::copy(rng, std::back_inserter(rng_copy));
return 0;
}
```
https://godbolt.org/z/nmRQgo
[Bug c++/95497] New: [11 Regression] ICE: concepts with a fully known / complete type in requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95497
Bug ID: 95497
Summary: [11 Regression] ICE: concepts with a fully known /
complete type in requires
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 ICEs starting with gcc-11:
```c++
template
struct A{};
template
concept c =
requires(T t, A b) // note that A is independent of T
{
{ t += b };
};
```
https://godbolt.org/z/pQI1ee
Thank you!
[Bug c++/95371] New: [10 Regression] ICE concepts with template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95371
Bug ID: 95371
Summary: [10 Regression] ICE concepts with template template
parameter
Product: gcc
Version: 10.1.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: ---
Hallo gcc-team,
the following code worked with gcc9, but ICEs with gcc 10.1 and in trunk
```c++
template
struct configuration {
template typename query_t>
static constexpr bool exists() { return true; }
template typename query_t>
void remove() requires(exists());
};
int main() {
configuration<> cfg{};
cfg.remove();
}
```
https://godbolt.org/z/NGU5i9
```
> g++-10 -std=c++2a
: In function 'int main()':
:12:31: internal compiler error: Segmentation fault
12 | cfg.remove();
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler returned: 1
```
[Bug libstdc++/95322] New: std::list | take | transform, expression does not work cbegin() == end()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322
Bug ID: 95322
Summary: std::list | take | transform, expression does not work
cbegin() == end()
Product: gcc
Version: 10.1.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,
I'm not sure if this is intended behaviour, or if this is a defect in the
standard, or something that you should never write in a generic context.
ASFAIK you can use that expression on any container and on any view, but not on
some(?!) combinations of views? This is a bit unexpected.
```c++
#include
#include
#include
int main()
{
std::list v{0,1 ,2, 3, 4, 5, 5, 6}; // works if std::vector
auto view1 = v | std::views::take(5);
auto view2 = v | std::views::transform([] (int i) { return i + 3;});
auto view3 = view1 | std::views::transform([] (int i) { return i + 3;});
std::ranges::cbegin(view1) == std::ranges::end(view1); // works
std::ranges::cbegin(view2) == std::ranges::end(view2); // works
std::ranges::cbegin(view3) == std::ranges::end(view3); // does not work
return 0;
}
```
https://godbolt.org/z/4Nzr69
[Bug libstdc++/93983] std::filesystem::path is not concept-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983
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 #6 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
It seems that I hit the same issue when making us of ranges:
```c++
#include
#include
static_assert(std::input_iterator);
struct alignment_file_input
{
alignment_file_input(std::filesystem::path);
template
alignment_file_input(stream_t);
int* begin();
int* end();
};
static_assert(std::ranges::input_range);
int main()
{
alignment_file_input fin{int{}};
auto && view = fin | std::views::take(1);
}
```
https://godbolt.org/z/__hw9w
[Bug c++/94819] [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't Pt. 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94819
--- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
A slightly more reduced example:
```c++
#include
template
struct alphabet_tuple_base
{
template
requires std::is_same_v
constexpr alphabet_tuple_base(component_type) {} // commenting out
constexpr works?!
template
requires (!std::is_same_v)
alphabet_tuple_base(indirect_component_type) {};
};
template
struct structured_rna : alphabet_tuple_base {
using base_type = alphabet_tuple_base;
using base_type::base_type;
};
struct dna4 {};
struct rna4 {};
structured_rna t1{rna4{}}; // commenting out any of these works?!
structured_rna t2{dna4{}}; // commenting out any of these works?!
structured_rna t3{rna4{}}; // commenting out any of these works?!
```
https://godbolt.org/z/VACou9
[Bug c++/94819] New: [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't Pt. 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94819
Bug ID: 94819
Summary: [10 Regression] Inherited and constrained constructors
are "ambiguous" even if they aren't Pt. 2
Product: gcc
Version: 10.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,
a recent report of mine https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94549
fixed my reduced example, but my unreduced test case is still failing.
This is the second attempt at reducing my test case and this came out of it:
```c++
#include
template
concept same_as = std::is_same_v;
template
concept convertible_to = std::is_convertible_v;
template
struct alphabet_tuple_base
{
template
static constexpr bool is_component = (same_as ||
...);
template
static constexpr bool is_indirect_component = !is_component &&
(convertible_to || ...);
// commenting out constexpr works?!
template
requires is_component
constexpr alphabet_tuple_base(component_type) {}
template
requires is_indirect_component
alphabet_tuple_base(indirect_component_type);
};
template
struct structured_rna : alphabet_tuple_base {
using base_type = alphabet_tuple_base;
using base_type::base_type;
};
struct dna4 {};
struct rna4 {
rna4(dna4);
};
struct wuss51 {};
// commenting out any of these works?!
structured_rna t1{wuss51{}};
structured_rna t2{dna4{}};
structured_rna t3{wuss51{}};
```
https://godbolt.org/z/WVvSxb
Note that `is_component` and `is_indirect_component` are mutual exclusive, so
there isn't any ambiguity even if they don't subsume each other.
This worked in gcc-9 with `-fconcepts` and apparently in msvc and clang, too.
```
> g++-git -std=c++2a
:41:41: error: call of overloaded 'structured_rna()' is ambiguous
41 | structured_rna t3{wuss51{}}; // commenting out any of
these works?!
| ^
:20:15: note: candidate: 'constexpr
alphabet_tuple_base::alphabet_tuple_base(component_type) [with
component_type = wuss51; component_types = {rna4, wuss51}]'
20 | constexpr alphabet_tuple_base(component_type) {} // commenting out
constexpr works?!
| ^~~
:30:20: note: inherited here
30 | using base_type::base_type;
|^
:24:5: note: candidate:
'alphabet_tuple_base::alphabet_tuple_base(indirect_component_type)
[with indirect_component_type = indirect_component_type; component_types =
{rna4, wuss51}]'
24 | alphabet_tuple_base(indirect_component_type);
| ^~~
:30:20: note: inherited here
30 | using base_type::base_type;
|^
:28:8: note: candidate: 'constexpr structured_rna::structured_rna(const structured_rna&)'
28 | struct structured_rna : alphabet_tuple_base {
|^~
:28:8: note: candidate: 'constexpr structured_rna::structured_rna(structured_rna&&)'
Compiler returned: 1
```
[Bug c++/94772] New: [10 Regression] constructing constexpr variables fail with delegated constexpr constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94772
Bug ID: 94772
Summary: [10 Regression] constructing constexpr variables fail
with delegated constexpr constructors
Product: gcc
Version: 10.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!
The following code does not compile with gcc10 anymore:
```c++
struct foo
{
constexpr foo() noexcept = default;
// fails with gcc10; commenting : foo{} out works with gcc10
constexpr foo(int a, int b) : foo{}
{
bar += a + b;
}
int bar{};
};
int main()
{
constexpr foo bar{1, 2};
}
```
https://godbolt.org/z/brsFdo
All major compilers and gcc < 10 do support this, so I think this is a
regression.
```
> g++-git -std=c++2a
: In function 'int main()':
:15:27: in 'constexpr' expansion of 'foo(1, 2)'
:8:13: error: modifying a const object '((foo*)this)->foo::bar' is not
allowed in a constant expression
8 | bar += a + b;
| ^~~~
:15:19: note: originally declared 'const' here
15 | constexpr foo bar{1, 2};
|
```
Thank you!
[Bug libstdc++/94674] std::ranges::basic_istream_view::iterator is missing std::iterator_traits entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94674 --- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Thank you for pointing me to this. I find this highly unexpected. There was made a change to `std::type_traits` in C++20 that sets default values, but it does not apply to all iterators? My use case was slightly different, I wanted to extract the `pointer` member type and there is no equivalent like `std::ranges::range_pointer_t` for that. This makes it particularly cumbersome to "forward" properties of an underlying iterator which is used when wrapping it in a new iterator.
[Bug c++/94674] New: std::ranges::basic_istream_view::iterator is missing std::iterator_traits entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94674
Bug ID: 94674
Summary: std::ranges::basic_istream_view::iterator is missing
std::iterator_traits entries
Product: gcc
Version: 10.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,
I'm not sure if I should have named the issue `std::iterator_traits is missing
default values for an iterator` (https://eel.is/c++draft/iterator.traits#3.2).
Maybe I misunderstood this, but I thought that I can query every iterator for
it's traits.
The following code does not work:
```c++
#include
#include
#include
int main()
{
// std::string_view view; // does work
auto && view = std::ranges::basic_istream_view>{}; // does not work
// auto && view = std::ranges::take_view{}; // does work
using iterator_t = std::ranges::iterator_t;
using iter_value1_t = std::iter_value_t;
using iter_value2_t = typename
std::iterator_traits::value_type;
static_assert(std::same_as);
return 0;
}
```
with `g++-10 -std=c++2a`
https://godbolt.org/z/QAfdml
[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 #1 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
After playing with this a bit more, I found out that clang actually behaves
differently:
```c++
#include
#include
template
concept same_as = std::is_same_v;
template
concept foo = requires(t v)
{
{v} -> same_as;
};
// all of them work with gcc and msvc
static_assert(foo); // fails with clang
static_assert(foo); // fails with clang
static_assert(foo); // fails with clang
static_assert(foo);
static_assert(foo);
```
https://godbolt.org/z/MGpfZF
I created an issue at https://bugs.llvm.org/show_bug.cgi?id=45622
[Bug c++/94673] New: [concepts] What is the return type of local parameters of requires expressions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94673
Bug ID: 94673
Summary: [concepts] What is the return type of local parameters
of requires expressions?
Product: gcc
Version: 10.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: ---
What should I expect when I write the following concept:
```c++
#include
#include
template
concept same_as = std::is_same_v;
template
concept foo = requires(t v)
{
{v} -> same_as;
};
static_assert(foo); // gcc 9 / clang
static_assert(foo); // clang
static_assert(foo); // clang
```
https://godbolt.org/z/rRkCzE
* clang says that the type of the expression `v` is `t`.
* gcc 9 partially agreed on this for `foo`.
* gcc 10 rejects all of them
* msvc has the same opinion as gcc10, but also fails to provide an answer why.
gcc10 gives me an (improvable?) reason why the concept failed:
```
:13:15: note: constraints not satisfied
:8:9: required by the constraints of 'template concept foo'
:8:15: in requirements with 'int v'
:10:6: note: 'v' does not satisfy return-type-requirement
```
[Bug c++/94549] New: [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94549
Bug ID: 94549
Summary: [10 Regression] Inherited and constrained constructors
are "ambiguous" even if they aren't
Product: gcc
Version: c++-concepts
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: ---
The following code worked until gcc 10:
```c++
struct base {
template
requires false
base(type);
template
requires true
base(type);
};
struct derived : base {
using base::base;
};
int main() { derived{'G'}; }
```
All other major compilers supporting concepts accept this example, see
https://godbolt.org/z/cabrpc
but gcc10 produces
```
> g++-git -std=c++2a ice.cpp
ice.cpp: In function ‘int main()’:
ice.cpp:15:25: error: call of overloaded ‘derived()’ is ambiguous
15 | int main() { derived{'G'}; }
| ^
ice.cpp:4:3: note: candidate: ‘base::base(type)’
4 | base(type);
| ^~~~
ice.cpp:12:15: note: inherited here
12 | using base::base;
| ^~~~
ice.cpp:8:3: note: candidate: ‘base::base(type)’
8 | base(type);
| ^~~~
ice.cpp:12:15: note: inherited here
12 | using base::base;
| ^~~~
ice.cpp:11:8: note: candidate: ‘constexpr derived::derived(const derived&)’
11 | struct derived : base {
|^~~
ice.cpp:11:8: note: candidate: ‘constexpr derived::derived(derived&&)’
```
My gcc version is
```
> g++-git -v
Using built-in specs.
COLLECT_GCC=g++-git
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-git/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/marehr/Packages/gcc-git/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto --disable-boostrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200326 (experimental) (GCC)
```
[Bug ipa/93799] New: [10 Regression] ice in propagate_vals_across_arith_jfunc, at ipa-cp.c:2039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93799
Bug ID: 93799
Summary: [10 Regression] ice in
propagate_vals_across_arith_jfunc, at ipa-cp.c:2039
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
CC: marxin at gcc dot gnu.org
Target Milestone: ---
The following code ICEs
```c++
struct search_param {
int total;
};
void search_trivial(search_param error_left) {
search_trivial(error_left);
search_param error_left2{error_left};
error_left2.total--;
search_trivial(error_left2);
}
void search_algo_uni(search_param error_left) { search_trivial(error_left); }
void search_algo(search_param error_left) { search_algo_uni(error_left); }
int main() { search_algo({}); return 0; }
```
https://godbolt.org/z/aPnCGi
with
```
> g++-git -O3 -c ice.cpp
during IPA pass: cp
ice.cpp:12:41: internal compiler error: in propagate_vals_across_arith_jfunc,
at ipa-cp.c:2039
12 | int main() { search_algo({}); return 0; }
| ^
0x639286 propagate_vals_across_arith_jfunc
/home/marehr/Packages/gcc-git/src/gcc/gcc/ipa-cp.c:2039
0x14d5f24 propagate_aggregate_lattice
/home/marehr/Packages/gcc-git/src/gcc/gcc/ipa-cp.c:2690
0x14d5f24 propagate_aggs_across_jump_function
/home/marehr/Packages/gcc-git/src/gcc/gcc/ipa-cp.c:2781
0x14d5f24 propagate_constants_across_call
/home/marehr/Packages/gcc-git/src/gcc/gcc/ipa-cp.c:2875
0x14d62a6 propagate_constants_topo
/home/marehr/Packages/gcc-git/src/gcc/gcc/ipa-cp.c:3794
0x14da490 ipcp_propagate_stage
/home/marehr/Packages/gcc-git/src/gcc/gcc/ipa-cp.c:3910
0x14da490 ipcp_driver
/home/marehr/Packages/gcc-git/src/gcc/gcc/ipa-cp.c:5899
0x14da490 execute
/home/marehr/Packages/gcc-git/src/gcc/gcc/ipa-cp.c:5992
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.archlinux.org/> for instructions.
```
This might be the same ICE as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93763, but I reported it as a new
issue, because they have different stack-traces.
```
> g++-git -v
Using built-in specs.
COLLECT_GCC=g++-git
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-git/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/marehr/Packages/gcc-git/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto --disable-boostrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200217 (experimental) (GCC)
```
[Bug c++/93667] [10 regression] ICE in esra with nested [[no_unique_address]] field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667 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 #1 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Is this a duplicate / variant of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93516?
[Bug c++/93664] New: ICE: Segmentation fault on invalid concept code gcc/gcc/cp/constraint.cc:2537
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93664
Bug ID: 93664
Summary: ICE: Segmentation fault on invalid concept code
gcc/gcc/cp/constraint.cc:2537
Product: gcc
Version: 10.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,
this (invalid!) code ICEs:
```c++
#include
#include
template
concept bool semiregular = requires(T t) {
{(t != t)};
};
template concept bool view_ = semiregular;
template concept bool is_true = B;
// this part is invalid, commenting in =, or
// ommiting bool resolves the ICE
template
concept bool
pair_like_convertible_from_ /*=*/ (is_true);
template
struct subrange {
template
requires pair_like_convertible_from_
operator PairLike();
};
int main() {
subrange> sub;
view_;
}
```
https://godbolt.org/z/c__ob5
When replacing all `concept bool` with `concept` the ICE vanishes.
```
> g++-git --std=c++2a
ice.cpp: In instantiation of ‘subrange::operator PairLike() [with PairLike =
const std::error_condition; I = std::istreambuf_iterator >]’:
ice.cpp:6:7: required from here
ice.cpp:6:7: internal compiler error: Segmentation fault
6 | {(t != t)};
|~~~^
0xc8026f crash_signal
/home/marehr/Packages/gcc-git/src/gcc/gcc/toplev.c:328
0x69819d force_rvalue(tree_node*, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/cvt.c:564
0x6834c2 satisfy_constraint_r
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2537
0x683bf8 satisfy_constraint
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2599
0x6845c4 satisfy_declaration_constraints
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2617
0x6850e8 constraint_satisfaction_value
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2733
0x6850e8 constraints_satisfied_p(tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2754
0x6511f2 add_function_candidate
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:2281
0x6537fc add_template_candidate_real
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3440
0x653d86 add_template_candidate
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3481
0x653d86 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5829
0x64f0b5 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5744
0x64f0b5 build_user_type_conversion_1
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:4079
0x64fb43 reference_binding
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:1843
0x650121 implicit_conversion
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:1992
0x650e79 add_function_candidate
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:2389
0x653dc4 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5842
0x654357 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5744
0x654357 add_operator_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5933
0x659344 build_new_op_1
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:6156
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.archlinux.org/> for instructions.
```
```
> g++-git -v
Using built-in specs.
COLLECT_GCC=g++-git
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-git/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/marehr/Packages/gcc-git/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto --disable-boostrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200206 (experimental) (GCC)
```
[Bug c++/93345] [10 Regression] ICE in nothrow_spec_p, at cp/except.c:1247
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93345
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 #7 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Hi Jason Merrill,
I have the following gcc-9 code:
```
template concept bool a = true;
template struct b {};
template using c = b>;
struct h {
template auto operator()(g) noexcept(noexcept(c{})) {}
};
template concept bool e = requires(d f) { h{}(f); };
static_assert(e);
```
that ICEs at the same location:
```
> g++ -std=c++17 -fconcepts -c ice.cpp
ice.cpp:7:59: internal compiler error: in nothrow_spec_p, at cp/except.c:1247
7 | template concept bool e = requires(d f) { h{}(f); };
|~~~^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.archlinux.org/> for instructions.
```
Is this a dupe of this? or should I create a new issue? A gcc-10 build of mine
seems to compile it. So this patch might need to be backported to gcc9.
```
> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.0 (GCC)
```
[Bug c++/93400] New: [10 Regression] ICE: in tsubst, at cp/pt.c:15142 on friends with concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93400
Bug ID: 93400
Summary: [10 Regression] ICE: in tsubst, at cp/pt.c:15142 on
friends with concepts
Product: gcc
Version: 10.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: ---
The following code ICEs on a recent gcc-10 build, but worked in gcc 9 and
below:
```
template bool a = true;
template concept b = a;
template struct f { template friend auto g(c, f); };
auto d = f<1>{};
auto e = f<0>{};
```
https://godbolt.org/z/A5xXyR
With the following error:
```
> g++-git -std=c++2a -c ice.cpp // and -std=c++17 -fconcepts
ice.cpp: In instantiation of ‘struct f<0>’:
ice.cpp:5:15: required from here
ice.cpp:3:54: internal compiler error: in tsubst, at cp/pt.c:15142
3 | template struct f { template friend auto g(c, f); };
| ^
0x602fb4 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:15142
0x7723f5 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:13125
0x76a73c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:19022
0x7630c4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:18955
0x7630c4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:18590
0x6825f6 tsubst_constraint(tree_node*, tree_node*, int, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2349
0x781d6f tsubst_friend_function
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:10846
0x781d6f instantiate_class_template_1
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:11975
0x7823e2 instantiate_class_template(tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:12040
0x7b242d complete_type(tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/typeck.c:137
0x7b242d complete_type(tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/typeck.c:111
0x790cb9 finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/semantics.c:2929
0x71cf1d cp_parser_functional_cast
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:29405
0x734044 cp_parser_postfix_expression
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:7134
0x718aca cp_parser_binary_expression
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:9508
0x71a12c cp_parser_assignment_expression
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:9813
0x71927d cp_parser_constant_expression
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:10107
0x7197e1 cp_parser_initializer_clause
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:23108
0x71d04f cp_parser_initializer
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:23046
0x742b94 cp_parser_init_declarator
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:20752
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.archlinux.org/> for instructions.
```
gcc version being:
```
g++-git -v
Using built-in specs.
COLLECT_GCC=g++-git
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-git/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/marehr/Packages/gcc-git/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto --disable-boostrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200123 (experimental) (GCC)
```
[Bug c++/93324] [10 Regression] ICE with -Wall on constexpr if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93324 --- Comment #5 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Thank you! I can confirm it being fixed <3
[Bug c++/92541] ICE when concept requires contextual conversion to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92541 --- Comment #4 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Oh okay, how should I proceed? Create a new issue or hijack this one?
[Bug c++/92541] ICE when concept requires contextual conversion to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92541
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 #1 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Is this a variant of the same ICE?
```
template bool a = true;
template concept b = a;
template struct f { template friend auto g(c, f); };
auto d = f<1>{};
auto e = f<0>{};
```
https://godbolt.org/z/A5xXyR
[Bug c++/93377] New: [10 Regression] ICE in tsubst_pack_expansion, at cp/pt.c:12852
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93377
Bug ID: 93377
Summary: [10 Regression] ICE in tsubst_pack_expansion, at
cp/pt.c:12852
Product: gcc
Version: 10.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: ---
The following code worked in gcc9 and below, but fails with a recent snapshot
of gcc
```c++
struct empty
{};
template
c value;
template
auto func(value);
template
struct alignment_algorithm;
template
struct select
{
template
decltype(algorithm_t()(func<_args_t>...)) choose();
template
static empty choose();
using type = decltype(choose, args_t...>());
};
template
struct select_algorithm : select
{};
template struct maybe_value { int value; };
template
struct maybe_value;
struct function
{
template >::value)>
function(algorithm_t);
};
template
struct alignment_configuration_traits
{
static constexpr bool is_vectorised = 0;
};
template
struct alignment_algorithm
{
using traits_t = alignment_configuration_traits;
template
void operator()(indexed_sequence_pairs_t) requires traits_t::is_vectorised;
};
int main()
{
function{alignment_algorithm{}};
}
```
(I couldn't reduce it any more, maybe someone else can help with it)
produces the following ICE (https://godbolt.org/z/6uK11R):
```
> g++-git -std=c++17 -fconcepts -c ice.cpp // or g++-git -std=c++2a -c ice.cp
ice.cpp: In instantiation of ‘void alignment_algorithm<
,
>::operator()(indexed_sequence_pairs_t) requires traits_t...>::is_vectorised [with indexed_sequence_pairs_t =
int; config_t = int; = {}]’:
ice.cpp:17:25: required by substitution of ‘template decltype (algorithm_t()(func<_args_t>...))
select::choose() [with algorithm_t =
alignment_algorithm; _args_t = {int}]’
ice.cpp:22:68: required from ‘struct select’
ice.cpp:37:13: recursively required by substitution of ‘template
struct maybe_value [with cn =
select_algorithm, int>]’
ice.cpp:37:13: required by substitution of ‘template function::function(algorithm_t) [with algorithm_t =
alignment_algorithm; = ]’
ice.cpp:58:40: required from here
ice.cpp:17:25: internal compiler error: in tsubst_pack_expansion, at
cp/pt.c:12852
17 | decltype(algorithm_t()(func<_args_t>...)) choose();
|~^~
0x601131 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:12852
0x770121 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:13111
0x775368 tsubst_argument_pack(tree_node*, tree_node*, int, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:13073
0x7700f4 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:13123
0x76c46a tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:14985
0x777997 tsubst_qualified_id
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:16002
0x76742f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:19259
0x760e34 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:18932
0x760e34 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:18590
0x681222 satisfy_constraint_r
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2499
0x681998 satisfy_constraint
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2575
0x682c14 satisfy_declaration_constraints
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2593
0x682ed8 constraint_satisfaction_value
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2708
0x682ed8 constraints_satisfied_p(tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2729
0x64f2c1 add_function_candidate
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:2281
0x65175c add_template_candidate_real
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3440
0x651ce6 add_template_candidate
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3481
0x651ce6 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5827
0x656d14 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5742
0x656d14 build_op_call_1
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:4777
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.ar
[Bug c++/93324] New: [10 Regression] ICE with -Wall on constexpr if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93324
Bug ID: 93324
Summary: [10 Regression] ICE with -Wall on constexpr if
Product: gcc
Version: 10.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: ---
The following code works on gcc 9 and below, but ICEs on gcc10 with -Wall.
```
struct
{
template
static constexpr bool a() { return 0; }
} e;
template
void d()
{
auto c(e);
using b = decltype(c);
if constexpr (b::a<2>());
}
```
See godbolt: https://godbolt.org/z/3wEnL7
```
> g++-git -std=c++17 -Wall -c ice.cpp
ice.cpp: In function ‘void d()’:
ice.cpp:12:26: internal compiler error: Segmentation fault
12 | if constexpr (b::a<2>());
| ^
0xc7230f crash_signal
/home/marehr/Packages/gcc-git/src/gcc/gcc/toplev.c:328
0x783eca fndecl_built_in_p(tree_node const*, built_in_class)
/home/marehr/Packages/gcc-git/src/gcc/gcc/tree.h:6208
0x783eca fndecl_built_in_p(tree_node const*, unsigned int, built_in_class)
/home/marehr/Packages/gcc-git/src/gcc/gcc/tree.h:6217
0x783eca is_std_constant_evaluated_p
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/semantics.c:737
0x783eca finish_if_stmt_cond(tree_node*, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/semantics.c:771
0x71bfcb cp_parser_selection_statement
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:11898
0x71bfcb cp_parser_statement
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:11261
0x71c8f8 cp_parser_statement_seq_opt
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:11745
0x71c9b0 cp_parser_compound_statement
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:11699
0x7325b0 cp_parser_function_body
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:22907
0x7325b0 cp_parser_ctor_initializer_opt_and_function_body
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:22958
0x735cad cp_parser_function_definition_after_declarator
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:28745
0x736ca7 cp_parser_function_definition_from_specifiers_and_declarator
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:28661
0x736ca7 cp_parser_init_declarator
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:20536
0x73b7b4 cp_parser_single_declaration
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:29236
0x73b93d cp_parser_template_declaration_after_parameters
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:28808
0x73beea cp_parser_explicit_template_declaration
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:29074
0x73f0f9 cp_parser_declaration
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:13277
0x73f6d8 cp_parser_translation_unit
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:4723
0x73f6d8 c_parse_file()
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:43569
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.archlinux.org/> for instructions.
```
This code compiles when removing the -Wall flag.
```
> g++-git -v
Using built-in specs.
COLLECT_GCC=g++-git
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-git/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/marehr/Packages/gcc-git/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto --disable-boostrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200116 (experimental) (GCC)
```
[Bug c++/91525] ICE (Segmentation Fault) on a bool conversion operator with concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91525 --- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de --- On gcc-10 I get now the following stacktrace: ``` g++-git -std=c++17 -fconcepts -c ice.cpp main.cpp: In function ‘std::string e()’: main.cpp:46:16: internal compiler error: Segmentation fault 46 | std::cout << o; |^ 0xc5b15f crash_signal /home/marehr/Packages/gcc-git/src/gcc/gcc/toplev.c:328 0x645182 compare_ics /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:10538 0x648c84 joust /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:11191 0x649cbc tourney /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:11630 0x649fd1 build_user_type_conversion_1 /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:4165 0x64b435 implicit_conversion /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:2053 0x64baf0 good_conversion(tree_node*, tree_node*, tree_node*, int, int) /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:2093 0x77183e check_non_deducible_conversion /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:21173 0x77183e check_non_deducible_conversions /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:20645 0x77183e fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool, bool) /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:20947 0x64e879 add_template_candidate_real /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3394 0x64f046 add_template_candidate /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3479 0x64f046 add_candidates /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5805 0x64f612 add_candidates /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5720 0x64f612 add_operator_candidates /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5909 0x6545eb build_new_op_1 /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:6132 0x6551ed build_new_op(op_location_t const&, tree_code, int, tree_node*, tree_node*, tree_node*, tree_node**, int) /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:6520 0x7a563a build_x_binary_op(op_location_t const&, tree_code, tree_node*, tree_code, tree_node*, tree_code, tree_node**, int) /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/typeck.c:4245 0x70c7ad cp_parser_binary_expression /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:9650 0x70d575 cp_parser_assignment_expression /home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:9785 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://bugs.archlinux.org/> for instructions ```
[Bug c++/92552] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:3045 with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92552 --- Comment #7 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Thank you!
[Bug c++/91525] ICE (Segmentation Fault) on a bool conversion operator with concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91525 --- Comment #2 from gcc-bugs at marehr dot dialup.fu-berlin.de --- This still fails and furthermore fails in `-std=c++2a` mode as well.
[Bug c++/90764] [10 Regression] internal compiler error in build_deduction_guide, at cp/pt.c:27162
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90764 --- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de --- *** Bug 91121 has been marked as a duplicate of this bug. ***
[Bug c++/91121] ICE with type deduction guides and CRTP base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91121 gcc-bugs at marehr dot dialup.fu-berlin.de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from gcc-bugs at marehr dot dialup.fu-berlin.de --- This seems to be fixed now: ``` g++-git -v Using built-in specs. COLLECT_GCC=g++-git COLLECT_LTO_WRAPPER=/opt/gcc/gcc-git/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/marehr/Packages/gcc-git/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++ --enable-shared --enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp --enable-cet=auto --disable-boostrap Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.0.0 20191207 (experimental) (GCC) ``` *** This bug has been marked as a duplicate of bug 90764 ***
[Bug c++/90764] [10 Regression] internal compiler error in build_deduction_guide, at cp/pt.c:27162
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90764
--- Comment #2 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
This produces
```
> g++-git -std=c++17 ice.cpp
ice.cpp: In instantiation of ‘void g() [with f = e]’:
ice.cpp:7:17: required from here
ice.cpp:6:54: error: cannot deduce template arguments for ‘e<...auto...>’ from
‘()’
6 | template typename f> void g() { f(); }
|
```
where
```
g++-git -v
Using built-in specs.
COLLECT_GCC=g++-git
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-git/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/marehr/Packages/gcc-git/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto --disable-boostrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20191207 (experimental) (GCC)
```
[Bug c++/86037] __PRETTY_FUNCTION__ for constexpr lambda's is missing [with = type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86037 --- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de --- This still persists in gcc-9.2 and gcc-10.0.
[Bug c++/92594] New: [10 Regression] internal compiler error: in build_value_init_noctor, at cp/init.c:400 using std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92594
Bug ID: 92594
Summary: [10 Regression] internal compiler error: in
build_value_init_noctor, at cp/init.c:400 using
std::tuple
Product: gcc
Version: 10.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 ices on me:
```
template struct tuple {
tuple() : _M_head_impl() {}
_Head _M_head_impl;
};
template struct pod_tuple { type0 _head; };
struct e {};
struct bar : e {
using e::e;
};
int main() { tuple> a; }
```
with
```
> g++-git -std=c++17 -c ice.cpp
ice.cpp: In instantiation of ‘tuple<_Head>::tuple() [with _Head =
pod_tuple]’:
ice.cpp:10:36: required from here
ice.cpp:2:26: internal compiler error: in build_value_init_noctor, at
cp/init.c:400
2 | tuple() : _M_head_impl() {}
| ^
0x5ddd2b build_value_init_noctor(tree_node*, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/init.c:400
0x6ab8f5 build_value_init(tree_node*, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/init.c:379
0x6b1c46 perform_member_init
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/init.c:810
0x6b1c46 emit_mem_initializers(tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/init.c:1374
0x7365b4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:17529
0x734c5a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:17509
0x734c5a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:17826
0x7341fc tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:17509
0x7341fc instantiate_decl(tree_node*, bool, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:25312
0x7532eb instantiate_pending_templates(int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:25428
0x699aa0 c_parse_final_cleanups()
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/decl2.c:4848
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.archlinux.org/> for instructions.
```
gcc version is:
```
Using built-in specs.
COLLECT_GCC=g++-git
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-git/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/marehr/Packages/gcc-git/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto --disable-boostrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20191116 (experimental) (GCC)
```
[Bug c++/92582] New: [10 Regression] internal compiler error: Segmentation fault with concept on constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92582
Bug ID: 92582
Summary: [10 Regression] internal compiler error: Segmentation
fault with concept on constructor
Product: gcc
Version: 10.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 ices:
```
#include
template
concept bool input_or_output_iterator = std::is_same_v;
template concept convertible_to = requires(From(f)()) {
static_cast(f());
};
template struct reference;
template using reference_t = typename reference::type;
template struct reference {
using type = typename std::iterator_traits::reference;
};
template
requires (!input_or_output_iterator) struct reference {
using type = reference_t()))>;
};
template struct b {
template
static constexpr bool e = convertible_to, int>;
template b(std::initializer_list) requires e;
};
b g{std::vector{}};
```
> g++-git -std=c++17 -fconcepts -c ice.cpp
as well as
> g++-git -std=c++2a -c ice.cpp
results in
```
ice.cpp:19:62: internal compiler error: Segmentation fault
19 | template b(std::initializer_list) requires e;
| ^~~~
0xc4999f crash_signal
/home/marehr/Packages/gcc-git/src/gcc/gcc/toplev.c:328
0x72e6b5 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:18836
0x735eb6 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:18765
0x735eb6 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:18423
0x65d8e2 satisfy_constraint_r
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2474
0x65e118 satisfy_constraint
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2554
0x65f4cb satisfy_associated_constraints
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2572
0x65f4cb constraints_satisfied_p
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2656
0x627852 add_function_candidate
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:2264
0x629e3c add_template_candidate_real
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3422
0x62a3c6 add_template_candidate
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3463
0x62a3c6 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5781
0x62a6f4 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5696
0x62a6f4 add_list_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3902
0x63281e build_new_method_call_1
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:10086
0x6330d6 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:10268
0x6330d6 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:9706
0x6abb43 expand_default_init
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/init.c:1970
0x6abb43 expand_aggr_init_1
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/init.c:2085
0x6adab6 build_aggr_init(tree_node*, tree_node*, int, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/init.c:1820
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.archlinux.org/> for instructions.
```
```
> g++-git -v
Using built-in specs.
COLLECT_GCC=g++-git
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-git/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/marehr/Packages/gcc-git/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++ --enable-shared --enable-threads=posix
--with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto --disable-boostrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20191116 (experimental) (GCC)
```
Thank you!
[Bug c++/92552] New: [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:3045 with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92552
Bug ID: 92552
Summary: [10 Regression] internal compiler error: in
lazily_declare_fn, at cp/method.c:3045 with -fconcepts
Product: gcc
Version: 10.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: ---
Created attachment 47287
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47287=edit
ice.cpp
Hi gcc-team,
The patch from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91930 didn't
resolve this ice for me.
I tried to reduce the problem, but I'm stuck at the current version maybe
someone else can continue the help with the reduction.
```
> /usr/local/bin/g++-git -std=c++17 -fconcepts -c ice.cpp
ice.cpp: In instantiation of ‘g::iter::iter(g) [with
view = std::span, -1>; simd = unsigned int; g =
g, -1>, unsigned int>]’:
ice.cpp:184:26: required from ‘g::iter g::begin()
[with view = std::span, -1>; simd = unsigned int]’
ice.cpp:63:21: required from ‘constexpr auto
ranges::_begin_::fn::impl_< >::operator()(R&&) const [with R =
g, -1>, unsigned int>&; bool = true]’
ice.cpp:71:21: required from ‘constexpr auto
ranges::_begin_::fn::operator()(R&&) const [with R =
g, -1>, unsigned int>&]’
ice.cpp:74:47: required by substitution of ‘template using _t =
decltype (ranges::_begin_::fn{}(declval())) [with R =
g, -1>, unsigned int>&]’
ice.cpp:80:10: required from here
ice.cpp:10:50: internal compiler error: in lazily_declare_fn, at
cp/method.c:3045
10 | template concept bool semiregular = __is_constructible(T);
| ^
0x5de62d lazily_declare_fn(special_function_kind, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/method.c:3045
0x6cec2c get_class_binding(tree_node*, tree_node*, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/name-lookup.c:1285
0x7598b6 lookup_field_r
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/search.c:993
0x75a1db dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/search.c:1433
0x75a1db lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/search.c:1147
0x75a673 lookup_fnfields(tree_node*, tree_node*, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/search.c:1352
0x6c7b4d locate_fn_flags
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/method.c:1600
0x6c7ec1 synthesized_method_base_walk
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/method.c:2080
0x6c8860 synthesized_method_walk
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/method.c:2246
0x6c9b79 implicitly_declare_fn(special_function_kind, tree_node*, bool,
tree_node*, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/method.c:2677
0x6c9f23 lazily_declare_fn(special_function_kind, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/method.c:3017
0x6cec2c get_class_binding(tree_node*, tree_node*, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/name-lookup.c:1285
0x7598b6 lookup_field_r
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/search.c:993
0x75a1db dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/search.c:1433
0x75a1db lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/search.c:1147
0x75a673 lookup_fnfields(tree_node*, tree_node*, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/search.c:1352
0x63307f build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:9672
0x6cad77 constructible_expr
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/method.c:1733
0x6cb013 is_xible_helper
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/method.c:1783
0x6cb013 is_xible(tree_code, tree_node*, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/method.c:1810
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.archlinux.org/> for instructions.
```
```
> g++-git -v
Using built-in specs.
COLLECT_GCC=g++-git
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-git/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/marehr/Packages/gcc-git/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs
[Bug c++/92206] [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92206 --- Comment #8 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Thank you! I can confirm that the patch resolved the issue.
[Bug c++/92206] [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92206 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 #6 from gcc-bugs at marehr dot dialup.fu-berlin.de --- ```c++ #include template struct is_swappable_with; template )> using iter_reference_t_ = R; template using iter_reference_t = iter_reference_t_; template std::enable_if_t< is_swappable_with, iter_reference_t>::value> operator00; ``` Another one, reduced from range-v3.
[Bug libstdc++/91495] std::transform_reduce with unary op is implemented in the parallel case but not the basic case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91495 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 #4 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Will this be back-ported to gcc-7 or gcc-8?
[Bug c++/87768] [8 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:19002 when using concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87768 --- Comment #6 from gcc-bugs at marehr dot dialup.fu-berlin.de --- I can confirm that this works from 9 and up. Is there any chance to backport it to 8? In the ticket it says `Target Milestone: 8.4`, does that mean there will be a 8.4 release that fixes this?
[Bug c++/91525] New: ICE (Segmentation Fault) on a bool conversion operator with concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91525
Bug ID: 91525
Summary: ICE (Segmentation Fault) on a bool conversion operator
with concepts
Product: gcc
Version: 8.3.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: ---
The following code segfaults on gcc 7 and gcc 8.
It seems to be fixed in gcc 9, but a variant of the following code still
segfault on gcc 9 and 10.
```c++
#include
#include
namespace ranges {
struct view_interface {
template < bool = true > operator bool();
#if 1
template < bool B = true> requires false operator bool(); // ICE on gcc <= 10
#elif 1
template < bool B = true> requires false explicit operator bool(); // ICE on
gcc <= 8. This code is working since gcc 9.
#else
template < bool B = true, std::enable_if_t> explicit operator bool(); // a
possible workaround
#endif
};
template < typename View > struct impl {
template < typename... Ts, typename V = View >
static auto bind(Ts... ts) -> decltype(V::bind((ts)...));
};
template < typename > struct view;
template < typename Fun > view< Fun > make_view(Fun);
template < typename View > struct view {
template < typename Arg, typename Pipe >
friend auto operator|(Arg, Pipe)
-> decltype(Pipe::pipe(std::declval< Arg >, std::declval< Pipe >()));
View view_;
template < typename Rng, typename Vw > static auto pipe(Rng, Vw v) {
return v.view_(0);
}
template < typename... Ts, typename V = View >
auto operator()(Ts... ts)
-> decltype(make_view(impl< V >::bind(view_, (ts)...)));
};
struct f {
template < typename g > static auto bind(f h, g t) {
return std::bind(h, std::placeholders::_1, t);
}
template < typename a, typename ValRng >
auto operator()(a, ValRng) -> view_interface;
};
view< f > join;
} std::string e() {
std::vector< std::string > extensions;
std::string i;
auto o = extensions | ranges::join(i);
std::cout << o;
}
```
This will produce this error:
```terminal
> g++-9 -std=c++17 -fconcepts -c ice.cpp'
ice.cpp: In function ‘std::string e()’:
ice.cpp:53:16: internal compiler error: Segmentation fault
53 | std::cout << o;
|^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.archlinux.org/> for instructions.
```
Tested compiler versions are:
```terminal
> g++-7 --version
g++-7 (GCC) 7.4.1 20181207
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> g++-8 --version
g++-8 (GCC) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> g++-9 --version
g++ (GCC) 9.1.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> g++-git --version
g++-git (GCC) 10.0.0 20190709 (experimental)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```
[Bug c++/91121] ICE with type deduction guides and CRTP base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91121 --- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Oh it might be the same one as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90764
[Bug c++/91121] New: ICE with type deduction guides and CRTP base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91121
Bug ID: 91121
Summary: ICE with type deduction guides and CRTP base class
Product: gcc
Version: 10.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 will ICE
```c++
template struct a { a(int); };
template struct b : a> { using a::a; };
template b(c)->b;
struct e {
template e(d);
} e{b{2}};
```
with
```
> g++-git -std=c++17 ice.cpp
ice.cpp:6:8: internal compiler error: Segmentation fault
6 | } e{b{2}};
|^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.archlinux.org/> for instructions.
```
gcc version:
```
g++-git -v
Using built-in specs.
COLLECT_GCC=g++-git
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-git/bin/../lib/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/marehr/Packages/gcc-git/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20190709 (experimental) (GCC)
```
Thank you!
[Bug c++/87768] New: ICE in tsubst_copy_and_build, at cp/pt.c:19002 when using concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87768
Bug ID: 87768
Summary: ICE in tsubst_copy_and_build, at cp/pt.c:19002 when
using concepts
Product: gcc
Version: 8.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,
compiling this program with `g++-8 -fconcepts -std=c++17 concept_ice.cpp`
```
struct a {};
template using b = a;
template struct c;
template
requires requires(d e) { e[0]; }
struct c {
static constexpr bool f = [] { return false; }();
};
struct g : b::f> {};
```
yields this ICE:
```
concept_ice.cpp: In instantiation of ‘constexpr const bool c::f’:
concept_ice.cpp:11:29: required from here
concept_ice.cpp:6:29: internal compiler error: in tsubst_copy_and_build, at
cp/pt.c:19002
requires requires(d e) { e[0]; }
~^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.archlinux.org/> for instructions.
```
g++-7.3.1 compiles this just fine.
Thank you for your work!
[Bug c++/86037] New: __PRETTY_FUNCTION__ for constexpr lambda's is missing [with = type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86037
Bug ID: 86037
Summary: __PRETTY_FUNCTION__ for constexpr lambda's is missing
[with = type]
Product: gcc
Version: 8.1.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,
this code changed output between gcc-7 and gcc-8
```
// pretty_function.cpp
#include
#include
template
struct pretty_lambda
{
static constexpr auto as_string = [] ()
{
return std::string{__PRETTY_FUNCTION__};
};
};
int main()
{
std::string lambda_int = pretty_lambda::as_string();
std::cout << lambda_int << "\n";
return 0;
}
```
compiling with `g++-7 -std=c++17 pretty_function.cpp` outputs:
pretty_lambda:: [with type = int]
compiling with `g++-8 -std=c++17 pretty_function.cpp` outputs:
pretty_lambda::
Is there a reason for this change? The same class, but with `as_string` as a
static function delivers an output with the `[with type = int]` part
(i.e., `static auto seqan3::detail::pretty_function::as_string() [with
type = int]`).
So it seems to me that the general format was not changed. I know that this is
in no way a standard function or something, but I would prefer a consistent
output.
> g++-7 -v
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc7/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,lto
--enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib
--with-isl --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp
--enable-gnu-unique-object --enable-linker-build-id --enable-lto
--enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-werror --enable-checking=release
--enable-default-pie --enable-default-ssp --program-suffix=-7
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 7.3.1 20180406 (GCC)
> g++-8 -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 8.1.0 (GCC)
Thank you for your awesome work!
Marcel
[Bug c++/84684] inserting random code / flags produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684
--- Comment #6 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
I use now a more simpler approach for the fold expression [1], but the problem
from this bug ticket still persisted when I used the same kind of assignment:
for (size_t i = 0u; i < alphabet_t::value_size; ++i) {
value_to_char[i] = to_char(alphabet.assign_rank(i));
}
Extracting the rhs into a external lambda function
auto assign_rank_to_char = [](auto alphabet, size_t rank) constexpr
{
return seqan3::to_char(seqan3::assign_rank(alphabet, rank));
};
...
for (size_t i = 0u; i < alphabet_t::value_size; ++i) {
value_to_char[i] = assign_rank_to_char(alphabet, i);
}
Seems to resolve the problem for me and our build systems. I'm eager to know
which edge case I triggered here :)
[1]
https://github.com/marehr/seqan3/blob/0aa304d9a4bc81eb52dd144f3da5fd38330408fc/include/seqan3/alphabet/composition/union_composition.hpp#L362-L389
[Bug c++/84684] New: inserting random code / flags produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84684 Bug ID: 84684 Summary: inserting random code / flags produces wrong code Product: gcc Version: 7.3.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: --- Created attachment 43552 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43552=edit static_assert's throw even though they should not Hi gcc-team, I'm really sorry for this really bad title, but I really don't know what is going on and what the cause is. When I compile the attached code it produces on my machine incorrect results which is tested via static_asserts. When I add some code or add some compiler flags a different static_assert throws. Also on different environment (e.g. travis-ci, our build system,...) this code throws at different places. There is also the possibility that it does not throw at all which would be my expectation. I have different states of the reduced source code if this one does not work for you. > g++ -std=c++17 -Wall -Werror -fconcepts -o > union_composition_detail_test.cpp.o -c union_composition_detail_test.cpp I even encountered states where the flags did not have any influence and the problem persisted, but I ran more frequently in this issue with those flags. The only observation I had was that `value_to_char[i] = alphabet.assign_rank(i).to_char();` seems to always work, but it might be a coincidence. Thank you! > g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp Thread model: posix gcc version 7.3.0 (GCC)
[Bug ipa/82801] [6 Regression] Internal compiler error with Eigen and __attribute__((always_inline, flatten))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82801
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 #10 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Hi,
I did built gcc from git sources
[https://github.com/gcc-mirror/gcc/commit/156d24841, gcc version 8.0.0 20171215
(experimental) (GCC)] today and ran into the same? error.
I could extract this minimal code snippet from our code base that does not work
with g++-8, but with gcc version 7.2.1 20171128 (GCC).
```
class a {};
class b {};
class c : b, a {
__attribute__((always_inline)) c operator=(c);
};
```
~~~
Error log:
internal compiler error: Segmentation fault
__attribute__((always_inline)) c operator=(c);
^
0xc0092f crash_signal
/home/marehr/Packages/gcc-git/src/gcc/gcc/toplev.c:325
0x828832 cxx11_attribute_p(tree_node const*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/attribs.c:802
0x828832 get_attribute_name(tree_node const*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/attribs.c:817
0x828832 private_lookup_attribute(char const*, unsigned long, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/attribs.c:1778
0x828953 lookup_attribute
/home/marehr/Packages/gcc-git/src/gcc/gcc/attribs.h:172
0x828953 diag_attr_exclusions
/home/marehr/Packages/gcc-git/src/gcc/gcc/attribs.c:410
0x828ae9 diag_attr_exclusions
/home/marehr/Packages/gcc-git/src/gcc/gcc/attribs.c:378
0x829f82 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/attribs.c:702
0x7422bc cplus_decl_attributes(tree_node**, tree_node*, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/decl2.c:1508
0x72fd62 grokfndecl
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/decl.c:8844
0x73dc6d grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/decl.c:11987
0x745342 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/decl2.c:829
0x79e34e cp_parser_member_declaration
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:23842
0x79f16a cp_parser_member_specification_opt
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:23316
0x79f16a cp_parser_class_specifier_1
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:22458
0x7a0bf9 cp_parser_class_specifier
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:22710
0x7a0bf9 cp_parser_type_specifier
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:16718
0x7acad5 cp_parser_decl_specifier_seq
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:13579
0x7b1c90 cp_parser_simple_declaration
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:12888
0x7b2bf8 cp_parser_block_declaration
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/parser.c:12835
[Bug c++/83328] New: string.insert does not return a iterator when using initializer lists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83328
Bug ID: 83328
Summary: string.insert does not return a iterator when using
initializer lists
Product: gcc
Version: 7.2.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!
According to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf
[24.3.2.6.4]
or http://en.cppreference.com/w/cpp/string/basic_string/insert [9]
```
iterator insert(const_iterator p, initializer_list il
```
should return an iterator, but the following code
```
#include
int main() {
std::string s = " world!";
auto it = s.insert(s.begin(), {'h', 'e', 'l', 'l', 'o'});
return 0;
}
```
fails with
```
string.cpp: In function ‘int main()’:
string.cpp:5:8: error: ‘void it’ has incomplete type
auto it = s.insert(s.begin(), {'h', 'e', 'l', 'l', 'o'});
^~
```
This behaviour is since g++-4.9
[Bug c++/82410] [7/8 Regression] ICE in replace_placeholders_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82410
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 #4 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
I (may) have run into the same issue:
```
template
struct twice
{
value_t _first{};
value_t _second{_first};
struct inner{};
inner get() const
{
return inner{};
}
};
template
twice(value_t first)
-> twice;
int main()
{
auto result = twice{0u}.get();
}
```
[Bug c++/82326] New: static_cast for vector extension not working?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82326
Bug ID: 82326
Summary: static_cast for vector extension not working?
Product: gcc
Version: 7.2.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: ---
My problem is the following:
```
// main.cpp
#include
#include
using int32x4_t = int32_t __attribute__ ((__vector_size__(16)));
using uint32x4_t = uint32_t __attribute__ ((__vector_size__(16)));
int main()
{
int32x4_t a{-1, 0, 1, 2};
// invalid static_cast from type ‘int32x4_t {aka __vector(4) int}’
// to type ‘uint32x4_t {aka __vector(4) unsigned int}
uint32x4_t b = static_cast(a); // fails with above message
uint32x4_t c = reinterpret_cast(a); // works
// invalid static_cast from type ‘int32x4_t {aka __vector(4) int}’
// to type ‘__m128i {aka __vector(2) long long int}
__m128i d = static_cast<__m128i>(a); // fails with above message
__m128i e = reinterpret_cast<__m128i>(a); // works
return 0;
}
```
> g++ -msse4 main.cpp -o main
Why is a static_cast not working?
This is a hassle, because different compilers support different syntaxes.
* gcc allows only reinterpret_cast and C-style casts
* clang allows both static_cast and reinterpret_cast and C-style casts
* icc (Intel Compiler) allows only static_cast and C-style casts
Thank you!
[Bug c++/61806] [C++11] Expression sfinae w/o access gives hard error in partial template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61806
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 #3 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
I think I encountered a variant of this bug.
Using this new awesome -fconcept feature, you can do the following:
```
template
struct type_trait;
template <>
struct type_trait
{
static constexpr auto length = 0;
};
template <>
struct type_trait
{
private:
static constexpr auto length = 0;
};
template
concept bool has_length = requires(type_t a)
{
{ type_trait::length };
};
int main()
{
static_assert(!has_length); // expect: false, has no ::length
static_assert(has_length); // expect: true, has ::length
static_assert(!has_length); // expect: false, ::length is non-visible
// but, last one fails in a compiler error
return 0;
}
```
This example asks whether a type_trait is defined for a given type. And it
would be super useful to be able to express this.
I think gcc uses internally SFINAE to check this but unfortunately fails
because of this bug (probably).
[Bug libstdc++/80251] Is the is_aggregate meta function missing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80251 --- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de --- I'm sorry for the inconvenience! I didn't see that is_aggregate was just a recent addition to the standard [1]. I just wanted to see if I can check at compile time if my data structure is an aggregate type, like I can do with is_pod. And I just happened to find such a function on cppreference, but I didn't realize that this was added quite recently. [1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0625r0.html#2911
[Bug libstdc++/80251] New: Is the is_aggregate meta function missing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80251
Bug ID: 80251
Summary: Is the is_aggregate meta function missing?
Product: gcc
Version: 7.0.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,
is is_aggregate [1] really missing or is it within some experimental
namespaces?
If I try to compile the following:
```c++
#include
struct aggregate_t {
int foo;
int bar;
};
int main() {
aggregate_t foo;
static_assert(std::is_aggregate_v<decltype(foo)>>);
return 0;
}
```
It will result in the following error:
```terminal
bug_gcc_is_aggregate.cpp: In function ‘int main()’:
bug_gcc_is_aggregate.cpp:10:22: error: ‘is_aggregate_v’ is not a member of
‘std’
static_assert(std::is_aggregate_v<decltype(foo)>>);
^~
bug_gcc_is_aggregate.cpp:10:22: note: suggested alternative: ‘is_array_v’
static_assert(std::is_aggregate_v<decltype(foo)>>);
^~
is_array_v
bug_gcc_is_aggregate.cpp:10:37: error: expected primary-expression before
‘decltype’
static_assert(std::is_aggregate_v<decltype(foo)>>);
^~~~
bug_gcc_is_aggregate.cpp:10:37: error: expected ‘,’ before ‘decltype’
bug_gcc_is_aggregate.cpp:10:37: error: expected string-literal before
‘decltype’
bug_gcc_is_aggregate.cpp:10:37: error: expected ‘)’ before ‘decltype’
zsh: exit 1 g++-7 -std=gnu++1z -Wall -Wextra bug_gcc_is_aggregate.cpp
```
[1] http://en.cppreference.com/w/cpp/types/is_aggregate
[Bug libstdc++/80172] Segfault when using a constructed intializer list of tuple(int, variant) created through template pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80172 --- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Thank you for your feedback! With std::array it works without a problem :)
[Bug libstdc++/80172] New: Segfault when using a constructed intializer list of tuple(int, variant) created through template pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80172 Bug ID: 80172 Summary: Segfault when using a constructed intializer list of tuple(int, variant) created through template pack expansion Product: gcc Version: 7.0.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: --- Created attachment 41044 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41044=edit example source code that triggers segfault Hi gcc-team, the attached source code compiles, but will terminate with a segfault when executed. > g++-7 -std=gnu++1z -Wall -Wextra > bug_gcc_tuple_of_variant_in_pack_expansion.cpp > ./a.out 0. 4 1. 5 2. 1 A N - 0. A 1. N 2. - zsh: segmentation fault (core dumped) ./a.out best regards marehr
[Bug libstdc++/80165] New: Constexpr tuple of variant doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80165
Bug ID: 80165
Summary: Constexpr tuple of variant doesn't work
Product: gcc
Version: 7.0.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: ---
Created attachment 41038
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41038=edit
Example that a tuple of a variant can't be constructed
Hi gcc-team,
first of all, I'm not sure if this bug(?) should be filed here. If not please
move it to the correct component.
I currently was trying to create a constexpr tuple of a constexpr variant as
value, which apparently doesn't work, even though I can create a constexpr
variant.
I get the following error:
```
In file included from bug_gcc_constexpr_tuple_of_variant.cpp:2:0:
/usr/local/bin/gcc-7/include/c++/7.0.1/tuple: In function ‘int main()’:
bug_gcc_constexpr_tuple_of_variant.cpp:8:51: in constexpr expansion of
‘std::make_tuple(_Elements&& ...) [with _Elements = {const std
::variant&}]()’
bug_gcc_constexpr_tuple_of_variant.cpp:8:51: in constexpr expansion of
‘std::tuple<std::variant >(std::forward&>(__args#0))’
/usr/local/bin/gcc-7/include/c++/7.0.1/tuple:609:33: in constexpr expansion
of ‘((std::tuple<std::variant >*)this)->std::tuple<std::variant >::.std::_Tuple_imp
l<0, std::variant
>::_Tuple_impl(__elements#0)’
/usr/local/bin/gcc-7/include/c++/7.0.1/tuple:361:21: error: ‘constexpr
std::_Head_base<_Idx, _Head, false>::_Head_base(const _Head&) [w
ith long unsigned int _Idx = 0; _Head = std::variant]’ called in a constant expression
: _Base(__head) { }
^
/usr/local/bin/gcc-7/include/c++/7.0.1/tuple:125:17: note: ‘constexpr
std::_Head_base<_Idx, _Head, false>::_Head_base(const _Head&) [wi
th long unsigned int _Idx = 0; _Head = std::variant]’ is not usable as a constexpr fun
ction because:
constexpr _Head_base(const _Head& __h)
^~
/usr/local/bin/gcc-7/include/c++/7.0.1/tuple:126:25: error: call to
non-constexpr function ‘std::variant<_Types>::variant(const std::va
riant<_Types>&) [with _Types = {unsigned char, short unsigned int, unsigned
int}]’
: _M_head_impl(__h) { }
^
In file included from bug_gcc_constexpr_tuple_of_variant.cpp:3:0:
/usr/local/bin/gcc-7/include/c++/7.0.1/variant:932:7: note:
‘std::variant<_Types>::variant(const std::variant<_Types>&) [with _Types =
{unsigned char, short unsigned int, unsigned int}]’ is not usable as a
constexpr function because:
variant(const variant&) = default;
^~~
/usr/local/bin/gcc-7/include/c++/7.0.1/variant:399:7: note: defaulted
constructor calls non-constexpr ‘std::__detail::__variant::_Varia
nt_base<_Types>::_Variant_base(const
std::__detail::__variant::_Variant_base<_Types>&) [with _Types = {unsigned
char, short unsigned in
t, unsigned int}]’
_Variant_base(const _Variant_base& __rhs)
^
zsh: exit 1 g++-7 -std=c++1z -Wall -Wextra
bug_gcc_constexpr_tuple_of_variant.cpp
```
Maybe you can tell me what I'm doing wrong.
Best regards
marehr
