Re: RISC-V Pioneer Box for builder.sourceware.org gcc CI
Hi Jeff,
On Thu, Aug 08, 2024 at 09:51:24AM -0600, Jeff Law wrote:
> On 8/8/24 9:13 AM, Mark Wielaard wrote:
> >But I don't fully understand how the gcc testsuite detects whether rvv
> >is implemented. e.g. rvv.exp seems to just check whether the target is
> >RISC-V and if so just executes all tests assuming it can just set
> >-march=rv64gcv* and/or -mrvv-* and run the tests:
> >
> ># Exit immediately if this isn't a RISC-V target.
> >if ![istarget riscv*-*-*] then {
> > return
> >}
> >
> >Should that test be more precise? Or is there some other test that is?
> There's some bits to avoid run tests on targets that don't support
> V. But they may need adjustment to deal with those V0.7.1 systems.
>
> >
> >I do see some of the runtime tests have:
> >/* { dg-do run { target { riscv_v } } } */
> >
> >How exactly does that work? How does it determine the riscv_v target?
> It's all buried inside target-supports.exp.
Found check_effective_target_riscv_v_ok, which tries to execute
vsetivli. Which does work as expected. It is an rvv 1.0 instruction,
so produces an SIGILL on rvv 0.7.1 and so those runtime tests are
skipped as expected.
I did find two tests that use check_vect_support_and_set_flags and
then explicitly use dg-do run even if the effective target doesn't
support riscv_v.
gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c
Which I think just needs to use { dg-do run { target { riscv_v } } }
gcc/testsuite/gcc.dg/vect/pr101145.c
Which I don't know how to "skip".
Is there a generic "dg-require-effective-target supports vect"?
I thought there would be much more, but it turns out all other
failures aren't rvv runtime failures, but compile time failures.
> And yes, there are extreme serialization events in the build. The
> vector implementation for riscv really makes that problem worse.
> insn-recog, insn-output, insn-attrtab and their associated
> generation step can take significant time.
Sam suggested to use STAGE1_CFLAGS="-O2". That seems to help bootstrap
a bit (at least makes those long serialized compiles for those
generated files a bit quicker).
Cheers,
Mark
gcc-15-20240811 is now available
Snapshot gcc-15-20240811 is now available on https://gcc.gnu.org/pub/gcc/snapshots/15-20240811/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 15 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 2b23a444bcf7eb67cb04b431d8fd4fa6f65222de You'll find: gcc-15-20240811.tar.xz Complete GCC SHA256=11c3bf4fcb44309162d3e6c558aab48b27de8318e17f06b38da0f5634e4e1146 SHA1=7051c12d6955ae5ef9eb79afd404081dabc9f34c Diffs from 15-20240804 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-15 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
RE: [RFC] Summary of libgomp failures for offloading to nvptx from AArch64
> -Original Message-
> From: Richard Biener
> Sent: Monday, July 29, 2024 7:18 PM
> To: Prathamesh Kulkarni
> Cc: gcc@gcc.gnu.org
> Subject: Re: [RFC] Summary of libgomp failures for offloading to nvptx
> from AArch64
>
> External email: Use caution opening links or attachments
>
>
> On Mon, Jul 29, 2024 at 1:35 PM Prathamesh Kulkarni
> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Richard Biener
> > > Sent: Friday, July 26, 2024 6:51 PM
> > > To: Prathamesh Kulkarni
> > > Cc: gcc@gcc.gnu.org
> > > Subject: Re: [RFC] Summary of libgomp failures for offloading to
> > > nvptx from AArch64
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On Thu, Jul 25, 2024 at 3:36 PM Prathamesh Kulkarni via Gcc
> > > wrote:
> > > >
> > > > Hi,
> > > > I am working on enabling offloading to nvptx from AAarch64 host.
> > > > As mentioned on wiki
> > > > (https://gcc.gnu.org/wiki/Offloading#Running_.27make_check.27),
> > > > I ran make check-target-libgomp on AAarch64 host (and no GPU)
> with
> > > following results:
> > > >
> > > > === libgomp Summary ===
> > > >
> > > > # of expected passes14568
> > > > # of unexpected failures1023
> > > > # of expected failures 309
> > > > # of untested testcases 54
> > > > # of unresolved testcases 992
> > > > # of unsupported tests 644
> > > >
> > > > It seems majority of the tests fail due to the following 4
> issues:
> > > >
> > > > * Compiling a minimal test-case:
> > > >
> > > > int main()
> > > > {
> > > > int x;
> > > > #pragma omp target map (to: x)
> > > > {
> > > > x = 0;
> > > > }
> > > > return x;
> > > > }
> > > >
> > > > Compiling with -fopenmp -foffload=nvptx-none results in
> following
> > > issues:
> > > >
> > > > (1) Differing values of NUM_POLY_INT_COEFFS between host and
> > > accelerator, which results in following ICE:
> > > >
> > > > 0x1a6e0a7 pp_quoted_string
> > > > ../../gcc/gcc/pretty-print.cc:2277
> > > > 0x1a6ffb3 pp_format(pretty_printer*, text_info*, urlifier
> const*)
> > > > ../../gcc/gcc/pretty-print.cc:1634
> > > > 0x1a4a3f3
> diagnostic_context::report_diagnostic(diagnostic_info*)
> > > > ../../gcc/gcc/diagnostic.cc:1612
> > > > 0x1a4a727 diagnostic_impl
> > > > ../../gcc/gcc/diagnostic.cc:1775 0x1a4e20b
> > > > fatal_error(unsigned int, char const*, ...)
> > > > ../../gcc/gcc/diagnostic.cc:2218 0xb3088f
> > > > lto_input_mode_table(lto_file_decl_data*)
> > > > ../../gcc/gcc/lto-streamer-in.cc:2121
> > > > 0x6f5cdf lto_file_finalize
> > > > ../../gcc/gcc/lto/lto-common.cc:2285
> > > > 0x6f5cdf lto_create_files_from_ids
> > > > ../../gcc/gcc/lto/lto-common.cc:2309
> > > > 0x6f5cdf lto_file_read
> > > > ../../gcc/gcc/lto/lto-common.cc:2364
> > > > 0x6f5cdf read_cgraph_and_symbols(unsigned int, char const**)
> > > > ../../gcc/gcc/lto/lto-common.cc:2812
> > > > 0x6cfb93 lto_main()
> > > > ../../gcc/gcc/lto/lto.cc:658
> > > >
> > > > This is already tracked in https://gcc.gnu.org/PR96265 (and
> > > > related
> > > > PR's)
> > > >
> > > > Streaming out mode_table:
> > > > mode = SI, mclass = 2, size = 4, prec = 32 mode = DI, mclass =
> 2,
> > > size
> > > > = 8, prec = 64
> > > >
> > > > Streaming in mode_table (in lto_input_mode_table):
> > > > mclass = 2, size = 4, prec = 0
> > > > (and then calculates the correct mode value by iterating over
> all
> > > > modes of mclass starting from narrowest mode)
> > > >
> > > > The issue is that the value for prec is not getting streamed-in
> > > > correctly for SImode as seen above. While streaming out from
> > > > AArch64
> > > host, it is 32, but while streaming in for nvptx, it is 0. This
> > > happens because of differing values of NUM_POLY_INT_COEFFS between
> > > AArch64 and nvptx backend.
> > > >
> > > > Since NUM_POLY_INT_COEFFS is 2 for aarch64, the streamed-out
> > > > values for mode, precision would be <4, 0> and <32, 0>
> > > > respectively (streamed-out in bp_pack_poly_value). Both zeros
> come
> > > > from coeffs[1] of size and prec. While streaming in however,
> > > > NUM_POLY_INT_COEFFS is
> > > 1 for nvptx, and thus it incorrectly treats <4, 0> as size and
> > > precision respectively, which is why precision gets streamed in as
> > > 0, and thus it encounters the above ICE.
> > > >
> > > > Supporting non VLA code with offloading:
> > > >
> > > > In the general case, it's hard to support offloading for
> arbitrary
> > > poly_ints when NUM_POLY_INT_COEFFS differs for host and
> accelerator.
> > > > For example, it's not possible to represent a degree-2 poly_int
> > > > like
> > > 4 + 4x (as-is) on an accelerator with NUM_POLY_INT_COEFFS == 1.
> > > >
> > > > However, IIUC, we can support offloading for restricted set of
> > > > poly_ints whose degree <= accel's NUM_POLY_INT_COEFFS, since
> they
> > > can
> > > > be represented on accelerator ? For a h
Re: [RFC] Summary of libgomp failures for offloading to nvptx from AArch64
On Sun, Aug 11, 2024 at 11:36 PM Prathamesh Kulkarni via Gcc
wrote:
>
>
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Monday, July 29, 2024 7:18 PM
> > To: Prathamesh Kulkarni
> > Cc: gcc@gcc.gnu.org
> > Subject: Re: [RFC] Summary of libgomp failures for offloading to nvptx
> > from AArch64
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Mon, Jul 29, 2024 at 1:35 PM Prathamesh Kulkarni
> > wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Richard Biener
> > > > Sent: Friday, July 26, 2024 6:51 PM
> > > > To: Prathamesh Kulkarni
> > > > Cc: gcc@gcc.gnu.org
> > > > Subject: Re: [RFC] Summary of libgomp failures for offloading to
> > > > nvptx from AArch64
> > > >
> > > > External email: Use caution opening links or attachments
> > > >
> > > >
> > > > On Thu, Jul 25, 2024 at 3:36 PM Prathamesh Kulkarni via Gcc
> > > > wrote:
> > > > >
> > > > > Hi,
> > > > > I am working on enabling offloading to nvptx from AAarch64 host.
> > > > > As mentioned on wiki
> > > > > (https://gcc.gnu.org/wiki/Offloading#Running_.27make_check.27),
> > > > > I ran make check-target-libgomp on AAarch64 host (and no GPU)
> > with
> > > > following results:
> > > > >
> > > > > === libgomp Summary ===
> > > > >
> > > > > # of expected passes14568
> > > > > # of unexpected failures1023
> > > > > # of expected failures 309
> > > > > # of untested testcases 54
> > > > > # of unresolved testcases 992
> > > > > # of unsupported tests 644
> > > > >
> > > > > It seems majority of the tests fail due to the following 4
> > issues:
> > > > >
> > > > > * Compiling a minimal test-case:
> > > > >
> > > > > int main()
> > > > > {
> > > > > int x;
> > > > > #pragma omp target map (to: x)
> > > > > {
> > > > > x = 0;
> > > > > }
> > > > > return x;
> > > > > }
> > > > >
> > > > > Compiling with -fopenmp -foffload=nvptx-none results in
> > following
> > > > issues:
> > > > >
> > > > > (1) Differing values of NUM_POLY_INT_COEFFS between host and
> > > > accelerator, which results in following ICE:
> > > > >
> > > > > 0x1a6e0a7 pp_quoted_string
> > > > > ../../gcc/gcc/pretty-print.cc:2277
> > > > > 0x1a6ffb3 pp_format(pretty_printer*, text_info*, urlifier
> > const*)
> > > > > ../../gcc/gcc/pretty-print.cc:1634
> > > > > 0x1a4a3f3
> > diagnostic_context::report_diagnostic(diagnostic_info*)
> > > > > ../../gcc/gcc/diagnostic.cc:1612
> > > > > 0x1a4a727 diagnostic_impl
> > > > > ../../gcc/gcc/diagnostic.cc:1775 0x1a4e20b
> > > > > fatal_error(unsigned int, char const*, ...)
> > > > > ../../gcc/gcc/diagnostic.cc:2218 0xb3088f
> > > > > lto_input_mode_table(lto_file_decl_data*)
> > > > > ../../gcc/gcc/lto-streamer-in.cc:2121
> > > > > 0x6f5cdf lto_file_finalize
> > > > > ../../gcc/gcc/lto/lto-common.cc:2285
> > > > > 0x6f5cdf lto_create_files_from_ids
> > > > > ../../gcc/gcc/lto/lto-common.cc:2309
> > > > > 0x6f5cdf lto_file_read
> > > > > ../../gcc/gcc/lto/lto-common.cc:2364
> > > > > 0x6f5cdf read_cgraph_and_symbols(unsigned int, char const**)
> > > > > ../../gcc/gcc/lto/lto-common.cc:2812
> > > > > 0x6cfb93 lto_main()
> > > > > ../../gcc/gcc/lto/lto.cc:658
> > > > >
> > > > > This is already tracked in https://gcc.gnu.org/PR96265 (and
> > > > > related
> > > > > PR's)
> > > > >
> > > > > Streaming out mode_table:
> > > > > mode = SI, mclass = 2, size = 4, prec = 32 mode = DI, mclass =
> > 2,
> > > > size
> > > > > = 8, prec = 64
> > > > >
> > > > > Streaming in mode_table (in lto_input_mode_table):
> > > > > mclass = 2, size = 4, prec = 0
> > > > > (and then calculates the correct mode value by iterating over
> > all
> > > > > modes of mclass starting from narrowest mode)
> > > > >
> > > > > The issue is that the value for prec is not getting streamed-in
> > > > > correctly for SImode as seen above. While streaming out from
> > > > > AArch64
> > > > host, it is 32, but while streaming in for nvptx, it is 0. This
> > > > happens because of differing values of NUM_POLY_INT_COEFFS between
> > > > AArch64 and nvptx backend.
> > > > >
> > > > > Since NUM_POLY_INT_COEFFS is 2 for aarch64, the streamed-out
> > > > > values for mode, precision would be <4, 0> and <32, 0>
> > > > > respectively (streamed-out in bp_pack_poly_value). Both zeros
> > come
> > > > > from coeffs[1] of size and prec. While streaming in however,
> > > > > NUM_POLY_INT_COEFFS is
> > > > 1 for nvptx, and thus it incorrectly treats <4, 0> as size and
> > > > precision respectively, which is why precision gets streamed in as
> > > > 0, and thus it encounters the above ICE.
> > > > >
> > > > > Supporting non VLA code with offloading:
> > > > >
> > > > > In the general case, it's hard to support offloading for
> > arbitrary
> > > > poly_ints when NUM_POLY_INT_COEFFS differs for host and
> > accelerator.
> > > > > For example, it's not
