Re: Stepping up as maintainer for ia64
> On Mar 7, 2024, at 20:08, Richard Biener wrote: > >> Am 07.03.2024 um 19:09 schrieb 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. > > 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-x7kyh6s...@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...@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
[PATCH] fix PowerPC < 7 w/ Altivec not to default to power7
This might not be the best timing -short before a major release-, however, Sam just commented on the bug I filled years ago [1], so here we go: Glibc uses .machine to determine assembler optimizations to use. However, since reworking the rs6000 .machine output selection in commit e154242724b084380e3221df7c08fcdbd8460674 22 May 2019, G5 as well as Cell, and even power4 w/ -maltivec currently resulted in power7. Mask _ALTIVEC away as the .machine selection already did for GFX and GPOPT. powerpc64-t2-linux-gnu-gcc test.c -S -o - -mcpu=G5 .file "test.c" .machine power7 .abiversion 2 .section".text" .ident "GCC: (GNU) 10.2.0" .section.note.GNU-stack,"",@progbits We ship this in T2/Linux [2] since 2020 and it is tested on G5, Cell and Power8. Signed-of-by: René Rebe [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367 [2] https://t2sde.org --- gcc-11.1.0-RC-20210423/gcc/config/rs6000/rs6000.cc.vanilla 2021-04-25 22:57:16.964223106 +0200 +++ gcc-11.1.0-RC-20210423/gcc/config/rs6000/rs6000.cc 2021-04-25 22:57:27.193223841 +0200 @@ -5765,7 +5765,7 @@ HOST_WIDE_INT flags = rs6000_isa_flags; /* Disable the flags that should never influence the .machine selection. */ - flags &= ~(OPTION_MASK_PPC_GFXOPT | OPTION_MASK_PPC_GPOPT | OPTION_MASK_ISEL); + flags &= ~(OPTION_MASK_PPC_GFXOPT | OPTION_MASK_PPC_GPOPT | OPTION_MASK_ALTIVEC | OPTION_MASK_ISEL); if ((flags & (ISA_3_1_MASKS_SERVER & ~ISA_3_0_MASKS_SERVER)) != 0) return "power10"; -- René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10789 Berlin https://exactcode.com | https://t2sde.org | https://rene.rebe.de
Re: [PATCH] fix PowerPC < 7 w/ Altivec not to default to power7
On Fri, 8 Mar 2024 at 11:27, Rene Rebe wrote: > > This might not be the best timing -short before a major release-, > however, Sam just commented on the bug I filled years ago [1], so here > we go: > > Glibc uses .machine to determine assembler optimizations to use. > However, since reworking the rs6000 .machine output selection in > commit e154242724b084380e3221df7c08fcdbd8460674 22 May 2019, G5 as > well as Cell, and even power4 w/ -maltivec currently resulted in > power7. Mask _ALTIVEC away as the .machine selection already did for > GFX and GPOPT. > > powerpc64-t2-linux-gnu-gcc test.c -S -o - -mcpu=G5 > .file "test.c" > .machine power7 > .abiversion 2 > .section".text" > .ident "GCC: (GNU) 10.2.0" > .section.note.GNU-stack,"",@progbits > > We ship this in T2/Linux [2] since 2020 and it is tested on G5, Cell > and Power8. > > Signed-of-by: René Rebe > > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97367 > [2] https://t2sde.org > > --- gcc-11.1.0-RC-20210423/gcc/config/rs6000/rs6000.cc.vanilla 2021-04-25 > 22:57:16.964223106 +0200 > +++ gcc-11.1.0-RC-20210423/gcc/config/rs6000/rs6000.cc 2021-04-25 > 22:57:27.193223841 +0200 > @@ -5765,7 +5765,7 @@ >HOST_WIDE_INT flags = rs6000_isa_flags; > >/* Disable the flags that should never influence the .machine selection. > */ > - flags &= ~(OPTION_MASK_PPC_GFXOPT | OPTION_MASK_PPC_GPOPT | > OPTION_MASK_ISEL); > + flags &= ~(OPTION_MASK_PPC_GFXOPT | OPTION_MASK_PPC_GPOPT | > OPTION_MASK_ALTIVEC | OPTION_MASK_ISEL); > >if ((flags & (ISA_3_1_MASKS_SERVER & ~ISA_3_0_MASKS_SERVER)) != 0) > return "power10"; Patches should be sent to the gcc-patches list instead of this one, and should be against trunk not an old gcc-11 RC. See https://gcc.gnu.org/contribute.html#patches for more details - thanks!
Re: Stepping up as maintainer for ia64
On Fri, 8 Mar 2024, Ren? Rebe wrote: > > > On Mar 7, 2024, at 20:08, Richard Biener wrote: > > > >> Am 07.03.2024 um 19:09 schrieb 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. > > > > 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-x7kyh6s...@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...@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 SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
Questions about language hooks and some macro definitions
Hello, I have been trying to understand the higher level structure of g++, so I have been reading the source code. I'm not sure about some things and asked the dev irc channel. There I was recommended to ask them here so: 1) Is there some reason, why following language hook definitions have not been removed from cp/cp-lang.cc: LANG_HOOKS_CLEAR_BINDING_STACK pop_everything LANG_HOOKS_HANDLE_FILENAME c_common_handle_filename as they were removed in following patches: 2008-03-11 Paolo Bonzini * langhooks-def.h (LANG_HOOKS_CLEAR_BINDING_STACK): Delete. * langhooks.h (struct lang_hooks): delete clear_binding_stack member. * toplev.c (compile_file): Don't call it. 2003-07-31 Per Bothner * opts.c (in_fnames, num_in_fnames): Moved here from c-opts. (add_input_filename): New function. (handle_options): Call add_input_filename directly instead of with a lang hook. * opts.h (in_fnames, num_in_fnames): Moved here. (add_input_filename): Declare. * c-decl.c: Need to #include opts.h. * Makefile.in (c-decl.o): Also depends on opts.h. * c-opts.c (in_fnames, num_in_fnames): Moved to opts.c. (c_common_handle_filename): Replaced by add_input_filename. * c-common.h (in_fnames, num_in_fnames, c_common_handle_filename): Remove. * langhooks.h (struct lang_hooks): Remove handle_filename hook. * langhooks-def.h (LANG_HOOKS_HANDLE_FILENAME): Remove macro. (LANG_HOOKS_INITIALIZER): Remove use of LANG_HOOKS_HANDLE_FILENAME. * c-lang.c (LANG_HOOKS_HANDLE_FILENAME): Remove macro. 2) Why macro FROB_CONTEXT in cp/cp-tree.h: #define FROB_CONTEXT(NODE) \ ((NODE) == global_namespace ? DECL_CONTEXT (NODE) : (NODE)) returns DECL_CONTEXT (NODE) if NODE is global_namespace, as the gcc internal manual says that: > The DECL_CONTEXT for the global_namespace is NULL_TREE Isn't DECL_CONTEXT (NODE) redundant and could be replaced by NULL_TREE? I assume that the answers for both is simply that, nobody just has not written a patch removing them. However I'm not sure as there might be some deeper reason that I'm not understanding. -- Miro Palmu
Re: Stepping up as maintainer for ia64
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: [PATCH] fix PowerPC < 7 w/ Altivec not to default to power7
On 3/8/24 5:30 AM, Jonathan Wakely via Gcc wrote: > Patches should be sent to the gcc-patches list instead of this one, > and should be against trunk not an old gcc-11 RC. See > https://gcc.gnu.org/contribute.html#patches for more details - thanks! And you need to CC the rs6000/powerpc port maintainers which you can find along with their preferred email addresses in the MAINTAINERS file. If you don't CC them, they may miss seeing the patch. Peter
Re: Stepping up as maintainer for ia64
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
gcc-12-20240308 is now available
Snapshot gcc-12-20240308 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20240308/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision 36650e98d521788b108afd772615f0ecea2e83de You'll find: gcc-12-20240308.tar.xz Complete GCC SHA256=42286fc76ece551aec4bbddd478ab41fe6c5362eb30870f8000c43e1de8f8522 SHA1=c8e2e1d8ff66eb3f9ec71f7c5eb149fca4e718e7 Diffs from 12-20240301 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Stepping up as maintainer for ia64
On Fri, 8 Mar 2024 at 22:35, Frank Scheiner via Gcc 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
On 3/8/24 5:28 PM, Jonathan Wakely wrote: > On Fri, 8 Mar 2024 at 22:35, Frank Scheiner via Gcc 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
