* [PATCH 0/3] Remove ia64*-*-linux from the list of obsolete targets [not found] ` <3DAB006A-ACE2-4BEC-AA01-87625DBEE259@exactcode.de> @ 2024-06-12 10:33 ` Rene Rebe 2024-06-12 10:42 ` [PATCH 1/3] " Rene Rebe ` (3 more replies) 0 siblings, 4 replies; 29+ messages in thread From: Rene Rebe @ 2024-06-12 10:33 UTC (permalink / raw) To: gcc-patches; +Cc: rguenther, frank.scheiner Hey there, I wanted to come back to maintaining the ia64 port as discussed preciously the other month on the gcc list. It has been some days as we were busy releasing the biggest release of our Embdded T2/Linux distribution [0] and we obviously did not want to propose to enable LRA for IA-64 in the last last days of the gcc 14 release process. We used the time to further stability test the LRA enabled GCC built in T2/Linux and set up running the GCC testsuite accordingly for which Frank posted test results from GCC git for reference [1] and w/ LRA [2] enabled with only minimal changes, but also some new testsuite passes. Due to the -j4 run I summed up the text files result manually in LibreOffice: gcc 35572, 31789 33273, 28492 37189, 36804 28735, 37634 sum 134769, 134719 g++ 69349, 61058 61467, 63545 61614, 63752 56027, 60102 sum 248457, 248457 gfortran 18895, 17502 19329, 19051 13950, 17583 17442, 15482 sum 69616, 69618 objc 693, 783 760, 669 609, 649 716, 677 sum 2778, 2778 ibstdc++ 4495, 4635 4001, 3629 3958, 4580 4970, 4580 sum 17424, 17424 The LRA enabled built Linux kernel and whole user-land packages boot and function normally, too. Instead of looking into random test suite failures, I would first rather try to allocate some time to look into some build failures for more advanced real-world open source packages that I observered over the last years and already occured unrelated of the LRA enablement. > > On Mar 7, 2024, at 20:08, Richard Biener <rguenther@suse.de> wrote: > >> I saw the deprecation of ia64*-*-* scrolling by [1]. > >> > >> Which surprised me, as (minor bugs aside) gcc ia64*-*-linux just works for us and > >> we still actively support it as part of our T2 System Development Environment [2]. > >> > >> For ia64 we are currently a team of three and also keep maintaining linux-kernel and > >> glibc git trees with ia64 restored and hope to bring back ia64 to linux upstream the > >> coming months as promised. [3] > >> > >> Despite popular believe ia64 actually just works for all those projects and we already > >> fixed the few minor bugs we could find or reproduce. > >> > >> Last week I also already patched and tested enabling LRA for ia64 in gcc [4] and could > >> -without any regression- compile a full ia64 T2/Linux release ISO that boots and runs > >> including an X desktop and Gtk applications. That was of course even with the latest > >> linux kernel and glibc versions with ia64 support restored respectively. > >> > >> Given there are currently no other volunteers, I therefore with this email step up and > >> offer to become ia64 maintainer for GCC to keep the code compiling, tested and > >> un-deprecated for the next years and releases to come. > > > > You’re welcome - we look forward to LRA enablement with ia64 and for it to get an > > active maintainer. Note maintainers are appointed by the Steering Committee. [0] https://t2sde.org/ [1] https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816346.html [2] https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816422.html -- René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin https://exactcode.com | https://t2sde.org | https://rene.rebe.de ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH 1/3] Remove ia64*-*-linux from the list of obsolete targets 2024-06-12 10:33 ` [PATCH 0/3] Remove ia64*-*-linux from the list of obsolete targets Rene Rebe @ 2024-06-12 10:42 ` Rene Rebe 2024-06-12 18:40 ` Jonathan Wakely 2024-06-13 8:58 ` Gerald Pfeifer 2024-06-12 10:42 ` [PATCH 2/3] Enabled LRA for ia64 Rene Rebe ` (2 subsequent siblings) 3 siblings, 2 replies; 29+ messages in thread From: Rene Rebe @ 2024-06-12 10:42 UTC (permalink / raw) To: gcc-patches; +Cc: rguenther, frank.scheiner The following un-deprecates ia64*-*-linux for GCC 15. Since we plan to support this for some years to come. gcc/ * config.gcc: Only exlicitly list ia64*-*-(hpux|vms|elf) in the list of obsoleted targets. contrib/ * config-list.mk (LIST): no --enable-obsolete for ia64*-*-linux. --- contrib/config-list.mk | 4 ++-- gcc/config.gcc | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/contrib/config-list.mk b/contrib/config-list.mk index f282cd95c8d..b99573b1f5b 100644 --- a/contrib/config-list.mk +++ b/contrib/config-list.mk @@ -60,8 +60,8 @@ LIST = \ i686-pc-linux-gnu i686-pc-msdosdjgpp i686-lynxos i686-nto-qnx \ i686-rtems i686-solaris2.11 i686-wrs-vxworks \ i686-wrs-vxworksae \ - i686-cygwinOPT-enable-threads=yes i686-mingw32crt ia64-elfOPT-enable-obsolete \ - ia64-linuxOPT-enable-obsolete ia64-hpuxOPT-enable-obsolete \ + i686-cygwinOPT-enable-threads=yes i686-mingw32crt linux-ia64 \ + ia64-elfOPT-enable-obsolete ia64-hpuxOPT-enable-obsolete ia64-hp-vmsOPT-enable-obsolete iq2000-elf lm32-elf \ lm32-rtems lm32-uclinux \ loongarch64-linux-gnuf64 loongarch64-linux-gnuf32 loongarch64-linux-gnusf \ diff --git a/gcc/config.gcc b/gcc/config.gcc index a37113bd00a..6d6ca6da7a0 100644 --- a/gcc/config.gcc +++ b/gcc/config.gcc @@ -272,7 +272,7 @@ esac # Obsolete configurations. case ${target} in - ia64*-*-* \ + ia64*-*-hpux* | ia64*-*-*vms* | ia64*-*-elf* \ | nios2*-*-* \ ) if test "x$enable_obsolete" != xyes; then -- 2.45.0 -- René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin https://exactcode.com | https://t2sde.org | https://rene.rebe.de ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/3] Remove ia64*-*-linux from the list of obsolete targets 2024-06-12 10:42 ` [PATCH 1/3] " Rene Rebe @ 2024-06-12 18:40 ` Jonathan Wakely 2024-06-12 18:48 ` Jonathan Wakely 2024-06-13 8:58 ` Gerald Pfeifer 1 sibling, 1 reply; 29+ messages in thread From: Jonathan Wakely @ 2024-06-12 18:40 UTC (permalink / raw) To: Rene Rebe; +Cc: gcc-patches, rguenther, frank.scheiner On 12/06/24 12:42 +0200, Rene Rebe wrote: >The following un-deprecates ia64*-*-linux for GCC 15. Since we plan to >support this for some years to come. > >gcc/ > * config.gcc: Only exlicitly list ia64*-*-(hpux|vms|elf) in the > list of obsoleted targets. > >contrib/ > * config-list.mk (LIST): no --enable-obsolete for ia64*-*-linux. >--- > contrib/config-list.mk | 4 ++-- > gcc/config.gcc | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > >diff --git a/contrib/config-list.mk b/contrib/config-list.mk >index f282cd95c8d..b99573b1f5b 100644 >--- a/contrib/config-list.mk >+++ b/contrib/config-list.mk >@@ -60,8 +60,8 @@ LIST = \ > i686-pc-linux-gnu i686-pc-msdosdjgpp i686-lynxos i686-nto-qnx \ > i686-rtems i686-solaris2.11 i686-wrs-vxworks \ > i686-wrs-vxworksae \ >- i686-cygwinOPT-enable-threads=yes i686-mingw32crt ia64-elfOPT-enable-obsolete \ >- ia64-linuxOPT-enable-obsolete ia64-hpuxOPT-enable-obsolete \ >+ i686-cygwinOPT-enable-threads=yes i686-mingw32crt linux-ia64 \ Shouldn't this be ia64-linux? And why reorder the entries? I would expect the change to be simply s/ia64-linuxOPT-enable-obsolete/ia64-linux/ >+ ia64-elfOPT-enable-obsolete ia64-hpuxOPT-enable-obsolete > ia64-hp-vmsOPT-enable-obsolete iq2000-elf lm32-elf \ > lm32-rtems lm32-uclinux \ > loongarch64-linux-gnuf64 loongarch64-linux-gnuf32 loongarch64-linux-gnusf \ >diff --git a/gcc/config.gcc b/gcc/config.gcc >index a37113bd00a..6d6ca6da7a0 100644 >--- a/gcc/config.gcc >+++ b/gcc/config.gcc >@@ -272,7 +272,7 @@ esac > > # Obsolete configurations. > case ${target} in >- ia64*-*-* \ >+ ia64*-*-hpux* | ia64*-*-*vms* | ia64*-*-elf* \ > | nios2*-*-* \ > ) > if test "x$enable_obsolete" != xyes; then >-- >2.45.0 > > >-- > René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin > https://exactcode.com | https://t2sde.org | https://rene.rebe.de ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/3] Remove ia64*-*-linux from the list of obsolete targets 2024-06-12 18:40 ` Jonathan Wakely @ 2024-06-12 18:48 ` Jonathan Wakely 0 siblings, 0 replies; 29+ messages in thread From: Jonathan Wakely @ 2024-06-12 18:48 UTC (permalink / raw) To: Rene Rebe; +Cc: gcc-patches, rguenther, frank.scheiner On 12/06/24 19:40 +0100, Jonathan Wakely wrote: >On 12/06/24 12:42 +0200, Rene Rebe wrote: >>The following un-deprecates ia64*-*-linux for GCC 15. Since we plan to >>support this for some years to come. >> >>gcc/ >> * config.gcc: Only exlicitly list ia64*-*-(hpux|vms|elf) in the "exlicitly" >> list of obsoleted targets. >> >>contrib/ >> * config-list.mk (LIST): no --enable-obsolete for ia64*-*-linux. >>--- >>contrib/config-list.mk | 4 ++-- >>gcc/config.gcc | 2 +- >>2 files changed, 3 insertions(+), 3 deletions(-) >> >>diff --git a/contrib/config-list.mk b/contrib/config-list.mk >>index f282cd95c8d..b99573b1f5b 100644 >>--- a/contrib/config-list.mk >>+++ b/contrib/config-list.mk >>@@ -60,8 +60,8 @@ LIST = \ >> i686-pc-linux-gnu i686-pc-msdosdjgpp i686-lynxos i686-nto-qnx \ >> i686-rtems i686-solaris2.11 i686-wrs-vxworks \ >> i686-wrs-vxworksae \ >>- i686-cygwinOPT-enable-threads=yes i686-mingw32crt ia64-elfOPT-enable-obsolete \ >>- ia64-linuxOPT-enable-obsolete ia64-hpuxOPT-enable-obsolete \ >>+ i686-cygwinOPT-enable-threads=yes i686-mingw32crt linux-ia64 \ > >Shouldn't this be ia64-linux? And why reorder the entries? > >I would expect the change to be simply >s/ia64-linuxOPT-enable-obsolete/ia64-linux/ > >>+ ia64-elfOPT-enable-obsolete ia64-hpuxOPT-enable-obsolete >> ia64-hp-vmsOPT-enable-obsolete iq2000-elf lm32-elf \ >> lm32-rtems lm32-uclinux \ >> loongarch64-linux-gnuf64 loongarch64-linux-gnuf32 loongarch64-linux-gnusf \ >>diff --git a/gcc/config.gcc b/gcc/config.gcc >>index a37113bd00a..6d6ca6da7a0 100644 >>--- a/gcc/config.gcc >>+++ b/gcc/config.gcc >>@@ -272,7 +272,7 @@ esac >> >># Obsolete configurations. >>case ${target} in >>- ia64*-*-* \ >>+ ia64*-*-hpux* | ia64*-*-*vms* | ia64*-*-elf* \ >> | nios2*-*-* \ >> ) >> if test "x$enable_obsolete" != xyes; then >>-- >>2.45.0 >> >> >>-- >> René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin >> https://exactcode.com | https://t2sde.org | https://rene.rebe.de ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/3] Remove ia64*-*-linux from the list of obsolete targets 2024-06-12 10:42 ` [PATCH 1/3] " Rene Rebe 2024-06-12 18:40 ` Jonathan Wakely @ 2024-06-13 8:58 ` Gerald Pfeifer 1 sibling, 0 replies; 29+ messages in thread From: Gerald Pfeifer @ 2024-06-13 8:58 UTC (permalink / raw) To: Rene Rebe; +Cc: gcc-patches, rguenther, frank.scheiner On Wed, 12 Jun 2024, Rene Rebe wrote: > gcc/ > * config.gcc: Only exlicitly list ia64*-*-(hpux|vms|elf) in the > list of obsoleted targets. Typo: "explicitly" (or you can simply drop it here). Gerald ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH 2/3] Enabled LRA for ia64. 2024-06-12 10:33 ` [PATCH 0/3] Remove ia64*-*-linux from the list of obsolete targets Rene Rebe 2024-06-12 10:42 ` [PATCH 1/3] " Rene Rebe @ 2024-06-12 10:42 ` Rene Rebe 2024-06-12 11:01 ` Richard Biener 2024-06-12 10:43 ` [PATCH 3/3] MAINTAINERS: Add myself as IA-64 maintainer Rene Rebe 2024-06-12 18:44 ` [PATCH 0/3] Remove ia64*-*-linux from the list of obsolete targets Jonathan Wakely 3 siblings, 1 reply; 29+ messages in thread From: Rene Rebe @ 2024-06-12 10:42 UTC (permalink / raw) To: gcc-patches; +Cc: rguenther, frank.scheiner gcc/ * config/ia64/ia64.cc: Enable LRA for ia64. * config/ia64/ia64.md: Likewise. * config/ia64/predicates.md: Likewise. --- gcc/config/ia64/ia64.cc | 7 ++----- gcc/config/ia64/ia64.md | 4 ++-- gcc/config/ia64/predicates.md | 2 +- 3 files changed, 5 insertions(+), 8 deletions(-) diff --git a/gcc/config/ia64/ia64.cc b/gcc/config/ia64/ia64.cc index ac3d56073ac..d189bfb2cb4 100644 --- a/gcc/config/ia64/ia64.cc +++ b/gcc/config/ia64/ia64.cc @@ -618,9 +618,6 @@ static const scoped_attribute_specs *const ia64_attribute_table[] = #undef TARGET_LEGITIMATE_ADDRESS_P #define TARGET_LEGITIMATE_ADDRESS_P ia64_legitimate_address_p -#undef TARGET_LRA_P -#define TARGET_LRA_P hook_bool_void_false - #undef TARGET_CANNOT_FORCE_CONST_MEM #define TARGET_CANNOT_FORCE_CONST_MEM ia64_cannot_force_const_mem @@ -1329,7 +1326,7 @@ ia64_expand_move (rtx op0, rtx op1) { machine_mode mode = GET_MODE (op0); - if (!reload_in_progress && !reload_completed && !ia64_move_ok (op0, op1)) + if (!lra_in_progress && !reload_completed && !ia64_move_ok (op0, op1)) op1 = force_reg (mode, op1); if ((mode == Pmode || mode == ptr_mode) && symbolic_operand (op1, VOIDmode)) @@ -1776,7 +1773,7 @@ ia64_expand_movxf_movrf (machine_mode mode, rtx operands[]) } } - if (!reload_in_progress && !reload_completed) + if (!lra_in_progress && !reload_completed) { operands[1] = spill_xfmode_rfmode_operand (operands[1], 0, mode); diff --git a/gcc/config/ia64/ia64.md b/gcc/config/ia64/ia64.md index 698e302081e..d485acc0ea8 100644 --- a/gcc/config/ia64/ia64.md +++ b/gcc/config/ia64/ia64.md @@ -2318,7 +2318,7 @@ (match_operand:DI 3 "register_operand" "f")) (match_operand:DI 4 "nonmemory_operand" "rI"))) (clobber (match_scratch:DI 5 "=f"))] - "reload_in_progress" + "lra_in_progress" "#" [(set_attr "itanium_class" "unknown")]) @@ -3407,7 +3407,7 @@ (match_operand:DI 2 "shladd_operand" "n")) (match_operand:DI 3 "nonmemory_operand" "r")) (match_operand:DI 4 "nonmemory_operand" "rI")))] - "reload_in_progress" + "lra_in_progress" "* gcc_unreachable ();" "reload_completed" [(set (match_dup 0) (plus:DI (mult:DI (match_dup 1) (match_dup 2)) diff --git a/gcc/config/ia64/predicates.md b/gcc/config/ia64/predicates.md index 01a4effd339..85f5380e734 100644 --- a/gcc/config/ia64/predicates.md +++ b/gcc/config/ia64/predicates.md @@ -347,7 +347,7 @@ allows reload the opportunity to avoid spilling addresses to the stack, and instead simply substitute in the value from a REG_EQUIV. We'll split this up again when splitting the insn. */ - if (reload_in_progress || reload_completed) + if (lra_in_progress || reload_completed) return true; /* Some symbol types we allow to use with any offset. */ -- 2.45.0 -- René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin https://exactcode.com | https://t2sde.org | https://rene.rebe.de ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-12 10:42 ` [PATCH 2/3] Enabled LRA for ia64 Rene Rebe @ 2024-06-12 11:01 ` Richard Biener 2024-06-12 12:50 ` René Rebe 2024-06-12 14:09 ` Frank Scheiner 0 siblings, 2 replies; 29+ messages in thread From: Richard Biener @ 2024-06-12 11:01 UTC (permalink / raw) To: Rene Rebe; +Cc: gcc-patches, frank.scheiner On Wed, 12 Jun 2024, Rene Rebe wrote: > > gcc/ > * config/ia64/ia64.cc: Enable LRA for ia64. > * config/ia64/ia64.md: Likewise. > * config/ia64/predicates.md: Likewise. That looks simple enough. I cannot find any copyright assignment on file with the FSF so you probably want to contribute to GCC under the DCO (see https://gcc.gnu.org/dco.html), in that case please post patches with Signed-off-by: tags. For this patch please state how you tested it, I assume you bootstrapped GCC natively on ia64-linux and ran the testsuite. I can find two gcc-testresult postings, one appearantly with LRA and one without? Both from May: https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html somehow for example libstdc++ summaries were not merged, it might be you do not have recent python installed on the system? Or you didn't use contrib/test_summary to create those mails. It would be nice to see the difference between LRA and not LRA in the testresults, can you quote that? Thanks, Richard. > --- > gcc/config/ia64/ia64.cc | 7 ++----- > gcc/config/ia64/ia64.md | 4 ++-- > gcc/config/ia64/predicates.md | 2 +- > 3 files changed, 5 insertions(+), 8 deletions(-) > > diff --git a/gcc/config/ia64/ia64.cc b/gcc/config/ia64/ia64.cc > index ac3d56073ac..d189bfb2cb4 100644 > --- a/gcc/config/ia64/ia64.cc > +++ b/gcc/config/ia64/ia64.cc > @@ -618,9 +618,6 @@ static const scoped_attribute_specs *const ia64_attribute_table[] = > #undef TARGET_LEGITIMATE_ADDRESS_P > #define TARGET_LEGITIMATE_ADDRESS_P ia64_legitimate_address_p > > -#undef TARGET_LRA_P > -#define TARGET_LRA_P hook_bool_void_false > - > #undef TARGET_CANNOT_FORCE_CONST_MEM > #define TARGET_CANNOT_FORCE_CONST_MEM ia64_cannot_force_const_mem > > @@ -1329,7 +1326,7 @@ ia64_expand_move (rtx op0, rtx op1) > { > machine_mode mode = GET_MODE (op0); > > - if (!reload_in_progress && !reload_completed && !ia64_move_ok (op0, op1)) > + if (!lra_in_progress && !reload_completed && !ia64_move_ok (op0, op1)) > op1 = force_reg (mode, op1); > > if ((mode == Pmode || mode == ptr_mode) && symbolic_operand (op1, VOIDmode)) > @@ -1776,7 +1773,7 @@ ia64_expand_movxf_movrf (machine_mode mode, rtx operands[]) > } > } > > - if (!reload_in_progress && !reload_completed) > + if (!lra_in_progress && !reload_completed) > { > operands[1] = spill_xfmode_rfmode_operand (operands[1], 0, mode); > > diff --git a/gcc/config/ia64/ia64.md b/gcc/config/ia64/ia64.md > index 698e302081e..d485acc0ea8 100644 > --- a/gcc/config/ia64/ia64.md > +++ b/gcc/config/ia64/ia64.md > @@ -2318,7 +2318,7 @@ > (match_operand:DI 3 "register_operand" "f")) > (match_operand:DI 4 "nonmemory_operand" "rI"))) > (clobber (match_scratch:DI 5 "=f"))] > - "reload_in_progress" > + "lra_in_progress" > "#" > [(set_attr "itanium_class" "unknown")]) > > @@ -3407,7 +3407,7 @@ > (match_operand:DI 2 "shladd_operand" "n")) > (match_operand:DI 3 "nonmemory_operand" "r")) > (match_operand:DI 4 "nonmemory_operand" "rI")))] > - "reload_in_progress" > + "lra_in_progress" > "* gcc_unreachable ();" > "reload_completed" > [(set (match_dup 0) (plus:DI (mult:DI (match_dup 1) (match_dup 2)) > diff --git a/gcc/config/ia64/predicates.md b/gcc/config/ia64/predicates.md > index 01a4effd339..85f5380e734 100644 > --- a/gcc/config/ia64/predicates.md > +++ b/gcc/config/ia64/predicates.md > @@ -347,7 +347,7 @@ > allows reload the opportunity to avoid spilling addresses to > the stack, and instead simply substitute in the value from a > REG_EQUIV. We'll split this up again when splitting the insn. */ > - if (reload_in_progress || reload_completed) > + if (lra_in_progress || reload_completed) > return true; > > /* Some symbol types we allow to use with any offset. */ > -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg) ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-12 11:01 ` Richard Biener @ 2024-06-12 12:50 ` René Rebe 2024-06-12 13:00 ` Richard Biener 2024-06-12 14:09 ` Frank Scheiner 1 sibling, 1 reply; 29+ messages in thread From: René Rebe @ 2024-06-12 12:50 UTC (permalink / raw) To: Richard Biener; +Cc: gcc-patches, frank.scheiner Hi, > On Jun 12, 2024, at 13:01, Richard Biener <rguenther@suse.de> wrote: > > On Wed, 12 Jun 2024, Rene Rebe wrote: >> >> gcc/ >> * config/ia64/ia64.cc: Enable LRA for ia64. >> * config/ia64/ia64.md: Likewise. >> * config/ia64/predicates.md: Likewise. > > That looks simple enough. I cannot find any copyright assignment on > file with the FSF so you probably want to contribute to GCC under > the DCO (see https://gcc.gnu.org/dco.html), in that case please post > patches with Signed-off-by: tags. If it helps for the future, I can apply for copyright assignment, too. > For this patch please state how you tested it, I assume you > bootstrapped GCC natively on ia64-linux and ran the testsuite. > I can find two gcc-testresult postings, one appearantly with LRA > and one without? Both from May: > > https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html > https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html Yes, that are the two I quoted in the patch cover letter. https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654321.html > somehow for example libstdc++ summaries were not merged, it might > be you do not have recent python installed on the system? Or you > didn't use contrib/test_summary to create those mails. It would be > nice to see the difference between LRA and not LRA in the testresults, > can you quote that? We usually cross-compile gcc, but also ran natively for the testsuite. Given the tests run quite long natively on the hardware we currently have, I summed the results them up in the cover letter. I would assume that shoudl be enough to include with a note the resulting kernel and user-space world was booted and worked without issues? If so, I’ll just resend with the additional information added. Thank you so much, René > Thanks, > Richard. > >> --- >> gcc/config/ia64/ia64.cc | 7 ++----- >> gcc/config/ia64/ia64.md | 4 ++-- >> gcc/config/ia64/predicates.md | 2 +- >> 3 files changed, 5 insertions(+), 8 deletions(-) >> >> diff --git a/gcc/config/ia64/ia64.cc b/gcc/config/ia64/ia64.cc >> index ac3d56073ac..d189bfb2cb4 100644 >> --- a/gcc/config/ia64/ia64.cc >> +++ b/gcc/config/ia64/ia64.cc >> @@ -618,9 +618,6 @@ static const scoped_attribute_specs *const ia64_attribute_table[] = >> #undef TARGET_LEGITIMATE_ADDRESS_P >> #define TARGET_LEGITIMATE_ADDRESS_P ia64_legitimate_address_p >> >> -#undef TARGET_LRA_P >> -#define TARGET_LRA_P hook_bool_void_false >> - >> #undef TARGET_CANNOT_FORCE_CONST_MEM >> #define TARGET_CANNOT_FORCE_CONST_MEM ia64_cannot_force_const_mem >> >> @@ -1329,7 +1326,7 @@ ia64_expand_move (rtx op0, rtx op1) >> { >> machine_mode mode = GET_MODE (op0); >> >> - if (!reload_in_progress && !reload_completed && !ia64_move_ok (op0, op1)) >> + if (!lra_in_progress && !reload_completed && !ia64_move_ok (op0, op1)) >> op1 = force_reg (mode, op1); >> >> if ((mode == Pmode || mode == ptr_mode) && symbolic_operand (op1, VOIDmode)) >> @@ -1776,7 +1773,7 @@ ia64_expand_movxf_movrf (machine_mode mode, rtx operands[]) >> } >> } >> >> - if (!reload_in_progress && !reload_completed) >> + if (!lra_in_progress && !reload_completed) >> { >> operands[1] = spill_xfmode_rfmode_operand (operands[1], 0, mode); >> >> diff --git a/gcc/config/ia64/ia64.md b/gcc/config/ia64/ia64.md >> index 698e302081e..d485acc0ea8 100644 >> --- a/gcc/config/ia64/ia64.md >> +++ b/gcc/config/ia64/ia64.md >> @@ -2318,7 +2318,7 @@ >> (match_operand:DI 3 "register_operand" "f")) >> (match_operand:DI 4 "nonmemory_operand" "rI"))) >> (clobber (match_scratch:DI 5 "=f"))] >> - "reload_in_progress" >> + "lra_in_progress" >> "#" >> [(set_attr "itanium_class" "unknown")]) >> >> @@ -3407,7 +3407,7 @@ >> (match_operand:DI 2 "shladd_operand" "n")) >> (match_operand:DI 3 "nonmemory_operand" "r")) >> (match_operand:DI 4 "nonmemory_operand" "rI")))] >> - "reload_in_progress" >> + "lra_in_progress" >> "* gcc_unreachable ();" >> "reload_completed" >> [(set (match_dup 0) (plus:DI (mult:DI (match_dup 1) (match_dup 2)) >> diff --git a/gcc/config/ia64/predicates.md b/gcc/config/ia64/predicates.md >> index 01a4effd339..85f5380e734 100644 >> --- a/gcc/config/ia64/predicates.md >> +++ b/gcc/config/ia64/predicates.md >> @@ -347,7 +347,7 @@ >> allows reload the opportunity to avoid spilling addresses to >> the stack, and instead simply substitute in the value from a >> REG_EQUIV. We'll split this up again when splitting the insn. */ >> - if (reload_in_progress || reload_completed) >> + if (lra_in_progress || reload_completed) >> return true; >> >> /* Some symbol types we allow to use with any offset. */ >> > > -- > Richard Biener <rguenther@suse.de> > SUSE Software Solutions Germany GmbH, > Frankenstrasse 146, 90461 Nuernberg, Germany; > GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg) -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin http://exactcode.com | http://exactscan.com | http://ocrkit.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-12 12:50 ` René Rebe @ 2024-06-12 13:00 ` Richard Biener 2024-06-12 13:19 ` René Rebe 0 siblings, 1 reply; 29+ messages in thread From: Richard Biener @ 2024-06-12 13:00 UTC (permalink / raw) To: René Rebe; +Cc: gcc-patches, frank.scheiner [-- Attachment #1: Type: text/plain, Size: 6231 bytes --] On Wed, 12 Jun 2024, René Rebe wrote: > Hi, > > > On Jun 12, 2024, at 13:01, Richard Biener <rguenther@suse.de> wrote: > > > > On Wed, 12 Jun 2024, Rene Rebe wrote: > >> > >> gcc/ > >> * config/ia64/ia64.cc: Enable LRA for ia64. > >> * config/ia64/ia64.md: Likewise. > >> * config/ia64/predicates.md: Likewise. > > > > That looks simple enough. I cannot find any copyright assignment on > > file with the FSF so you probably want to contribute to GCC under > > the DCO (see https://gcc.gnu.org/dco.html), in that case please post > > patches with Signed-off-by: tags. > > If it helps for the future, I can apply for copyright assignment, too. It's not a requirement - you as contributor get the choice under which legal framework you contribute to GCC, for the DCO there's the formal requirement of Signed-off-by: tags. > > For this patch please state how you tested it, I assume you > > bootstrapped GCC natively on ia64-linux and ran the testsuite. > > I can find two gcc-testresult postings, one appearantly with LRA > > and one without? Both from May: > > > > https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html > > https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html > > Yes, that are the two I quoted in the patch cover letter. > > https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654321.html > > > somehow for example libstdc++ summaries were not merged, it might > > be you do not have recent python installed on the system? Or you > > didn't use contrib/test_summary to create those mails. It would be > > nice to see the difference between LRA and not LRA in the testresults, > > can you quote that? > > We usually cross-compile gcc, but also ran natively for the testsuite. > Given the tests run quite long natively on the hardware we currently > have, I summed the results them up in the cover letter. I would assume > that shoudl be enough to include with a note the resulting kernel and > user-space world was booted and worked without issues? I specifically wondered if bootstrap with LRA enabled succeeds. That needs either native or emulated hardware. I think we consider ia64-linux a host platform and not only a cross compiler target. > If so, I’ll just resend with the additional information added. For the LRA enablement patch the requirement is that patches should state how they were tested - usually you'll see sth like Boostrapped and tested on x86_64-unknown-linux-gnu. In your case it was Cross-built from x86_64-linux(?) to ia64-linux, natively tested not sure how you exactly did this though? I've never tried testing of a canadian-cross tree - did you copy the whole build tree over from the x86 to the ia64 machine? Thanks, Richard. > Thank you so much, > René > > > Thanks, > > Richard. > > > >> --- > >> gcc/config/ia64/ia64.cc | 7 ++----- > >> gcc/config/ia64/ia64.md | 4 ++-- > >> gcc/config/ia64/predicates.md | 2 +- > >> 3 files changed, 5 insertions(+), 8 deletions(-) > >> > >> diff --git a/gcc/config/ia64/ia64.cc b/gcc/config/ia64/ia64.cc > >> index ac3d56073ac..d189bfb2cb4 100644 > >> --- a/gcc/config/ia64/ia64.cc > >> +++ b/gcc/config/ia64/ia64.cc > >> @@ -618,9 +618,6 @@ static const scoped_attribute_specs *const ia64_attribute_table[] = > >> #undef TARGET_LEGITIMATE_ADDRESS_P > >> #define TARGET_LEGITIMATE_ADDRESS_P ia64_legitimate_address_p > >> > >> -#undef TARGET_LRA_P > >> -#define TARGET_LRA_P hook_bool_void_false > >> - > >> #undef TARGET_CANNOT_FORCE_CONST_MEM > >> #define TARGET_CANNOT_FORCE_CONST_MEM ia64_cannot_force_const_mem > >> > >> @@ -1329,7 +1326,7 @@ ia64_expand_move (rtx op0, rtx op1) > >> { > >> machine_mode mode = GET_MODE (op0); > >> > >> - if (!reload_in_progress && !reload_completed && !ia64_move_ok (op0, op1)) > >> + if (!lra_in_progress && !reload_completed && !ia64_move_ok (op0, op1)) > >> op1 = force_reg (mode, op1); > >> > >> if ((mode == Pmode || mode == ptr_mode) && symbolic_operand (op1, VOIDmode)) > >> @@ -1776,7 +1773,7 @@ ia64_expand_movxf_movrf (machine_mode mode, rtx operands[]) > >> } > >> } > >> > >> - if (!reload_in_progress && !reload_completed) > >> + if (!lra_in_progress && !reload_completed) > >> { > >> operands[1] = spill_xfmode_rfmode_operand (operands[1], 0, mode); > >> > >> diff --git a/gcc/config/ia64/ia64.md b/gcc/config/ia64/ia64.md > >> index 698e302081e..d485acc0ea8 100644 > >> --- a/gcc/config/ia64/ia64.md > >> +++ b/gcc/config/ia64/ia64.md > >> @@ -2318,7 +2318,7 @@ > >> (match_operand:DI 3 "register_operand" "f")) > >> (match_operand:DI 4 "nonmemory_operand" "rI"))) > >> (clobber (match_scratch:DI 5 "=f"))] > >> - "reload_in_progress" > >> + "lra_in_progress" > >> "#" > >> [(set_attr "itanium_class" "unknown")]) > >> > >> @@ -3407,7 +3407,7 @@ > >> (match_operand:DI 2 "shladd_operand" "n")) > >> (match_operand:DI 3 "nonmemory_operand" "r")) > >> (match_operand:DI 4 "nonmemory_operand" "rI")))] > >> - "reload_in_progress" > >> + "lra_in_progress" > >> "* gcc_unreachable ();" > >> "reload_completed" > >> [(set (match_dup 0) (plus:DI (mult:DI (match_dup 1) (match_dup 2)) > >> diff --git a/gcc/config/ia64/predicates.md b/gcc/config/ia64/predicates.md > >> index 01a4effd339..85f5380e734 100644 > >> --- a/gcc/config/ia64/predicates.md > >> +++ b/gcc/config/ia64/predicates.md > >> @@ -347,7 +347,7 @@ > >> allows reload the opportunity to avoid spilling addresses to > >> the stack, and instead simply substitute in the value from a > >> REG_EQUIV. We'll split this up again when splitting the insn. */ > >> - if (reload_in_progress || reload_completed) > >> + if (lra_in_progress || reload_completed) > >> return true; > >> > >> /* Some symbol types we allow to use with any offset. */ > >> > > > > -- > > Richard Biener <rguenther@suse.de> > > SUSE Software Solutions Germany GmbH, > > Frankenstrasse 146, 90461 Nuernberg, Germany; > > GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg) > > -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg) ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-12 13:00 ` Richard Biener @ 2024-06-12 13:19 ` René Rebe 2024-06-12 14:03 ` Frank Scheiner 0 siblings, 1 reply; 29+ messages in thread From: René Rebe @ 2024-06-12 13:19 UTC (permalink / raw) To: Richard Biener; +Cc: gcc-patches, frank.scheiner [-- Attachment #1: Type: text/plain, Size: 7203 bytes --] On Jun 12, 2024, at 15:00, Richard Biener <rguenther@suse.de> wrote: > > On Wed, 12 Jun 2024, René Rebe wrote: > >> Hi, >> >>> On Jun 12, 2024, at 13:01, Richard Biener <rguenther@suse.de> wrote: >>> >>> On Wed, 12 Jun 2024, Rene Rebe wrote: >>>> >>>> gcc/ >>>> * config/ia64/ia64.cc: Enable LRA for ia64. >>>> * config/ia64/ia64.md: Likewise. >>>> * config/ia64/predicates.md: Likewise. >>> >>> That looks simple enough. I cannot find any copyright assignment on >>> file with the FSF so you probably want to contribute to GCC under >>> the DCO (see https://gcc.gnu.org/dco.html), in that case please post >>> patches with Signed-off-by: tags. >> >> If it helps for the future, I can apply for copyright assignment, too. > > It's not a requirement - you as contributor get the choice under > which legal framework you contribute to GCC, for the DCO there's > the formal requirement of Signed-off-by: tags. > >>> For this patch please state how you tested it, I assume you >>> bootstrapped GCC natively on ia64-linux and ran the testsuite. >>> I can find two gcc-testresult postings, one appearantly with LRA >>> and one without? Both from May: >>> >>> https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html >>> https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html >> >> Yes, that are the two I quoted in the patch cover letter. >> >> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654321.html >> >>> somehow for example libstdc++ summaries were not merged, it might >>> be you do not have recent python installed on the system? Or you >>> didn't use contrib/test_summary to create those mails. It would be >>> nice to see the difference between LRA and not LRA in the testresults, >>> can you quote that? >> >> We usually cross-compile gcc, but also ran natively for the testsuite. >> Given the tests run quite long natively on the hardware we currently >> have, I summed the results them up in the cover letter. I would assume >> that shoudl be enough to include with a note the resulting kernel and >> user-space world was booted and worked without issues? > > I specifically wondered if bootstrap with LRA enabled succeeds. > That needs either native or emulated hardware. I think we consider > ia64-linux a host platform and not only a cross compiler target. With “also ran” I meant to say we did both, our T2 framework usually boot-straps everything cross compiled, but also supports native in-system compilation. Frank also manually natively bootstrapped gcc and ran the testsuite natively on ia64. >> If so, I’ll just resend with the additional information added. > > For the LRA enablement patch the requirement is that patches should > state how they were tested - usually you'll see sth like > > Boostrapped and tested on x86_64-unknown-linux-gnu. > > In your case it was > > Cross-built from x86_64-linux(?) to ia64-linux, natively tested OK - I include the details in v2. > not sure how you exactly did this though? I've never tried > testing of a canadian-cross tree - did you copy the whole build > tree over from the x86 to the ia64 machine? IIRC the testsuite did not just work copying the canadian-cross. I did run the testsuite from the cross-compiled gcc using a ssh based dejagnu board config, but Frank also did fully bootstrap and ran the testsuite natively. Thanks, René > Thanks, > Richard. > >> Thank you so much, >> René >> >>> Thanks, >>> Richard. >>> >>>> --- >>>> gcc/config/ia64/ia64.cc | 7 ++----- >>>> gcc/config/ia64/ia64.md | 4 ++-- >>>> gcc/config/ia64/predicates.md | 2 +- >>>> 3 files changed, 5 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/gcc/config/ia64/ia64.cc b/gcc/config/ia64/ia64.cc >>>> index ac3d56073ac..d189bfb2cb4 100644 >>>> --- a/gcc/config/ia64/ia64.cc >>>> +++ b/gcc/config/ia64/ia64.cc >>>> @@ -618,9 +618,6 @@ static const scoped_attribute_specs *const ia64_attribute_table[] = >>>> #undef TARGET_LEGITIMATE_ADDRESS_P >>>> #define TARGET_LEGITIMATE_ADDRESS_P ia64_legitimate_address_p >>>> >>>> -#undef TARGET_LRA_P >>>> -#define TARGET_LRA_P hook_bool_void_false >>>> - >>>> #undef TARGET_CANNOT_FORCE_CONST_MEM >>>> #define TARGET_CANNOT_FORCE_CONST_MEM ia64_cannot_force_const_mem >>>> >>>> @@ -1329,7 +1326,7 @@ ia64_expand_move (rtx op0, rtx op1) >>>> { >>>> machine_mode mode = GET_MODE (op0); >>>> >>>> - if (!reload_in_progress && !reload_completed && !ia64_move_ok (op0, op1)) >>>> + if (!lra_in_progress && !reload_completed && !ia64_move_ok (op0, op1)) >>>> op1 = force_reg (mode, op1); >>>> >>>> if ((mode == Pmode || mode == ptr_mode) && symbolic_operand (op1, VOIDmode)) >>>> @@ -1776,7 +1773,7 @@ ia64_expand_movxf_movrf (machine_mode mode, rtx operands[]) >>>> } >>>> } >>>> >>>> - if (!reload_in_progress && !reload_completed) >>>> + if (!lra_in_progress && !reload_completed) >>>> { >>>> operands[1] = spill_xfmode_rfmode_operand (operands[1], 0, mode); >>>> >>>> diff --git a/gcc/config/ia64/ia64.md b/gcc/config/ia64/ia64.md >>>> index 698e302081e..d485acc0ea8 100644 >>>> --- a/gcc/config/ia64/ia64.md >>>> +++ b/gcc/config/ia64/ia64.md >>>> @@ -2318,7 +2318,7 @@ >>>> (match_operand:DI 3 "register_operand" "f")) >>>> (match_operand:DI 4 "nonmemory_operand" "rI"))) >>>> (clobber (match_scratch:DI 5 "=f"))] >>>> - "reload_in_progress" >>>> + "lra_in_progress" >>>> "#" >>>> [(set_attr "itanium_class" "unknown")]) >>>> >>>> @@ -3407,7 +3407,7 @@ >>>> (match_operand:DI 2 "shladd_operand" "n")) >>>> (match_operand:DI 3 "nonmemory_operand" "r")) >>>> (match_operand:DI 4 "nonmemory_operand" "rI")))] >>>> - "reload_in_progress" >>>> + "lra_in_progress" >>>> "* gcc_unreachable ();" >>>> "reload_completed" >>>> [(set (match_dup 0) (plus:DI (mult:DI (match_dup 1) (match_dup 2)) >>>> diff --git a/gcc/config/ia64/predicates.md b/gcc/config/ia64/predicates.md >>>> index 01a4effd339..85f5380e734 100644 >>>> --- a/gcc/config/ia64/predicates.md >>>> +++ b/gcc/config/ia64/predicates.md >>>> @@ -347,7 +347,7 @@ >>>> allows reload the opportunity to avoid spilling addresses to >>>> the stack, and instead simply substitute in the value from a >>>> REG_EQUIV. We'll split this up again when splitting the insn. */ >>>> - if (reload_in_progress || reload_completed) >>>> + if (lra_in_progress || reload_completed) >>>> return true; >>>> >>>> /* Some symbol types we allow to use with any offset. */ >>>> >>> >>> -- >>> Richard Biener <rguenther@suse.de> >>> SUSE Software Solutions Germany GmbH, >>> Frankenstrasse 146, 90461 Nuernberg, Germany; >>> GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg) >> >> > > -- > Richard Biener <rguenther@suse.de> > SUSE Software Solutions Germany GmbH, > Frankenstrasse 146, 90461 Nuernberg, Germany; > GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg) -- ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin http://exactcode.com | http://exactscan.com | http://ocrkit.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-12 13:19 ` René Rebe @ 2024-06-12 14:03 ` Frank Scheiner 0 siblings, 0 replies; 29+ messages in thread From: Frank Scheiner @ 2024-06-12 14:03 UTC (permalink / raw) To: René Rebe, Richard Biener; +Cc: gcc-patches Hi all, On 12.06.24 15:19, René Rebe wrote: > On Jun 12, 2024, at 15:00, Richard Biener <rguenther@suse.de> wrote: >> On Wed, 12 Jun 2024, René Rebe wrote: >>>> On Jun 12, 2024, at 13:01, Richard Biener <rguenther@suse.de> wrote: >>>> On Wed, 12 Jun 2024, Rene Rebe wrote: >> not sure how you exactly did this though? I've never tried >> testing of a canadian-cross tree - did you copy the whole build >> tree over from the x86 to the ia64 machine? > > IIRC the testsuite did not just work copying the canadian-cross. > I did run the testsuite from the cross-compiled gcc using a ssh > based dejagnu board config, but Frank also did fully bootstrap and > ran the testsuite natively. Exactly, the results I posted are both based on natively bootstrapped GCC binaries (took ca. 5 hours each on my rx2800 i2). The post titles include the exact commit hash they are based on: 1. [ia64] Results for 15.0.0 20240528 (experimental) [master revision 236116068151bbc72aaaf53d0f223fe06f7e3bac] (GCC) testsuite on ia64-t2-linux-gnu ([1]) 2. [ia64] Results for 15.0.0 20240528 (experimental) [master revision 236116068151bbc72aaaf53d0f223fe06f7e3bac] (GCC) w/LRA testsuite on ia64-t2-linux-gnu ([2]) [1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816346.html [2]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816422.html I tried to save time during the testsuite runs (it still took more than 7 hours on my rx2800 i2 running in tmpfs) by manually running multiple testsuites in parallel in the following fashion: ``` gcc | libstdc++ | | ----------| g++ | | | ----------| gfortran | | | ----------| libgomp |----------- | libatomic |----------- | objc ``` ... and also using multiple jobs per testsuite where it saved time (e.g. it does not for the libgomp testsuite). This is the reason that the output is somewhat split up. [1] and [2] each also list the commands used to run the testsuites and timing data. For reference these were produced on a: rx2800 i2 w/1 x Itanium 2 9320 running @1.33 GHz w/SMT enabled Cheers, Frank ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-12 11:01 ` Richard Biener 2024-06-12 12:50 ` René Rebe @ 2024-06-12 14:09 ` Frank Scheiner 2024-06-12 18:54 ` Jonathan Wakely 2024-06-13 7:02 ` Richard Biener 1 sibling, 2 replies; 29+ messages in thread From: Frank Scheiner @ 2024-06-12 14:09 UTC (permalink / raw) To: Richard Biener; +Cc: gcc-patches, Rene Rebe Dear Richard, On 12.06.24 13:01, Richard Biener wrote: > [...] > I can find two gcc-testresult postings, one appearantly with LRA > and one without? Both from May: > > https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html > https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html > > somehow for example libstdc++ summaries were not merged, it might > be you do not have recent python installed on the system? Or you > didn't use contrib/test_summary to create those mails. No, I did not use contrib/test_summary. But I still have tarballs of both testsuite runs, so could still produce these summaries - I hope? Do I need to run this on the host that did the testing or can I run it on my NFS server where the tarballs are actually located, too? Architectures are different though, the NFS server is 32-bit ARM. Cheers, Frank ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-12 14:09 ` Frank Scheiner @ 2024-06-12 18:54 ` Jonathan Wakely 2024-06-12 20:59 ` Frank Scheiner 2024-06-13 7:02 ` Richard Biener 1 sibling, 1 reply; 29+ messages in thread From: Jonathan Wakely @ 2024-06-12 18:54 UTC (permalink / raw) To: Frank Scheiner; +Cc: Richard Biener, gcc-patches, Rene Rebe On 12/06/24 16:09 +0200, Frank Scheiner wrote: >Dear Richard, > >On 12.06.24 13:01, Richard Biener wrote: >>[...] >>I can find two gcc-testresult postings, one appearantly with LRA >>and one without? Both from May: >> >>https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html >>https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html >> >>somehow for example libstdc++ summaries were not merged, it might >>be you do not have recent python installed on the system? Or you >>didn't use contrib/test_summary to create those mails. > >No, I did not use contrib/test_summary. But I still have tarballs of >both testsuite runs, so could still produce these summaries - I hope? It looks like the results at https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816422.html are just what's printed on standard out, including output from 'make -j4' so not combined into one set of results. It would certainly be better to either get the results from the .sum files, or just use the contrib/test_summary script to do that for you. >Do I need to run this on the host that did the testing or can I run it >on my NFS server where the tarballs are actually located, too? I don't think the script cares where it's run, it just looks at text files which should work on any host. >Architectures are different though, the NFS server is 32-bit ARM. Text is text. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-12 18:54 ` Jonathan Wakely @ 2024-06-12 20:59 ` Frank Scheiner 2024-06-13 10:33 ` Jonathan Wakely 0 siblings, 1 reply; 29+ messages in thread From: Frank Scheiner @ 2024-06-12 20:59 UTC (permalink / raw) To: Jonathan Wakely, Richard Biener; +Cc: gcc-patches, Rene Rebe [-- Attachment #1: Type: text/plain, Size: 1861 bytes --] Hi Jonathan, Richard, On 12.06.24 20:54, Jonathan Wakely wrote: > On 12/06/24 16:09 +0200, Frank Scheiner wrote: >> Dear Richard, >> >> On 12.06.24 13:01, Richard Biener wrote: >>> [...] >>> I can find two gcc-testresult postings, one appearantly with LRA >>> and one without? Both from May: >>> >>> https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html >>> https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html >>> >>> somehow for example libstdc++ summaries were not merged, it might >>> be you do not have recent python installed on the system? Or you >>> didn't use contrib/test_summary to create those mails. >> >> No, I did not use contrib/test_summary. But I still have tarballs of >> both testsuite runs, so could still produce these summaries - I hope? > > It looks like the results at > https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816422.html are > just what's printed on standard out, including output from 'make -j4' > so not combined into one set of results. That's what it is, yes. > It would certainly be better to either get the results from the .sum > files, or just use the contrib/test_summary script to do that for you. Ok, I posted the results as created by contrib/test_summary now: 1. non-LRA version on [1] 2. LRA version on [2] [1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817267.html [2]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817268.html The difference 2 compared to 1 is attached. >> Do I need to run this on the host that did the testing or can I run it >> on my NFS server where the tarballs are actually located, too? > > I don't think the script cares where it's run, it just looks at text > files which should work on any host. It looks like it worked fine. :-) Cheers, Frank [-- Attachment #2: gcc-15-lra-to-non-lra-testsute-summary.diff --] [-- Type: text/x-patch, Size: 6196 bytes --] diff --git a/gcc-15-testsuite-summary.log b/gcc-15-lra-testsuite-summary.log index b7acc04..558079a 100644 --- a/gcc-15-testsuite-summary.log +++ b/gcc-15-lra-testsuite-summary.log @@ -306,13 +306,12 @@ FAIL: gcc.dg/guality/csttest.c -Og -DPREVENT_OPTIMIZATION line 55 q == -(0x1ef FAIL: gcc.dg/guality/csttest.c -Og -DPREVENT_OPTIMIZATION line 55 r == -(0x1efULL << 50) XPASS: gcc.dg/guality/example.c -O0 execution test XPASS: gcc.dg/guality/guality.c -O0 execution test -XPASS: gcc.dg/guality/guality.c -O3 -g -DPREVENT_OPTIMIZATION execution test FAIL: gcc.dg/guality/inline-params-2.c -O1 -DPREVENT_OPTIMIZATION execution test FAIL: gcc.dg/guality/inline-params-2.c -O2 -DPREVENT_OPTIMIZATION execution test +FAIL: gcc.dg/guality/inline-params-2.c -O3 -g -DPREVENT_OPTIMIZATION execution test FAIL: gcc.dg/guality/inline-params-2.c -Os -DPREVENT_OPTIMIZATION execution test FAIL: gcc.dg/guality/inline-params-2.c -Og -DPREVENT_OPTIMIZATION execution test FAIL: gcc.dg/guality/inline-params.c -O1 -DPREVENT_OPTIMIZATION execution test -XPASS: gcc.dg/guality/inline-params.c -O3 -g -DPREVENT_OPTIMIZATION execution test FAIL: gcc.dg/guality/inline-params.c -Og -DPREVENT_OPTIMIZATION execution test FAIL: gcc.dg/guality/ipa-sra-1.c -O1 -DPREVENT_OPTIMIZATION line 19 k == 3 FAIL: gcc.dg/guality/ipa-sra-1.c -O1 -DPREVENT_OPTIMIZATION line 31 k == 3 @@ -434,6 +433,7 @@ FAIL: gcc.dg/guality/pr41447-1.c -Os -DPREVENT_OPTIMIZATION execution test FAIL: gcc.dg/guality/pr41447-1.c -Og -DPREVENT_OPTIMIZATION execution test FAIL: gcc.dg/guality/pr41616-1.c -O1 -DPREVENT_OPTIMIZATION execution test FAIL: gcc.dg/guality/pr41616-1.c -O2 -DPREVENT_OPTIMIZATION execution test +FAIL: gcc.dg/guality/pr41616-1.c -O3 -g -DPREVENT_OPTIMIZATION execution test FAIL: gcc.dg/guality/pr41616-1.c -Og -DPREVENT_OPTIMIZATION execution test FAIL: gcc.dg/guality/pr43051-1.c -Os -DPREVENT_OPTIMIZATION line 34 c == &a[0] FAIL: gcc.dg/guality/pr43077-1.c -O0 line 19 vara == 1 @@ -798,10 +798,10 @@ FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation, -fprofile-genera UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c compilation, -fprofile-use -D_PROFILE_USE UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution, -fprofile-generate -D_PROFILE_GENERATE UNRESOLVED: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution, -fprofile-use -D_PROFILE_USE -FAIL: gcc.dg/tree-prof/pr77698.c compilation, -fprofile-generate -D_PROFILE_GENERATE -UNRESOLVED: gcc.dg/tree-prof/pr77698.c compilation, -fprofile-use -D_PROFILE_USE -UNRESOLVED: gcc.dg/tree-prof/pr77698.c execution, -fprofile-generate -D_PROFILE_GENERATE -UNRESOLVED: gcc.dg/tree-prof/pr77698.c execution, -fprofile-use -D_PROFILE_USE +FAIL: gcc.dg/tree-prof/pr47187.c compilation, -fprofile-generate -D_PROFILE_GENERATE +UNRESOLVED: gcc.dg/tree-prof/pr47187.c compilation, -fprofile-use -D_PROFILE_USE +UNRESOLVED: gcc.dg/tree-prof/pr47187.c execution, -fprofile-generate -D_PROFILE_GENERATE +UNRESOLVED: gcc.dg/tree-prof/pr47187.c execution, -fprofile-use -D_PROFILE_USE FAIL: gcc.dg/tree-ssa/abs-4.c scan-tree-dump-times optimized "= -" 3 FAIL: gcc.dg/tree-ssa/abs-4.c scan-tree-dump-times optimized "= ABS_EXPR" 3 FAIL: gcc.dg/tree-ssa/asm-2.c (test for excess errors) @@ -953,18 +953,21 @@ FAIL: gcc.target/ia64/pr49303.c (test for excess errors) === gcc Summary === -# of expected passes 134719 -# of unexpected failures 899 -# of unexpected successes 21 -# of expected failures 1362 +# of expected passes 134769 +# of unexpected failures 901 +# of unexpected successes 19 +# of expected failures 1364 # of unresolved testcases 23 -# of unsupported tests 3081 -/dev/shm/gcc-15/src.gcc.ia64-toolchain-3.240529.112623.549077/gcc/gcc.build.lnx/gcc/xgcc version 15.0.0 20240528 (experimental) (GCC) +# of unsupported tests 3036 +/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/gcc/xgcc version 15.0.0 20240528 (experimental) (GCC) === gfortran tests === Running target unix +FAIL: gfortran.dg/default_initialization_3.f90 -O3 -g (internal compiler error: in create_block_for_bookkeeping, at sel-sched.cc:4557) +FAIL: gfortran.dg/default_initialization_3.f90 -O3 -g (test for excess errors) +UNRESOLVED: gfortran.dg/default_initialization_3.f90 -O3 -g compilation failed to produce executable FAIL: gfortran.dg/pr95690.f90 -O (test for errors, line 6) FAIL: gfortran.dg/pr95690.f90 -O (test for excess errors) FAIL: gfortran.dg/guality/arg1.f90 -O1 line 14 a(10) == 10 @@ -978,11 +981,12 @@ FAIL: gfortran.dg/vect/vect-2.f90 -O scan-tree-dump-times vect "Alignment of === gfortran Summary === -# of expected passes 69618 -# of unexpected failures 10 +# of expected passes 69616 +# of unexpected failures 12 # of expected failures 273 +# of unresolved testcases 1 # of unsupported tests 168 -/dev/shm/gcc-15/src.gcc.ia64-toolchain-3.240529.112623.549077/gcc/gcc.build.lnx/gcc/gfortran version 15.0.0 20240528 (experimental) (GCC) +/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/gcc/gfortran version 15.0.0 20240528 (experimental) (GCC) === g++ tests === @@ -1201,7 +1205,7 @@ FAIL: g++.dg/tree-prof/pr35545.C scan-tree-dump-not optimized "OBJ_TYPE_REF" # of expected failures 2595 # of unresolved testcases 5 # of unsupported tests 11542 -/dev/shm/gcc-15/src.gcc.ia64-toolchain-3.240529.112623.549077/gcc/gcc.build.lnx/gcc/xg++ version 15.0.0 20240528 (experimental) (GCC) +/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/gcc/xg++ version 15.0.0 20240528 (experimental) (GCC) === objc tests === @@ -1212,7 +1216,7 @@ Running target unix # of expected passes 2778 # of unsupported tests 58 -/dev/shm/gcc-15/src.gcc.ia64-toolchain-3.240529.112623.549077/gcc/gcc.build.lnx/gcc/xgcc version 15.0.0 20240528 (experimental) (GCC) +/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/gcc/xgcc version 15.0.0 20240528 (experimental) (GCC) === libatomic tests === ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-12 20:59 ` Frank Scheiner @ 2024-06-13 10:33 ` Jonathan Wakely 2024-06-13 14:11 ` Jeff Law 2024-06-14 11:07 ` Frank Scheiner 0 siblings, 2 replies; 29+ messages in thread From: Jonathan Wakely @ 2024-06-13 10:33 UTC (permalink / raw) To: Frank Scheiner; +Cc: Richard Biener, gcc-patches, Rene Rebe On Wed, 12 Jun 2024 at 22:00, Frank Scheiner <frank.scheiner@web.de> wrote: > > Hi Jonathan, Richard, > > On 12.06.24 20:54, Jonathan Wakely wrote: > > On 12/06/24 16:09 +0200, Frank Scheiner wrote: > >> Dear Richard, > >> > >> On 12.06.24 13:01, Richard Biener wrote: > >>> [...] > >>> I can find two gcc-testresult postings, one appearantly with LRA > >>> and one without? Both from May: > >>> > >>> https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html > >>> https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html > >>> > >>> somehow for example libstdc++ summaries were not merged, it might > >>> be you do not have recent python installed on the system? Or you > >>> didn't use contrib/test_summary to create those mails. > >> > >> No, I did not use contrib/test_summary. But I still have tarballs of > >> both testsuite runs, so could still produce these summaries - I hope? > > > > It looks like the results at > > https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816422.html are > > just what's printed on standard out, including output from 'make -j4' > > so not combined into one set of results. > > That's what it is, yes. > > > It would certainly be better to either get the results from the .sum > > files, or just use the contrib/test_summary script to do that for you. > > Ok, I posted the results as created by contrib/test_summary now: > > 1. non-LRA version on [1] > > 2. LRA version on [2] > > [1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817267.html > > [2]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817268.html Thanks! These ones are probably due to non-reserved names in glibc or kernel headers: FAIL: 17_intro/names.cc -std=gnu++17 (test for excess errors) FAIL: 17_intro/names_pstl.cc -std=gnu++17 (test for excess errors) FAIL: experimental/names.cc -std=gnu++17 (test for excess errors) The errors for all three are probably the same and should be decipherable from libstdc++.log which will show which names defined as macros in names.cc are clashing with names in system headers. > > The difference 2 compared to 1 is attached. > > >> Do I need to run this on the host that did the testing or can I run it > >> on my NFS server where the tarballs are actually located, too? > > > > I don't think the script cares where it's run, it just looks at text > > files which should work on any host. > > It looks like it worked fine. :-) > > Cheers, > Frank > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-13 10:33 ` Jonathan Wakely @ 2024-06-13 14:11 ` Jeff Law 2024-06-13 14:16 ` Jonathan Wakely 2024-06-14 11:07 ` Frank Scheiner 1 sibling, 1 reply; 29+ messages in thread From: Jeff Law @ 2024-06-13 14:11 UTC (permalink / raw) To: Jonathan Wakely, Frank Scheiner; +Cc: Richard Biener, gcc-patches, Rene Rebe On 6/13/24 4:33 AM, Jonathan Wakely wrote: > On Wed, 12 Jun 2024 at 22:00, Frank Scheiner <frank.scheiner@web.de> wrote: >> >> Hi Jonathan, Richard, >> >> On 12.06.24 20:54, Jonathan Wakely wrote: >>> On 12/06/24 16:09 +0200, Frank Scheiner wrote: >>>> Dear Richard, >>>> >>>> On 12.06.24 13:01, Richard Biener wrote: >>>>> [...] >>>>> I can find two gcc-testresult postings, one appearantly with LRA >>>>> and one without? Both from May: >>>>> >>>>> https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html >>>>> https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html >>>>> >>>>> somehow for example libstdc++ summaries were not merged, it might >>>>> be you do not have recent python installed on the system? Or you >>>>> didn't use contrib/test_summary to create those mails. >>>> >>>> No, I did not use contrib/test_summary. But I still have tarballs of >>>> both testsuite runs, so could still produce these summaries - I hope? >>> >>> It looks like the results at >>> https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816422.html are >>> just what's printed on standard out, including output from 'make -j4' >>> so not combined into one set of results. >> >> That's what it is, yes. >> >>> It would certainly be better to either get the results from the .sum >>> files, or just use the contrib/test_summary script to do that for you. >> >> Ok, I posted the results as created by contrib/test_summary now: >> >> 1. non-LRA version on [1] >> >> 2. LRA version on [2] >> >> [1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817267.html >> >> [2]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817268.html > > Thanks! > > These ones are probably due to non-reserved names in glibc or kernel headers: > > FAIL: 17_intro/names.cc -std=gnu++17 (test for excess errors) > FAIL: 17_intro/names_pstl.cc -std=gnu++17 (test for excess errors) > FAIL: experimental/names.cc -std=gnu++17 (test for excess errors) > > The errors for all three are probably the same and should be > decipherable from libstdc++.log which will show which names defined as > macros in names.cc are clashing with names in system headers. And wouldn't failure of these imply that the headers are either ancient with some kind of pollution or that there's a ia64 specific goof in the headers? These tests work on the other linux targets AFAIK. jeff ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-13 14:11 ` Jeff Law @ 2024-06-13 14:16 ` Jonathan Wakely 2024-06-13 14:18 ` Jonathan Wakely 0 siblings, 1 reply; 29+ messages in thread From: Jonathan Wakely @ 2024-06-13 14:16 UTC (permalink / raw) To: Jeff Law; +Cc: Frank Scheiner, Richard Biener, gcc-patches, Rene Rebe On Thu, 13 Jun 2024 at 15:11, Jeff Law <jeffreyalaw@gmail.com> wrote: > > > > On 6/13/24 4:33 AM, Jonathan Wakely wrote: > > On Wed, 12 Jun 2024 at 22:00, Frank Scheiner <frank.scheiner@web.de> wrote: > >> > >> Hi Jonathan, Richard, > >> > >> On 12.06.24 20:54, Jonathan Wakely wrote: > >>> On 12/06/24 16:09 +0200, Frank Scheiner wrote: > >>>> Dear Richard, > >>>> > >>>> On 12.06.24 13:01, Richard Biener wrote: > >>>>> [...] > >>>>> I can find two gcc-testresult postings, one appearantly with LRA > >>>>> and one without? Both from May: > >>>>> > >>>>> https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html > >>>>> https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html > >>>>> > >>>>> somehow for example libstdc++ summaries were not merged, it might > >>>>> be you do not have recent python installed on the system? Or you > >>>>> didn't use contrib/test_summary to create those mails. > >>>> > >>>> No, I did not use contrib/test_summary. But I still have tarballs of > >>>> both testsuite runs, so could still produce these summaries - I hope? > >>> > >>> It looks like the results at > >>> https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816422.html are > >>> just what's printed on standard out, including output from 'make -j4' > >>> so not combined into one set of results. > >> > >> That's what it is, yes. > >> > >>> It would certainly be better to either get the results from the .sum > >>> files, or just use the contrib/test_summary script to do that for you. > >> > >> Ok, I posted the results as created by contrib/test_summary now: > >> > >> 1. non-LRA version on [1] > >> > >> 2. LRA version on [2] > >> > >> [1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817267.html > >> > >> [2]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817268.html > > > > Thanks! > > > > These ones are probably due to non-reserved names in glibc or kernel headers: > > > > FAIL: 17_intro/names.cc -std=gnu++17 (test for excess errors) > > FAIL: 17_intro/names_pstl.cc -std=gnu++17 (test for excess errors) > > FAIL: experimental/names.cc -std=gnu++17 (test for excess errors) > > > > The errors for all three are probably the same and should be > > decipherable from libstdc++.log which will show which names defined as > > macros in names.cc are clashing with names in system headers. > And wouldn't failure of these imply that the headers are either ancient > with some kind of pollution or that there's a ia64 specific goof in the > headers? Yes, indeed. It probably means some ia64-specific structures in kernel headers use non-reserved names like "next" or "ptr" or something, instead of __next or __ptr. > These tests work on the other linux targets AFAIK. Most of them, yes. I think Jakub noticed some failures on s390x linux recently, due to bad names in s390x-specific structs in the kernel headers. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-13 14:16 ` Jonathan Wakely @ 2024-06-13 14:18 ` Jonathan Wakely 0 siblings, 0 replies; 29+ messages in thread From: Jonathan Wakely @ 2024-06-13 14:18 UTC (permalink / raw) To: Jeff Law; +Cc: Frank Scheiner, Richard Biener, gcc-patches, Rene Rebe On Thu, 13 Jun 2024 at 15:16, Jonathan Wakely <jwakely@redhat.com> wrote: > > On Thu, 13 Jun 2024 at 15:11, Jeff Law <jeffreyalaw@gmail.com> wrote: > > > > > > > > On 6/13/24 4:33 AM, Jonathan Wakely wrote: > > > On Wed, 12 Jun 2024 at 22:00, Frank Scheiner <frank.scheiner@web.de> wrote: > > >> > > >> Hi Jonathan, Richard, > > >> > > >> On 12.06.24 20:54, Jonathan Wakely wrote: > > >>> On 12/06/24 16:09 +0200, Frank Scheiner wrote: > > >>>> Dear Richard, > > >>>> > > >>>> On 12.06.24 13:01, Richard Biener wrote: > > >>>>> [...] > > >>>>> I can find two gcc-testresult postings, one appearantly with LRA > > >>>>> and one without? Both from May: > > >>>>> > > >>>>> https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html > > >>>>> https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html > > >>>>> > > >>>>> somehow for example libstdc++ summaries were not merged, it might > > >>>>> be you do not have recent python installed on the system? Or you > > >>>>> didn't use contrib/test_summary to create those mails. > > >>>> > > >>>> No, I did not use contrib/test_summary. But I still have tarballs of > > >>>> both testsuite runs, so could still produce these summaries - I hope? > > >>> > > >>> It looks like the results at > > >>> https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816422.html are > > >>> just what's printed on standard out, including output from 'make -j4' > > >>> so not combined into one set of results. > > >> > > >> That's what it is, yes. > > >> > > >>> It would certainly be better to either get the results from the .sum > > >>> files, or just use the contrib/test_summary script to do that for you. > > >> > > >> Ok, I posted the results as created by contrib/test_summary now: > > >> > > >> 1. non-LRA version on [1] > > >> > > >> 2. LRA version on [2] > > >> > > >> [1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817267.html > > >> > > >> [2]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817268.html > > > > > > Thanks! > > > > > > These ones are probably due to non-reserved names in glibc or kernel headers: > > > > > > FAIL: 17_intro/names.cc -std=gnu++17 (test for excess errors) > > > FAIL: 17_intro/names_pstl.cc -std=gnu++17 (test for excess errors) > > > FAIL: experimental/names.cc -std=gnu++17 (test for excess errors) > > > > > > The errors for all three are probably the same and should be > > > decipherable from libstdc++.log which will show which names defined as > > > macros in names.cc are clashing with names in system headers. > > And wouldn't failure of these imply that the headers are either ancient > > with some kind of pollution or that there's a ia64 specific goof in the > > headers? > > Yes, indeed. It probably means some ia64-specific structures in kernel > headers use non-reserved names like "next" or "ptr" or something, > instead of __next or __ptr. > > > These tests work on the other linux targets AFAIK. > > Most of them, yes. I think Jakub noticed some failures on s390x linux > recently, due to bad names in s390x-specific structs in the kernel > headers. Ah yes, see r14-10076-gcf5f7791056b3e for details - the commit message has lots of info. There were problems in kernel headers and in s390x-specific parts of glibc. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-13 10:33 ` Jonathan Wakely 2024-06-13 14:11 ` Jeff Law @ 2024-06-14 11:07 ` Frank Scheiner 2024-06-14 12:53 ` Jonathan Wakely 1 sibling, 1 reply; 29+ messages in thread From: Frank Scheiner @ 2024-06-14 11:07 UTC (permalink / raw) To: Jonathan Wakely, jeffreyalaw; +Cc: Richard Biener, gcc-patches, Rene Rebe [-- Attachment #1: Type: text/plain, Size: 2079 bytes --] Dear Jonathan, Jeff, On 13.06.24 12:33, Jonathan Wakely wrote: > On Wed, 12 Jun 2024 at 22:00, Frank Scheiner <frank.scheiner@web.de> wrote: >> Ok, I posted the results as created by contrib/test_summary now: >> >> 1. non-LRA version on [1] >> >> 2. LRA version on [2] >> >> [1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817267.html >> >> [2]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817268.html > > Thanks! > > These ones are probably due to non-reserved names in glibc or kernel headers: > > FAIL: 17_intro/names.cc -std=gnu++17 (test for excess errors) > FAIL: 17_intro/names_pstl.cc -std=gnu++17 (test for excess errors) > FAIL: experimental/names.cc -std=gnu++17 (test for excess errors) > > The errors for all three are probably the same and should be > decipherable from libstdc++.log which will show which names defined as > macros in names.cc are clashing with names in system headers. Thanks for the hints. I looked into the log now and searched for the respective tests. And the log excerpts for all three failing tests (also attached with more context): ``` FAIL: 17_intro/names.cc -std=gnu++17 (test for excess errors) Excess errors: /usr/include/bits/sigcontext.h:37: error: expected unqualified-id before ';' token /usr/include/bits/sigcontext.h:37: error: expected ')' before ';' token /usr/include/sys/ucontext.h:44: error: expected unqualified-id before ';' token /usr/include/sys/ucontext.h:44: error: expected ')' before ';' token ``` ...point to two headers which are part of glibc 2.39 (w/ia64 support re-added): * /usr/include/bits/sigcontext.h:32-38: ``` 32 struct __ia64_fpreg 33 { 34 union 35 { 36 unsigned long bits[2]; 37 } u; 38 } __attribute__ ((__aligned__ (16))); ``` * /usr/include/sys/ucontext.h:39-45: ``` 39 struct __ia64_fpreg_mcontext 40 { 41 union 42 { 43 unsigned long __ctx(bits)[2]; 44 } __ctx(u); 45 } __attribute__ ((__aligned__ (16))); ``` Cheers, Frank [-- Attachment #2: gcc-15-lra-failing-names-tests.md --] [-- Type: text/markdown, Size: 22539 bytes --] # Log excerpts for failing tests in libstdc++v3 for 5.0.0 20240528 (experimental) [master revision 236116068151bbc72aaaf53d0f223fe06f7e3bac] (GCC) w/LRA # ## FAIL: 17_intro/names.cc -std=gnu++17 (test for excess errors) ## ``` extra_tool_flags are: -std=gnu++17 -D__GLIBCXX__=99999999 Executing on host: /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/./gcc/xg++ -shared-libgcc -B/dev/shm/gcc-15-lra/src.gcc.ia64-to olchain-3.240529.123346.921189/gcc/gcc.build.lnx/./gcc -nostdinc++ -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux -gnu/libstdc++-v3/src -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/src/.libs -L/dev/shm/gcc-15 -lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/ia64-t2-linux-gnu/bin/ -B/usr/ia64-t2-linux -gnu/lib/ -isystem /usr/ia64-t2-linux-gnu/include -isystem /usr/ia64-t2-linux-gnu/sys-include -fchecking=1 -B/usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.12334 6.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -fPIC -D_GNU_SOUR CE -DLOCALEDIR="." -nostdinc++ -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include/ia64-t2-li nux-gnu -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include -I/dev/shm/gcc-15-lra/src.gcc.ia6 4-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/libsupc++ -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/backward -I /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/util /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/g cc/libstdc++-v3/testsuite/17_intro/names.cc -std=gnu++17 -D__GLIBCXX__=99999999 -fdiagnostics-plain-output -S -o names.s (timeout = 360) spawn -ignore SIGHUP /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/./gcc/xg++ -shared-libgcc -B/dev/shm/gcc-15-lra/src.gcc.ia64- toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/./gcc -nostdinc++ -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/src -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/src/.libs -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/ia64-t2-linux-gnu/bin/ -B/usr/ia64-t2-linux-gnu/lib/ -isystem /usr/ia64-t2-linux-gnu/include -isystem /usr/ia64-t2-linux-gnu/sys-include -fchecking=1 -B/usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -fPIC -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include/ia64-t2-linux-gnu -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/libsupc++ -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/backward -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/util /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/17_intro/names.cc -std=gnu++17 -D__GLIBCXX__=99999999 -fdiagnostics-plain-output -S -o names.s In file included from /usr/include/signal.h:301, from /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include/csignal:42, from /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include/ia64-t2-linux-gnu/bits/stdc++.h:116, from /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/17_intro/names.cc:378: /usr/include/bits/sigcontext.h:37: error: expected unqualified-id before ';' token /usr/include/bits/sigcontext.h:37: error: expected ')' before ';' token /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/17_intro/names.cc:101: note: to match this '(' In file included from /usr/include/signal.h:316: /usr/include/sys/ucontext.h:44: error: expected unqualified-id before ';' token /usr/include/sys/ucontext.h:44: error: expected ')' before ';' token /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/17_intro/names.cc:101: note: to match this '(' compiler exited with status 1 FAIL: 17_intro/names.cc -std=gnu++17 (test for excess errors) Excess errors: /usr/include/bits/sigcontext.h:37: error: expected unqualified-id before ';' token /usr/include/bits/sigcontext.h:37: error: expected ')' before ';' token /usr/include/sys/ucontext.h:44: error: expected unqualified-id before ';' token /usr/include/sys/ucontext.h:44: error: expected ')' before ';' token ``` => both listed headers are "part of the GNU C Library": /usr/include/bits/sigcontext.h:32-38: ``` 32 struct __ia64_fpreg 33 { 34 union 35 { 36 unsigned long bits[2]; 37 } u; 38 } __attribute__ ((__aligned__ (16))); ``` /usr/include/sys/ucontext.h:39-45: ``` 39 struct __ia64_fpreg_mcontext 40 { 41 union 42 { 43 unsigned long __ctx(bits)[2]; 44 } __ctx(u); 45 } __attribute__ ((__aligned__ (16))); ``` ## FAIL: 17_intro/names_pstl.cc -std=gnu++17 (test for excess errors) ## ``` extra_tool_flags are: -std=gnu++17 -D__GLIBCXX__=99999999 Executing on host: /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/./gcc/xg++ -shared-libgcc -B/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/./gcc -nostdinc++ -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/src -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/src/.libs -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/ia64-t2-linux-gnu/bin/ -B/usr/ia64-t2-linux-gnu/lib/ -isystem /usr/ia64-t2-linux-gnu/include -isystem /usr/ia64-t2-linux-gnu/sys-include -fchecking=1 -B/usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -fPIC -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include/ia64-t2-linux-gnu -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/libsupc++ -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/backward -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/util /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/17_intro/names_pstl.cc -std=gnu++17 -D__GLIBCXX__=99999999 -fdiagnostics-plain-output -S -o names_pstl.s (timeout = 360) spawn -ignore SIGHUP /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/./gcc/xg++ -shared-libgcc -B/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/./gcc -nostdinc++ -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/src -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/src/.libs -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/ia64-t2-linux-gnu/bin/ -B/usr/ia64-t2-linux-gnu/lib/ -isystem /usr/ia64-t2-linux-gnu/include -isystem /usr/ia64-t2-linux-gnu/sys-include -fchecking=1 -B/usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -fPIC -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include/ia64-t2-linux-gnu -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/libsupc++ -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/backward -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/util /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/17_intro/names_pstl.cc -std=gnu++17 -D__GLIBCXX__=99999999 -fdiagnostics-plain-output -S -o names_pstl.s In file included from /usr/include/signal.h:301, from /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include/csignal:42, from /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include/ia64-t2-linux-gnu/bits/stdc++.h:116, from /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/17_intro/names.cc:378, from /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/17_intro/names_pstl.cc:13: /usr/include/bits/sigcontext.h:37: error: expected unqualified-id before ';' token /usr/include/bits/sigcontext.h:37: error: expected ')' before ';' token /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/17_intro/names.cc:101: note: to match this '(' In file included from /usr/include/signal.h:316: /usr/include/sys/ucontext.h:44: error: expected unqualified-id before ';' token /usr/include/sys/ucontext.h:44: error: expected ')' before ';' token /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/17_intro/names.cc:101: note: to match this '(' In file included from /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include/ia64-t2-linux-gnu/bits/c++config.h:887, from /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include/cstddef:49, from /usr/include/oneapi/tbb/blocked_range.h:20, from /usr/include/oneapi/tbb.h:28, from /usr/include/tbb/tbb.h:17, from /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/17_intro/names_pstl.cc:10: /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h: In function '_RandomAccessIterator __pstl::__internal::__brick_unique(_RandomAccessIterator, _RandomAccessIterator, _BinaryPredicate, std::true_type)': /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h:1219: note: '#pragma message: [Parallel STL message]: "Vectorized algorithm unimplemented, redirected to serial"' /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h: In function '_RandomAccessIterator __pstl::__internal::__brick_partition(_RandomAccessIterator, _RandomAccessIterator, _UnaryPredicate, std::true_type)': /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h:1929: note: '#pragma message: [Parallel STL message]: "Vectorized algorithm unimplemented, redirected to serial"' /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h: In function '_RandomAccessIterator __pstl::__internal::__brick_stable_partition(_RandomAccessIterator, _RandomAccessIterator, _UnaryPredicate, std::true_type)': /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h:2029: note: '#pragma message: [Parallel STL message]: "Vectorized algorithm unimplemented, redirected to serial"' /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h: In function '_RandomAccessIterator3 __pstl::__internal::__brick_merge(_RandomAccessIterator1, _RandomAccessIterator1, _RandomAccessIterator2, _RandomAccessIterator2, _RandomAccessIterator3, _Compare, std::true_type)': /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h:2715: note: '#pragma message: [Parallel STL message]: "Vectorized algorithm unimplemented, redirected to serial"' /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h: In function 'void __pstl::__internal::__brick_inplace_merge(_RandomAccessIterator, _RandomAccessIterator, _RandomAccessIterator, _Compare, std::true_type)': /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h:2764: note: '#pragma message: [Parallel STL message]: "Vectorized algorithm unimplemented, redirected to serial"' /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h: In function '_OutputIterator __pstl::__internal::__brick_set_union(_RandomAccessIterator1, _RandomAccessIterator1, _RandomAccessIterator2, _RandomAccessIterator2, _OutputIterator, _Compare, std::true_type)': /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h:3141: note: '#pragma message: [Parallel STL message]: "Vectorized algorithm unimplemented, redirected to serial"' /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h: In function '_RandomAccessIterator3 __pstl::__internal::__brick_set_intersection(_RandomAccessIterator1, _RandomAccessIterator1, _RandomAccessIterator2, _RandomAccessIterator2, _RandomAccessIterator3, _Compare, std::true_type)': /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h:3202: note: '#pragma message: [Parallel STL message]: "Vectorized algorithm unimplemented, redirected to serial"' /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h: In function '_RandomAccessIterator3 __pstl::__internal::__brick_set_difference(_RandomAccessIterator1, _RandomAccessIterator1, _RandomAccessIterator2, _RandomAccessIterator2, _RandomAccessIterator3, _Compare, std::true_type)': /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h:3298: note: '#pragma message: [Parallel STL message]: "Vectorized algorithm unimplemented, redirected to serial"' /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h: In function '_RandomAccessIterator3 __pstl::__internal::__brick_set_symmetric_difference(_RandomAccessIterator1, _RandomAccessIterator1, _RandomAccessIterator2, _RandomAccessIterator2, _RandomAccessIterator3, _Compare, std::true_type)': /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/pstl/algorithm_impl.h:3390: note: '#pragma message: [Parallel STL message]: "Vectorized algorithm unimplemented, redirected to serial"' compiler exited with status 1 FAIL: 17_intro/names_pstl.cc -std=gnu++17 (test for excess errors) Excess errors: /usr/include/bits/sigcontext.h:37: error: expected unqualified-id before ';' token /usr/include/bits/sigcontext.h:37: error: expected ')' before ';' token /usr/include/sys/ucontext.h:44: error: expected unqualified-id before ';' token /usr/include/sys/ucontext.h:44: error: expected ')' before ';' token ``` ## FAIL: experimental/names.cc -std=gnu++17 (test for excess errors) ## ``` extra_tool_flags are: -std=gnu++17 -D__GLIBCXX__=99999999 Downloading on target to filebuf_members-1.txt: /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/data/filebuf_members-1.tx t Executing on host: /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/./gcc/xg++ -shared-libgcc -B/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/./gcc -nostdinc++ -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/src -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/src/.libs -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/ia64-t2-linux-gnu/bin/ -B/usr/ia64-t2-linux-gnu/lib/ -isystem /usr/ia64-t2-linux-gnu/include -isystem /usr/ia64-t2-linux-gnu/sys-include -fchecking=1 -B/usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -fPIC -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include/ia64-t2-linux-gnu -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/libsupc++ -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/backward -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/util /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/experimental/names.cc -std=gnu++17 -D__GLIBCXX__=99999999 -fdiagnostics-plain-output -S -o names.s (timeout = 360) spawn -ignore SIGHUP /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/./gcc/xg++ -shared-libgcc -B/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/./gcc -nostdinc++ -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/src -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/src/.libs -L/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/ia64-t2-linux-gnu/bin/ -B/usr/ia64-t2-linux-gnu/lib/ -isystem /usr/ia64-t2-linux-gnu/include -isystem /usr/ia64-t2-linux-gnu/sys-include -fchecking=1 -B/usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -fPIC -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include/ia64-t2-linux-gnu -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/libsupc++ -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/include/backward -I/dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/util /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/experimental/names.cc -std=gnu++17 -D__GLIBCXX__=99999999 -fdiagnostics-plain-output -S -o names.s In file included from /usr/include/signal.h:301, from /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include/csignal:42, from /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/gcc.build.lnx/ia64-t2-linux-gnu/libstdc++-v3/include/ia64-t2-linux-gnu/bits/stdc++.h:116, from /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/experimental/../17_intro/names.cc:378, from /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/experimental/names.cc:24: /usr/include/bits/sigcontext.h:37: error: expected unqualified-id before ';' token /usr/include/bits/sigcontext.h:37: error: expected ')' before ';' token /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/experimental/../17_intro/names.cc:101: note: to match this '(' In file included from /usr/include/signal.h:316: /usr/include/sys/ucontext.h:44: error: expected unqualified-id before ';' token /usr/include/sys/ucontext.h:44: error: expected ')' before ';' token /usr/src/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/experimental/../17_intro/names.cc:101: note: to match this '(' compiler exited with status 1 FAIL: experimental/names.cc -std=gnu++17 (test for excess errors) Excess errors: /usr/include/bits/sigcontext.h:37: error: expected unqualified-id before ';' token /usr/include/bits/sigcontext.h:37: error: expected ')' before ';' token /usr/include/sys/ucontext.h:44: error: expected unqualified-id before ';' token /usr/include/sys/ucontext.h:44: error: expected ')' before ';' token ``` ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-14 11:07 ` Frank Scheiner @ 2024-06-14 12:53 ` Jonathan Wakely 2024-06-14 13:07 ` Frank Scheiner 0 siblings, 1 reply; 29+ messages in thread From: Jonathan Wakely @ 2024-06-14 12:53 UTC (permalink / raw) To: Frank Scheiner; +Cc: jeffreyalaw, Richard Biener, gcc-patches, Rene Rebe On Fri, 14 Jun 2024 at 12:07, Frank Scheiner <frank.scheiner@web.de> wrote: > > Dear Jonathan, Jeff, > > On 13.06.24 12:33, Jonathan Wakely wrote: > > On Wed, 12 Jun 2024 at 22:00, Frank Scheiner <frank.scheiner@web.de> wrote: > >> Ok, I posted the results as created by contrib/test_summary now: > >> > >> 1. non-LRA version on [1] > >> > >> 2. LRA version on [2] > >> > >> [1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817267.html > >> > >> [2]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-June/817268.html > > > > Thanks! > > > > These ones are probably due to non-reserved names in glibc or kernel headers: > > > > FAIL: 17_intro/names.cc -std=gnu++17 (test for excess errors) > > FAIL: 17_intro/names_pstl.cc -std=gnu++17 (test for excess errors) > > FAIL: experimental/names.cc -std=gnu++17 (test for excess errors) > > > > The errors for all three are probably the same and should be > > decipherable from libstdc++.log which will show which names defined as > > macros in names.cc are clashing with names in system headers. > > Thanks for the hints. I looked into the log now and searched for the > respective tests. And the log excerpts for all three failing tests (also > attached with more context): > > ``` > FAIL: 17_intro/names.cc -std=gnu++17 (test for excess errors) > Excess errors: > /usr/include/bits/sigcontext.h:37: error: expected unqualified-id before > ';' token > /usr/include/bits/sigcontext.h:37: error: expected ')' before ';' token > /usr/include/sys/ucontext.h:44: error: expected unqualified-id before > ';' token > /usr/include/sys/ucontext.h:44: error: expected ')' before ';' token > ``` > > ...point to two headers which are part of glibc 2.39 (w/ia64 support > re-added): > > * /usr/include/bits/sigcontext.h:32-38: > ``` > 32 struct __ia64_fpreg > 33 { > 34 union > 35 { > 36 unsigned long bits[2]; > 37 } u; > 38 } __attribute__ ((__aligned__ (16))); > ``` > > * /usr/include/sys/ucontext.h:39-45: > ``` > 39 struct __ia64_fpreg_mcontext > 40 { > 41 union > 42 { > 43 unsigned long __ctx(bits)[2]; > 44 } __ctx(u); > 45 } __attribute__ ((__aligned__ (16))); > ``` This is an ia64-specific glibc bug, because it means the following valid C program is rejected: #define _GNU_SOURCE #define bits 111 #define u no u #include <signal.h> int main() { } ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-14 12:53 ` Jonathan Wakely @ 2024-06-14 13:07 ` Frank Scheiner 2024-06-14 13:23 ` Jonathan Wakely 0 siblings, 1 reply; 29+ messages in thread From: Frank Scheiner @ 2024-06-14 13:07 UTC (permalink / raw) To: Jonathan Wakely; +Cc: jeffreyalaw, Richard Biener, gcc-patches, Rene Rebe On 14.06.24 14:53, Jonathan Wakely wrote: > On Fri, 14 Jun 2024 at 12:07, Frank Scheiner <frank.scheiner@web.de> wrote: >> ...point to two headers which are part of glibc 2.39 (w/ia64 support >> re-added): >> >> * /usr/include/bits/sigcontext.h:32-38: >> ``` >> 32 struct __ia64_fpreg >> 33 { >> 34 union >> 35 { >> 36 unsigned long bits[2]; >> 37 } u; >> 38 } __attribute__ ((__aligned__ (16))); >> ``` >> >> * /usr/include/sys/ucontext.h:39-45: >> ``` >> 39 struct __ia64_fpreg_mcontext >> 40 { >> 41 union >> 42 { >> 43 unsigned long __ctx(bits)[2]; >> 44 } __ctx(u); >> 45 } __attribute__ ((__aligned__ (16))); >> ``` > > This is an ia64-specific glibc bug, because it means the following > valid C program is rejected: > > #define _GNU_SOURCE > #define bits 111 > #define u no u > #include <signal.h> > int main() { } Ok, I see. Should this then be "worked around" like in [1] with something like: ``` #if defined (__linux__) && defined (__ia64__) // <sys/ucontext.h> defines __ia64_fpreg_mcontext::u #undef u #endif ``` ...in `libstdc++-v3/testsuite/17_intro/names.cc` or should we fix it in glibc instead? [1]: https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=cf5f7791056b3ed993bc8024be767a86157514a9 Cheers, Frank ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-14 13:07 ` Frank Scheiner @ 2024-06-14 13:23 ` Jonathan Wakely 2024-06-17 18:03 ` Joseph Myers 0 siblings, 1 reply; 29+ messages in thread From: Jonathan Wakely @ 2024-06-14 13:23 UTC (permalink / raw) To: Frank Scheiner; +Cc: jeffreyalaw, Richard Biener, gcc-patches, Rene Rebe On Fri, 14 Jun 2024 at 14:07, Frank Scheiner <frank.scheiner@web.de> wrote: > > On 14.06.24 14:53, Jonathan Wakely wrote: > > On Fri, 14 Jun 2024 at 12:07, Frank Scheiner <frank.scheiner@web.de> wrote: > >> ...point to two headers which are part of glibc 2.39 (w/ia64 support > >> re-added): > >> > >> * /usr/include/bits/sigcontext.h:32-38: > >> ``` > >> 32 struct __ia64_fpreg > >> 33 { > >> 34 union > >> 35 { > >> 36 unsigned long bits[2]; > >> 37 } u; > >> 38 } __attribute__ ((__aligned__ (16))); > >> ``` > >> > >> * /usr/include/sys/ucontext.h:39-45: > >> ``` > >> 39 struct __ia64_fpreg_mcontext > >> 40 { > >> 41 union > >> 42 { > >> 43 unsigned long __ctx(bits)[2]; > >> 44 } __ctx(u); > >> 45 } __attribute__ ((__aligned__ (16))); > >> ``` > > > > This is an ia64-specific glibc bug, because it means the following > > valid C program is rejected: > > > > #define _GNU_SOURCE > > #define bits 111 > > #define u no u > > #include <signal.h> > > int main() { } > > Ok, I see. Should this then be "worked around" like in [1] with > something like: > > ``` > #if defined (__linux__) && defined (__ia64__) > // <sys/ucontext.h> defines __ia64_fpreg_mcontext::u > #undef u > #endif > ``` > > ...in `libstdc++-v3/testsuite/17_intro/names.cc` or should we fix it in > glibc instead? Both, ideally. The libstdc++ test should definitely be fixed because it fails with released versions of glibc already in the wild. But glibc should also be fixed because it's a standards conformance issue. > > [1]: > https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=cf5f7791056b3ed993bc8024be767a86157514a9 > > Cheers, > Frank > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-14 13:23 ` Jonathan Wakely @ 2024-06-17 18:03 ` Joseph Myers 2024-06-17 18:53 ` Jonathan Wakely 0 siblings, 1 reply; 29+ messages in thread From: Joseph Myers @ 2024-06-17 18:03 UTC (permalink / raw) To: Jonathan Wakely Cc: Frank Scheiner, jeffreyalaw, Richard Biener, gcc-patches, Rene Rebe On Fri, 14 Jun 2024, Jonathan Wakely wrote: > Both, ideally. The libstdc++ test should definitely be fixed because > it fails with released versions of glibc already in the wild. But > glibc should also be fixed because it's a standards conformance issue. The __ctx macro used in various sys/ucontext.h headers prepends __ in standards conformance modes (the point being to avoid breaking the API outside such modes when we fixed the namespace issues). #ifdef __USE_MISC # define __ctx(fld) fld #else # define __ctx(fld) __ ## fld #endif (bits/sigcontext.h didn't get any such fixes as it's not included at all in standards conformance modes, only if __USE_MISC.) -- Joseph S. Myers josmyers@redhat.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-17 18:03 ` Joseph Myers @ 2024-06-17 18:53 ` Jonathan Wakely 2024-06-17 19:36 ` Frank Scheiner 0 siblings, 1 reply; 29+ messages in thread From: Jonathan Wakely @ 2024-06-17 18:53 UTC (permalink / raw) To: Joseph Myers Cc: Frank Scheiner, jeffreyalaw, Richard Biener, gcc-patches, Rene Rebe On Mon, 17 Jun 2024 at 19:03, Joseph Myers <josmyers@redhat.com> wrote: > > On Fri, 14 Jun 2024, Jonathan Wakely wrote: > > > Both, ideally. The libstdc++ test should definitely be fixed because > > it fails with released versions of glibc already in the wild. But > > glibc should also be fixed because it's a standards conformance issue. > > The __ctx macro used in various sys/ucontext.h headers prepends __ in > standards conformance modes (the point being to avoid breaking the API > outside such modes when we fixed the namespace issues). > > #ifdef __USE_MISC > # define __ctx(fld) fld > #else > # define __ctx(fld) __ ## fld > #endif > > (bits/sigcontext.h didn't get any such fixes as it's not included at all > in standards conformance modes, only if __USE_MISC.) I see, thanks. So it's not a problem in C, only in C++ due to G++ defining _GNU_SOURCE. Let's just change the libstdc++ tests then. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-17 18:53 ` Jonathan Wakely @ 2024-06-17 19:36 ` Frank Scheiner 0 siblings, 0 replies; 29+ messages in thread From: Frank Scheiner @ 2024-06-17 19:36 UTC (permalink / raw) To: Jonathan Wakely, Joseph Myers Cc: jeffreyalaw, Richard Biener, gcc-patches, Rene Rebe On 17.06.24 20:53, Jonathan Wakely wrote: > On Mon, 17 Jun 2024 at 19:03, Joseph Myers <josmyers@redhat.com> wrote: >> >> On Fri, 14 Jun 2024, Jonathan Wakely wrote: >> >>> Both, ideally. The libstdc++ test should definitely be fixed because >>> it fails with released versions of glibc already in the wild. But >>> glibc should also be fixed because it's a standards conformance issue. >> >> The __ctx macro used in various sys/ucontext.h headers prepends __ in >> standards conformance modes (the point being to avoid breaking the API >> outside such modes when we fixed the namespace issues). >> >> #ifdef __USE_MISC >> # define __ctx(fld) fld >> #else >> # define __ctx(fld) __ ## fld >> #endif >> >> (bits/sigcontext.h didn't get any such fixes as it's not included at all >> in standards conformance modes, only if __USE_MISC.) > > I see, thanks. So it's not a problem in C, only in C++ due to G++ > defining _GNU_SOURCE. > > Let's just change the libstdc++ tests then. Great, I did test that patched in the same way as in [1] on Friday. It makes the three failing tests pass: ``` # make check-target-libstdc++-v3 RUNTESTFLAGS="conformance.exp=17_intro/names*\ experimental/names.cc" Test run by root on Fri Jun 14 16:04:26 2024 Native configuration is ia64-t2-linux-gnu === libstdc++ tests === Schedule of variations: unix Running target unix Running /dev/shm/gcc-15-lra/src.gcc.ia64-toolchain-3.240529.123346.921189/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... PASS: 17_intro/names.cc -std=gnu++17 (test for excess errors) PASS: 17_intro/names_pstl.cc -std=gnu++17 (test for excess errors) PASS: experimental/names.cc -std=gnu++17 (test for excess errors) === libstdc++ Summary === # of expected passes 3 ``` [1]: https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=cf5f7791056b3ed993bc8024be767a86157514a9 You most likely want the workaround as separate patch on this list, as the failures were happening for both the non-LRA and LRA case, right? Cheers, Frank ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/3] Enabled LRA for ia64. 2024-06-12 14:09 ` Frank Scheiner 2024-06-12 18:54 ` Jonathan Wakely @ 2024-06-13 7:02 ` Richard Biener 1 sibling, 0 replies; 29+ messages in thread From: Richard Biener @ 2024-06-13 7:02 UTC (permalink / raw) To: Frank Scheiner; +Cc: gcc-patches, Rene Rebe On Wed, 12 Jun 2024, Frank Scheiner wrote: > Dear Richard, > > On 12.06.24 13:01, Richard Biener wrote: > > [...] > > I can find two gcc-testresult postings, one appearantly with LRA > > and one without? Both from May: > > > > https://sourceware.org/pipermail/gcc-testresults/2024-May/816422.html > > https://sourceware.org/pipermail/gcc-testresults/2024-May/816346.html > > > > somehow for example libstdc++ summaries were not merged, it might > > be you do not have recent python installed on the system? Or you > > didn't use contrib/test_summary to create those mails. > > No, I did not use contrib/test_summary. But I still have tarballs of > both testsuite runs, so could still produce these summaries - I hope? > > Do I need to run this on the host that did the testing or can I run it > on my NFS server where the tarballs are actually located, too? > > Architectures are different though, the NFS server is 32-bit ARM. GCC supports parallel checking just fine using 'make -k -jN check' (it's important to add -k), the summaries and logs will be merged at the end of the testsuite run via the contrib/dg-extract-results.py script. The test_summary script will not do such merging but only gather FAILs and summaries from the individual sub-harness results into a nice summary report. Richard. > Cheers, > Frank > > -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg) ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH 3/3] MAINTAINERS: Add myself as IA-64 maintainer. 2024-06-12 10:33 ` [PATCH 0/3] Remove ia64*-*-linux from the list of obsolete targets Rene Rebe 2024-06-12 10:42 ` [PATCH 1/3] " Rene Rebe 2024-06-12 10:42 ` [PATCH 2/3] Enabled LRA for ia64 Rene Rebe @ 2024-06-12 10:43 ` Rene Rebe 2024-06-12 19:03 ` Jonathan Wakely 2024-06-12 18:44 ` [PATCH 0/3] Remove ia64*-*-linux from the list of obsolete targets Jonathan Wakely 3 siblings, 1 reply; 29+ messages in thread From: Rene Rebe @ 2024-06-12 10:43 UTC (permalink / raw) To: gcc-patches; +Cc: rguenther, frank.scheiner MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index e2870eef2ef..4328ca5f84c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -78,6 +78,7 @@ i386 port Jan Hubicka <hubicka@ucw.cz> i386 port Uros Bizjak <ubizjak@gmail.com> i386 vector ISA extns Kirill Yukhin <kirill.yukhin@gmail.com> i386 vector ISA extns Hongtao Liu <hongtao.liu@intel.com> +ia64 port René Rebe <rene.rebe@exactcode.com> iq2000 port Nick Clifton <nickc@redhat.com> lm32 port Sebastien Bourdeauducq <sebastien@milkymist.org> LoongArch port Chenghua Xu <xuchenghua@loongson.cn> -- 2.45.0 -- René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin https://exactcode.com | https://t2sde.org | https://rene.rebe.de ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 3/3] MAINTAINERS: Add myself as IA-64 maintainer. 2024-06-12 10:43 ` [PATCH 3/3] MAINTAINERS: Add myself as IA-64 maintainer Rene Rebe @ 2024-06-12 19:03 ` Jonathan Wakely 0 siblings, 0 replies; 29+ messages in thread From: Jonathan Wakely @ 2024-06-12 19:03 UTC (permalink / raw) To: Rene Rebe; +Cc: gcc-patches, rguenther, frank.scheiner On 12/06/24 12:43 +0200, Rene Rebe wrote: > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > >diff --git a/MAINTAINERS b/MAINTAINERS >index e2870eef2ef..4328ca5f84c 100644 >--- a/MAINTAINERS >+++ b/MAINTAINERS >@@ -78,6 +78,7 @@ i386 port Jan Hubicka <hubicka@ucw.cz> > i386 port Uros Bizjak <ubizjak@gmail.com> > i386 vector ISA extns Kirill Yukhin <kirill.yukhin@gmail.com> > i386 vector ISA extns Hongtao Liu <hongtao.liu@intel.com> >+ia64 port René Rebe <rene.rebe@exactcode.com> I think this change should only happen if/when you're officially appointed as the port maintainer by the steering committee. Port maintainers are expected to have a track record of good commits before being appointed. Just sending patches to resurrect the port and posting testresults seems OK for now. > iq2000 port Nick Clifton <nickc@redhat.com> > lm32 port Sebastien Bourdeauducq <sebastien@milkymist.org> > LoongArch port Chenghua Xu <xuchenghua@loongson.cn> >-- >2.45.0 > > >-- > René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin > https://exactcode.com | https://t2sde.org | https://rene.rebe.de ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 0/3] Remove ia64*-*-linux from the list of obsolete targets 2024-06-12 10:33 ` [PATCH 0/3] Remove ia64*-*-linux from the list of obsolete targets Rene Rebe ` (2 preceding siblings ...) 2024-06-12 10:43 ` [PATCH 3/3] MAINTAINERS: Add myself as IA-64 maintainer Rene Rebe @ 2024-06-12 18:44 ` Jonathan Wakely 3 siblings, 0 replies; 29+ messages in thread From: Jonathan Wakely @ 2024-06-12 18:44 UTC (permalink / raw) To: Rene Rebe; +Cc: gcc-patches, rguenther, frank.scheiner On 12/06/24 12:33 +0200, Rene Rebe wrote: >Hey there, > >I wanted to come back to maintaining the ia64 port as discussed >preciously the other month on the gcc list. > >It has been some days as we were busy releasing the biggest release of >our Embdded T2/Linux distribution [0] and we obviously did not want to >propose to enable LRA for IA-64 in the last last days of the gcc 14 >release process. > >We used the time to further stability test the LRA enabled GCC built >in T2/Linux and set up running the GCC testsuite accordingly for which >Frank posted test results from GCC git for reference [1] and w/ LRA >[2] enabled with only minimal changes, but also some new testsuite >passes. Due to the -j4 run I summed up the text files result manually >in LibreOffice: But the .sum files already combine all the results into one file. >gcc >35572, 31789 >33273, 28492 >37189, 36804 >28735, 37634 >sum 134769, 134719 > >g++ >69349, 61058 >61467, 63545 >61614, 63752 >56027, 60102 >sum 248457, 248457 > >gfortran >18895, 17502 >19329, 19051 >13950, 17583 >17442, 15482 >sum 69616, 69618 > >objc >693, 783 >760, 669 >609, 649 >716, 677 >sum 2778, 2778 > >ibstdc++ >4495, 4635 >4001, 3629 >3958, 4580 >4970, 4580 >sum 17424, 17424 > >The LRA enabled built Linux kernel and whole user-land packages boot >and function normally, too. > >Instead of looking into random test suite failures, I would first >rather try to allocate some time to look into some build failures for >more advanced real-world open source packages that I observered over >the last years and already occured unrelated of the LRA enablement. > >> > On Mar 7, 2024, at 20:08, Richard Biener <rguenther@suse.de> wrote: >> >> I saw the deprecation of ia64*-*-* scrolling by [1]. >> >> >> >> Which surprised me, as (minor bugs aside) gcc ia64*-*-linux just works for us and >> >> we still actively support it as part of our T2 System Development Environment [2]. >> >> >> >> For ia64 we are currently a team of three and also keep maintaining linux-kernel and >> >> glibc git trees with ia64 restored and hope to bring back ia64 to linux upstream the >> >> coming months as promised. [3] >> >> >> >> Despite popular believe ia64 actually just works for all those projects and we already >> >> fixed the few minor bugs we could find or reproduce. >> >> >> >> Last week I also already patched and tested enabling LRA for ia64 in gcc [4] and could >> >> -without any regression- compile a full ia64 T2/Linux release ISO that boots and runs >> >> including an X desktop and Gtk applications. That was of course even with the latest >> >> linux kernel and glibc versions with ia64 support restored respectively. >> >> >> >> Given there are currently no other volunteers, I therefore with this email step up and >> >> offer to become ia64 maintainer for GCC to keep the code compiling, tested and >> >> un-deprecated for the next years and releases to come. >> > >> > You’re welcome - we look forward to LRA enablement with ia64 and for it to get an >> > active maintainer. Note maintainers are appointed by the Steering Committee. > >[0] https://t2sde.org/ >[1] https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816346.html >[2] https://gcc.gnu.org/pipermail/gcc-testresults/2024-May/816422.html > >-- > René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin > https://exactcode.com | https://t2sde.org | https://rene.rebe.de ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2024-06-17 19:36 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <45833A6D-A84C-4276-AADB-BE2923886F64@exactcode.de>
[not found] ` <A935D68A-1B29-421A-A239-52CA50ADA239@suse.de>
[not found] ` <3DAB006A-ACE2-4BEC-AA01-87625DBEE259@exactcode.de>
2024-06-12 10:33 ` [PATCH 0/3] Remove ia64*-*-linux from the list of obsolete targets Rene Rebe
2024-06-12 10:42 ` [PATCH 1/3] " Rene Rebe
2024-06-12 18:40 ` Jonathan Wakely
2024-06-12 18:48 ` Jonathan Wakely
2024-06-13 8:58 ` Gerald Pfeifer
2024-06-12 10:42 ` [PATCH 2/3] Enabled LRA for ia64 Rene Rebe
2024-06-12 11:01 ` Richard Biener
2024-06-12 12:50 ` René Rebe
2024-06-12 13:00 ` Richard Biener
2024-06-12 13:19 ` René Rebe
2024-06-12 14:03 ` Frank Scheiner
2024-06-12 14:09 ` Frank Scheiner
2024-06-12 18:54 ` Jonathan Wakely
2024-06-12 20:59 ` Frank Scheiner
2024-06-13 10:33 ` Jonathan Wakely
2024-06-13 14:11 ` Jeff Law
2024-06-13 14:16 ` Jonathan Wakely
2024-06-13 14:18 ` Jonathan Wakely
2024-06-14 11:07 ` Frank Scheiner
2024-06-14 12:53 ` Jonathan Wakely
2024-06-14 13:07 ` Frank Scheiner
2024-06-14 13:23 ` Jonathan Wakely
2024-06-17 18:03 ` Joseph Myers
2024-06-17 18:53 ` Jonathan Wakely
2024-06-17 19:36 ` Frank Scheiner
2024-06-13 7:02 ` Richard Biener
2024-06-12 10:43 ` [PATCH 3/3] MAINTAINERS: Add myself as IA-64 maintainer Rene Rebe
2024-06-12 19:03 ` Jonathan Wakely
2024-06-12 18:44 ` [PATCH 0/3] Remove ia64*-*-linux from the list of obsolete targets Jonathan Wakely
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).