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=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
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
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
: 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59457
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
CC
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
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62172
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62172
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57533
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
CC
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
CC: jason at redhat dot com
Simple case:
template class T
struct Y
{
template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63201
--- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Created attachment 33458
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33458action=edit
Additional specialization tests for variable templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63201
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61133
--- Comment #4 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Yep, done.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
CC: jason at redhat dot com
Jason wrote in a private email:
I think what we need is a compiler hook to say whether a particular expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #3 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Looks good so far. I think this is a sufficient start for implementing the
library traits. Does the patch cover template cases as well? Such as
struct B {B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60132
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60132
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #10 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Reduced:
template bool b
struct bool_
{
};
template typename T, class... Args
struct mytrait : bool___is_trivially_constructible(T, Args...)
{
}
trivial_trait2.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #13 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Hmm. The first of the two ICE tests still ICEs. It no longer stops my build,
though - and I don't quite understand why, because previously the build
ICEd when building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #15 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Jason Merrill from comment #14)
(In reply to Ville Voutilainen from comment #13)
Hmm. The first of the two ICE tests still ICEs.
Which test? None
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #16 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Ville Voutilainen from comment #15)
(In reply to Jason Merrill from comment #14)
(In reply to Ville Voutilainen from comment #13)
Hmm. The first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #18 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Jason Merrill from comment #17)
(In reply to Ville Voutilainen from comment #16)
This one:
#include type_traits
template typename T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #20 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Jason Merrill from comment #19)
(In reply to Ville Voutilainen from comment #18)
to work just fine. Yet this particular test will not work with my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #22 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Created attachment 33664
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33664action=edit
Preprocessed source for is_trivially_copy_constructible tests
This test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #24 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Jason Merrill from comment #23)
(In reply to Ville Voutilainen from comment #22)
This test fails the static_assert for TType (which is a trivial type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #26 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Jason Merrill from comment #25)
And the ICE reduces to
struct A {
A(...);
};
int main()
{
volatile A a;
volatile A a2(a);
}
which
-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
CC: jason at redhat dot com
Created attachment 33702
-- https://gcc.gnu.org/bugzilla
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
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
++
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=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?
: 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=50025
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
CC
++
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=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
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=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=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
++
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
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
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=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=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
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=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
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=50169
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
CC
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=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=31397
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
--- Comment #9 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Ville Voutilainen from comment #8)
Does not ICE anymore, and the original bug has been resolved (Daniel's local
class example is still rejected). I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
CC: jason at redhat dot com
Test snippet:
#include initializer_list
struct _Iter_less_iter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57979
--- Comment #5 from Ville Voutilainen ville.voutilainen at gmail dot com ---
I think this should be put on hold, since EWG told CWG in Rapperswil
that const floats should perform the same magic as const ints do, see
http://open-std.org/JTC1/SC22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57979
--- Comment #6 from Ville Voutilainen ville.voutilainen at gmail dot com ---
In other words, EWG wants the standard to be changed so that GCC's behavior
actually becomes conforming, as far as I understand the intent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63959
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63959
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63999
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12277
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
CC
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
templatetypename struct foo
{
static_assert(noexcept(((foo *)1)-~foo()), );
};
template class fooint;
Clang diagnoses the use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58107
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
CC: jason at redhat dot com
The problem occurs with forward and move, but not with a static_castT(t).
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64178
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64169
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64171
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62212
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60372
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64073
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63996
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61971
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63809
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
1 - 100 of 551 matches
Mail list logo
