[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871 Yann Collet changed: What|Removed |Added CC||yann.collet.73 at gmail dot com

[Bug c/82802] New: Potential UBSAN error with pointer difference (32-bits mode)

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yann.collet.73 at gmail dot com Target Milestone: --- As part of our CI test suite, we compile and run fuzzer tests every day. The UBSAN test has been failing for some time now. I suspect

[Bug tree-optimization/65709] [5 Regression] Bad code for LZ4 decompression with -O3 on x86_64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709 Yann Collet changed: What|Removed |Added CC||yann.collet.73 at gmail dot com

[Bug c/67435] New: Large performance drop on apparently unrelated changes (probable cause : strange inlining side-effect)

: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yann.collet.73 at gmail dot com Target Milestone: --- Some weird effect with gcc (tested version : 4.8.4). I've got a performance oriented

[Bug c/67435] Large performance drop on apparently unrelated changes (probable cause : strange inlining side-effect)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67435 --- Comment #4 from Yann Collet --- > Gcc also tries to limit code growth for the unit also which might be > something you are seeing. Yes, that could be the case. Is there some information available somewhere on such unit-level limit ? Specif

[Bug c/67435] Large performance drop on apparently unrelated changes (probable cause : strange inlining side-effect)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67435 --- Comment #5 from Yann Collet --- Complementary information : -Winline : does not output anything (is that normal ?) -fdump-ipa-inline : produce several large files, the interesting one being 1.5 MB long. That's a huge dump to analyze. Nonet

[Bug c/67435] Large performance drop on apparently unrelated changes (probable cause : strange inlining side-effect)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67435 --- Comment #6 from Yann Collet --- The issue seems in fact related to _instruction alignment_. More precisely, to alignment of some critical loop. That's basically why adding some code in the file would just "pushes" some other code into anothe

[Bug c/67435] Large performance drop on apparently unrelated changes (potential cause : critical loop instruction alignment)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67435 --- Comment #8 from Yann Collet --- Thanks for the link. It's a very good read, and indeed, completely in line with my recent experience. Recommended solution seems to be the same : "-falign-loops=32" The article also mentions that the issue is

[Bug c/67435] Feature request: Implement align-loops attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67435 --- Comment #10 from Yann Collet --- > there already is an aligned attribute for functions, variables and fields, Sure, but none of them is related to aligning the start of an hot instruction loop. Aligning the function instead looks like a poor

[Bug tree-optimization/65709] [5 Regression] Bad code for LZ4 decompression with -O3 on x86_64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709 --- Comment #18 from Yann Collet --- This issue makes me wonder : how to efficiently access unaligned memory ? The case in point is ARM cpu. They don't support SSE/AVX, so they seem unaffected by this specific issue, but this issue force writin

[Bug c/67366] New: Poor assembly generation for unaligned memory accesses on ARM v6 & v7 cpus

rity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: yann.collet.73 at gmail dot com Target Milestone: --- Accessing unaligned memory positions used to be forbidden on ARM cpus. But since ARMv6 (quite many years by now),