ty: 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:
(https://godbolt.org/z/jc3cnvacz)
```
#include
#include
struct fire_and_forget {};
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120147
--- Comment #6 from LIU Hao ---
(In reply to Jonathan Wakely from comment #3)
> And yet somehow it does. Confirmed.
You forgot to restore the old `CXXFLAGS`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120147
--- Comment #5 from LIU Hao ---
issue seems to be that in `ac_fn_cxx_try_compile ()` there's
} && test -s conftest.$ac_objext; then :
which checks whether an object file is created, but the cmdline above has `-S`
which produces an asse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120147
--- Comment #4 from LIU Hao ---
configure:5: checking whether _get_osfhandle is defined in
configure:54468:
/home/lh_mouse/GitHub/MINGW-packages/mingw-w64-gcc/src/build-MINGW32/./gcc/xgcc
-shared-libgcc
-B/home/lh_mouse/GitHub/MINGW-packag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #106 from LIU Hao ---
Both the other two patches are on the ML:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670425.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681957.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
LIU Hao changed:
What|Removed |Added
Attachment #61261|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #40 from LIU Hao ---
(In reply to Eric Botcazou from comment #39)
> > What's the difference between the `-mstackrealign` option and the
> > `force_align_arg_pointer` attribute?
>
> -mstackrealign (ix86_force_align_arg_pointer) is on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #38 from LIU Hao ---
(In reply to Eric Botcazou from comment #37)
> You may want to revert the previous change though.
What's the difference between the `-mstackrealign` option and the
`force_align_arg_pointer` attribute?
I'm quite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
LIU Hao changed:
What|Removed |Added
Attachment #61251|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #17 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #34 from LIU Hao ---
(In reply to Gabriel Ivăncescu from comment #33)
> Shouldn't using SSE automatically re-align it to 16, seeing as the alignment
> requirement is stricter? I don't see how __force_align_arg_pointer__ is
> useful a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #32 from LIU Hao ---
Created attachment 61251
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61251&action=edit
another non-working patch
Unfortunately, decreasing the incoming stack alignment to 4 but also keeping
preferred st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #31 from LIU Hao ---
(In reply to Gabriel Ivăncescu from comment #30)
> Why would it not be safe? For MinGW specifically, what's not safe about it?
> The entire Windows stack assumes only 4-byte alignment for i386, because
> that's w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
LIU Hao changed:
What|Removed |Added
Attachment #61236|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
LIU Hao changed:
What|Removed |Added
Attachment #61234|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #27 from LIU Hao ---
Created attachment 61234
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61234&action=edit
proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #26 from LIU Hao ---
(In reply to Zeb Figura from comment #25)
> That's the difference between -mpreferred-stack-boundary and
> -mincoming-stack-boundary; I'm asking about -mstackrealign.
i386.opt:
mstackrealign
Target Var(ix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #24 from LIU Hao ---
(In reply to Zeb Figura from comment #23)
> Only partly. The example in the initial code is fixed. However, if you
> change it to aligned(8) instead of aligned(16), it no longer aligns. See
> comment 17.
>
> Usi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119970
--- Comment #5 from LIU Hao ---
Is there a reason why `__write_to_terminal` takes a `span` instead of a
`span`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119970
--- Comment #1 from LIU Hao ---
Created attachment 61218
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61218&action=edit
this isn't specific to mingw, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #22 from LIU Hao ---
(In reply to Zeb Figura from comment #0)
> Minimal example:
>
> typedef int myint[4] __attribute__((aligned(16)));
>
> extern void g(void *);
>
> void f(void)
> {
> myint a;
> g(&a);
> }
>
>
Would yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
--- Comment #19 from LIU Hao ---
test.c:
```
void foo(int* p);
int bar(int x, int y) {
_Alignas(16) int t[4] = { x, y, x, y };
foo(t);
return 42;
}
```
With SSE (not default):
```
E:\lh_mouse\Desktop>gcc test.c -O2 -c -msse && objdump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #18 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #46 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #49 from LIU Hao ---
(In reply to Luke Dalessandro from comment #48)
> So my understanding is that 104688 basically determined that it's correct to
> implement atomic load with movdqa for aligned addresses on architectures
> with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #47 from LIU Hao ---
(In reply to Luke Dalessandro from comment #46)
> But if 104688 isn't related to this issue, and thus Jakub's comment was in
> error, I definitely don't understand the underlying problem and why clang is
> fine do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
LIU Hao changed:
What|Removed |Added
Attachment #57199|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #103 from LIU Hao ---
New test results on master:
```
UCRT64 ~/Desktop
$ cat test.c
extern __thread int i[8];
int foo (void)
{
return i[2] + i[4];
}
UCRT64 ~/Desktop
$ x86_64-w64-mingw32-gcc --version
x86_64-w64-mingw32-gcc.exe (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110008
--- Comment #3 from LIU Hao ---
Please consider reopening this:
(https://gcc.godbolt.org/z/Kr3s4Yfz1)
```
test:
pushr13
pushr12
pushrbp
pushrbx
mov ebx, edi
sub rsp, 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #102 from LIU Hao ---
I have bootstrapped GCC 15 with native TLS on {i686,x86_64}-w64-mingw32, and
have rebuilt these packages; no issues have been observed so far:
* mingw-w64
* mcfgthread
* binutils
* gdb
* mpdecimal
* mpfr
* icu
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #101 from LIU Hao ---
I have bootstrapped GCC 15 (master) with this patch applied, but without
`--enable-tls`, on {i686,x86_64}-w64-mingw32; and have checked that TLS is
emulated as before so it's not an ABI break by default.
I'm pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #99 from LIU Hao ---
binutils 2.44 is available in MSYS2 now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #97 from LIU Hao ---
(In reply to Julian Waters from comment #96)
> Created attachment 60287 [details]
> Latest TLS
>
> Changed to hard error on broken @secrel32 support. Do help me check if the
> configure patch is ok. If it is, it'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #95 from LIU Hao ---
To be honest, I think `set_have_as_tls=no` is a rather horrible idea. It
changes the output ABI about thread-local storage according to the linker,
which is just there, happens to be used, in an unpredictable way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
LIU Hao changed:
What|Removed |Added
Attachment #59742|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118268
--- Comment #12 from LIU Hao ---
(In reply to Antoni from comment #11)
> Oh, I didn't try with bc, I only tried with this code:
>
> void byte() {}
>
> The error is the same as without this patch:
>
> /tmp/ccX2cpcq.s: Error: .size expression f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118268
--- Comment #10 from LIU Hao ---
(In reply to Antoni from comment #9)
> This doesn't seem to work.
>
> From what I can see, it seems we might need to define ASM_OUTPUT_LABELREF
> for i386. Would that make sense?
What's the error? I tried build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118268
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
LIU Hao changed:
What|Removed |Added
Attachment #59666|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #90 from LIU Hao ---
As mentioned yesterday, the libstdc++ `call_once` has to be reimplemented to
get rid of `__once_callable` and `__once_call` which can't be exported from
libstdc++ DLL.
You might want to introduce a builtin macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117393
--- Comment #3 from LIU Hao ---
16 can be inlined if SSE2 is available. 32 can also be inlined if AVX2 is
available.
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
This is observed in code that compares two UUIDs (that's why it's so useful):
(https://gcc.godbolt.org/z/1cY9GeaPb)
```
template
bool
bytewise_equal(const T&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #85 from LIU Hao ---
Created attachment 59666
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59666&action=edit
libstdc++ fix
It is not possible to export a `__thread` variable with native TLS, because
it's not possible to acces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #84 from LIU Hao ---
(In reply to Julian Waters from comment #83)
> Liu Hao: The registers it's using seem to be all over the place. Prior it
> was using rdx for the gs:[88] load and rax for everything else, now it's
> either using an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #82 from LIU Hao ---
(In reply to Uroš Bizjak from comment #81)
> (In reply to Julian Waters from comment #75)
> > Any feedback on the new patch?
>
> I would propose you legitimize TLS address using get_thread_pointer (as is
> the ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
--- Comment #59 from LIU Hao ---
Created attachment 59642
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59642&action=edit
proposed patch for MCF thread model
Partly fix this issue for the MCF thread model.
Partly do some cleanup for the n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #80 from LIU Hao ---
In libstdc++ there is:
```
/// @cond undocumented
# ifdef _GLIBCXX_HAVE_TLS
// If TLS is available use thread-local state for the type-erased callable
// that is being run by std::call_once in the current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #79 from LIU Hao ---
Created attachment 59639
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59639&action=edit
quote symbols for intel syntax
This patch is necessary for TLS in Intel syntax to work with GNU AS. Details
follow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #78 from LIU Hao ---
I changed it to `ix86_GOT_alias_set()` and checked output assembly. The patch
should be fine for these setups:
* x86_64-w64-mingw-32 (-O0, -O1, -O2, -Os)
* i686-w64-mingw-32 (-O0, -O1, -O2, -Os)
Simple test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #77 from LIU Hao ---
../../gcc/gcc/config/i386/i386.cc: In function 'rtx_def*
legitimize_tls_address(rtx, tls_model, bool)':
../../gcc/gcc/config/i386/i386.cc:12196:27: error: 'GOT_ALIAS_SET' was not
declared in this scope; did you me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #76 from LIU Hao ---
I can include this patch for some testing on GCC 14 now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562
--- Comment #6 from LIU Hao ---
The mingw-w64 bug which you've linked has been fixed for UCRT:
https://github.com/mingw-w64/mingw-w64/blob/0d42217123d3aec0341b79f6d959c76e09648a1e/mingw-w64-crt/crt/tls_atexit.c#L119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117148
--- Comment #4 from LIU Hao ---
>From the code we can see that the call is unconditional; it must happen, so is
not 'unlikely'. On the other hand, `atomic_cmpxchg_iptr` is more complex but
surprisingly it is able to be inlined.
And yes, changin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117148
--- Comment #2 from LIU Hao ---
Oh, the sample code contained a typo:
*(intptr_t*) out = ival;
should be
*(intptr_t*) out = icmp;
However it doesn't affect the bug. (https://godbolt.org/z/fdxbbadnj) It's
because GCC fail to inline `ato
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105495
--- Comment #8 from LIU Hao ---
(In reply to LIU Hao from comment #7)
> Oh, the sample code contained a typo:
>
>*(intptr_t*) out = ival;
>
> should be
>
>*(intptr_t*) out = icmp;
>
> However it doesn't affect the bug.
ahh sorry pos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105495
--- Comment #7 from LIU Hao ---
Oh, the sample code contained a typo:
*(intptr_t*) out = ival;
should be
*(intptr_t*) out = icmp;
However it doesn't affect the bug.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
This code is complex but the two `atomic_*` routines can be ignored.
(https://godbolt.org/z/G6zsdPsrj)
```
#include
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117132
--- Comment #2 from LIU Hao ---
(In reply to Andrew Pinski from comment #1)
> It depends on the ABI, some require the extension while others don't.
> PR 14441 is for a target which has the extension.
This is not about sign-extension but truncat
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
(https://godbolt.org/z/besjxE9Pc)
```
extern long real_foo(long x, long y);
int my_foo_x_y(int x, int y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #49 from LIU Hao ---
On Windows x64 almost all symbols in the flat address space are to be
referenced by RIP-relative addressing. I don't know whether things would work
otherwise.
This correspond to GCC's `-mcmodel=medium` and Clang'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #28 from LIU Hao ---
(In reply to Julian Waters from comment #27)
> I think I remember clang using __tls_index instead of _tls_index for 32 bit
> as well, but that's the only difference I remember. On another note, Cygwin
Yes, you ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #26 from LIU Hao ---
Comment on attachment 59290
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59290
Newer patch for TLS support, incomplete
> + "mov{l}\t{_tls_index(%%rip), %k0|%k0, DWORD PTR
> [rip+_tls_index]}\;mov{q}\t{%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116857
--- Comment #5 from LIU Hao ---
Thanks for the fix! (it indeed does not throw on Windows.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116576
--- Comment #1 from LIU Hao ---
Here is a longer solution but it breaks the dependency:
```
31c0; xor eax, eax
48 ffc8 ; dec rax
48 d1e8 ; shr rax
; (8 bytes; no dependency)
```
: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
For this simple function:
```
int64_t make_value(void) { return INT64_MAX; }
```
Both GCC and Clang generate an 8-byte `movabs` which adds up to 10 bytes:
```
48 b8 ff7f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109464
LIU Hao changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115049
--- Comment #13 from LIU Hao ---
(In reply to LIU Hao from comment #12)
> Created attachment 58662 [details]
> test patch
This fixes the issue for me on x86_64-w64-mingw32.
Note this is actually not target-specific; all targets that implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115049
--- Comment #12 from LIU Hao ---
Created attachment 58662
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58662&action=edit
test patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115049
--- Comment #11 from LIU Hao ---
The function template `std::discard_block_engine::operator()` is instantiated
in both translation units. The two specializations use different sets of
caller-saved registers. Specifically, the specialization in '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115049
--- Comment #10 from LIU Hao ---
(In reply to LIU Hao from comment #9)
> The bug exists around the initialization of a global variable in 'file2.cpp':
This is incorrect. The argument to `operator new` is `4` so the bug happens for
initializatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115049
--- Comment #9 from LIU Hao ---
Created attachment 58656
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58656&action=edit
reduced testcase
After spending four days on this, I have reduced a testcase. `./test.sh` should
reproduce the segfa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #27 from LIU Hao ---
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #24 from LIU Hao ---
GCC 14 branch built successfully on i686-w64-mingw32 with the backported
commit. I have also built boost 1.84 successfully.
I'm now trying to fix the LD fault..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #23 from LIU Hao ---
I am afraid I can't do a complete bootstrap any more due to
https://sourceware.org/bugzilla/show_bug.cgi?id=31720. LD is segfaulting
randomly.
I will backport the commit to GCC 14 branch and make a non-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #19 from LIU Hao ---
(In reply to Jakub Jelinek from comment #17)
> Created attachment 58125 [details]
> gcc15-pr114968.patch
>
> Here is an updated patch.
> Note, even when not taking thiscall attribute into consideration, the
> ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #18 from LIU Hao ---
(In reply to Jakub Jelinek from comment #16)
> What is the reason behind
> /* mingw32 atexit function is safe to use in shared libraries. Use it
>to register C++ static destructors. */
> #define TARGET_CXX_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #15 from LIU Hao ---
Created attachment 58124
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58124&action=edit
proposed patch v2
Update the patch. Did a quick test on i686-w64-mingw32 and seemed to solve the
issue.
Rebuilding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #14 from LIU Hao ---
I suspect it's because that `get_atexit_fn_ptr_type` is shared by `atexit` and
`__cxa_thread_atexit` but the destructors for them do not use the same calling
convention ..
So I should make a copy of it, as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #13 from LIU Hao ---
I am using a modified patch:
```
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 4d6b2b98761..fbd9b4dac2e 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -25799,6 +2579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #12 from LIU Hao ---
testcase:
```
namespace __cxxabiv1
{
extern "C" int __cxa_thread_atexit(void (__thiscall* dtor)(void*), void* obj,
void* dso) noexcept;
}
struct nontrivial
{
nontrivial();
~nontrivial();
};
void*
get_data(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #11 from LIU Hao ---
(In reply to LIU Hao from comment #10)
> (In reply to Jakub Jelinek from comment #8)
> > Created attachment 58123 [details]
> > gcc15-pr114968.patch
> >
> > This is what I'd do, but completely untested...
>
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #10 from LIU Hao ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 58123 [details]
> gcc15-pr114968.patch
>
> This is what I'd do, but completely untested...
It does not solve the issue.
Side note: Although I th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #9 from LIU Hao ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 58123 [details]
> gcc15-pr114968.patch
>
> This is what I'd do, but completely untested...
Thanks. I am gonna give it a run.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #6 from LIU Hao ---
I suspect this isn't correct. I am getting strange errors like 'ld exited with
code 5' not sure what could cause it (possibly also recent MSYS2 updates):
```
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #5 from LIU Hao ---
(In reply to LIU Hao from comment #4)
> > (build_function_type_list returns a shared type, so if attributes are to be
> > added, it needs to go on a variant of the type.
> >
Just saw this. So I would have to cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #4 from LIU Hao ---
(In reply to Jakub Jelinek from comment #2)
> Guess you need to add a target hook next to use_aeabi_atexit and
> use_atexit_for_cxa_atexit which returns attributes that should be added to a
> FUNCTION_TYPE constru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
LIU Hao changed:
What|Removed |Added
Target||i686-w64-mingw32,
|
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
The builtin declaration lacks a `__thiscall` attribute on its first argument
(the callback) and conflicts with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933
--- Comment #8 from LIU Hao ---
Fixed in this commit:
https://github.com/lhmouse/mcfgthread/commit/86ea295e41523183e7680c03cab35e6eb74c4857
It has actually been disallowed since C++98 (N1804) but as part of a different
paragraph.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114933
--- Comment #6 from LIU Hao ---
ISO/IEC WG21 N4917
> 13.9.4 Explicit specialization [temp.expl.spec]
> 2 An explicit specialization shall not use a storage-class-specifier (9.2.2)
> other than thread_local.
This paragraph is new in N4658 and w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53687
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #28 from LIU Hao ---
(In reply to Andrew Pinski from comment #27)
> %zu should be added to ms_printf too.
MSVCRT.DLL from Windows 7 does not support the `z` modifier.
It seems supported on Windows 10; however people really should pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #26 from LIU Hao ---
(In reply to Martin Storsjö from comment #25)
> But since the change in c51f1e7427e6a5ae2a6d82b5a790df77a3adc99a (released
> in GCC 12 already), we probably don't need this any longer. So I think it
> might be mor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #24 from LIU Hao ---
(In reply to Andrew Pinski from comment #23)
> Note since MSVC 2015 runtime, printf has support %ll so ms_printf should be
> fixed to incldue that.
>
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262
--- Comment #7 from LIU Hao ---
(In reply to Jan Hubicka from comment #6)
> > Note GCC has not retuned its -Os heurstics for a long time because it has
> > been
> > decent enough for most folks and corner cases like this is almost never come
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262
--- Comment #4 from LIU Hao ---
(In reply to Andrew Pinski from comment #3)
> It looks like it has been this way since r0-37737-g4838c5ee553f06 (2001) (or
> rather that is when it was used by the tree inline; I don't want to dig
> further back t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262
--- Comment #2 from LIU Hao ---
(In reply to Andrew Pinski from comment #1)
> I thought it was documented that gnu_inline also causes always_inline if
> optimization is turned on but I can't seem to find that ...
Is that the case in GCC source?
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
(https://gcc.godbolt.org/z/a4ox6oEfT)
```
struct impl;
struct impl* get_impl(int key);
int get_value(struct impl* p);
extern __inline__ __attribute__((__gnu_inline__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113633
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #26 from LIU Hao ---
Created attachment 57199
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57199&action=edit
Draft patch Ver. 2
1. Fix a typo in `ASM_OUTPUT_SYMBOL_REF` (`x` => `SYM`)
2. For Intel syntax, if the name does no
1 - 100 of 308 matches
Mail list logo
