||2014-08-18
CC||ville.voutilainen at gmail dot
com
Ever confirmed|0 |1
--- Comment #1 from Ville Voutilainen ---
Reduced:
#include
int move_count = 0;
struct X {
X() = default;
X(const X&) = def
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
: 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
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
First test:
#include
#ifdef OK
struct ostream { } cout;
bool operator<<(ostream&, const char* s)
{ __builtin_printf("%s", s); return true; }
#else
using std::co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
--- Comment #6 from Ville Voutilainen ---
(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 to have these as duplicates
because wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61491
--- Comment #1 from Ville Voutilainen ---
This is part of DR1206:
http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#1206
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
#include
template struct Base
{
enum class E : unsigned;
E e;
Base(E e) : e(e) {}
};
struct X;
template<>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59483
--- Comment #3 from Ville Voutilainen ---
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 the patch fixes, or the patch itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
--- Comment #3 from Ville Voutilainen ---
[ville@localhost ~]$ g++ --std=c++11 -c dan.cpp
dan.cpp: In instantiation of ‘struct derive::foo(base::type) [with T = char;
base::type = int]::f_t’:
dan.cpp:18:5: required from ‘void derive::foo(base:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59483
--- Comment #2 from Ville Voutilainen ---
It seems that 58972 is a duplicate, and is fixed by the same patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61133
--- Comment #1 from Ville Voutilainen ---
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 #13 from Ville Voutilainen ---
(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, but that's another
matter), so I rec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58753
--- Comment #11 from Ville Voutilainen ---
(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 the problem.
nt: c++
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 varia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51501
--- Comment #10 from Ville Voutilainen ---
(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 Issues was more or less
on hold w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51424
--- Comment #8 from Ville Voutilainen ---
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 ---
(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, so this is already in, no need t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60708
--- Comment #3 from Ville Voutilainen ---
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++11, it ICEs on 4.7 and 4.8 as well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60708
--- Comment #2 from Ville Voutilainen ---
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.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Test:
template struct mypair {
mypair(T, U) {}
};
template auto my_make_pair(T t, U u)
{
return mypair(t, u);
}
template struct S {
mypair get_pair() noexcept {
return my_make_pair
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
template void f(T&& t, int i, U&&... u) {}
template void g(T&&... t) {g(t..., 5, t...);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59838
--- Comment #5 from Ville Voutilainen ---
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?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59838
--- Comment #3 from Ville Voutilainen ---
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 simple enough.
++
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 ---
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 probably be on hold until CWG decides the
erity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
template struct foo { };
template using bar = foo;
template using baz = bar;
int
main (int argc, char *argv[])
{
}
This gives
ed
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
struct A {};
template
int func (A) {
return {};
}
template
auto func () -> decltype (func (A{})) {
return {};
}
int
main (int argc, c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59702
--- Comment #1 from Ville Voutilainen ---
I forgot to mention that clang accepts the code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59686
--- Comment #1 from Ville Voutilainen ---
(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 this, gcc accepts.
well, typ
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.
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
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59482
--- Comment #1 from Ville Voutilainen ---
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 analysis follows:
I investigated t
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 func
++
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
IRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Test snippet:
template
int func (T) { return 0; }
template
auto func (T t, Ts... ts) -> decltype (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59457
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
: 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:
template struct Obj;
template struct A {
template class> struc
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 friend void f(T) {} // #2
};
int main()
{
f(5); // #3
}
The function in
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:
template class Obj;
template<> class Obj {
struct secret{};
};
template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58753
--- Comment #8 from Ville Voutilainen ---
Slightly reduced, I guess...
#include
template
struct X {X(std::initializer_list) {}};
template
class T {
X x{1};
};
int main()
{
T t;
}
This gives
plaatti-reduced2.cpp: In constructor ‘
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58761
--- Comment #2 from Ville Voutilainen ---
Reduced:
template
struct X
{
int x = 42;
int y = [this](){return this->x;}();
};
int main()
{
X x;
}
Seems to require a template to trigger, but from that point onwards,
it's quite easy to trigg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55588
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51851
--- Comment #1 from Ville Voutilainen
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 is replaced
by the actual type)",
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: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50811
--- Comment #7 from Ville Voutilainen
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 to fix it. ;)
Just out of curiosity,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50811
--- Comment #4 from Ville Voutilainen
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=50811
--- Comment #3 from Ville Voutilainen
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, pardon my ruminations, it just
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50811
--- Comment #2 from Ville Voutilainen
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 #1 from Ville Voutilainen
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 in this scope
When it's just struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50169
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41426
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail
501 - 554 of 554 matches
Mail list logo
