http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59165
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
I think I remember the rationale now: std::begin and std::end only work if
c.begin() and c.end() xist, in which case range-based for will use those
members directly anyway.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org ---
It's not fixed yet, sorry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59173
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
Thanks for the report, John. I'll fix the library parts (assuming the corrected
versions still compile with G++)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59182
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59177
--- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Andy Lutomirski from comment #5)
# For clock_gettime, nanosleep and sched_yield support.
# NB: The default is [no], because otherwise it requires linking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59192
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
It will get fixed when adding C++11 allocator support to std::deque, which is
in progress but not ready.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
struct A
{
static constexpr bool value = true;
};
templatetypename T
struct B
{
templatetypename U
using C = A;
};
templatetypename T
templatetypename U
const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59210
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59173
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
Author: redi
Date: Wed Nov 20 13:39:33 2013
New Revision: 205114
URL: http://gcc.gnu.org/viewcvs?rev=205114root=gccview=rev
Log:
PR c++/59173
* include/ext/pointer.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59173
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||accepts-invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59213
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
I think G++ is implementing the resolution of
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1402
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59213
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Bruce Merry from comment #0)
assuming I've correctly interpreted the C++11 spec [the draft - N3242].
That's a pretty old draft now, you'd be better looking at a current
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Oleg Smolsky from comment #0)
in ...gcc/include/c++/4.8.x-google/x86_64-unknown-linux/bits/atomic_word.h
typedef int _Atomic_word;
Should this be std
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org ---
I realise that, but the general point is still valid: for race detectors to
understand the atomic updates in the library they library needs to be compiled
with the race detector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #6)
tsan as well, but the point is till ...
s/till/still/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org ---
No, you're right, that's a different issue. I think we've just been relying on
loads of (correctly-aligned) _Atomic_word being atomic, although that's not
going to keep tsan happy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49204
--- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org ---
Author: redi
Date: Wed Nov 20 20:59:19 2013
New Revision: 205144
URL: http://gcc.gnu.org/viewcvs?rev=205144root=gccview=rev
Log:
PR libstdc++/49204
* include/std/future
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49204
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords|ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188
--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Kostya Serebryany from comment #1)
one other problem would be that we have zero tests for tsan in gcc :(
It would be great if someone could do something about
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59224
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59224
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
Possibly a dup of PR 41174 (although that was wrong prior to 4.6.0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59246
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59247
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org ---
Oleg, I can't reproduce this tsan warning with the cases Iv'e tried, what is
the stack trace you see?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59238
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59247
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
namespace outer {
inline namespace inner {
#ifndef OK
templatetypename T struct A;
#endif
: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
I *think* this is valid, and clang accepts it, but G++ doesn't:
namespace detail {
inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59247
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
Author: redi
Date: Fri Nov 22 16:59:25 2013
New Revision: 205277
URL: http://gcc.gnu.org/viewcvs?rev=205277root=gccview=rev
Log:
PR libstdc++/59247
* include/bits/c++config
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59247
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59256
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
It only affects --enable-symvers=gnu-versioned-namespace not the default
config, but it makes regex unusable. We can work around it if needed by
moving __regex_algo_impl out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59264
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
Your code has undefined behaviour because it modifies the same variables more
than once between sequence points.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59264
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59274
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59283
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
This is a known issue. Our std::string does not support the C++11 allocator
requirements, and the current implementation probably never will. When we
switch to a non-Copy-On-Write
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59294
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59296
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53683
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Ed Smith-Rowland from comment #4)
It looks like libcpp/charset.c might have a lot of the guts that could help
with the implementation of codecvt_utf8, etc.
Maybe we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53683
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org ---
We also have ext/codecvt_specializations.h but it needs a lot of work to
re-use.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53683
--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org ---
Because your program is ill-formed, and not supposed to compile, so what you
reported is not a bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59312
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
Which document are you looking at? That's not what 12.8/23 in the standard
says.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
I believe the information at
http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Volatiles.html is true of C++03
but not C++11.
The relevant change is
http://open
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
You can use a #pragma to disable -Wdeprecated locally
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org ---
It's now 2013 so the sensible thing to do is not return by value if your
destructor can throw.
FWIW Clang also behaves the same as G++ and Intel, and of course calls
std::terminate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59312
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Alexander Khovansky from comment #0)
— any direct or indirect virtual base class.
I'm looking at N3290, but was looking for a bullet starting with that text. Now
I see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
Doing this before any other includes will work:
#include bits/c++config
#undef _GLIBCXX_DEPRECATED
#define _GLIBCXX_DEPRECATED
I'm not convinced we want to support this officially.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54316
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Summary|[C++11] move constructor|[C++11] move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59342
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59360
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
another dup of PR 57899 ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59365
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59373
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59373
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
You can also look in the source, where the table is formatted correctly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59373
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59406
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
We're not really making any non-critical changes to TR1 code now.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59449
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
What page links to them?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59421
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
Is all that code really necessary to demonstrate the bug?
Please read http://gcc.gnu.org/bugs/ again (you did read it before submitting
,as requested, right?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59439
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org ---
Don't do that then ;-)
Noone ever claimed std::stringstream is a good way to convert integers to
strings in performance critical code. Even if the std::locale construction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59514
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
I think this is already fixed on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org ---
Users can specialize std::setUserDefinedType::find to do something different,
e.g. write to a file, and it must not do that if they call std::find.
It's not a matter of whether
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59552
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59681
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59192
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org ---
It should be done for GCC 5.0
The WIP patch is not reliable.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54170
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53901
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54170
--- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-06
08:32:28 UTC ---
I think those errors indicate you don't have Flex installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54186
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-06
10:12:13 UTC ---
(In reply to comment #0)
I hope I posted ok.
Please read http://gcc.gnu.org/bugs/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-06
14:30:31 UTC ---
Thanks very much. For this sort of test it doesn't need to fail every time, the
GCC testsuite is run often enough on a wide enough variety of systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54194
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54196
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-07
20:55:36 UTC ---
N.B. there are various overloads of operator new that are implicitly declared
in every translation unit, including (in C++03)
void* operator new(std::size_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54207
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-09
11:39:10 UTC ---
4.7.1 gets an ICE too, but it works on trunk.
As it's undefined behaviour (bool is a keyword) and it already works on trunk
it might not be worth changing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-09
21:50:59 UTC ---
Why is this marked enhancement ?
Is this the same issue as PR 54213 ? If so please close that one.
What exactly is your question and why do you think it's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54180
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54180
--- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-10
15:04:10 UTC ---
Also, you declare SQL_date_begin[10] then fill it with 11 characters
(-MM-DD plus the numm terminator) and do the same with SQL_date_end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182
--- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-10
16:53:54 UTC ---
You can use a linker version script.
http://sourceware.org/binutils/docs/ld/VERSION.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182
--- Comment #17 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-11
00:02:03 UTC ---
If it does what you need then use it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-12
16:22:28 UTC ---
I need a ChangeLog entry before I can commit the change, which needs your name,
could you provide a ChangeLog entry? Thanks.
Unless I'm mistaken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51452
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52681
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-12
18:57:58 UTC ---
Author: redi
Date: Sun Aug 12 18:57:53 2012
New Revision: 190330
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190330
Log:
PR libstdc++/52681
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52681
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54237
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||bkoz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185
--- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-13
14:35:21 UTC ---
Perfect - thanks. I'll get it committed tonight.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54197
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185
--- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-13
19:56:55 UTC ---
Author: redi
Date: Mon Aug 13 19:56:50 2012
New Revision: 190356
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190356
Log:
2012-08-13 David Adler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185
--- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-13
19:56:55 UTC ---
Author: redi
Date: Mon Aug 13 19:56:50 2012
New Revision: 190356
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190356
Log:
2012-08-13 David Adler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185
--- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-13
19:57:36 UTC ---
Author: redi
Date: Mon Aug 13 19:57:31 2012
New Revision: 190357
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190357
Log:
2012-08-13 David Adler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54248
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54248
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-14
08:01:44 UTC ---
Should this comment really be talking about boost?
N.B. I don't see any actual harm in talking about Boost, seeing as the concept
checking code came
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-14
10:50:40 UTC ---
(In reply to comment #5)
seems mildly inconsistent to add things only to the *few* *.h headers over
which we do have control.
Better to be mildly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54249
--- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-14
10:59:41 UTC ---
N.B. see also http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00375.html and
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00192.html and the stdalign.h part
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54250
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54258
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54259
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Target|debian on amd64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54260
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53632
--- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-15
14:28:02 UTC ---
yes it was only ok very briefly, and has been slow again since then
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54259
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-15
14:46:11 UTC ---
Re component - c++
Although the error is due to a limitation in the FE, it's not a regression in
the FE, as SFINAE has never respected access control until
401 - 500 of 22294 matches
Mail list logo
