[Bug c++/97198] New: __is_constructible(int[], int) should return true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97198
Bug ID: 97198
Summary: __is_constructible(int[], int) should return true
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Target Milestone: ---
The sample code below returns 0 if it is compiled by GCC HEAD with c++2a mode
but I think that it should return 1.
sample code
int main()
{
return __is_constructible(int[], int);
}
sample code
cf. https://wandbox.org/permlink/nFQtqfxDNJPZRhZt
The C++20 DIS 20.15.4.3 Type properties[meta.unary.prop] p.8 says,
The predicate condition for a template specialization is_constructible shall be satisfied if and only if the following variable definition
would be well-formed for some invented variable t:
T t(declval()...);
...
cf. https://timsong-cpp.github.io/cppwp/n4861/meta#unary.prop-8
If T = int[] and Args = int, it is well-formed.
sample code
int main()
{
using T = int[];
T t(42);
}
sample code
cf. https://wandbox.org/permlink/2MhF1PNUbgq7mNAC
So, I think that __is_constructible(int[], int) should return true even though
int[] is imcomplete type. (unless it is a defect of the C++20 DIS)
Related PR:
PR94149 __is_constructible doesn't know about C++20 parenthesized init for
arrays
PR90532 [8/9/10 Regression] is_constructible_v and
is_default_constructible_v should agree
[Bug c++/92187] New: [concepts] An abbreviated function template ignores type constraint in some circumstances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92187
Bug ID: 92187
Summary: [concepts] An abbreviated function template ignores
type constraint in some circumstances
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Target Milestone: ---
The sample code below is compiled successfully by current trunk.
==
template
concept C = false;
C auto f(auto)
{
return 42;
}
int main()
{
return f(0);
}
==
cf. https://wandbox.org/permlink/BXPESMeiWSoUSmTn
According to C++ standard draft N4835 [dcl.type.auto.deduct] p.6,
> For a placeholder-type-specifier with a type-constraint, the
> immediately-declared
> constraint of the type-constraint for the type deduced for the placeholder
> shall
> be satisfied.
So I think that the code should be failed to compile.
Note that the codes below are failed to compile.
==
template
concept C = false;
// normal(non abbreviated) function template
template
C auto f(T)
{
return 42;
}
int main()
{
return f(0);
}
==
cf. https://wandbox.org/permlink/j3HfbOv7PbOqSnhj
==
template
concept C = false;
// normal function
C auto f(int)
{
return 42;
}
int main()
{
return f(0);
}
==
cf. https://wandbox.org/permlink/blq6P4QgQdgEuPF9
==
template
concept C = false;
// trailing return type
auto f(auto) -> C auto
{
return 42;
}
int main()
{
return f(0);
}
==
cf. https://wandbox.org/permlink/JfV8QmbNnjZ4ranP
[Bug c++/92186] New: [concepts] requires expression outside of concept definition cannot return false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92186
Bug ID: 92186
Summary: [concepts] requires expression outside of concept
definition cannot return false
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Target Milestone: ---
The sample code below cannot be compiled by current trunk.
==
template
int foo()
{
if (requires(T i) {
i++;
}) {
return 42;
} else {
return 99;
}
}
int main()
{
return foo();
}
==
cf. https://wandbox.org/permlink/6S5cGSAJHBL86cfi
According to C++ standard draft N4835 [expr.prim.req] p.6,
> The substitution of template arguments into a requires-expression
> may result in the formation of invalid types or expressions in its
> requirements or the violation of the semantic constraints of those
> requirements.
> In such cases, the requires-expression evaluates to false; it does
> not cause the program to be ill-formed.
So I think that the code should be compiled successfully.
Note that the code below can be compiled.
==
template
concept can_increment = requires(T i) {
i++;
};
template
int foo()
{
if (can_increment) {
return 42;
} else {
return 99;
}
}
int main()
{
return foo();
}
==
cf. https://wandbox.org/permlink/VCqlkJwZHKNxZIaE
[Bug c++/68781] [concepts] requires in member function is not unevaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68781 Mitsuru Kariya changed: What|Removed |Added CC||kariya_mitsuru at hotmail dot com --- Comment #1 from Mitsuru Kariya --- This compiles with current trunk.
[Bug c++/90533] New: [C++20] cannot redeclare telmplate function if it contains lambda expression in its declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90533
Bug ID: 90533
Summary: [C++20] cannot redeclare telmplate function if it
contains lambda expression in its declaration
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Target Milestone: ---
The sample code below should be compiled successfully in c++20 mode but gcc
9.1.0 or above generate compilation error.
=sample code=
template static void k(decltype([]{ return 0; }()));
template static void k(decltype([]{ return 0; }()));
template static void k(int) {}
int main()
{
k<0>(0);
}
===compiler output===
prog.cc: In function 'int main()':
prog.cc:7:11: error: call of overloaded 'k<0>(int)' is ambiguous
7 | k<0>(0);
| ^
prog.cc:1:30: note: candidate: 'void k(decltype (())) [with int N = 0;
decltype (()) = int]'
1 | template static void k(decltype([]{ return 0; }()));
| ^
prog.cc:2:30: note: candidate: 'void k(decltype (())) [with int N = 0;
decltype (()) = int]'
2 | template static void k(decltype([]{ return 0; }()));
| ^
prog.cc:3:30: note: candidate: 'void k(int) [with int N = 0]'
3 | template static void k(int) {}
| ^
=
cf. https://wandbox.org/permlink/GRhyXXNttvOtlNxu
The 1st and 2nd declarations should not contain closure type in its signature
because an operand of the decltype contains no template parameter.
So these three declarations should be identical.
Note that the sample code above is from p0315r4 and the paper says that it is
equivalent to a following code that is compiled successfully by gcc 9.1.0 or
above.
=sample code=
struct lambda { auto operator()() const { return 0; } };
template static void k(decltype(lambda{}()));
template static void k(decltype(lambda{}()));
template static void k(int) {}
int main()
{
k<0>(0);
}
===compiler output===
cf. https://wandbox.org/permlink/jUosb2rfxR58JBbx
I think the code above is bit inaccurate but a more precise version below is
also compiled successfully by gcc 9.1.0 or above.
=sample code=
struct lambda1 { auto operator()() const { return 0; } };
struct lambda2 { auto operator()() const { return 0; } };
template static void k(decltype(lambda1{}()));
template static void k(decltype(lambda2{}()));
template static void k(int) {}
int main()
{
k<0>(0);
}
===compiler output===
cf. https://wandbox.org/permlink/kl8K4AHTPL5dL4rq
[links]
Wording for lambdas in unevaluated contexts
http://wg21.link/p0315r4
C++2a Support in GCC
https://gcc.gnu.org/projects/cxx-status.html#cxx2a
[Bug libstdc++/90239] New: [C++20] scoped_allocator_adaptor should support nested pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90239
Bug ID: 90239
Summary: [C++20] scoped_allocator_adaptor should support nested
pair
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Target Milestone: ---
The current implementation of scoped_allocator_adaptor is not support nested
pair.
=== sample code ===
#include
#include
#include
#include
#include
// stateful allocator
template
class MyAlloc {
public:
using value_type = T;
T* allocate(std::size_t n) { return static_cast(::operator
new(sizeof(T) * n)); }
void deallocate(T* p, std::size_t n) { ::operator
delete(static_cast(p), sizeof(T) * n); }
MyAlloc(int state) noexcept : state(state) {}
template
MyAlloc(const MyAlloc& o) noexcept : state(o.state) {}
int state;
};
template
bool operator==(const MyAlloc& lhs, const MyAlloc& rhs) noexcept
{
return lhs.state == rhs.state;
}
template
bool operator!=(const MyAlloc& lhs, const MyAlloc& rhs) noexcept
{
return lhs.state != rhs.state;
}
// type alias
template
using SA = std::scoped_allocator_adaptor>;
template
using VEC = std::vector>;
int main()
{
VEC, int>, int>> v(SA(1));
v.emplace_back(std::make_pair(VEC{SA(2)}, 1), 2);
v.emplace_back(std::make_pair(VEC{SA(3)}, 3), 4);
std::cout << v.get_allocator().state << ", "
<< v[0].first.first.get_allocator().state << ", "
<< v[1].first.first.get_allocator().state << '\n';
}
=== sample code ===
=== sample output ===
1, 2, 3
=== sample output ===
cf. https://wandbox.org/permlink/mcVJEFjpR2UeyW0O
I think that it should output "1, 1, 1" in c++2a mode.
P0591R4: Utility functions to implement uses-allocator construction
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0591r4.pdf
C++ 2020 Implementation Status
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2020
commit for P0591R4
https://github.com/gcc-mirror/gcc/commit/6a9c77f14d18d819dc4b03e1ebc2da4e5f085627
[Bug libstdc++/87619] New: sizeof(std::variant) can be reduced if its variant_size is UCHAR_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87619 Bug ID: 87619 Summary: sizeof(std::variant) can be reduced if its variant_size is UCHAR_MAX Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: kariya_mitsuru at hotmail dot com Target Milestone: --- The current implementation of std::variant stores its index() on an unsigned char member variable (_M_index) if its std::variant_size is less than UCHAR_MAX. But I think that its index() can be stored on unsigned char even if its variant_size is equal to UCHAR_MAX. cf. https://wandbox.org/permlink/CpVcCKU3526PnDel FYI: I think that the first template parameter of _Select_int_base is slightly larger than necessary. https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/std/variant?revision=264786=markup#l365
[Bug libstdc++/87194] New: Associative container cannot be inserted from move iterators that refer to elements implicitly convertible to value_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87194
Bug ID: 87194
Summary: Associative container cannot be inserted from move
iterators that refer to elements implicitly
convertible to value_type
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Target Milestone: ---
The sample code below is failed to compile by GCC HEAD (Sep 1, 2018).
=== sample code ===
#include
#include
#include
#include
#include
struct S {
S(const char* s) : s(s) {}
operator std::string() && { return std::move(s); }
std::string s;
};
int main()
{
std::array a{ "abc", "def", "ghi" };
std::set s;
s.insert(std::make_move_iterator(a.begin()),
std::make_move_iterator(a.end()));
}
=== sample code ===
cf. https://wandbox.org/permlink/c8rASYAgPKxRBUt0
The C++17 standard [associative.reqmts] says,
p.8: ..., i and j satisfy input iterator requirements and refer to elements
implicitly convertible to value_type, ...
a.insert(i,j) in Table 90: Requires: value_type shall be EmplaceConstructible
into X from *i.
So, I think that the sample code should be coumpiled successfully.
The unordered_set has the same problem.
cf. https://wandbox.org/permlink/Q4pVJkFVSS2Qijrg
But I don't know why, [unord.req] says that
p.8: ..., i and j denote input iterators that refer to value_type, ...
So, I am not sure that the unordered_set should be too.
[Bug libstdc++/87135] New: [C++17] unordered containers violate iterator validity requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87135
Bug ID: 87135
Summary: [C++17] unordered containers violate iterator validity
requirements
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Target Milestone: ---
Please see the sample code below.
=== sample code ===
#include
#include
template
void print(const S& s, typename S::const_iterator& it)
{
std::cout << "size = " << s.size() << '\n';
std::cout << "bucket_count = " << s.bucket_count() << '\n';
std::cout << "load_factor = " << s.load_factor() << '\n';
std::cout << "max_load_factor = " << s.max_load_factor() << '\n';
std::cout << "size limit = " << s.bucket_count() * s.max_load_factor() <<
"\n\n";
for (std::size_t i = 0; it != s.end() && i < s.size() / 2; ++i, ++it) {
std::cout << *it << ' ';
}
std::cout << "\n\n";
}
int main()
{
std::unordered_set s;
const auto max = 10;
s.reserve(max);
for (int i = 0; i < max; ++i) {
s.insert(i);
}
auto it = s.cbegin();
print(s, it);
s.insert(max);
print(s, it);
}
=== sample code ===
=== output ===
size = 10
bucket_count = 11
load_factor = 0.909091
max_load_factor = 1
size limit = 11
9 8 7 6 5
size = 11
bucket_count = 23
load_factor = 0.478261
max_load_factor = 1
size limit = 23
4 5 6 7 8
=== output ===
cf. https://wandbox.org/permlink/QhPfL6787GV8RYXV
The C++17 standard 26.2.7[unord.req]/p.15 says,
The insert and emplace members shall not affect the validity of iterators if
(N+n) <= z * B, where N is the number of elements in the container prior to
the
insert operation, n is the number of elements inserted, B is the container's
bucket count, and z is the container’s maximum load factor.
So, I think that the sample code above should never rehash.
[Bug c++/77841] New: a new expression of a char array cannot be initialized by a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77841
Bug ID: 77841
Summary: a new expression of a char array cannot be initialized
by a string literal
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Target Milestone: ---
Please see the sample code below.
== sample code ==
int main()
{
char* s = new char[4]{"abc"};
}
== sample code ==
= compiler output (GCC HEAD 7.0.0 20161003) =
prog.cc: In function 'int main()':
prog.cc:3:32: error: invalid conversion from 'const char*' to 'char'
[-fpermissive]
char* s = new char[4]{"abc"};
^
= compiler output (GCC HEAD 7.0.0 20161003) =
cf. http://melpon.org/wandbox/permlink/utGUZYo8NKRqGDM5
The latest draft standard says,
5.3.4 New [expr.new] p.17.2
Otherwise, the new-initializer is interpreted according to the initialization
rules of 8.5 for direct-initialization.
8.5 Initializers [dcl.init] p.17.1
If the initializer is a (non-parenthesized) braced-init-list, the object or
reference is list-initialized (8.5.4).
8.5.4 List-initialization [dcl.init.list] p.3.2
Otherwise, if T is a character array and the initializer list has a single
element that is an appropriately-typed string literal (8.5.2), initialization
is performed as described in that section.
So, I think that the sample code above should be compiled successfully.
Note that 8.5.4 p.3.2 was added for resolution of
DR1490.(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1490) and
DR1467.(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1467).
Note also that GCC (at least 4.4.7 or later) accepts a string-literal within a
brace-init-list for (usual) direct-initialization.
== sample code ==
int main()
{
char s[4]{"abc"};
}
== sample code ==
cf. http://melpon.org/wandbox/permlink/fZkVTLQXBxatUjBX
[Bug c++/70352] [C++11] auto cannot be used in the type-id of a new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70352 --- Comment #1 from Mitsuru Kariya --- Sorry, I forgot to paste an error message. = error message = prog.cc: In function 'int main()': prog.cc:3:19: error: invalid use of 'auto' auto p = new (auto)(42); ^~~~ = error message =
[Bug c++/70352] New: [C++11] auto cannot be used in the type-id of a new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70352
Bug ID: 70352
Summary: [C++11] auto cannot be used in the type-id of a
new-expression
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Target Milestone: ---
The sample code below should be compiled successfully but it causes a
compilation error.
== sample code ==
int main()
{
auto p = new (auto)(42);
}
== sample code ==
cf. http://melpon.org/wandbox/permlink/eSIE4OPkAubCIO5z
The C++11 standard 7.1.6.4 [dcl.spec.auto] p.4 says,
The auto type-specifier can also be used in declaring a variable in ...,
in the type-specifier-seq in the new-type-id or type-id of a new-expression
(5.3.4),
...
The 'auto' type-specifier above is a type-id, so it is well-formed.
[Bug c++/70351] New: [C++11] static constexpr member cannot define with a const qualifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70351
Bug ID: 70351
Summary: [C++11] static constexpr member cannot define with a
const qualifier
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Target Milestone: ---
Please see the sample code below.
== sample code ==
struct T {};
struct S {
static constexpr T m{};
};
const T S::m;
int main(){}
== sample code ==
= error message =
prog.cc:7:12: error: 'constexpr' needed for in-class initialization of static
data member 'const T S::m' of non-integral type [-fpermissive]
const T S::m;
^
= error message =
cf. http://melpon.org/wandbox/permlink/TWKgHmFWnK07lCdm
I think that the code should be compiled successfully.
(The constexpr specifier has no effect on the type of a variable
except that it qualifies the variable as a const.)
Note that it is compiled successfully if T is an integral type.
== sample code ==
using T = int;
struct S {
static constexpr T m{};
};
const T S::m;
int main(){}
== sample code ==
cf. http://melpon.org/wandbox/permlink/59kDO82vFfFEsLJF
Note also that it is compiled successfully if a constexpr specifier
is used in the definition.
== sample code ==
struct T {};
struct S {
static constexpr T m{};
};
constexpr T S::m;
int main(){}
== sample code ==
cf. http://melpon.org/wandbox/permlink/pywyTowtvOVJ6sB5
[Bug c++/66287] [C++11] A constexpr variable of const int* const cannot be initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66287
--- Comment #1 from Mitsuru Kariya kariya_mitsuru at hotmail dot com ---
I found several examples that cause the similar error message.
=== sample code 1 ===
constexpr int copy(const int v)
{
return v;
}
constexpr const int r = 42;
constexpr const int c = copy(r);
int main() {}
=== sample code 1 ===
== output 1 ==
prog.cc:7:32: error: modification of '_ZGR1c1' is not a constant-expression
constexpr const int c = copy(r);
^
== output 1 ==
cf. http://melpon.org/wandbox/permlink/fbHQBPKu1LETPmIr
=== sample code 2 ===
struct T {
int i;
};
constexpr T copy(const T v)
{
return v;
}
constexpr const auto r = T{42};
constexpr const auto c = copy(r);
int main() {}
=== sample code 2 ===
== output 2 ==
prog.cc:11:33: error: modification of '_ZGR1c1' is not a constant-expression
constexpr const auto c = copy(r);
^
== output 2 ==
cf. http://melpon.org/wandbox/permlink/0KeNtSOZrybNAnxa
I think these examples should be compiled successfully, but I am not sure about
the latter case because CLANG also rejects it.
[Bug c++/66287] New: [C++11] A constexpr variable of const int* const cannot be initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66287
Bug ID: 66287
Summary: [C++11] A constexpr variable of const int* const
cannot be initialized
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Target Milestone: ---
Created attachment 35627
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35627action=edit
g++ -v
Please see the sample code below.
=== sample code ===
constexpr const int i = 42;
constexpr const int* const p = i;
int main() {}
=== sample code ===
== output ==
prog.cc:2:34: error: modification of '_ZGR1p1' is not a constant-expression
constexpr const int* const p = i;
^
== output ==
cf. http://melpon.org/wandbox/permlink/RfoewySFecAtfEOV
I think that i is a valid constant expression.
Note that it is compiled successfully if the variable i is not a reference.
=== sample code ===
constexpr const int i = 42;
constexpr const int* const p = i;
int main() {}
=== sample code ===
cf. http://melpon.org/wandbox/permlink/qdLd3nqzteNRrnow
Note also that an rvalue reference causes the same error.
=== sample code ===
constexpr int i = 42;
constexpr int* p = i;
int main() {}
=== sample code ===
== output ==
prog.cc:2:23: error: modification of '_ZGR1p1' is not a constant-expression
constexpr int* p = i;
^
== output ==
cf. http://melpon.org/wandbox/permlink/TzS1T2dzyjSMxlKd
[Bug c++/65398] [5 Regression] [C++11] GCC rejects constexpr variable definitions with valid initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65398
--- Comment #13 from Mitsuru Kariya kariya_mitsuru at hotmail dot com ---
Thank you for your quick response.
But unfortunately, I found problems like below.
== sample code 1 ==
constexpr char f(const char* s)
{
return *(s + 1);
}
constexpr char s[] = ss;
constexpr auto c = f(s[0]);
int main() {}
== sample code 1 ==
= error message 1 =
sample1.cpp:8:21: in constexpr expansion of 'f(( s[0]))'
sample1.cpp:8:27: error: '*(s + 1u)' is not a constant expression
constexpr auto c = f(s[0]);
^
= error message 1 =
== sample code 2 ==
constexpr char s1[] = s1;
constexpr char s2[] = s2;
constexpr auto eq = (s1 + 0) == (s2 + 1);
int main() {}
== sample code 2 ==
= error message 2 =
sample2.cpp:4:30: error: '(((const char*)( s1)) == (((const char*)( s2)) +
1u))' is not a constant expression
constexpr auto eq = (s1 + 0) == (s2 + 1);
^
= error message 2 =
== sample code 3 ==
constexpr bool g(char const* found, char const* last) {
return found == last;
}
constexpr bool f(const char* s)
{
return g(s, s + 1);
}
constexpr char s[] = ss;
constexpr auto b = f(s[0]);
int main() {}
== sample code 3 ==
= error message 3 =
sample3.cpp:2:15: error: '(( s[0]) == (( s[0]) + 1u))' is not a constant
expression
return found == last;
^
= error message 3 =
The sample code 1 is compiled successfully on both the 4.9.2 and the previous
revision but it causes an error on the head revision.
The sample code 2 causes an error on the 4.9.2, the previous revision and the
head revision.
The sample code 3 is compiled successfully on the 4.9.2, but it causes an error
on both the previous revision and the head revision.
(I use a constexpr library and its tests are passed on 4.9.2 but are failed on
5.0.0.)
[Bug c++/65642] New: GCC rejects valid constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65642 Bug ID: 65642 Summary: GCC rejects valid constant expression Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kariya_mitsuru at hotmail dot com
[Bug c++/65398] [5 Regression] [C++11] GCC rejects constexpr variable definitions with valid initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65398 --- Comment #15 from Mitsuru Kariya kariya_mitsuru at hotmail dot com --- I have opened a new issue bug 65642. (Sorry, I made a mistake in operation so its description is empty.)
[Bug c++/65642] [C++11] GCC rejects valid constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65642
Mitsuru Kariya kariya_mitsuru at hotmail dot com changed:
What|Removed |Added
Summary|GCC rejects valid constant |[C++11] GCC rejects valid
|expression |constant expression
--- Comment #1 from Mitsuru Kariya kariya_mitsuru at hotmail dot com ---
Please see the sample codes below.
== sample code 1 ==
constexpr char f(const char* s)
{
return *(s + 1);
}
constexpr char s[] = ss;
constexpr auto c = f(s[0]);
int main() {}
== sample code 1 ==
= error message 1 =
sample1.cpp:8:21: in constexpr expansion of 'f(( s[0]))'
sample1.cpp:8:27: error: '*(s + 1u)' is not a constant expression
constexpr auto c = f(s[0]);
^
= error message 1 =
== sample code 2 ==
constexpr bool g(char const* found, char const* last) {
return found == last;
}
constexpr bool f(const char* s)
{
return g(s, s + 1);
}
constexpr char s[] = ss;
constexpr auto b = f(s[0]);
int main() {}
== sample code 2 ==
= error message 2 =
sample2.cpp:2:15: error: '(( s[0]) == (( s[0]) + 1u))' is not a constant
expression
return found == last;
^
= error message 2 =
== sample code 3 ==
constexpr char s1[] = s1;
constexpr char s2[] = s2;
constexpr auto eq = (s1 + 0) == (s2 + 1);
int main() {}
== sample code 3 ==
= error message 3 =
sample3.cpp:4:30: error: '(((const char*)( s1)) == (((const char*)( s2)) +
1u))' is not a constant expression
constexpr auto eq = (s1 + 0) == (s2 + 1);
^
= error message 3 =
The sample code 1 and 2 are compiled successfully on the 4.9.2, but they cause
an error on the head revision.
The sample code 3 causes an error on the 4.9.2 and the head revision.
These testcases are derived from bug 65398.
[Bug c++/65398] [5 Regression] [C++11] GCC rejects constexpr variable definitions with valid initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65398
--- Comment #6 from Mitsuru Kariya kariya_mitsuru at hotmail dot com ---
I also found a strange behavior like below.
== sample code ==
#include iostream
constexpr char s1[] = s1;
constexpr char s2[] = s2;
bool f(const char* p1, const char* p2) { return p1 == p2; }
constexpr auto eq1 = s1[sizeof(s1)] == s2[0];
auto eq2 = f(s1[sizeof(s1)], s2[0]);
int main()
{
std::cout static_castconst void*(s1[sizeof(s1)]) std::endl;
std::cout static_castconst void*(s2[0]) std::endl;
std::cout std::boolalpha eq1 , eq2 std::endl;
}
== sample code ==
== output ==
0x400bb8
0x400bb8
false, true
== output ==
cf. http://melpon.org/wandbox/permlink/Iu0rFFMgeYqT98fo
I think that it should either
1) cause a compilation error at the definition of the eq1 if the result of
s1[sizeof(s1)] == s2[0] is unspecified.
or
2) output true, true because both the s1[sizeof(s1)] and s2[0]
represent the same address.
but I am not sure which behavior is appropriate.
(I cannot find an explicit description by which comparison between one past the
end pointer and another object's pointer is unspecified behavior, in the C++
standard.)
[Bug c++/65398] [5 Regression] [C++11] GCC rejects constexpr variable definitions with valid initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65398 --- Comment #8 from Mitsuru Kariya kariya_mitsuru at hotmail dot com --- Oh, thanks a lot! I've got it. (And I've understood the reason why clang rejects it ;).)
[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65509
Mitsuru Kariya kariya_mitsuru at hotmail dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #15 from Mitsuru Kariya kariya_mitsuru at hotmail dot com ---
I found another sample like below.
= sample code =
constexpr char s[] = s;
constexpr auto eq = (s[0] + 0) == (s[0] + 1);
int main() {}
= sample code =
error message
compare3.cpp:3:33: error: '(( s[0]) == (( s[0]) + 1u))' is not a constant
expression
constexpr auto eq = (s[0] + 0) == (s[0] + 1);
error message
Note that gcc 4.9.2 accepts it.
cf. http://melpon.org/wandbox/permlink/RybrdNbUdtMi39wX
[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65509
--- Comment #14 from Mitsuru Kariya kariya_mitsuru at hotmail dot com ---
The rev.221737 seems to be able to compile the sample code above, but cannot
compile another sample code like below.
= sample code =
constexpr char s1[] = s1;
constexpr char s2[] = s2;
constexpr auto eq = (s1 + 0) == (s2 + 1);
int main() {}
= sample code =
error message
compare2.cpp:4:30: error: '(((const char*)( s1)) == (((const char*)( s2)) +
1u))' is not a constant expression
constexpr auto eq = (s1 + 0) == (s2 + 1);
error message
Although the first sample causes compilation error only in 5.0.0, the second
sample causes compilation error in 4.9.2 too.
cf. http://melpon.org/wandbox/permlink/KhcREuNqGofbZvqw
[Bug c++/65579] New: [C++11] gcc requires definition of a static constexpr member even though it is not odr-used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65579
Bug ID: 65579
Summary: [C++11] gcc requires definition of a static constexpr
member even though it is not odr-used
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 35143
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35143action=edit
g++ -v
The sample code below should be compiled and linked successfully but it causes
a linkage error.
== sample code ==
template typename
struct S {
int i;
};
struct T {
static constexpr Sint s{1};
};
int main()
{
return T::s.i;
}
== sample code ==
cf. http://melpon.org/wandbox/permlink/JFgGdscpiHVEJpdb
I think that the T::s is not odr-used.
Note that it is compiled and linked successfully if S is not a template.
== sample code ==
struct S {
int i;
};
struct T {
static constexpr S s{1};
};
int main()
{
return T::s.i;
}
== sample code ==
cf. http://melpon.org/wandbox/permlink/bvH2k7pW8WQSXQmN
[Bug c++/54483] undefined reference to static constexpr in .so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54483
Mitsuru Kariya kariya_mitsuru at hotmail dot com changed:
What|Removed |Added
CC||kariya_mitsuru at hotmail dot
com
--- Comment #9 from Mitsuru Kariya kariya_mitsuru at hotmail dot com ---
(In reply to Juisoo from comment #8)
However, if I add another data member which is initialized with val by
default, I still get the undefined reference error, see second attachment.
The second testcase is reduced like below.
== testcase ==
struct A {
static constexpr float val = 0.08;
A(const float = val) {}
};
int main()
{
A{};
}
== testcase ==
cf. http://melpon.org/wandbox/permlink/ZCbNwLlPQakWjluY
I think that the testcase is ill-formed because the A::val is odr-used.
When A's ctor is called with no argument,
1) The lvalue-to-rvalue conversion is not applied to A::val.
(Since the ctor's parameter is a reference type.)
2) A::val is not a discarded-value expression.
On the other hand, A::val is not odr-used in the first testcase.
(Since the builtin unary - operator requires that its operand is a prvalue.)
So, I think that this pr is fixed.
(But I don't know whether this pr can be closed since I cannot find a test.)
[Bug c++/65509] New: [C++11] GCC rejects operator== with two distinct pointers as not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65509
Bug ID: 65509
Summary: [C++11] GCC rejects operator== with two distinct
pointers as not constexpr
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 35091
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35091action=edit
g++ -v
The sample code below should be compiled successfully but gcc 5.0 rejects it.
= sample code =
constexpr int i1 = 1;
constexpr int i2 = 2;
constexpr auto b = i1 == i2;
int main() {}
= sample code =
cf. http://melpon.org/wandbox/permlink/1Ae9Blr93vcU9qKQ
Note that gcc 4.9.2 accepts it.
cf. http://melpon.org/wandbox/permlink/72exRtJrkijS9D8u
[Bug c++/65398] New: [C++11] GCC rejects constexpr variable definitions with valid initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65398
Bug ID: 65398
Summary: [C++11] GCC rejects constexpr variable definitions
with valid initialization
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 35017
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35017action=edit
g++ -v
The sample code below should be compiled successfully but gcc 5.0 rejects it.
= sample code =
constexpr char s[] = abc;
constexpr char c = *(s[0] + 1);
int main() {}
= sample code =
cf. http://melpon.org/wandbox/permlink/jRbgl6YCTXHSspI9
Note that gcc 4.9.2 accepts it.
cf. http://melpon.org/wandbox/permlink/bwuaSYUvgwAjRTfo
Note also that gcc 5.0 accepts if s[0] is replaced with s.
= sample code =
constexpr char s[] = abc;
constexpr char c = *(s + 1);
int main() {}
= sample code =
cf. http://melpon.org/wandbox/permlink/sy0THyfnSq6XCT0L
[Bug c/65350] New: [C++14] operator new[] should not be called if # of initializer elements exceeds # of elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65350
Bug ID: 65350
Summary: [C++14] operator new[] should not be called if # of
initializer elements exceeds # of elements
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Please see the sample code below.
== sample code ==
#include iostream
#include new
void* operator new[](std::size_t size)
{
std::cout my operator new[]( size ) std::endl;
return ::operator new(size);
}
int main()
{
int i = 1;
try {
int* p = new int[i]{ 1, 2 };
delete[] p;
} catch (const std::bad_array_new_length e) {
std::cout e.what() std::endl;
}
}
== sample code ==
== output ==
my operator new[](4)
std::bad_array_new_length
== output ==
cf. http://melpon.org/wandbox/permlink/tQFp5fpPXT5mZu34
The C++14 standard 5.3.4[expr.new]/p.7 says,
The expression in a noptr-new-declarator is erroneous if:
...
--- the new-initializer is a braced-init-list and the number of array
elements
for which initializers are provided (including the terminating '\0' in
a
string literal (2.13.5)) exceeds the number of elements to initialize.
... Otherwise, a new-expression with an erroneous expression **does not call
an allocation function** and terminates by throwing an exception of a type
that would match a handler (15.3) of type std::bad_array_new_length
(18.6.2.2).
...
(emphasis mine)
So, I think that the sample code above should output only
== output ==
std::bad_array_new_length
== output ==
[Bug c/65350] [C++14] operator new[] should not be called if # of initializer elements exceeds # of elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65350 --- Comment #1 from Mitsuru Kariya kariya_mitsuru at hotmail dot com --- Created attachment 34985 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34985action=edit g++ -v
[Bug c++/65295] New: [C++1y] constexpr function causes ICE if it returns a local variable bigger than 16 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65295
Bug ID: 65295
Summary: [C++1y] constexpr function causes ICE if it returns a
local variable bigger than 16 bytes
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 34934
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34934action=edit
g++ -v
The sample code below causes ICE.
== sample code ==
struct arr {
constexpr arr() : elem() {}
char elem[17];
};
constexpr arr f()
{
arr result;
return result;
}
constexpr arr a{f()};
int main(){}
== sample code ==
== ICE output ==
prog.cc:12:19: in constexpr expansion of 'f()'
prog.cc:12:20: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.c:2959
constexpr arr a{f()};
^
0x6fac0e cxx_eval_constant_expression
/home/heads/gcc/gcc-source/gcc/cp/constexpr.c:2959
0x6f86ed cxx_eval_constant_expression
/home/heads/gcc/gcc-source/gcc/cp/constexpr.c:3117
0x6f84e2 cxx_eval_conditional_expression
/home/heads/gcc/gcc-source/gcc/cp/constexpr.c:1678
0x6f84e2 cxx_eval_constant_expression
/home/heads/gcc/gcc-source/gcc/cp/constexpr.c:3316
0x6fb451 cxx_eval_statement_list
/home/heads/gcc/gcc-source/gcc/cp/constexpr.c:2866
0x6f85ab cxx_eval_constant_expression
/home/heads/gcc/gcc-source/gcc/cp/constexpr.c:3388
0x6f8ecc cxx_eval_constant_expression
/home/heads/gcc/gcc-source/gcc/cp/constexpr.c:3394
0x6fde37 cxx_eval_call_expression
/home/heads/gcc/gcc-source/gcc/cp/constexpr.c:1392
0x6f8eab cxx_eval_constant_expression
/home/heads/gcc/gcc-source/gcc/cp/constexpr.c:3021
0x6fb610 cxx_eval_outermost_constant_expr
/home/heads/gcc/gcc-source/gcc/cp/constexpr.c:3529
0x639247 store_init_value(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, int)
/home/heads/gcc/gcc-source/gcc/cp/typeck2.c:833
0x60bde5 check_initializer
/home/heads/gcc/gcc-source/gcc/cp/decl.c:6002
0x60cf3c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/heads/gcc/gcc-source/gcc/cp/decl.c:6638
0x68108e cp_parser_init_declarator
/home/heads/gcc/gcc-source/gcc/cp/parser.c:17282
0x6826ec cp_parser_simple_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:11592
0x6829e3 cp_parser_block_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:11466
0x687db9 cp_parser_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:11363
0x68803a cp_parser_declaration_seq_opt
/home/heads/gcc/gcc-source/gcc/cp/parser.c:11249
0x68866f cp_parser_translation_unit
/home/heads/gcc/gcc-source/gcc/cp/parser.c:4100
0x68866f c_parse_file()
/home/heads/gcc/gcc-source/gcc/cp/parser.c:33173
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
== ICE output ==
cf. http://melpon.org/wandbox/permlink/GaYaqMrDUdWiU65i
It does not cause ICE if
(1) sizeof(arr) is smaller than or equal to 16.
cf. http://melpon.org/wandbox/permlink/lNwMp9fSmYG9vOzc
or
(2) it is compiled with -fno-elide-constructors.
cf. http://melpon.org/wandbox/permlink/HK7UlzKRPmLTqmz7
[Bug libstdc++/65290] New: [C++11] operator new(std::size_t, const std::nothrow_t) should call operator new(std::size_t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65290
Bug ID: 65290
Summary: [C++11] operator new(std::size_t, const
std::nothrow_t) should call operator new(std::size_t)
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 34930
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34930action=edit
g++ -v
Please see the sample code below.
== sample code ==
#include iostream
#include new
void* operator new(std::size_t)
{
throw std::bad_alloc();
}
int main()
{
int* p = new(std::nothrow) int;
std::cout std::boolalpha (p == nullptr) std::endl;
delete p;
}
== sample code ==
== output ==
false
== output ==
cf. http://melpon.org/wandbox/permlink/LTq0gqETftUEvWK0
The C++11 standard 18.6.1.1[new.delete.single]/p.8 says,
Default behavior: Calls operator new(size). If the call returns normally,
returns the result of that call. Otherwise, returns a null pointer.
This description was changed in C++11(see LWG DR206).
cf. http://cplusplus.github.io/LWG/lwg-defects.html#206
So, I think that the sample code above should output
== output ==
true
== output ==
I am not sure whether operator new(std::size_t, const std::nothrow_t) should
call operator new(std::size_t) in C++03 mode.
[Bug libstdc++/64903] New: is_partitioned should not apply a predicate more than (last - first) times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64903
Bug ID: 64903
Summary: is_partitioned should not apply a predicate more than
(last - first) times
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 34645
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34645action=edit
g++ -v
Please see the sample code below.
= sample code =
#include iostream
#include algorithm
int main()
{
int v[] = { 1, 3, 5, 7, 9, 2, 4, 6, 8, 10 };
int c = 0;
std::cout std::boolalpha
std::is_partitioned(v, v + 10, [c](int x) { return ++c, (x 1) !=
0; })
std::endl;
std::cout c times std::endl;
}
= sample code =
= output =
true
11 times
= output =
cf. http://melpon.org/wandbox/permlink/OHXgHtbgmm4Ak8pJ
The C++11 standard 25.3.13[alg.partitions]/p.3 says, At most last - first
applications of pred.
So the sample code above should output
= output =
true
10 times
= output =
[Bug libstdc++/64680] New: basic_regex::operator= does not reset flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64680
Bug ID: 64680
Summary: basic_regex::operator= does not reset flags
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 34491
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34491action=edit
g++ -v
The sample code below should not throw a regex_error.
= sample code =
#include regex
int main()
{
std::regex re([[:alnum:]], std::regex_constants::basic);
re = \\w+;
}
===
cf. http://melpon.org/wandbox/permlink/lrD2Ia4urIPVgakK
According to the C++11 standard 28.8.3[re.regex.assign], operator=(const charT*
ptr) is equivalent to assign(ptr), and assign(ptr) calls assign(const char*
ptr, flag_type f = regex_constants::ECMAScript).
Since \\w+ is a valid ECMAScript syntax, the sample code above should end
normally.
[Bug libstdc++/64585] New: The basic_regex object should not match any character sequence after a call to basic_regex::imbue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64585
Bug ID: 64585
Summary: The basic_regex object should not match any character
sequence after a call to basic_regex::imbue
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 34437
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34437action=edit
g++ -v
Please see the following sample.
=== sample code ===
#include iostream
#include regex
int main()
{
static const char s[] = ;
std::regex re();
std::cout std::boolalpha std::regex_search(s, re) std::endl;
auto loc = re.imbue(re.getloc());
std::cout std::boolalpha std::regex_search(s, re) std::endl;
}
===
= output ==
true
true
===
cf. http://melpon.org/wandbox/permlink/0wKMiCY8uNEhOecE
The C++11 standard 28.8.5[re.regex.locale]/p.1 says, After a call to imbue the
basic_regex object does not match any character sequence.
So I think that the output should be
= output ==
true
false
===
[Bug libstdc++/64584] New: basic_regex::assign breaks *this if it throws regex_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64584
Bug ID: 64584
Summary: basic_regex::assign breaks *this if it throws
regex_error
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 34436
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34436action=edit
g++ -v
Please see the following sample.
=== sample code ===
#include iostream
#include regex
int main()
{
std::regex re();
std::cout re.flags() std::endl;
try {
re.assign((, std::regex_constants::icase);
} catch (const std::regex_error e) {
std::cout e.code() std::endl;
}
std::cout re.flags() std::endl;
}
===
= output ==
16
5
1
===
cf. http://melpon.org/wandbox/permlink/tqxSS6MImnpsCGUf
The C++11 standard 28.8.3[re.regex.assign]/p.15 says, If an exception is
thrown, *this is unchanged.
So I think that the output should be
= output ==
16
5
16
===
[Bug libstdc++/64239] regex_iterator::operator= should copy match_results::position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64239
--- Comment #7 from Mitsuru Kariya kariya_mitsuru at hotmail dot com ---
When I used the match_results::swap on r218710, I got a compilation error.
== sample code
==
#include regex
int main()
{
std::cmatch mm1, mm2;
mm1.swap(mm2);
}
=
== g++ output
===
In file included from /usr/local/gcc-218710/include/c++/5.0.0/regex:59:0,
from swap.cpp:1:
/usr/local/gcc-218710/include/c++/5.0.0/bits/regex.h: In instantiation of 'void
std::match_results template-parameter-1-1, template-parameter-1-2
::swap(std::match_results template-parameter-1-1, template-parameter-1-2
) [with _Bi_iter = const char*; _Alloc = std::allocatorstd::sub_matchconst
char* ]':
swap.cpp:7:15: required from here
/usr/local/gcc-218710/include/c++/5.0.0/bits/regex.h:1864:6: error: no matching
function for call to 'std::match_resultsconst char*::swap(const char*, const
char*)'
swap(_M_begin, __that._M_begin);
^
/usr/local/gcc-218710/include/c++/5.0.0/bits/regex.h:1861:7: note: candidate:
void std::match_results template-parameter-1-1, template-parameter-1-2
::swap(std::match_results template-parameter-1-1, template-parameter-1-2
) [with _Bi_iter = const char*; _Alloc = std::allocatorstd::sub_matchconst
char* ]
swap(match_results __that)
^
/usr/local/gcc-218710/include/c++/5.0.0/bits/regex.h:1861:7: note: candidate
expects 1 argument, 2 provided
=
g++ -v
=
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-218710/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-218710/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc.218710/configure --prefix=/usr/local/gcc-218710
--enable-checking=yes --disable-nls --enable-languages=c,c++,lto
Thread model: posix
gcc version 5.0.0 20141213 (experimental) (GCC)
=
Note that the sample code above was compiled successfully on r218555.
I think that the match_results::swap needs use std::swap; for swapping
_M_begin.
[Bug libstdc++/64441] A match_results returns an incorrect sub_match if the sub_match::matched is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64441
--- Comment #2 from Mitsuru Kariya kariya_mitsuru at hotmail dot com ---
The rev.219121 seems to satisfy the sample code above, but does not satisfy
another sample code like below.
== sample code
==
#include iostream
#include regex
int main()
{
const char s[] = abc;
const std::regex re((\\d+)|(\\w+));
std::cmatch m;
std::regex_search(s, m, re);
std::cout std::boolalpha;
for (size_t i = 0, n = m.size(); i = n; ++i) {
auto sub = m[i];
std::cout i : sub.matched , str = ' sub.str() ',
range = [ sub.first - s , sub.second - s )
std::endl;
}
}
=
= output =
0:true, str = 'abc', range = [0, 3)
1:false, str = '', range = [3, 3)
2:true, str = 'abc', range = [0, 3)
3:false, str = '', range = [-140735878146800, -140735878146800)
==
According to the C++11 standard 28.10.4[re.results.acc]/p.8,
If n = size() then returns a sub_match object representing an unmatched
sub-expression.
So, I think that n = 1 and n = 3 should be an identical result, and the output
should be
= output =
0:true, str = 'abc', range = [0, 3)
1:false, str = '', range = [3, 3)
2:true, str = 'abc', range = [0, 3)
3:false, str = '', range = [3, 3)
==
[Bug libstdc++/64441] New: A match_results returns an incorrect sub_match if the sub_match::matched is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64441
Bug ID: 64441
Summary: A match_results returns an incorrect sub_match if the
sub_match::matched is false
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 34362
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34362action=edit
g++ -v
Please see the following sample.
== sample code
==
#include iostream
#include regex
int main()
{
const char s[] = abc;
const std::regex re((\\d+)|(\\w+));
std::cmatch m;
std::regex_search(s, m, re);
std::cout std::boolalpha;
for (size_t i = 0, n = m.size(); i n; ++i) {
auto sub = m[i];
std::cout i : sub.matched , str = ' sub.str() ',
range = [ sub.first - s , sub.second - s )
std::endl;
}
}
=
= output =
0:true, str = 'abc', range = [0, 3)
1:false, str = '', range = [-140734305427376, -140734305427376)
2:true, str = 'abc', range = [0, 3)
==
cf. http://melpon.org/wandbox/permlink/SBoMF5UKYYa38Y4N
The C++11 standard 28.10[re.results]/p.4 says, Otherwise matched is false, and
members first and second point to the end of the sequence that was searched.
So, I think that the output should be
= output =
0:true, str = 'abc', range = [0, 3)
1:false, str = '', range = [3, 3)
2:true, str = 'abc', range = [0, 3)
==
[Bug libstdc++/64302] New: The match_results::cbegin()/cend() return incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64302
Bug ID: 64302
Summary: The match_results::cbegin()/cend() return incorrect
results
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 34277
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34277action=edit
g++ -v
The match_results::cbegin()/cend() should return identical results as the
match_results::begin()/end() but the match_results::cbegin()/cend() return
incorrect results by libstdc++.
== sample code ==
#include iostream
#include regex
#include string
int main()
{
std::string s( 111 222 );
std::regex re((\\d+)\\s+(\\d+));
std::smatch m;
if (std::regex_search(s, m, re)) {
std::cout begin - end std::endl;
for (auto it = m.begin(), end = m.end(); it != end; ++it) {
std::cout '\'' *it '\'' std::endl;
}
std::cout cbegin - cend std::endl;
for (auto it = m.cbegin(), end = m.cend(); it != end; ++it) {
std::cout '\'' *it '\'' std::endl;
}
} else {
std::cout unmatch! std::endl;
}
}
=
= output =
begin - end
'111 222'
'111'
'222'
cbegin - cend
'222'
' '
' '
==
cf. http://melpon.org/wandbox/permlink/Xhkav0mRRdT5wRXw
According to the C++11 standard 28.10.4[re.results.acc]/p.13 p.14, the
match_results::cbegin()/cend() has same difinitions as the
match_results::begin()/end().
[Bug libstdc++/64303] New: The regex_token_iterator's copy constructor creates an incorrect iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64303
Bug ID: 64303
Summary: The regex_token_iterator's copy constructor creates an
incorrect iterator
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 34278
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34278action=edit
g++ -v
Please see the following sample.
== sample code
==
#include iostream
#include regex
#include string
int main()
{
const std::string s( 111 222 );
const std::regex re(\\w+);
std::sregex_token_iterator it1(s.begin(), s.end(), re), it2(it1), end;
for (; it1 != end; ++it1) {
std::cout range = ( it1-first - s.begin() , it1-second -
s.begin() ),
str = ' it1-str() '\'' std::endl;
}
std::cout std::endl;
for (; it2 != end; ++it2) {
std::cout range = ( it2-first - s.begin() , it2-second -
s.begin() ),
str = ' it2-str() '\'' std::endl;
}
}
=
= output =
range = (2, 5), str = '111'
range = (7, 10), str = '222'
range = (488, 10), str = ''
range = (7, 10), str = '222'
==
cf. http://melpon.org/wandbox/permlink/Dbb2PcGdnNeNon2r
Though the C++11 standard says nothing about the regex_token_iterator's copy
constructor, I think that *it2 should be equal to *it1.
So, the output should be
= output =
range = (2, 5), str = '111'
range = (7, 10), str = '222'
range = (2, 5), str = '111'
range = (7, 10), str = '222'
==
Note that the operator= is a same result.
cf. http://melpon.org/wandbox/permlink/doxdyo4AfiFM6UMK
[Bug libstdc++/64239] regex_iterator::operator= should copy match_results::position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64239 --- Comment #3 from Mitsuru Kariya kariya_mitsuru at hotmail dot com --- Sorry, I confused the copy ctor with the copy assignment operator. But it seems that both are same results. operator= version : http://melpon.org/wandbox/permlink/ZHzYukOyuluuzpwu I didn't notice, but both the copy ctor and the copy assignment operator of match_results are also same results as Mr. Wakely pointed out above. copy ctor version : http://melpon.org/wandbox/permlink/Z4Z0kr5yTcB0iyEk operator= version : http://melpon.org/wandbox/permlink/tHBSWP3hJpinggzw
[Bug libstdc++/64239] New: regex_iterator::operator= should copy match_results::position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64239
Bug ID: 64239
Summary: regex_iterator::operator= should copy
match_results::position
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 34231
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34231action=edit
g++ -v
Please see the following sample.
== sample code
==
#include iostream
#include regex
#include string
int main()
{
std::regex re(\\w+);
std::string s(-a-b-c-);
for (auto it1 = std::sregex_iterator(s.begin(), s.end(), re), end =
std::sregex_iterator(); it1 != end; ++it1) {
auto it2 = it1;
std::cout position() = it1-position() , length() =
it1-length() , str() = ' it1-str() '\n
position() = it2-position() , length() =
it2-length() , str() = ' it2-str() '\n\n;
}
}
=
= output =
position() = 1, length() = 1, str() = 'a'
position() = 1, length() = 1, str() = 'a'
position() = 3, length() = 1, str() = 'b'
position() = 1, length() = 1, str() = 'b'
position() = 5, length() = 1, str() = 'c'
position() = 1, length() = 1, str() = 'c'
==
cf. http://melpon.org/wandbox/permlink/IiULKqL2GwCwwvHc
Though the C++11 standard says nothing about regex_iterator::operator=, I think
that it2-position() should be equal to it1-position().
So, the output should be
= output =
position() = 1, length() = 1, str() = 'a'
position() = 1, length() = 1, str() = 'a'
position() = 3, length() = 1, str() = 'b'
position() = 3, length() = 1, str() = 'b'
position() = 5, length() = 1, str() = 'c'
position() = 5, length() = 1, str() = 'c'
==
[Bug libstdc++/64140] New: match_results.prefix() returns an incorrect result if regex_iterator holds a zero-length match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64140
Bug ID: 64140
Summary: match_results.prefix() returns an incorrect result if
regex_iterator holds a zero-length match
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 34156
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34156action=edit
g++ -v
Please see the following sample.
== sample code
==
#include iostream
#include regex
#include string
void print(const char* t, const std::string s, const std::ssub_match sub)
{
std::cout t : (sub.matched ? matched : unmatched)
,
length() = sub.length() , str() = ' sub.str() \',
pair = ( sub.first - s.begin() , sub.second - s.begin()
),
' std::string(sub.first, sub.second) '\'' std::endl;
}
int main()
{
const std::regex e(z*);
const std::string s(ab);
int i = 0;
for (auto it = std::sregex_iterator(s.begin(), s.end(), e), end =
std::sregex_iterator();
it != end; ++it) {
std::cout i++ ':' std::endl;
print(prefix, s, it-prefix());
print(match , s, (*it)[0]);
std::cout std::endl;
}
}
=
= output =
0:
prefix: unmatched, length() = 0, str() = '', pair = (0, 0), ''
match : matched , length() = 0, str() = '', pair = (0, 0), ''
1:
prefix: unmatched, length() = 0, str() = '', pair = (0, 1), 'a'
match : matched , length() = 0, str() = '', pair = (1, 1), ''
2:
prefix: unmatched, length() = 0, str() = '', pair = (1, 2), 'b'
match : matched , length() = 0, str() = '', pair = (2, 2), ''
==
cf. http://melpon.org/wandbox/permlink/JSkP6tl2QWFxmOEv
According to C++11 standard 28.11.3[re.alg.search]/p.3 Table 143,
prefix().matched should be true
if prefix().first != prefix().second.
(prefix().first is correct, because 28.12.1.4[re.regiter.incr]/p.5 says
match.prefix().first
shall be equal to the previous value of match[0].second.)
So, I think that the output should be
= output =
0:
prefix: unmatched, length() = 0, str() = '', pair = (0, 0), ''
match : matched , length() = 0, str() = '', pair = (0, 0), ''
1:
prefix: matched , length() = 1, str() = 'a', pair = (0, 1), 'a'
match : matched , length() = 0, str() = '', pair = (1, 1), ''
2:
prefix: matched , length() = 1, str() = 'b', pair = (1, 2), 'b'
match : matched , length() = 0, str() = '', pair = (2, 2), ''
==
[Bug libstdc++/63990] New: regex_search increments a past-the-end iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63990
Bug ID: 63990
Summary: regex_search increments a past-the-end iterator
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 34049
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34049action=edit
g++ -v
The sample code below is aborted with attempt to increment a past-the-end
iterator.
=
#include regex
#include debug/string
int main()
{
__gnu_debug::string s = a;
std::regex_search(s.begin(), s.end(), std::regex(b));
}
=
cf. http://melpon.org/wandbox/permlink/2EesivDageAWjAnN
It seems that it always occurs if regex_search is not matched.
It also seems that such an iterator is never accessed.
cf. http://melpon.org/wandbox/permlink/PfGxfu5qjoqaDgEm
I think that it may not cause any problem.
But it is better to fix.
[Bug libstdc++/63920] Any regular expression should not match an empty sequence if match_not_null is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63920 --- Comment #1 from Mitsuru Kariya kariya_mitsuru at hotmail dot com --- Sorry, the last link was mistaken. The right link is below. http://melpon.org/wandbox/permlink/v1HhsIs8d2LrmUk9
[Bug libstdc++/63920] New: Any regular expression should not match an empty sequence if match_not_null is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63920
Bug ID: 63920
Summary: Any regular expression should not match an empty
sequence if match_not_null is specified
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 34005
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34005action=edit
gcc -v
The sample code below should output not match but it outputs match:1, 0 if
it is compiled by gcc 5.0.
#include iostream
#include regex
int main()
{
std::cmatch m;
auto result = std::regex_search(a, m, std::regex(b*),
std::regex_constants::match_not_null);
if (result) {
std::cout match: m.position() , m.length()
std::endl;
} else {
std::cout not match std::endl;
}
}
cf. http://melpon.org/wandbox/permlink/pTz5CBMMP4a6BU7f
According to C++11 standard 28.5.2[re.matchflag]/Table 139, The expression
shall not match an empty sequence. if match_not_null is specified.
Note that the sample code of the Boost.regex version outputs not match.
cf. http://melpon.org/wandbox/permlink/mfFqERCbt6qFf8HC
[Bug c++/63654] New: An explicit copy constructor should be used in the second step of a class copy-initialization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63654
Bug ID: 63654
Summary: An explicit copy constructor should be used in the
second step of a class copy-initialization.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 33815
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33815action=edit
gcc -v
The sample code below should be compiled successfully but it causes a
compilation error by gcc.
sample code ===
struct S {
explicit S(const S) {}
S(int) {}
};
int main()
{
S s = 1;
}
= compiler output
prog.cc: In function 'int main()':
prog.cc:8:11: error: no matching function for call to 'S::S(S)'
S s = 1;
^
prog.cc:3:5: note: candidate: S::S(int)
S(int) {}
^
prog.cc:3:5: note: no known conversion for argument 1 from 'S' to 'int'
prog.cc:3:5: note: after user-defined conversion: S::S(int)
= compiler output
cf. http://melpon.org/wandbox/permlink/fA27PoaI9y9q2Xz6
C++ standard [dcl.init]/p.17.6.2 says that
... The result of the call (which is the temporary for the constructor case) is
then used to direct-initialize, according to the rules above, the object that
is the destination of the copy-initialization. ...
I think that the variable s should be *direct-initialize* from the result of
the call S(int), so the explicit copy constructor explicit S(const S)
should be used.
(at least if the option -pedantic-errors is specified)
[Bug c++/63604] New: [C++11] A direct-initialization of a reference should use explicit conversion functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63604
Bug ID: 63604
Summary: [C++11] A direct-initialization of a reference should
use explicit conversion functions
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
The sample code below should be compiled successfully but it causes compilation
error by gcc.
==
struct T {};
struct S {
explicit operator T() { return T(); }
};
int main()
{
S s;
T t(s);
(void) t;
}
==
cf. http://melpon.org/wandbox/permlink/LHgajpAXzqTbpYDc
An initialization of a reference in a direct-initialization context should use
an explicit conversion function that converts to a class prvalue.
The latest C++ standard (n4140) 13.3.1.6 [over.match.ref]/p.1.1 says that
The conversion functions of S and its base classes are considered. Those
non-explicit conversion functions that are not hidden within S and yield type
“lvalue reference to cv2 T2” (when initializing an lvalue reference or an
rvalue reference to function) or “cv2 T2” or “rvalue reference to cv2 T2” (when
initializing an rvalue reference or an lvalue reference to function), where
“cv1 T” is reference-compatible (8.5.3) with “cv2 T2”, are candidate functions.
For direct-initialization, those explicit conversion functions that are not
hidden within S and yield type “lvalue reference to cv2 T2” or “cv2 T2” or
“rvalue reference to cv2 T2”, respectively, where T2 is same type as T or can
be converted to type T with a qualification conversion (4.4), are also
candidate functions.
I think that this sample code corresponds to the case “For
direct-initialization, ...”.
Note that this sample code is compiled successfully if the conversion function
returns an rvalue reference.
(cf. http://melpon.org/wandbox/permlink/kGpALX7zvzHzi7K5)
See also BUG 48453.
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 Mitsuru Kariya kariya_mitsuru at hotmail dot com changed: What|Removed |Added CC||kariya_mitsuru at hotmail dot com --- Comment #10 from Mitsuru Kariya kariya_mitsuru at hotmail dot com --- Each status of the issues mentioned above is CWG 1287: DRWP CWG 1604: DR CWG 1650: NAD And, gcc HEAD (5.0.0) does not cause the slicing problem. cf. 5.0.0 http://melpon.org/wandbox/permlink/xQQq1n98s7blSz8x cf. 4.9.1 http://melpon.org/wandbox/permlink/l69tDXdptf1WVdAT Note that these are compiled with the option -fno-elide-constructors. (Sorry, I don't know whether this issue should be RESOLVED FIXED or not, however.)
[Bug c++/63290] New: [C++11] alias declaration with exception specification should cause compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63290 Bug ID: 63290 Summary: [C++11] alias declaration with exception specification should cause compilation error Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kariya_mitsuru at hotmail dot com The sample code below should cause a compilation error but it can be compiled successfully by g++. using FP = void(*)() noexcept; cf. http://melpon.org/wandbox/permlink/mAWrk0HBXLEOxGyw According C++11 standard [except.spec] 15.4/2, An exception-specification shall not appear in a typedef declaration or alias-declaration. Note: Another sample code below causes a compilation error. typedef void(*FP)() noexcept; cf. http://melpon.org/wandbox/permlink/42ybFVNyFpAb0KN2
[Bug c++/61953] New: [C++11] The template parameter pack of a function template should be the last template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61953
Bug ID: 61953
Summary: [C++11] The template parameter pack of a function
template should be the last template parameter
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
The both sample codes below should cause compilation error but they are
compiled successfully by gcc.
==
templateclass... T, class... U void f() { }
==
===
templateclass... T, class U void g() { }
===
According to C++11 standard 14.1 Template parameters [temp.param] paragraph 11,
A template parameter pack of a function template shall not be followed by
another template parameter unless that template parameter can be deduced from
the parameter-type-list of the function template or has a default argument.
The latest draft is more clarified using the following example.
===
// U can be neither deduced from the parameter-type-list nor specified
templateclass... T, class... U void f() { } // error
templateclass... T, class U void g() { } // error
===
cf. http://melpon.org/wandbox/permlink/zO14UQDvxpXwRfYm
[Bug libstdc++/61791] New: [C++11] [constexpr] Additional overloads of std::real should be a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61791
Bug ID: 61791
Summary: [C++11] [constexpr] Additional overloads of std::real
should be a constexpr function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
I think that the sample code below should be compiled successfully.
===
#include complex
static constexpr double d = std::real(10);
int main() {}
===
Note that it is compiled successfully if the argument is
std::complexdouble(10) instead of 10.
According to C++11 standard 26.4.9[cmplx.over] paragraph 2, if either argument
has type complexdouble, double, or an integer type, then both arguments are
effectively cast to complexdouble.
Therefore, I think it should be compiled successfully too.
[Bug libstdc++/61791] [C++11] [constexpr] Additional overloads of std::real should be a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61791 --- Comment #1 from Mitsuru Kariya kariya_mitsuru at hotmail dot com --- Sorry, the text which should be quoted was mistaken. According to C++11 standard 26.4.9[cmplx.over] paragraph 2, if either argument has type complexdouble, double, or an integer type, then both arguments are effectively cast to complexdouble. According to C++11 standard 26.4.9[cmplx.over] paragraph 2, if the argument has type double or an integer type, then it is effectively cast to complexdouble.
[Bug libstdc++/61795] New: [C++11] return type of std::pow(std::complexfloat, int) should be std::complexdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61795
Bug ID: 61795
Summary: [C++11] return type of std::pow(std::complexfloat,
int) should be std::complexdouble
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
With libstdc++, the return type of std::pow(std::complexfloat, int) is
std::complexfloat.
However, In C++11 mode, the return type of std::pow(std::complexfloat, int)
should be std::complexdouble.
According to C++11 standard 26.4.9[cmplx.over] paragraph 3, if either argument
has type complexdouble, double, or an integer type, then both arguments are
effectively cast to complexdouble.
The return type of std::pow(std::complexdouble, std::complexdouble) is
std::complexdouble, So I think that std::pow(std::complexfloat, int) should
be std::complexdouble in C++11 mode.
The sample code below can show whether the return type is std::complexdouble.
#include iostream
#include typeinfo
#include complex
int main()
{
std::cout std::boolalpha
(typeid(std::pow(std::complexfloat(1), 1)) ==
typeid(std::complexdouble))
std::endl;
}
cf. http://melpon.org/wandbox/permlink/zW8TWZe9kKzKWqFq
While in C++03 mode, the return type of std::pow(std::complexfloat, int)
should be std::complexfloat, I think.
Note that this problem does not occur in std::complexdouble and
std::complexlong double because there is no difference between C++03 and
C++11.
See also: PR56106, PR57974
[Bug libstdc++/61795] [C++11] return type of std::pow(std::complexfloat, int) should be std::complexdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61795
--- Comment #2 from Mitsuru Kariya kariya_mitsuru at hotmail dot com ---
I think that this behaviour is caused by r201253 (for PR57974, Comment 11).
DR844 was fixed by r136694 but reverted by r201253.
diff r135878 r136694
https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/std/complex?r1=135878r2=136694
diff r199924 r201253
https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/std/complex?r1=199924r2=201253
Moreover, I think that I mistook.
Note that this problem does not occur in std::complexdouble and
std::complexlong double because there is no difference between
C++03 and C++11.
This is not true.
In C++03, the 2nd argument of std::pow can cause implicit conversions.
(Because it is the trivial int type.)
However, I believe that it should cause no implicit conversion in C++11.
(I think so from C++11 standard text quoted above.)
Therefore, I think that the sample code below should be compiled successfully
in C++03 mode but should cause compilation error in C++11 mode.
===
#include complex
struct S {
operator int() { return 1; }
};
int main()
{
std::complexdouble d = std::pow(std::complexdouble(0), S());
}
===
[Bug libstdc++/61761] New: [C++11] std::proj returns incorrect values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61761
Bug ID: 61761
Summary: [C++11] std::proj returns incorrect values
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
std::proj returns incorrect values if _GLIBCXX_USE_C99_COMPLEX is not defined.
For example, std::proj(std::complexdouble(1, 2)) should be
std::complexdouble(1, 2) but libstdc++ returns
std::complexdouble(0.33,0.67).
If _GLIBCXX_USE_C99_COMPLEX is defined, the sample code below can show the
difference between a glibc version and a libstdc++ version.
sample source
#include iostream
#include complex
#include climits
void check(const std::complexdouble c)
{
// libstdc++ version
std::complexdouble r1 = std::__complex_proj(c);
std::cout libstdc++ version : proj( c ) = r1 std::endl;
// glibc version
std::complexdouble r2 = std::__complex_proj(c.__rep());
std::cout glibc version : proj( c ) = r2 std::endl;
}
int main()
{
check(std::complexdouble(1, 2));
check(std::complexdouble(1, NAN));
}
sample output
libstdc++ version : proj( (1,2) ) = (0.33,0.67)
glibc version : proj( (1,2) ) = (1,2)
libstdc++ version : proj( (1,nan) ) = (nan,nan)
glibc version : proj( (1,nan) ) = (1,nan)
===
According to C99 standard 7.3.9.4 (referenced from C++11 standard 26.4.7
[complex.value.ops] paragraph 8), z projects to z except that all complex
infinities (even those with one infinite part and one NaN part) project to
positive infinity on the real axis.
Note that the glibc version 2.11 or below had the same bug.
(For std::complexdouble(1, NAN), the glibc version 2.18 or below had a
different bug.)
[Bug c++/60842] New: In-class initializer causes a strange error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60842
Bug ID: 60842
Summary: In-class initializer causes a strange error
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
The sample code below causes a strange error.
=== source code ===
namespace N {
class I {};
}
template typename, typename
class J {};
class S {
Jint, N::I j = Jint, N::I{};
};
int main() {}
=== source code ===
== error messages ==
prog.cc:9:32: error: invalid use of '::'
Jint, N::I j = Jint, N::I{};
^
prog.cc:9:32: error: expected ';' at end of member declaration
prog.cc:9:33: error: expected unqualified-id before '' token
Jint, N::I j = Jint, N::I{};
^
prog.cc:9:24: error: wrong number of template arguments (1, should be 2)
Jint, N::I j = Jint, N::I{};
^
prog.cc:6:7: error: provided for 'templateclass, class class J'
class J {};
^
== error messages ==
I think that the sample code should be compiled successfully.
cf. http://melpon.org/wandbox/permlink/h96WGv3EW3DOyHnB
[Bug libstdc++/60594] std::function of a type with a declared (but not defined) return type fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60594
Mitsuru Kariya kariya_mitsuru at hotmail dot com changed:
What|Removed |Added
CC||kariya_mitsuru at hotmail dot
com
--- Comment #5 from Mitsuru Kariya kariya_mitsuru at hotmail dot com ---
FYI, the BUG2 above is compiled successfully by gcc 4.7.3.
cf. http://melpon.org/wandbox/permlink/UZdP4fovs2ATM2iZ
Additionally, the sample code below cannot be compiled by gcc HEAD.
#include functional
struct S {
std::functionS() f;
};
int main()
{
S l{ []{ return S{nullptr}; } };
}
cf. http://melpon.org/wandbox/permlink/HAZ7i5JE94KSQhM7
It is also compiled successfully by gcc 4.7.3.
And I think that struct S is not incomplete type (at least, at the point where
it is used).
[Bug c++/60209] New: Declaration of user-defined literal operator cause error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60209 Bug ID: 60209 Summary: Declaration of user-defined literal operator cause error Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kariya_mitsuru at hotmail dot com I think that the sample code below should be compiled successfully. void operator _x(unsigned long long); According to C++11 standard 2.2[lex.phases], string literal concatenation occurs in compilation phase 6 and syntax analysis is performed in compilation phase 7.
[Bug c++/59921] New: Variable names should be ignored when qualified name lookup is applied to nested name specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59921
Bug ID: 59921
Summary: Variable names should be ignored when qualified name
lookup is applied to nested name specifier
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
The sample code below should be compiled successfully but g++ reports an error.
int A = 1;
enum A {
x = 2,
};
int main()
{
return A::x;
}
According to C++11 standard 3.4.3 [basic.lookup.qual] paragraph 1, The variable
name A should be ignored.
gcc versions and error messages:
http://melpon.org/wandbox/permlink/tPZK53MNWXsmfw2x
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #15 from Mitsuru Kariya kariya_mitsuru at hotmail dot com --- Created attachment 30775 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30775action=edit Patch For your convenience, I attached a patch for this problem. This algorithm is always scanned to reverse order. If a scan fails in less than enough, a re-scan is performed from the point that advanced necessary elements from the original starting point. For example, if __count is 20 and a scan fails after 18 elements succeeded, a re-scan is performed from the point that advanced 2 elements.
[Bug libstdc++/58358] New: search_n has a Complexxity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358
Bug ID: 58358
Summary: search_n has a Complexxity violation for random access
iterator
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Following code should print less than or equal to 11, but it prints 20.
#include algorithm
#include vector
#include iostream
int main()
{
std::vectorint a{2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1};
int count = 0;
std::search_n(a.begin(), a.end(), 10, 1, [count](int t, int u){ ++count;
return t == u; });
std::cout count std::endl;
}
