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:
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
> -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
Re: insn attributes: Support blocks of C-code?
Am 17.07.24 um 20:49 schrieb Richard Sandiford:
Georg-Johann Lay writes:
[...]
Am 13.07.24 um 13:44 schrieb Richard Sandiford:
It shouldn't be necessary to emit the enum tag these days. If removing
Hi Richard,
I am not familiar with the gensupport policies, which is the reason why
the feature is just a suggestion / proposal and not a patch.
IMO patches should not come from someone like me who has no experience
in that area; better someone more experienced would take it over.
it causes anything to break, I think we should fix whatever that breaking
thing is. Could you try doing that, as a pre-patch? Or I can give it a
go, if you'd rather not.
Yes please.
OK, I pushed b19906a029a to remove the enum tags. The type name is
now stored as a const char * in attr_desc::cxx_type.
Great. With that in place, the feature would be something like the
attached delta (I didn't repeat the texi part).
There is one place where SYMBOL_REF issues fprint_c_condition in
line genattrtab.cc:3717 (after applying the delta) where I couln't
find a way to reach it.
And the "enum" in genattr.cc could be removed, too?
Johann
* read-md.h (fprint_c_condition): Add cxx_type parameter.
(print_c_condition): Same.
* genattrtab.cc (write_test_expr) [MATCH_TEST]: Pass down "bool"
as cxx_type argument to fprint_c_condition.
(write_attr_value) [SYMBOL_REF]: Pass down attr->cxx_type
as cxx_type argument to fprint_c_condition.
* genconditions.cc (write_one_condition): Pass down "$bool"
(bool with no capture) as cxx_type down to print_c_condition.
* genrecog.cc (print_test): Pass down "bool"
as cxx_type argument to print_c_condition.
* read-md.cc (md_reader::fprint_c_condition): Add cxx_type
parameter. Use it in lambda expression when cond is a block
of code.
(md_reader::print_c_condition): Add cxx_type parameter.
Pass it down to md_reader::fprint_c_condition.
If we do that, then we can just a return a const char * for the type.
Yes, const char* would be easier. I just didn't know how to alloc one,
and where. A new const char* property in class attr_desc_would solve
it.
And then in turn we can pass a const char * to (f)print_c_condition.
The MD reader then wouldn't need to know about attributes.
Thanks,
Richard
When this feature makes it into GCC, then match_test should behave
similar, I guess? I.e. support function bodies that return bool.
I just wasn't sure which caller of fprint_c_condition runs with
match_test resp. symbol_ref from which context (insn attribute or
predicate, etc).
Yeah, might be useful for match_test too.
Thanks for looking into this and for considering it as an extension.
The shortcomings like non-support of pathological comments like
/* } */ is probably not such a big issue. And fixing it would have
to touch the md scanner / lexer and have side effects I don't know,
like on build performance and stability of course. That part could
be fixed when someone actually needs it.
It looks like we don't support \{ and \}, but that's probably an oversight.
Thanks,
Richarddiff --git a/gcc/genattrtab.cc b/gcc/genattrtab.cc
index 2a51549ddd4..63ddef84469 100644
--- a/gcc/genattrtab.cc
+++ b/gcc/genattrtab.cc
@@ -3707,7 +3707,7 @@ write_test_expr (FILE *outf, rtx exp, unsigned int attrs_cached, int flags,
break;
case MATCH_TEST:
- rtx_reader_ptr->fprint_c_condition (outf, XSTR (exp, 0));
+ rtx_reader_ptr->fprint_c_condition (outf, XSTR (exp, 0), "bool");
if (flags & FLG_BITWISE)
fprintf (outf, " != 0");
break;
@@ -4385,7 +4385,8 @@ write_attr_value (FILE *outf, class attr_desc *attr, rtx value)
break;
case SYMBOL_REF:
- rtx_reader_ptr->fprint_c_condition (outf, XSTR (value, 0));
+ rtx_reader_ptr->fprint_c_condition (outf, XSTR (value, 0),
+ attr->cxx_type);
break;
case ATTR:
diff --git a/gcc/genconditions.cc b/gcc/genconditions.cc
index 13963dc3ff4..8a55f0f1033 100644
--- a/gcc/genconditions.cc
+++ b/gcc/genconditions.cc
@@ -141,9 +141,9 @@ write_one_condition (void **slot, void * ARG_UNUSED (dummy))
}
fputs ("\",\n__builtin_constant_p ", stdout);
- rtx_reader_ptr->print_c_condition (test->expr);
+ rtx_reader_ptr->print_c_condition (test->expr, "$bool");
fputs ("\n? (int) ", stdout);
- rtx_reader_ptr->print_c_condition (test->expr);
+ rtx_reader_ptr->print_c_condition (test->expr, "$bool");
fputs ("\n: -1 },\n", stdout);
return 1;
}
diff --git a/gcc/genrecog.cc b/gcc/genrecog.cc
index ba09ec3b600..c597958a487 100644
--- a/gcc/genrecog.cc
+++ b/gcc/genrecog.cc
@@ -4762,7 +4762,7 @@ print_test (output_state *os, const rtx_test &test, bool is_param,
gcc_assert (!is_param && value == 1);
if (invert_p)
printf ("!");
- rtx_reader_ptr->print_c_condition (test.u.string);
+ rtx_reader_ptr->print_c_condition (test.u.string, "bool");
brea
Re: How to implement Native TLS for a specific platform?
Hi Claudiu, Thanks for the tip, I've since looked at and drawn inspiration from arc.cc. The main issue I have now is how to implement the code in legitimize_tls_address under i386.cc and the corresponding i386.md machine description file to get the following assembly for a TLS read (Assuming that local is the name of the thread local variable, that the last mov depends on the size of the variable, since it would be movq if it was an 8 byte variable, that rscratch refers to scratch registers, and that rscratch1 holds the read TLS value at the end of the operation): movl _tls_index(%rip), %rscratch1 movq %gs:88, %rscratch2 movq (%rscratch2, %rscratch1, 8), %rscratch1 movl local@SECREL32(%rscratch1), %rscratch1 With some reference from the arc.cc code and another (unofficial) patch for the platform that I want to implement TLS for, I've managed a half finished implementation of TLS, but the final blocker so to speak is my lack of understanding on how the RTL manipulating code in legitimize_tls_address works. If you have any pointers on how to manipulate RTL to get the assembly required as seen above, I would be very much grateful :) best regards, Julian On Tue, Jul 16, 2024 at 8:16 PM Claudiu Zissulescu Ianculescu < claz...@gmail.com> wrote: > Hi Julian, > > You can check how we did it for ARC. In a nutshell, you need to define > HAVS_AS_TLS macro, you need to legitimize the new TLS address and > calls. Please have a look in arc.cc and search for TLS, also use git > blame to see the original patches. Of course, there are different ways > to implement TLS, in ARC is the simplest solution. Also, u need to > hack the assembler, linker and the OS for a full implementation. > > Cheers, > Claudiu > > On Tue, Jul 9, 2024 at 7:14 PM Julian Waters via Gcc > wrote: > > > > Hi all, > > > > I'm currently trying to implement Native TLS on a platform that gcc uses > > emutls for at the moment, but I can't seem to figure out where and how to > > implement it. I have a rough idea of the assembly required for TLS on > this > > platform, but I don't know where to plug it in to the compiler to make it > > work. Could someone point me in the right direction for implementing TLS > > for a platform that doesn't have it implemented at the moment? > > > > I'm aware that I am being vague as to which platform I want to implement > it > > for. It's a platform that is likely low priority in the eyes of most gcc > > maintainers, so I'm deliberately avoiding mentioning what platform it is > so > > I don't get crickets for a reply :) > > > > best regards, > > Julian >
Re: How to implement Native TLS for a specific platform?
I guess I'll just say what platform I want to implement this for, since the roundabout way of talking about it is probably confusing to everyone. It's Windows, and hopefully implementing TLS for it should be relatively easier since there is only 1 TLS model on Windows best regards, Julian On Thu, Jul 18, 2024 at 5:39 PM Julian Waters wrote: > Hi Claudiu, > > Thanks for the tip, I've since looked at and drawn inspiration from > arc.cc. The main issue I have now is how to implement the code in > legitimize_tls_address under i386.cc and the corresponding i386.md machine > description file to get the following assembly for a TLS read (Assuming > that local is the name of the thread local variable, that the last mov > depends on the size of the variable, since it would be movq if it was an 8 > byte variable, that rscratch refers to scratch registers, and that > rscratch1 holds the read TLS value at the end of the operation): > > movl _tls_index(%rip), %rscratch1 > movq %gs:88, %rscratch2 > movq (%rscratch2, %rscratch1, 8), %rscratch1 > movl local@SECREL32(%rscratch1), %rscratch1 > > With some reference from the arc.cc code and another (unofficial) patch > for the platform that I want to implement TLS for, I've managed a half > finished implementation of TLS, but the final blocker so to speak is my > lack of understanding on how the RTL manipulating code in > legitimize_tls_address works. If you have any pointers on how to manipulate > RTL to get the assembly required as seen above, I would be very much > grateful :) > > best regards, > Julian > > On Tue, Jul 16, 2024 at 8:16 PM Claudiu Zissulescu Ianculescu < > claz...@gmail.com> wrote: > >> Hi Julian, >> >> You can check how we did it for ARC. In a nutshell, you need to define >> HAVS_AS_TLS macro, you need to legitimize the new TLS address and >> calls. Please have a look in arc.cc and search for TLS, also use git >> blame to see the original patches. Of course, there are different ways >> to implement TLS, in ARC is the simplest solution. Also, u need to >> hack the assembler, linker and the OS for a full implementation. >> >> Cheers, >> Claudiu >> >> On Tue, Jul 9, 2024 at 7:14 PM Julian Waters via Gcc >> wrote: >> > >> > Hi all, >> > >> > I'm currently trying to implement Native TLS on a platform that gcc uses >> > emutls for at the moment, but I can't seem to figure out where and how >> to >> > implement it. I have a rough idea of the assembly required for TLS on >> this >> > platform, but I don't know where to plug it in to the compiler to make >> it >> > work. Could someone point me in the right direction for implementing TLS >> > for a platform that doesn't have it implemented at the moment? >> > >> > I'm aware that I am being vague as to which platform I want to >> implement it >> > for. It's a platform that is likely low priority in the eyes of most gcc >> > maintainers, so I'm deliberately avoiding mentioning what platform it >> is so >> > I don't get crickets for a reply :) >> > >> > best regards, >> > Julian >> >
tsvc test iteration count during check-gcc
The tsvc tests take just too long on simulators, particularly if there is little or no vectorization of the test because of compiler limitations, target limitations, or the chosen options. Having 151 tests time out at a quarter of an hour is not fun, and making the time out go away by upping the timeout might make for better looking results, but not for better turn-around times. So, I though to just change the iteration count (which is currently defined as 1 in tsvc.h, resulting in billions of operations for a single test) to something small, like 10. This requires new expected results, but there were pretty straightforward to auto-generate. The lack of a separate number for s3111 caused me some puzzlement, but it can indeed share a value with s3. But then if I want to specifically change the iteration count for simulators, I have to change 151 individual test files to add another dg-additional-options stanza. I can leave the job to grep / bash / ed, but then I get 151 locally changed files, which is a pain to merge. So I wonder if tsvc.h shouldn't really default to a low iteration count. Is there actually any reason to run the regression tests with an iteration count of 1 on any host? I mean, if you wanted to get some regression check on performance, you'd really want to have something more exact that wall clock time doesn't exceed whatever timeout is set. You could test set a ulimit for cpu time and fine tune that for proper benchmark regression test - but for the purposes of an ordinary gcc regression test, you generally just want the optimizations perfromed (like in the dump file tests present) and the computation be performed correctly. And for these, it makes little difference how many iterations you use for the test, as long as you convince GCC that the code is 'hot'.
Re: tsvc test iteration count during check-gcc
> Am 18.07.2024 um 16:20 schrieb Joern Wolfgang Rennecke > : > > The tsvc tests take just too long on simulators, particularly if there is > little or no vectorization of the test because of compiler limitations, > target limitations, or the chosen options. Having > 151 tests time out at a quarter of an hour is not fun, and making the time > out go away by upping the timeout might make for better looking results, but > not for better turn-around times. > > So, I though to just change the iteration count (which is currently defined > as 1 in tsvc.h, resulting in billions of operations for a single test) to > something small, like 10. > > This requires new expected results, but there were pretty straightforward to > auto-generate. The lack of a separate number for s3111 caused me some > puzzlement, but it can indeed share a value with s3. > > But then if I want to specifically change the iteration count for simulators, > I have to change 151 individual test files to add another > dg-additional-options stanza. I can leave the job to grep / bash / ed, > but then I get 151 locally changed files, which is a pain to merge. > So I wonder if tsvc.h shouldn't really default to a low iteration count. > Is there actually any reason to run the regression tests with an iteration > count of 1 on any host? Only laziness of not generating new expected outcomes. So I’m fine with lowering them. Richard > I mean, if you wanted to get some regression check on performance, you'd > really want to have something more exact that wall clock time doesn't exceed > whatever timeout is set. You could test set a ulimit for cpu time and fine > tune that for proper benchmark regression test - but for > the purposes of an ordinary gcc regression test, you generally just want the > optimizations perfromed (like in the dump file tests present) and the > computation be performed correctly. And for these, it makes little > difference how many iterations you use for the test, as long as you convince > GCC that the code is 'hot'.
gcc-12-20240718 is now available
Snapshot gcc-12-20240718 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20240718/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision c5a26fc24b0af61498fae65ccad69d51d63d2a8b You'll find: gcc-12-20240718.tar.xz Complete GCC SHA256=945248e2afcb6700273f032b705a1d2da0c662c9e1ac48860315e21229e12177 SHA1=1ff6ea9fe02426b856e7496248e091164afb9041 Diffs from 12-20240711 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 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.
