https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62172
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Test:
struct X
{
friend void f(X, int) = delete;
friend void f(X, double) {}
};
struct Y;
void g(Y, int);
void g(Y, double);
struct Y
{
friend void g(Y, int) = delete
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
First test:
#include iostream
#ifdef OK
struct ostream { } cout;
bool operator(ostream, const char* s)
{ __builtin_printf(%s, s); return true; }
#else
using std::cout;
#endif
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
struct A {
A(int val){}
};
int main()
{
A a{ [x=123]{ return x; }() };
}
init-capture2.cpp: In function ‘int main()’:
init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
--- Comment #6 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Jonathan Wakely from comment #5)
Seems to be fixed on trunk, probably by Ville's fix for protected members.
Yes, that fix is for 59483, I didn't wish
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
#include iostream
template class D struct Base
{
enum class E : unsigned;
E e;
Base(E e) : e(e) {}
};
struct X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61491
--- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com ---
This is part of DR1206:
http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#1206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59483
--- Comment #3 from Ville Voutilainen ville.voutilainen at gmail dot com ---
So, correction, the original testcase in 58972 is fixed by this patch, but the
other testcase in it ICEs the compiler. That testcase is not really related to
the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59483
--- Comment #2 from Ville Voutilainen ville.voutilainen at gmail dot com ---
It seems that 58972 is a duplicate, and is fixed by the same patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
--- Comment #3 from Ville Voutilainen ville.voutilainen at gmail dot com ---
[ville@localhost ~]$ g++ --std=c++11 -c dan.cpp
dan.cpp: In instantiation of ‘struct deriveT::foo(base::type) [with T = char;
base::type = int]::f_t’:
dan.cpp:18:5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61133
--- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Patch is in https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00656.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58753
--- Comment #11 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Paolo Carlini from comment #10)
Looks somewhat similar, but not identical. In this particular
bug it doesn't seem to be a case of explicitness being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58753
--- Comment #13 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Paolo Carlini from comment #12)
Ah, indeed, comment 2 has an explicit diagnostic as well. The patch
looks reasonable (to my taste the condition doesn't
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Testcase:
int main()
{
auto x = [y = 5](){};
auto z = x.y;
}
The member should not be usable. The most recent WP says
An init-capture behaves as if it declares and explicitly captures a variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51501
--- Comment #10 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Jason Merrill from comment #9)
Ville, has EWG taken a look at this issue? I'm sorry this didn't come up in
Not yet. The handling of Extension-status Core
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51424
--- Comment #8 from Ville Voutilainen ville.voutilainen at gmail dot com ---
My 2 cents is to open a separate bug if we want diagnostics for the more
elaborate self-delegating cases.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51424
--- Comment #5 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Jakub Jelinek from comment #4)
GCC 4.9.0 has been released
Well, shouldn't this bug be closed, then? The patch Paolo wrote was applied and
shipped in 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60708
--- Comment #2 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Well, no - the error that 4.7 gives is caused by my using a C++14 deduced
return type for a function there. 4.9 supports those with --std=c++1y.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60708
--- Comment #3 from Ville Voutilainen ville.voutilainen at gmail dot com ---
So, to clarify, this is not accepts-invalid, nor is it a 4.7-4.9 regression
with regards to whether the function should be accepted. If I change the test
to
be purely C
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Test:
template class T, class U struct mypair {
mypair(T, U) {}
};
template class T, class U auto my_make_pair(T t, U u)
{
return mypairT, U(t, u);
}
templatetypename T struct S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
CC
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
template class T, class... U void f(T t, int i, U... u) {}
template class... T void g(T... t) {g(t..., 5, t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59838
--- Comment #3 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Ok, but the patch needs to be massaged a bit to give an error in the case where
the underlying type is not set, if the complain flag has error set. I can do
that, seems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59838
--- Comment #5 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Ah, of course, it will end up returning error_mark_node and then other
machinery reports the error. Ok, looks quite good. Can you post it to
gcc-patches, then?
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Very simple test:
enum E { a, b = true ? 1 : ((E)a, 0) };
enumcrash.cpp:1:32: internal compiler error: Segmentation fault
enum E { a, b = true ? 1 : ((E)a, 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59701
--- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com ---
The testcase caused an ICE in recent versions of clang, and was fixed so that
the code is rejected by clang. This is related to Core Issue 1430, so the bug
should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59702
--- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com ---
I forgot to mention that clang accepts the code.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
struct A {};
templatetypename
int func (A) {
return {};
}
templatetypename T
auto func () - decltype (funcT (A{})) {
return {};
}
int
main
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
templatetypename... Args struct foo { };
templatetypename T, typename... Args using bar = fooT, Args...;
templatetypename T, typename
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
int main
{
static const int x = 5;
const int * const y = x;
static_assert(y, );
}
clang rejects this, gcc accepts.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59686
--- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Ville Voutilainen from comment #0)
int main
{
static const int x = 5;
const int * const y = x;
static_assert(y, );
}
clang rejects
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
constexpr int foo(float f) {return int(f);}
int main()
{
const float x = 0.5;
static_assert(x 0.1, all good); // #1
constexpr int i = foo(x); // #2
}
gcc accepts
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Test snippet:
templatetypename T
int func (T) { return 0; }
templatetypename T, typename... Ts
auto func (T t, Ts... ts
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Test:
struct aa {
friend struct cc;
private:
struct bb {};
};
struct cc : aa::bb {};
Output:
ville.cpp:1:47: error: ‘struct aa::bb’ is private
struct aa { friend struct cc
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Test:
struct X {
protected:
int i;
};
struct Y: X {
void f() {
[]{ X::i = 3; }(); } // #1
};
Output:
eelis.cpp: In lambda function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59482
--- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com ---
A friend function can access the private class, thus
void f();
struct B {
friend void f();
private:
struct C {};};
void f() {
struct D : B::C{};
}
Some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59457
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
CC
: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Test:
templateint,int struct Obj;
templatetypename... Ts struct
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Reduced test:
struct X
{
//friend void f(int) {} // #1
template class T friend void f(T) {} // #2
};
int main()
{
f(5); // #3
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
This code compiles without any problem:
templatetypename class Obj;
template class Objvoid {
struct secret
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58761
--- Comment #2 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Reduced:
template class T
struct X
{
int x = 42;
int y = [this](){return this-x;}();
};
int main()
{
Xint x;
}
Seems to require a template to trigger, but from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58753
--- Comment #8 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Slightly reduced, I guess...
#include initializer_list
template class T
struct X {X(std::initializer_listint) {}};
template class zomg
class T {
XT x{1};
};
int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55588
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51851
Bug #: 51851
Summary: Overriding a function with a parameter of dependent
type fails to override.
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51851
--- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com
2012-01-13 19:13:13 UTC ---
Johannes Schaub says in both situations the question is whether the parameter
type adjustments happen immediately or after instantiation (when T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50811
--- Comment #7 from Ville Voutilainen ville.voutilainen at gmail dot com
2011-10-21 14:24:23 UTC ---
(In reply to comment #6)
thanks!
You're welcome! I don't like leaving bugs open in code I wrote,
so instead of turning in early, I decided
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50811
--- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com
2011-10-20 23:26:57 UTC ---
Oh my.
struct C
{
int x;
};
int main()
{
struct C final {};
int y = final.x;
}
says
error: ‘final’ was not declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50811
--- Comment #2 from Ville Voutilainen ville.voutilainen at gmail dot com
2011-10-20 23:34:06 UTC ---
It thus looks like it gets parsed as a class definition instead of a variable
definition.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50811
--- Comment #3 from Ville Voutilainen ville.voutilainen at gmail dot com
2011-10-20 23:48:15 UTC ---
(In reply to comment #2)
It thus looks like it gets parsed as a class definition instead of a variable
definition.
..which is actually correct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50811
--- Comment #4 from Ville Voutilainen ville.voutilainen at gmail dot com
2011-10-21 00:40:58 UTC ---
Patch in
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01914.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50169
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41426
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
CC
501 - 554 of 554 matches
Mail list logo
