`constexpr foo_table[] =`
{
{ 1, 2 },
{ 3, 4 },
{ 5, 6 },
};
```
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
On ARM64, Windows uses X18 as a pointer to thread-specific data. We have this declaration which we can't
get rid of:
register struct _TEB *__mingw_current_teb __asm__("x18");
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
d by failure to compile a simple C++ program, but the cause can vary: Your system might have
no c++ compiler (which i think is unlikely), or the existent c++ compiler rejected the program due to an
unknown option. You can take a look at the end of config.log.
--
Best regards,
LIU Hao
OpenPGP_
e --enable-languages=c,c++,fortran --disable-multilib
make -j$(nproc)
```
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
2f6b1b742911ba0770b49bbb/mingw-w64-crt/crt/crtexe.c#L203-L267
[2] https://sourceware.org/binutils/docs/ld/WIN32.html
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
My code is pure C language and does not need this code. How to remove the extra
assembly code.
The solution is to define `WinMain()` (or `wWinMain()` with the `-municode` option), where GCC will
not insert `__main()`.
Note the call still exists, before your main function is called.
--
B
ne it in one of your source files.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
another register. I don't see a point in
doing that.
Not to mention that MOV can be implemented by register renaming which has a
latency of zero.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
lease take a look at PR115049 and decide whether it should block the release? Although
this issue is reported about mingw-w64, I suspect Linux may be affected too.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
#x27;restrict'-qualified parameter
// aliases with argument 1
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
Attached is an alternative patch to functionalize `load_macros_array`. It allows GCC to build on
x86_64-w64-mingw32. Not tested though, as I know no Rust.
As before, please edit the patch at your disposal.
--
Best regards,
LIU Hao
diff --git a/gcc/rust/checks/errors/borrowck/rust-borrow
hing about Rust.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
Hello,
Attached is a patch for fixing build issues on *-w64-mingw32. Please check and
update at your leisure.
'gcc/system.h' contains a macro called `mkdir()` and there is no need to invoke `_mkdir()` within a
conditional block.
--
Best regards,
LIU Hao
diff --git a/gcc/rust/che
. The other branch below clearly
eliminates the dependency.
}
else
{
// The architects say this is safe even for 0.
res = -1;
asm("bsf %1, %0" : "+r"(res) : "rm"(x));
}
return res + 1;
}
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
This patch does not look so horrible:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929#c26
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
houldn't have checked for `*` right?
The calls to `output_addr_const()` are from `dw2_assemble_integer (int size, rtx x)` in
'gcc/dwarf2asm.cc'. Now I need some directives on how to fix this; parsing the symbol seems awkward.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
"`, it would mean something very different
and cause linker errors.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
h_mouse\AppData\Local\Temp\ccuyuu6c.s:29: Error: invalid use of
register
C:\Users\lh_mouse\AppData\Local\Temp\ccuyuu6c.s:29: Warning: register value
used as expression
lh_mouse@lhmouse-pc ~/Desktop $
```
--
Best regards,
LIU Hao
From 2579afab42b90dceac860114acbad1ab79bca979 Mon Sep 17 00:
t;bx"[rip]
> as test.s -o test.o
> objdump -d test.o
test.o: file format pe-x86-64
(...)
0: 48 8d 05 00 00 00 00learax,[rip+0x0]# 7 <.text+0x7>
7: 90 nop
So I think I had better try my patch in the next few days
does not cause ambiguity, it can be accepted either
way.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
ax noprefix; mov eax, DWORD PTR gs:0x48' -o a.o &&
objdump -Mintel -d a.o
...
<.text>:
0:65 8b 04 25 48 00 00moveax,DWORD PTR gs:0x48
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
so their compiler outputs do not
really turn into assembly code before finally becoming target code. This approach is not subject to
the ambiguity.
As GCC still relies on GAS to produce object files, (as stated in the first paragraph,) it might
make some sense to implement a strict mode on outputs
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
r supports Windows 7, but it's always possible to cross-compile from a
supported system to Windows 7, or something even older like Windows XP or 2000. If you encounter an
issue, please let me know.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
packages, we
generally recommend https://www.msys2.org/.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
d)
#endif /* L_gcov_dump */
-#ifdef L_gcov_fork
+#if defined L_gcov_fork && !defined _WIN32
/* A wrapper for the fork function. We reset counters in the child
so that they are not counted twice. */
```
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
. Calls to weak functions can jump to random,
non-allocated memory and cause faults. Instead, duplicates of COMDAT sections are removed by the
`.linkonce discard` directive.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
iled.
Makes sense. The target-specific macro `_WIN32` serves that purpose.
However `fork()` doesn't actually exist there, and linking should indeed fail. Maybe `__gcov_fork()`
shouldn't be defined at all.
--
Best regards,
LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
them for C++ [1] and GCC defines `NOMINMAX` in 'os_defines.h',
so either way it is not necessary.
[1]
https://github.com/mingw-w64/mingw-w64/blob/3ebb92804e3125d1be8f61bcd42f15a8db15ba1e/mingw-w64-headers/include/minmax.h#L9
--
Best regards,
LIU Hao
OpenPGP_signature.asc
on my
TigerLake CPU.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
)) // [[noreturn]] won't work
int
my_stream::
underflow()
{
throw std::invalid_argument("not implemented");
}
```
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
x86 has very few GPRs and GCC doesn't optimize multi-word arithmetic very
well. Performance may or may not vary depending on cache locality and number of μops; not to mention
`movq` and `movd` which have relative high latencies. I would like to see some benchmarking results
first
tion like this, you must do it
yourself.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
ub, SourceForge, StackOverflow, ncurses etc. are marked as from mailing lists. I
suspect there is kinda misconfiguration.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
That look likes a private macro that prevents inclusion of 'msxml.h', which can identified by
examining Windows headers. It's undocumented and probably shouldn't be defined by users.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
for this issue is to add `-DCOM_NO_WINDOWS_H` in `CPPFLAGS`
when building GCC.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
-patc...@gcc.gnu.org with a CC to Jonathan Yong
<10wa...@gmail.com>, who is the only maintainer on GCC for mingw-w64 port.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
, it seems to make a difference only if the result is ever written back to memory.
And for comparison, it makes completely no difference whether the operand is 32-bit or 8-bit, except
when the operand is an 8-bit ?H register. [1]
[1] https://uops.info/table.html
--
Best regards,
LIU Hao
在 2023/4/11 16:51, LIU Hao via Gcc 写道:
My interpretation is that if one argument is a SNaN and the other is not,
`fmax()` shall return the
SNaN unchanged, without converting it to a QNaN. (F.10.9.2 The fmax functions,
ISO/IEC 9899:2017)
'the other is not' means the other op
017)
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
What should we do about it? A skull is neither descriptive nor
informative, and is very unfriendly for message filters. A tag there might look much more helpful,
such as [BUILDBOT] or [FAIL].
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
lling wide APIs explicitly, such overhead can be avoided.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
ption:
```
mov edx, 2
mov eax, edx # edx:eax = 0x20002
mov ecx, edx
div ecx# division overflows because the quotient
# can't stored into EAX
```
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
al
ret
```
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
Would you please do the same to libgomp too?
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
this parameter is useful for more people.
I vote +1 for this in GCC 14.
GCC 13 (i.e. current master branch) is at stage3 so it's not an option at this
moment.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
在 2022-11-26 17:20, Dave Blanchard 写道:
No, I'm not trolling, just venting here for a moment. So sick of garbage ass,
crusty junkware that's always a battle to the death to accomplish anything.
I really understand where Liu Hao was coming from yesterday when he was in here
raging a
ell, if that's your decision, fair enough. I can maintain my own distribution.
Patch attached [1]; bootstrapped on {x86_64,1686}-w64-mingw32 without any
issues so far.
[1]
https://github.com/lhmouse/MINGW-packages/blob/gcc-13/mingw-w64-gcc/9000-Deprecate-the-nonsense-AT-T-synax.patch
--
Be
在 2022/11/25 16:50, Marc Glisse 写道:
On Fri, 25 Nov 2022, LIU Hao via Gcc wrote:
I am a Windows developer and I have been writing x86 and amd64 assembly for more than ten years.
One annoying thing about GCC is that, for x86 if I need to write I piece of inline assembly then I
have to do it
a lot of work to keep up with
it all.
I hope that, if we decide to make Intel syntax the default since GCC 14, then such crud will be
eventually got rid of since GCC 24. OTOH, if we don't do that, we would have to live with it forever.
--
Best regards,
LIU Hao
OpenPGP_signature
Descri
year-old evilness and refusing to move
forward. Upgrading the compiler is always a big change, and updating sources should be expected,
when we take `-Werror` into account.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
to you, please consider how to write VFMADD231PD in
AT&T syntax, really.
I have been tired of such inconsistency. For God's sake, please deprecate it.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
aultlibs` to
GCC, and specify desired libraries explicitly.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
efault-msvcrt=`, so
they always match.
[1] https://sourceforge.net/p/mingw-w64/mailman/message/36030072/
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
= strcspn (role, ":");
```
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
.
Thanks, I've pushed it to trunk now.
Thank you for taking care of it!
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
ccess to
GCC repo, and it takes a couple of hours for me to bootstrap GCC just for this tiny change.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
e not used inside GCC and the include of mutex should be
done early.
Well I am not familiar with such behavior. Feel free to amend the patch, until it looks good to you.
I hope we can check this in before GCC 13 RC.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
lto,c++,fortran,objc,obj-c++` and with the `mcf` thread model; no errors observed. The built
`libgccjit-0.dll` does not have imports from winpthread any more.
Please review.
--
Best regards,
LIU Hao
From ceb65f21b5ac23ce218efee82f40f641ebe44361 Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Mon,
x27;gcc' subdirectory, so I suspect it isn't an option there?
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
ttribute__((__gnu_inline__)) __inline__
#endif
extern
int g_strcmp0(const char*str1, const char*str2);
#ifndef INSIDE_FOO_C
__attribute__((__gnu_inline__)) __inline__
#endif
extern
int g_strcmp0(const char*str1, const char*str2) {
...
```
--
Best regards,
LIU Hao
OpenPGP
27;:
```
#ifndef INSIDE_FOO_C
__attribute__((__gnu_inline__)) __inline__
#endif
extern
int g_strcmp0(const char*str1, const char*str2) {
...
```
'foo.c':
```
__attribute__((__dllexport__)) /* This is optional. */
extern int g_strcmp0 (const char *str1, const
在 2022-10-29 20:15, Eric Botcazou 写道:
So what could be causing it?
An oversight in https://gcc.gnu.org/pipermail/gcc-cvs/2022-August/370830.html
has broken --disable-sjlj-exceptions. That's now fixed.
Thank you. Rebuilding now.
--
Best regards,
LIU Hao
OpenPGP_signature
Descri
could be causing
it? Thanks in advance.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
line%60
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
it, it should be seen as
```
__attribute__((__dllexport__))
extern inline
int g_strcmp0(const char*, const char*)
```
There is no `gnu_inline` in this case. GCC always generates a COMDAT/weak/linkonce definition, which
will not cause multiple definition errors.
在 2022/10/11 21:28, LIU Hao via Gcc 写道:
Did you have any declarations that had no `__gnu_inline__`? GNU inline functions are supposed to be
emitted out of line, even when its address is taken.
This should be 'to be never emitted out of line'. Sorry for that.
--
Best regard
在 2022/10/11 21:10, xclae...@gmail.com 写道:
Le mardi 11 octobre 2022 à 13:00 +0800, LIU Hao a écrit :
you may try
```
__attribute__((__gnu_inline__))
extern inline
int g_strcmp0(const char*, const char*)
{ ...
```
Thanks, I gave that a try but I get many: multiple
n is being defined in a DLL, `__dllexport__` should be used in place of
`__gnu_inline__`. This may require another macro, similar to `GLIB_API`.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
://twdev.blog/2021/08/cmake/
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
en no problems.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
ike that. `China, Taiwan, Hsinchu` is acceptable;
`Taiwan` is not.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
t would be great as well.
Thank you for the information. Reverting cfc9fdcec8861be0d11ec4493cca518bf5b4c32d made the build
proceed again. I have created PR 101377 for it [1].
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377
--
Best regards,
LIU Hao
OpenPGP_signature
Descriptio
have attached the build log in case you
need it.
--
Best regards,
LIU Hao
mingw-w64-gcc-mcf-11.1.1.d20210708.c11.g35aca8e9b45-1-x86_64-build.log.gz
Description: application/gzip
OpenPGP_signature
Description: OpenPGP digital signature
void* ptr = 0;
if(sscanf(buf, "%p", &ptr))
*(int*)ptr = 100;
fprintf(stderr, "value = %d\n", value); // 100 instead of 42
}
```
--
Best regards,
Liu Hao
OpenPGP_signature
Description: OpenPGP digital signature
hor), then rebased the modified commit
onto ee52bf609bac. Git is smart enough to drop duplicate changes, but the leftovers formed a new
commit, which was exactly a325bdd195e.
--
Best regards,
Liu Hao
OpenPGP_signature
Description: OpenPGP digital signature
;
else
return INT_MIN;
}
return res;
}
which can be optimized further as
int f (int a, int b)
{
int res;
if (__builtin_add_overflow (a, b, &res))
res = (a >> sizeof(int) * CHAR_BIT - 1) ^ INT_MAX;
return res;
}
--
Best regards,
Liu
在 17/04/2021 16.27, Aaron Gyes 写道:
As far as I understand it Chris Punches lives in North America.
Only 2% of the world population lives in the US, indeed, most live in China.
It’s interesting the unkind reaction Liu Hao received in this very thread
when they encountered the arguments making
table, and whether a disclaimer from an employer is
needed, doesn't need to be done in public. The contributor might not want to discuss who their
employer is on the public list, for example.
Thanks for your information.
--
Best regards,
Liu Hao
OpenPGP_signature
Description:
nese society and has almost eradicated sexism. It's something I can hardly understand why you
(singular) still have a very vicious opinion on that.
[I am not meant to participate in the discussion about the history and future
of GCC.]
--
Best regards,
Liu Hao
OpenPGP_signature
Des
regards,
Liu Hao
OpenPGP_signature
Description: OpenPGP digital signature
在 2021/1/14 上午9:47, Roy Qu via Gcc 写道:
> I use "gcc -finput-charset=utf-8 -fexec-charset=gb2312" to compile utf-8
> encoding source files under windows. Most of the time it works well, but
> when the source file contains some characters such as "—", gcc will fail
> and the error message is: "[Err
在 2020/11/27 下午4:14, Richard Biener 写道:
>
> I prefer the ( on the next line. The argument list can be two spaces
> indented from
> the function name or "right justified" (I think the latter looks
> visually better).
>
The right justification thing looks reasonable. For example, I think this
``
在 2020/11/27 上午7:50, Jonathan Wakely via Gcc 写道:
> I've touched on the subject a few times, e.g.
> https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html
> and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html
>
> Libstdc++ code is indented by 2 columns for the enclosing namespace,
在 2020/11/19 上午2:31, sotrdg sotrdg via Gcc 写道:
> The locale shit is not thread safe. printf(“Hello World %d”,3) is undefined
> behavior under none-UTF-8 exec-charset. WTF WTF WTF.
>
> This is purely garbage tbh. Just remove this toggle. I want encoding, I can
> use another library. I do not need
在 2020/8/13 上午2:40, David Blaikie 写道:
>
> Then use of `auto*` would make it easier for you to spot use of plain
> pointers in your projects & scrutinize them further?
>
My point is that `auto*` conveys no more information than `auto`. The absence
of `*` does not imply the object (pointer)
being
在 2020/8/11 下午9:55, Nathan Sidwell 写道:
>
> I agree, it's the way I use auto. I particularly like the
> auto *foo = expr;
> idiom, when you're getting a pointer, but the type of the pointee is clear.
> It informs how you use 'foo'.
>
>
Personally I dislike this syntax. Pointers are objects
在 2020/5/29 18:35, Andreas Schwab 写道:
> On Mai 29 2020, David Brown wrote:
>
>> So my counter-proposal for you would be to recommend gcc's "typeof" as a
>> new keyword (spelt "_Typeof", with "typeof" as a macro in ,
>> in solid C tradition).
>
> Or call it _Decltype/decltype, following C++.
>
>
在 2019/12/16 4:00, Jeffrey Walton 写道:
>
> If RTFM was going to work, then it would have happened in the last 50
> years or so.
>
> If error free programming was going to happen, then it would have
> happened in the last 50 years or so.
>
> Come back to reality.
>
What's your point? Don't RTFM
在 2018/9/20 22:08, Vincent Lefevre 写道:
>> In C++, declaring n1 const avoids the warning regardless of
>> optimization levels.
>
> If the constant propagation is done at -O0, this could explain
> the behavior.
>
> Or do you mean that GCC remembers the type the data come from,
> i.e. assuming char
在 2018/9/19 16:52, lokesh janghel 写道:
Hi,
I am starting to looking into this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85667#c0
We did some analysis about that issue and found that the problem occurs may
be in the code generation phase in GCC.
ABI says that struct type uses the int
在 2018-08-20 16:27, Richard Biener 写道:
> Btw, I can't find wording in the standards that nullptr + 1 is
> invoking undefined behavior,
> that is, that pointer arithmetic is only allowed on pointers pointing
> to a valid object.
> Any specific pointers?
>
The C standard only defines addition and s
在 2018-08-15 12:48, Jeff Law 写道:
I just don't think anyone's ever bothered to catch this case. I believe
there is a BZ which touches on this issue.
Yes, here it is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
This PR uses a placement new as the example, which in GCC 8 assumes the
poi
Dear GCC people,
At the moment, with GCC 8.2, I compile the program
```
int foo(const char *p)
{
if(p == 0)
return 2;
const char *q = p + 1;
if(q == 0)
return 1;
return 0;
}
```
using
```
gcc-8 test.c -Wall -Wextra -Wpedantic -O3 -S
```
and get the following as
在 2018-08-10 18:53, Kim Gräsman 写道:
I'm worried that this might only serve to trick the compiler.
It shouldn't. If it was merely a trick then `std::aligned_storage` would
be completely unusable.
Explicitly using `-fno-strict-aliasing` for GCC < 6 would seem more
direct to me -- as Jonathan
在 2018-08-10 06:20, Kim Gräsman 写道:
On Fri, Aug 10, 2018 at 12:02 AM, Jonathan Wakely
wrote:
If GCC 4.9.3 thinks there's an aliasing violation it might
misoptimise. It doesn't matter if it's right or not, it matters if it
treats the code as undefined or not.
And apparently GCC does think ther
It has been long since this was reported. Today Alexey said he had found
the reason. He believed that 899af040b0 was causing the failure [1].
After reverting it the x64 bootstrap succeeded, however the x86
bootstrap failed with an ICE [2].
So now we have two issues here. Should we file a new P
在 2018/7/5 9:14, snow_xmas 写道:
Hello.
The source in the attachment can not be compiled, because there is a
variable in the lambda-introducer does not have a copy-constructor, but have a
move-constructor. When a function object constructed by a lambda-expression
like this, the compiler wil
在 2018/6/5 4:44, Steve Ellcey 写道:
Is there a bug in __builtin_isnormal or am I just confused as to what it
means? There doesn't seem to be any actual definition/documentation for
the function. __builtin_isnormal(0.0) is returning false. That seems
wrong to me, 0.0 is a normal (as opposed to a
在 2018/6/2 18:11, Eric Botcazou 写道:
Any ideas about how to resolve this?
Compare with a known working version (e.g. GCC 7) and find the discrepancy.
Hmm there would be a huge amount of code to check. It seems to me that
it is GNATLINK that causes the error. As I have absolutely no knowledge
1 - 100 of 111 matches
Mail list logo