> -----Original Message----- > From: Hongtao Liu <crazy...@gmail.com> > Sent: Friday, July 7, 2023 3:55 PM > To: Beulich, Jan <jbeul...@suse.com> > Cc: haochen.jiang <haoch...@ecsmtp.sh.intel.com>; Jiang, Haochen > <haochen.ji...@intel.com>; gcc-regress...@gcc.gnu.org; gcc- > patc...@gcc.gnu.org; Liu, Hongtao <hongtao....@intel.com> > Subject: Re: [r14-2314 Regression] FAIL: gcc.target/i386/pr100711-2.c scan- > assembler-times vpandn 8 on Linux/x86_64 > > On Fri, Jul 7, 2023 at 3:50 PM Hongtao Liu <crazy...@gmail.com> wrote: > > > > 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? > This also prevents us from finding potential problems.
Yes, -march=cascadelake actually opens AVX512F related features. It sometimes show the potential problems while sometimes false positive. I will add a hint in the script email. Thx, Haochen > > > > > > 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 > > > > -- > BR, > Hongtao
