[r14-2314 Regression] FAIL: gcc.target/i386/pr100711-2.c scan-assembler-times vpandn 8 on Linux/x86_64

[r14-2314 Regression] FAIL: gcc.target/i386/pr100711-2.c scan-assembler-times vpandn 8 on Linux/x86_64

[haochen.jiang]

On Linux/x86_64,

e007369c8b67bcabd57c4fed8cff2a6db82e78e6 is the first bad commit
commit e007369c8b67bcabd57c4fed8cff2a6db82e78e6
Author: Jan Beulich <jbeulich@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

with GCC configured with

../../gcc/configure --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-2314/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl --enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check RUNTESTFLAGS="i386.exp=gcc.target/i386/pr100711-1.c --target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="i386.exp=gcc.target/i386/pr100711-2.c --target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me at haochen dot jiang at intel.com)

Re: [r14-2314 Regression] FAIL: gcc.target/i386/pr100711-2.c scan-assembler-times vpandn 8 on Linux/x86_64

[Jan Beulich]

On 06.07.2023 13:57, haochen.jiang wrote:
> On Linux/x86_64,
> 
> e007369c8b67bcabd57c4fed8cff2a6db82e78e6 is the first bad commit
> commit e007369c8b67bcabd57c4fed8cff2a6db82e78e6
> Author: Jan Beulich <jbeulich@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
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.

Jan

> with GCC configured with
> 
> ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-2314/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl --enable-libmpx x86_64-linux --disable-bootstrap
> 
> To reproduce:
> 
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="i386.exp=gcc.target/i386/pr100711-1.c --target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="i386.exp=gcc.target/i386/pr100711-2.c --target_board='unix{-m32\ -march=cascadelake}'"
> 
> (Please do not reply to this email, for question about this report, contact me at haochen dot jiang at intel.com)

Re: [r14-2314 Regression] FAIL: gcc.target/i386/pr100711-2.c scan-assembler-times vpandn 8 on Linux/x86_64

[Hongtao Liu]

On Fri, Jul 7, 2023 at 3:18 PM Jan Beulich via Gcc-regression
<gcc-regression@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 <jbeulich@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.
>
> Jan
>
> > with GCC configured with
> >
> > ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-2314/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl --enable-libmpx x86_64-linux --disable-bootstrap
> >
> > To reproduce:
> >
> > $ cd {build_dir}/gcc && make check RUNTESTFLAGS="i386.exp=gcc.target/i386/pr100711-1.c --target_board='unix{-m32\ -march=cascadelake}'"
> > $ cd {build_dir}/gcc && make check RUNTESTFLAGS="i386.exp=gcc.target/i386/pr100711-2.c --target_board='unix{-m32\ -march=cascadelake}'"
> >
> > (Please do not reply to this email, for question about this report, contact me at haochen dot jiang at intel.com)
>


-- 
BR,
Hongtao

Re: [r14-2314 Regression] FAIL: gcc.target/i386/pr100711-2.c scan-assembler-times vpandn 8 on Linux/x86_64

[Jan Beulich]

On 07.07.2023 09:46, Hongtao Liu wrote:
> On Fri, Jul 7, 2023 at 3:18 PM Jan Beulich via Gcc-regression
> <gcc-regression@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 <jbeulich@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

Re: [r14-2314 Regression] FAIL: gcc.target/i386/pr100711-2.c scan-assembler-times vpandn 8 on Linux/x86_64

[Hongtao Liu]

On Fri, Jul 7, 2023 at 3:50 PM Jan Beulich <jbeulich@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-regression@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 <jbeulich@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

Re: [r14-2314 Regression] FAIL: gcc.target/i386/pr100711-2.c scan-assembler-times vpandn 8 on Linux/x86_64

[Hongtao Liu]

On Fri, Jul 7, 2023 at 3:50 PM Hongtao Liu <crazylht@gmail.com> wrote:
>
> On Fri, Jul 7, 2023 at 3:50 PM Jan Beulich <jbeulich@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-regression@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 <jbeulich@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.
> >
> > 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

RE: [r14-2314 Regression] FAIL: gcc.target/i386/pr100711-2.c scan-assembler-times vpandn 8 on Linux/x86_64

[Jiang, Haochen]

> -----Original Message-----
> From: Hongtao Liu <crazylht@gmail.com>
> Sent: Friday, July 7, 2023 3:55 PM
> To: Beulich, Jan <JBeulich@suse.com>
> Cc: haochen.jiang <haochenj@ecsmtp.sh.intel.com>; Jiang, Haochen
> <haochen.jiang@intel.com>; gcc-regression@gcc.gnu.org; gcc-
> patches@gcc.gnu.org; Liu, Hongtao <hongtao.liu@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 <crazylht@gmail.com> wrote:
> >
> > On Fri, Jul 7, 2023 at 3:50 PM Jan Beulich <jbeulich@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-regression@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 <jbeulich@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