[Bug tree-optimization/80635] [8/9/10 regression] std::optional and bogus -Wmaybe-uninitialized warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #53 from Liu Hao --- For people who are not willing to turn off this warning: This warning may be suppressed by introducing a volatile member in the union that is used as the storage. Using Martin Sebor's testcase, this look likes t

[Bug bootstrap/97124] New: ICE when bootstrapping GCC on x86_64-w64-mingw32

: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- Created attachment 49242 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49242&action=edit build log This happens inside MSYS2 with `makepkg-mingw` [1]. Las

[Bug bootstrap/97124] ICE when bootstrapping GCC on x86_64-w64-mingw32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97124 --- Comment #1 from Liu Hao --- MSYS2 has this patch [1]. Should it be incorporated by GCC somehow? [1] https://github.com/msys2/MINGW-packages/commit/0b2f1460ea3b72aa6cf4f263ace52f61a3470afe

[Bug bootstrap/97124] ICE when bootstrapping GCC on x86_64-w64-mingw32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97124 --- Comment #3 from Liu Hao --- Did you reproduce the ICE when cross-compiling? I suspect no, as the MSYS2 patch contains some twiddling about stack limits and forces static linking of libgcc during bootstrapping, which should not affect cross-c

[Bug bootstrap/97124] ICE when bootstrapping GCC on x86_64-w64-mingw32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97124 --- Comment #5 from Liu Hao --- I didn't keep a copy of the file. It was stage1 xgcc that ICEs, not the host gcc.

[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92190 Liu Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #7 from

[Bug c++/61189] ICE with __builtin_return_address() in noexcept lambda on x86

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61189 Liu Hao changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 Liu Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #21 from

[Bug libstdc++/85670] New: `std::filesystem` does not compile on mingw-w64

: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- Created attachment 44080 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44080&action=edit compiler errors Compiling this simple code using `g++ -std=c++17

[Bug libstdc++/85671] New: Lack of `std::move()` inside `operator/` for `std::filesystem::path`.

Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- In 'bits/fs_path.h' there is ``` /// Append one path to another inline path operator/(const path& __lhs, con

[Bug libstdc++/85671] Lack of `std::move()` inside `operator/` for `std::filesystem::path`.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85671 --- Comment #2 from Liu Hao --- 在 2018/5/7 20:13, redi at gcc dot gnu.org 写道: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85671 > > Jonathan Wakely changed: > > What|Removed |Added > -

[Bug c++/85776] New: ICE when compiling `boost::thread` with `-std=c++11` on mingw-w64

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- Created attachment 44129 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44129&action=edit (though not minimal) testcase Co

[Bug c++/85776] ICE when compiling `boost::thread` with `-std=c++11` on mingw-w64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85776 --- Comment #2 from Liu Hao --- (In reply to Richard Biener from comment #1) > Works for me on x86_64-linux with boost 1.54.0 > > Can you please attach preprocessed source? There is one on . URL:

[Bug c++/85776] ICE when compiling `boost::thread` with `-std=c++11` on mingw-w64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85776 --- Comment #3 from Liu Hao --- Created attachment 44134 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44134&action=edit preprocessed source with GCC 8.1 N.B. This file is very large.

[Bug libstdc++/78870] Support std::filesystem on Windows

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #21 from Liu Hao --- On current branch master [1] and gcc-8-branch the libstdc++fs DLL is not created for x86_64-w64-mingw32. Please re-open. [1] remotes/origin/master 84b3cf31c30 PR target/85832 PR

[Bug libstdc++/78870] Support std::filesystem on Windows

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #22 from Liu Hao --- ``` lh_mouse@lhmouse-pc /e/GitHub/MINGW-packages/mingw-w64-gcc-git $ gcc --version gcc.exe (master HEAD with MCF thread model, built by LH_Mouse.) 9.0.0 20180604 (experimental) Copyright (C) 2018 Free Software Fou

[Bug libstdc++/78870] Support std::filesystem on Windows

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #24 from Liu Hao --- (In reply to Jonathan Wakely from comment #23) > Nothing has been committed for gcc-8-branch so of course it isn't created. > > For trunk, did you read comment 14? Sorry didn't notice it. I started a new build j

[Bug libstdc++/78870] Support std::filesystem on Windows

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #25 from Liu Hao --- Created attachment 44234 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44234&action=edit test results for trunk

[Bug libstdc++/78870] Support std::filesystem on Windows

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #26 from Liu Hao --- Created attachment 44235 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44235&action=edit test results for trunk

[Bug libstdc++/78870] Support std::filesystem on Windows

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870 --- Comment #27 from Liu Hao --- Some tests failed, but despite the failure, all tests compiled now.

[Bug preprocessor/91932] New: #pragma does not silence floating constant overflow warnings

Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- ### Testcase 1: ```c #pragma GCC diagnostic ignored "-Woverflow" double x = 1.0e1; ``` results in ``` prog.cc:2:

[Bug libstdc++/91653] ostream::operator<<(streambuf*) should fail the ostream when write output stream error but not

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91653 Liu Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #5 from

[Bug c++/83562] New: broken destructors of thread_local objects on i686 mingw targets

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- Test program: ```c++ struct cat { cat(){ __builtin_printf("cat(): %p\n", (void *)this); } ~cat(){ __builtin_printf(&qu

[Bug c++/84283] std::map::insert(const_iterator, P&&) now ambiguous with std::map::insert(InputIterator, InputIterator)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84283 Liu Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #1 from

[Bug c++/84283] std::map::insert(const_iterator, P&&) now ambiguous with std::map::insert(InputIterator, InputIterator)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84283 --- Comment #2 from Liu Hao --- Ditto, but even more reduced: -- #include template struct map { template::value>::type> void * insert(void * pos, Pair&& x); template void insert(Iterator first, Iterator last)

[Bug c/86929] New: `-fstack-protector` results in wrong code

Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- Target: *-w64-mingw32 The following program: ``` void test(int n) { char str[50]; } int main(void) { test(42); } ``` , after being compiled with ``` x86_64-w64-mingw32

[Bug c/86929] `-fstack-protector` results in wrong code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86929 --- Comment #2 from Liu Hao --- Oh didn't know it happens on macOS too. I didn't find the duplicate because I searched for 'mingw' only.

[Bug c++/87137] [8/9 Regression] Non-virtual member function increases struct size

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137 --- Comment #9 from Liu Hao --- (In reply to Nathan Sidwell from comment #6) > Created attachment 44623 [details] > patch > > This patch appears to fix the problem It'd be good to (a) confirms it also > passes on MS's compiler With this patch

[Bug lto/87525] infinite loop generated for fread() if enabling -flto and -D_FORTIFY_SOURCE=2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87525 Liu Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #9 from

[Bug c++/87742] New: False warning 'array

ignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- Created attachment 44894 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44894&action=edit reduced testcase using CReduce Compiling the attached source file with `-O2 -Wall` results

[Bug c++/87742] False warning "warning: array subscript 3 is above array bounds of 'const std::type_info* const [3]' "

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87742 Liu Hao changed: What|Removed |Added Attachment #44894|0 |1 is obsolete|

[Bug c++/87987] New: Missed optimization with ranged-for loop on a constexpr array

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- This simple program: ```c++ static constexpr bool table[] = { 1, 0, 0, 1, 1, 0, 1, 0 }; int check() { int sum = 0; for(auto value

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87742 --- Comment #4 from Liu Hao --- In my real-world example, 0) the enclosing function is indeterminately recursive, but there is no infinite loop, and 1) `o` has type `size_t`, which is a compile time constant because it is the index of a type in a

[Bug preprocessor/70936] New: Hard-coded C++ header paths and relocation problem on Windows

Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- The following message is copied from https://gcc.gnu.org/ml/gcc/2016-05/msg3.html ``` This is a cross-post from gcc-help as there

[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936 --- Comment #2 from lh_mouse --- (In reply to Andrew Pinski from comment #1) > I use relocatable directory feature on Linux but I have not tested 6 yet. > This is a driver issue I think ... I was examining gcc/gcc/incpath.c for problems, thoug

[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936 --- Comment #6 from lh_mouse --- (In reply to Jonathan Wakely from comment #4) > Please provide the missing information that https://gcc.gnu.org/bugs/ asks > for, so we know how you configured GCC. The following command shows how gcc has been co

[Bug libstdc++/71298] changes to libstdc++ breaks windows builds

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71298 lh_mouse changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #1 from

[Bug c++/71564] New: label inside a lambda conflicts (?) with another one outside it

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- This code fails to compile with any current version of g++ from 4.7 to 7.0: ``` int main(){ _infinite_retry

[Bug c++/71564] label inside a lambda conflicts (?) with another one outside it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71564 --- Comment #1 from lh_mouse --- clang++ 3.0 seems to have issues dealing with this, but it seems to have been fixed since clang++ 3.1.

[Bug middle-end/50168] __builtin_ctz() and intrinsics __bsr(), __bsf() generate suboptimal code on x86_64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50168 Liu Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #11 from

[Bug web/81894] New: Typo in x86 built-in function list

Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/x86-Built-in-Functions.html#x86-Built-in-Functions says: ``` The following built-in functions are available when -mlzcnt is used. All of them

[Bug libstdc++/77726] On MinGW targets, user-defined `operator delete(void *)` is not called if the sized-deallocation version is not provided in C++14 mode when libstdc++ is linked dynamically

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77726 --- Comment #2 from Liu Hao --- It isn't weired if you know how a Dynamic-Link Library (DLL) on Windows works different than a Shared Object (SO) on Linux. Windows does not have a dynamic linker such as `ld.so` on Linux. Symbols in a DLL are res

[Bug c++/80883] New: Hardcoded null DSO handle parameter to __cxa_thread_atexit() on MinGW-w64 targets

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- It looks like that GCC for MinGW-w64 targets always passes a null DSO handle to `__cxa_thread_atexit()` when registering

[Bug c++/79620] New: decltype() inside a lambda capturing-by-value

++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- The following example copied from the C++17 draft [N4582] fails to compile: void f3() { float x, &r

[Bug target/82858] New: __builtin_add_overflow() generates suboptimal code with unsigned types on x86

: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- The following function: ``` unsigned saturated_add(unsigned a, unsigned b){ unsigned c; if(__builtin_add_overflow(a

[Bug target/82858] __builtin_add_overflow() generates suboptimal code with unsigned types on x86

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82858 --- Comment #2 from Liu Hao --- Trunk on produces the following code: ``` saturated_add(unsigned int, unsigned int): add edi, esi mov eax, -1 cmovnc eax, edi ret ``` Condition moves are however, in my opinion,

[Bug c/83122] New: -Wconversion and shifting bitwise

Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- Minimal testcase: ```c // gcc -c test.c -Wall -Wextra -pedantic -pedantic-errors -std=c99 -Wconversion typedef __UINT64_TYPE__ uint64_t; struct foo { uint64_t a : 3

[Bug c/83122] -Wconversion and shifting bitwise

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83122 --- Comment #2 from Liu Hao --- Yes it is hard to tell whether there is indeed loss of precision. At the moment, the (only?) redictable way to silence the warning is to use a bitwise and operation. That is, `ptr->b = (val >> 3) & (UINT64_MAX >>

[Bug c/83151] New: Explicit unsigned bitfields are treated as signed ones

Component: c Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- Minimal testcase: ```c struct foo { unsigned bf : 6; }; unsigned get(const struct foo *ptr){ return ~ptr->bf; } ``` ``` E:\Desktop>gcc -c test.c -Wall -Wextra

[Bug c/83151] Explicit unsigned bitfields are treated as signed ones

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83151 Liu Hao changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c/83151] Explicit unsigned bitfields are treated as signed ones

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83151 --- Comment #4 from Liu Hao --- I do care about these warnings and that is why these warnings are enabled. However the one in the original post seems nothing but false positive to me. I know what the standard says about integer promotion (when

[Bug target/83210] New: __builtin_mul_overflow() generates suboptimal code when exactly one argument is the constant 2

Keywords: missed-optimization Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- This snippet illustrates the problem: <https://godbolt.or

[Bug target/83210] __builtin_mul_overflow() generates suboptimal code when exactly one argument is the constant 2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83210 --- Comment #1 from Liu Hao --- FWIW, it can still be improved when the constant is something other than 2. For example: ``` bool mul_8_and_check(unsigned *dst, unsigned src){ return __builtin_mul_overflow(src, 8, dst); } ``` can be rewrit

[Bug target/83210] __builtin_mul_overflow() generates suboptimal code when exactly one argument is the constant 2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83210 --- Comment #4 from Liu Hao --- (In reply to Andrew Pinski from comment #2) > (res >> 3) != src; > > Why not just (src>>(sizeof (res)*8-3))!=0. > > Seems shorter and might be faster. What if the second operand is not a power of 2? `(res * 5 /

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881 --- Comment #8 from Liu Hao --- I cannot reproduce this problem on either i686-w64-mingw32 or x86_64-w64-mingw32 with --enable-tls. On line 677 in libgomp.h there is a call to `gomp_thread()` which is supposed to return a pointer to a __thread

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881 --- Comment #10 from Liu Hao --- Compiling this rather simple program using your gcc: ``` __thread int a = 1; int get_a(void){ return a; } ``` resulted in wrong assembly: ``` E:\Desktop\gcc-7.1.0-debug-broken-tls\bin>gcc E:\Desktop\test.c

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881 --- Comment #11 from Liu Hao --- Diff'ing configure options used to build both GCC produces the following result: ``` E:\Desktop>gcc-7.1.0-debug-broken-tls\bin\gcc.exe -v 2>&1 | sed "s/ --/\n&/g" > yours.txt E:\Desktop>gcc -v 2>&1 | sed "s/ --/

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881 --- Comment #13 from Liu Hao --- Native TLS requires essential support from LD, which I don't think is going to be available in foreseeable future. Without native TLS GCC tries to use emulated TLS, and if it generates code attempting to use the

[Bug c++/77601] New: error: cannot convert 'is_same' to 'const bool' in initialization

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- The following code chokes GCC: template struct is_same { constexpr operator bool() const noexcept {

[Bug c++/77601] error: cannot convert 'is_same' to 'const bool' in initialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77601 --- Comment #1 from lh_mouse --- Oops, the last line in `main()` should have been constexpr bool b3 = is_same{}; And as the comment before that line says, it works with g++.

[Bug c++/67273] Incorrect -Wshadow warning with generic lambdas

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67273 lh_mouse changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #1 from

[Bug libstdc++/77726] New: On MinGW targets, user-defined `operator delete(void *)` is not called if the sized-deallocation version is not provided in C++14 mode when libstdc++ is linked dynamically

dynamically Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target

[Bug c++/61189] New: ICE with __builtin_return_address() in noexcept lambda on x86

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Minimal test case: void foo(){ []() noexcept { return __builtin_return_address(0); }(); } Compiled with: E:\Desktop>g++ test.cpp -std=c++1y test.cpp: In lam

[Bug libgcc/61585] New: Subscript-out-of-range in unwind-seh.c?

Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com In file gcc/libgcc/unwind-seh.c, line 69: struct _Unwind_Context { _Unwind_Word cfa; _Unwind_Word ra; _Unwind_Word reg[2]; // ** Defined here. PDISPATCHER_CONTEXT disp; }; /* Get the value of

[Bug rtl-optimization/67449] New: Branch elimination problem on x86

-optimization Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- The following `do ... while` statement creates a loop with two branches: C code: int a[10]; void next(int **pp){ (++*pp == a + 10) && (*pp = 0); }

[Bug rtl-optimization/67449] Branch elimination problem on x86

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67449 lh_mouse changed: What|Removed |Added Severity|minor |trivial

[Bug libstdc++/63959] New: G++ misreports volatile int as trivially copyable

: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com The type trait std::is_trivially_copyable::value yields true on g++ (GCC) 5.0.0 20141119 (experimental). ISO C++ states that volatile types are NOT trivially copyable: N3936 3.9 Types

[Bug c++/61189] ICE with __builtin_return_address() in noexcept lambda on x86

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61189 --- Comment #3 from lh_mouse --- Thanks Kai. It seems to be exactly the same reason that causes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62152. Maybe we should merge them?

[Bug c++/64382] New: ICE due to use of `this` inside a lambda that captures everything by ref inside a member function of a class template

: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com template struct my_queue { void push(T){ } void ice(){ trav([&](auto

[Bug libstdc++/61645] New: forward_list::splice_after shall not throw exceptions

Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com ISO/IEC 14882:2011 23.3.4.6 forward_list operations [forwardlist.ops] void splice_after(const_iterator position, forward_list& x); void splice_after(const_iterator position, forward_

[Bug libstdc++/61645] forward_list::splice_after shall not throw exceptions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61645 --- Comment #2 from lh_mouse --- (In reply to Daniel Krügler from comment #1) > "Throws: Nothing" does not impose the requirement onto implementations that > such a function is required to be marked equivalent to noexcept(true), so > this looks m

[Bug c++/61838] New: ICE on Windows with ctors defined outside class definitions

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Created attachment 33139 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33139&action=edit crashme.cpp A ctor, which takes a parameter of a template class

[Bug c++/62152] New: ICE caused by using __builtin_ia32_pause() inside C++11 noexcept functions on Windows

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com // ice.cpp void foo() noexcept { __builtin_ia32_pause(); // also reproducable with ::_mm_pause(); (requires #include ) } // EOF The

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339 lh_mouse changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #2 from

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339 --- Comment #4 from lh_mouse --- (In reply to Jonathan Wakely from comment #3) > OK, whatever weird definition of leak you are using is irrelevant. The > memory is still in use until the program exits, and there is still a pointer > to it. It is

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339 --- Comment #6 from lh_mouse --- (In reply to Markus Trippelsdorf from comment #5) > (In reply to lh_mouse from comment #4) > > (In reply to Jonathan Wakely from comment #3) > > > OK, whatever weird definition of leak you are using is irrelevant.

[Bug c++/71740] New: ICE when defining a pointer to the `memcpy()` function with namespace scope using `auto` targeting i686

: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- The following code generates an ICE with i686-w64-mingw32-gcc: ** Note: the function `memcpy` is

[Bug c++/71740] ICE when defining a pointer to the `memcpy()` function with namespace scope using `auto` targeting i686

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71740 --- Comment #1 from lh_mouse --- Explicitly specifying __cdecl or __attribute__((__cdecl__)) causes an ICE. Specifying __stdcall or __fastcall, or not specifying one, does not produce an ICE.

[Bug c++/72768] New: Potential bug about the order of destructors of static objects and atexit() callbacks in C++?

Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- Created attachment 39040 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39040&action=edit The test

[Bug c++/72768] Potential bug about the order of destructors of static objects and atexit() callbacks in C++?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72768 --- Comment #2 from lh_mouse --- (In reply to Jonathan Wakely from comment #1) > Arguably the object is not completely initialized until the principal > constructor returns. I doubt it. If an exception is thrown inside the principal ctor which d

[Bug c++/72768] Potential bug about the order of destructors of static objects and atexit() callbacks in C++?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72768 --- Comment #3 from lh_mouse --- > 15.2 Constructors and destructors [except.ctor] > 3 For an object of class type of any storage duration whose initialization or > destruction is terminated by an > exception, the destructor is invoked for each

[Bug c++/72768] Potential bug about the order of destructors of static objects and atexit() callbacks in C++?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72768 --- Comment #6 from lh_mouse --- > But then if the delegating constructor throws you would run the destructor > twice e.g. The `atexit()` callback in question can check the `__cxa_guard` of the object to determine whether it should call the des

[Bug c++/72768] Potential bug about the order of destructors of static objects and atexit() callbacks in C++?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72768 --- Comment #8 from lh_mouse --- (In reply to Jonathan Wakely from comment #7) > It *could* check, but that doesn't mean it should. I was merely stating that the twice-destruction problem wasn't unresolvable. The topic about the C++ standard st

[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461 Liu Hao changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #31 from

[Bug target/90262] Inline small constant memmoves

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90262 --- Comment #3 from Liu Hao --- This exists on x86_64 too: https://gcc.godbolt.org/z/z5MW4E4aE ```c int xcopy(char* dst, const char* src) { __builtin_memmove(dst, src, 32); return dst[0]; } ``` Clang generates this assembly: ```

[Bug c++/100111] New: `-fno-elide-constructors` causes ICE in GCC 10.3

Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- Host: x86_64-linux-gnu Target: x86_64-linux-gnu Created attachment 50610 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50610&acti

[Bug c++/100111] [10/11 Regression] `-fno-elide-constructors` with `constexpr` ctors causes ICE in GCC 10.3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100111 --- Comment #5 from Liu Hao --- Thanks for the patch. I am now starting bootstrapping GCC 10.3.1 on `{i686,x86_64}-w64-mingw32`. Let me see how it goes.

[Bug c++/100111] [10/11 Regression] `-fno-elide-constructors` with `constexpr` ctors causes ICE in GCC 10.3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100111 --- Comment #6 from Liu Hao --- I have bootstrapped GCC 10.3.1 on `i686,x86_64}-w64-mingw32` successfully and verified that this patch fixed the error.

[Bug bootstrap/97124] ICE when bootstrapping GCC on x86_64-w64-mingw32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97124 --- Comment #6 from Liu Hao --- Today I got the same ICE when building mingw-w64. I am not clear why this error only happened with GCC previously.

[Bug bootstrap/97124] ICE when bootstrapping GCC on x86_64-w64-mingw32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97124 Liu Hao changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/83562] broken destructors of thread_local objects on i686 mingw targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562 Liu Hao changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #15 from Liu Hao --- Why did you add me in CC without asking for my acknowledgement? If you had asked MSYS2 people, I am pretty sure you would have received more constructive suggestions.

[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 Liu Hao changed: What|Removed |Added CC|lh_mouse at 126 dot com| --- Comment #20 from Liu Hao --- 0

[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #11 from Liu Hao --- My personally built GCC [1] didn't seem able to reproduce this, using exact the same options. The latest commit from GCC repo was 700dcc60b5646cc64ae3ba72a79a7542b4902b50. Were there any differences when building

[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #14 from Liu Hao --- Created attachment 50259 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50259&action=edit a much simpler testcase Added a much simpler testcase. `xmm6` is set to `123.456`, and an exception is thrown and c

[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #15 from Liu Hao --- Thanks. The 'Final fix' looks good to me. I applied it locally and built GCC. With a debugger, I verified that after the try-catch statement, all non-volatile XMM registers (6-15) had been restored properly. `

[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #18 from Liu Hao --- (In reply to Jakub Jelinek from comment #17) > > That would certainly need : "xmm5" in clobbers (etc.). > And isn't really portable anyway, the compiler can choose to put > anything into %xmm6 in between that and

[Bug bootstrap/100411] New: GCC 11 branch bootstrap ICE on x86_w64-w64-mingw32

Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- (i686-w64-mingw32 succeeded.) /d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/./prev-gcc/xg++ -B/d/lh_mouse/GitHub/MINGW

[Bug target/100411] GCC 11 branch bootstrap ICE on x86_w64-w64-mingw32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100411 --- Comment #2 from Liu Hao --- (In reply to Eric Botcazou from comment #1) > Can you post the configure line? As you wish, but it is very long (I have no idea why they have been there): ``` $ ../gcc/configure --prefix=/mingw64 --with-local-

[Bug target/100411] [11 regression] bootstrap failure on 64-bit Windows with --with-tune=nocona

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100411 --- Comment #6 from Liu Hao --- Thanks for the quick fix. It has resolved this issue on my setup.

  1   2   3   >