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
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
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://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
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
-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=edit
Draft patch Ver. 2
1. Fix a typo in `ASM_OUTPUT_SYMBOL_REF` (`x` => `SYM`)
2. For Intel syntax, if the name does not
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=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++
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
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
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
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
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
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
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
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
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
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Testcase:
(https://gcc.godbolt.org/z/97cThnszM)
```
struct data_mixed
{
int* p1;
int* p2
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
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
This is a piece of code taken from a WebSocket frame parser:
```
#include
struct Header
{
// 1st byte
uint8_t opcode : 4
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
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Given:
(https://gcc.godbolt.org/z/xevzx56Y5)
```
int complex(int x, int y)
__attribute__((__no_caller_saved_registers__));
int test
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
https://gcc.godbolt.org/z/94Wf3Worq
```
int complex_one(int, int);
int
test(int a, int b, int c)
{
if(__builtin_expect(a, 0) == 0)
return 0
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
For an unsigned bit field:
```
struct foo
{
unsigned a : 3;
unsigned b : 29;
};
void
bad_add(struct foo* p
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.
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
There is a lot of historical code which has been using `int` for array indexes:
```
extern int data[];
extern int next;
int
test_function(int* outptr
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
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
+++
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
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
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
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=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=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
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
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
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=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;
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=80883
LIU Hao changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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 #2 from LIU Hao ---
shouldn't this be classified as wrong code?
: 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=edit
unreduced testcase
Attac
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
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=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=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
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
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=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
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
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
-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
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
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' ?
: 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=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
>
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=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
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 #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.
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.
>
>
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=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
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=108059
LIU Hao changed:
What|Removed |Added
Known to fail||10.3.0, 11.1.0
Target|
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=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.
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 #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
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 #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
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=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
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=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=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=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=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=105523
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=105764
LIU Hao changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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: 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=edit
proposed patch
Bootstrapping GCC with fortran enabled and a cus
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 .
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=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,
1 - 100 of 218 matches
Mail list logo
