| Summary: | sys-devel/gcc-14: miscompiles dev-libs/libgcrypt-1.10.3-r1 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sam James <sam> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | base-system |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113135 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 914580 | ||
I managed to reduce at least the test itself quite a bit so far: $ git diff --stat 88cacf20894b41fa271522040962030390a1e416..HEAD tests/t-mpi-point.c tests/t-mpi-point.c | 4268 ++++------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 1 file changed, 82 insertions(+), 4186 deletions(-) the test itself isn't miscompiled, so need to start looking at which TU in libgcrypt is broken 6cb155a6cf314232248a12bdd395ed4151ae5a28 is the first bad commit commit 6cb155a6cf314232248a12bdd395ed4151ae5a28 Author: Tamar Christina <tamar.christina@arm.com> Date: Fri Jan 12 15:24:49 2024 +0000 middle-end: make memory analysis for early break more deterministic [PR113135] Instead of searching for where to move stores to, they should always be in exit belonging to the latch. We can only ever delay stores and even if we pick a different exit than the latch one as the main one, effects still happen in program order when vectorized. If we don't move the stores to the latch exit but instead to whever we pick as the "main" exit then we can perform incorrect memory accesses (luckily these are trapped by verify_ssa). We used to iterate over the conds and check the loads and stores inside them. However this relies on the conds being ordered in program order. Additionally if there is a basic block between two conds we would not have analyzed it. Instead this now walks from the preds of the destination basic block up to the loop header and analyzes every block along the way. As a later optimization we could stop as soon as we've seen all the BBs we have conds for. For now the header will always contain the first cond, but this can change when we support arbitrary control flow. gcc/ChangeLog: PR tree-optimization/113135 * tree-vect-data-refs.cc (vect_analyze_early_break_dependences): Rework dependency analysis. gcc/testsuite/ChangeLog: PR tree-optimization/113135 * gcc.dg/vect/vect-early-break_103-pr113135.c: New test. .../gcc.dg/vect/vect-early-break_103-pr113135.c | 14 +++++++ gcc/tree-vect-data-refs.cc | 43 +++++++++------------- 2 files changed, 32 insertions(+), 25 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/vect/vect-early-break_103-pr113135.c bisect found first bad commit My earlier bisect was bad. New result: ``` There are only 'skip'ped commits left to test. The first bad commit could be any of: 411de96dbf2bdafc7a90ebbfc63e68afd6388d29 6cb155a6cf314232248a12bdd395ed4151ae5a28 99c0a540d6689ede068f9ba98af6f38c3cd71362 We cannot bisect more! error: bisect run cannot continue any more ``` mpi-add.o is miscompiled (In reply to Sam James from comment #4) > mpi-add.o is miscompiled _gcry_mpi_add_ui The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/gcc-patches.git/commit/?id=a1e21703f86e5d60a68a53839774535ccdb8403e commit a1e21703f86e5d60a68a53839774535ccdb8403e Author: Sam James <sam@gentoo.org> AuthorDate: 2024-01-19 07:44:41 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-19 07:44:41 +0000 14.0.0: add 76_all_PR113467-vect-miscompile.patch Bug: https://gcc.gnu.org/PR113467 Bug: https://bugs.gentoo.org/922195 Signed-off-by: Sam James <sam@gentoo.org> 14.0.0/gentoo/76_all_PR113467-vect-miscompile.patch | 15 +++++++++++++++ 1 file changed, 15 insertions(+) The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=77a9314cece73d71ceec164369789b08e744a252 commit 77a9314cece73d71ceec164369789b08e744a252 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-01-22 04:56:08 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-22 04:56:30 +0000 sys-devel/gcc: add 14.0.1_pre20240121 Includes a workaround for bug #922195. Closes: https://bugs.gentoo.org/922195 Closes: https://bugs.gentoo.org/922580 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/gcc/Manifest | 1 + sys-devel/gcc/gcc-14.0.1_pre20240121.ebuild | 64 +++++++++++++++++++++++++++++ 2 files changed, 65 insertions(+) |
Started recently - I think between 14-20231217 5060825aa78b3da036df6437390fd42d094d8f15 and 14-20240114 5f6557b3c61134c762fa442e4f711317c372f364. I don't have a better guess than that yet because of all the vectorisation churn (partial break support landed in 14-20231224 a657c7e3518fcfc796f223d47385cad5e97dc9a5 and it's needed followups since). Only happens for me with -O3 -march=znver2 -m32. (Note that I also see a dev-libs/gmp miscompilation but I've, for now, started with libgcrypt as the test case looks a bit better.) ``` t-mpi-point: context_alloc: tv[0].'NIST P-521': sample point multiply failed: k: 7FFFFFE0003F00000007F00007FFFF80000000001FFC000000FFF030001F03E8FFFFF3E8003803E8000003EA003F0467FFFFF3E8000003E800FFE3E800000000 Qx: 7CAACB2174E1A97A63BABF4E9E6E82389898A1607E4737672B1070E5F66535E406455BFD70F2EBEEEF3F2DB9303E8DB3941190575849708A456188899714C96E74 expected Qx: 00C1002DC2884EEDADB3F9B468BBEBD55980799852C506D37271FFCD006919DB3A96DF8FE91EF6ED4B9081B1809E8F2C2B28AF5FCBF524147C73CB0B913D6FAB0995 Qy: 00990438D2386F13AC4FC5BE2F8690FC5BC1B3F5A312FD113D0DF71AD01C755A89C393087575588707247E45C22931BA45B1B9B02BE8049CD2B487CF68666DDD38D2 expected Qy: 01614E8A62C8293DD2AA6EF27D30974A4FD185019FA8EF4F982DA48698CECF706581F69EE9ED67A9C231EC9D0934D0F674646153273BCBB345E923B1EC1386A1A4AD t-mpi-point: context_alloc: tv[1].'NIST P-521': sample point multiply failed: k: 03FFF7FFFFFFFFFFFFFFE007FFFFFFE3FFFFFFFFFC01FFE0001FE02000FFFF000100000100FFFFC00100000080FFFFF040F8000001000000C100000000 Qx: 00A416B8B436A53456DBB98262BF27B80E80F9F0CA440CE867A80E56B486686837ECC41F557D4098D348EADCB8C9F05AE072EE631CE6979BA63269B698500C8F8002 expected Qx: 0172CD22CBE0634B6BFEE24BB1D350F384A945ED618ECAD48AADC6C1BC0DCC107F0FFE9FE14DC929F90153F390C25BE5D3A73A56F9ACCB0C72C768753869732D0DC4 Qy: 44D7D325D0CDEB1714AB1EE6BD62A166A2953E9799B706B49917402ACE58FF06CE207022D212958F596B0D94511FD5EC61185B6FF46B9ECBBFFBC6B1806CFCA674 expected Qy: 00D249CFB570DA4CC48FB5426A928B43D7922F787373B6182408FBC71706E7527E8414C79167F3C999FF58DE352D238F1FE7168C658D338F72696F2F889A97DE23C5 FAIL: t-mpi-point ```