[Bug c++/57825] New: Template specialization for ref qualified member pointers

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tomaszkam at gmail dot com Created attachment 30460 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30460action=edit Bugus code exmaple The class template specialization for member pointers

[Bug c++/57825] Template specialization for ref qualified member pointers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825 --- Comment #2 from Tomasz Kamiński tomaszkam at gmail dot com --- Propably this is also causing the problem with the standard library is_function and is_member function traits, because they cannot be implemented correclty. Example: struct

[Bug c++/57825] Template specialization for ref qualified member pointers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825 --- Comment #7 from Tomasz Kamiński tomaszkam at gmail dot com --- No, this was a different problem and it became fixed. Your example code works fine gcc 4.9.0 20130616 (experimental) (I do know this, because I recently completed

[Bug c++/63999] New: Explcit conversion operators are not considered for explicit cast using brace

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tomaszkam at gmail dot com For the following code: struct bool_convert { explicit operator bool() { return true; } }; bool x(bool_convert());//1 bool x1{bool_convert

[Bug libstdc++/66998] New: not_fn invocation is not SFINAE friendly

++ Assignee: unassigned at gcc dot gnu.org Reporter: tomaszkam at gmail dot com Target Milestone: --- According to the http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4529.html#func.not_fn the following invocations not_fn(f)(args...) and !INVOKE(f, args...) (in case

[Bug libstdc++/66998] not_fn invocation is not SFINAE friendly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66998 --- Comment #2 from Tomasz Kamiński tomaszkam at gmail dot com --- Sorry for missing using declaration. It's certainly a nice QoI improvement. I was basically lazy when I implemented it and used decltype(auto) because it's convenient. Yes

[Bug c++/71886] New: Incorrect error on operator() being an member in template

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tomaszkam at gmail dot com Target Milestone: --- Following class correctly compiles without any error in GCC 5.1.0: struct NonTemplate { typedef void type(); type operator

[Bug c++/71886] Incorrect error on operator() being an member in template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71886 --- Comment #1 from Tomasz Kamiński --- Such code is useful, for example in case of variant universal constructor from U&&, where there is a need to determine best candidate among the function taking parameter each type be value.

[Bug libstdc++/77727] New: Unwrapping std::optional constructor is not working for non-transferable object

: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: tomaszkam at gmail dot com Target Milestone: --- The following code does not compile: #include struct NonTransferable { NonTransferable(int

[Bug c++/78420] std::less<T*> is not a total order with -O2 enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 --- Comment #4 from Tomasz Kamiński --- Oh, you mean that compiler is not allowed to turn comparison of p == b into false at compile time, using 5.10 [expr.eq] p2.1? Some reference from clang: https://llvm.org/bugs/show_bug.cgi?id=13507. Note

[Bug c++/78420] std::less<T*> is not a total order with -O2 enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 --- Comment #7 from Tomasz Kamiński --- > No, it's very much allowed to do that. But I'm skeptical that it's allowed > to turn !(a(b,a) being false, when std::less{}(a,b) and

[Bug c++/78420] std::less<T*> is not a total order with -O2 enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 --- Comment #3 from Tomasz Kamiński --- > I don't see this as prohibiting the transformation. The standard seems to be > saying that they might or might not compare as equal, which presumably > depends on how variables are laid out in memory.

[Bug c++/78420] New: std::less<T*> is not an total order with optimization enabled

normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tomaszkam at gmail dot com Target Milestone: --- The 20.14.6 [comparisons] p14: For templates greater, less, greater_equal, and less_equal, the specializations for any pointer type

[Bug c++/78420] std::less<T*> is not an total order with optimization enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 --- Comment #1 from Tomasz Kamiński --- This is probably effect on changing !lt(a,b) && !lt(b, a) into !(a

[Bug c++/77976] `auto x = type{…}` initialization syntax rejects `explicit` user-defined conversion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77976 Tomasz Kamiński changed: What|Removed |Added CC||tomaszkam at gmail dot com

[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66139 --- Comment #2 from Tomasz Kamiński --- Example of some real life safe-code (now raw allocations, STL container used), that is leaking: #include #include #include using namespace std; struct Test { string a; string b; }; Test