https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118329
Jonathan Wakely changed:
What|Removed |Added
See Also||https://github.com/modm-io/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99572
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 99572, which changed state.
Bug 99572 Summary: std::counting_semaphore coalescing wakes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99572
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100806
Jonathan Wakely changed:
What|Removed |Added
CC||michaelkuc6 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112934
--- Comment #2 from Jonathan Wakely ---
Gah, I didn't get around to this for GCC 15, sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #44 from Jonathan Wakely ---
Oops, I put this PR number in the commits rather than PR 118493
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118493
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50871
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #10 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Jonathan Wakely from comment #0)
> > In C++20 mode includes which includes
> > for SYS_futex,
>
> We should use for that instead, which wou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118493
Jonathan Wakely changed:
What|Removed |Added
Priority|P3 |P2
|1
Last reconfirmed||2025-01-15
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #1 from Jonathan Wakely ---
Already testing a patch
++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 88322
Target Milestone: ---
Currently we use __platform_wait_t internally, which is int on Linux. That
means we only support up to std::counting_semaphore.
Referenced Bugs:
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116586
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #40 from Jonathan Wakely ---
Yes please - thanks for catching it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118408
--- Comment #8 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #7)
> Some of them, no? Only if one rebuilds all the new ABI std::regex using
> objects with newer gcc.
Ah yes, good point.
> On the other side, was std::regex a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118408
--- Comment #4 from Jonathan Wakely ---
(In reply to TC from comment #0)
> It may be too late to fix this though, but it's nice to at least have an
> issue to track it.
I think it might be OK to add the abi_tag("__cxx11") now.
It could cause p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118408
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> It fails if you mix old and new ABIs in a single executable.
More precisely, if you mix std::regex compiled with the old and new ABIs in a
single executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118408
--- Comment #2 from Jonathan Wakely ---
It fails if you mix old and new ABIs in a single executable. Using either ABI
consistently throughout the entire program works OK. If you mix them and use
std::regex, the linker picks either the old or new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87950
--- Comment #19 from Jonathan Wakely ---
(In reply to nightstrike from comment #17)
> As long as we are hijacking for C++, the following should not warn, given
> how enum class works:
Are you sure you know how enum class works?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118408
Jonathan Wakely changed:
What|Removed |Added
Keywords||ABI
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118402
--- Comment #1 from Jonathan Wakely ---
The code comments say:
2. A great deal of attention has been paid to avoid cache line thrashing
by flattening the tree structure into cache-line sized arrays, that
are indexed in an efficient way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99277
--- Comment #24 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #14)
> > 5) std::barrier implementation also uses a type that futex(2) can't handle
>
> barrier still uses a 1-byte enum for the atomic waits.
I've created PR 1
bstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 88322
Target Milestone: ---
Split out from PR 99277
The wait/notify synchronization in std::barrier is done on a 1-byte enum, which
means it has to use a proxy wait insid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118301
--- Comment #7 from Jonathan Wakely ---
(In reply to Richard Sandiford from comment #6)
> You obviously know better than me :), but I thought c++2a was used for
> things that aren't yet fully specified. Here it's about something that is
> fully
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974
--- Comment #7 from Jonathan Wakely ---
Patch posted that implements the proposed resolution:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673200.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101825
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
Jonathan Wakely changed:
What|Removed |Added
CC||tobias.schmidt at in dot tum.de
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118395
--- Comment #4 from Jonathan Wakely ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673200.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98749
--- Comment #2 from Jonathan Wakely ---
Patch for std::barrier checks posted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673200.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118395
--- Comment #3 from Jonathan Wakely ---
So all we need to do is add a single point of contention that all threads
synchronize on every time they call arrive, to make our contention-avoiding
tree barrier work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110854
Jonathan Wakely changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118395
--- Comment #2 from Jonathan Wakely ---
Making this constexpr requires major changes:
size_t const __count = (_M_expected + 1) >> 1;
_M_state = std::make_unique<__state_t[]>(__count);
We can't allocate an array during constan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115955
--- Comment #2 from Jonathan Wakely ---
std::barrier does:
std::hash __hasher;
size_t __current = __hasher(std::this_thread::get_id());
Maybe this could be improved too, although it doesn't have exactly the same
issue (not all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2023-02-28 00:00:00 |2025-1-10
--- Comment #6 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118395
--- Comment #1 from Jonathan Wakely ---
We also have:
static constexpr ptrdiff_t
max() noexcept
{ return __PTRDIFF_MAX__; }
But this seems wrong, because the constructor does:
size_t const __count = (_M_expected + 1
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
The C++20 standard says:
constexpr explicit barrier(ptrdiff_t expected,
CompletionFunction f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98749
--- Comment #1 from Jonathan Wakely ---
r15-4209-gf5021ce9aa6be5 added a check to std::latch::count_down, but with a
copy&paste error so that the same check is done twice. Oops.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115402
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110854
Jonathan Wakely changed:
What|Removed |Added
Blocks||88322
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98749
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
|ASSIGNED
Ever confirmed|0 |1
Last reconfirmed||2025-01-10
Assignee|rodgertq at gcc dot gnu.org|redi at gcc dot gnu.org
Blocks||88322
Referenced Bugs:
https
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Target Milestone|--- |15.0
Last reconfirmed|2023-12-10 00:00:00 |2025-1-10
Blocks||88322
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
[Bug
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Target Milestone|--- |15.0
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117962
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118035
Jonathan Wakely changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118093
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29593
--- Comment #8 from Jonathan Wakely ---
*** Bug 118386 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118386
Jonathan Wakely changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #5 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118260
--- Comment #8 from Jonathan Wakely ---
std::get for pair is from C++11, but yes it's a good candidate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118365
--- Comment #4 from Jonathan Wakely ---
Dup of PR 97174, or at least related.
Oh, I see Andrew already found that :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118260
--- Comment #6 from Jonathan Wakely ---
Good enough? Any other suggestions for functions to skip?
std::get for tuples?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118355
Jonathan Wakely changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118177
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90389
--- Comment #4 from Jonathan Wakely ---
Fixed for GCC 15, backports likely at a later date.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118093
--- Comment #2 from Jonathan Wakely ---
Fixed for GCC 15, but probably worth backporting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98723
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445
Bug 102445 depends on bug 98723, which changed state.
Bug 98723 Summary: On Windows with CP936 encoding, regex compiles very slow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98723
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445
Bug 102445 depends on bug 85824, which changed state.
Bug 85824 Summary: regex constructor crashes under UTF-8 locale on Solaris
SPARC when parsing a simple character class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85824
What|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94409
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445
Bug 102445 depends on bug 94409, which changed state.
Bug 94409 Summary: std::regexp (std::collate?) with GCC 7.3.1 on AIX, Japanese
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94409
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85824
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118349
--- Comment #5 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #4)
> Yes, it's just a hypothetical example, I probably wouldn't actually use such
> a low value myself, but rather would determine an appropriate value
> experiment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118301
--- Comment #5 from Jonathan Wakely ---
We already have -std=c++2a for that and it doesn't solve anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118341
--- Comment #3 from Jonathan Wakely ---
The debug bitset also does checking in its reference type, but only for C++98:
// In C++11 we rely on normal reference type to preserve the property
// of bitset to be use as a literal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118341
--- Comment #2 from Jonathan Wakely ---
(In reply to Sam James from comment #1)
> -D_GLIBCXX_DEBUG does fire on that mystery c[4] case but none of the others.
There's a __gnu_debug::bitset class that replaces std::bitset in debug mode.
The con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118349
--- Comment #2 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #0)
> for users who are okay with template usage, but just
> don't want it to get out of hand.
What does "get out of hand" mean? What unwanted consequence would yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118349
--- Comment #1 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #0)
> For example, one could do -Wtemplate-depth=17
> -ftemplate-depth=1024 to get a warning when the pre-C++11 limit is reached,
> but only actually fail if the pos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118341
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118334
--- Comment #4 from Jonathan Wakely ---
(In reply to Georg-Johann Lay from comment #2)
> Optionally, NAME is the new name of the mode. NAME is the
> name of the mode.
What does this mean?!
It seems confusing to me that INT_MODE an
ormal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: avr at gjlay dot de
Target Milestone: ---
Target: avr
Targets that define integers with non-standard sizes should inform li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118323
--- Comment #1 from Jonathan Wakely ---
Clang does better:
esc.cc:8:3: error: call to immediate function 'func()::(anonymous
class)::operator()' is not a constant expression
8 | []{
| ^
esc.cc:1:43: note: subexpression not valid i
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
This C++20 program gives a nice clear diagnostic:
consteval int check(int i) { if (i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118260
--- Comment #4 from Jonathan Wakely ---
Not all of those containers actually have a back() or data() member function,
but it doesn't matter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118260
--- Comment #3 from Jonathan Wakely ---
This seems like a good start:
--- a/libstdc++-v3/python/hook.in
+++ b/libstdc++-v3/python/hook.in
@@ -55,6 +55,11 @@ if gdb.current_objfile () is not None:
if not dir_ in sys.path:
sys.path.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118293
--- Comment #2 from Jonathan Wakely ---
It's possible that reusing the "trailing" capacity when pushing at the front of
an empty deque will break some invariant which other members rely on (e.g we
assume that popping the last element from a dequ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118293
--- Comment #1 from Jonathan Wakely ---
Similarly:
using V = std::deque>;
V v;
printf("Default-constructed capacity: %zu\n", capacity_of_v());
v.assign(capacity_of_v(), 1);
printf("Capacity after assign: %zu\n", capacity_of_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118244
--- Comment #9 from Jonathan Wakely ---
Libstdc++ does this for mingw-w64:
// Make sure that POSIX printf/scanf functions are activated. As
// libstdc++ depends on POSIX-definitions of those functions, we define
// it unconditionally.
#undef _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67119
--- Comment #5 from Jonathan Wakely ---
Or for commits on all branches:
$ git log --oneline --grep c++/8805 --tags=releases
e94987ae569 re PR c++/8805 (compile time regression with many member variables)
bafb714bac2 re PR c++/8805 (compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67119
--- Comment #4 from Jonathan Wakely ---
For example:
$ git log --oneline --grep c++/8805
bafb714bac2 re PR c++/8805 (compile time regression with many member variables)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118293
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118260
--- Comment #2 from Jonathan Wakely ---
I would like it if the libstdc++ code could use an attribute to opt-in to the
-ffold-simple-inlines logic used for std::move etc.
As noted in PR 96780, at some point I tried using __attribute__((artificia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102749
--- Comment #3 from Jonathan Wakely ---
>From the error message, I think the code looks like this:
#include
#include
using T = unsigned;
using Vec = std::vector;
struct Cont
{
void insert(std::variant&&, int) { }
void insert(std::varian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118276
--- Comment #11 from Jonathan Wakely ---
N.B. your first godbolt example never tests -DMODE=1 because the second pane
uses -DDEFAULTED=1
(In reply to Ben FrantzDale from comment #0)
> I think (?) `S() noexcept {}` is semantically the same as `
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118263
--- Comment #6 from Jonathan Wakely ---
(In reply to Richard Yao from comment #0)
> WaitForSingleObjectEx() is a C ABI function and thus invoking a C++
> exception in it triggers undefined behavior.
No it doesn't.
The compiler has no way to kn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107759
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107758
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118230
--- Comment #4 from Jonathan Wakely ---
The C++ standard specifies the requirements on hash functions and they must
return std::size_t, so what's the benefit of the reduced return type? Why not
just return size_t?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118191
--- Comment #4 from Jonathan Wakely ---
This bug database is still the wrong place for your questions.
You probably need a newer glibc, strtof128 is relatively new.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118196
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-12-24
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118191
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #22 from Jonathan Wakely ---
(In reply to Yury Gribov from comment #19)
> (In reply to Jonathan Wakely from comment #17)
> > That's what _GLIBCXX_DEBUG and/or _GLIBCXX_ASSERTIONS are for.
>
> I'm not sure they solve the issue
I'm n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118177
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-12-23
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #17 from Jonathan Wakely ---
(In reply to Yury Gribov from comment #10)
> As a compiler user I would actually love my STL to crash fast on invalid
> comparators rather than produce unpredictable and meaningless results which
> will c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118162
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #39 from Jonathan Wakely ---
(In reply to Antony Polukhin from comment #37)
> Unfortunately the examples are not artificial. People do write business
> logic code as `vector_variable == std::vector{"*"}`. That
> particular example is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #38 from Jonathan Wakely ---
That doesn't mean it has to be fast though. If people want to write slow code,
they get slow programs!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259
--- Comment #16 from Jonathan Wakely ---
Yes, I saw the freebsd changes and came to the same conclusion. Looping on 2gb
chunks won't hurt much.
I thought I saw some docs saying >= INT_MAX fails, but maybe I'm wrong. The
Rust change uses INT_MAX
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #7 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #5)
> Yes the original C++20 standard was written that way but was changed by LWG
> DR 2937 : https://cplusplus.github.io/LWG/issue2937 .
C++17 said (is_ot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99931
--- Comment #4 from Jonathan Wakely ---
There was a question on the Core reflector about this in June 2017, subject
"unnamed class in alias declaration"
The replies suggested that no semantic difference is intended and it's just a
wording oversi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99931
--- Comment #3 from Jonathan Wakely ---
Clang and EDG both treat the using-declaration as equivalent to a
typedef-declaration, and the first stackoverflow link says that MSVC does too.
I don't see an open Core issue about this, but it seems like
1 - 100 of 7196 matches
Mail list logo
