Re: [r15-2196 Regression] FAIL: c-c++-common/dfp/convert-bfp-6.c -std=gnu++98 execution test on Linux/x86_64
On Tue, Jul 30, 2024 at 03:03:39PM -0600, Jeff Law wrote: > > > 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. > Based on Jakub's comment, I'm going to assume it's a real issue related to > the compilation of the support code in libgcc and thus I need to do another > round of trying to reproduce. The testcases don't fail for me anymore, 20240722 (around 20:45 UTC) still failed, 20240726 (around 13:15 UTC) already didn't. Don't have record of exact revisions. Jakub
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. Jakub
Re: [r15-4988 Regression] FAIL: gcc.dg/gomp/max_vf-1.c scan-tree-dump-times ompexp "__builtin_GOMP_parallel_loop_nonmonotonic_dynamic \\(.*, 16, 0\\);" 1 on Linux/x86_64
On Thu, Nov 07, 2024 at 10:54:40AM +, Andrew Stubbs wrote:
> On 07/11/2024 00:37, haochen.jiang wrote:
> > d334f729e53867b838e867375b3f475ba793d96e is the first bad commit
> > commit d334f729e53867b838e867375b3f475ba793d96e
> > Author: Andrew Stubbs
> > Date: Wed Nov 6 12:26:08 2024 +
> >
> > openmp: Add testcases for omp_max_vf
> >
> > caused
> >
> > FAIL: gcc.dg/gomp/max_vf-1.c scan-tree-dump-times ompexp "\\+ 16" 1
> > FAIL: gcc.dg/gomp/max_vf-1.c scan-tree-dump-times ompexp "\\* 16" 2
> > FAIL: gcc.dg/gomp/max_vf-1.c scan-tree-dump-times ompexp
> > "__builtin_GOMP_parallel_loop_nonmonotonic_dynamic \\(.*, 16, 0\\);" 1
> >
> > with GCC configured with
> >
> > ../../gcc/configure
> > --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-4988/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="gomp.exp=gcc.dg/gomp/max_vf-1.c --target_board='unix{-m32\
> > -march=cascadelake}'"
> > $ cd {build_dir}/gcc && make check
> > RUNTESTFLAGS="gomp.exp=gcc.dg/gomp/max_vf-1.c --target_board='unix{-m64\
> > -march=cascadelake}'"
>
> This problem was supposed to be avoided by explicitly passing "-msse2" in
> the testcase. Apparently -march=cascadelake silently overrides that setting
> ... maybe don't do that?
What do yo mean by overrides?
-march=cascadelake -msse2
(or the other ordering too) certainly doesn't override the enabling of SSE2,
the -mISA and -mno-ISA flags take precedence over -march=; though other
flags can be set too from the -march= or its default set when configuring
the compiler.
So, if the testcase relies on SSE2 enabled and SSE3 not enabled, it should
use -msse2 -mno-sse3.
Seems the testcase actually relies on AVX not being enabled, so it should
use "-msse2 -mno-avx".
That will work fine even with -march=cascadelake, whether it is the default
or requested through --target_board.
Jakub
Re: [r15-4988 Regression] FAIL: gcc.dg/gomp/max_vf-1.c scan-tree-dump-times ompexp "__builtin_GOMP_parallel_loop_nonmonotonic_dynamic \\(.*, 16, 0\\);" 1 on Linux/x86_64
On Thu, Nov 07, 2024 at 11:31:17AM +, Andrew Stubbs wrote: > Anyway, I think the attached patch should fix it. It passes on my > configuration, but I don't have a Cascade Lake. You could have tested with whatever you have (if it has AVX) as -march= > OK? Yes, thanks. Jakub
