[Bug middle-end/52939] [4.7/4.8 Regression] ice in gimple_get_virt_method_for_binfo with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52939 Bryce Lelbach (wash) changed: What|Removed |Added CC||blelbach at cct dot lsu.edu --- Comment #9 from Bryce Lelbach (wash) 2012-08-22 23:52:55 UTC --- Is the fix for this in a released version of GCC?
[Bug libstdc++/47628] New: non-compliant C++0x erase methods on STL containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47628 Summary: non-compliant C++0x erase methods on STL containers Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: blelb...@cct.lsu.edu Apologizes if this has changed in the draft standard (my copy of n3092 indicates it hasn't): As of r169874, std::set<>, std::map<>, std::multiset<>, std::multimap<>, std::unordered_set<>, std::unordered_map<>, std::unordered_multiset<> and std::unordered_multimap<> have C++0x erase methods; instead of taking an `iterator' (or a range of `iterators' for some of the aforementioned containers), the GNU implementation of these containers accept a `const_iterator'. In ISO/IEC N3092, the specification of the erase() method is in [associative.reqmts] (Section 23.2.4) table 99 and [unord.req] (Section 23.2.5) table 100. I do not believe this problem affects the library in C++03/C++99 mode, as a preprocessor macro selects the old C++99/C++03 version of erase(). This is problematic in particular for std::map<>, where it can cause a call to erase() to be ambigious. I noticed this problem when compiling the Boost.Signals library (I'm a Boost developer) with a freshly built GCC 4.6.0. Please find attached a patch against trunk that fixes this problem.
[Bug libstdc++/47628] non-compliant C++0x erase methods on STL containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47628 --- Comment #1 from Bryce Lelbach (wash) 2011-02-07 01:00:28 UTC --- Created attachment 23262 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23262 Fix for STL erase() methods on associative containers
[Bug libstdc++/47628] non-compliant C++0x erase methods on STL containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47628 --- Comment #5 from Bryce Lelbach (wash) 2011-02-07 14:20:09 UTC --- Sorry! Wasn't aware this was correct.
[Bug c++/50399] New: [c++11] Lookup error w/ enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50399 Bug #: 50399 Summary: [c++11] Lookup error w/ enums Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: blelb...@cct.lsu.edu $ cat cxx11_enum_lookup_bug.cpp namespace A { namespace B { void F() { } } namespace C { enum B { }; void G() { B::F(); } } } $ /usr/lib/gcc-snapshot/bin/g++ --version g++ (Debian 20110816-1) 4.7.0 20110816 (experimental) [trunk revision 177785] Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ /usr/lib/gcc-snapshot/bin/g++ cxx11_enum_lookup_bug.cpp -c $ /usr/lib/gcc-snapshot/bin/g++ cxx11_enum_lookup_bug.cpp -c -std=c++0x cxx11_enum_lookup_bug.cpp: In function 'void A::C::G()': cxx11_enum_lookup_bug.cpp:13:12: error: 'F' is not a member of 'A::C::B' $ g++-4.6 --version g++-4.6 (Debian 4.6.1-8) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++-4.6 cxx11_enum_lookup_bug.cpp -c $ g++-4.6 cxx11_enum_lookup_bug.cpp -c -std=c++0x cxx11_enum_lookup_bug.cpp: In function ‘void A::C::G()’: cxx11_enum_lookup_bug.cpp:13:12: error: ‘F’ is not a member of ‘A::C::B’ $ g++-4.5 --version g++-4.5 (Debian 4.5.3-8) 4.5.3 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++-4.5 cxx11_enum_lookup_bug.cpp -c $ g++-4.5 cxx11_enum_lookup_bug.cpp -c -std=c++0x cxx11_enum_lookup_bug.cpp: In function ‘void A::C::G()’: cxx11_enum_lookup_bug.cpp:13:12: error: ‘F’ is not a member of ‘A::C::B’ $ g++-4.4 --version g++-4.4 (Debian 4.4.6-8) 4.4.6 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++-4.4 cxx11_enum_lookup_bug.cpp -c $ g++-4.4 cxx11_enum_lookup_bug.cpp -c -std=c++0x cxx11_enum_lookup_bug.cpp: In function ‘void A::C::G()’: cxx11_enum_lookup_bug.cpp:13: error: ‘F’ is not a member of ‘A::C::B’
[Bug libstdc++/49561] [C++0x] std::list::size complexity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 Bryce Lelbach (wash) changed: What|Removed |Added CC||blelbach at cct dot lsu.edu --- Comment #2 from Bryce Lelbach (wash) 2011-09-20 00:15:40 UTC --- (In reply to comment #1) > (In reply to comment #0) > > I realized that the complexity of std::list::size() is O(n), not O(1). > > > > This does not conform to standard. The standard states that size() function > > is > > in constant time for alls containers. > > No, the current standard does not. > > The C++0x draft does, but it's not yet a standard, and parts of it are not yet > implemented. The current standard is now C++11. 23.2.1, Table 96 explicitly states that the size() method of Containers must execute in constant time. Can this bug please be changed to confirmed? As of today (r178989), std::list<>::size() is still O(N).
[Bug libstdc++/49561] [C++0x] std::list::size complexity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 --- Comment #7 from Bryce Lelbach (wash) 2011-10-04 23:06:01 UTC --- Thanks - I'll give it a whirl!
[Bug c++/53446] New: Template function incorrectly rejected when convertible argument is provided for a parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53446 Bug #: 53446 Summary: Template function incorrectly rejected when convertible argument is provided for a parameter Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: blelb...@cct.lsu.edu Created attachment 27471 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27471 Failing test case (Thanks to rjmccall on #llvm for explaining the details of why this is a bug) In the attached code snippet, the second parameter of f<>(), B<>, is a non-deduced context, but the first argument D<> permits the deduction of T=int. That substitution should succeed, and then the second argument is convertible. The candidate can't be rejected just because B can't be matched with A.
[Bug c++/53446] Template function incorrectly rejected when convertible argument is provided for a parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53446 --- Comment #1 from Bryce Lelbach (wash) 2012-05-22 05:14:12 UTC --- Created attachment 27472 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27472 Results of compiling the test case
[Bug c++/53446] Template function incorrectly rejected when convertible argument is provided for a parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53446 --- Comment #2 from Bryce Lelbach (wash) 2012-05-22 05:15:36 UTC --- Comment on attachment 27472 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27472 Results of compiling the test case $ g++-4.5 --version g++-4.5 (Debian 4.5.3-12) 4.5.3 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++-4.5 incorrect_rejection_of_convertible_argument.cpp -o incorrect_rejection_of_convertible_argument incorrect_rejection_of_convertible_argument.cpp: In function ‘int main()’: incorrect_rejection_of_convertible_argument.cpp:18:11: error: no matching function for call to ‘f(D&, A&)’ $ $ g++-4.6 --version g++-4.6 (Debian 4.6.3-5) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++-4.6 incorrect_rejection_of_convertible_argument.cpp -o incorrect_rejection_of_convertible_argument incorrect_rejection_of_convertible_argument.cpp: In function ‘int main()’: incorrect_rejection_of_convertible_argument.cpp:18:11: error: no matching function for call to ‘f(D&, A&)’ incorrect_rejection_of_convertible_argument.cpp:18:11: note: candidate is: incorrect_rejection_of_convertible_argument.cpp:10:6: note: template void f(D, B::type>) $ $ g++-4.7 --version g++-4.7 (Debian 4.7.0-8) 4.7.0 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++-4.7 incorrect_rejection_of_convertible_argument.cpp -o incorrect_rejection_of_convertible_argument incorrect_rejection_of_convertible_argument.cpp: In function ‘int main()’: incorrect_rejection_of_convertible_argument.cpp:18:11: error: no matching function for call to ‘f(D&, A&)’ incorrect_rejection_of_convertible_argument.cpp:18:11: note: candidate is: incorrect_rejection_of_convertible_argument.cpp:10:6: note: template void f(D, B::type>) incorrect_rejection_of_convertible_argument.cpp:10:6: note: template argument deduction/substitution failed: incorrect_rejection_of_convertible_argument.cpp:18:11: note: ‘A’ is not derived from ‘B::type>’ $ $ clang++ --version Debian clang version 3.1-1 (tags/RELEASE_31/rc1) (based on LLVM 3.1) Target: x86_64-pc-linux-gnu Thread model: posix $ clang++ incorrect_rejection_of_convertible_argument.cpp -o incorrect_rejection_of_convertible_argument $
[Bug c++/53446] Template function incorrectly rejected when convertible argument is provided for a parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53446 --- Comment #3 from Bryce Lelbach (wash) 2012-05-22 05:17:03 UTC --- Created attachment 27473 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27473 Results of compiling the test case
[Bug c++/53446] Template function incorrectly rejected when convertible argument is provided for a parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53446 Bryce Lelbach (wash) changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #7 from Bryce Lelbach (wash) 2012-05-22 18:36:11 UTC --- Yes, this is a duplicate of 52072. *** This bug has been marked as a duplicate of bug 52072 ***
[Bug c++/52072] Several non-deduced contexts not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52072 Bryce Lelbach (wash) changed: What|Removed |Added CC||blelbach at cct dot lsu.edu --- Comment #2 from Bryce Lelbach (wash) 2012-05-22 18:36:11 UTC --- *** Bug 53446 has been marked as a duplicate of this bug. ***
[Bug libstdc++/49561] [C++0x] std::list::size complexity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 --- Comment #14 from Bryce Lelbach (wash) 2012-07-03 03:35:31 UTC --- (In reply to comment #13) > Patch reverted, thus in C++11 mode size() is back to O(n) but std::list can > interoperate with the C++98 version of it. Why has this been reverted? If std::list<>::size() is not O(1), then GCC's C++11 standard library is not compliant with the C++11 international standard. I have personally spoken with multiple members of the standard body and confirmed that this behavior is REQUIRED by the C++11 standard. Please re-apply this patch for C++11 mode, or state somewhere in the GCC docs that GCC is not compliant with the C++11 standard. In the C++03 and C++98 standards, it was highly suggested that compiler vendors implement std::list<>::size() as O(1). I understand this is a breaking change, but honestly, the C++ standard has been suggesting the O(1) implementation for over a decade, and the GCC standard library developers have chosen to implement different behavior. You've had many years of warning about this. (In reply to comment #10) > I can confirm it was just luck, really. ^ Paolo, this is correct. I think it's a really, really bad idea for any particular vendor to cherrypick elements of an ISO standard to implement. If you feel that the C++11 standard is wrong to require an O(1) implementation, please file a standard defect (I'm afraid you can expect me to fight it). Otherwise, I'd like to ask that you please reconsider applying this patch.
[Bug libstdc++/49561] [C++0x] std::list::size complexity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 --- Comment #15 from Bryce Lelbach (wash) 2012-07-03 03:38:52 UTC --- Also, didn't this already make it into the 4.7 release? Wouldn't reverting it now just cause incompatibilities with 4.7 and both older and newer releases?
[Bug c++/91592] New: `__is_assignable` fails for private assignment operators in certain contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91592 Bug ID: 91592 Summary: `__is_assignable` fails for private assignment operators in certain contexts Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: blelbach at cct dot lsu.edu Target Milestone: --- This code fails with GCC 8.2 and GCC trunk. https://godbolt.org/z/IljfIw ``` class B { B& operator=(const B&); }; static_assert(!__is_assignable(B&, B const&), ""); // Ok. void foo() { static_assert(!__is_assignable(B&, B const&), ""); // FAIL. } ``` MSVC, Clang and EDG all accept this code.
[Bug c++/87536] New: Illegal recursive concept leads to compiler ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87536 Bug ID: 87536 Summary: Illegal recursive concept leads to compiler ICE Product: gcc Version: c++-concepts Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: blelbach at cct dot lsu.edu Target Milestone: --- GCC concepts seem to allow the use of the name of a concept in the definition of the concept itself. This appears to allow me to trick GCC into infinitely recursing and blowing up with an ICE: https://godbolt.org/z/p8Yuo0 A repro is as follows: template bool concept X = X; template struct A{}; A a;