* [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
* [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
* [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 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 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 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
* 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 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 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 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 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
* 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
* 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
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).