[Bug libstdc++/80564] bind on SFINAE unfriendly generic lambda

2017-05-04 Thread r.hl at gmx dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80564

--- Comment #5 from r.hl at gmx dot net ---
See also the discussion on Phabricator: https://reviews.llvm.org/D32824

I agree; AFAICS [func.bind.bind] is clear on this: the type of the Func
object used to call the member operator() is non-const.

On 5/4/2017 9:09 PM, rs2740 at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80564
>
> TC  changed:
>
>What|Removed |Added
> 
>  CC||rs2740 at gmail dot com
>
> --- Comment #4 from TC  ---
> (In reply to Eric Fiselier from comment #3)
>> Here is an example of why `_Bind::operator()(...) const` must be considered
>> during overload resolution even if the call wrapper itself is not const.
>>
>> --
>> #include 
>>
>> struct Func {
>>   template 
>>   void operator()(Args&&...) = delete;
>>
>>   template 
>>   void operator()(Args&&...) const {}
>> };
>>
>> int main() {
>> Func f;
>> std::bind(f)();
>> }
>> -
> Interesting, libstdc++ rejects this as an attempt to call a deleted function.
> That seems more correct than libc++'s approach which calls the const overload.
>

[Bug c++/60705] New: alias template member access ignored

2014-03-29 Thread R.HL at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60705

Bug ID: 60705
   Summary: alias template member access ignored
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: R.HL at gmx dot net

GCC simply ignores the fact, that a private member is inaccessible:

class A
{
struct B {};
};

template
using C = A::B; // Already the declaration of this alias template is ill-formed

int main()
{
C c1;
C c2;
}

This compiles without any warnings/errors using the GCC-4.9 snapshot from the
2nd march, and is obviously ill-formed (because access control applies to all
names in all declarations,  ยง11/4).
There is AFAICS no exception for alias templates.

[Bug c++/60705] ill-formed member access in alias template ignored

2014-03-30 Thread R.HL at gmx dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60705

--- Comment #2 from Robert Haberlach  ---
In this case the nested-name-specifier is not dependent upon any template
argument. Thank you for the link, i didn't know that report yet.


[Bug c++/64428] New: aggregate with const member as union member [C++03]

2014-12-28 Thread R.HL at gmx dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64428

Bug ID: 64428
   Summary: aggregate with const member as union member [C++03]
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: R.HL at gmx dot net

struct A
{
const int b;
};

union U
{
A a;
};

int main()
{
U a = {1, 1};
}

Fails to compile using -std=c++03, although it should. Consider that no special
member function apart from the destructor is implicitly defined, and the
trivialty of them is preserved.


[Bug c++/64428] aggregate with const member as union member [C++03]

2014-12-28 Thread R.HL at gmx dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64428

--- Comment #2 from R.HL at gmx dot net ---
That was a typo, I quickly modified the example before submitting it. It should
be

U u = {1};


[Bug c++/63757] New: nullptr conversion sequence fails to compile

2014-11-05 Thread R.HL at gmx dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63757

Bug ID: 63757
   Summary: nullptr conversion sequence fails to compile
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: R.HL at gmx dot net

This code

#include 

void bar(void*) {}

struct foo
{
operator std::nullptr_t()
{
return nullptr;
}
};

int main()
{
bar(foo());
}

Does not compile with GCC 4.9.1 (neither -std=c++11 nor =c++14). However, it
should; There is one user defined conversion sequence inherent, consisting of
one standard conversion sequence converting nullptr to nullptr_t (which is a
pointer conversion, specifically a null pointer conversion), one user defined
conversion through the conversion operator function and a second standard
conversion sequence converting nullptr_t to void* (Which is also a pointer
conversion).


[Bug c++/63985] New: Accepts invalid range-based for declaration

2014-11-19 Thread R.HL at gmx dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63985

Bug ID: 63985
   Summary: Accepts invalid range-based for declaration
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: R.HL at gmx dot net

int arr[] {1, 2, 3};
for (int i = 5: arr)
std::cout << i << ", ";

Compiles, while it shouldn't. A warning message suggests that GCC ignores the
loop completely.

warning: variable 'arr' set but not used

Perhaps GCC can't decide what kind of loop this is and decides to ignore it
silently?