[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&view=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 --- 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=35627&action=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 #15 from Mitsuru Kariya --- 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 changed: What|Removed |Added Summary|GCC rejects valid constant |[C++11] GCC rejects valid |expression |constant expression --- Comment #1 from Mitsuru Kariya --- 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++/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 #13 from Mitsuru Kariya --- 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++/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 --- Oh, thanks a lot! I've got it. (And I've understood the reason why clang rejects it ;).)
[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 --- I also found a strange behavior like below. == sample code == #include 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_cast(&s1[sizeof(s1)]) << std::endl; std::cout << static_cast(&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++/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 changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #15 from Mitsuru Kariya --- 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 --- 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=35143&action=edit g++ -v The sample code below should be compiled and linked successfully but it causes a linkage error. == sample code == template 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/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 changed: What|Removed |Added CC||kariya_mitsuru at hotmail dot com --- Comment #9 from Mitsuru Kariya --- (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=35091&action=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=35017&action=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] [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 --- Created attachment 34985 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34985&action=edit g++ -v
[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 #include 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++/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=34934&action=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*, vec**, 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=34930&action=edit g++ -v Please see the sample code below. == sample code == #include #include 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=34645&action=edit g++ -v Please see the sample code below. = sample code = #include #include 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=34491&action=edit g++ -v The sample code below should not throw a regex_error. = sample code = #include 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=34437&action=edit g++ -v Please see the following sample. === sample code === #include #include 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=34436&action=edit g++ -v Please see the following sample. === sample code === #include #include 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 --- When I used the match_results::swap on r218710, I got a compilation error. == sample code == #include 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< , >::swap(std::match_results< , >&) [with _Bi_iter = const char*; _Alloc = std::allocator >]': 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_results::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< , >::swap(std::match_results< , >&) [with _Bi_iter = const char*; _Alloc = std::allocator >] 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 --- The rev.219121 seems to satisfy the sample code above, but does not satisfy another sample code like below. == sample code == #include #include 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=34362&action=edit g++ -v Please see the following sample. == sample code == #include #include 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++/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=34278&action=edit g++ -v Please see the following sample. == sample code == #include #include #include 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++/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=34277&action=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 #include #include 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++/64239] regex_iterator::operator= should copy match_results::position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64239 --- Comment #3 from Mitsuru Kariya --- 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=34231&action=edit g++ -v Please see the following sample. == sample code == #include #include #include 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=34156&action=edit g++ -v Please see the following sample. == sample code == #include #include #include 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=34049&action=edit g++ -v The sample code below is aborted with "attempt to increment a past-the-end iterator". = #include #include 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 --- 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=34005&action=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 #include 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=33815&action=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++/57610] Reference initialized with temporary instead of sub-object of conversion result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 Mitsuru Kariya changed: What|Removed |Added CC||kariya_mitsuru at hotmail dot com --- Comment #10 from Mitsuru Kariya --- 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++/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++/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. == template void f() { } == === template 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 template void f() { } // error template void g() { } // error === cf. http://melpon.org/wandbox/permlink/zO14UQDvxpXwRfYm
[Bug libstdc++/61795] [C++11] return type of std::pow(std::complex, int) should be std::complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61795 --- Comment #2 from Mitsuru Kariya --- 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=135878&r2=136694 diff r199924 r201253 https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/std/complex?r1=199924&r2=201253 Moreover, I think that I mistook. > Note that this problem does not occur in std::complex and > std::complex 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 struct S { operator int() { return 1; } }; int main() { std::complex d = std::pow(std::complex(0), S()); } ===
[Bug libstdc++/61795] New: [C++11] return type of std::pow(std::complex, int) should be std::complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61795 Bug ID: 61795 Summary: [C++11] return type of std::pow(std::complex, int) should be std::complex 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::complex, int) is std::complex. However, In C++11 mode, the return type of std::pow(std::complex, int) should be std::complex. According to C++11 standard 26.4.9[cmplx.over] paragraph 3, "if either argument has type complex, double, or an integer type, then both arguments are effectively cast to complex." The return type of std::pow(std::complex, std::complex) is std::complex, So I think that std::pow(std::complex, int) should be std::complex in C++11 mode. The sample code below can show whether the return type is std::complex. #include #include #include int main() { std::cout << std::boolalpha << (typeid(std::pow(std::complex(1), 1)) == typeid(std::complex)) << std::endl; } cf. http://melpon.org/wandbox/permlink/zW8TWZe9kKzKWqFq While in C++03 mode, the return type of std::pow(std::complex, int) should be std::complex, I think. Note that this problem does not occur in std::complex and std::complex because there is no difference between C++03 and C++11. See also: PR56106, PR57974
[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 --- 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 complex, double, or an integer type, then both > arguments are effectively cast to complex." 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 complex."
[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 static constexpr double d = std::real(10); int main() {} === Note that it is compiled successfully if the argument is std::complex(10) instead of 10. According to C++11 standard 26.4.9[cmplx.over] paragraph 2, "if either argument has type complex, double, or an integer type, then both arguments are effectively cast to complex." Therefore, I think it should be compiled successfully too.
[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::complex(1, 2)) should be std::complex(1, 2) but libstdc++ returns std::complex(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 #include #include void check(const std::complex& c) { // libstdc++ version std::complex r1 = std::__complex_proj(c); std::cout << "libstdc++ version : proj( " << c << " ) = " << r1 << std::endl; // glibc version std::complex r2 = std::__complex_proj(c.__rep()); std::cout << "glibc version : proj( " << c << " ) = " << r2 << std::endl; } int main() { check(std::complex(1, 2)); check(std::complex(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::complex(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 class J {}; class S { J j = J{}; }; int main() {} === source code === == error messages == prog.cc:9:32: error: invalid use of '::' J j = J{}; ^ prog.cc:9:32: error: expected ';' at end of member declaration prog.cc:9:33: error: expected unqualified-id before '>' token J j = J{}; ^ prog.cc:9:24: error: wrong number of template arguments (1, should be 2) J j = J{}; ^ prog.cc:6:7: error: provided for 'template 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 changed: What|Removed |Added CC||kariya_mitsuru at hotmail dot com --- Comment #5 from Mitsuru Kariya --- 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 struct S { std::function 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 --- Created attachment 30775 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30775&action=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 #include #include int main() { std::vector 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; }