[Bug middle-end/52939] [4.7/4.8 Regression] ice in gimple_get_virt_method_for_binfo with -O3

2012-08-22 Thread blelbach at cct dot lsu.edu
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

2011-02-06 Thread blelbach at cct dot lsu.edu
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

2011-02-06 Thread blelbach at cct dot lsu.edu
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

2011-02-07 Thread blelbach at cct dot lsu.edu
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

2011-09-14 Thread blelbach at cct dot lsu.edu
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

2011-09-19 Thread blelbach at cct dot lsu.edu
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

2011-10-04 Thread blelbach at cct dot lsu.edu
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

2012-05-21 Thread blelbach at cct dot lsu.edu
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

2012-05-21 Thread blelbach at cct dot lsu.edu
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

2012-05-21 Thread blelbach at cct dot lsu.edu
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

2012-05-21 Thread blelbach at cct dot lsu.edu
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

2012-05-22 Thread blelbach at cct dot lsu.edu
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

2012-05-22 Thread blelbach at cct dot lsu.edu
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

2012-07-02 Thread blelbach at cct dot lsu.edu
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

2012-07-02 Thread blelbach at cct dot lsu.edu
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

2019-08-28 Thread blelbach at cct dot lsu.edu
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

2018-10-05 Thread blelbach at cct dot lsu.edu
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;