Stepping up as maintainer for ia64

Stepping up as maintainer for ia64

[René Rebe]

Hey there,

I saw the deprecation of ia64*-*-* scrolling by [1].

Which surprised me, as (minor bugs aside) gcc ia64*-*-linux just works for us and
we still actively support it as part of our T2 System Development Environment [2].

For ia64 we are currently a team of three and also keep maintaining linux-kernel and
glibc git trees with ia64 restored and hope to bring back ia64 to linux upstream the
coming months as promised. [3]

Despite popular believe ia64 actually just works for all those projects and we already
fixed the few minor bugs we could find or reproduce.

Last week I also already patched and tested enabling LRA for ia64 in gcc [4] and could
-without any regression- compile a full ia64 T2/Linux release ISO that boots and runs
including an X desktop and Gtk applications. That was of course even with the latest
linux kernel and glibc versions with ia64 support restored respectively.

Given there are currently no other volunteers, I therefore with this email step up and
offer to become ia64 maintainer for GCC to keep the code compiling, tested and
un-deprecated for the next years and releases to come.

Thank you so much,
	René Rebe

[1] https://inbox.sourceware.org/gcc-bugs/bug-90785-4-X7KYh6SLIg@http.gcc.gnu.org%2Fbugzilla%2F/T/
[2] https://t2sde.org/#news-2023-12-05
[3] https://lore.kernel.org/linux-ia64/CAHk-=whFLZ67ffzt1juryCYcYz6eL_XjQF8WucDzwUR5H65+rA@mail.gmail.com/
[4] https://svn.exactcode.de/t2/trunk/package/develop/gcc/ia64-lra-impl.patch

--
ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
https://exactcode.com | https://t2sde.org

Re: Stepping up as maintainer for ia64

[Richard Biener]

> Am 07.03.2024 um 19:09 schrieb René Rebe <rene@exactcode.de>:
> 
> Hey there,
> 
> I saw the deprecation of ia64*-*-* scrolling by [1].
> 
> Which surprised me, as (minor bugs aside) gcc ia64*-*-linux just works for us and
> we still actively support it as part of our T2 System Development Environment [2].
> 
> For ia64 we are currently a team of three and also keep maintaining linux-kernel and
> glibc git trees with ia64 restored and hope to bring back ia64 to linux upstream the
> coming months as promised. [3]
> 
> Despite popular believe ia64 actually just works for all those projects and we already
> fixed the few minor bugs we could find or reproduce.
> 
> Last week I also already patched and tested enabling LRA for ia64 in gcc [4] and could
> -without any regression- compile a full ia64 T2/Linux release ISO that boots and runs
> including an X desktop and Gtk applications. That was of course even with the latest
> linux kernel and glibc versions with ia64 support restored respectively.
> 
> Given there are currently no other volunteers, I therefore with this email step up and
> offer to become ia64 maintainer for GCC to keep the code compiling, tested and
> un-deprecated for the next years and releases to come.

You’re welcome - we look forward to LRA enablement with ia64 and for it to get an
active maintainer.  Note maintainers are appointed by the Steering Committee.

If I read you correctly you’d keep the ia64-Linux port alive but the other sub-architectures like the hpux port can remain deprecated?

Thanks,
Richard 

> Thank you so much,
>    René Rebe
> 
> [1] https://inbox.sourceware.org/gcc-bugs/bug-90785-4-X7KYh6SLIg@http.gcc.gnu.org%2Fbugzilla%2F/T/
> [2] https://t2sde.org/#news-2023-12-05
> [3] https://lore.kernel.org/linux-ia64/CAHk-=whFLZ67ffzt1juryCYcYz6eL_XjQF8WucDzwUR5H65+rA@mail.gmail.com/
> [4] https://svn.exactcode.de/t2/trunk/package/develop/gcc/ia64-lra-impl.patch
> 
> --
> ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
> https://exactcode.com | https://t2sde.org

Re: Stepping up as maintainer for ia64

[René Rebe]

> On Mar 7, 2024, at 20:08, Richard Biener <rguenther@suse.de> wrote:
> 
>> Am 07.03.2024 um 19:09 schrieb René Rebe <rene@exactcode.de>:
>> 
>> Hey there,
>> 
>> I saw the deprecation of ia64*-*-* scrolling by [1].
>> 
>> Which surprised me, as (minor bugs aside) gcc ia64*-*-linux just works for us and
>> we still actively support it as part of our T2 System Development Environment [2].
>> 
>> For ia64 we are currently a team of three and also keep maintaining linux-kernel and
>> glibc git trees with ia64 restored and hope to bring back ia64 to linux upstream the
>> coming months as promised. [3]
>> 
>> Despite popular believe ia64 actually just works for all those projects and we already
>> fixed the few minor bugs we could find or reproduce.
>> 
>> Last week I also already patched and tested enabling LRA for ia64 in gcc [4] and could
>> -without any regression- compile a full ia64 T2/Linux release ISO that boots and runs
>> including an X desktop and Gtk applications. That was of course even with the latest
>> linux kernel and glibc versions with ia64 support restored respectively.
>> 
>> Given there are currently no other volunteers, I therefore with this email step up and
>> offer to become ia64 maintainer for GCC to keep the code compiling, tested and
>> un-deprecated for the next years and releases to come.
> 
> You’re welcome - we look forward to LRA enablement with ia64 and for it to get an
> active maintainer.  Note maintainers are appointed by the Steering Committee.

Great, I would suggest committing enabling LRA after the imminent stable release
for the next major GCC version. It would be nice to revert the deprecation if possible.
But in practice if of course does not really if we build the next stable release with
--enable-obsolete it just would look better.

> If I read you correctly you’d keep the ia64-Linux port alive but the other sub-architectures like the hpux port can remain deprecated?

Yes, as far as I am concerned we are only caring about Linux support. I guess
that could mean extra work for me carefully only deleting hpux code then?

I’ll send out the copyright assignment mail later today.
How can we get this Steeting Committee pointing going?

Thanks!
	René

> Thanks,
> Richard 
> 
>> Thank you so much,
>>   René Rebe
>> 
>> [1] https://inbox.sourceware.org/gcc-bugs/bug-90785-4-X7KYh6SLIg@http.gcc.gnu.org%2Fbugzilla%2F/T/
>> [2] https://t2sde.org/#news-2023-12-05
>> [3] https://lore.kernel.org/linux-ia64/CAHk-=whFLZ67ffzt1juryCYcYz6eL_XjQF8WucDzwUR5H65+rA@mail.gmail.com/
>> [4] https://svn.exactcode.de/t2/trunk/package/develop/gcc/ia64-lra-impl.patch
>> 
>> --
>> ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
>> https://exactcode.com | https://t2sde.org

--
ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
http://exactcode.com | http://exactscan.com | http://ocrkit.com

Re: Stepping up as maintainer for ia64

[Richard Biener]

[-- Attachment #1: Type: text/plain, Size: 3915 bytes --]

On Fri, 8 Mar 2024, Ren? Rebe wrote:

> 
> > On Mar 7, 2024, at 20:08, Richard Biener <rguenther@suse.de> wrote:
> > 
> >> Am 07.03.2024 um 19:09 schrieb Ren? Rebe <rene@exactcode.de>:
> >> 
> >> Hey there,
> >> 
> >> I saw the deprecation of ia64*-*-* scrolling by [1].
> >> 
> >> Which surprised me, as (minor bugs aside) gcc ia64*-*-linux just works for us and
> >> we still actively support it as part of our T2 System Development Environment [2].
> >> 
> >> For ia64 we are currently a team of three and also keep maintaining linux-kernel and
> >> glibc git trees with ia64 restored and hope to bring back ia64 to linux upstream the
> >> coming months as promised. [3]
> >> 
> >> Despite popular believe ia64 actually just works for all those projects and we already
> >> fixed the few minor bugs we could find or reproduce.
> >> 
> >> Last week I also already patched and tested enabling LRA for ia64 in gcc [4] and could
> >> -without any regression- compile a full ia64 T2/Linux release ISO that boots and runs
> >> including an X desktop and Gtk applications. That was of course even with the latest
> >> linux kernel and glibc versions with ia64 support restored respectively.
> >> 
> >> Given there are currently no other volunteers, I therefore with this email step up and
> >> offer to become ia64 maintainer for GCC to keep the code compiling, tested and
> >> un-deprecated for the next years and releases to come.
> > 
> > You?re welcome - we look forward to LRA enablement with ia64 and for it to get an
> > active maintainer.  Note maintainers are appointed by the Steering Committee.
> 
> Great, I would suggest committing enabling LRA after the imminent stable release
> for the next major GCC version. It would be nice to revert the deprecation if possible.
> But in practice if of course does not really if we build the next stable release with
> --enable-obsolete it just would look better.
> 
> > If I read you correctly you?d keep the ia64-Linux port alive but the other sub-architectures like the hpux port can remain deprecated?
> 
> Yes, as far as I am concerned we are only caring about Linux support. I guess
> that could mean extra work for me carefully only deleting hpux code then?

Well, the easy part is just removing the deprecated configs from
gcc/config.gcc, but yes, cleanup in the port specific code could be done.

> I?ll send out the copyright assignment mail later today.
> How can we get this Steeting Committee pointing going?

I CCed Jeff who is on the commitee to forward the maintainer proposal
though I guess this will not go forward as a first step.  Instead
you are probably expected to show activity on the port, for example
post the patch series to make ia64 use LRA, get write access to the
git repository and then be promoted maintainer.

It's good you started the copyright assignment process though
technically you can also contribute under the DCO.

As a first patch you might want to propose to un-deprecate the
ia64*-*-linux* triplets?

Thanks,
Richard.


> Thanks!
> 	Ren?
> 
> > Thanks,
> > Richard 
> > 
> >> Thank you so much,
> >>   Ren? Rebe
> >> 
> >> [1] https://inbox.sourceware.org/gcc-bugs/bug-90785-4-X7KYh6SLIg@http.gcc.gnu.org%2Fbugzilla%2F/T/
> >> [2] https://t2sde.org/#news-2023-12-05
> >> [3] https://lore.kernel.org/linux-ia64/CAHk-=whFLZ67ffzt1juryCYcYz6eL_XjQF8WucDzwUR5H65+rA@mail.gmail.com/
> >> [4] https://svn.exactcode.de/t2/trunk/package/develop/gcc/ia64-lra-impl.patch
> >> 
> >> --
> >> ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
> >> https://exactcode.com | https://t2sde.org
> 
> --
> ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin
> http://exactcode.com | http://exactscan.com | http://ocrkit.com
> 
> 

-- 
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)

Re: Stepping up as maintainer for ia64

[Peter Bergner]

On 3/8/24 7:16 AM, Richard Biener via Gcc wrote:
> I CCed Jeff who is on the commitee to forward the maintainer proposal
> though I guess this will not go forward as a first step.  Instead
> you are probably expected to show activity on the port, for example
> post the patch series to make ia64 use LRA, get write access to the
> git repository and then be promoted maintainer.

One other method for showing activity is posting regular testsuite
results on the gcc-testresults mailing list to show the community
the port is "working".

Peter

Re: Stepping up as maintainer for ia64

[Frank Scheiner]

On 08.03.24 23:00, Peter Bergner wrote:
> On 3/8/24 7:16 AM, Richard Biener via Gcc wrote:
>> I CCed Jeff who is on the commitee to forward the maintainer proposal
>> though I guess this will not go forward as a first step.  Instead
>> you are probably expected to show activity on the port, for example
>> post the patch series to make ia64 use LRA, get write access to the
>> git repository and then be promoted maintainer.
>
> One other method for showing activity is posting regular testsuite
> results on the gcc-testresults mailing list to show the community
> the port is "working".

I don't want to spam this or the other list each and every week, but I
am since a while cross-compiling each Linux mainline RC and release with
the latest gcc-14 snapshot available each time and test the result on a
variety of real machines and on the HP Sim platform in Ski (since
recently). And since doing that I haven't seen any new ICEs since I
reported [1].

[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111425

Something similar is done automatically for the Linux stable RC and
releases but with a fixed gcc-13.2.0 cross-compiler (provided by Arnd
Bergmann on [2]) on GitHub, including a test run in Ski, see for example
[3].

[2]: https://mirrors.edge.kernel.org/pub/tools/crosstool/

[3]:
https://github.com/johnny-mnemonic/linux-stable-rc/actions/runs/8198165399

Both are surely not as extensive as a testsuite run, but give a good
preview I think: it's working for what we are doing with these machines,
thanks for asking.

Cheers,
Frank

Re: Stepping up as maintainer for ia64

[Jonathan Wakely]

On Fri, 8 Mar 2024 at 22:35, Frank Scheiner via Gcc <gcc@gcc.gnu.org> wrote:
>
> On 08.03.24 23:00, Peter Bergner wrote:
> > On 3/8/24 7:16 AM, Richard Biener via Gcc wrote:
> >> I CCed Jeff who is on the commitee to forward the maintainer proposal
> >> though I guess this will not go forward as a first step.  Instead
> >> you are probably expected to show activity on the port, for example
> >> post the patch series to make ia64 use LRA, get write access to the
> >> git repository and then be promoted maintainer.
> >
> > One other method for showing activity is posting regular testsuite
> > results on the gcc-testresults mailing list to show the community
> > the port is "working".
>
> I don't want to spam this or the other list each and every week, but I

Sending test results to the gcc-testresults list is **not** spamming,
that's what the list is for!

https://gcc.gnu.org/pipermail/gcc-testresults/2024-March/date.html

If you're testing uncommon targets (e.g. ia64-linux) then sending test
results to the list is essential so we know the target builds, because
nobody else is testing it.

Re: Stepping up as maintainer for ia64

[Peter Bergner]

On 3/8/24 5:28 PM, Jonathan Wakely wrote:
> On Fri, 8 Mar 2024 at 22:35, Frank Scheiner via Gcc <gcc@gcc.gnu.org> wrote:
>>
>> On 08.03.24 23:00, Peter Bergner wrote:
>>> On 3/8/24 7:16 AM, Richard Biener via Gcc wrote:
>>>> I CCed Jeff who is on the commitee to forward the maintainer proposal
>>>> though I guess this will not go forward as a first step.  Instead
>>>> you are probably expected to show activity on the port, for example
>>>> post the patch series to make ia64 use LRA, get write access to the
>>>> git repository and then be promoted maintainer.
>>>
>>> One other method for showing activity is posting regular testsuite
>>> results on the gcc-testresults mailing list to show the community
>>> the port is "working".
>>
>> I don't want to spam this or the other list each and every week, but I
> 
> Sending test results to the gcc-testresults list is **not** spamming,
> that's what the list is for!

100% agree!  If you look at what we (IBM) post, we roughly post somewhere
around 7 testsuite results per day due to runs on different hardware,
endianness and OS (Linux versus AIX).  So spam ...err... post away!



> If you're testing uncommon targets (e.g. ia64-linux) then sending test
> results to the list is essential so we know the target builds, because
> nobody else is testing it.

Again, 100% agree!

Peter

Re: Stepping up as maintainer for ia64

[Frank Scheiner]

On 09.03.24 03:18, Peter Bergner via Gcc wrote:
> On 3/8/24 5:28 PM, Jonathan Wakely wrote:
>> On Fri, 8 Mar 2024 at 22:35, Frank Scheiner via Gcc <gcc@gcc.gnu.org> wrote:
>>>
>>> On 08.03.24 23:00, Peter Bergner wrote:
>>>> On 3/8/24 7:16 AM, Richard Biener via Gcc wrote:
>>>>> I CCed Jeff who is on the commitee to forward the maintainer proposal
>>>>> though I guess this will not go forward as a first step.  Instead
>>>>> you are probably expected to show activity on the port, for example
>>>>> post the patch series to make ia64 use LRA, get write access to the
>>>>> git repository and then be promoted maintainer.
>>>>
>>>> One other method for showing activity is posting regular testsuite
>>>> results on the gcc-testresults mailing list to show the community
>>>> the port is "working".
>>>
>>> I don't want to spam this or the other list each and every week, but I
>>
>> Sending test results to the gcc-testresults list is **not** spamming,
>> that's what the list is for!
>
> 100% agree!  If you look at what we (IBM) post, we roughly post somewhere
> around 7 testsuite results per day due to runs on different hardware,
> endianness and OS (Linux versus AIX).  So spam ...err... post away!
>
>
>
>> If you're testing uncommon targets (e.g. ia64-linux) then sending test
>> results to the list is essential so we know the target builds, because
>> nobody else is testing it.
>
> Again, 100% agree!

Ok, ok, I'll do. :-)

Cheers,
Frank