| Summary: | sci-mathematics/flint-3.1.0 tests take too much time, some test fail, some tests are not converging. gcc graphite issue? | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Arniiiii <lg3dx6fd> |
| Component: | Current packages | Assignee: | Michael Orlitzky <mjo> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | frp.bissey, lg3dx6fd, mjo, proxy-maint |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://github.com/flintlib/flint/issues/2029 | ||
| See Also: | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115697 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 915000 | ||
| Attachments: |
/etc/portage/make.conf // profile default/linux/amd64/17.1/desktop/plasma gcc-13 O3 pipe march=native(verbose) lto graphite ggdb3 testing FEATUREs : testing
environment // profile default/linux/amd64/17.1/desktop/plasma gcc-13.2.1_p20240210 O3 pipe march=native(verbose) lto graphite ggdb3 |
||
Created attachment 895948 [details]
environment // profile default/linux/amd64/17.1/desktop/plasma gcc-13.2.1_p20240210 O3 pipe march=native(verbose) lto graphite ggdb3
hah interesting. I've tried manually copy compile flags from portage, it fail some test with qqbar_enclosure_raw: root refinement not converging for example. Same from portage's attempt. but previously I just have added -O3 -ggdb3 -pipe -march=native -flto=auto . I need some iterations to find what flags cause it. Iteration 1 with manual testing of release: it happens with my compile flags from my /etc/portage/make.conf Iteration 2 with manual testing of release: it doesn't happen when without graphite flags Iteration 3 with manual testing of release: it happens with my compile flags from my /etc/portage/make.conf, but with -O2 Iteration 4 with manual testing of release: it happens with my compile flags from my /etc/portage/make.conf, but with -O0 sorry, it happens , iteration 3 and 4 was with -O3 , they are the same as iteration 1 Iteration 5 with manual testing of release: it DOESN'T happen with `-O0 -pipe -flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -fgraphite-identity -floop-interchange -floop-strip-mine -floop-nest-optimize -ggdb3 -frecord-gcc-switches` Iteration 6 with manual testing of release: it HAPPENS with `-O3 -pipe -flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -fgraphite-identity -floop-interchange -floop-strip-mine -floop-nest-optimize -ggdb3 -frecord-gcc-switches` Iteration 7 with manual testing of release: it HAPPENS with `-O2 -pipe -flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -fgraphite-identity -floop-interchange -floop-strip-mine -floop-nest-optimize -ggdb3 -frecord-gcc-switches` Iteration 8 with manual testing of release: it HAPPENS with `-O2 -pipe -fgraphite-identity -floop-interchange -floop-strip-mine -floop-nest-optimize -ggdb3 -frecord-gcc-switches` Iteration 9 with manual testing of release: it DOESN'T happen with `-O1 -pipe -fgraphite-identity -floop-interchange -floop-strip-mine -floop-nest-optimize -ggdb3 -frecord-gcc-switches` Iteration 10 with manual testing of release: it DOESN'T happen with `-O2 -pipe -ggdb3 -frecord-gcc-switches` Iteration 11 with manual testing of release: it DOESN'T happen with `-O1 -pipe -march=native -fgraphite-identity -floop-interchange -floop-strip-mine -floop-nest-optimize -ggdb3 -frecord-gcc-switches` also fyi: ``` │ ~/code/experiments/flint-3.1.0/build/GCC_13.2.1_x86_64-pc-linux-gnu/Debug resolve-march-native -march=alderlake -mabm -mno-cldemote -mno-kl -mno-pconfig -mno-sgx -mno-widekl -mshstk --param=l1-cache-line-size=64 --param=l1-cache-size=32 --param=l2-cache-size=30720 ``` After all these attempts, I guess, it happens at least when -O2 and graphite flags. Confirmed & reported upstream. Unless someone has a better idea, I think I'll filter the graphite flags for now. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f6d99555e8a35a1080174120515c87c59dc37a5e commit f6d99555e8a35a1080174120515c87c59dc37a5e Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2024-06-26 22:09:31 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2024-06-26 22:20:04 +0000 sci-mathematics/flint: add 3.1.3_p1 Closes: https://bugs.gentoo.org/934463 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> sci-mathematics/flint/Manifest | 1 + .../flint/files/flint-3.1.3_p1-c99-I.patch | 320 +++++++++++++++++++++ sci-mathematics/flint/flint-3.1.3_p1.ebuild | 89 ++++++ 3 files changed, 410 insertions(+) Someone may want to try reduce it but it won't be me, at least not any time soon. |
Created attachment 895947 [details] /etc/portage/make.conf // profile default/linux/amd64/17.1/desktop/plasma gcc-13 O3 pipe march=native(verbose) lto graphite ggdb3 testing FEATUREs : testing Idk why it try to test src-fmpz_mat-test-main and src-fmpq_mpoly_factor-test-main for too much time. I've tried manually download the flint-3.1.0 from github releases, compile and test it. It took to test literally less than a minute via `ctest . -j24 --verbose --test-load 999 ` ( literally how portage does (+ --verbose), if believe htop what portage calls. ) idk why it takes too much time on the test via portage, please, explain. I'll attach environment and make.conf