Re: Commit missing from gcc-cvs and bugzilla
Hi Johann, On Sat, Aug 10, 2024 at 07:34:09PM +0200, Georg-Johann Lay wrote: > I just noticed that one of my commits, > > https://gcc.gnu.org/r15-2865 > > is missing from > > https://gcc.gnu.org/pipermail/gcc-cvs/2024-August/date.html > > Even though it has the tag "PR target/113934" the respective > PR didn't get a pointer to the commit: > > https://gcc.gnu.org/PR113934 > > Did I do something wrong? I cannot find a typo in the commit > message... That is odd indeed. We did have an issue when the user account name contained non-ascii characters. But that doesn't seem to be the case here. Also it does look like your commit today for PR target/85624 did generate an gcc-cvs email and bugzilla update. So hopefully it is a one time thing. Did you get any unusual output on that commit? Cheers, Mark
RE: [RFC] Summary of libgomp failures for offloading to nvptx from AArch64
> -Original Message-
> From: Andrew Pinski
> Sent: Monday, August 12, 2024 12:28 PM
> To: Prathamesh Kulkarni
> Cc: Richard Biener ; gcc@gcc.gnu.org;
> tschwi...@baylibre.com
> Subject: Re: [RFC] Summary of libgomp failures for offloading to nvptx
> from AArch64
>
> External email: Use caution opening links or attachments
>
>
> 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>
> > >
RE: gcc-regression script build fail info
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-regress...@gcc.gnu.org' ; 'gcc-
> testresu...@gcc.gnu.org' ; 'gcc@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-regress...@gcc.gnu.org' ; 'gcc-
> > testresu...@gcc.gnu.org' ; gcc@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
