https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86476
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
ent: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
The last comment in LWG 1052 says "the wording in [reverse.iter.elem] (of
P0896R4) for operator-> is equivalent to the PR for LWG 1052"; unfortunately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
Case:
#include
#include
#include
using std::size_t;
#if __cpp_lib_integer_sequence >= 201304L
using
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Cases:
$ cd /tmp
$ g++ --version
g++ (GCC) 13.1.1 20230714
Copyright (C) 2023 Free Software Foundation, Inc.
This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103240
--- Comment #9 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #8)
> I don't think that's true. If __GXX_MERGED_TYPEINFO_NAMES is true then the
> out-of-line definition is correct. You can'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103240
--- Comment #7 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #6)
> What are the mangled type names that are unordered? (that's all you need to
> describe, everything about flat_map and partiti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103240
--- Comment #5 from frankhb1989 at gmail dot com ---
There are multiple issues.
1. The out-of-line definition and the inline definition of
std::type_info::before do different things. Specifically, only one name is
detected against to '*&#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103240
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
_M_merge_unique and _M_merge_equal in _Rb_tree have noexcept. This is
problematic because the call to _M_insert_node is potentially throwing, by the
call to the comparison object
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
//#if __cplusplus >= 201103L
template
__enable_if_t<__same_value_type<_InputIterato
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101279
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104191
--- Comment #4 from frankhb1989 at gmail dot com ---
Well, surrendering at the possibility of huge amount of node allocations,
because there is LWG 2794. (I'd complain this is over-restrictive and pure loss
of functionality for allocators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104191
--- Comment #2 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to frankhb1989 from comment #0)
> > and it should be solely determined by the internal node count type.
>
> What is th
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
Case:
#include
#include
template
struct one_alloc : std::allocator
{
template struct rebind { using other = one_alloc;};
T* allocate(std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92137
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100937
--- Comment #10 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to frankhb1989 from comment #7)
> The toolchain might not be ELF-specific, but
> on targets that *do* use ELF, of cours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100937
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
As I see has been removed in GCC 11, but the doc disagree:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_using.html
https://gcc.gnu.org/onlinedocs/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
Case:
template
void h()
{}
void f() noexcept
{}
int main()
{
h();
}
g++ prog.cc -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362
--- Comment #8 from frankhb1989 at gmail dot com ---
The first diagnostic message of `#pragma GCC poison __deref` points to
in my MSYS2 installation.
The change is made here:
https://sourceforge.net/p/mingw-w64/mingw-w64/ci
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82955
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362
--- Comment #1 from frankhb1989 at gmail dot com ---
To clarify a bit: is installed by the VC++ toolchain or WDK, not by
Windows SDK. Nevertheless, it is a system header both MS's CRT and Win32
headers rely on.
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
Case:
#include
#include
int main()
{}
/tmp $ g++ -D_GLIBCXX_DEBUG a.cc
In file included from F:/msys64/mingw64/include/c
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
Case:
struct S
{
~S() = delete;
};
S f();
int main()
{
using X = decltype(f()); // #1
using Y = decltype(S{}); // #2
}
#2 is wrongly rejected in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93470
--- Comment #4 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to frankhb1989 from comment #2)
> > Sorry, I missed to mention it only failed with `clang++ -std=c++2a`
>
> If you&#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93470
--- Comment #2 from frankhb1989 at gmail dot com ---
Case:
#include
void foo() {}
int main()
{
std::ref(foo)();
}
Sorry, I missed to mention it only failed with `clang++ -std=c++2a` (using
Clang++ 9.0.1). G++ with `-std=c++2a` still
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
In `std::reference_wrapper::operator()` in :
#if __cplusplus > 201703L
static_assert(sizeof(type), "type must be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89640
--- Comment #9 from frankhb1989 at gmail dot com ---
This seems still problematic.
void test1() {
[]() __attribute__((noreturn)) noexcept [[]] -> int{
return 0; // Warning expected.
}();
}
void test2() {
[]() noexc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91620
--- Comment #2 from frankhb1989 at gmail dot com ---
I missed `unique` should be also affected. The fixes have been applied in
libc++ in the same commit to fix `remove_if`.
MSVC's current implementations are also correct, with a diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91620
--- Comment #1 from frankhb1989 at gmail dot com ---
(The issue number in the case seems a typo. It is introduced in
https://reviews.llvm.org/rL358534.)
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
A case for std::list taken from libc++'s testsuite:
#include
#include
#include
#include
using namespace std;
struct PredLWG529
{
PredLWG529(int i) :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #8 from frankhb1989 at gmail dot com ---
(In reply to frankhb1989 from comment #5)
> (In reply to Jonathan Wakely from comment #4)
> > This might strictly conform to the requirements, but it's stupid. Why would
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #6 from frankhb1989 at gmail dot com ---
(In reply to frankhb1989 from comment #5)
>
> And the noexcept exceptions provided in the current implementations are
> really inconsistent, for instance, between move operator= of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #5 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #4)
> This might strictly conform to the requirements, but it's stupid. Why would
> you do that?
>
> Allocator equality doesn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #3 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to frankhb1989 from comment #0)
>
> This type does not meet the allocator requirements. For a valid allocator,
> A::rebind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #1 from frankhb1989 at gmail dot com ---
Allocator-extended constructors with explicit exception specifications may also
have the value_type/node mismatch problems.
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
Case:
#include
#include
#include
#include
struct A : std::allocator>
{
template
str
IRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
In :
template
_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>&
_Rb_tree<_Key,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91480
--- Comment #4 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to frankhb1989 from comment #0)
> > Also, in , `__cpp_lib_allocator_traits_is_always_equal` is
> > wro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91480
--- Comment #2 from frankhb1989 at gmail dot com ---
I agree the problem of 'L' is not likely found as a real issue in practice.
Perhaps this could be forwarded as an issue of the standard which requires
overspecified definitions. I
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
These macros are lacking of the `L` suffix compared to the content of the table
in [support.limits.general]. This can lead to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
Case:
struct B
{};
struct C : virtual B
{
__attribute__((nonnull(2))) C(const char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89640
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
template
void f()
{
using S = signed char;
constexpr const S v[]{0};
}
int main()
{
f();
}
a.cc: In instantiation of 'void f() [with I = int]':
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87742
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86954
--- Comment #4 from frankhb1989 at gmail dot com ---
Well, actually I'm not sure if the original implementation has done the right
thing, as I don't find that the standard has requirement to specify that the
replaced definitions must a
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
In the current implementation std::return_temporary_buffer, ::operator delete
is called with std::nothrow as 2nd argument. (It seems here is the only
occurrence of
everity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
Since this had been adopted by N3936, it should at least be in C++14 & C++17
modes.
Note this is also i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80284
frankhb1989 at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.201z
shows that "the feature" of N4510 (except the fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339
--- Comment #12 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #10)
> This behaviour is by design and is not a bug. Valgrind no longer shows the
> allocation as reachable. Other tools might still show the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339
--- Comment #9 from frankhb1989 at gmail dot com ---
(In reply to Andrew Pinski from comment #8)
> (In reply to frankhb1989 from comment #7)
> > This is definitely a leak from the view of libc. Why is the status INVALID
> > ins
++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
Several enumerators are commented out in for
MinGW-w64.
However, I find several macros are actually usable in in the
distribution (MSYS2) I am using, as:
/* Defined as WSAETIMEDOUT
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
There are cases that certain type info symbols are not needed, e.g. a class as
operand of 'typeid' which has multiple Boost.Operators bases. These base
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67795
--- Comment #10 from frankhb1989 at gmail dot com ---
(In reply to Marc Glisse from comment #7)
> Hmm, with the static_cast, the front-end produces:
>
> < = (struct string_view &) (struct string_view
> *) NON_LVALUE_EXPR &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67795
--- Comment #9 from frankhb1989 at gmail dot com ---
(In reply to Richard Biener from comment #5)
> I would guess the issue is that ?: returns an rvalue (but that may not be
> 100% correct if omitting the cast works and does not warn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67795
--- Comment #8 from frankhb1989 at gmail dot com ---
(In reply to Markus Trippelsdorf from comment #4)
> Return by value if you want to avoid undefined behavior.
No. This is not the point. For something like 'std::move' or '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67795
frankhb1989 at gmail dot com changed:
What|Removed |Added
Version|unknown |5.2.0
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67795
--- Comment #3 from frankhb1989 at gmail dot com ---
(In reply to Markus Trippelsdorf from comment #1)
> gcc even warns:
>
> t.cpp: In function ‘std::experimental::fundamentals_v1::string_view&
> erase_left(size_t, s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67795
frankhb1989 at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
Case:
// g++ -std=c++1y
#include
#include
#include
using namespace std;
using namespace experimental;
string_view&
erase_left(size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67661
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39121
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890
--- Comment #7 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to frankhb1989 from comment #5)
> > Mainly for testing of the conformance.
>
> I don't understand what this me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890
--- Comment #5 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #3)
> This was changed by
> http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#613
>
> It was a defect in the original standard. W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890
--- Comment #2 from frankhb1989 at gmail dot com ---
Tested here: http://melpon.org/wandbox/, both G++ 5.1 and 6.0 accepted the
invalid code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890
--- Comment #1 from frankhb1989 at gmail dot com ---
Oops, wrong version of case pasted ... I once wanted to use this minimal one:
sizeof(Tag::m);
Nevertheless, the conclusion is the same for this issue.
(There are other mess, e.g. Clang++ 3.6
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
Case:
struct Tag { int m; };
int main()
{
sizeof(&(Tag::m));
}
According to ISO C++03 5.1/10, this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65748
--- Comment #1 from frankhb1989 at gmail dot com ---
G++ 5 also seems to fail.
Recent Clang++ is OK.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Case:
struct E
{
E() = default;
E(const E&) = delete;
E(E&&) = default;
};
int main()
{
E e;
try
{
// E e;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65343
--- Comment #2 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
> Maybe we want to placement-new the mutexes into a buffer so they are never
> destroyed, although on mingw that will show up as leaked res
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Recently I found one of my program unexpected aborted by unhandled exception.
The program is compliled with '-std=c++11 -D_GLIBCXX_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #5 from frankhb1989 at gmail dot com ---
BTW, what if the clock_gettime call failed? The current implementation does
nothing about error handling... (Though for QPC on Windows it should rarely
fail for machines within a decade.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #4 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #3)
> What libstdc++ is doing is sensible, why is the realtime clock so much
> coarser than the monotonic clock on mingw-w64?
It is not alway
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #2 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
> Which of macros are defined on mingw-w64?
>
> Preprocessing this should tell you
>
> #include
> #ifdef _GLIBCXX_USE_CLOCK
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
ISO C++ specifies high_resolution_clock "represent clocks with the shortest
tick period". The comment in also says it is "with the shortest tick
period". However, the cu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61019
frankhb1989 at gmail dot com changed:
What|Removed |Added
Known to fail||4.8.2, 4.9.0
--- Comment
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Case:
template
struct S
{
static_assert(((S*)0)->~S(), "");
};
S b;
Result:
T:\>D:\MinGW\bin\g++.exe a.cc -std=c++11
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Minimal case:
template
struct X{};
void f(X(&&)[1])
{}
int main()
{
f({X()});
}
g++ a.cc -std=c++11
a.cc: In funct
ity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Case:
class C
{
public:
void f()
{
void (C::*pf)() = f;
}
};
int main(){}
a.cc: In member function 'void C::f()
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Minimal case:
int main()
{
int* p = new() int;
}
This should be invalid because as per the standard(ISO C++98/03/11) or the
current working draft of the standard
++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Several operations are undefined because they failed to meet required
behavior(ISO C++11 [defns.required.behavior]) at runtime. Currently libstdc++
throw exceptions for them. For example, when object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53402
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Case:
struct C
{
bool empty();
};
struct D : C
{
using C::empty;
};
int
main()
{
if(D().empty); // error expected but got ICE
}
Output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57183
Bug #: 57183
Summary: [C++11]auto and -Wunused-variable
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56699
--- Comment #1 from frankhb1989 at gmail dot com 2013-03-23 16:29:09 UTC ---
Sorry, something was wrong, g++-4.8 on Ubuntu should also reject Case 1 in
fact.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56699
Bug #: 56699
Summary: Failed for sizeof (non-static member) in lambda
expression
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55053
Bug #: 55053
Summary: std::is_explicitly_convertible should be removed
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54216
frankhb1989 at gmail dot com changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54216
Bug #: 54216
Summary: Missing diagnostic for ill-formed anonymous enum
declarations
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53873
Bug #: 53873
Summary: [C++11] strange error message for template overloading
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: trivial
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53872
Bug #: 53872
Summary: [C++11] ADL bug in std::thread
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
100 matches
Mail list logo
