[Bug libstdc++/95833] Incorrect static_assert in std::reduce overload taking a binary functor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95833 --- Comment #9 from Tony E Lewis --- Great. I confirm my original example code now compiles and runs cleanly on Compiler Explorer. Thanks very much for this. And thanks to OP for the report.
[Bug libstdc++/95833] Incorrect static_assert in std::reduce overload taking a binary functor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95833 --- Comment #3 from Tony E Lewis --- Great. Thanks very much.
[Bug libstdc++/95833] Incorrect static_assert in std::reduce overload taking a binary functor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95833 Tony E Lewis changed: What|Removed |Added CC||TonyELewis at hotmail dot com --- Comment #1 from Tony E Lewis --- I agree with the OP's report: I think this static_assert() is rejecting valid calls and accepting invalid calls. AFAIU from https://eel.is/c++draft/reduce, we don't require that *the range's value type* is convertible to the type we're reducing to; we require that *the binary operation always returns something* that's convertible to the type being reduced to. So I think these two lines in the numeric header: static_assert(is_invocable_r_v<_Tp, _BinaryOperation&, _Tp&, _Tp&>); static_assert(is_convertible_v); ...should instead be something like: static_assert(is_invocable_r_v<_Tp, _BinaryOperation&, _Tp&, _Tp&>); static_assert(is_invocable_r_v<_Tp, _BinaryOperation&, _Tp&, value_type&>); static_assert(is_invocable_r_v<_Tp, _BinaryOperation&, value_type&, _Tp&>); static_assert(is_invocable_r_v<_Tp, _BinaryOperation&, value_type&, value_type&>); (location : https://github.com/gcc-mirror/gcc/blob/af42043e6618e69187b47f37dac870763c01e20f/libstdc%2B%2B-v3/include/std/numeric#L282 ) Thanks very much for all work on libstdc++.
[Bug c++/83591] -Wduplicated-branches fires in system headers in template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83591 Tony E Lewis changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Tony E Lewis --- Closing as fixed.
[Bug libstdc++/96731] uniform_int_distribution requirement that its type is_integral is too strict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96731 --- Comment #5 from Tony E Lewis --- Thanks very much for your work on this. That's a shame but I appreciate the problems you've highlighted. > I don't plan to work on this any further for now. Yes, fair enough.
[Bug c++/83591] -Wduplicated-branches fires in system headers in template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83591 --- Comment #7 from Tony E Lewis --- Thanks for this comment T vd Sijs. Yes - I'm also able to compile this without problem in 9.3 (and in 10.1). Manuel López-Ibáñez: are you happy that all underlying issues are resolved and this can be closed?
[Bug libstdc++/96731] uniform_int_distribution requirement that its type is_integral is too strict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96731 --- Comment #3 from Tony E Lewis --- Thanks for correcting my failure to find the relevant part of the standard and for confirming this as an enhancement request. Yes please. If libstdc++'s sample() could play nicely with range-v3's view::indices, that'd be much appreciated.
[Bug libstdc++/96731] New: uniform_int_distribution requirement that its type is_integral is too strict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96731
Bug ID: 96731
Summary: uniform_int_distribution requirement that its type
is_integral is too strict
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Following on from https://github.com/ericniebler/range-v3/issues/1532 ...
I think the static_assert requirement in libstdc++'s uniform_int_distribution
code that its template argument type is_integral may be too strict.
I can't see any obvious mention of constraints on uniform_int_distribution's
IntType in http://eel.is/c++draft/rand.dist.uni.int
The motivating case is attempting to sample from a range-v3 view::indices. The
range-v3 clever tricks lead to uniform_int_distribution being invoked with a
range-v3 type.
This all works OK under libc++ because it doesn't impose any requirements on
the type. But the aforementioned static_assert in libstdc++ won't allow it.
The problem can be seen with the first error under GCC or Clang with -std=c++17
on this code:
#include
#include
#include
#include
#include
void fill_vec_with_random_sample_of_first_n_ints( const size_t
_num_possible_vals,
std::vector
_result,
std::mt19937_rng
) {
auto some_indices = ranges::views::indices( prm_num_possible_vals );
std::sample(
std::begin( some_indices ),
std::end ( some_indices ),
std::begin( prm_result ),
static_cast( prm_result.size() ),
prm_rng
);
}
Compiler Explorer : https://godbolt.org/z/MxrazP
One option is that libstdc++ could use std::numeric_limits::is_integer
instead of std::is_integral, so that range-v3 could then specialise accordingly
for its type.
[Bug c++/91993] [8/9 Regression] Spurious -Wconversion warning with -fsanitize=undefined since r6-4886-gcda0a029f45d20f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91993
--- Comment #7 from Tony E Lewis ---
Thanks for all work on this. I confirm that the motivating testcase now
compiles successfully on Godbolt's trunk build ("10.0.1 20200331
(experimental)").
[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 #10 from Tony E Lewis ---
I confirm that my testcase remains fixed on the Godbolt build of g++ trunk
("20200210").
Thanks.
[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 #8 from Tony E Lewis --- I see on Godbolt that my similar-looking ICE is also fixed now. Thanks very much.
[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 #4 from Tony E Lewis ---
Sorry - forgot to include the compiler output...
In file included from
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/iterator/reverse_iterator.hpp:20,
from
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/range/access.hpp:31,
from
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/range/concepts.hpp:30,
from
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/action/concepts.hpp:23,
from
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/range/conversion.hpp:21,
from :4:
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/iterator/basic_iterator.hpp:
In instantiation of 'struct
ranges::detail::iterator_associated_types_base_ > >, ranges::ref_view >::cursor, true>':
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/iterator/basic_iterator.hpp:492:31:
required from 'struct
ranges::basic_iterator > >, ranges::ref_view >::cursor>'
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/range/access.hpp:75:13:
required from 'constexpr auto ranges::_begin_::fn::operator()(R&&) const
requires (_safe_range) && ((has_member_begin) ||
(has_non_member_begin)) [with R =
ranges::join_with_view > >, ranges::ref_view >&]'
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/range/concepts.hpp:80:9:
required from 'ranges::detail::to_container::container_t
ranges::detail::to_container::fn::operator()(Rng&&) const requires
(input_range) && (convertible_to_cont_cont)
[with Rng = ranges::join_with_view > >, ranges::ref_view >; MetaFn = meta::id >;
ranges::detail::to_container::container_t =
std::__cxx11::basic_string]'
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/functional/invoke.hpp:134:34:
required by substitution of 'template constexpr
decltype ((F&&)(f)((Args&(ranges::invoke_fn::operator()::args))...))
ranges::invoke_fn::operator()(F&&, Args&& ...) const [with F =
ranges::detail::to_container::fn > >;
Args = {ranges::join_with_view,
std::allocator >, std::allocator, std::allocator > > > >, ranges::ref_view >}]'
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/functional/concepts.hpp:31:9:
required by substitution of 'template
concepts::return_t, typename
std::enable_if<(invocable, Rng> &&
concepts::detail::CPP_true(concepts::detail::Nil{})), void>::type>
ranges::detail::operator|(Rng&&, ranges::detail::to_container::closure > (*)(ranges::detail::to_container))
[with Rng = ranges::join_with_view > >, ranges::ref_view >; MetaFn = meta::id >]'
:11:19: required from here
/opt/compiler-explorer/libs/rangesv3/0.10.0/include/range/v3/iterator/basic_iterator.hpp:456:23:
internal compiler error: in lazily_declare_fn, at cp/method.c:3066
456 | Cur>::readable_iterator_associated_types_base;
| ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[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
Tony E Lewis changed:
What|Removed |Added
CC||TonyELewis at hotmail dot com
--- Comment #3 from Tony E Lewis ---
I've seen an ICE which looks likely to be a duplicate of this one. I'll put it
here so it can be retested when this one is fixed to confirm it's also fixed.
My ICE can be seen here: https://godbolt.org/z/R6MgH9
It involves compiling the following code with GCC trunk (20200102) with
`-std=c++2a` with range-v3 0.10.0.
#include
#include
#include
#include
auto f() {
const std::vector the_strings = { "a", "b" };
return the_strings
| ranges::views::join( "," )
| ranges::to;
}
I can reduce this testcase if its ICE persists after the original ICE is fixed.
[Bug c++/92313] Regression: ICE since 9.2 for templates derived from range-v3 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92313 --- Comment #4 from Tony E Lewis --- This is now fixed. The bug we decided this was probably a duplicate of (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92206) is now fixed. I've confirmed that trunk (on Godbolt) is also now behaving itself with this bug's repro cases. Thanks.
[Bug c++/92313] Regression: ICE since 9.2 for templates derived from range-v3 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92313 --- Comment #2 from Tony E Lewis --- Ah yes - that looks pretty likely. Sorry, I didn't spot that one.
[Bug c++/92313] New: Regression: ICE since 9.2 for templates derived from range-v3 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92313
Bug ID: 92313
Summary: Regression: ICE since 9.2 for templates derived from
range-v3 code
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Compiling:
~~~
#include
~~~
...with range-v3 0.9.1 is successful with GCC 9.2 but induces an ICE with GCC
trunk ("10.0.0 20191022 (experimental)") : [ https://godbolt.org/z/MwXurC ] :
With creduce's help, this boils down to:
~~~
template int an_int;
template ) > using a = decltype(
an_int );
template using b = a;
template using c = b< b >;
~~~
...which compiles cleanly under GCC 9.2 but fails with:
~~~
a.cpp:4:78: internal compiler error: in strip_typedefs, at cp/tree.c:1681
4 | template using c = b<
b >;
|
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
~~~
...under GCC trunk (r277657, 2019-10-31) with `-fsyntax-only a.cpp`.
Many thanks for all work on GCC.
[Bug c++/92289] Worse "control reaches end of non-void function" diagnostic with undefined sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92289 --- Comment #1 from Tony E Lewis --- Sorry: I should have said... Even the original warning isn't ideal because the compiler has enough information to know that all paths through f() either return a value or throw. So I don't think it should warn at all really. But if it is going to warn, I don't think its diagnostics should degrade when UBSan is enabled.
[Bug c++/92289] New: Worse "control reaches end of non-void function" diagnostic with undefined sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92289
Bug ID: 92289
Summary: Worse "control reaches end of non-void function"
diagnostic with undefined sanitizer
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
When I use Godbolt's GCC (9.2 or trunk ("10.0.0 20191022 (experimental)")) to
compile:
~~~
void throw_sum( int a, int b ) { throw a + b; }
#define THROW_WITH_LINE_NUM_ADDED( x ) throw_sum( x, __LINE__ )
bool f( const bool _val ) {
if ( prm_val ) { return true; }
THROW_WITH_LINE_NUM_ADDED( 0 );
}
~~~
...with `-Werror` I get a helpful warning (promoted to error):
~~~
: In function 'bool f(const bool&)':
:9:1: error: control reaches end of non-void function
[-Werror=return-type]
9 | }
| ^
cc1plus: all warnings being treated as errors
Compiler returned: 1
~~~
...but if I turn on UBSan (ie change the options to `-Werror
-fsanitize=undefined`), I get:
~~~
: In function 'bool f(const bool&)':
:3:49: error: control reaches end of non-void function
[-Werror=return-type]
3 | #define THROW_WITH_LINE_NUM_ADDED( x ) throw_sum( x, __LINE__ )
|~^~~
:8:4: note: in expansion of macro 'THROW_WITH_LINE_NUM_ADDED'
8 |THROW_WITH_LINE_NUM_ADDED( 0 );
|^
cc1plus: all warnings being treated as errors
Compiler returned: 1
~~~
...which I think is much less helpful. I don't think that enabling runtime
sanitizer checks should reduce the quality of the compiler's diagnostics.
Thanks very much to all who work on GCC.
[Bug c++/90894] maybe_unused attribute is ignored on function parameters in explicitly instantiated templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90894 Tony E Lewis changed: What|Removed |Added CC||TonyELewis at hotmail dot com --- Comment #1 from Tony E Lewis --- I've also just hit this issue. Good work on the clear, simple repro code Matt. >From what I can see using Godbolt, this issue has now been fixed between 9.2 and the current trunk (10.0.0 20191008).
[Bug c++/91993] New: Spurious -Wconversion warning with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91993
Bug ID: 91993
Summary: Spurious -Wconversion warning with
-fsanitize=undefined
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Compiling:
auto fn( const unsigned char ,
const unsigned char ,
const unsigned char ) {
return static_cast(
static_cast(
a << 1U
)
|
b
)
|
c;
}
...with:
g++ -fsanitize=undefined -Werror -Wconversion -std=c++17 -fsyntax-only a.cpp
...I get:
a.cpp: In function ‘auto fn(const unsigned char&, const unsigned char&, const
unsigned char&)’:
a.cpp:4:11: error: conversion from ‘int’ to ‘unsigned char’ may change value
[-Werror=conversion]
4 |return static_cast(
| ^~~
5 | static_cast(
| ~~~
6 |a << 1U
|~~~
7 | )
| ~
8 | |
| ~
9 | b
| ~
10 | )
| ~
cc1plus: all warnings being treated as errors
...which I think is spurious. Interestingly, the warning goes away if I remove
`-fsanitize=undefined` (and I can't persuade clang-tidy or `clang -Weverything`
to complain about it).
I'm seeing this on g++ (GCC) 9.2.0 (Ubuntu 18.04.3 LTS, Linux
4.15.0-65-generic) but I've registered it as 10.0 because I see the same
behaviour on GCC master on Godbolt.
The closest to an active duplicate that I can see is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91179 but that doesn't mention
`-fsanitize=undefined` so I suspect that's different.
[Bug libstdc++/82891] stable_sort() won't compile with function object that takes parameters by non-const reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891 --- Comment #8 from Tony E Lewis --- That makes sense. Thanks for the quick and clear response.
[Bug c++/80485] rejects-valid: constexpr static_cast of pointer-to-member-function to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485 --- Comment #8 from Tony E Lewis --- As far as I can see on Godbolt, this is now fixed in trunk. I'm happy for this issue to be closed.
[Bug libstdc++/82891] stable_sort() won't compile with function object that takes parameters by non-const reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891 --- Comment #6 from Tony E Lewis --- (also posted to the libc++ equiv: https://bugs.llvm.org/show_bug.cgi?id=35235) Thanks to everyone involved in libc++, libstdc++ and wg21 for all work on this. This makes sense to me. When the world is awash in good concepts-based compiler diagnostics, this should be pretty easy for users to deal with. Do the changes arising from issue 3031 take retrospective effect on previous standards? If not, is there an issue with libc++ / libstdc++ not adhering to those previous standards? Or is the point that, even if the change isn't retrospective, the previous standards were "wrong" enough and/or the violation is trivial enough that it isn't worth supporting the non-const references when compiling under previous standards? Either way, thanks very much everyone.
[Bug c++/80438] Variadic template class argument deduction failure from variadic constructor deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80438
Tony E Lewis changed:
What|Removed |Added
CC||TonyELewis at hotmail dot com
--- Comment #1 from Tony E Lewis ---
Here are the notes I wrote before I spotted I was about to file a duplicate of
Vittorio's report...
[C++17] constructor unexpectedly preferred over deduction guide in CTAD
Compiling the following under `-std=c++17` :
#include
template
struct x {
template x(const Ts &...) {}
};
template x(const Ts &...) -> x;
static_assert( std::is_same_v< decltype( x{ 0 } ), x > );
static_assert( ! std::is_same_v< decltype( x{ 0 } ), x< > > );
...I see the two static_assert statements failing under GCC, implying that `x{
0 }` is of type `x<>`, rather than `x` as I would expect. These two
static_assert statements pass under Clang.
I would expect `x` because I would expect the deduction guide to take
precedence over the constructor in determining the type of the expression `x{ 0
}`. AFAIU, this is what's meant by the point in [over.match.best] in the
standard that says F1 is "better" than F2 if:
> [...] F1 is generated from a deduction-guide [...] and F2 is not [...]
(from C++17 draft n4659.pdf and from working draft
http://eel.is/c++draft/over.match.best )
I'm seeing this on the current trunk build of GCC on Godbolt (g++ 9.0.0
20181225 (experimental)).
[Bug middle-end/83239] False positive from -Wstringop-overflow on simple std::vector code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239 --- Comment #25 from Tony E Lewis --- Yep - my original testcase now compiles without complaint on the trunk GCC on Godbolt. Thanks very much to everyone involved.
[Bug c++/87093] is_constructible (__is_constructible() instrinsic) explicitly instantiates conversion member function of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87093
--- Comment #8 from Tony E Lewis ---
Yep - verified on the GCC trunk on Godbolt ("9.0.0 20180915 (experimental)").
Fantastic stuff. Thanks very much Ville.
[Bug c++/87093] is_constructible (__is_constructible() instrinsic) explicitly instantiates conversion member function of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87093 --- Comment #2 from Tony E Lewis --- Thanks for the response. Yes - that makes sense to me.
[Bug libstdc++/68222] _Safe_iterator provides operators the wrapped iterator can't actually support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68222 --- Comment #4 from Tony E Lewis --- Yes - Godbolt's GCC trunk is now showing an error where I'd expect within the original repro code. Great stuff. Thanks very much for your work on this.
[Bug c++/87093] New: is_constructible (__is_constructible() instrinsic) explicitly instantiates conversion member function of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87093
Bug ID: 87093
Summary: is_constructible (__is_constructible() instrinsic)
explicitly instantiates conversion member function of
source
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
This following fails to compile under `g++ -fsyntax-only -std=c++17` but
succeeds under `clang++ -fsyntax-only -std=c++17` :
~~~
#include
template struct x {
operator bool() {
static_assert( ! ::std::is_same_v );
return false;
}
};
inline constexpr auto a = ::std::is_constructible>{};
~~~
The error is:
~~~
a.cpp: In instantiation of ‘x::operator bool() [with T = int]’:
/usr/include/c++/8/type_traits:932:12: required from ‘struct
std::is_constructible >’
a.cpp:10:65: required from here
a.cpp:5:18: error: static assertion failed
static_assert( ! ::std::is_same_v );
^~~~
~~~
I think this means that GCC's `__is_constructible()` intrinsic is explicitly
instantiating x's `operator bool()` when trying to figure out whether a bool
can be constructed from an x, whereas Clang' `__is_constructible()` isn't.
>From a quick look, I can't see anything obvious in the standard about whether
either GCC or Clang is wrong here and I guess it's arguable either way. But I
think I'd lean towards arguing that Clang's behaviour better reflects what I'd
expect from traits.
I've replicated this on Godbolt's GCC 9.0.0 20180823.
[Bug c++/86190] [6/7 Regression] -Wsign-conversion ignores explicit conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86190 --- Comment #12 from Tony E Lewis --- I confirm that Godbolt's GCC trunk now handles my testcase correctly. Thanks very much for all work on this.
[Bug c++/86190] [6/7/8/9 Regression] -Wsign-conversion ignores explicit conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86190
Tony E Lewis changed:
What|Removed |Added
CC||TonyELewis at hotmail dot com
--- Comment #7 from Tony E Lewis ---
I just hit this one yesterday (and am now disappointed to have missed being
able to contribute a new valid bug report by just 5 days :) ).
Thanks for the work that's already gone into addressing this.
The repro can be reduced slightly further by removing the struct:
typedef unsigned long sz_t;
sz_t s();
void f(int i) { s() < static_cast( i ); }
[Bug c++/80485] rejects-valid: constexpr static_cast of pointer-to-member-function to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485 --- Comment #7 from Tony E Lewis --- Ah yes - I'm seeing it compiling cleanly now on Godbolt's trunk (9.0.0 20180615). Must have been a temporary glitch in the build (and couldn't possibly have been due to my error :P ).
[Bug c++/80485] rejects-valid: constexpr static_cast of pointer-to-member-function to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485
--- Comment #5 from Tony E Lewis ---
Thanks to all for all work on this.
(Apologies if this isn't helpful but just in case it is...) I notice that the
original Godbolt snippet ( https://godbolt.org/g/JnrZss ) has regressed from a
rejects-valid in 8.1 to an ICE on trunk ("9.0.0 20180610") :
g++: internal compiler error: Segmentation fault signal terminated program as
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/65923] False positive for warning about literal operator suffix and using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65923 --- Comment #9 from Tony E Lewis --- I'm so delighted to see: #include #include using std::literals::chrono_literals::operator""s; using std::literals::string_literals::operator""s; ...compiling cleaning on Godbolt. Thanks for this Ville.
[Bug c++/83990] [7 Regression] Spurious "potential null pointer dereference" warning regression from 7.1 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990 --- Comment #17 from Tony E Lewis --- I confirm that I'm seeing this as fixed on GCC trunk on Godbolt. Thanks very much to all involved in getting this sorted quickly.
[Bug c++/83990] [7/8 Regression] Spurious "potential null pointer dereference" warning regression from 7.1 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990 --- Comment #3 from Tony E Lewis --- Just to be clear... I don't think it's _necessarily_ a problem that the warning is being triggered in this particular context (because I'm not in a position to judge that). The core problem I wish to highlight is that, despite being triggered within a system header, the warning isn't being silenced as I would expect. And my suspicion is that this is caused by the source location info having been lost so the location cannot be recognised as within a system header (as has been hypothesised for bug 83591). (I also wish to highlight that the lack of source location info makes the warning very much harder to respond to.)
[Bug c++/83990] Spurious "potential null pointer dereference" warning regression from 7.1 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990 --- Comment #1 from Tony E Lewis --- Created attachment 43218 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43218=edit Verbose output from GCC 7.2.0 [Ubuntu 17.10]
[Bug c++/83990] New: Spurious "potential null pointer dereference" warning regression from 7.1 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990
Bug ID: 83990
Summary: Spurious "potential null pointer dereference" warning
regression from 7.1 onwards
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Created attachment 43217
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43217=edit
Pre-processed (-save-temps) on GCC 7.2.0 [Ubuntu 17.10]
Compiling this code:
#include
#include
#include
void a() {
std::vector s;
s.reserve( 5 );
for (const std::string : s) {
std::cout << x;
}
}
template void ignore_unused(Ts &&...) {}
void b() {
for (const int : { 0, 0, 0, 0 } ) {
ignore_unused( i );
std::vector s;
s.reserve( 5 );
for (const std::string : s) {
std::cout << x;
}
}
}
...with...
g++ -std=c++17 -O3 -Werror -Wnull-dereference a.cpp -s -o /tmp/a.o
Gives the following error (upgraded from a warning):
In function ‘void std::vector<_Tp, _Alloc>::reserve(std::vector<_Tp,
_Alloc>::size_type) [with _Tp = std::__cxx11::basic_string; _Alloc =
std::allocator<std::__cxx11::basic_string >]’:
cc1plus: error: potential null pointer dereference
[-Werror=null-dereference]
cc1plus: all warnings being treated as errors
I don't think the user code is doing anything to warrant this warning and it's
unhelpful that there is no stack/line information to track the issue.
I'm guessing that the problem here is that, as is hypothesised for bug 83591,
the source location info has been lost so the warning isn't being squelched as
it should for being in a system header.
>From what I can see on GodBolt, this issue was introduced between 6.3 and 7.1
and is still present in trunk (8.0.1 20180122).
In 7.1, the problem goes away if compiling with -std=c++14 or -std=c++11
(rather than -std=c++17) but in trunk (8.0.1 20180122) the problem persists in
all three modes.
[Bug middle-end/83239] False positive from -Wstringop-overflow on simple std::vector code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239 --- Comment #21 from Tony E Lewis --- Many thanks to all for the thought, time and work you're devoting to this issue.
[Bug c++/83591] -Wduplicated-branches fires in system headers in template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83591 --- Comment #4 from Tony E Lewis --- Thanks for the response. That all sounds sensible.
[Bug c++/83591] -Wduplicated-branches fires in system headers in template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83591 --- Comment #2 from Tony E Lewis --- Further, even adding: #pragma GCC diagnostic ignored "-Wduplicated-branches" ...doesn't appear to stop these warnings in this example code, though it does correctly silence the warning in non-template functions.
[Bug c++/83591] -Wduplicated-branches fires in system headers in template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83591 --- Comment #1 from Tony E Lewis --- Created attachment 42965 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42965=edit Intermediate file
[Bug c++/83591] New: -Wduplicated-branches fires in system headers in template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83591
Bug ID: 83591
Summary: -Wduplicated-branches fires in system headers in
template instantiation
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Compiling with:
g++ -Werror -Wduplicated-branches -c -isystem sysheaddir b.cpp
where b.cpp is :
#include "a.hpp"
...and sysheaddir/a.hpp is:
template
void f() {
int b;
( b ? b : b );
}
void g() {
f<>();
}
...gives:
sysheaddir/a.hpp:8:6: required from here
cc1plus: error: this condition has identical branches
[-Werror=duplicated-branches]
cc1plus: all warnings being treated as errors
Thought the code *does* have duplicate branches, I see two problems with this:
* the warning is firing even though all the code relevant to the warning is in
a system header
* the warning doesn't provide the line number on which the identical branches
appear
I suspect that it's already the intended design that this warning shouldn't
fire in system headers. Indeed, if I add a simple `void h() { int b; b ? b : b;
}` into b.cpp, it triggers the warning but if I add it to the system header
sysheaddir/a.hpp, it doesn't.
I'm using g++ (Ubuntu 7.2.0-8ubuntu3) 7.2.0. It looks to me from using
godbolt.org, that the same problems persist in trunk (8.0.0 20171225).
I suspect this is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82541
but it has differences:
* I'm highlighting a true positive warning in a *system* header (rather than a
false positive in the .cpp file)
* I'm highlighting the lack of line number in the warning message
[Bug c++/83239] New: False positive from -Wstringop-overflow on simple std::vector code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
Bug ID: 83239
Summary: False positive from -Wstringop-overflow on simple
std::vector code
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Created attachment 42765
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42765=edit
Pre-processed (-save-temps) on GCC 7.2.0 [Ubuntu 17.10]
Compiling this:
#include
void fn() {
std::vector a;
int num = 2;
while ( num > 0 ) {
const auto a_size = a.size();
if ( a_size < 3 ) {
a.assign( 1, 0 );
}
else {
a.resize( a_size - 2 ); // <-- I think problem is here
}
--num;
}
}
...with `g++ -O3 -Wall -Werror a.cpp` results in:
In function ‘void fn()’:
cc1plus: error: ‘void* __builtin_memset(void*, int, long unsigned int)’:
specified size 18446744073709551608 exceeds maximum object size
9223372036854775807 [-Werror=stringop-overflow=]
cc1plus: all warnings being treated as errors
I think this is a problem for three reasons:
1. the warning doesn't tell me the location of the problem
2. worse, the warning name "stringop-overflow" is actively misleading because
the code containing the problem isn't using strings
3. the warning is wrong: AFAIU, it's complaining about `a_size - 2`
potentially being a huge unsigned integer due to wrapping below 0 but it's in
an else clause that only executes if `a_size >= 3`.
I'm seeing this problem on both GCC 8.0.0 20171130 (Godbolt) and GCC 7.2.0 (my
Ubuntu).
Though there are other open bugs relating to this warning:
* bug 79929
* bug 82076
* bug 82103
* bug 82646
...I'm not sure any cover this issue (eg the first one is about Fortran).
Thanks very much.
[Bug libstdc++/82891] stable_sort() won't compile with function object that takes parameters by non-const reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891 --- Comment #4 from Tony E Lewis --- Thanks very much for your quick work on this. I agree that changing the standard is a reasonable approach but I also think that changing the library implementations is a reasonable approach too. Please may I ask what reasons make you go straight down the spec-changing route rather than making the libraries comply? I tried putting the argument on the libc++ issue (here: https://bugs.llvm.org/show_bug.cgi?id=35235 ) that changing the libraries is do-able and helps make more reasonable code "just work". It also removes one more corner case from generic-programming. This seems to all work in the right direction of making C++ simpler. Are these arguments unpersuasive?
[Bug libstdc++/82891] stable_sort() won't compile with function object that takes parameters by non-const reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891 --- Comment #1 from Tony E Lewis --- I should say that I've also raised the same issue against libc++ : https://bugs.llvm.org/show_bug.cgi?id=35235
[Bug libstdc++/82891] New: stable_sort() won't compile with function object that takes parameters by non-const reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891
Bug ID: 82891
Summary: stable_sort() won't compile with function object that
takes parameters by non-const reference
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
This fails to compile:
~~~
#include
#include
int main() {
std::vector a = { 5, 7, 1, 4, 1, 4, 2 };
std::stable_sort(
std::begin( a ),
std::end ( a ),
[] (int , int ) { return x < y; }
);
}
~~~
...but works with std::sort(). The problem is that libstdc++ is trying to call
the function object with a const int (&), which the compiler can't bind a
non-const reference to.
Yet I suspect this code is valid. In point 9 (P896-897) of $25.1 of the C++14
draft at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf, it
says:
> The BinaryPredicate parameter is used whenever an algorithm expects a
> function object that when applied
> to the result of dereferencing two corresponding iterators or to
> dereferencing an iterator and type
> T when T is part of the signature returns a value testable as true. In other
> words, if an algorithm takes
> BinaryPredicate binary_pred as its argument and first1 and first2 as its
> iterator arguments, it should
> work correctly in the construct binary_pred(*first1, *first2) contextually
> converted to bool (Clause 4).
> BinaryPredicate always takes the first iterator’s value_type as its first
> argument, that is, in those cases
> when T value is part of the signature, it should work correctly in the
> construct binary_pred(*first1,
> value) contextually converted to bool (Clause 4). binary_pred shall not apply
> any non-constant function
> through the dereferenced iterators.
I'm not versed in standardese but I understand the middle part of this as
saying that an implementation of the standard library should work with any
predicate that can take dereferenced iterators as arguments and can be called
in a bool context (so long as it meets other specific requirements).
The errors on GodBolt are:
> In file included from
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/stl_algobase.h:71:0,
> from
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/algorithm:61,
> from :1:
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/predefined_ops.h:
> In instantiation of 'bool
> __gnu_cxx::__ops::_Iter_comp_val<_Compare>::operator()(_Iterator, _Value&)
> [with _Iterator = __gnu_cxx::__normal_iterator<int*, std::vector >;
> _Value = const int; _Compare = main()::<lambda(int&, int&)>]':
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/stl_algobase.h:959:14:
>required from '_ForwardIterator std::__lower_bound(_ForwardIterator,
> _ForwardIterator, const _Tp&, _Compare) [with _ForwardIterator =
> __gnu_cxx::__normal_iterator<int*, std::vector >; _Tp = int; _Compare =
> __gnu_cxx::__ops::_Iter_comp_val<main()::<lambda(int&, int&)> >]'
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/stl_algo.h:2501:26:
>required from 'void std::__merge_without_buffer(_BidirectionalIterator,
> _BidirectionalIterator, _BidirectionalIterator, _Distance, _Distance,
> _Compare) [with _BidirectionalIterator = __gnu_cxx::__normal_iterator<int*,
> std::vector >; _Distance = long int; _Compare =
> __gnu_cxx::__ops::_Iter_comp_iter<main()::<lambda(int&, int&)> >]'
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/stl_algo.h:2772:34:
>required from 'void std::__inplace_stable_sort(_RandomAccessIterator,
> _RandomAccessIterator, _Compare) [with _RandomAccessIterator =
> __gnu_cxx::__normal_iterator<int*, std::vector >; _Compare =
> __gnu_cxx::__ops::_Iter_comp_iter<main()::<lambda(int&, int&)> >]'
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/stl_algo.h:5004:28:
>required from 'void std::__stable_sort(_RandomAccessIterator,
> _RandomAccessIterator, _Compare) [with _RandomAccessIterator =
> __gnu_cxx::__normal_iterator<int*, std::vector >; _Compare =
> __gnu_cxx::__ops::_Iter_comp_iter<main()::<lambda(int&, int&)> >]'
> /opt/compiler-explorer/gcc-trunk-20171106/include/c++/8.0.0/bits/stl_algo.h:5075:36:
>required from 'void std::stable_sort(_RAIter, _RAIter, _Compare) [with
> _RAIter = __gnu_cxx::__normal_iterator<int*, std::vecto
[Bug c++/80485] New: rejects-valid: constexpr static_cast of pointer-to-member-function to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485
Bug ID: 80485
Summary: rejects-valid: constexpr static_cast of
pointer-to-member-function to bool
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
GCC rejects the following code (partly adapted from Boost's tribool), which I
think is valid:
struct dummy {
void nonnull() {};
};
typedef void (dummy::*safe_bool)();
constexpr safe_bool a = ::nonnull;
static_assert( static_cast( a ), "" );
int main () { return 0; }
I'm compiling with -std=c++14 and I'm seeing these errors:
:9:1: error: non-constant condition for static assertion
static_assert( static_cast( a ), "" );
^
:9:16: error: '(dummy::nonnull != 0)' is not a constant expression
static_assert( static_cast( a ), "" );
^~
Compiler exited with result code 1
This code is accepted by Clang.
This looks related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71896 but
that has status "RESOLVED FIXED" but I'm seeing this on "GCC 7 (snapshot)" on
godbolt.org (see https://godbolt.org/g/JnrZss ) as well as on my GCC 6.2.0.
[Bug c++/78301] New: noexcept() operator rejects sibling method call without object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78301
Bug ID: 78301
Summary: noexcept() operator rejects sibling method call
without object
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
This code fails to compile under g++ (including "gcc HEAD 7.0.0 201611" on
http://melpon.org/wandbox):
struct a {
void inner() const {}
void outer() const noexcept( noexcept( inner() ) ) {
inner();
}
};
with the error:
a.cpp:3:47: error: cannot call member function ‘void a::inner() const’ without
object
void outer() const noexcept( noexcept( inner() ) ) {
^
Both Clang and MSVC accept this code, presumably treating the call to inner()
in the same way to the call in the body of outer(). This seems sensible. Is
there any principled reason g++ rejects it. If not, please can g++ be altered
to handle this inline with Clang and MSVC? Many thanks.
[Bug c++/77446] Suspicious "non-constant condition for static assertion" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77446 --- Comment #3 from Tony E Lewis --- Great to see this will now be covered by a testcase. Thanks very much for all work.
[Bug c++/69095] internal compiler error: in dependent_type_p, at cp/pt.c:19399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69095 --- Comment #6 from Tony E Lewis --- For information: mine is now fixed too. More detail: my example that was previously triggering this Internal Compiler Error on GCC 5.2.1 now gets sensible error messages under "gcc HEAD 7.0.0 20161004" on http://melpon.org/wandbox/ .
[Bug c++/77446] New: Suspicious "non-constant condition for static assertion" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77446
Bug ID: 77446
Summary: Suspicious "non-constant condition for static
assertion" error
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
I'm compiling the following under C++14 mode on HEAD 7.0.0 201608 of
http://melpon.org/wandbox/
struct inner {
int field_a = 0;
bool field_b = false;
explicit constexpr inner(const int _field_a) noexcept : field_a{
arg_field_a } {}
};
struct outer {
inner the_inner = inner{ 0 };
constexpr outer() noexcept = default;
constexpr int set_inner(const inner _inner) {
the_inner = arg_inner;
return 0;
}
};
constexpr inner another_inner{ 1 };
static_assert( outer{}.set_inner( another_inner ) == 0, "" );
int main() {}
...and seeing this error:
prog.cc:19:1: error: non-constant condition for static assertion
static_assert( outer{}.set_inner( another_inner ) == 0, "" );
^
I suspect this is a compiler error, particularly because;
* Commenting out the field_b line makes it work.
* Clang compiles this without complaint.
* The error message appears to be inconsistent, sometimes gaining the
following messages after the messages above...
prog.cc:19:33: in constexpr expansion of
'outer{inner(0)}.outer::set_inner(another_inner)'
prog.cc:19:1: error: accessing value of '.outer::the_inner' through
a 'char [5]' glvalue in a constant expression
Many apologies if this is a false positive.
Many thanks for all your hard work on this wonderful compiler.
[Bug c++/70377] New: "unexpected AST" and "confused by earlier errors, bailing out" from throw in simple constexpr fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70377
Bug ID: 70377
Summary: "unexpected AST" and "confused by earlier errors,
bailing out" from throw in simple constexpr fn
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
Compiling this code:
#include
#include
#include
template
constexpr size_t simple_find(const std::array<int, N> _array,
const int_value
) {
for (size_t ctr = 0; ctr != N; ++ctr) {
if ( arg_array[ ctr ] == arg_value ) {
return ctr;
}
}
throw std::out_of_range( "" );
}
static constexpr std::array<int, 3> some_ints { { 10, 11 } };
static_assert( simple_find( some_ints, 10 ) == static_cast( 0 ), "" );
static_assert( simple_find( some_ints, 11 ) == static_cast( 1 ), "" );
int main() { }
...under -std=c++14 gives:
a.cpp:19:1: error: non-constant condition for static assertion
static_assert( simple_find( some_ints, 10 ) == static_cast( 0 ), "" );
^
a.cpp:19:27: error: ‘constexpr size_t simple_find(const std::array<int, N>&,
const int&) [with long unsigned int N = 3ul; size_t = long unsigned int]’
called in a constant expression
static_assert( simple_find( some_ints, 10 ) == static_cast( 0 ), "" );
^
a.cpp:6:18: note: ‘constexpr size_t simple_find(const std::array<int, N>&,
const int&) [with long unsigned int N = 3ul; size_t = long unsigned int]’ is
not usable as a constexpr function because:
constexpr size_t simple_find(const std::array<int, N> _array,
^
a.cpp:6:18: sorry, unimplemented: unexpected AST of kind loop_expr
a.cpp:6: confused by earlier errors, bailing out
I think the code is valid C++14. Even if not, I doubt you want the errors seen
above.
The code compiles cleanly if the throw statement is replaced with 'return 0;'.
I'm seeing this issue on g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010. I've also
tried it on http://melpon.org/wandbox and I think the issue is still there on a
recent 6.0.0 HEAD.
Thanks very much.
[Bug c++/69095] internal compiler error: in dependent_type_p, at cp/pt.c:19399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69095 Tony E Lewis changed: What|Removed |Added CC||TonyELewis at hotmail dot com --- Comment #2 from Tony E Lewis --- I've independently stumbled across what appears to be the same bug in 5.2.1. I get error message: internal compiler error: in dependent_type_p, at cp/pt.c:21141 When a fix is made available for this, I can also check it against my (much longer) failing source file. My context details: GCC 5.2.1 (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010 Ubuntu 15.10 4.2.0-23-generic #28-Ubuntu SMP Sun Dec 27 17:47:31 UTC 2015 x86_64
[Bug libstdc++/68222] New: _Safe_iterator provides operators the wrapped iterator can't actually support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68222
Bug ID: 68222
Summary: _Safe_iterator provides operators the wrapped iterator
can't actually support
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
It would be very helpful if the _Safe_iterator wrapper disabled operators, such
as non-member operator-(), that aren't actually supported by the wrapped
iterator type. Since the non-member operator-() is well formed, modern iterator
code might reasonably choose to enable code that uses it but this will result
in a compile error. One example of this cropping up:
https://github.com/ericniebler/range-v3/issues/231
This issue is illustrated in the following code:
// Turn debug mode on
#define _GLIBCXX_DEBUG
#include
#include
template void ignore_unused(const Ts &...);
int main() {
// A list of int
const std::list nums = { 1, 2, 3, 4 };
// Grab the iterator type (which is
_Safe_iterator<_List_const_iterator, list >)
using list_itr_type = decltype( std::cbegin( nums ) );
// TD bob;
// Confirm cend returns the same type
static_assert( std::is_same< decltype( std::cend( nums ) ),
list_itr_type >::value, "" );
// The list's iterator type provides a well-formed non-member
operator-() with valid return type (long int)
using subtraction_return_type = decltype( std::declval()
- std::declval() );
static_assert( std::is_same< subtraction_return_type, long int
>::value, "" );
// Yet an attempt to actually fails to compile because the wrapped list
iterator
// doesn't support operator-()
const auto fail_here = std::cend( nums ) - std::begin( nums );
ignore_unused( fail_here );
return 0;
}
// Command : g++ -std=c++14 -Wall -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations safe_itr_prob.cpp
// STL : GNU libstdc++ version 20151010 (
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21 )
// Compiler: GNU C++ version 5.2.1 20151010
// OS : Ubuntu 15.10 (Linux 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8
15:35:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux)
[Bug libstdc++/59603] std::random_shuffle tries to swap element with itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603 Tony E Lewis changed: What|Removed |Added CC||TonyELewis at hotmail dot com --- Comment #12 from Tony E Lewis --- Thanks for work on this. Should this fix be applied to shuffle() as well as to random_shuffle()?
