[Bug c/103252] questionable codegen with kmovd

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

[Bug c/103252] New: questionable codegen with kmovd

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

[Bug c/103252] questionable codegen with kmovd

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

[Bug target/103252] questionable codegen with kmovd

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

[Bug target/103275] [11/12 Regression] don't generate kmov with IE model relocations

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.)

[Bug target/103252] questionable codegen with kmovd

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

[Bug c/103275] New: don't generate kmov with IE model relocations

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:

[Bug target/103252] questionable codegen with kmovd

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

[Bug target/103275] don't generate kmov with IE model relocations

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]

[Bug target/103275] don't generate kmov with IE model relocations

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

[Bug target/103275] [11/12 Regression] don't generate kmov with IE model 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.

[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1

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

[Bug driver/105171] New: `local_tick` can overflow and become -1

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

[Bug driver/105171] gcc/toplev.c: `local_tick` can overflow and become -1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171 Jason A. Donenfeld changed: What|Removed |Added Component|plugins |driver --- Comment #1 from Jason

[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1

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

[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1

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

[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1

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

[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171 Jason A. Donenfeld changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED