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


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