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 L
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117799
Bug ID: 117799
Summary: __builtin_memcmp not optimized for size
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117148
Bug ID: 117148
Summary: `-Os` results in much larger code than `-O2` about
bitfields
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117132
Bug ID: 117132
Summary: A call to a function which returns a wider result can
be considered a sibling call
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Sever
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)
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116576
Bug ID: 116576
Summary: `INT64_MAX` and `-Oz`
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee:
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,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
Bug ID: 114968
Summary: missing `__thiscall` attribute on builtin declaration
of `__cxa_thread_atexit()`
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Sever
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 LI
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262
Bug ID: 114262
Summary: Over-inlining when optimizing for size?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opt
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 L
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #25 from LIU Hao ---
Created attachment 57191
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57191&action=edit
Draft patch
This is a draft patch, bootstrapped on {i686,x86_64}-w64-mingw32 successfully.
Haven't run tests though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64064
--- Comment #2 from LIU Hao ---
It looks that MS STL calls `_fseeki64(fp, ...)` [1], while libstdc++ calls
`lseek(_fileno(fp), ...)` [2].
The seek operation shall take the buffering of `FILE` struct into account,
hence I think the libstdc++ impl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64064
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #1 from LI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #24 from LIU Hao ---
I've composed a proposal to address this issue:
https://github.com/lhmouse/mcfgthread/wiki/Formalized-Intel-Syntax-for-x86#the-proposal
The proposal is to treat names between `ptr` and `[` as symbols, and to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #4 from LI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81456
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #12 from L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #42 from LIU Hao ---
(In reply to Yongwei Wu from comment #27)
> Anyone can show a valid use case for a non-lock-free version of 128-bit
> atomic_compare_exchange?
>
> I am trying to use it in a data structure intended to be lock-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97503
--- Comment #8 from LIU Hao ---
(In reply to Uroš Bizjak from comment #7)
> Actually, sign-extension, but the result is never sign-extended.
Yes but it should be a no-op right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70
--- Comment #9 from LIU Hao ---
(In reply to Costas Argyris from comment #8)
> (In reply to LIU Hao from comment #3)
> > Costas, would you like to provide a configure option to exclude that
> > manifest?
>
> I created a patch for that and attac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #41 from LIU Hao ---
There should have been an option, long ago since GCC 7, which may be called
-mcx16-just-emit-the-god-damn-cmpxchg16b-for-me-if-it-does-not-work-its-not-your-fault
`__sync_*` are not an option as 1) they do no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70
--- Comment #5 from LIU Hao ---
(In reply to Costas Argyris from comment #4)
> A couple of comments:
>
> 1) Isn't Windows XP officially not supported any more?If that is the
> case, does it make sense to introduce a new configure option sol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70
--- Comment #3 from LIU Hao ---
Costas, would you like to provide a configure option to exclude that manifest?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #38 from LIU Hao ---
(In reply to Andrew Pinski from comment #35)
> (In reply to peter0x44 from comment #34)
> > Unfortunately, this option breaks GCC running under Windows XP.
>
> XP has not been supported by mingw for a long time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97503
--- Comment #5 from LIU Hao ---
(In reply to LIU Hao from comment #4)
> lzcnt rax, rdx
> testrdx, rdx
> mov edx, 64
> cmove rax, rdx
There is actually another missed optimization here. LZCNT sets CF if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97503
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #4 from LI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112272
Bug ID: 112272
Summary: suboptimal zero-initialization of struct of mixed
pointer and integer types
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70
--- Comment #2 from LIU Hao ---
(In reply to Costas Argyris from comment #1)
> Looks like '... @ Windows XP' is the Host, not the Target, in the PR.
> Target seems irrelevant here.
>
> LH, is this the issue you originally mentioned about my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110613
--- Comment #3 from LIU Hao ---
There are some more cases about loading adjacent bitfields; not sure whether I
should create new PRs or paste them here. They seem highly related to the
aliasing characteristics of `unsigned char`; if I inject
`__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110613
Bug ID: 110613
Summary: optimization about combined store of adjacent
bitfields
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110247
--- Comment #2 from LIU Hao ---
(In reply to Andrew Pinski from comment #1)
> The way I read the documentation, it will NOT be used when dealing with
If it is known, then why shouldn't it?
One potential usecase where this would be helpful is `
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110247
Bug ID: 110247
Summary: suboptimal code about `no_caller_saved_registers` on
caller side
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110008
Bug ID: 110008
Summary: early returns from functions result in suboptimal code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109992
Bug ID: 109992
Summary: Addition/subtraction to the last bitfield of a struct
can be optimized
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109950
--- Comment #4 from LIU Hao ---
Given the fact that GCC is already able to warn about out-of-range indexes for
an array, why wouldn't it be possible to infer that `*(data + next)` is always
an element of `data`?
If the result of `data + next` (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109950
--- Comment #2 from LIU Hao ---
(In reply to Alexander Monakov from comment #1)
> That's the REX prefix, not an operand size override prefix. It doesn't cause
> a decoding stall.
Thanks for pointing this out. Thought it was 66H.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109950
Bug ID: 109950
Summary: can array subscripts be assumed to be non-negative?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109257
--- Comment #6 from LIU Hao ---
gcc/config/i386/i386.cc:
```
void
ix86_print_operand (FILE *file, rtx x, int code)
{
if (code)
{
switch (code)
{
case 'A':
switch (ASSEMBLER_DIALECT)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #14 from LIU Hao ---
(In reply to Thomas Neumann from comment #12)
> Created attachment 55037 [details]
> radix sort fix
>
> I could reproduce the problem, the radix sort did not behave correctly when
> we ran out of bits, which can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #13 from LIU Hao ---
I will test this later today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #23 from LIU Hao ---
Changes to GCC should look like this I suspect (I didn't test this):
```
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index fbd33a6bfd1..de80c7a805f 100644
--- a/gcc/config/i386/i386.cc
+++ b/gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #21 from LIU Hao ---
(In reply to jbeulich from comment #20)
> This is assembly; I don't see how (dis)similarity with C would matter. I
> also don't see how your example is any different in this regard from
>
> mov eax, "symbol"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #19 from LIU Hao ---
(In reply to jbeulich from comment #11)
> I have a rough plan on the gas side, but that will then need a gcc side
> change as well: For a couple of years we have had quoted symbol names there.
> While this doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #11 from LIU Hao ---
(In reply to Thomas Neumann from comment #10)
> (In reply to LIU Hao from comment #9)
> > GDB is affected, too:
>
> I will debug that. That is easier to build than Ada. Strange that it only
> affects 32bit Windo
1 - 100 of 192 matches
Mail list logo
