RE: [r13-8949 Regression] FAIL: gcc.target/i386/avx512dq-vreducess-1b.c (test for excess errors) on Linux/x86_64

2024-07-28 Thread Jiang, Haochen via Gcc-regression
Ah... When I solved the huge conflict this morning due to AVX10 refactor for
GCC13/12, I forgot that it is in GCC14 AVX10.1 refactor when I added the
_mm_avx512_setzero_ps/pd. Should use _mm_setzero_ps/pd instead.

Never do something tweak quickly on a sleepy Monday morning.

Thx,
Haochen

> -Original Message-
> From: haochen.jiang 
> Sent: Monday, July 29, 2024 1:28 PM
> To: Jiang, Haochen ; gcc-regression@gcc.gnu.org;
> gcc-patc...@gcc.gnu.org
> Subject: [r13-8949 Regression] FAIL: gcc.target/i386/avx512dq-vreducess-
> 1b.c (test for excess errors) on Linux/x86_64
> 
> On Linux/x86_64,
> 
> bb15c4cf21dbe76df5a225342d1fbe8ecd3c7971 is the first bad commit
> commit bb15c4cf21dbe76df5a225342d1fbe8ecd3c7971
> Author: Haochen Jiang 
> Date:   Thu Jul 25 16:12:20 2024 +0800
> 
> i386: Fix AVX512 intrin macro typo
> 
> caused
> 
> FAIL: gcc.target/i386/avx512dq-vreducesd-1b.c (test for excess errors)
> FAIL: gcc.target/i386/avx512dq-vreducess-1b.c (test for excess errors)
> 
> with GCC configured with
> 
> ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-bisect/gcc-
> 13/releases/gcc-13/r13-8949/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/avx512dq-vreducesd-1b.c --
> target_board='unix{-m32}'"
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512dq-vreducesd-1b.c --
> target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512dq-vreducesd-1b.c --
> target_board='unix{-m64}'"
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512dq-vreducesd-1b.c --
> target_board='unix{-m64\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512dq-vreducess-1b.c --
> target_board='unix{-m32}'"
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512dq-vreducess-1b.c --
> target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512dq-vreducess-1b.c --
> target_board='unix{-m64}'"
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="i386.exp=gcc.target/i386/avx512dq-vreducess-1b.c --
> target_board='unix{-m64\ -march=cascadelake}'"
> 
> (Please do not reply to this email, for question about this report, contact 
> me at
> haochen dot jiang at intel.com.) (If you met problems with cascadelake
> related, disabling AVX512F in command line might save that.) (However,
> please make sure that there is no potential problems with AVX512.)


RE: gcc-regression script build fail info

2024-08-12 Thread Jiang, Haochen via Gcc-regression
Ping for this thread.

Any ideas? If no, I will change the generated info with command following
if we take r15-1643 as example and see if it is clearer:

head -26 makelog.r15-1643.x86_64.native | tail -7 > 1.log;
grep -E "(error:|Error)" makelog.r15-1643.x86_64.native >> 1.log;
echo " Detailed Info around error (+- 10 Lines) 
" >> 1.log;
grep -C 10 -E "error:" makelog.r15-1643.x86_64.native >> 1.log;

Thx,
Haochen

> -Original Message-
> From: Jiang, Haochen
> Sent: Thursday, July 18, 2024 3:57 PM
> To: 'Sam James' 
> Cc: 'gcc-regression@gcc.gnu.org' ; 'gcc-
> testresu...@gcc.gnu.org' ; 'g...@gcc.gnu.org'
> 
> Subject: RE: gcc-regression script build fail info
> 
> 
> 
> > -Original Message-
> > From: Jiang, Haochen
> > Sent: Thursday, July 18, 2024 3:46 PM
> > To: 'Sam James' 
> > Cc: 'gcc-regression@gcc.gnu.org' ; 'gcc-
> > testresu...@gcc.gnu.org' ; g...@gcc.gnu.org
> > Subject: gcc-regression script build fail info
> >
> > > > For future reports, would it be possible to change the grep to
> > > > something
> > > > like:
> > > >
> > > > grep -E "(error:|Error)" or just grep -rsin "error" -w or something.
> > > >
> > > > This would allow catching the actual compile error in libbacktrace
> > > > if it's not going to fit in the last N lines from make.
> > >
> > > Hi Sam,
> > >
> > > Let me change that in the script and see if it is much clearer.
> > >
> > > This bug report definitely seems not clear for me also.
> >
> > Hi all,
> >
> > Sam just mentioned in another thread that the current log for build fail in
> gcc-
> > regression is not clear at all, like the problem in:
> > https://gcc.gnu.org/pipermail/gcc-regression/2024-July/080272.html
> > The 100 bottom line didn't give any info for why it runs into a build fail.
> >
> > As Sam suggested, we might change the build fail info part which is 
> > currently
> > using 'tail -100' to 'grep -E "(error:|Error)"' to get some clear info.
> >
> > Does any one still needs the 'tail -100' for some more info? Or if the 
> > output
> for
> > 'grep -E "(error:|Error)" is enough?
> >
> > For example, for r15-2116, overall report will be:
> 
> Made a typo here, the report is generated from r15-1643.
> 
> >
> > make[2]: Entering directory '/home/haochenj/src/gcc-regression'
> > rm -rf bld
> > mkdir -p bld
> > cd bld; \
> >  RUNTESTFLAGS="--target_board='unix{-m32,}'" ../src-master/configure \
> > --with-arch=native --with-cpu=native --enable-clocale=gnu --with-
> system-
> > zlib --enable-shared --enable-cet --with-demangler-in-ld --enable-libmpx --
> > prefix=/usr/gcc-15.0.0 --with-fpmath=sse checking build system type...
> > x86_64-pc-linux-gnu
> > grep "Error " makelog.r15-1643.x86_64.native >> makelog.r15-
> > 1643.x86_64.native.mail; \
> > make[6]: [Makefile:1832: x86_64-pc-linux-gnu/bits/largefile-config.h] Error
> 1
> > (ignored)
> > make[6]: [Makefile:1831: x86_64-pc-linux-gnu/bits/largefile-config.h] Error
> 1
> > (ignored)
> > make[6]: [Makefile:1832: x86_64-pc-linux-gnu/bits/largefile-config.h] Error
> 1
> > (ignored)
> > ../../src-master/gcc/config/i386/i386.cc:107:12: error: 'rtx_def*
> > legitimize_dllimport_symbol(rtx, bool)' declared 'static' but never defined 
> > [-
> > Werror=unused-function]
> > ../../src-master/gcc/config/i386/i386.cc:108:12: error: 'rtx_def*
> > legitimize_pe_coff_extern_decl(rtx, bool)' declared 'static' but never 
> > defined
> [-
> > Werror=unused-function]
> > make[6]: *** [Makefile:2557: i386.o] Error 1
> > make[5]: *** [Makefile:5108: all-stage2-gcc] Error 2
> > make[4]: *** [Makefile:30031: stage2-bubble] Error 2
> > make[3]: *** [Makefile:30275: bootstrap] Error 2
> > make[2]: *** [Makefile:313: bootstrap] Error 2
> > make[1]: *** [Makefile:409: one] Error 1
> > make: *** [Makefile:406: one-master] Error 2
> >
> > Thx,
> > Haochen
> >
> > >
> > > Thx,
> > > Haochen
> > >
> > > >
> > > > (Not needed here as ILT already fixed the issue on master).
> > > >
> > > > thanks,
> > > > sam


RE: gcc-regression script build fail info

2024-08-14 Thread Jiang, Haochen via Gcc-regression
> -Original Message-
> From: Sam James 
> Sent: Thursday, August 15, 2024 6:30 AM
> To: Jiang, Haochen 
> Cc: gcc-regression@gcc.gnu.org; gcc-testresu...@gcc.gnu.org;
> g...@gcc.gnu.org
> Subject: Re: gcc-regression script build fail info
> 
> "Jiang, Haochen"  writes:
> 
> > Ping for this thread.
> >
> > Any ideas? If no, I will change the generated info with command
> > following if we take r15-1643 as example and see if it is clearer:
> >
> > head -26 makelog.r15-1643.x86_64.native | tail -7 > 1.log; grep -E
> > "(error:|Error)" makelog.r15-1643.x86_64.native >> 1.log; echo
> > " Detailed Info around error (+- 10 Lines)
> > " >> 1.log; grep -C 10 -E "error:"
> > makelog.r15-1643.x86_64.native >> 1.log;
> >
> 
> This plan sounds good to me, although I was hoping someone might speak
> up ;)
> 
> I will keep an eye on the failures afterwards and then see if it looks OK too.
> 
> (Sorry if you were waiting on me, I may have misunderstood.)
> 

I have changed the command to the mentioned one for normal and ia32 build
while keeping the native build as unchanged for comparison and prevent
something went wrong for the change. (I suppose it won't break but in case I did
some typo.)

Thx,
Haochen


RE: [r15-3000 Regression] FAIL: gcc.target/i386/avx10_2-rounding-3.c (test for excess errors) on Linux/x86_64

2024-08-20 Thread Jiang, Haochen via Gcc-regression
The three avx10.2 related test regression are all related to the usage of
-mavx10.2 -march=cascadelake, which is unavoidable warning.

I am considering to change -march=cascadelake to a arch with AVX10 in
the future to avoid these false alarms.

Thx,
Haochen

> -Original Message-
> From: haochen.jiang 
> Sent: Tuesday, August 20, 2024 11:59 PM
> To: Hu, Lin1 ; gcc-regression@gcc.gnu.org; gcc-
> patc...@gcc.gnu.org; Jiang, Haochen 
> Subject: [r15-3000 Regression] FAIL: gcc.target/i386/avx10_2-rounding-3.c
> (test for excess errors) on Linux/x86_64
> 
> On Linux/x86_64,
> 
> 3d1b5530ea1d23e26dc5ab70aa4a2e7b9dc19b50 is the first bad commit
> commit 3d1b5530ea1d23e26dc5ab70aa4a2e7b9dc19b50
> Author: Hu, Lin1 
> Date:   Mon Aug 19 10:09:03 2024 +0800
> 
> AVX10.2 ymm rounding: Support vcvt{,u}w2ph and vdivp{s,d,h} intrins
> 
> caused
> 
> FAIL: gcc.target/i386/avx10_2-rounding-3.c (test for excess errors)
> 
> with GCC configured with
> 
> ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-
> bisect/master/master/r15-3000/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/avx10_2-rounding-3.c --
> target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-rounding-3.c --
> target_board='unix{-m64\ -march=cascadelake}'"
> 
> (Please do not reply to this email, for question about this report, contact 
> me at
> haochen dot jiang at intel.com.) (If you met problems with cascadelake
> related, disabling AVX512F in command line might save that.) (However,
> please make sure that there is no potential problems with AVX512.)


RE: [r15-3185 Regression] FAIL: gcc.target/i386/avx10_2-compare-1.c (test for excess errors) on Linux/x86_64

2024-08-26 Thread Jiang, Haochen via Gcc-regression
As applied to all AVX10.2 patches, it is caused by vector size warning
mentioned previously.

Thx,
Haochen

> -Original Message-
> From: haochen.jiang 
> Sent: Monday, August 26, 2024 11:54 PM
> To: jun.zh...@intel.com; gcc-regression@gcc.gnu.org; gcc-
> patc...@gcc.gnu.org; Jiang, Haochen 
> Subject: [r15-3185 Regression] FAIL: gcc.target/i386/avx10_2-compare-1.c
> (test for excess errors) on Linux/x86_64
> 
> On Linux/x86_64,
> 
> 576bd309ded9dfe258023f26924c064a7bf12875 is the first bad commit
> commit 576bd309ded9dfe258023f26924c064a7bf12875
> Author: Zhang, Jun 
> Date:   Mon Aug 26 10:53:54 2024 +0800
> 
> AVX10.2: Support compare instructions
> 
> caused
> 
> FAIL: gcc.target/i386/avx10_2-compare-1.c (test for excess errors)
> 
> with GCC configured with
> 
> ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-
> bisect/master/master/r15-3185/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/avx10_2-compare-1.c --
> target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-compare-1.c --
> target_board='unix{-m64\ -march=cascadelake}'"
> 
> (Please do not reply to this email, for question about this report, contact 
> me at
> haochen dot jiang at intel.com.) (If you met problems with cascadelake
> related, disabling AVX512F in command line might save that.) (However,
> please make sure that there is no potential problems with AVX512.)


RE: [r15-3359 Regression] FAIL: gcc.target/i386/avx10_2-bf-vector-cmpp-1.c (test for excess errors) on Linux/x86_64

2024-09-02 Thread Jiang, Haochen via Gcc-regression
As each AVX10.2 testcases previously, this is caused by option combination 
warning,
which is expected.

> From: haochen.jiang 
> Sent: Monday, September 2, 2024 9:06 PM
> 
> On Linux/x86_64,
> 
> f77435aa3911c437cba71991509eee57b333b3ce is the first bad commit commit
> f77435aa3911c437cba71991509eee57b333b3ce
> Author: Levy Hsu 
> Date:   Mon Sep 2 10:24:49 2024 +0800
> 
> i386: Support vec_cmp for V8BF/V16BF/V32BF in AVX10.2
> 
> caused
> 
> FAIL: gcc.target/i386/avx10_2-bf-vector-cmpp-1.c (test for excess errors)
> 
> with GCC configured with
> 
> ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-
> bisect/master/master/r15-3359/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/avx10_2-bf-vector-cmpp-1.c --
> target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_2-bf-vector-cmpp-1.c --
> target_board='unix{-m64\ -march=cascadelake}'"
> 
> (Please do not reply to this email, for question about this report, contact 
> me at
> haochen dot jiang at intel.com.) (If you met problems with cascadelake 
> related,
> disabling AVX512F in command line might save that.) (However, please make sure
> that there is no potential problems with AVX512.)


RE: [r15-3359 Regression] FAIL: gcc.target/i386/avx10_2-bf-vector-cmpp-1.c (test for excess errors) on Linux/x86_64

2024-09-02 Thread Jiang, Haochen via Gcc-regression


> -Original Message-
> From: Hongtao Liu 
> Sent: Tuesday, September 3, 2024 1:47 PM
> To: Jiang, Haochen 
> Cc: haochen.jiang ; ad...@levyhsu.com; gcc-
> regress...@gcc.gnu.org; gcc-patc...@gcc.gnu.org
> Subject: Re: [r15-3359 Regression] FAIL: gcc.target/i386/avx10_2-bf-vector-
> cmpp-1.c (test for excess errors) on Linux/x86_64
> 
> On Tue, Sep 3, 2024 at 9:45 AM Jiang, Haochen via Gcc-regression
>  wrote:
> >
> > As each AVX10.2 testcases previously, this is caused by option combination
> warning,
> > which is expected.
> >
> Can we put the warning for mix usage of mavx10 and -mavx512f under -
> Wpsabi
> And add -Wno-psabi in addition to -march=cascadelake to avoid the
> false positive?

We could do that if nobody has objection to that.

Thx,
Haochen

> 
> --
> BR,
> Hongtao


RE: [r15-3359 Regression] FAIL: gcc.target/i386/avx10_2-bf-vector-cmpp-1.c (test for excess errors) on Linux/x86_64

2024-09-04 Thread Jiang, Haochen via Gcc-regression
> -Original Message-
> From: Richard Biener 
> Sent: Tuesday, September 3, 2024 2:40 PM
> 
> On Tue, Sep 3, 2024 at 7:36 AM Jiang, Haochen 
> wrote:
> >
> >
> >
> > > From: Hongtao Liu 
> > > Sent: Tuesday, September 3, 2024 1:47 PM
> > >
> > > On Tue, Sep 3, 2024 at 9:45 AM Jiang, Haochen via Gcc-regression
> > >  wrote:
> > > >
> > > > As each AVX10.2 testcases previously, this is caused by option
> combination
> > > warning,
> > > > which is expected.
> > > >
> > > Can we put the warning for mix usage of mavx10 and -mavx512f under -
> > > Wpsabi
> > > And add -Wno-psabi in addition to -march=cascadelake to avoid the
> > > false positive?
> >
> > We could do that if nobody has objection to that.
> 
> But mixing both doesn't do anything to the ABI so -Wpsabi sounds like the
> wrong bucket to me.  Instead we have to solve the issue at hand - I would
> expect users to run into this warning as well if we do within our testsuite?

If we can bear that "false positive", I suppose it is ok.

l will change the -march=cascadelake to the future CPU contains AVX10.2
when it is doable to eliminate them.

Thx,
Haochen

> 
> Richard.
> 
> > Thx,
> > Haochen
> >
> > >
> > > --
> > > BR,
> > > Hongtao


RE: [r15-429 Regression] FAIL: experimental/simd/pr109261_constexpr_simd.cc -msse2 -O2 -Wno-psabi (test for excess errors) on Linux/x86_64

2024-05-14 Thread Jiang, Haochen via Gcc-regression
Hi Matthias,

From my side, I get several error like this:

/export/users/haochenj/src/gcc-bisect/master/master/r15-429/bld/x86_64-linux/32/libstdc++-v3/include/experimental/bits/simd_builtin.h:131:
 error: could not convert 
'std::experimental::parallelism_v2::__vec_shuffle<__vector(4) wchar_t, 
__extract_part<2, 3, 2, wchar_t, 3>(_SimdWrapper)::, std::integer_sequence 
>(std::experimental::parallelism_v2::__as_vector<_SimdWrapper 
>(__x), (std::make_index_sequence<2>(), std::make_index_sequence<2>()), 
(std::experimental::parallelism_v2::__extract_part<2, 3, 
2, wchar_t, 3>(_SimdWrapper)::(), 
std::experimental::parallelism_v2::__extract_part<2, 3, 2, wchar_t, 
3>(_SimdWrapper)::()))' from 
'__vector(2) wchar_t' to 'std::conditional_t >' {aka 
'std::conditional >::type'}

See if this helps.

Thx,
Haochen

> -Original Message-
> From: Matthias Kretz 
> Sent: Tuesday, May 14, 2024 9:26 PM
> To: Jiang, Haochen 
> Cc: gcc-regression@gcc.gnu.org; gcc-patc...@gcc.gnu.org
> Subject: Re: [r15-429 Regression] FAIL:
> experimental/simd/pr109261_constexpr_simd.cc -msse2 -O2 -Wno-psabi (test
> for excess errors) on Linux/x86_64
> 
> Thanks for the report. But I'm unable to reproduce the issue. I'm testing on a
> Skylake-AVX512 system. I even did a clean rebuild of all of GCC using your
> configuration (minus your prefix) and still no failure.
> 
> Could you please send me your libstdc++.log after failing the test?
> 
> Best,
>   Matthias
> 
> On Montag, 13. Mai 2024 18:55:13 MESZ haochen. jiang wrote:
> > On Linux/x86_64,
> >
> > fb1649f8b4ad5043dd0e65e4e3a643a0ced018a9 is the first bad commit
> > commit fb1649f8b4ad5043dd0e65e4e3a643a0ced018a9
> > Author: Matthias Kretz 
> > Date:   Mon May 6 12:13:55 2024 +0200
> >
> > libstdc++: Use __builtin_shufflevector for simd split and concat
> >
> > caused
> >
> > FAIL: experimental/simd/pr109261_constexpr_simd.cc -msse2 -O2 -Wno-psabi
> > (test for excess errors)
> >
> > with GCC configured with
> >
> > ../../gcc/configure
> > --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-429/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}/x86_64-linux/libstdc++-v3/testsuite && make check
> >
> RUNTESTFLAGS="conformance.exp=experimental/simd/pr109261_constexpr_si
> md.cc
> > --target_board='unix{-m32}'"
> >
> > (Please do not reply to this email, for question about this report, contact
> > me at haochen dot jiang at intel.com.) (If you met problems with
> > cascadelake related, disabling AVX512F in command line might save that.)
> > (However, please make sure that there is no potential problems with
> > AVX512.)
> 
> 
> --
> ─
> ─
>  Dr. Matthias Kretz   https://mattkretz.github.io
>  GSI Helmholtz Center for Heavy Ion Research   https://gsi.de
>  std::simd
> ─
> ─


[r15-579 Regression] FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O2 (test for excess errors) on Linux/x86_64

2024-05-19 Thread Jiang, Haochen via Gcc-regression
On Linux/x86_64,

a9251ab3c91c8c559d0306838575a666ae62dff4 is the first bad commit
commit a9251ab3c91c8c559d0306838575a666ae62dff4
Author: Richard Biener 
Date:   Thu May 16 12:35:28 2024 +0200

wrong code with points-to and volatile

caused


with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-579/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}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="c++.exp=libgomp.oacc-c-c++-common/acc_prof-kernels-1.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="c++.exp=libgomp.oacc-c-c++-common/acc_prof-kernels-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="c++.exp=libgomp.oacc-c-c++-common/acc_prof-kernels-1.c 
--target_board='unix{-m64}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="c++.exp=libgomp.oacc-c-c++-common/acc_prof-kernels-1.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at haochen dot jiang at intel.com.)
(If you met problems with cascadelake related, disabling AVX512F in command 
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)


RE: [r15-983 Regression] FAIL: gcc.target/i386/avx10_1-25.c (test for excess errors) on Linux/x86_64

2024-06-03 Thread Jiang, Haochen via Gcc-regression
The fail is expected since -march=cascadelake -mavx10.1-256 will lead to a 
warning.
Also, we could not use -mno-avx512f with -mavx10.1-256, which also lead to a 
warning.

> -Original Message-
> From: haochen.jiang 
> Sent: Monday, June 3, 2024 10:22 PM
> To: Jiang, Haochen ; gcc-regression@gcc.gnu.org;
> gcc-patc...@gcc.gnu.org
> Subject: [r15-983 Regression] FAIL: gcc.target/i386/avx10_1-25.c (test for
> excess errors) on Linux/x86_64
> 
> On Linux/x86_64,
> 
> 1f2ca510065a2033bac408eb5a960ef0126f25cc is the first bad commit
> commit 1f2ca510065a2033bac408eb5a960ef0126f25cc
> Author: Haochen Jiang 
> Date:   Mon May 20 15:52:32 2024 +0800
> 
> Add AVX10.1 target_clones support
> 
> caused
> 
> FAIL: gcc.target/i386/avx10_1-25.c (test for excess errors)
> 
> with GCC configured with
> 
> ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-
> bisect/master/master/r15-983/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/avx10_1-25.c --
> target_board='unix{-m32\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="i386.exp=gcc.target/i386/avx10_1-25.c --
> target_board='unix{-m64\ -march=cascadelake}'"
> 
> (Please do not reply to this email, for question about this report, contact 
> me at
> haochen dot jiang at intel.com.) (If you met problems with cascadelake
> related, disabling AVX512F in command line might save that.) (However,
> please make sure that there is no potential problems with AVX512.)


RE: master branch: commit r15-2116 failed to bootstrap on Linux/x86_64 (commit r15-2111 builds)!

2024-07-17 Thread Jiang, Haochen via Gcc-regression
> -Original Message-
> From: Sam James 
> Sent: Thursday, July 18, 2024 12:48 PM
> To: haoch...@gnu-skx-1.sc.intel.com
> Cc: gcc-regression@gcc.gnu.org; gcc-testresu...@gcc.gnu.org; Jiang, Haochen
> 
> Subject: Re: master branch: commit r15-2116 failed to bootstrap on
> Linux/x86_64 (commit r15-2111 builds)!
> 
> Hi!
> 
> For future reports, would it be possible to change the grep to something
> like:
> 
> grep -E "(error:|Error)" or just grep -rsin "error" -w or something.
> 
> This would allow catching the actual compile error in libbacktrace if it's not
> going to fit in the last N lines from make.

Hi Sam,

Let me change that in the script and see if it is much clearer.

This bug report definitely seems not clear for me also.

Thx,
Haochen

> 
> (Not needed here as ILT already fixed the issue on master).
> 
> thanks,
> sam


gcc-regression script build fail info

2024-07-18 Thread Jiang, Haochen via Gcc-regression
> > For future reports, would it be possible to change the grep to
> > something
> > like:
> >
> > grep -E "(error:|Error)" or just grep -rsin "error" -w or something.
> >
> > This would allow catching the actual compile error in libbacktrace if
> > it's not going to fit in the last N lines from make.
> 
> Hi Sam,
> 
> Let me change that in the script and see if it is much clearer.
> 
> This bug report definitely seems not clear for me also.

Hi all,

Sam just mentioned in another thread that the current log for build
fail in gcc-regression is not clear at all, like the problem in:
https://gcc.gnu.org/pipermail/gcc-regression/2024-July/080272.html
The 100 bottom line didn't give any info for why it runs into a build fail.

As Sam suggested, we might change the build fail info part which is
currently using 'tail -100' to 'grep -E "(error:|Error)"' to get some clear
info.

Does any one still needs the 'tail -100' for some more info? Or if 
the output for 'grep -E "(error:|Error)" is enough?

For example, for r15-2116, overall report will be:

make[2]: Entering directory '/home/haochenj/src/gcc-regression'
rm -rf bld
mkdir -p bld
cd bld; \
 RUNTESTFLAGS="--target_board='unix{-m32,}'" ../src-master/configure \
--with-arch=native --with-cpu=native --enable-clocale=gnu 
--with-system-zlib --enable-shared --enable-cet --with-demangler-in-ld 
--enable-libmpx --prefix=/usr/gcc-15.0.0 --with-fpmath=sse
checking build system type... x86_64-pc-linux-gnu
grep "Error " makelog.r15-1643.x86_64.native >> 
makelog.r15-1643.x86_64.native.mail; \
make[6]: [Makefile:1832: x86_64-pc-linux-gnu/bits/largefile-config.h] Error 1 
(ignored)
make[6]: [Makefile:1831: x86_64-pc-linux-gnu/bits/largefile-config.h] Error 1 
(ignored)
make[6]: [Makefile:1832: x86_64-pc-linux-gnu/bits/largefile-config.h] Error 1 
(ignored)
../../src-master/gcc/config/i386/i386.cc:107:12: error: 'rtx_def* 
legitimize_dllimport_symbol(rtx, bool)' declared 'static' but never defined 
[-Werror=unused-function]
../../src-master/gcc/config/i386/i386.cc:108:12: error: 'rtx_def* 
legitimize_pe_coff_extern_decl(rtx, bool)' declared 'static' but never defined 
[-Werror=unused-function]
make[6]: *** [Makefile:2557: i386.o] Error 1
make[5]: *** [Makefile:5108: all-stage2-gcc] Error 2
make[4]: *** [Makefile:30031: stage2-bubble] Error 2
make[3]: *** [Makefile:30275: bootstrap] Error 2
make[2]: *** [Makefile:313: bootstrap] Error 2
make[1]: *** [Makefile:409: one] Error 1
make: *** [Makefile:406: one-master] Error 2

Thx,
Haochen

> 
> Thx,
> Haochen
> 
> >
> > (Not needed here as ILT already fixed the issue on master).
> >
> > thanks,
> > sam


RE: gcc-regression script build fail info

2024-07-18 Thread Jiang, Haochen via Gcc-regression



> -Original Message-
> From: Jiang, Haochen
> Sent: Thursday, July 18, 2024 3:46 PM
> To: 'Sam James' 
> Cc: 'gcc-regression@gcc.gnu.org' ; 'gcc-
> testresu...@gcc.gnu.org' ; g...@gcc.gnu.org
> Subject: gcc-regression script build fail info
> 
> > > For future reports, would it be possible to change the grep to
> > > something
> > > like:
> > >
> > > grep -E "(error:|Error)" or just grep -rsin "error" -w or something.
> > >
> > > This would allow catching the actual compile error in libbacktrace
> > > if it's not going to fit in the last N lines from make.
> >
> > Hi Sam,
> >
> > Let me change that in the script and see if it is much clearer.
> >
> > This bug report definitely seems not clear for me also.
> 
> Hi all,
> 
> Sam just mentioned in another thread that the current log for build fail in 
> gcc-
> regression is not clear at all, like the problem in:
> https://gcc.gnu.org/pipermail/gcc-regression/2024-July/080272.html
> The 100 bottom line didn't give any info for why it runs into a build fail.
> 
> As Sam suggested, we might change the build fail info part which is currently
> using 'tail -100' to 'grep -E "(error:|Error)"' to get some clear info.
> 
> Does any one still needs the 'tail -100' for some more info? Or if the output 
> for
> 'grep -E "(error:|Error)" is enough?
> 
> For example, for r15-2116, overall report will be:

Made a typo here, the report is generated from r15-1643.

> 
> make[2]: Entering directory '/home/haochenj/src/gcc-regression'
> rm -rf bld
> mkdir -p bld
> cd bld; \
>  RUNTESTFLAGS="--target_board='unix{-m32,}'" ../src-master/configure \
> --with-arch=native --with-cpu=native --enable-clocale=gnu 
> --with-system-
> zlib --enable-shared --enable-cet --with-demangler-in-ld --enable-libmpx --
> prefix=/usr/gcc-15.0.0 --with-fpmath=sse checking build system type...
> x86_64-pc-linux-gnu
> grep "Error " makelog.r15-1643.x86_64.native >> makelog.r15-
> 1643.x86_64.native.mail; \
> make[6]: [Makefile:1832: x86_64-pc-linux-gnu/bits/largefile-config.h] Error 1
> (ignored)
> make[6]: [Makefile:1831: x86_64-pc-linux-gnu/bits/largefile-config.h] Error 1
> (ignored)
> make[6]: [Makefile:1832: x86_64-pc-linux-gnu/bits/largefile-config.h] Error 1
> (ignored)
> ../../src-master/gcc/config/i386/i386.cc:107:12: error: 'rtx_def*
> legitimize_dllimport_symbol(rtx, bool)' declared 'static' but never defined [-
> Werror=unused-function]
> ../../src-master/gcc/config/i386/i386.cc:108:12: error: 'rtx_def*
> legitimize_pe_coff_extern_decl(rtx, bool)' declared 'static' but never 
> defined [-
> Werror=unused-function]
> make[6]: *** [Makefile:2557: i386.o] Error 1
> make[5]: *** [Makefile:5108: all-stage2-gcc] Error 2
> make[4]: *** [Makefile:30031: stage2-bubble] Error 2
> make[3]: *** [Makefile:30275: bootstrap] Error 2
> make[2]: *** [Makefile:313: bootstrap] Error 2
> make[1]: *** [Makefile:409: one] Error 1
> make: *** [Makefile:406: one-master] Error 2
> 
> Thx,
> Haochen
> 
> >
> > Thx,
> > Haochen
> >
> > >
> > > (Not needed here as ILT already fixed the issue on master).
> > >
> > > thanks,
> > > sam


RE: [r15-2135 Regression] FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -Os at line 32 (test for warnings, line 31) on Linux/x86_64

2024-07-18 Thread Jiang, Haochen via Gcc-regression
Hi Paul,

I suspect it is not the correct way to do that, those lines are ok since they 
are XFAIL. The problem is that specific warning test.

Thx,
Haochen

From: Paul Richard Thomas 
Sent: Friday, July 19, 2024 12:28 AM
To: haochen.jiang 
Cc: pa...@gcc.gnu.org; gcc-regression@gcc.gnu.org; gcc-patc...@gcc.gnu.org; 
Jiang, Haochen 
Subject: Re: [r15-2135 Regression] FAIL: 
libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable -Os at line 32 (test for warnings, line 
31) on Linux/x86_64

Hi Haochen,

Try removing lines 37-41 since these are precisely the bogus warnings that the 
patch is meant to eliminate.

Regards

Paul

On Thu, 18 Jul 2024 at 14:38, haochen.jiang 
mailto:haoch...@ecsmtp.sh.intel.com>> wrote:
On Linux/x86_64,

c3aa339ea50f050caf7ed2e497f5499ec2d7b9cc is the first bad commit
commit c3aa339ea50f050caf7ed2e497f5499ec2d7b9cc
Author: Paul Thomas mailto:pa...@gcc.gnu.org>>
Date:   Thu Jul 18 08:51:35 2024 +0100

Fortran: Suppress bogus used uninitialized warnings [PR108889].

caused

FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O0   at line 32 (test for warnings, line 
31)
FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O1   at line 32 (test for warnings, line 
31)
FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O2   at line 32 (test for warnings, line 
31)
FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions   at line 32 (test for warnings, line 
31)
FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -g   at line 32 (test for warnings, 
line 31)
FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -Os   at line 32 (test for warnings, line 
31)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-2135/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}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="fortran.exp=libgomp.oacc-fortran/privatized-ref-2.f90 
--target_board='unix{-m32}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="fortran.exp=libgomp.oacc-fortran/privatized-ref-2.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="fortran.exp=libgomp.oacc-fortran/privatized-ref-2.f90 
--target_board='unix{-m64}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="fortran.exp=libgomp.oacc-fortran/privatized-ref-2.f90 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at haochen dot jiang at intel.com.)
(If you met problems with cascadelake related, disabling AVX512F in command 
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)


RE: [r15-2135 Regression] FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -Os at line 32 (test for warnings, line 31) on Linux/x86_64

2024-07-18 Thread Jiang, Haochen via Gcc-regression
Just did a quick test. Correct myself previously. Those lines also
needs to be removed since they are XPASS now.

However the real issue is the dg-note at Line 32, that is the warning
disappeared.

diff --git a/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90 
b/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90
index 498ef70b63a..8cf79a10e8d 100644
--- a/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90
+++ b/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90
@@ -29,16 +29,10 @@ program main
   implicit none (type, external)
   integer :: j
   integer, allocatable :: A(:)
-  ! { dg-note {'a' declared here} {} { target *-*-* } .-1 }
   character(len=:), allocatable :: my_str
   character(len=15), allocatable :: my_str15

   A = [(3*j, j=1, 10)]
-  ! { dg-bogus {'a\.offset' is used uninitialized} {PR77504 etc.} { xfail 
*-*-* } .-1 }
-  ! { dg-bogus {'a\.dim\[0\]\.lbound' is used uninitialized} {PR77504 etc.} { 
xfail *-*-* } .-2 }
-  ! { dg-bogus {'a\.dim\[0\]\.ubound' is used uninitialized} {PR77504 etc.} { 
xfail *-*-* } .-3 }
-  ! { dg-bogus {'a\.dim\[0\]\.lbound' may be used uninitialized} {PR77504 
etc.} { xfail { ! __OPTIMIZE__ } } .-4 }
-  ! { dg-bogus {'a\.dim\[0\]\.ubound' may be used uninitialized} {PR77504 
etc.} { xfail { ! __OPTIMIZE__ } } .-5 }
   call foo (A, size(A))
   call bar (A)
   my_str = "1234567890"

After the change, all the tests are passed. However, is that right?

I am not familiar with either Fortran or libgomp, but the warning
like something declared here which might report variable declaration
conflict seems needed.

Thx,
Haochen

From: Jiang, Haochen
Sent: Friday, July 19, 2024 9:49 AM
To: Paul Richard Thomas 
Cc: pa...@gcc.gnu.org; gcc-regression@gcc.gnu.org; gcc-patc...@gcc.gnu.org
Subject: RE: [r15-2135 Regression] FAIL: 
libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable -Os at line 32 (test for warnings, line 
31) on Linux/x86_64

Hi Paul,

I suspect it is not the correct way to do that, those lines are ok since they 
are XFAIL. The problem is that specific warning test.

Thx,
Haochen

From: Paul Richard Thomas 
mailto:paul.richard.tho...@gmail.com>>
Sent: Friday, July 19, 2024 12:28 AM
To: haochen.jiang 
mailto:haoch...@ecsmtp.sh.intel.com>>
Cc: pa...@gcc.gnu.org; 
gcc-regression@gcc.gnu.org; 
gcc-patc...@gcc.gnu.org; Jiang, Haochen 
mailto:haochen.ji...@intel.com>>
Subject: Re: [r15-2135 Regression] FAIL: 
libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable -Os at line 32 (test for warnings, line 
31) on Linux/x86_64

Hi Haochen,

Try removing lines 37-41 since these are precisely the bogus warnings that the 
patch is meant to eliminate.

Regards

Paul

On Thu, 18 Jul 2024 at 14:38, haochen.jiang 
mailto:haoch...@ecsmtp.sh.intel.com>> wrote:
On Linux/x86_64,

c3aa339ea50f050caf7ed2e497f5499ec2d7b9cc is the first bad commit
commit c3aa339ea50f050caf7ed2e497f5499ec2d7b9cc
Author: Paul Thomas mailto:pa...@gcc.gnu.org>>
Date:   Thu Jul 18 08:51:35 2024 +0100

Fortran: Suppress bogus used uninitialized warnings [PR108889].

caused

FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O0   at line 32 (test for warnings, line 
31)
FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O1   at line 32 (test for warnings, line 
31)
FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O2   at line 32 (test for warnings, line 
31)
FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions   at line 32 (test for warnings, line 
31)
FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -O3 -g   at line 32 (test for warnings, 
line 31)
FAIL: libgomp.oacc-fortran/privatized-ref-2.f90 -DACC_DEVICE_TYPE_host=1 
-DACC_MEM_SHARED=1 -foffload=disable  -Os   at line 32 (test for warnings, line 
31)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-2135/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}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="fortran.exp=libgomp.oacc-fortran/privatized-ref-2.f90 
--target_board='unix{-m32}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check 
RUNTESTFLAGS="fortran.exp=libgomp.oacc-fortran/privatized-ref-2.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/x86_64-linu

RE: [r15-2196 Regression] FAIL: c-c++-common/dfp/convert-bfp-6.c -std=gnu++98 execution test on Linux/x86_64

2024-07-23 Thread Jiang, Haochen via Gcc-regression
It might be a false positive timeout alert. Please ignore that first.

Thx,
Haochen

> -Original Message-
> From: haochen.jiang 
> Sent: Tuesday, July 23, 2024 7:51 PM
> To: j...@ventanamicro.com; gcc-regression@gcc.gnu.org; gcc-
> patc...@gcc.gnu.org; Jiang, Haochen 
> Subject: [r15-2196 Regression] FAIL: c-c++-common/dfp/convert-bfp-6.c -
> std=gnu++98 execution test on Linux/x86_64
> 
> On Linux/x86_64,
> 
> 88d16194d0c8a6bdc2896c8944bfbf3e6038c9d2 is the first bad commit
> commit 88d16194d0c8a6bdc2896c8944bfbf3e6038c9d2
> Author: Jeff Law 
> Date:   Mon Jul 22 08:45:10 2024 -0600
> 
> [NFC][PR rtl-optimization/115877] Avoid setting irrelevant bit groups as 
> live
> in ext-dce
> 
> caused
> 
> FAIL: c-c++-common/dfp/convert-bfp-10.c execution test
> FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++14 execution test
> FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++17 execution test
> FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++20 execution test
> FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++98 execution test
> FAIL: c-c++-common/dfp/convert-bfp-6.c execution test
> FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++14 execution test
> FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++17 execution test
> FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++20 execution test
> FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++98 execution test
> 
> with GCC configured with
> 
> ../../gcc/configure --prefix=/export/users/haochenj/src/gcc-
> bisect/master/master/r15-2196/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="dfp.exp=c-c++-
> common/dfp/convert-bfp-10.c --target_board='unix{-m32}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="dfp.exp=c-c++-
> common/dfp/convert-bfp-10.c --target_board='unix{-m32\ -
> march=cascadelake}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="dfp.exp=c-c++-
> common/dfp/convert-bfp-6.c --target_board='unix{-m32}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="dfp.exp=c-c++-
> common/dfp/convert-bfp-6.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.) (If you met problems with cascadelake
> related, disabling AVX512F in command line might save that.) (However,
> please make sure that there is no potential problems with AVX512.)


RE: [r15-2196 Regression] FAIL: c-c++-common/dfp/convert-bfp-6.c -std=gnu++98 execution test on Linux/x86_64

2024-07-23 Thread Jiang, Haochen via Gcc-regression



> -Original Message-
> From: Jakub Jelinek 
> Sent: Wednesday, July 24, 2024 1:09 PM
> To: Jiang, Haochen 
> Cc: j...@ventanamicro.com; gcc-regression@gcc.gnu.org; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [r15-2196 Regression] FAIL: c-c++-common/dfp/convert-bfp-6.c
> -std=gnu++98 execution test on Linux/x86_64
> 
> On Wed, Jul 24, 2024 at 01:49:06AM +, Jiang, Haochen wrote:
> > It might be a false positive timeout alert. Please ignore that first.
> 
> It is not.  I'm seeing it too consistently on i686-linux:
> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c execution test
> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c execution test
> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++11
> execution test
> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++14
> execution test
> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++17
> execution test
> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++20
> execution test
> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++23
> execution test
> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++26
> execution test
> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++98
> execution test
> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++11
> execution test
> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++14
> execution test
> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++17
> execution test
> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++20
> execution test
> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++23
> execution test
> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++26
> execution test
> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++98
> execution test
> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c execution test
> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c execution test
> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++11
> execution test
> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++14
> execution test
> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++17
> execution test
> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++20
> execution test
> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++23
> execution test
> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++26
> execution test
> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++98
> execution test
> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++11
> execution test
> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++14
> execution test
> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++17
> execution test
> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++20
> execution test
> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++23
> execution test
> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++26
> execution test
> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++98
> execution test
> 
> The compilation of convert-bfp-6.c itself is identical between the older 
> (where
> it didn't fail) and newer (where it fails) builds, what has changed is 
> libgcc.a.
> In particular, what matters is libgcc/bid_binarydecimal.o.
> If I link all objects from libgcc from older (good libgcc) but 
> bid_binarydecimal.o
> (that one from newer bad libgcc), convert-bfp-6 still aborts, if I link all 
> objects
> from libgcc from newer (bad libgcc) but bid_binarydecimal.o (that one from
> older good libgcc), convert-bfp-6 works.

I see. If it is not a false alarm, then it seems to me that 
gcc-15-2212-gad642d2c950
from Jeff might fix the problem from the regression report. But I am not sure 
if it
really fix the problem or happen to be right.

Thx,
Haochen

> 
>   Jakub



RE: [r15-4833 Regression] FAIL: gcc.dg/builtin-prefetch-1.c (test for warnings, line 36) on Linux/x86_64

2024-11-01 Thread Jiang, Haochen via Gcc-regression
> From: haochen.jiang 
> Sent: Friday, November 1, 2024 4:32 PM
> 
> On Linux/x86_64,
> 
> e9ab41b79933d42410126f0eb7b29f820745276c is the first bad commit commit
> e9ab41b79933d42410126f0eb7b29f820745276c
> Author: Hu, Lin1 
> Date:   Fri Nov 1 10:04:40 2024 +0800
> 
> Support Intel MOVRS
> 
> caused
> 
> FAIL: gcc.c-torture/execute/builtin-prefetch-1.c   -O0  (test for excess 
> errors)
> FAIL: gcc.c-torture/execute/builtin-prefetch-1.c   -O1  (test for excess 
> errors)
> FAIL: gcc.c-torture/execute/builtin-prefetch-1.c   -O2 -flto 
> -fno-use-linker-plugin -
> flto-partition=none  (test for excess errors)
> FAIL: gcc.c-torture/execute/builtin-prefetch-1.c   -O2 -flto 
> -fuse-linker-plugin -
> fno-fat-lto-objects  (test for excess errors)
> FAIL: gcc.c-torture/execute/builtin-prefetch-1.c   -O2  (test for excess 
> errors)
> FAIL: gcc.c-torture/execute/builtin-prefetch-1.c   -O3 -g  (test for excess 
> errors)
> FAIL: gcc.c-torture/execute/builtin-prefetch-1.c   -Os  (test for excess 
> errors)
> FAIL: gcc.dg/builtin-prefetch-1.c (test for excess errors)
> FAIL: gcc.dg/builtin-prefetch-1.c  (test for warnings, line 31)
> FAIL: gcc.dg/builtin-prefetch-1.c  (test for warnings, line 32)
> FAIL: gcc.dg/builtin-prefetch-1.c  (test for warnings, line 33)
> FAIL: gcc.dg/builtin-prefetch-1.c  (test for warnings, line 34)
> FAIL: gcc.dg/builtin-prefetch-1.c  (test for warnings, line 35)
> FAIL: gcc.dg/builtin-prefetch-1.c  (test for warnings, line 36)
> 
Hmm... It seems that the last minute change I did in the patch did not get 
committed.

I will send out a patch to fix that.

Thx,
Haochen


RE: [r14-11845 Regression] FAIL: c-c++-common/tsan/tls_race.c -O2 output pattern test on Linux/x86_64

2025-06-15 Thread Jiang, Haochen via Gcc-regression


> From: haochen.jiang 
> Sent: Monday, June 16, 2025 11:42 AM
> To: a...@gjlay.de; gcc-regression@gcc.gnu.org; gcc-patc...@gcc.gnu.org;
> Jiang, Haochen 
> 
> On Linux/x86_64,
> 
> ddf8b0e06f27667b689dbd970d6c4ab0f088d671 is the first bad commit
> commit ddf8b0e06f27667b689dbd970d6c4ab0f088d671
> Author: Georg-Johann Lay 
> Date:   Thu Jun 12 10:07:37 2025 +0200
> 
> Fix test case for PR117811 which failed for int < 32 bit.
> 
> caused
> 
> FAIL: c-c++-common/tsan/tls_race.c   -O0  output pattern test
> FAIL: c-c++-common/tsan/tls_race.c   -O2  output pattern test
> 

Please disregard this.

I will shut down GCC 14 bisect for a while to see why it is still happening.

Thx,
Haochen


x86 Bisect script is currently down

2025-05-13 Thread Jiang, Haochen via Gcc-regression
Hi all,

During my vacation last three weeks, it seems to me that
my bisect script is down. After I am back from my holiday
this week, I found that the machine OS disk is totally down.

Please expect some time to bring that bisect script back. The
Test regression reporter is still running. (However, with quite
a few false positive for a long time due to timeout issue and
hard to fix unless I found other powerful machines.)

Thx,
Haochen


RE: x86 Bisect script is currently down

2025-05-18 Thread Jiang, Haochen via Gcc-regression
The script is back online for now. But still with some issues
on automation due to the machine config after crash.

I will run the script on at least a daily basis for a temporary
solution.

Thx,
Haochen

From: Jiang, Haochen
Sent: Wednesday, May 14, 2025 10:51 AM
To: gcc-regression@gcc.gnu.org
Subject: x86 Bisect script is currently down

Hi all,

During my vacation last three weeks, it seems to me that
my bisect script is down. After I am back from my holiday
this week, I found that the machine OS disk is totally down.

Please expect some time to bring that bisect script back. The
Test regression reporter is still running. (However, with quite
a few false positive for a long time due to timeout issue and
hard to fix unless I found other powerful machines.)

Thx,
Haochen


RE: [r16-1429 Regression] FAIL: g++.target/i386/vect-pragma-target-2.C -std=gnu++98 (test for excess errors) on Linux/x86_64

2025-06-12 Thread Jiang, Haochen via Gcc-regression
I will do that.

Thx,
Haochen

From: Andrew Pinski 
Sent: Thursday, June 12, 2025 10:52 PM
Cc: gb.de...@gmail.com; gcc-regression@gcc.gnu.org; GCC Patches 
; Jiang, Haochen 
Subject: Re: [r16-1429 Regression] FAIL: g++.target/i386/vect-pragma-target-2.C 
-std=gnu++98 (test for excess errors) on Linux/x86_64


On Wed, Jun 11, 2025, 10:17 PM haochen.jiang 
mailto:haoch...@smtp.intel.com>> wrote:
On Linux/x86_64,

dcb9af06212e8bb36e84a1b8498c625c29abeb6f is the first bad commit
commit dcb9af06212e8bb36e84a1b8498c625c29abeb6f
Author: Gwenole Beauchesne mailto:gb.de...@gmail.com>>
Date:   Mon Jun 2 14:44:55 2025 -0700

c/c++: Handle '#pragma GCC target optimize' early [PR48026]

caused

FAIL: gcc.target/i386/vect-pragma-target-1.c scan-assembler-times 
vpaddw.+zmm[0-9]+ 1
FAIL: g++.target/i386/vect-pragma-target-1.C  -std=gnu++17  
scan-assembler-times vpaddw.+zmm[0-9]+ 1
FAIL: g++.target/i386/vect-pragma-target-1.C  -std=gnu++26  
scan-assembler-times vpaddw.+zmm[0-9]+ 1
FAIL: g++.target/i386/vect-pragma-target-1.C  -std=gnu++98  
scan-assembler-times vpaddw.+zmm[0-9]+ 1


Can someone file a bug for this. It is just a testcase issue so I am willing to 
let it broken until I get back from vacation.




with GCC configured with

../../gcc/configure 
--prefix=/export/users3/haochenj/src/gcc-bisect/master/master/r16-1429/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/vect-pragma-target-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/vect-pragma-target-1.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=g++.target/i386/vect-pragma-target-1.C 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=g++.target/i386/vect-pragma-target-1.C 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at haochen dot jiang at intel.com)
(If you met problems with cascadelake related, disabling AVX512F in command 
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)


[r16-3810 Regression] FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-no.C -std=c++17 at line 21 (test for warnings, line 12) on Linux/x86_64

2025-09-12 Thread Jiang, Haochen via Gcc-regression
On Linux/x86_64,

6456da6bab8a2c43e7899afda991589065d96595 is the first bad commit
commit 6456da6bab8a2c43e7899afda991589065d96595
Author: Jonathan Wakely 
Date:   Thu Jul 17 22:02:45 2025 +0100

libstdc++: Make atomicity helpers use unsigned arithmetic [PR121148]

caused

FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers.C  -std=c++17  at 
line 12 (test for warnings, line 11)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers.C  -std=c++17 
telltale event that we are going within a deeper frame than 'main' (test for 
warnings, line 9)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers.C  -std=c++17 
(test for excess errors)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers.C  -std=c++26  at 
line 12 (test for warnings, line 11)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers.C  -std=c++26 
telltale event that we are going within a deeper frame than 'main' (test for 
warnings, line 9)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers.C  -std=c++26 
(test for excess errors)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-default.C  
-std=c++14  at line 12 (test for warnings, line 11)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-default.C  
-std=c++14  at line 17 (test for warnings, line 10)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-default.C  
-std=c++14  at line 18 (test for warnings, line 11)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-default.C  
-std=c++14  at line 19 (test for warnings, line 11)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-default.C  
-std=c++14  at line 20 (test for warnings, line 11)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-default.C  
-std=c++17  at line 12 (test for warnings, line 11)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-default.C  
-std=c++17  at line 18 (test for warnings, line 11)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-default.C  
-std=c++17  at line 19 (test for warnings, line 11)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-default.C  
-std=c++17  at line 20 (test for warnings, line 11)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-no.C  -std=c++14  
at line 13 (test for warnings, line 12)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-no.C  -std=c++14  
at line 18 (test for warnings, line 11)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-no.C  -std=c++14  
at line 19 (test for warnings, line 12)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-no.C  -std=c++14  
at line 20 (test for warnings, line 12)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-no.C  -std=c++14  
at line 21 (test for warnings, line 12)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-no.C  -std=c++17  
at line 13 (test for warnings, line 12)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-no.C  -std=c++17  
at line 19 (test for warnings, line 12)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-no.C  -std=c++17  
at line 20 (test for warnings, line 12)
FAIL: g++.dg/analyzer/fanalyzer-show-events-in-system-headers-no.C  -std=c++17  
at line 21 (test for warnings, line 12)

with GCC configured with

../../gcc/configure 
--prefix=/export/users3/haochenj/src/gcc-bisect/master/master/r16-3810/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="analyzer.exp=g++.dg/analyzer/fanalyzer-show-events-in-system-headers.C
 --target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="analyzer.exp=g++.dg/analyzer/fanalyzer-show-events-in-system-headers.C
 --target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="analyzer.exp=g++.dg/analyzer/fanalyzer-show-events-in-system-headers.C
 --target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="analyzer.exp=g++.dg/analyzer/fanalyzer-show-events-in-system-headers.C
 --target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="analyzer.exp=g++.dg/analyzer/fanalyzer-show-events-in-system-headers-default.C
 --target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="analyzer.exp=g++.dg/analyzer/fanalyzer-show-events-in-system-headers-default.C
 --target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="analyzer.exp=g++.dg/analyzer/fanalyzer-show-events-in-system-headers-default.C
 --target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="analyzer.exp=g++.dg/analyzer/fanalyzer-show-events-in-system-headers-default.C
 --target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="analyzer.e

RE: [r16-3760 Regression] FAIL: g++.target/i386/pr116896-1.C -std=gnu++23 scan-assembler-times \tjp\t 1 on Linux/x86_64

2025-09-12 Thread Jiang, Haochen via Gcc-regression
> From: Robin Dapp 
> Sent: Friday, September 12, 2025 2:53 PM
> 
> > FAIL: gcc.target/i386/pr116896.c scan-assembler-times \tjp\t 2
> > FAIL: g++.target/i386/pr116896-1.C  -std=gnu++20  scan-assembler-times
> \tjp\t 1
> > FAIL: g++.target/i386/pr116896-1.C  -std=gnu++23  scan-assembler-times
> \tjp\t 1
> > FAIL: g++.target/i386/pr116896-1.C  -std=gnu++26  scan-assembler-times
> \tjp\t 1
> >
> > with GCC configured with
> >
> > ../../gcc/configure --prefix=/export/users3/haochenj/src/gcc-
> bisect/master/master/r16-3760/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
> >
> 
> Grml, I had seen this error during testing but it didn't appear any more 
> during
> the final round with the latest patch version.
> 
> This is the difference:
> 
> Before:
> 
> foo:
> .LFB0:
> .cfi_startproc
> xorl%eax, %eax
> vcomiss %xmm1, %xmm0
> jp  .L2
> seta%al
> sbbl$0, %eax
> ret
> .L2:
> movl$2, %eax
> ret
>   .cfi_endproc
> 
> After:
> 
> foo:
> .LFB0:
> .cfi_startproc
> xorl%eax, %eax
> vcomiss %xmm1, %xmm0
> movl$2, %edx
> seta%al
> sbbl$0, %eax
> vucomiss%xmm1, %xmm0
> cmovp   %edx, %eax
> ret
>   .cfi_endproc
> 
> Is the "before" what we want, given the two other functions in the test are
> branchless?  I suppose so, as the if-converted sequence is pretty lengthy.
> 

I also believe that we should keep the before one. The main problem I suppose
would be the extra ucomi here. It is an even bigger problem than the conditional
jmp vs cmov originally in that PR.

Thx,
Haochen



[r16-3760 Regression] FAIL: g++.target/i386/pr116896-1.C -std=gnu++23 scan-assembler-times \tjp\t 1 on Linux/x86_64

2025-09-11 Thread Jiang, Haochen via Gcc-regression
On Linux/x86_64,

9ff5cadac4579fe714dc8de3a39eaef8534c64f7 is the first bad commit
commit 9ff5cadac4579fe714dc8de3a39eaef8534c64f7
Author: Robin Dapp 
Date:   Tue Sep 9 16:15:48 2025 +0200

ifcvt: Clarify if_info.original_cost.

caused

FAIL: gcc.target/i386/pr116896.c scan-assembler-times \tjp\t 2
FAIL: g++.target/i386/pr116896-1.C  -std=gnu++20  scan-assembler-times \tjp\t 1
FAIL: g++.target/i386/pr116896-1.C  -std=gnu++23  scan-assembler-times \tjp\t 1
FAIL: g++.target/i386/pr116896-1.C  -std=gnu++26  scan-assembler-times \tjp\t 1

with GCC configured with

../../gcc/configure 
--prefix=/export/users3/haochenj/src/gcc-bisect/master/master/r16-3760/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/pr116896.c --target_board='unix{-m32\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/pr116896.c --target_board='unix{-m64\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=g++.target/i386/pr116896-1.C --target_board='unix{-m32\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=g++.target/i386/pr116896-1.C --target_board='unix{-m64\ 
-march=cascadelake}'"

(Please directly reply to this email for question about this report.)
(If you met problems with cascadelake related, disabling AVX512F in command 
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)


RE: [r16-3364 Regression] FAIL: gcc.target/i386/shift-gf2p8affine-7.c scan-assembler-times vgf2p8affineqb 53 on Linux/x86_64

2025-08-28 Thread Jiang, Haochen via Gcc-regression
> From: Andi Kleen 
> Sent: Friday, August 29, 2025 5:13 AM
> > >
> > > with GCC configured with
> > >
> > > ../../gcc/configure --prefix=/export/users3/haochenj/src/gcc-
> bisect/master/master/r16-3364/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/shift-gf2p8affine-5.c --
> target_board='unix{-m32\ -march=cascadelake}'"
> 
> 
> Ah never mind it's there. The test breaks if you override
> -march=... because it changes the vector cost model and then
> the number of generated instructions is different.
> I've seen that with other tuning options too.
> 
> I'll see how to fix that. Perhaps it just needs to specify its own
> -march=generic which might take preference.
> 

It seems to me caused by more 256 bit vectorization enabled.

One of the simplest way is to strict to prefer-vector-width=128 and adjust
the testcase. But I am not sure if it meets the original need for the testcase.

Thx,
Haochen.


RE: [r16-3364 Regression] FAIL: gcc.target/i386/shift-gf2p8affine-7.c scan-assembler-times vgf2p8affineqb 53 on Linux/x86_64

2025-08-28 Thread Jiang, Haochen via Gcc-regression
> From: Andi Kleen 
> Sent: Friday, August 29, 2025 1:22 PM
> 
> This patch should fix it. Please confirm.
> 
> 
> diff --git a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-1.c
> b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-1.c
> index e5be3a35538..cb576eb4498 100644
> --- a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-1.c
> +++ b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-1.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-mgfni -mavx512vl -mavx512bw -mavx512f -O3" } */
> +/* { dg-options "-mgfni -mavx512vl -mavx512bw -mavx512f -O3 -
> march=x86-64 -mtune=generic" } */
>  /* { dg-final { scan-assembler-times "vgf2p8affineqb" 14 } } */
> 
>  #ifndef N
> diff --git a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-2.c
> b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-2.c
> index 098361aa9ab..c46af84bdcc 100644
> --- a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-2.c
> +++ b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-2.c
> @@ -1,5 +1,5 @@
>  /* { dg-do run } */
> -/* { dg-options "-mgfni -mavx512vl -mavx512bw -mavx512f -O3 -Wno-shift-
> count-negative" } */
> +/* { dg-options "-mgfni -mavx512vl -mavx512bw -mavx512f -O3 -Wno-
> shift-count-negative -march=x86-64 -mtune=generic" } */
> 
>  #include 
> 
> diff --git a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-3.c
> b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-3.c
> index 9e5ae5d19f3..2099f4edddf 100644
> --- a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-3.c
> +++ b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-3.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-mgfni -mavx512bw -mavx512f -O3" } */
> +/* { dg-options "-mgfni -mavx512bw -mavx512f -O3 -march=x86-64 -
> mtune=generic" } */
>  /* { dg-final { scan-assembler-times "vgf2p8affineqb" 12 } } */
> 
>  /* Based on a test case from Andrew Pinski */
> diff --git a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-5.c
> b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-5.c
> index 65fb69227e6..b8489a659a5 100644
> --- a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-5.c
> +++ b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-5.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-mgfni -mavx -O3 -Wno-shift-count-negative" } */
> +/* { dg-options "-mgfni -mavx -O3 -Wno-shift-count-negative -march=x86-
> 64 -mtune=generic" } */
>  /* { dg-final { scan-assembler-times "vgf2p8affineqb" 31 } } */

At least -mtune=generic won't fix this from my side.

gcc.target/i386/shift-gf2p8affine-5.c: vgf2p8affineqb found 53 times
FAIL: gcc.target/i386/shift-gf2p8affine-5.c scan-assembler-times vgf2p8affineqb 
31

Thx,
Haochen

> 
>  #include "shift-gf2p8affine-2.c"
> diff --git a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-6.c
> b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-6.c
> index 3391debd6c5..bf8d3418b38 100644
> --- a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-6.c
> +++ b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-6.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-mgfni -O3 -Wno-shift-count-negative" } */
> +/* { dg-options "-mgfni -O3 -Wno-shift-count-negative -march=x86-64 -
> mtune=generic" } */
>  /* { dg-final { scan-assembler-times "vgf2p8affineqb" 0 } } */
> 
>  #include "shift-gf2p8affine-2.c"
> diff --git a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-7.c
> b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-7.c
> index 37ba0c80ef8..8e93bb32e5d 100644
> --- a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-7.c
> +++ b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-7.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-options "-mgfni -mavx512vl -mavx512bw -mavx512f -O3 -Wno-shift-
> count-negative" } */
> +/* { dg-options "-mgfni -mavx512vl -mavx512bw -mavx512f -O3 -Wno-
> shift-count-negative -mtune=generic -march=x86-64" } */
>  /* { dg-final { scan-assembler-times "vgf2p8affineqb" 53 } } */
> 
>  #include "shift-gf2p8affine-2.c"


RE: [r16-3364 Regression] FAIL: gcc.target/i386/shift-gf2p8affine-7.c scan-assembler-times vgf2p8affineqb 53 on Linux/x86_64

2025-08-28 Thread Jiang, Haochen via Gcc-regression
> From: Jiang, Haochen
> Sent: Friday, August 29, 2025 1:48 PM
> 
> > From: Andi Kleen 
> > Sent: Friday, August 29, 2025 1:22 PM
> >
> > This patch should fix it. Please confirm.
> >
> >
> > diff --git a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-1.c
> > b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-1.c
> > index e5be3a35538..cb576eb4498 100644
> > --- a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-1.c
> > +++ b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-1.c
> > @@ -1,5 +1,5 @@
> >  /* { dg-do compile } */
> > -/* { dg-options "-mgfni -mavx512vl -mavx512bw -mavx512f -O3" } */
> > +/* { dg-options "-mgfni -mavx512vl -mavx512bw -mavx512f -O3 -
> > march=x86-64 -mtune=generic" } */
> >  /* { dg-final { scan-assembler-times "vgf2p8affineqb" 14 } } */
> >
> >  #ifndef N
> > diff --git a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-2.c
> > b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-2.c
> > index 098361aa9ab..c46af84bdcc 100644
> > --- a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-2.c
> > +++ b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-2.c
> > @@ -1,5 +1,5 @@
> >  /* { dg-do run } */
> > -/* { dg-options "-mgfni -mavx512vl -mavx512bw -mavx512f -O3 -Wno-
> shift-
> > count-negative" } */
> > +/* { dg-options "-mgfni -mavx512vl -mavx512bw -mavx512f -O3 -Wno-
> > shift-count-negative -march=x86-64 -mtune=generic" } */
> >
> >  #include 
> >
> > diff --git a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-3.c
> > b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-3.c
> > index 9e5ae5d19f3..2099f4edddf 100644
> > --- a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-3.c
> > +++ b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-3.c
> > @@ -1,5 +1,5 @@
> >  /* { dg-do compile } */
> > -/* { dg-options "-mgfni -mavx512bw -mavx512f -O3" } */
> > +/* { dg-options "-mgfni -mavx512bw -mavx512f -O3 -march=x86-64 -
> > mtune=generic" } */
> >  /* { dg-final { scan-assembler-times "vgf2p8affineqb" 12 } } */
> >
> >  /* Based on a test case from Andrew Pinski */
> > diff --git a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-5.c
> > b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-5.c
> > index 65fb69227e6..b8489a659a5 100644
> > --- a/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-5.c
> > +++ b/gcc/testsuite/gcc.target/i386/shift-gf2p8affine-5.c
> > @@ -1,5 +1,5 @@
> >  /* { dg-do compile } */
> > -/* { dg-options "-mgfni -mavx -O3 -Wno-shift-count-negative" } */
> > +/* { dg-options "-mgfni -mavx -O3 -Wno-shift-count-negative -march=x86-
> > 64 -mtune=generic" } */
> >  /* { dg-final { scan-assembler-times "vgf2p8affineqb" 31 } } */
> 
> At least -mtune=generic won't fix this from my side.
> 
> gcc.target/i386/shift-gf2p8affine-5.c: vgf2p8affineqb found 53 times
> FAIL: gcc.target/i386/shift-gf2p8affine-5.c scan-assembler-times
> vgf2p8affineqb 31
> 

Sorry, mine. I just found you also added -march=x86-64. Then it should be
fixed everywhere.

Thx,
Haochen


FW: [r16-3364 Regression] FAIL: gcc.target/i386/shift-gf2p8affine-7.c scan-assembler-times vgf2p8affineqb 53 on Linux/x86_64

2025-08-26 Thread Jiang, Haochen via Gcc-regression
On Linux/x86_64,

001cd39749f94ece8276b63f91eb864babb81a5d is the first bad commit
commit 001cd39749f94ece8276b63f91eb864babb81a5d
Author: Andi Kleen 
Date:   Sun Aug 3 17:35:39 2025 -0700

Use x86 GFNI for vectorized constant byte shifts/rotates

caused

FAIL: gcc.target/i386/shift-gf2p8affine-5.c scan-assembler-times vgf2p8affineqb 
31
FAIL: gcc.target/i386/shift-gf2p8affine-6.c scan-assembler-times vgf2p8affineqb 0
FAIL: gcc.target/i386/shift-gf2p8affine-7.c scan-assembler-times vgf2p8affineqb 
53

with GCC configured with

../../gcc/configure 
--prefix=/export/users3/haochenj/src/gcc-bisect/master/master/r16-3364/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/shift-gf2p8affine-5.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/shift-gf2p8affine-5.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/shift-gf2p8affine-6.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/shift-gf2p8affine-6.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/shift-gf2p8affine-7.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/shift-gf2p8affine-7.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please directly reply to this email for question about this report.)
(If you met problems with cascadelake related, disabling AVX512F in command 
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)


[r16-3379 Regression] FAIL: gcc.dg/debug/ctf/ctf-array-7.c (test for excess errors) on Linux/x86_64

2025-08-26 Thread Jiang, Haochen via Gcc-regression
On Linux/x86_64,

c77d79785d32b30502c8bcd6aa53b63d715bb124 is the first bad commit
commit c77d79785d32b30502c8bcd6aa53b63d715bb124
Author: David Faust 
Date:   Wed Aug 6 09:24:40 2025 -0700

ctf: avoid overflow for array num elements [PR121411]

caused

FAIL: gcc.dg/debug/ctf/ctf-array-7.c (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users3/haochenj/src/gcc-bisect/master/master/r16-3379/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="ctf.exp=gcc.dg/debug/ctf/ctf-array-7.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="ctf.exp=gcc.dg/debug/ctf/ctf-array-7.c --target_board='unix{-m32\ 
-march=cascadelake}'"

(Please directly reply to this email for question about this report.)
(If you met problems with cascadelake related, disabling AVX512F in command 
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)


[r16-4069 Regression] FAIL: gfortran.dg/pr87908.f90 -Os (test for excess errors) on Linux/x86_64

2025-09-25 Thread Jiang, Haochen via Gcc-regression
On Linux/x86_64,

e77daa57300ba2cb116af8dd24f58cad00dc669c is the first bad commit
commit e77daa57300ba2cb116af8dd24f58cad00dc669c
Author: Paul Thomas 
Date:   Wed Sep 24 08:01:23 2025 +0100

Fortran: Fix ICE in check_interface [PR87908]

caused

FAIL: gfortran.dg/pr87908.f90   -O0  (internal compiler error: Segmentation 
fault)
FAIL: gfortran.dg/pr87908.f90   -O0  (test for excess errors)
FAIL: gfortran.dg/pr87908.f90   -O1  (internal compiler error: Segmentation 
fault)
FAIL: gfortran.dg/pr87908.f90   -O1  (test for excess errors)
FAIL: gfortran.dg/pr87908.f90   -O2  (internal compiler error: Segmentation 
fault)
FAIL: gfortran.dg/pr87908.f90   -O2  (test for excess errors)
FAIL: gfortran.dg/pr87908.f90   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  (internal compiler error: 
Segmentation fault)
FAIL: gfortran.dg/pr87908.f90   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/pr87908.f90   -O3 -g  (internal compiler error: Segmentation 
fault)
FAIL: gfortran.dg/pr87908.f90   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/pr87908.f90   -Os  (internal compiler error: Segmentation 
fault)
FAIL: gfortran.dg/pr87908.f90   -Os  (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users3/haochenj/src/gcc-bisect/master/master/r16-4069/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="dg.exp=gfortran.dg/pr87908.f90 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gfortran.dg/pr87908.f90 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gfortran.dg/pr87908.f90 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gfortran.dg/pr87908.f90 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please directly reply to this email for question about this report.)
(If you met problems with cascadelake related, disabling AVX512F in command 
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)