https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171
--- Comment #23 from Jason A. Donenfeld ---
The output of crc32_string() is always >0 for that case (I think?). And the
case where the user passes an explicit "0" to -frandom-seed was already
considered to be "disabled" by the prior code. A 0 se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171
--- Comment #21 from Jason A. Donenfeld ---
FYI, Linux is working around this shortcoming with the trick in this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c40160f2998c897231f8454bf797558d30a20375
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171
--- Comment #18 from Jason A. Donenfeld ---
If it truly doesn't matter whether local_tick is a valid value or an overflowed
one (to 0 or to -1 in this case), then just remove `&& (!local_tick ||
local_tick == (unsigned)-1)`. If you object to rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171
Jason A. Donenfeld changed:
What|Removed |Added
Resolution|WONTFIX |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171
--- Comment #4 from Jason A. Donenfeld ---
(In reply to Andrew Pinski from comment #2)
> >local_tick = (unsigned) tv.tv_sec * 1000 + tv.tv_usec / 1000;
>
> The only place where local_tick is used is inside coverage.cc:
> if (!flag_branch_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171
Jason A. Donenfeld changed:
What|Removed |Added
Component|plugins |driver
--- Comment #1 from Jason A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171
Bug ID: 105171
Summary: `local_tick` can overflow and become -1
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103275
--- Comment #12 from Jason A. Donenfeld ---
(It might be too late at this point to say it, but I thought it's worth
mentioning that another approach might be convincing the binutils people to
accept kmov/vmov/vex relocations.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103275
--- Comment #6 from Jason A. Donenfeld ---
Working around this now downstream via
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=876602ee223c6c4225371b428a346f0b2d7f2020
which we'll revert whenever an upstream fix is available.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103275
--- Comment #3 from Jason A. Donenfeld ---
Here: https://gcc.godbolt.org/z/zqbWK8rE8
On line 76 of the output:
kmovd k0, DWORD PTR __libc_tsd_CTYPE_B@gotntpoff[ebx]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103275
--- Comment #2 from Jason A. Donenfeld ---
Yes, but as I wrote, this sort of thing is emitted by gcc when compiling C
code, as described in https://sourceware.org/bugzilla/show_bug.cgi?id=28595
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103275
Bug ID: 103275
Summary: don't generate kmov with IE model relocations
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103252
--- Comment #9 from Jason A. Donenfeld ---
> When the mask registers are available for use, RA considers them and when
> spilling to those is cheaper than to memory, it spills to them and not memory.
Yes, this is the thing I don't get. When y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103252
--- Comment #7 from Jason A. Donenfeld ---
The strange thing in this case is that the non-avx512 codegen _doesn't_ spill
to memory. It just uses the gprs that are around. So it seems like that,
somehow, the mere existence of the mask registers c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103252
--- Comment #5 from Jason A. Donenfeld ---
> This one is fine/ok as GCC is using k0 as a spill register rather than
> spilling to memory. 32bit x86 has limited registers and all. There is nothing
> odd about this one even.
Right, okay, I see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103252
--- Comment #2 from Jason A. Donenfeld ---
Here's a more minimal test case: https://gcc.godbolt.org/z/15hnsb6of
And even smaller: https://gcc.godbolt.org/z/KG63ErzEr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103252
--- Comment #1 from Jason A. Donenfeld ---
My march=native should expand to:
-march=tigerlake -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2
-mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mavx512f -mbmi -mbmi2 -maes
-mpclmul -m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103252
Bug ID: 103252
Summary: questionable codegen with kmovd
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
As
18 matches
Mail list logo
