On Fri, Jul 7, 2023 at 3:50 PM Jan Beulich <jbeul...@suse.com> wrote: > > 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? I'll do that. > > Jan
-- BR, Hongtao
