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

[lh_mouse at 126 dot com]

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 this:

```
  union {
T t;
char x[sizeof (T)];
volatile char dont_use;   // this silences such warnings.
  };
```

(the `sizeof (T)` thing is unnecessary, as the union will always have correct
size and alignment w/o it.)

Hope it helps.

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97124

Bug ID: 97124
   Summary: ICE when bootstrapping GCC on x86_64-w64-mingw32
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: 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].
Last known working revision should be around 2020-08-26.

Reverting these commits locally did NOT help:

7ad48f0a6b498e4fb89d0ab1208d8e74fe747101
2cbd82044b21679fa533445f373374576f638da1
436ee9fec2751826bc48069d4dd320207fd9dfa4
a41439a06901dfff7c01d2455cb881ff939b57b5



[1]
https://github.com/lhmouse/MINGW-packages/blob/master/mingw-w64-gcc-git/PKGBUILD


```
In file included from
E:/GitHub/MINGW-packages/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/gcc/include/immintrin.h:55,
 from
E:/GitHub/MINGW-packages/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/gcc/include/x86intrin.h:32,
 from
C:/MinGW/MSYS2/mingw64/x86_64-w64-mingw32/include/winnt.h:1555,
 from
C:/MinGW/MSYS2/mingw64/x86_64-w64-mingw32/include/minwindef.h:163,
 from
C:/MinGW/MSYS2/mingw64/x86_64-w64-mingw32/include/windef.h:9,
 from
C:/MinGW/MSYS2/mingw64/x86_64-w64-mingw32/include/windows.h:69,
 from ../../../gcc-git/libgcc/libgcc2.c:2183:
E:/GitHub/MINGW-packages/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/gcc/include/avx512fintrin.h:
In function
'_mm512_mask_reduce_mul_ps':
E:/GitHub/MINGW-packages/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/gcc/include/avx512fintrin.h:15958:3:
internal
compiler error: Segmentation fault
15958 |   __A = _mm512_mask_mov_ps (_mm512_set1_ps (1.0f), __U, __A);
  |   ^~~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc-mcf.lhmouse.com/> for instructions.
make[3]: *** [Makefile:501: _trampoline.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory
'/e/GitHub/MINGW-packages/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libgcc'
make[2]: *** [Makefile:17959: all-stage1-target-libgcc] Error 2
make[2]: Leaving directory
'/e/GitHub/MINGW-packages/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32'
make[1]: *** [Makefile:21867: stage1-bubble] Error 2
make[1]: Leaving directory
'/e/GitHub/MINGW-packages/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32'
make: *** [Makefile:1009: all] Error 2
==> ERROR: A failure occurred in build().
```

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

[lh_mouse at 126 dot com]

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

[lh_mouse at 126 dot com]

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-compiling.

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

[lh_mouse at 126 dot com]

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

[lh_mouse at 126 dot com]

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 Liu Hao  ---
MSDN says 'the upper portions of YMM0-15 and ZMM0-15 are considered volatile
and must be considered destroyed on function calls' explicitly [1].

I am not clear about the cause of OP's ICE, but I think it should conform to
MSABI to emit VZEROUPPER in the epilog, followed by restoring XMM6 - XMM15,
destroying their upper halves. Similar with the prolog.

[1]
https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019#callercallee-saved-registers

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61189

Liu Hao  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Liu Hao  ---
This is confirmed to have been fixed as of GCC 8.2. The exact version is
unknown, however.

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

[lh_mouse at 126 dot com]

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 Liu Hao  ---
This comment could be important:

<https://github.com/Alexpux/MSYS2-packages/issues/1209#issuecomment-379576367>

> mstorsjo commented 10 days ago
> However, this only seems to be an issue when passing such variables by value. 
> Local variables seem to be properly aligned even with GCC:

If the `__m256` in question in the original post was made to pass by reference,
the crash would go away. From the assembly code following that reply we can
also conclude that, it is not the impossibility of realigning the stack during
run time that is the issue (because RSP was aligned in that snippet of code and
I believe that code was correct). It is GCC does not realign the stack at all
that is the issue.

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85670

Bug ID: 85670
   Summary: `std::filesystem` does not compile on mingw-w64
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: 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 test.cc`:

```
#include 

int main() {
std::filesystem::rename(std::filesystem::path("a"),
std::filesystem::path("b"));
}
```
results in a number of errors (attached).

The `no match for 'operator!='` error is caused by inline definition of `path&
operator/=(const path& __p)`, where the `operator!=()` has not been visible.

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85671

Bug ID: 85671
   Summary: Lack of `std::move()` inside `operator/` for
`std::filesystem::path`.
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  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, const path& __rhs)
  { return path(__lhs) /= __rhs; }
```


Isn't this returning a copy of the unnamed object, because `operator/=` returns
an lvalue reference?  

I think the operand of the return statement should be `move(path(__lhs) /=
__rhs)`.

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

[lh_mouse at 126 dot com]

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
> 
>   Status|UNCONFIRMED |ASSIGNED
> Last reconfirmed||2018-05-07
> Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot 
> gnu.org
>   Ever confirmed|0   |1
> 
> --- Comment #1 from Jonathan Wakely  ---
> It would be better to do:
> 
>path __tmp(__lhs);
>__tmp /= __rhs;
>return __tmp;
> 
> That allows a copy to be elided.
> 

There is no difference in implementation as long as NRVO is in effect.

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85776

Bug ID: 85776
   Summary: ICE when compiling `boost::thread` with `-std=c++11`
on mingw-w64
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  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

Compiling the attached program using `-std=c++11` with boost 1.66 results in an
ICE:

```
E:\Desktop>g++ -std=c++11 test.cc
In file included from
C:/MinGW/MSYS2/mingw32/include/boost/thread/detail/thread.hpp:23,
 from
C:/MinGW/MSYS2/mingw32/include/boost/thread/thread_only.hpp:22,
 from
C:/MinGW/MSYS2/mingw32/include/boost/thread/thread.hpp:12,
 from C:/MinGW/MSYS2/mingw32/include/boost/thread.hpp:13,
 from test.cc:1:
C:/MinGW/MSYS2/mingw32/include/boost/thread/detail/invoke.hpp: In function
'decltype (*(forward)(boost::detail::invoke::a0).*boost::detail::invoke::f)
boost::detail::invoke(Fp&&, A0&&) [with Fp = void (A::*)(); A0 = A*]':
C:/MinGW/MSYS2/mingw32/include/boost/thread/detail/invoke.hpp:102:43: internal
compiler error: in gimplify_expr, at gimplify.c:12188
 return (*boost::forward(a0)).*f;
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc-mcf.lhmouse.com/> for instructions.
```

This is confirmed to be the case on 5.4 (native and cross from Linux) and 8.1.1
(native).


Preprocessing the testcase results in such an enormous file (5+ MiB) that
CReduce has been unable to reduce it at all (it resulted in a `}` only, which
was apparently a bug).

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

[lh_mouse at 126 dot com]

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: https://sourceforge.net/p/mingw-w64/bugs/694/attachment/TestClass.ii

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

[lh_mouse at 126 dot com]

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

[lh_mouse at 126 dot com]

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 target/86036 * config/i386/sse.md
(_eq3

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

[lh_mouse at 126 dot com]

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 Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



This is the list of DLLs installed with `make install`:

```
libatomic-1.dll
libgcc_s_seh-1.dll
libgomp-1.dll
libquadmath-0.dll
libssp-0.dll
libstdc++-6.dll
```

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

[lh_mouse at 126 dot com]

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 just now.

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

[lh_mouse at 126 dot com]

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

[lh_mouse at 126 dot com]

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

[lh_mouse at 126 dot com]

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91932

Bug ID: 91932
   Summary: #pragma does not silence floating constant overflow
warnings
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  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:1: warning: floating constant exceeds range of 'double' [-Woverflow]
2 | double x = 1.0e1;
  | ^~
```


### Testcase 2:  <https://wandbox.org/permlink/Qcck5DvbLwOu9Ls3>

```c
#pragma GCC diagnostic ignored "-Woverflow"

#define CONS(a,b)  1.0##e##a##b

int main()
  {
double x = CONS(-,1);
double y = CONS(+,1);
(void)(x+y);
  }
```
results in:
```
prog.cc:7:3: warning: floating constant truncated to zero [-Woverflow]
7 |   double x = CONS(-,1);
  |   ^~
prog.cc:8:3: warning: floating constant exceeds range of 'double' [-Woverflow]
8 |   double y = CONS(+,1);
  |   ^~
```


This overflow/underflow is intended sometimes.

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

[lh_mouse at 126 dot com]

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 Liu Hao  ---
This may be inconsistency (if not necessarily a defect) in the C++ standard,
since both `basic_ostream::{put,write}`, as UnformattedOutputFunctions, set
`badbit` in case of output failure, but `operator<<(basic_streambuf*)` doesn't.
Nevertheless GCC is doing the right thing and conform to all standards.

It should also be noted that if `operator<<(basic_streambuf*)` could not
extract any character, `failbit` is set on the output stream. Thus correct use
of this function requires a loop, as follows:

```
bool copy_stream(std::ostream& os, std::istream& is)
  {
while(os && (is.rdbuf()->sgetc()
 != std::istream::traits_type::eof()))
  os << is.rdbuf();
return !!os;
  }
```

Anyway, it is not a bug in libstdc++.

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562

Bug ID: 83562
   Summary: broken destructors of thread_local objects on i686
mingw targets
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  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("~cat(): %p\n", (void *)this); }
  void meow(){ __builtin_printf("meow(): %p\n", (void *)this); }
};

thread_local cat c;

int main(){
  c.meow();
}
```

Compiling and running this program outputs a garbage pointer inside the dtor:


```plaintext
E:\Desktop>i686-w64-mingw32-g++ test.cpp && a.exe
cat(): 0084177C
meow(): 0084177C
~cat(): 76EC2FED
```

Recompile the original program with `-S -O2` and notice the following assembly
code:

```s
C1:
   .ascii "cat(): %p\12\0"
   .text
   .def___tls_init.part.0; .scl3;  .type   32; .endef
__tls_init.part.0:
   pushl   %ebx
   subl$24, %esp
   movl$___emutls_v.__tls_guard, (%esp)
   call___emutls_get_address
   movb$1, (%eax)
   movl$___emutls_v.c, (%esp)
   call___emutls_get_address
   movl%eax, %ebx
   movl%eax, 4(%esp)
   movl$LC1, (%esp)
   call_printf
   movl$0, 8(%esp)
   movl%ebx, 4(%esp)
   movl$__ZN3catD1Ev, (%esp)
   call___cxa_thread_atexit
   addl$24, %esp
   popl%ebx
   ret
```

GCC emits a call to the destructor of `cat` using `__cxa_thread_atexit()`. This
causes the crash, because `__cxa_thread_atexit()` requires the callback to use
the `__cdecl` calling convention, where its argument is to be pushed onto
stack, while the destructor expects the `__thiscall` calling convention, where
its argument, the implicit `this` pointer, is to be passed via the ECX
register. Hence inside the callback ECX merely gets whatever garbage value that
happens to reside in it.

Reference: https://sourceforge.net/p/mingw-w64/bugs/527/

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

[lh_mouse at 126 dot com]

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 Liu Hao  ---
This is a reduced testcase, which compiles fine using clang++ HEAD:

<https://wandbox.org/permlink/yFf8eAbMWxE5HKUC>


--

#include 

template
struct pair {
F first;
S second;
pair(F, S);
};

template
struct map {
using value_type = pair;
using const_iterator = const value_type *;
using iterator = value_type *;

const_iterator begin() const;
const_iterator end() const;

template::value>::type>
iterator insert(const_iterator pos, Pair&& x);

template
void insert(Iterator first, Iterator last);
};

template
struct map_type_to_map : map {
void add() {
map current_values, values;
current_values.insert(values.begin(), values.end());
}
};

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

[lh_mouse at 126 dot com]

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);
};

template
struct map_type_to_map : map {
void add() {
void * ptr = 0;
map current_values;
current_values.insert(ptr, ptr);
}
};

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86929

Bug ID: 86929
   Summary: `-fstack-protector` results in wrong code
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  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-gcc -fstack-protector -O0 test.c
```

, results in assembly that references the FS segment register

```
test:
pushq   %rbp
.seh_pushreg%rbp
movq%rsp, %rbp
.seh_setframe   %rbp, 0
subq$96, %rsp
.seh_stackalloc 96
.seh_endprologue
movl%ecx, 16(%rbp)
movq%fs:0, %rax
```

, which causes crashes on x64, as on Windows this not the correct way to
reference native thread-local storage. At the moment, GCC should use emutls
instead.

Compiling this program with i686-w64-mingw32-gcc does not results in an
immediate segment fault, but the assembly code still references the GS segment
register, so it is still wrong.

Prior to GCC 8, stack protectors used static, non-thread-local pointers, which
were subject to data races, but didn't result in segment fault for
single-threaded programs.

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

[lh_mouse at 126 dot com]

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

[lh_mouse at 126 dot com]

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 applied, GCC 8.2.1 accepts the testcase, as well as Microsoft
CL 19.15.26726 .

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

[lh_mouse at 126 dot com]

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 Liu Hao  ---
I reproduced this problem on Linux Mint 19 using the last two attachments. This
issue is only reproducible on i686 i.e. after `-m32` is added into FLAGS in the
build script, as I am on an x64 system.

```
lh_mouse@lhmouse-ideapad ~/Desktop $ objdump -dMintel-mneomic libFLAC.so.8.3.0 
| grep -F 'fread.constprop.5'
2530 :
2530:   eb fe   jmp2530 
2c4e:   e8 dd f8 ff ff  call   2530 
8204:   e8 27 a3 ff ff  call   2530 
8b4e:   e8 dd 99 ff ff  call   2530 
lh_mouse@lhmouse-ideapad ~/Desktop $ gcc --version
gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

lh_mouse@lhmouse-ideapad ~/Desktop $ 
```

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87742

Bug ID: 87742
   Summary: False warning 'array
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: 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 in a warning about
array subscript out of bound:

```
lh_mouse@lhmouse-ideapad ~/Desktop $ g++-7 test.cpp  -O2 -Wall -c -o /dev/null
test.cpp: In member function ‘void H::w() const’:
test.cpp:35:45: warning: array subscript is above array bounds [-Warray-bounds]
   const type_info &m_fn3() const { return *b[o]; }
~^
lh_mouse@lhmouse-ideapad ~/Desktop $ g++-8 test.cpp  -O2 -Wall -c -o /dev/null
test.cpp:25:32: warning: unnecessary parentheses in declaration of ‘b’
[-Wparentheses]
   static const type_info *const(b[]);
^
test.cpp:48:48: warning: unnecessary parentheses in declaration of ‘b’
[-Wparentheses]
 template  const type_info *const(F::b[]){&typeid(l)...};
^
test.cpp: In member function ‘void H::w() const’:
test.cpp:35:45: warning: array subscript 3 is above array bounds of ‘const
std::type_info* const [3]’ [-Warray-bounds]
   const type_info &m_fn3() const { return *b[o]; }
~^
```

(<https://wandbox.org/permlink/tv83ODDn9mWNhjvZ> for an online version.)

but in the context where `o` is used, it is expected to have a value of 2
instead of 3, so the out-of-bound access shouldn't happen.

Original (unreduced) code is at
<https://github.com/lhmouse/asteria/blob/c44081129943334baee36287378a0227edba9fd7/asteria/src/value.cpp#L292>.
The out-of-bound access is reported at
<https://github.com/lhmouse/asteria/blob/c44081129943334baee36287378a0227edba9fd7/asteria/src/rocket/variant.hpp#L330>.

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87742

Liu Hao  changed:

   What|Removed |Added

  Attachment #44894|0   |1
is obsolete||

--- Comment #1 from Liu Hao  ---
Created attachment 44895
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44895&action=edit
manually reduced and formatted source without `std::type_info`

Updated testcase to get rid of `std::type_info` and re-formatted it a little.

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87987

Bug ID: 87987
   Summary: Missed optimization with ranged-for loop on a
constexpr array
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  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 : table) {
  sum += value;
}
return sum;
  }
```

after being compiled by GCC 8.2 with `-std=c++11 -O2 -Wall -Wextra -Wpedantic
-Werror`, yields a loop:

```asm
check():
mov edx, OFFSET FLAT:table
xor eax, eax
.L2:
movzx   ecx, BYTE PTR [rdx]
add rdx, 1
add eax, ecx
cmp rdx, OFFSET FLAT:table+8
jne .L2
ret
```

, while Clang 6.0 optimizes the body to a constant:

```asm
check():  # @check()
mov eax, 4
ret
```

( Online comparison can be viewed here:  https://gcc.godbolt.org/z/oaSr6j )

Making the function `constexpr` however overcomes this obstacle:
```c++
static constexpr bool table[] = { 1, 0, 0, 1, 1, 0, 1, 0 };

// This requires only C++11.
constexpr int check_constexpr(const bool *p, int n)
  {
return (n == 0) ? 0 : *p + check_constexpr(p + 1, n - 1);
  }

int check()
  {
return check_constexpr(table, sizeof(table));
  }
```

( And here is the online comparison for this one:
https://gcc.godbolt.org/z/HZjBSh )

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

[lh_mouse at 126 dot com]

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 parameter pack;  because the number of elements in the
array is the `sizeof...` the parameter pack, in no case will it be out of
bound.

BTW the cast there is not to `unsigned char` but to an enum whose underlying
type is `unsigned char`. Using a wider integer type for it might resolve the
problem. Your information is invaluable.

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936

Bug ID: 70936
   Summary: Hard-coded C++ header paths and relocation problem on
Windows
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  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 haven't been any replies on
gcc-help since two days ago. Hope someone could help.
```

I have built GCC from gcc-6-branch in MSYS2 with mingw-w64 CRT on Windows
today.
Now I have a relocation problem:

Assuming mingw-w64 headers are located in the follow directory,which is, the
native_system_header_dir:
> C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/include
I have built GCC and it has that hard-coded path.
When I compile something using g++ -v, the headers are searched in the
following paths:
```
ignoring nonexistent directory "/mingw32/include"
ignoring duplicate directory "C:/MinGW/MSYS2/mingw32/i686-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 C:/MinGW/MSYS2/mingw32/include/c++/6.1.1
 C:/MinGW/MSYS2/mingw32/include/c++/6.1.1/i686-w64-mingw32
 C:/MinGW/MSYS2/mingw32/include/c++/6.1.1/backward
 C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/include
 C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/../../../../include
 C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/include-fixed

C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/../../../../i686-w64-mingw32/include
End of search list.
```
The C++ headers are searched before any mingw-w64 headers, which is just fine.

However, if I move gcc to another directory, let's say,
C:/this_is_a_new_directory/mingw32/,
then re-compile the same program with g++ -v, the headers are searched in the
following paths:
```
ignoring duplicate directory
"C:/this_is_a_new_directory/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.1.1/include"
ignoring nonexistent directory "C:/MinGW/MSYS2/mingw32/include"
ignoring nonexistent directory "/mingw32/include"
ignoring duplicate directory
"C:/this_is_a_new_directory/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.1.1/include-fixed"
ignoring duplicate directory
"C:/this_is_a_new_directory/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.1.1/../../../../i686-w64-mingw32/include"
ignoring nonexistent directory
"C:/MinGW/MSYS2/mingw32/i686-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:

C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/include

C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/../../../../include

C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/include-fixed

C:/this_is_a_new_directory/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/../../../../i686-w64-mingw32/include
 C:/this_is_a_new_directory/mingw32/lib/gcc/../../include/c++/6.1.1

C:/this_is_a_new_directory/mingw32/lib/gcc/../../include/c++/6.1.1/i686-w64-mingw32
 C:/this_is_a_new_directory/mingw32/lib/gcc/../../include/c++/6.1.1/backward
End of search list.
```
This time the C++ headers are searched after mingw-w64 headers, which causes
the following error:
```
In file included from
C:/MinGW/mingw32/include/c++/6.1.1/ext/string_conversions.h:41:0,
 from
C:/MinGW/mingw32/include/c++/6.1.1/bits/basic_string.h:5402,
 from C:/MinGW/mingw32/include/c++/6.1.1/string:52,
 from
C:/MinGW/mingw32/include/c++/6.1.1/bits/locale_classes.h:40,
 from C:/MinGW/mingw32/include/c++/6.1.1/bits/ios_base.h:41,
 from C:/MinGW/mingw32/include/c++/6.1.1/ios:42,
 from C:/MinGW/mingw32/include/c++/6.1.1/ostream:38,
 from C:/MinGW/mingw32/include/c++/6.1.1/iostream:39,
 from test.cpp:1:
C:/MinGW/mingw32/include/c++/6.1.1/cstdlib:75:25: fatal error: stdlib.h: No
such file or directory
 #include_next 
 ^
compilation terminated.
```

Do you know how to solve this problem (modifications to gcc source code are
expected)?
Thanks in advance.



--
Best regards,
lh_mouse
2016-05-02

I made some investigation yesterday and here is the result:
```

Diff'ing gcc/libstdc++-v3/include/c_global/cstdlib from gcc-5-branch and
gcc-6-branch gives the following result:
(git diff gcc-5-branch gcc-6-branch -- libstdc++-v3/include/c_global/cstdlib)
```
@@ -69,7 +69,11 @@ namespace std

 #else

-#include 
+// Need to ensure this finds the C library's  not a libstdc++
+// wrapper that might already be installed later in the include sea

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

[lh_mouse at 126 dot com]

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, though failed to find any, I
think it is worthing mentioning that '-iprefix this_directory_need_not_exist/'
effectively vanished the problem - that is, the order of C and C++ include
paths became correct again.

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

[lh_mouse at 126 dot com]

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 configured:
```
E:\>i686-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.1.1/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc/configure --prefix=/mingw32
--with-local-prefix=/mingw32/local --build=i686-w64-mingw32
--host=i686-w64-mingw32 --target=i686-w64-mingw32
--with-native-system-header-dir=/mingw
32/i686-w64-mingw32/include --libexecdir=/mingw32/lib
--with-gxx-include-dir=/mingw32/include/c++/6.1.1 --enable-bootstrap
--with-arch=i686 --with-tune=generic --enable-languages=c,lto,c++ --enable-sh
ared --enable-static --enable-libatomic --enable-threads=mcf --enable-graphite
--enable-fully-dynamic-string --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-vers
ion-specific-runtime-libs --disable-isl-version-check --enable-lto
--enable-libgomp --disable-multilib --enable-checking=release --disable-rpath
--disable-win32-registry --disable-nls --disable-werror
 --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw32
--with-mpfr=/mingw32 --with-mpc=/mingw32 --with-isl=/mingw32
--with-pkgversion='gcc-6-branch HEAD with MCF thread model, built
 by LH_Mouse.' --with-bugurl=http://cpp.ra2diy.com/ --with-gnu-as --with-gnu-ld
--disable-tls --disable-sjlj-exceptions --with-dwarf2
Thread model: mcf
gcc version 6.1.1 20160511 (gcc-6-branch HEAD with MCF thread model, built by
LH_Mouse.)
```



A minimal testcase with a relocated toolchain is:
```
LH_Mouse@LH-PC  /mingw32/bin
$ echo '#include ' | g++ -v -x c++ -
Using built-in specs.
COLLECT_GCC=C:\new_directory\MSYS2\mingw32\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/new_directory/MSYS2/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc/configure --prefix=/mingw32
--with-local-prefix=/mingw32/local --build=i686-w64-mingw32
--host=i686-w64-mingw32 --target=i686-w64-mingw32
--with-native-system-header-dir=/mingw
32/i686-w64-mingw32/include --libexecdir=/mingw32/lib
--with-gxx-include-dir=/mingw32/include/c++/6.1.1 --enable-bootstrap
--with-arch=i686 --with-tune=generic --enable-languages=c,lto,c++ --enable-sh
ared --enable-static --enable-libatomic --enable-threads=mcf --enable-graphite
--enable-fully-dynamic-string --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-vers
ion-specific-runtime-libs --disable-isl-version-check --enable-lto
--enable-libgomp --disable-multilib --enable-checking=release --disable-rpath
--disable-win32-registry --disable-nls --disable-werror
 --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw32
--with-mpfr=/mingw32 --with-mpc=/mingw32 --with-isl=/mingw32
--with-pkgversion='gcc-6-branch HEAD with MCF thread model, built
 by LH_Mouse.' --with-bugurl=http://cpp.ra2diy.com/ --with-gnu-as --with-gnu-ld
--disable-tls --disable-sjlj-exceptions --with-dwarf2
Thread model: mcf
gcc version 6.1.1 20160511 (gcc-6-branch HEAD with MCF thread model, built by
LH_Mouse.)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=i686'

C:/new_directory/MSYS2/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/cc1plus.exe
-quiet -v -iprefix
C:/new_directory/MSYS2/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/
-U_REENTRANT - -quiet -dumpba
se - -mtune=generic -march=i686 -auxbase - -version -o
C:\Users\LH_Mouse\AppData\Local\Temp\ccUWITfc.s
GNU C++14 (gcc-6-branch HEAD with MCF thread model, built by LH_Mouse.) version
6.1.1 20160511 (i686-w64-mingw32)
compiled by GNU C version 6.1.1 20160511, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory
"C:/new_directory/MSYS2/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.1.1/include"
ignoring nonexistent directory "C:/MinGW/MSYS2/mingw32/include"
ignoring nonexistent directory "/mingw32/include"
ignoring duplicate directory
"C:/new_directory/MSYS2/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.1.1/include-fixed"
ignoring duplicate directory
"C:/new_directory/MSYS2/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/6.1.1/../../../../i686-w64-mingw32/include"
ignoring nonexistent directory
"C:/MinGW/MSYS2/mingw32/i686-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 C:/new_directory/MSYS2/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/include

C:/new_directory/MSYS2/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/../../../../include

C:/new_directory/MSYS2/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/include-fixed

C:/new_directory/MSYS2/mingw32/bin/../lib/gcc/i686-w64-mingw32/6.1.1/../.

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

[lh_mouse at 126 dot com]

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 lh_mouse  ---
It might be a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936 .

And see some discussion here:
https://github.com/Alexpux/MINGW-packages/pull/1437

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71564

Bug ID: 71564
   Summary: label inside a lambda conflicts (?) with another one
outside it
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  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:
[=]{
_infinite_retry:
goto _infinite_retry; // go to the second _infinite_retry.
}();
goto _infinite_retry; // go to the first _infinite_retry.
}
```

D:\Desktop>g++ test.cpp -Wall
test.cpp: In function 'int main()':
test.cpp:2:2: warning: label '_infinite_retry' defined but not used
[-Wunused-label]
  _infinite_retry:
  ^~~
test.cpp:7:8: error: label '_infinite_retry' used but not defined
   goto _infinite_retry; // go to the outer _infinite_retry.
^~~


Quoting from the standard:
```
ISO/IEC WG21 N4582 

5.1.2 Lambda expressions [expr.prim.lambda]
8 The lambda-expression’s compound-statement yields the function-body (8.4) of
the function call operator, ...

3.3.5 Function scope [basic.funscope]
1 Labels (6.1) have function scope and may be used anywhere in the function in
which they are declared. Only
labels have function scope.
```

The compound statement of a lambda expression is a function body thus it
creates a function scope. The second label should reside in that scope but
somehow nullifies the first one, causing the second goto statement to fail to
find the first label.

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

[lh_mouse at 126 dot com]

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

[lh_mouse at 126 dot com]

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 Liu Hao  ---
I think it is okay to zero-extend the result (which is a no-op, because on x64,
writing to the lower 32 bits of a GPR zeroes its upper 32 bits implicitly,
except the `NOP` instruction which is actually encoded as `XCHG EAX, EAX`),
because sign-extending an _undefined_ result doesn't produce a defined result
after all.

Clang generates the optimal code, as follows:

source:
```c
unsigned long long my_ctz(unsigned n){
return (unsigned)__builtin_ctz(n);
}
```

clang 4.0.0 with `-O3`:
```
my_ctz(unsigned int):
bsfl%edi, %eax
retq
```

gcc 7.1 with `-O3`:
```
my_ctz(unsigned int):
xorl%eax, %eax
rep bsfl%edi, %eax
cltq   # This conversion from `int` to `unsigned long long` is
redundent.
ret
```

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81894

Bug ID: 81894
   Summary: Typo in x86 built-in function list
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  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 generate the machine instruction that is part of the name.

unsigned short __builtin_ia32_lzcnt_16(unsigned short);
unsigned int __builtin_ia32_lzcnt_u32(unsigned int);
unsigned long long __builtin_ia32_lzcnt_u64 (unsigned long long);
```

The first function `__builtin_ia32_lzcnt_16()` doesn't exist. It is
`__builtin_ia32_lzcnt_u16()` that exists.

[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

[lh_mouse at 126 dot com]

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 resolved at build-time, in contrary to Linux, where symbols in a SO are
resolved at load-time. The DLL loader can resolve symbols to addresses, but it
isn't as powerful as linkers after all. Consequently, an executable cannot use
its strong symbols to override already-resolved weak ones in a DLL.

If the user does not define a sized deallocation function, the default one in
libstdc++*.dll is used, which calls the weak, default, non-sized deallocation
function in the same DLL, which is the only candidate when the DLL is built and
can't be overridden.

Possible solution:
The default sized deallocation function should not call the non-sized one
directly. We may introduce a static pointer-to-function which points to the
non-sized one initially. The default sized deallocation function should read
that pointer then call the function it points to. An executable that defines a
non-sized deallocation function should modify that pointer to point to the
user-provided non-sized deallocation function before any other code that may
allocate dynamic memory, possibly via an implicitly generated __constructor__
with high priority.

Question:
What will happen if both the executable and another DLL try to replace the
non-sized deallocation function?
It looks to me that on Linux such scenario will end up in multiple definitions.
In this case abort() or std::terminate() is possibly solution.

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80883

Bug ID: 80883
   Summary: Hardcoded null DSO handle parameter to
__cxa_thread_atexit() on MinGW-w64 targets
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  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 destructors for objects with thread
storage duration. This violates Itanium ABI apparently, doesn't it?
The `__cxa_thread_atexit()` function calls `GetModuleHandleExW()` to obtain a
DLL handle from the function that will be called, which isn't reliable at all,
because when we have `thread_local std::string s; s = "hello";` the first
parameter actually points to `std::string::~basic_string` which is in
libstdc++.
The destructor is then called only when libstdc++ is unloaded, but it should
have been called when the DLL that contains that thread_local definition is
unloaded.


Testcase:
(This can be found http://paste.ubuntu.com/24657853/ at the moment.)
-
E:\Desktop>cat test.cc
#include 

extern "C" int __stdcall DllMain(void *hInstance, void *, unsigned long
dwReason, void *pReserved){
thread_local std::string s;
s = "hello";
return 1;
}

E:\Desktop>g++ test.cc -std=c++11 -O3 -shared -S

E:\Desktop>cat test.s
.file   "test.cc"
.section .rdata,"dr"
.LC0:
.ascii "hello\0"
.text
.globl  DllMain
.defDllMain;.scl2;  .type   32; .endef
.seh_proc   DllMain
DllMain:
.LFB1041:
pushq   %rsi
.seh_pushreg%rsi
pushq   %rbx
.seh_pushreg%rbx
subq$56, %rsp
.seh_stackalloc 56
.seh_endprologue
leaq__emutls_v._ZGVZ7DllMainE1s(%rip), %rcx
call__emutls_get_address
movq%rax, %rsi
leaq__emutls_v._ZZ7DllMainE1s(%rip), %rcx
call__emutls_get_address
movq%rax, %rbx
cmpb$0, (%rsi)
jne .L2
leaq16(%rax), %rax
movq%rax, (%rbx)
movq$0, 8(%rbx)
movb$0, 16(%rbx)
movb$1, (%rsi)
xorl%r8d, %r8d
movq%rbx, %rdx
leaq   
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev(%rip), %rcx
call__cxa_thread_atexit
.L2:
movq8(%rbx), %r8
movq$5, 32(%rsp)
leaq.LC0(%rip), %r9
xorl%edx, %edx
movq%rbx, %rcx
call   
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEyyPKcy
movl$1, %eax
addq$56, %rsp
popq%rbx
popq%rsi
ret
.seh_endproc
.data
.align 32
__emutls_v._ZZ7DllMainE1s:
.quad   32
.quad   8
.quad   0
.quad   0
.align 32
__emutls_v._ZGVZ7DllMainE1s:
.quad   8
.quad   8
.quad   0
.quad   0
.ident  "GCC: (gcc-7-branch HEAD with MCF thread model, built by
LH_Mouse.) 7.1.1 20170518"
.def__emutls_get_address;   .scl2;  .type   32; .endef
.def_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev; 
.scl2;  .type   32; .endef
.def__cxa_thread_atexit;.scl2;  .type   32; .endef
.def   
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEyyPKcy;  
.scl2;  .type   32; .endef
.section   
.rdata$.refptr._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev, "dr"
.globl 
.refptr._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev
.linkonce   discard
.refptr._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev:
.quad   _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev

E:\Desktop>gcc --version
gcc (gcc-7-branch HEAD with MCF thread model, built by LH_Mouse.) 7.1.1
20170518
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


E:\Desktop>
-
In the case of Windows x64 ABI the first four parameters are passed in
RCX/XMM0, RDX/XMM1, R8/XMM2 and R9/XMM3, respectively.
The third parameter (DSO handle) is R8 and here it is apparently set to zero on
line #43.

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79620

Bug ID: 79620
   Summary: decltype() inside a lambda capturing-by-value
   Product: gcc
   Version: 6.3.1
Status: 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 example copied from the C++17 draft [N4582] fails to compile:


void f3() {
float x, &r = x;
[=] {   // x and r are not captured (appearance in a
decltype operand is not an odr-use)
decltype(x) y1; // y1 has type float
decltype((x)) y2 = y1;  // y2 has type float const& because this lambda
// is not mutable and x is an lvalue
decltype(r) r1 = y1;// r1 has type float& (transformation not
considered)
decltype((r)) r2 = y2;  // r2 has type float const&
};
}


E:\Desktop>g++ -pedantic -pedantic-errors -std=c++14 test.cpp
test.cpp: In lambda function:
test.cpp:8:22: error: binding 'const float' to reference of type 'float&'
discards qualifiers
   decltype((r)) r2 = y2;  // r2 has type float const&
  ^~

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82858

Bug ID: 82858
   Summary: __builtin_add_overflow() generates suboptimal code
with unsigned types on x86
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: 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, b, &c)){
return -1;
}
return c;
}
```

, after being compiled with `gcc -O3 -Wall -Wextra -pedantic -pedantic-errors
-masm=intel`, results in:

```
saturated_add(unsigned int, unsigned int):
  add edi, esi
  jc .L3
  mov eax, edi
  ret
.L3:
  or eax, -1
  ret
```

This is suboptimal, as the branch can be simply eliminated as follows:

```
saturated_add(unsigned int, unsigned int):
  add edi, esi
  sbb eax, eax  // EAX = -1 if CF is set and 0 otherwise.
  or eax, edi
  ret
```

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

[lh_mouse at 126 dot com]

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, nothing better than branches, or
they could be something worse: 

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83122

Bug ID: 83122
   Summary: -Wconversion and shifting bitwise
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  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;
uint64_t b : 61;
};

void set_a(struct foo *ptr, uint64_t val){
ptr->b = val >> 3;
}
```


The program above results in a warning about loss of precision:

```
test.c: In function 'set_a':
test.c:11:11: warning: conversion to 'long long unsigned int:61' from 'uint64_t
{aka long long unsigned int}' may alter its value [-Wconversion]
  ptr->b = val >> 3;
   ^~~
```

This is a false positive since the 3 MSBs of `val` are filled with zeroes.

In reality, the warning persists even after I replace `val >> 3` with `val >>
63`.

[Bug c/83122] -Wconversion and shifting bitwise

[lh_mouse at 126 dot com]

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 >> 3)`.

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83151

Bug ID: 83151
   Summary: Explicit unsigned bitfields are treated as signed ones
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 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 -Wsign-conversion -Werror
test.c: In function 'get':
test.c:6:10: error: conversion to 'unsigned int' from 'int' may change the sign
of the result [-Werror=sign-conversion]
   return ~ptr->bf;
  ^~~~
cc1.exe: all warnings being treated as errors
```


GCC manual says

> -fsigned-bitfields
> -funsigned-bitfields
> -fno-signed-bitfields
> -fno-unsigned-bitfields
>   These options control whether a bit-feld is signed or unsigned, when the 
> declaration does not use either signed or unsigned. By default, such a 
> bit-feld is
>   signed, because this is consistent: the basic integer types such as int are 
> signed
>   types.

but it looks certainly incorrect if an explicit `unsigned` is specified.

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83151

Liu Hao  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Liu Hao  ---
Oh sorry for forgetting about that. I will close this PR.

BTW, despite the viability of silence the warning with a cast, will the warning
eventually go away? The promoted `int` will have its vacuum bits filled with
zeroes so there is no loss of information as if it were promoted to `unsigned`.

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

[lh_mouse at 126 dot com]

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 used as an
arithmetic operand, any bit-field with type `int`, `unsigned` or `_Bool` will
be promoted to `int` if `int` is capable of representing all of its values
possible, and to `unsigned` otherwise). The conversion from signed types to
unsigned types are clearly implementation-defined, but according to GCC manual
"GCC supports only two’s complement integer types, and all bit patterns are
ordinary values" so conversion from unsigned types to their signed counterparts
is no-op.

No doubt adding casts would mute the warning, but sometimes it is not possible
e.g. in a compound assignment expression:

```
void set_mask(uint8_t * mask, uint8_t to_rm, uint8_t to_add){
  *mask &= ~to_rm; // This leads to a warning about conversion from `int` to
`uint8_t`.
  *mask |= to_add; // There is no warning because GCC knows the upper bits are
out of interest.
}
```

These assignment expressions have to be rewritten to use the non-compound form:

```
void set_mask(uint8_t * mask, uint8_t to_rm, uint8_t to_add){
  *mask = (uint8_t)((*mask & ~to_rm) | to_add);
}
```
, being longer, more complex, thus harder to maintain.


I believe it can still be improved, since promotion from `uint8_t` to `int`
brings in bit zeroes. The higher bits can't be set to bit ones by bitwise
and'ing with anything, hence the waring is a false positive.

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83210

Bug ID: 83210
   Summary: __builtin_mul_overflow() generates suboptimal code
when exactly one argument is the constant 2
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  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.org/g/TssrYv>

```
bool mul_and_check(unsigned *dst, unsigned src){
return __builtin_mul_overflow(src, 2, dst);
}
```

With `g++ -O3`, this compiles to:

```
mul_and_check(unsigned int*, unsigned int):
  mov eax, esi
  mov edx, 2
  xor ecx, ecx
  mul edx
  mov esi, eax
  jo .L5
.L2:
  mov eax, ecx
  mov DWORD PTR [rdi], esi
  and eax, 1
  ret
.L5:
  mov ecx, 1
  jmp .L2
```

This is very suboptimal. GCC could have used a bitwise shift operation instead,
as follows:

```
mul_and_check(unsigned int*, unsigned int):
  xor eax, eax # EAX  = 0
  shl esi, 1   # CF   = MSB(src)
   # src  = src * 2;
  rol eax, 1   # EAX  = CF
  mov dword ptr[rdi], esi  # *dst = src
  ret
```

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

[lh_mouse at 126 dot com]

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 rewritten as:

bool mul_8_and_check(unsigned *dst, unsigned src){
unsigned res = src << 3;
*dst = res;
return (res >> 3) != src; // The result will have been truncated if
  // dividing the result by 8 does not yield
  // the original value.
}
```

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

[lh_mouse at 126 dot com]

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 / 5 != src)` will
always work, but bitwise shifting might not.

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

[lh_mouse at 126 dot com]

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 object. However, from your first post, it is
weird that for i686 GCC generates code referring the GS segment register, since
GS is unused by x86 Windows.

On x86 Windows, TLS is indirected from the FS register. It is Microsoft's
rocket science, hence GCC still relies on the emutls solution. The GS register
is known to be utilized by x64 Windows and Linux AFAICT.

I presume that your GCC generated Linux code for Windows targets. If you are
cross-compiling for example it may becaused by GCC scripts mistaking the host
for the build. This still requires investigation.

Reference: 

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

[lh_mouse at 126 dot com]

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 -S -masm=intel
-O2 -o -
.file   "test.c"
.intel_syntax noprefix
.text
.p2align 4,,15
.globl  get_a
.defget_a;  .scl2;  .type   32; .endef
.seh_proc   get_a
get_a:
.seh_endprologue
mov rax, QWORD PTR fs:0
mov eax, DWORD PTR a@tpoff[rax]
ret
.seh_endproc
.globl  a
.data
.align 4
a:
.long   1
.ident  "GCC: (GNU) 7.1.0"
```

With my working GCC it resulted in:

```
E:\Desktop>gcc E:\Desktop\test.c -S -masm=intel -O2 -o -
.file   "test.c"
.intel_syntax noprefix
.text
.globl  get_a
.defget_a;  .scl2;  .type   32; .endef
.seh_proc   get_a
get_a:
sub rsp, 40
.seh_stackalloc 40
.seh_endprologue
lea rcx, __emutls_v.a[rip]
call__emutls_get_address
mov eax, DWORD PTR [rax]
add rsp, 40
ret
.seh_endproc
.section .rdata,"dr"
.align 4
__emutls_t.a:
.long   1
.globl  __emutls_v.a
.data
.align 32
__emutls_v.a:
.quad   4
.quad   4
.quad   0
.quad   __emutls_t.a
.ident  "GCC: (gcc-7-branch HEAD with MCF thread model, built by
LH_Mouse.) 7.2.1 20171119"
.def__emutls_get_address;   .scl2;  .type   32; .endef
```

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

[lh_mouse at 126 dot com]

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/ --/\n&/g" > mine.txt

E:\Desktop>gcc-7.1.0-debug-broken-tls\bin\gcc.exe -v 2>&1 | sed "s/ --/\n&/g" >
yours.txt

E:\Desktop>diff --color -U1 mine.txt yours.txt
--- mine.txt2017-11-30 09:42:33.612869600 +0800
+++ yours.txt   2017-11-30 09:42:35.493977200 +0800
@@ -1,47 +1,35 @@
 Using built-in specs.
-COLLECT_GCC=gcc
-COLLECT_LTO_WRAPPER=C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/7.2.1/lto-wrapper.exe
+COLLECT_GCC=gcc-7.1.0-debug-broken-tls\bin\gcc.exe
+COLLECT_LTO_WRAPPER=e:/desktop/gcc-7.1.0-debug-broken-tls/bin/../libexec/gcc/x86_64-w64-mingw32/7.1.0/lto-wrapper.exe
 Target: x86_64-w64-mingw32
-Configured with: ../gcc/configure
- --prefix=/mingw64
- --with-local-prefix=/mingw64/local
- --build=x86_64-w64-mingw32
+Configured with: ../../src/gcc-7.1.0/configure
  --host=x86_64-w64-mingw32
- --target=x86_64-w64-mingw32
- --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
- --libexecdir=/mingw64/lib
- --enable-bootstrap
- --with-arch=x86-64
- --with-tune=nocona
- --enable-languages=c,lto,c++
- --enable-shared
+ --enable-languages=c,c++
+ --enable-seh-exceptions
+ --enable-threads=posix
+ --enable-tls
+ --disable-nls
+ --disable-shared
  --enable-static
- --enable-threads=mcf
- --enable-graphite
  --enable-fully-dynamic-string
- --enable-libstdcxx-time=yes
- --disable-libstdcxx-pch
- --disable-libstdcxx-debug
- --disable-isl-version-check
  --enable-lto
+ --enable-plugins
  --enable-libgomp
- --disable-multilib
- --enable-checking=release
- --disable-rpath
+ --with-dwarf2
  --disable-win32-registry
- --enable-nls
- --disable-werror
- --disable-symvers
- --with-libiconv
- --with-system-zlib
- --with-gmp=/mingw64
- --with-mpfr=/mingw64
- --with-mpc=/mingw64
- --with-isl=/mingw64
- --with-pkgversion='gcc-7-branch HEAD with MCF thread model, built by
LH_Mouse.'
- --with-bugurl=https://gcc-mcf.lhmouse.com/
- --with-gnu-as
- --with-gnu-ld
- --disable-tls
-Thread model: mcf
-gcc version 7.2.1 20171119 (gcc-7-branch HEAD with MCF thread model, built by
LH_Mouse.)
+ --enable-version-specific-runtime-libs
+ --prefix=/mingw64-64
+ --with-sysroot=/mingw64-64
+ --target=x86_64-w64-mingw32
+ --enable-targets=all
+ --enable-checking=release
+ --with-gmp=/usr/new-gcc/lib/gmp-5.0.5
+ --with-mpfr=/usr/new-gcc/lib/mpfr-2.4.2
+ --with-mpc=/usr/new-gcc/lib/mpc-0.9
+ --with-isl=/usr/new-gcc/lib/isl-0.18
+ --with-cloog=/usr/new-gcc/lib/cloog-0.18.4
+ --with-host-libstdcxx='-lstdc++ -lsupc++'
+ --disable-cloog-version-check
+ --enable-cloog-backend=isl
+Thread model: posix
+gcc version 7.1.0 (GCC)

E:\Desktop>
```

I notice that:
0) You didn't specify `--build=`.
1) You specified `--enable-targets=all` but I think this does not affect mingw
targets according to  and should be
removed.

Maybe you should try adding `--build=`?

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

[lh_mouse at 126 dot com]

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 native one (which does not exist), it is, of course, a
bug.

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77601

Bug ID: 77601
   Summary: error: cannot convert 'is_same' to 'const
bool' in initialization
   Product: gcc
   Version: 7.0
Status: 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 chokes GCC:

template
struct is_same {
constexpr operator bool() const noexcept {
return false;
}
};
template
struct is_same {
constexpr operator bool() const noexcept {
return true;
}
};

template
void foo(Z){
// This works with clang++ but does not with g++.
constexpr bool b1 = is_same{};

// This works with both.
constexpr bool b2 = is_same();
}

int main(){
foo(1);
// This works with both, too.

constexpr bool b3 = is_same();
}

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

[lh_mouse at 126 dot com]

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

[lh_mouse at 126 dot com]

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 lh_mouse  ---
Not very sure whether it is related to this one:

struct foo {
template
void iterate(F f){
int i = 1;
f(i);
}
void kick(){
iterate([&](auto i){ });
}
};

Replacing `auto` with `int` gets rid of the warning.

[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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77726

Bug ID: 77726
   Summary: 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
   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 Milestone: ---

Testcase:



E:\Desktop>cat test.cc
void *operator new(__SIZE_TYPE__ cb){
auto p = __builtin_malloc(cb);
__builtin_printf("%s: %p\n", __PRETTY_FUNCTION__, p);
return p;
}
void operator delete(void *p) noexcept {
__builtin_printf("%s: %p\n", __PRETTY_FUNCTION__, p);
__builtin_free(p);
}
#if 0
void operator delete(void *p, __SIZE_TYPE__ cb) noexcept {
__builtin_printf("%s: %p, %lu\n", __PRETTY_FUNCTION__, p, (unsigned
long)cb);
__builtin_free(p);
}
#endif
int main(){
delete new int;
}

E:\Desktop>g++ test.cc -std=c++14 -Wall -Wextra -pedantic
test.cc:6:6: warning: the program should also define 'void operator
delete(void*, unsigned int)' [-Wsized-deallocation]
 void operator delete(void *p) noexcept {
  ^~~~

E:\Desktop>a.exe
void* operator new(unsigned int): 003F6FA0

E:\Desktop>g++ test.cc -std=c++14 -Wall -Wextra -pedantic -static
test.cc:6:6: warning: the program should also define 'void operator
delete(void*, unsigned int)' [-Wsized-deallocation]
 void operator delete(void *p) noexcept {
  ^~~~

E:\Desktop>a.exe
void* operator new(unsigned int): 007C6CF8
void operator delete(void*): 007C6CF8

E:\Desktop>g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=C:/MinGW/MSYS2/mingw32/lib/gcc/i686-w64-mingw32/6.2.1/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc/configure --prefix=/mingw32
--with-local-prefix=/mingw32/local --build=i686-w64-mingw32
--host=i686-w64-mingw32 --target=i686-w64-mingw32
--with-native-system-header-dir=/mingw
32/i686-w64-mingw32/include --libexecdir=/mingw32/lib --enable-bootstrap
--with-arch=i686 --with-tune=generic --enable-languages=c,lto,c++
--enable-shared --enable-static --enable-libatomic --enable-t
hreads=mcf --enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug
--disable-isl-version-check --enable-lto --enable-libgomp --dis
able-multilib --enable-checking=release --disable-rpath
--disable-win32-registry --disable-nls --disable-werror --disable-symvers
--with-libiconv --with-system-zlib --with-gmp=/mingw32 --with-mpfr=/mi
ngw32 --with-mpc=/mingw32 --with-isl=/mingw32 --with-pkgversion='gcc-6-branch
HEAD with MCF thread model, built by LH_Mouse.'
--with-bugurl=http://github.lhmouse.com/ --with-gnu-as --with-gnu-ld --dis
able-tls --disable-sjlj-exceptions --with-dwarf2
Thread model: mcf
gcc version 6.2.1 20160924 (gcc-6-branch HEAD with MCF thread model, built by
LH_Mouse.)

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61189

Bug ID: 61189
   Summary: ICE with __builtin_return_address() in noexcept lambda
on x86
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  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 lambda function:
test.cpp:2:54: internal compiler error: in ix86_compute_frame_layout, at
config/i386/i386.c:9510
  []() noexcept { return __builtin_return_address(0); }();
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://sourceforge.net/projects/mingw-w64> for instructions.


g++ version:

E:\Desktop>g++ -v
Thread model: win32
gcc version 4.9.0 (i686-win32-sjlj-rev1, Built by MinGW-W64 project)

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61585

Bug ID: 61585
   Summary: Subscript-out-of-range in unwind-seh.c?
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  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 register INDEX as saved in CONTEXT.  */

_Unwind_Word
_Unwind_GetGR (struct _Unwind_Context *c, int index)
{
  if (index < 0 || index > 2)   // ** Isn't 2 an out-of-range index??
abort ();
  return c->reg[index];  // ** Accessed here.
}

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67449

Bug ID: 67449
   Summary: Branch elimination problem on x86
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: rtl-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);
}

int main(){
for(int i = 0; i < 10; ++i){
a[i] = i;
}

int *p = a;
do {
__builtin_printf("element = %d\n", *p);
next(&p);
//  __asm__("");
} while(p);
}


Assembly output:

L13:
testl   %ebx, %ebx
je  L6  ; one here.
L4:
movl(%ebx), %eax
movl$LC1, (%esp)
addl$4, %ebx
movl%eax, 4(%esp)
call_printf
cmpl$_a+40, %ebx
jne L13 ; another one here.
L6:


But if we uncomment that empty __asm__ statement, the first branch vanishes:

Assembly output:

L5:
movl(%ebx), %eax
movl$LC1, (%esp)
addl$4, %ebx
movl%eax, 4(%esp)
call_printf
cmpl$_a+40, %ebx
cmove   %esi, %ebx
testl   %ebx, %ebx  ; the only one branch in this loop.
jne L5

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

[lh_mouse at 126 dot com]

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63959

Bug ID: 63959
   Summary: G++ misreports volatile int as trivially copyable
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: 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 [basic.types]
9 Arithmetic types (3.9.1), ... Cv-unqualified scalar types, trivially copyable
class types (Clause 9), arrays of such types,
** and nonvolatile const-qualified versions of these types (3.9.3) **
are collectively called trivially copyable types. ...

So this is a bug. Please fix.

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

[lh_mouse at 126 dot com]

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64382

Bug ID: 64382
   Summary: ICE due to use of `this` inside a lambda that captures
everything by ref inside a member function of a class
template
   Product: gcc
   Version: 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 &&v){ push(v); });
}
template
void trav(F &&f){
f(T());
}
};
template class my_queue;

-

E:\Desktop>g++ -c test.cpp -std=c++14
test.cpp: In lambda function:
test.cpp:6:29: internal compiler error: Segmentation fault
   trav([&](auto &&v){ push(v); });
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://sourceforge.net/projects/mingw-w64> for instructions.

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61645

Bug ID: 61645
   Summary: forward_list::splice_after shall not throw exceptions
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 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_list&& x);
(... omitted ...)
3 Throws: Nothing. **
4 Complexity: O(distance(x.begin(), x.end()))



// test_case.cpp

#include 

int main(){
std::forward_list l{1,2,3};
static_assert(
noexcept(l.splice_after(l.before_begin(), l)),
"!!"
); // fails
static_assert(
noexcept(l.splice_after(l.before_begin(), l, l.before_begin())),
"!!"
); // ditto
static_assert(
noexcept(l.splice_after(l.before_begin(), l, l.before_begin(),
l.end())),
"!!"
); // ditto
}

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

[lh_mouse at 126 dot com]

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 more like an enhancement request to me - but let's wait what
> Jonathan or Pablo have to say.

Replace forward_list with list, splice_after with splice and before_begin with
begin, all three static_assert's hold.

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61838

Bug ID: 61838
   Summary: ICE on Windows with ctors defined outside class
definitions
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  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 with a template parameter
of another variadic template class, and defined outside its class definition,
results in an ICE. This ICE seems to happen on Windows only.

E:\Desktop>g++ crashme.cpp -std=c++1y
cc1plus.exe: internal compiler error: Segmentation fault

E:\Desktop>g++ -v
...
Target: x86_64-w64-mingw32
...
Thread model: win32
gcc version 4.9.1 (x86_64-win32-seh-rev0, Built by MinGW-W64 project)

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62152

Bug ID: 62152
   Summary: ICE caused by using __builtin_ia32_pause() inside
C++11 noexcept functions on Windows
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  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 above code will result in an ICE when compiled to i686 code:

E:\Desktop>g++ ice.cpp -std=c++14 -m32 -c
ice.cpp: In function 'void foo()':
ice.cpp:3:1: internal compiler error: in ix86_compute_frame_layout, at
config/i386/i386.c:9510
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://sourceforge.net/projects/mingw-w64> for instructions.

If compiled to x86_64 code it won't ICE on Windows.

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

[lh_mouse at 126 dot com]

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 lh_mouse  ---
(In reply to Andreas Schwab from comment #1)
> This is not a leak.  The memory is still reachable and there is no point in
> freeing it if the program is exiting anyway.

It is definitely a leak.

'Being reachable' has nothing to do with whether it is a leak or not. If you
malloc() something but never free() it, it leaks essentially. Being reachable
only means the leak detector (here, valgrind) is unable to tell whether it is a
false leak that would eventually be freed after the detector itself terminates.

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

[lh_mouse at 126 dot com]

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 not lost, or forgotten about, it is in use by the run-time.

That is an ostrich strategy.

The runtime is amenable for deallocation of the pool because it is the runtime
that has allocated the pool. The runtime shall free it, by definition, when it
is no longer 'in use by the run-time', but not never.

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

[lh_mouse at 126 dot com]

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. The
> > > memory is still in use until the program exits, and there is still a 
> > > pointer
> > > to it. It is not lost, or forgotten about, it is in use by the run-time.
> > 
> > That is an ostrich strategy.
> > 
> > The runtime is amenable for deallocation of the pool because it is the
> > runtime that has allocated the pool. The runtime shall free it, by
> > definition, when it is no longer 'in use by the run-time', but not never.
> 
> See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535
> for further motivation.

I did read those posts but fail to get what the last post meant:
> Of course that's broken in older releases as well because of the
> emergency_mutex being dynamically constructed.

Also if the order of global ctors is essential I would suggest a standalone
ctor and dtor:

namespace {

char *arena;
size_t arena_size;

__attribute__((__constructor__(65535)))
void area_ctor(){
  // perform initialization here...
}

__attribute__((__destructor__(1)))
void area_dtor(){
  // ... and perform cleanup here.
}

}

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

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71740

Bug ID: 71740
   Summary: ICE when defining a pointer to the `memcpy()` function
with namespace scope using `auto` targeting i686
   Product: gcc
   Version: 6.2.0
Status: 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 declared manually to avoid
#include'ing any system headers. The prototype MUST match
the one in the standard library. Renaming it or changing its
parameters is not allowed in order to reproduce the ICE. **
```
D:\Desktop>cat test.cpp
extern "C" void *__attribute__((__cdecl__)) memcpy(void *, const void *,
unsigned);
auto p = &memcpy;

D:\Desktop>i686-w64-mingw32-gcc test.cpp
test.cpp:2:11: internal compiler error: Segmentation fault
 auto p = &memcpy;
   ^~

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

test.cpp:2:11: internal compiler error: Aborted

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
i686-w64-mingw32-gcc: internal compiler error: Aborted (program cc1plus)
```

Changing `memcpy` to something like `foo` or changing the type of the last
parameter to `unsigned long` causes the ICE to vanish.

Replacing `auto p =` with `void *(*p)(void *, const void *, unsigned) =` works
around the problem.

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

[lh_mouse at 126 dot com]

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++?

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72768

Bug ID: 72768
   Summary: Potential bug about the order of destructors of static
objects and atexit() callbacks in C++?
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  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 testcase in question.

Reading the ISO C++ standard,
> 3.6.4 Termination [basic.start.term]
> 3 If the completion of the initialization of an object with
> static storage duration is sequenced before a call to std::atexit
> (see , 18.5), the call to the function passed to std::atexit
> is sequenced before the call to the destructor for the object. ...

Notwithstanding the vagueness of 'the completion of the initialization of an
object',
the following program:

#include 
#include 

enum class state {
null,
initialized,
destroyed,
};

extern void broken_atexit();

struct global_data {
state s;

global_data()
: s(state::null)
{
std::puts("delegated constructor");
}
global_data(int) 
: global_data()
{
s = state::initialized;
std::atexit(&broken_atexit);
std::puts("delegating constructor");
}
~global_data(){
s = state::destroyed;
}
} data(1);

void broken_atexit(){
if(data.s == state::destroyed){
std::puts("attempt to use a destroyed object?");
std::abort();
}
std::puts("okay");
}

int main(){
}

, when compiled with GCC, results in use of a destroyed object:

lh_mouse@lhmouse-dev:~$ g++ test.cc -std=c++11
lh_mouse@lhmouse-dev:~$ ./a.out 
delegated constructor
delegating constructor
attempt to use a destroyed object?
Aborted
lh_mouse@lhmouse-dev:~$

The reason of this problem is that GCC front-end registers the dtor after
the delegating constructor returns, which is invoked before the other 
callback registered inside the delegating constructor body.

The problem would be gone only if the GCC front-end registers the dtor after
the delegated constructor returns.

Is this a GCC bug?

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

[lh_mouse at 126 dot com]

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 delegates
to another one, the dtor is called. It doesn't make sense to call a dtor on an
object that has not been completely initialized.
(A public target ctor and a private one have different semantical purposes, but
it is a different story.)

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

[lh_mouse at 126 dot com]

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 of the object’s fully 
> constructed subobjects, that is, for each
> subobject for which the principal constructor (12.6.2) has completed 
> execution and the destructor has not
> yet begun execution, except that in the case of destruction, the variant 
> members of a union-like class are not
> destroyed. ...

Strangely enough, the standard says 'fully constructed' instead of 'completely
initialized' here. I tend to consider it a symbol indicating that the committee
think the two phrases are distinct from each other. From my point of view, the
object is 'completely initialized' once a (delegated or non-delegated,
including principle) ctor returns - if an exception is thrown, the dtor shall
be called -, despite the principal ctor in progress. The antonym of 'completely
initialized' should be 'partially initialized', being in a state when the ctor
of a subobject throws an exception， which is not the case here.

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

[lh_mouse at 126 dot com]

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 destructor. Lack of a guard object
(when the static object has namespace scope instead of block scope) is out of
question because throwing anything out of the constructor would result in a
call to `std::terminate()`.

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

[lh_mouse at 126 dot com]

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 starts here:
https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/VipjQOBUg6M

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

[lh_mouse at 126 dot com via Gcc-bugs]

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 Liu Hao  ---
(In reply to Jakub Jelinek from comment #29)
> CCing some folks familiar with Windows, while Martin has committed a mmap
> based solution, I think it will not work on Windows, but
> CreateFileMapping/MapViewOfFile/UnmapViewOfFile/CloseHandle could be a
> Windows replacement for that:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565575.html
> Can anyone of you please have a look into that?
> I don't have access to Windows (and my experience with it is 25+ years old
> anyway), and Martin doesn't have either.

Windows has native heap management functions [1] so there is no need to play
with file mappings like `mmap()`.

`malloc(size)` becomes `HeapAlloc(GetProcessHeap(), 0, size)`, and
`calloc(nmemb, size)` becomes `HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
nmemb * size)` except for the overflow check, and
`realloc(ptr, size)` becomes `ptr ? HeapReAlloc(GetProcessHeap(), 0, ptr, size)
: HeapAlloc(GetProcessHeap(), 0, size)`, and
`free(ptr)` becomes `ptr && HeapFree(GetProcessHeap(), ptr)`.


[1]
https://docs.microsoft.com/en-us/windows/win32/api/heapapi/nf-heapapi-heapalloc

[Bug target/90262] Inline small constant memmoves

[lh_mouse at 126 dot com via Gcc-bugs]

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:

```
xcopy(char*, char const*):  # @xcopy(char*, char
const*)
movups  xmm0, xmmword ptr [rsi]
movups  xmm1, xmmword ptr [rsi + 16]
movups  xmmword ptr [rdi], xmm0
movups  xmmword ptr [rdi + 16], xmm1
movsx   eax, byte ptr [rdi]
ret
```

which comprises two XMM loads followed by two XMM stores, and should work as
expected no matter whether `dst` and `src` point to overlapped regions.


But GCC generates a call to `memmove()` instead, and is rather inefficient for
this tiny amount of memory:

```
xcopy(char*, char const*):
sub rsp, 8
mov edx, 32
callmemmove
movsx   eax, BYTE PTR [rax]
add rsp, 8
ret
```

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

[lh_mouse at 126 dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100111

Bug ID: 100111
   Summary: `-fno-elide-constructors` causes ICE in GCC 10.3
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 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&action=edit
minimum testcase

```
lh_mouse@lhmouse-ideapad ~/Desktop $ cat ice.cc
// g++-10 -fno-elide-constructors ice.cc

struct b {};
struct j : b {
  int e;
  constexpr j(b k) : b(k), e() {}
};
struct g {
  j h;
  constexpr g() : h({}) {}
} a;
lh_mouse@lhmouse-ideapad ~/Desktop $ g++-10 -fno-elide-constructors ice.cc
ice.cc:11:3:   in ‘constexpr’ expansion of ‘a.g::g()’
ice.cc:10:23:   in ‘constexpr’ expansion of ‘((g*)this)->g::h.j::j((b(), b()))’
ice.cc:11:3: internal compiler error: in cxx_eval_store_expression, at
cp/constexpr.c:4939
   11 | } a;
  |   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
```

```
lh_mouse@lhmouse-ideapad ~/Desktop $ g++-10 -v
Using built-in specs.
COLLECT_GCC=g++-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
10.3.0-1ubuntu1~20.04~2' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-S8Osas/gcc-10-10.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-S8Osas/gcc-10-10.3.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1~20.04~2) 
```

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

[lh_mouse at 126 dot com via Gcc-bugs]

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

[lh_mouse at 126 dot com via Gcc-bugs]

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

[lh_mouse at 126 dot com via Gcc-bugs]

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

[lh_mouse at 126 dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97124

Liu Hao  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Liu Hao  ---
I received this response from MSYS2 later:

```
jeremyd2019 @jeremyd2019 Oct 26 10:52
how is that back?!?
that is caused by a messed up libgmp, and gcc segfaults when it tries to parse
a floating point constant
(specifically, a messed up libgmp import library, and used via mpfr)
gmp patch I sent upstream:
https://gmplib.org/list-archives/gmp-bugs/2020-October/004890.html
```

There's a detailed explanation about the cause in the mail linked above, which
also answers why this ICE does not always happen.

AFAICT this can be closed.

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

[lh_mouse at 126 dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562

Liu Hao  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Liu Hao  ---
https://github.com/gcc-mirror/gcc/commit/7fc0f78c3f43af1967cb7b1ee8f4947f3b890aa2

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

[lh_mouse at 126 dot com via Gcc-bugs]

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

[lh_mouse at 126 dot com via Gcc-bugs]

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. You may ask about this issue on MSYS2 issue tracker [1].
1. Talk to the community (the 'people'), not an individual person.
2. Stop being noisy.


[1] https://github.com/msys2/MINGW-packages/issues

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

[lh_mouse at 126 dot com via Gcc-bugs]

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 GCC itself?


[1]
https://github.com/lhmouse/MINGW-packages-dev/blob/master/mingw-w64-gcc-git/PKGBUILD

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

[lh_mouse at 126 dot com via Gcc-bugs]

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 caught, and `xmm6`
is copied back into a `double` and printed. With GCC 10.2.1 a garbage value is
output. The bug goes away if the `throw` is commented out.

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

[lh_mouse at 126 dot com via Gcc-bugs]

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.



```
// x86_64-w64-mingw32-g++ -O2 -fno-omit-frame-pointer test.cc

__attribute__((__noinline__)) void clobber_xmm6()
  {
__asm__ volatile ("xorpd %%xmm6, %%xmm6" ::: "xmm6");
throw 42;   // remove this to get expected result
  }

int main()
  {
static const double xmm5  =  5.123456;
static const double xmm6  =  6.123456;
static const double xmm7  =  7.123456;
static const double xmm8  =  8.123456;
static const double xmm9  =  9.123456;
static const double xmm10 = 10.123456;
static const double xmm11 = 11.123456;
static const double xmm12 = 12.123456;
static const double xmm13 = 13.123456;
static const double xmm14 = 14.123456;
static const double xmm15 = 15.123456;
__asm__ volatile ("movsd %0, %%xmm5 " :: "m"(xmm5 ));
__asm__ volatile ("movsd %0, %%xmm6 " :: "m"(xmm6 ));
__asm__ volatile ("movsd %0, %%xmm7 " :: "m"(xmm7 ));
__asm__ volatile ("movsd %0, %%xmm8 " :: "m"(xmm8 ));
__asm__ volatile ("movsd %0, %%xmm9 " :: "m"(xmm9 ));
__asm__ volatile ("movsd %0, %%xmm10" :: "m"(xmm10));
__asm__ volatile ("movsd %0, %%xmm11" :: "m"(xmm11));
__asm__ volatile ("movsd %0, %%xmm12" :: "m"(xmm12));
__asm__ volatile ("movsd %0, %%xmm13" :: "m"(xmm13));
__asm__ volatile ("movsd %0, %%xmm14" :: "m"(xmm14));
__asm__ volatile ("movsd %0, %%xmm15" :: "m"(xmm15));

try {
  clobber_xmm6();
}
catch(...) { }

double value;
__asm__ volatile ("movsd %%xmm6, %0" : "=x"(value));
__builtin_printf("value = %g\n", value);  // expect `123.456`
  }


```

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

[lh_mouse at 126 dot com via Gcc-bugs]

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 the asm before printf.
> But, loading the value from memory into some double temporary (with "=x" for
> many of them)
> in an asm and then e.g. just "+x" them in empty asms and then comparing
> values will likely reproduce it too.
> 

Yes this needs to be polished a bit for automated testing.

As explained above, I was using a debugger, so all I wanted to do was to tell
the compiler XMM5-XMM15 were clobbered, then it would generate a handler that
could recover them (XMM5 is caller-saved so no need to recover it).

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

[lh_mouse at 126 dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100411

Bug ID: 100411
   Summary: GCC 11 branch bootstrap ICE on x86_w64-w64-mingw32
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 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-packages-dev/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/./prev-gcc/
-B/mingw64/x86_64-w64-mingw32/bin/ -nostdinc++
-B/d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs
-B/d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs

-I/d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/prev-x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32

-I/d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/prev-x86_64-w64-mingw32/libstdc++-v3/include

-I/d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/gcc/libstdc++-v3/libsupc++
-L/d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c   -g -O2 -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format
-fno-checking -gtoggle -D__USE_MINGW_ACCESS -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I../../gcc/gcc/../libcody -I/mingw64/include -I/mingw64/include
-I/mingw64/include  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/gcc/../libbacktrace -I/mingw64/include -D__USE_MINGW_ANSI_STDIO=1
-I/mingw64/include -o tree-sra.o -MT tree-sra.o -MMD -MP -MF
./.deps/tree-sra.TPo ../../gcc/gcc/tree-sra.c
during RTL pass: final
../../gcc/gcc/tree-sra.c: In function 'bool
path_comparable_for_same_access(tree)':
../../gcc/gcc/tree-sra.c:1983:1: internal compiler error: in
seh_emit_stackalloc, at config/i386/winnt.c:1056
 1983 | }
  | ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc-mcf.lhmouse.com/> for instructions.
make[3]: *** [Makefile:1142: tree-sra.o] Error 1
make[3]: Leaving directory
'/d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32/gcc'
make[2]: *** [Makefile:4833: all-stage2-gcc] Error 2
make[2]: Leaving directory
'/d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32'
make[1]: *** [Makefile:24280: stage2-bubble] Error 2
make[1]: Leaving directory
'/d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/build-x86_64-w64-mingw32'
make: *** [Makefile:1013: all] Error 2

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

[lh_mouse at 126 dot com via Gcc-bugs]

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-prefix=/mingw64/local
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64
--with-tune=nocona --enable-languages=c,lto,c++ --enable-shared --enable-static
--enable-threads=mcf --enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug
--enable-libstdcxx-filesystem-ts=yes --disable-isl-version-check --enable-lto
--enable-libgomp --disable-multilib --enable-checking=release --disable-rpath
--disable-win32-registry --enable-nls --disable-werror --disable-symvers
--with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64
--with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion=GCC with MCF thread
model, built by LH_Mouse. --with-bugurl=https://gcc-mcf.lhmouse.com/
--with-gnu-as --with-gnu-ld --with-boot-ldflags=-pipe
-Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high
-Wl,--disable-dynamicbase,--default-image-base-low -static-libstdc++
-static-libgcc LDFLAGS_FOR_TARGET=-pipe
-Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high
--enable-linker-plugin-flags=LDFLAGS=-static-libstdc++\ -static-libgcc\ -pipe\
-Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high\
-Wl,--stack,12582912 --disable-tls --enable-plugin
```

The PKGBUILD script can be found at
.

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

[lh_mouse at 126 dot com via Gcc-bugs]

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.