https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100411
--- Comment #7 from Liu Hao ---
Does this affect other `-mtune=` values too? I am thinking about
`--with-tune=ivybridge`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #8 from LIU Hao ---
The commit above just lets GCC bootstrap on Windows. The cause of this issue is
still there.
Maybe it's possible to replace all direct calls to `abort()` in gcc and libcpp
with `fancy_abort (__FILE__, __LINE__, _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #10 from LIU Hao ---
(In reply to Arsen Arsenović from comment #9)
> (In reply to LIU Hao from comment #8)
> > The commit above just lets GCC bootstrap on Windows. The cause of this issue
> > is still there.
> >
> > Maybe it's possi
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Godbolt: https://gcc.godbolt.org/z/PrPP4v9z1
```
extern int r;
int
bz(int value)
{
r = __builtin_ctz(value);
return value != 0; // always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108341
--- Comment #7 from LIU Hao ---
(In reply to Jakub Jelinek from comment #4)
> I think 0 argument for __builtin_c[lt]z{,l,ll,imax} is always undefined, 0
> argument
> to .C[LT]Z (internal calls) is undefined if C[LT]Z_DEFINED_VALUE_AT_ZERO is
> n
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Original reported by Théo Cavignac here:
https://sourceforge.net/p/mingw-w64/mailman/message/37773946/
The ICE is only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108675
--- Comment #4 from LIU Hao ---
Does it make any sense to remove `#include ` from
'gcc.c-torture/execute/builtins/lib/fprintf.c' ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108675
--- Comment #7 from LIU Hao ---
(In reply to nightstrike from comment #5)
> (In reply to LIU Hao from comment #4)
> > Does it make any sense to remove `#include ` from
> > 'gcc.c-torture/execute/builtins/lib/fprintf.c' ?
>
> That will prevent t
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Godbolt: https://gcc.godbolt.org/z/fsavMzMo7
```
void
set_bool(bool& fl, __UINT32_TYPE__ value)
{
fl |= value >> 31;
}
```
This code shifts a `uint32` to th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104588
--- Comment #3 from LIU Hao ---
Sounds so. Changing `char a[32]` to `long a[4]` or `void* a[4]` makes GCC
generate MOVAPS like Clang, but `int a[8]` or `short a[16]` does not.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Target: x86_64-linux-gnu
This is a piece of code that has been simplified from a Boyer-Moore-Horspool
implementation:
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104632
--- Comment #2 from LIU Hao ---
I don't think it's a duplicate. This only happens when reading through a
pointer by negative offsets. If I change the code to read by non-negative
offsets, GCC is actually very happy about it:
https://gcc.godbolt
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Created attachment 52847
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52847&action=edit
proposed patch
A few days ago I was playing with linker plu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105335
--- Comment #3 from LIU Hao ---
Windows uses a full-width 32-bit exit status, but there is no standard
convention for them.
1. If a process has exited successfully, the status is zero. This matches
POSIX.
2. If a process has exited due to a fau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105764
LIU Hao changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #6 from
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
I was reading
<https://quuxplusone.github.io/blog/2018/04/17/downsides-of-omitting-trivial-destructor-calls/>,
which I think is a great article. But the issue that was mentio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82028
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #2 from
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Target: x86_64-linux-gnu
https://gcc.godbolt.org/z/M3YoaYeEf
```c++
struct alignas(16) foo
{
unsigned char a[32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #10 from LIU Hao ---
(In reply to Tomas Kalibera from comment #7)
> I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches
> mailing list in May:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #36 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93687
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #10 from LIU Hao ---
(In reply to Andrew Pinski from comment #8)
> That inline-asm is not correct and GCC does not understand segments if you
> don't use named address space feature.
>
Named address space is not supported unless a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #13 from LIU Hao ---
(In reply to Andrew Pinski from comment #11)
> Yes but the inline-asm is just broken. Anyways this is not related to the
> original issue reported here.
It IS related. GCC should not warn about dereferencing a c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #53 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027
--- Comment #1 from LIU Hao ---
I need some information about this though:
When multilib is enabled, does GCC still link programs with `-lmsvcrt`? There
seems to be only reference to msvcrt:
gcc/config/i386/mingw32.h:187: -lmoldname -lmin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027
--- Comment #6 from LIU Hao ---
That's not a GCC bug. That's because you have installed libraries to the
default but wrong location.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027
--- Comment #7 from LIU Hao ---
The .la files generated by libtool are usually nonsense
(https://fedoraproject.org/wiki/Changes/RemoveLaFiles). If you run `make
install` by hand then you may delete them by hand. Some packagers (e.g. makepkg
on A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027
--- Comment #9 from LIU Hao ---
(In reply to cqwrteur from comment #8)
> if I delete them by hand, then gcc could not build anymore since build
> scripts of libstdc++ would complain .la do not exist
No library in MSYS2 has been installed with .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027
--- Comment #11 from LIU Hao ---
It has nothing to do with MSYS2. MSYS2 is merely an example to show that .la
files are not necessary and should not be installed.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
This was reported on IRC by Vladimir_Kozelko:
https://godbolt.org/z/oMjTc1813
```
#include
struct unused {
template
constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108059
LIU Hao changed:
What|Removed |Added
Known to fail||10.3.0, 11.1.0
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108059
--- Comment #2 from LIU Hao ---
Reconfirmed with all the following versions:
* g++-10 (Ubuntu 10.4.0-4ubuntu1~22.04) 10.4.0
* g++-11 (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
* g++-12 (Ubuntu 12.2.0-3ubuntu1~22.04) 12.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108203
--- Comment #2 from LIU Hao ---
(In reply to nightstrike from comment #0)
> Bug report that came from it:
> https://sourceforge.net/p/mingw-w64/bugs/292/
>
I think this should be no longer the case. Two years ago I submitted a patch
that made
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Recently, mingw-w64 has got updated from Wine. GCC then ceases to
build:
```
../../gcc/gcc/system.h:791:30: error: expected identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #2 from LIU Hao ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to LIU Hao from comment #0)
> > 791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
>
> The C++ standard says this is undefined.
>
> W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #5 from LIU Hao ---
A quick and obvious fix is to add `CPPFLAGS='-DWIN32_LEAN_AND_MEAN'` when
configuring. Bootstrapped successfully on {i686,x86_64}-w64-mingw32.
I still think GCC source files should be patched.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Godbolt: https://gcc.godbolt.org/z/7ob6zc17P
Offending testcase:
```c
typedef struct { int b; } cond;
int
__MCF_batch_release_common(cond* p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105495
--- Comment #1 from LIU Hao ---
A possible workaround is to use a scalar type to provide storage for local
variables, and cast them as needed:
Godbolt: https://gcc.godbolt.org/z/n7zq7Pn4G
```c
typedef struct { int b; } cond;
int
__MCF_batch_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105495
--- Comment #3 from LIU Hao ---
Wouldn't that go away if the value in it is never read back?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105495
--- Comment #5 from LIU Hao ---
This does not trigger the issue:
```c
#define __atomic_compare_exchange(p,c,n,w,ms,mf) \
({ int __temp; \
__builtin_memcpy(&__temp, c, sizeof(*c)); \
_Bool __r = __atomic_compare_exchange(p, (__typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #53 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
--- Comment #55 from LIU Hao ---
(In reply to Andrew Pinski from comment #54)
> (In reply to LIU Hao from comment #53)
> > The patch no longer applies to GCC 12.
>
> Right because I think this issue has been fixed by r12-5855-g747380f47da0da .
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Created attachment 53049
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53049&action=edit
proposed patch
Bootstrapping GCC with fortran enable
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Given (godbolt: https://gcc.godbolt.org/z/hqKKW33T7):
```
long long
foo(long long x, unsigned bits)
{
return x + (unsigned) __builtin_ctz(bits);
}
```
GCC
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Created attachment 51117
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51117&action=edit
bootstrap log
With binutils 2.36 I get
/d/lh_mouse/GitH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377
--- Comment #4 from Liu Hao ---
configure said 'yes' for 'broken dwarf5 support'. I am not quite clear whether
this means whether it is broken or not (but I suspect yes):
```
configure:29798: checking linker PT_GNU_EH_FRAME support
configure:29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377
--- Comment #6 from Liu Hao ---
Created attachment 51118
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51118&action=edit
gzip'd gcc/config.log
Of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377
--- Comment #8 from LIU Hao ---
lh_mouse@lhmouse-pc ~ $ /mingw64/x86_64-w64-mingw32/bin/as --version
GNU assembler (GNU Binutils) 2.36.1
Copyright (C) 2021 Free Software Foundation, Inc.
This program is free software; you may redistribute it und
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377
--- Comment #12 from LIU Hao ---
I will try rebuilding tomorrow (~11hrs later).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377
--- Comment #15 from LIU Hao ---
I have bootstrapped GCC 11.1.1 on both {x86_64,i686}-w64-mingw32 and seen no
problem so far.
-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=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
--- 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 #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=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
: 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=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=108865
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #22 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #24 from LIU Hao ---
(In reply to Costas Argyris from comment #23)
> Created attachment 54730 [details]
> Make symbol optional
>
> Could you please try this patch?
Didn't test this completely, but it did allow the build to continue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #26 from LIU Hao ---
(In reply to Costas Argyris from comment #23)
> Created attachment 54730 [details]
> Make symbol optional
>
> Could you please try this patch?
Works for me. I have checked that cpp.exe, cc1.exe, cc1plus.exe all
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
https://gcc.godbolt.org/z/Tc8v5qfv1
a proper tail call:
```
extern int (*foo)(int, int);
int ptc_to_foo(int a, int b) { return foo(a, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109257
--- Comment #3 from LIU Hao ---
(In reply to jbeulich from comment #2)
> Sure, but there's no reason for gas to not accept what MASM would. You also
> don't really make clear why you think this is an issue, and hence why it
> should be changed i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109257
--- Comment #5 from LIU Hao ---
(In reply to jbeulich from comment #4)
> Being as compatible as possible with MASM has been the primary goal of
> supporting Intel syntax. Intel's SDM doesn't specify complete assembly
> language; it serves as a r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109380
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82028
--- Comment #6 from LIU Hao ---
Looks like this has been fixed? https://gcc.godbolt.org/z/xP5E76aYz
Despite that however, GCC generates suboptimal code that uses an XMM register
to perform the bitwise AND operation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82028
--- Comment #7 from LIU Hao ---
clang generates 14 bytes:
```
mov rax, 0x7FFF # 48 B8 FF FF FF FF FF FF FF 7F
and rax, rcx # 48 23 C1
ret # C3
``
but in principle this function requires o
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Created attachment 54824
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54824&action=edit
unreduced testcase
Atta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109464
--- Comment #2 from LIU Hao ---
shouldn't this be classified as wrong code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109464
LIU Hao changed:
What|Removed |Added
Known to fail||10.4.0, 9.5.0
--- Comment #4 from LIU Hao --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109464
--- Comment #5 from LIU Hao ---
Additional information:
I tried splitting the two class templates into two separate .cpp files, so the
explicit instantiation of `basic_shallow_string` should not be subject to
the instantiation of `basic_cow_str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80883
LIU Hao changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #22 from LIU Hao ---
Yes, GCC should be told to shut up about dereferencing artificial address
values.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #31 from LIU Hao ---
(In reply to Andrew Pinski from comment #24)
> The warning is there for the above case really (and similar ones with struct
> offsets). Where you originally have a null pointer and have an offset from
> there; by
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
GAS PR: https://sourceware.org/bugzilla/show_bug.cgi?id=30418
Filed in both places, as we need changes both.
This is how MSVC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #13 from LIU Hao ---
dup notwithstanding, I think I had better copy my recommendation here for
reference:
This is how MSVC handles such names:
(https://gcc.godbolt.org/z/TonjYaxqj)
```
static int* volatile rip;
static unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #15 from LIU Hao ---
> Which as least MASM up to 12.x won't assemble. For one it complains about
> "rip" being undeclared. And then the load of "ecx" is _not_ a memory access
> (i.e. the "DWORD PTR" is ignored there). Which is in line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #17 from LIU Hao ---
Yeah. It looks to me like the Microsoft compiler doesn't actually uses the
assembler (like LLVM).
Given the C source:
```
extern int rax;
int main() { return rax; }
```
which compiled without errors:
```
> cl /O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #18 from LIU Hao ---
Would it make any sense to have GAS be more permissive about such labels,
1. unconditionally? or
2. when input is from a pipe? or
3. when a special option is in effect e.g. `--output-from-gcc`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #9 from LIU Hao ---
GDB is affected, too:
https://github.com/msys2/MINGW-packages/pull/16968#issuecomment-1533702758
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
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=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 #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=109670
--- Comment #13 from LIU Hao ---
I will test this later today.
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=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=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 #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=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=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=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.
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=114968
LIU Hao changed:
What|Removed |Added
Target||i686-w64-mingw32,
|
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
--- 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 #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 #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.
101 - 200 of 307 matches
Mail list logo
