Re: [PATCH 2/3] Enabled LRA for ia64.
On 17.06.24 20:53, Jonathan Wakely wrote: On Mon, 17 Jun 2024 at 19:03, Joseph Myers 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 passes3 ``` [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
Re: [PATCH 2/3] Enabled LRA for ia64.
On Mon, 17 Jun 2024 at 19:03, Joseph Myers 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.
Re: [PATCH 2/3] Enabled LRA for ia64.
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 josmy...@redhat.com
Re: [PATCH 2/3] Enabled LRA for ia64.
On Fri, 14 Jun 2024 at 14:07, Frank Scheiner wrote:
>
> On 14.06.24 14:53, Jonathan Wakely wrote:
> > On Fri, 14 Jun 2024 at 12:07, Frank Scheiner 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
> > int main() { }
>
> Ok, I see. Should this then be "worked around" like in [1] with
> something like:
>
> ```
> #if defined (__linux__) && defined (__ia64__)
> // 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
>
Re: [PATCH 2/3] Enabled LRA for ia64.
On 14.06.24 14:53, Jonathan Wakely wrote:
On Fri, 14 Jun 2024 at 12:07, Frank Scheiner 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
int main() { }
Ok, I see. Should this then be "worked around" like in [1] with
something like:
```
#if defined (__linux__) && defined (__ia64__)
// 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
Re: [PATCH 2/3] Enabled LRA for ia64.
On Fri, 14 Jun 2024 at 12:07, Frank Scheiner wrote:
>
> Dear Jonathan, Jeff,
>
> On 13.06.24 12:33, Jonathan Wakely wrote:
> > On Wed, 12 Jun 2024 at 22:00, Frank Scheiner 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
int main() { }
Re: [PATCH 2/3] Enabled LRA for ia64.
Dear Jonathan, Jeff,
On 13.06.24 12:33, Jonathan Wakely wrote:
On Wed, 12 Jun 2024 at 22:00, Frank Scheiner 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
# 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__=
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__= -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-se
Re: [PATCH 2/3] Enabled LRA for ia64.
On Thu, 13 Jun 2024 at 15:16, Jonathan Wakely wrote: > > On Thu, 13 Jun 2024 at 15:11, Jeff Law wrote: > > > > > > > > On 6/13/24 4:33 AM, Jonathan Wakely wrote: > > > On Wed, 12 Jun 2024 at 22:00, Frank Scheiner > > > 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.
Re: [PATCH 2/3] Enabled LRA for ia64.
On Thu, 13 Jun 2024 at 15:11, Jeff Law wrote: > > > > On 6/13/24 4:33 AM, Jonathan Wakely wrote: > > On Wed, 12 Jun 2024 at 22:00, Frank Scheiner 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.
Re: [PATCH 2/3] Enabled LRA for ia64.
On 6/13/24 4:33 AM, Jonathan Wakely wrote: On Wed, 12 Jun 2024 at 22:00, Frank Scheiner 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
Re: [PATCH 2/3] Enabled LRA for ia64.
On Wed, 12 Jun 2024 at 22:00, Frank Scheiner 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 >
Re: [PATCH 2/3] Enabled LRA for ia64.
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 SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
Re: [PATCH 2/3] Enabled LRA for ia64.
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 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-
Re: [PATCH 2/3] Enabled LRA for ia64.
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.
Re: [PATCH 2/3] Enabled LRA for ia64.
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
Re: [PATCH 2/3] Enabled LRA for ia64.
Hi all, On 12.06.24 15:19, René Rebe wrote: On Jun 12, 2024, at 15:00, Richard Biener wrote: On Wed, 12 Jun 2024, René Rebe wrote: On Jun 12, 2024, at 13:01, Richard Biener 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
Re: [PATCH 2/3] Enabled LRA for ia64.
On Jun 12, 2024, at 15:00, Richard Biener wrote:
>
> On Wed, 12 Jun 2024, René Rebe wrote:
>
>> Hi,
>>
>>> On Jun 12, 2024, at 13:01, Richard Biener 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/c
Re: [PATCH 2/3] Enabled LRA for ia64.
On Wed, 12 Jun 2024, René Rebe wrote:
> Hi,
>
> > On Jun 12, 2024, at 13:01, Richard Biener 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")))]
> >
Re: [PATCH 2/3] Enabled LRA for ia64.
Hi,
> On Jun 12, 2024, at 13:01, Richard Biener 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
> 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 | htt
Re: [PATCH 2/3] Enabled LRA for ia64.
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
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
[PATCH 2/3] Enabled LRA for ia64.
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
