| Message ID | 20240612.124242.1291436266291405210.rene@exactcode.de |
|---|---|
| State | New |
| Headers | show |
| Series | Remove ia64*-*-linux from the list of obsolete targets | expand |
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. */ >
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)
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) > >
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)
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
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
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.
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
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 > >
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 >
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
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.
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.
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
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() { }
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
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 >
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.)
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.
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
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. */
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(-)