[Bug libstdc++/111357] New: __integer_pack fails to work with values of dependent type convertible to integers

2023-09-09 Thread frankhb1989 at gmail dot com via Gcc-bugs
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

[Bug lto/110844] New: LTO sometimes fail with -save-temp -dumpdir options

2023-07-28 Thread frankhb1989 at gmail dot com via Gcc-bugs
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

[Bug libstdc++/103240] std::type_info::before gives wrong answer for ARM EABI

2023-05-05 Thread frankhb1989 at gmail dot com via Gcc-bugs
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't just re

[Bug libstdc++/103240] std::type_info::before gives wrong answer for ARM EABI

2023-05-04 Thread frankhb1989 at gmail dot com via Gcc-bugs
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 partition

[Bug libstdc++/103240] std::type_info::before gives wrong answer for ARM EABI

2023-04-29 Thread frankhb1989 at gmail dot com via Gcc-bugs
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

[Bug libstdc++/103240] std::type_info::before gives wrong answer for ARM EABI

2023-04-29 Thread frankhb1989 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103240 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot

[Bug libstdc++/108771] New: Incorrect noexcept for merging in

2023-02-13 Thread frankhb1989 at gmail dot com via Gcc-bugs
++ 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

[Bug libstdc++/107189] New: Inconsistent range insertion implementations in std::_Rb_tree in

2022-10-08 Thread frankhb1989 at gmail dot com via Gcc-bugs
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

[Bug ipa/101279] Function attributes often block inlining

2022-06-28 Thread frankhb1989 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101279 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot

[Bug libstdc++/104191] Incorrect max_size() for node-based containers

2022-01-25 Thread frankhb1989 at gmail dot com via Gcc-bugs
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 used

[Bug libstdc++/104191] Incorrect max_size() for node-based containers

2022-01-25 Thread frankhb1989 at gmail dot com via Gcc-bugs
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

[Bug libstdc++/104191] New: Incorrect max_size() for node-based containers

2022-01-22 Thread frankhb1989 at gmail dot com via Gcc-bugs
: 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

[Bug target/92137] [ia32] Missing documentation for ia32 builtins

2021-12-21 Thread frankhb1989 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92137 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot

[Bug driver/100937] configure: Add --enable-default-semantic-interposition

2021-11-22 Thread frankhb1989 at gmail dot com via Gcc-bugs
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

[Bug driver/100937] configure: Add --enable-default-semantic-interposition

2021-11-02 Thread frankhb1989 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100937 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot

[Bug libstdc++/100682] New: Outdated manual about the debug mode using

2021-05-19 Thread frankhb1989 at gmail dot com via Gcc-bugs
: 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

[Bug c++/70834] Incorrect warning for placement new when conditionally used

2021-05-18 Thread frankhb1989 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot

[Bug c++/100472] New: [C++17] Wrong template non-type argument handling on function reference to noexcept functions

2021-05-07 Thread frankhb1989 at gmail dot com via Gcc-bugs
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

[Bug libstdc++/97362] [8/9/10 Regression] `__deref` in in debug mode clashes with internal macro in Windows system header

2021-02-17 Thread frankhb1989 at gmail dot com via Gcc-bugs
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

[Bug driver/82955] ICE when using -fdump-passes -fdisable-tree-einline

2020-12-27 Thread frankhb1989 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82955 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot

[Bug libstdc++/97362] `__deref` in in debug mode clashes with internal macro in Windows system header

2020-10-10 Thread frankhb1989 at gmail dot com via Gcc-bugs
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.

[Bug libstdc++/97362] New: __deref in in debug mode clashes with Windows SDK internal macro

2020-10-10 Thread frankhb1989 at gmail dot com via Gcc-bugs
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

[Bug c++/94602] New: wrong semantic check to prvalue as decltype operand

2020-04-15 Thread frankhb1989 at gmail dot com
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

[Bug libstdc++/93470] [9/10 Regression] [C++2a] std::reference_wrapper to function type is broken with Clang

2020-01-27 Thread frankhb1989 at gmail dot com
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're

[Bug libstdc++/93470] [C++2a] std::reference_wrapper to function type is broken

2020-01-27 Thread frankhb1989 at gmail dot com
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

[Bug libstdc++/93470] New: [C++2a] std::reference_wrapper to function type is broken

2020-01-27 Thread frankhb1989 at gmail dot com
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

[Bug c++/89640] [9 Regression] g++ chokes on lambda with __attribute__

2019-11-28 Thread frankhb1989 at gmail dot com
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

[Bug libstdc++/91620] std::[forward_]list::remove_if/unique should respect to DR 526

2019-08-31 Thread frankhb1989 at gmail dot com
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 different

[Bug libstdc++/91620] [forward_]list::remove_if should respect to DR 526

2019-08-30 Thread frankhb1989 at gmail dot com
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.)

[Bug c++/91620] New: [forward_]list::remove_if should respect to DR 529

2019-08-30 Thread frankhb1989 at gmail dot com
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) : i_(i

[Bug libstdc++/91541] [C++17] Exception specification of operator= of node-based containers may be broken

2019-08-27 Thread frankhb1989 at gmail dot com
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 &

[Bug libstdc++/91541] [C++17] Exception specification of operator= of node-based containers may be broken

2019-08-27 Thread frankhb1989 at gmail dot com
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

[Bug libstdc++/91541] [C++17] Exception specification of operator= of node-based containers may be broken

2019-08-27 Thread frankhb1989 at gmail dot com
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't care abo

[Bug libstdc++/91541] [C++17] Exception specification of operator= of node-based containers may be broken

2019-08-26 Thread frankhb1989 at gmail dot com
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

[Bug libstdc++/91541] [C++17] Exception specification of operator= of node-based containers may be broken

2019-08-25 Thread frankhb1989 at gmail dot com
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.

[Bug libstdc++/91541] New: [C++17] Exception specification of operator= of node-based containers may be broken

2019-08-25 Thread frankhb1989 at gmail dot com
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

[Bug libstdc++/91531] New: _Rb_tree's copy assignment should respect to POCCA regardless of is_always_equal

2019-08-23 Thread frankhb1989 at gmail dot com
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, _Val

[Bug libstdc++/91480] Nonconforming definitions of standard library feature-test macros

2019-08-23 Thread frankhb1989 at gmail dot com
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 > >

[Bug libstdc++/91480] Nonconforming definitions of standard library feature-test macros

2019-08-18 Thread frankhb1989 at gmail dot com
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 don't find

[Bug libstdc++/91480] New: Nonconforming definitions of standard library feature-test macros

2019-08-17 Thread frankhb1989 at gmail dot com
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

[Bug c/66970] Add __has_builtin() macro

2019-08-10 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot

[Bug c++/91127] New: Incorrect checking of nonnull attribute with argument to a constructor of class with a virtual base

2019-07-09 Thread frankhb1989 at gmail dot com
: 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

[Bug c++/89640] [9 Regression] g++ chokes on lambda with __attribute__

2019-06-23 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89640 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot

[Bug c++/90966] New: ICE in tsubst_copy, at cp/pt.c:16155

2019-06-23 Thread frankhb1989 at gmail dot com
++ 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]': a.cc:10:9

[Bug c++/87742] [7/8/9 Regression] false warning: array subscript 3 is above array bounds of 'const std::type_info* const [3]'

2019-02-01 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87742 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot

[Bug c++/41958] [c++0x] bogus variadic partial ordering code

2018-11-06 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot

[Bug libstdc++/86954] redundant nothrow in call of ::operator delete

2018-08-14 Thread frankhb1989 at gmail dot com
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 acknowledge

[Bug libstdc++/86954] New: redundant nothrow in call of ::operator delete

2018-08-14 Thread frankhb1989 at gmail dot com
: 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

[Bug libstdc++/86734] New: [DR 2188] reverse_iterator::operator-> does not support overloaded operator

2018-07-30 Thread frankhb1989 at gmail dot com
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 a

[Bug libstdc++/80284] Support of associative containers with incomplete element type

2017-04-03 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80284 frankhb1989 at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug c++/80284] New: Support of associative containers with incomplete element type

2017-04-02 Thread frankhb1989 at gmail dot com
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

[Bug middle-end/17308] nonnull attribute not as useful as it could

2016-11-10 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot

[Bug libstdc++/66339] g++ 5.1.0 Generates memory leak

2016-09-19 Thread frankhb1989 at gmail dot com
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

[Bug libstdc++/66339] g++ 5.1.0 Generates memory leak

2016-09-19 Thread frankhb1989 at gmail dot com
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

[Bug libstdc++/71444] New: Error code on MinGW-w64

2016-06-07 Thread frankhb1989 at gmail dot com
++ 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

[Bug c++/70480] New: Reduce RTTI code bloat for specified types

2016-03-31 Thread frankhb1989 at gmail dot com
: 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 classes

[Bug c++/66339] g++ 5.1.0 Generates memory leak

2016-01-11 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot

[Bug c++/67795] Wrong code generated for conditional expression with cast

2015-10-01 Thread frankhb1989 at gmail dot com
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

[Bug c++/67795] Wrong code generated for conditional expression with cast

2015-10-01 Thread frankhb1989 at gmail dot com
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

[Bug c++/67795] Wrong code generated for conditional expression with cast

2015-10-01 Thread frankhb1989 at gmail dot com
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 'std::forward',

[Bug c++/67795] Wrong code generated for conditional expression with cast

2015-10-01 Thread frankhb1989 at gmail dot com
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)

[Bug c++/67795] New: Wrong code generated for conditional expression with cast

2015-10-01 Thread frankhb1989 at gmail dot com
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

[Bug c++/67795] Wrong code generated for conditional expression with cast

2015-10-01 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67795 frankhb1989 at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED

[Bug c++/67795] Wrong code generated for conditional expression with cast

2015-10-01 Thread frankhb1989 at gmail dot com
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 &

[Bug c/67661] Wrong warning when declare VLAs: operation on 'x' may be undefined [-Wsequence-point]

2015-09-24 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67661 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot

[Bug c/39121] strange behavior in chained operations

2015-08-09 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39121 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot

[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member

2015-05-19 Thread frankhb1989 at gmail dot com
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 means. Testing what? G++? G

[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member

2015-05-18 Thread frankhb1989 at gmail dot com
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. What possible

[Bug c++/65890] New: [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member

2015-04-25 Thread frankhb1989 at gmail dot com
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

[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member

2015-04-25 Thread frankhb1989 at gmail dot com
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.

[Bug c++/65890] [C++03]sizeof(qualified-id) accepted when the operand denotes a non-static member

2015-04-25 Thread frankhb1989 at gmail dot com
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

[Bug c++/65748] [C++11][C++14]Invalid copy elision on operand of throw-exception

2015-04-12 Thread frankhb1989 at gmail dot com
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.

[Bug c++/65748] New: [C++11][C++14]Invalid copy elision on operand of throw-exception

2015-04-12 Thread frankhb1989 at gmail dot com
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; // Not here

[Bug libstdc++/65343] unexpected exception thrown during destruction of static object in debug mode

2015-03-10 Thread frankhb1989 at gmail dot com
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 resources

[Bug libstdc++/65343] New: unexpected exception thrown during destruction of static object in debug mode

2015-03-07 Thread frankhb1989 at gmail dot com
: 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_DEBUG

[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support

2014-10-31 Thread frankhb1989 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot

[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock

2014-09-29 Thread frankhb1989 at gmail dot com
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 chrono #ifdef _GLIBCXX_USE_CLOCK_REALTIME #ifdef

[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock

2014-09-29 Thread frankhb1989 at gmail dot com
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 always true

[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock

2014-09-29 Thread frankhb1989 at gmail dot com
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.)

[Bug libstdc++/63400] New: [C++11]precision of std::high_resolution_clock

2014-09-28 Thread frankhb1989 at gmail dot com
: 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 chrono also says it is with the shortest tick period. However, the current implementation

[Bug c++/61019] New: ICE: incomplete type of class template as pseudo-destructor-name

2014-04-30 Thread frankhb1989 at gmail dot com
Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: frankhb1989 at gmail dot com Case: templateclass struct S { static_assert(((S*)0)-~S(), ); }; Sint b; Result: T:\D:\MinGW\bin\g++.exe a.cc -std=c++11 a.cc

[Bug c++/61019] ICE: incomplete type of class template as pseudo-destructor-name

2014-04-30 Thread frankhb1989 at gmail dot com
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

[Bug c++/60709] New: [C++11]ICE when using a braced-init-list as function argument to initialize a reference to array

2014-03-30 Thread frankhb1989 at gmail dot com
Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: frankhb1989 at gmail dot com Minimal case: templateclass T struct X{}; void f(Xint()[1]) {} int main() { f({Xint()}); } g++ a.cc -std=c++11 a.cc

[Bug c++/59931] New: Wrong wording of diagnostic about imaginary member function type

2014-01-23 Thread frankhb1989 at gmail dot com
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()': a.cc:6:21: error: cannot

[Bug c++/59682] New: Invalid syntax accepted: new-placement without expression-list

2014-01-05 Thread frankhb1989 at gmail dot com
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

[Bug libstdc++/58395] New: Undefined behavior vs. exception

2013-09-11 Thread frankhb1989 at gmail dot com
++ 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

[Bug c++/53402] [C++11] non-inline namespace can be wrongly re-opened as inline

2013-07-14 Thread frankhb1989 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53402 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot

[Bug c++/57444] New: ICE in instantiate_type for invalid use of member with using-declaration

2013-05-28 Thread frankhb1989 at gmail dot com
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

[Bug c++/57183] New: [C++11]auto and -Wunused-variable

2013-05-06 Thread frankhb1989 at gmail dot com
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

[Bug c++/56699] New: Failed for sizeof (non-static member) in lambda expression

2013-03-23 Thread frankhb1989 at gmail dot com
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:

[Bug c++/56699] Failed for sizeof (non-static member) in lambda expression

2013-03-23 Thread frankhb1989 at gmail dot com
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.

[Bug libstdc++/55053] New: std::is_explicitly_convertible should be removed

2012-10-24 Thread frankhb1989 at gmail dot com
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

[Bug c++/54216] New: Missing diagnostic for ill-formed anonymous enum declarations

2012-08-09 Thread frankhb1989 at gmail dot com
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

[Bug c++/54216] Missing diagnostic for ill-formed anonymous enum declarations

2012-08-09 Thread frankhb1989 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54216 frankhb1989 at gmail dot com changed: What|Removed |Added Severity|normal |minor

[Bug libstdc++/53872] New: [C++11] ADL bug in std::thread

2012-07-06 Thread frankhb1989 at gmail dot com
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

[Bug c++/53873] New: [C++11] strange error message for template overloading

2012-07-06 Thread frankhb1989 at gmail dot com
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