scan-*-dump-times across multiple functions considered harmful
Quite often I see a test quickly written to test some new feature (bug fix, extension or optimization) that has a couple of functions to cover various aspects of the feature, checked all together with a single scan-tree-dump-times, scan-rtl-dump-times etc. check, using the expected value for the target of the test writer. Or worse, it's all packed into one giant function, with unpredictable interactions between the different pieces of code. I think we have less of those recently, but please don't interpret this post as a suggestion to fall back to this practice. Quite often it turns out that the feature applies only to some of the functions / sites on some targets. The first reaction is often to create multiple copies of the scan-*-dump-times stanza, with mutually exclusive conditions for each copy, which might look harmless when there are only two cases, but as more are added, it quickly turns into an unmaintainable mess of lots dejagnu directives with complicated. This can get even worse if different targets can get the compiler the pattern multiple times for the same piece of source, like for vectorization that is tried with different vectorization factors. I think we should discuss what is best practice to address these problems efficiently, and to preferably write new tests avoiding them in the first place. When each function has a single site per feature where success is given if the pattern appears at least once, a straightforward solution that has already been used a number of times is to split the test into multiple smaller tests. The main disadvantages of this approach are that a large set of small files can clutter the directory where they appear, making it less maintainable, and that the compiler is invoked more often, generally with the same set of include files read each time, thus making the test runs slower. Another approach would be to use source line numbers, where present and distinctive, to add to the scan pattern to make it specific to the site under concern. That should, for instance, work for vectorization scan-tree-dump-times tests. The disadvantage of that approach is that the tests become more brittle, as the line numbers would have to be adjusted whenever the line numbers of the source site change, like when new include files, dejagnu directives at the file start, or typedefs are needed. Maybe we could get the best of both worlds if we add a new dump option? Say, if we make that option add the (for polymorphic languages like C++: mangled) name of the current function to each dumped line that is interesting to scan for. Or just every line, if that's simpler.
P.S. to: scan-*-dump-times across multiple functions considered harmful
P.S.: to get get the specifity of linenumbers without the brittleness, we could have a pragma for the extra dump line tag instead. Either till the next such pragme / EOF, or (if before next such pragma), till the end of function. Disadvantages: Not actually more specific when the source describes a template, or gets cloned. Unless we add the mangled filename too, either unconditionally, per option, or per format (complex, bugprone). The tag would have to be associated with or included in the source location. That might get complex and be a source of bugs in itself.
Re: Criteria for adding AIX as a secondary platform.
On Tue, Jul 01, 2025 at 09:44:50PM +0200, Eric Botcazou wrote: > > Some years ago (well, 5+ honestly) I was using I think 119 to help > > figure out some endian-specific bugs in a patch I was working on. It > > is slightly worrying if AIX/power support has bitrotted due to it > > being kicked off the primary/secondary platforms list, are there any > > other reasonably powerful big-endian targets developers can rely on > > and which are available on the compile farm? > > Yes, SPARC/Solaris, and it's much easier to work with than PowerPC/AIX. powerpc64-linux is on the compiler farm as well. Jakub
Re: Criteria for adding AIX as a secondary platform.
On Tue, Jul 1, 2025 at 8:59 AM Thomas Koenig via Gcc wrote: > > Am 30.06.25 um 20:47 schrieb Jonathan Wakely via Gcc: > > On Mon, 30 Jun 2025, 17:13 Thomas Koenig via Gcc, wrote: > > > >> Am 30.06.25 um 17:17 schrieb Richard Biener via Gcc: > >>> There used to be access to an AIX system on the compile farm, but I do > >> not know about the status of that. > >> > >> https://portal.cfarm.net/machines/list/ lists > >> cfarm111 and cfarm119 as AIX machines, a POWER7 > >> and POWER8 system, respectively. > >> > > > > Bootstrap works ok on cfarm119, with the right options. I haven't tried on > > cfarm111 for a few years. > > In the spirit of "Why not?" I gave this a spin. After replacing > make with gmake via a symlink in ~/bin (and setting the PATH > accordingly), I tried to run a bootstrap which failed somewhere > along the lines with > > checking for powerpc-ibm-aix7.1.5.0-gcc... gcc > checking whether the C compiler works... no > configure: error: in `/home/tkoenig/trunk-bin/mpfr': > configure: error: C compiler cannot create executables > See `config.log' for more details > > Not submitting a PR on this one, the environment on that > machine may be strange. > > Anyone wanting to get this to work will have their work cut out. > > If anybody wants to take a peek, /home/tkoenig is world-readable > on that machine. Some years ago (well, 5+ honestly) I was using I think 119 to help figure out some endian-specific bugs in a patch I was working on. It is slightly worrying if AIX/power support has bitrotted due to it being kicked off the primary/secondary platforms list, are there any other reasonably powerful big-endian targets developers can rely on and which are available on the compile farm? -- Janne Blomqvist
Re: Criteria for adding AIX as a secondary platform.
> Some years ago (well, 5+ honestly) I was using I think 119 to help > figure out some endian-specific bugs in a patch I was working on. It > is slightly worrying if AIX/power support has bitrotted due to it > being kicked off the primary/secondary platforms list, are there any > other reasonably powerful big-endian targets developers can rely on > and which are available on the compile farm? Yes, SPARC/Solaris, and it's much easier to work with than PowerPC/AIX. -- Eric Botcazou
smtgcc mid-year update
I have continued working on my translation validator, smtgcc [1]. Here is an update of what I have done since the end-of-year update. smtgcc-tv-backend - The main focus has been improving the smtgcc-tv-backend tool which checks that the generated assembly is a refinement of the final GIMPLE IR. Highlights: * Implemented most AArch64 SVE instructions * Implemented most RISC-V vector instructions * Improved performance There are still some limitations in the ABI support. This is not too problematic, as smtgcc reports "not implemented" instead of trying to analyze, so it avoids false positives. But it does restrict the range of code it can handle. The tool also still generates overly complicated SMT formulas for some common instructions, which makes tests time out unnecessarily. Add SMTGCC_ASM environment variable --- The smtgcc-tv-backend tool verifies that the generated assembly is a refinement of the final GIMPLE IR. It is now possible to override the file used for reading the assembly by setting the SMTGCC_ASM environment variable. This is useful for testing the implementation of smtgcc, but can also be used to verify hand-written assembly by letting smtgcc-tv-backend compare the GIMPLE from the C function against the provided assembly code instead of the compiler-generated output. Caching --- smtgcc can now cache SMT queries in a Redis database, and use the cached result when an identical query is submitted. This speeds up continuous testing of GCC a lot. GCC testing --- I am continuing with weekly runs of the GCC test suite. The testing is done with -fno-strict-aliasing and, for AArch64 and RISC-V, -fno-section-anchors, as type-based aliasing and section anchors are not yet supported by smtgcc. The tests are done on optimization levels: * -O3 * -O2 * -Os * -O1 * -O0 and for the following target flags (where I typically only run a subset of targets each week): * x86_64: - - -march=x86-64-v2 - -march=x86-64-v3 - -march=x86-64-v4 - -m32 * AArch64 - - -march=armv8.9-a - -march=armv9.5-a * RISC-V - -march=rv64gcbv - -march=rv64gcv - -march=rv64gcb - -march=rv64gc - -march=rv32gcbv - -march=rv32gcv - -march=rv32gcb - -march=rv32gc Please let me know if there are additional configurations you would like me to include in the testing. One GCC bug complicates this work: PR118669, which causes smtgcc to report many spurious vectorization failures for AArch64 and RISC-V. In practice, this forces me to ignore all failures in the vectorization pass. Reported GCC bugs - Most GCC bugs I have reported have been fixed, but there is currently one open bug where GCC generates incorrect code: PR113703. I have also reported several bugs where optimizations perform invalid transformations that introduce new undefined behavior, although these do not, in practice, miscompile code with the current pass ordering. The following are still open: PR106883, PR106884, PR109626, PR110760, PR111257, PR111280, PR111494, PR113590, PR114056, PR118669, PR119720. Plans - In the coming months, I plan to continue improving the current functionality. In particular: * Add the remaining AArch64 and RISC-V instructions * Implement full ABI support for AArch64 and RISC-V * Add support for restrict * Improve handling of uninitialized memory * Improve handling of pointer provenance * Fix false positives * Improve performance /Krister [1] https://github.com/kristerw/smtgcc/
Re: Criteria for adding AIX as a secondary platform.
Thank you all for your response. I would be posting regression test results regularly and will work on setting up a buildbot for AIX. I can see that currently the AIX build is broken with the below error. In file included from ./tm.h:25, from /opt/freeware/src/packages/BUILD/gcc/gcc/backend.h:28, from /opt/freeware/src/packages/BUILD/gcc/gcc/tree.cc:33: /opt/freeware/src/packages/BUILD/gcc/gcc/tree.cc: In function 'tree_node* generate_internal_label(const char*)': /opt/freeware/src/packages/BUILD/gcc/gcc/config/rs6000/xcoff.h:206:30: error: 'rs6000_xcoff_strip_dollar' was not declared in this scope 206 | sprintf (LABEL, "*%s..%u", rs6000_xcoff_strip_dollar (PREFIX), (unsigned) (NUM)) | ^ /opt/freeware/src/packages/BUILD/gcc/gcc/tree.cc:819:3: note: in expansion of macro 'ASM_GENERATE_INTERNAL_LABEL' 819 | ASM_GENERATE_INTERNAL_LABEL (tmp, prefix, num++); This seems to have caused by https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0337e3c2743ca0c57da8c6b78b725a7d83f0b721 Analysing more on this failure. Thanks, Sangamesh On Mon, Jun 30, 2025 at 8:48 PM David Edelsohn wrote: > The general criteria for primary, secondary, and tertiary platforms are > described on the page to which you linked. > > The choice of level is decided by the GCC Steering Committee in > consultation with the GCC Release Managers and the maintainers for the > targets / platforms. > > AIX is an unusual platform that always has required extra effort from the > GCC community. The reduction in participation and investment from IBM > means that the GCC community cannot tie its functional status to the > release criteria for GCC. > > Thanks, David > > On Mon, Jun 30, 2025 at 10:48 AM swamy sangamesh < > swamy.sangam...@gmail.com> wrote: > >> Hi All, >> >> Would like to know the criteria for adding AIX as a secondary platform. >> https://gcc.gnu.org/gcc-15/criteria.html >> >> Willing to participate in the work needed for the platform to be added as >> primary and secondary. >> >> >> -- >> Thanks & Regards, >> Sangamesh >> > -- Thanks & Regards, Sangamesh
Re: Criteria for adding AIX as a secondary platform.
On Tue, Jul 1, 2025 at 10:31 AM swamy sangamesh via Gcc wrote: > > Thank you all for your response. > > I would be posting regression test results regularly and will work on > setting up a buildbot for AIX. > > I can see that currently the AIX build is broken with the below error. > > In file included from ./tm.h:25, > from /opt/freeware/src/packages/BUILD/gcc/gcc/backend.h:28, > from /opt/freeware/src/packages/BUILD/gcc/gcc/tree.cc:33: > /opt/freeware/src/packages/BUILD/gcc/gcc/tree.cc: In function 'tree_node* > generate_internal_label(const char*)': > /opt/freeware/src/packages/BUILD/gcc/gcc/config/rs6000/xcoff.h:206:30: > error: 'rs6000_xcoff_strip_dollar' was not declared in this scope > 206 | sprintf (LABEL, "*%s..%u", rs6000_xcoff_strip_dollar (PREFIX), > (unsigned) (NUM)) > | ^ > /opt/freeware/src/packages/BUILD/gcc/gcc/tree.cc:819:3: note: in expansion > of macro 'ASM_GENERATE_INTERNAL_LABEL' > 819 | ASM_GENERATE_INTERNAL_LABEL (tmp, prefix, num++); > > This seems to have caused by > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0337e3c2743ca0c57da8c6b78b725a7d83f0b721 > > Analysing more on this failure. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120866#c4 explictly . Thanks, Andrew > > Thanks, > Sangamesh > > On Mon, Jun 30, 2025 at 8:48 PM David Edelsohn wrote: > > > The general criteria for primary, secondary, and tertiary platforms are > > described on the page to which you linked. > > > > The choice of level is decided by the GCC Steering Committee in > > consultation with the GCC Release Managers and the maintainers for the > > targets / platforms. > > > > AIX is an unusual platform that always has required extra effort from the > > GCC community. The reduction in participation and investment from IBM > > means that the GCC community cannot tie its functional status to the > > release criteria for GCC. > > > > Thanks, David > > > > On Mon, Jun 30, 2025 at 10:48 AM swamy sangamesh < > > swamy.sangam...@gmail.com> wrote: > > > >> Hi All, > >> > >> Would like to know the criteria for adding AIX as a secondary platform. > >> https://gcc.gnu.org/gcc-15/criteria.html > >> > >> Willing to participate in the work needed for the platform to be added as > >> primary and secondary. > >> > >> > >> -- > >> Thanks & Regards, > >> Sangamesh > >> > > > > -- > Thanks & Regards, > Sangamesh
Re: Criteria for adding AIX as a secondary platform.
On Tue, Jul 1, 2025 at 1:59 AM Thomas Koenig via Gcc wrote: > Am 30.06.25 um 20:47 schrieb Jonathan Wakely via Gcc: > > On Mon, 30 Jun 2025, 17:13 Thomas Koenig via Gcc, > wrote: > > > >> Am 30.06.25 um 17:17 schrieb Richard Biener via Gcc: > >>> There used to be access to an AIX system on the compile farm, but I do > >> not know about the status of that. > >> > >> https://portal.cfarm.net/machines/list/ lists > >> cfarm111 and cfarm119 as AIX machines, a POWER7 > >> and POWER8 system, respectively. > >> > > > > Bootstrap works ok on cfarm119, with the right options. I haven't tried > on > > cfarm111 for a few years. > > In the spirit of "Why not?" I gave this a spin. After replacing > make with gmake via a symlink in ~/bin (and setting the PATH > accordingly), I tried to run a bootstrap which failed somewhere > along the lines with > > checking for powerpc-ibm-aix7.1.5.0-gcc... gcc > checking whether the C compiler works... no > configure: error: in `/home/tkoenig/trunk-bin/mpfr': > configure: error: C compiler cannot create executables > See `config.log' for more details > > Not submitting a PR on this one, the environment on that > machine may be strange. > > Anyone wanting to get this to work will have their work cut out. > > If anybody wants to take a peek, /home/tkoenig is world-readable > on that machine. > Did you follow the instructions on the GCC Compile Farm wiki page about bootstrapping on AIX? David > > Best regards > > Thomas > >
