On 07.07.2023 09:46, Hongtao Liu wrote: > On Fri, Jul 7, 2023 at 3:18 PM Jan Beulich via Gcc-regression > <gcc-regress...@gcc.gnu.org> wrote: >> >> On 06.07.2023 13:57, haochen.jiang wrote: >>> On Linux/x86_64, >>> >>> e007369c8b67bcabd57c4fed8cff2a6db82e78e6 is the first bad commit >>> commit e007369c8b67bcabd57c4fed8cff2a6db82e78e6 >>> Author: Jan Beulich <jbeul...@suse.com> >>> Date: Wed Jul 5 09:49:16 2023 +0200 >>> >>> x86: yet more PR target/100711-like splitting >>> >>> caused >>> >>> FAIL: gcc.target/i386/pr100711-1.c scan-assembler-times pandn 2 >>> FAIL: gcc.target/i386/pr100711-2.c scan-assembler-times vpandn 8 >> >> I expect the same applies here - -mno-avx512f (or -mno-avx512vl) might > For this one, we can just add -mno-avx512f to the testcase,it aims to > optimize pandn for avx2 target. >> address this failure. But whether that's really the way to go I'm not >> sure of. Plus of course such adjustments should have been done ahead >> of time, when it was decided that testing with certain -march= settings >> is a goal. My changes have merely uncovered the prior omissions. > It's not a standard request, it's just our private tester which is > used to find gcc bugs and miss-optimizations. > It sometimes generates false positive reports (usually adding > -mno-avx512f to the testcase can fix that), hope that's not too > annoying.
Wouldn't that then better be done once uniformly for all affected tests, rather than being discovered piecemeal? Anyway, in this case: Since you said you'd take care of the other test, will/can you do so for the two ones here as well, or am I on the hook? Jan
