Docs and port needs some axe, otherwise we should not release it.
port is also unmaintained (no MAINTAINERS entry)
CCing Mentor / AdaCore folks who stepped up as maintainers.
Can't see how ppc-spe can be P1 :-) BUt will certainly confirm that some cleanup should happen here.
On December 12, 2017 12:51:35 AM GMT+01:00, law at redhat dot com <gcc-bugzilla@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 > >Jeffrey A. Law <law at redhat dot com> changed: > > What |Removed |Added >---------------------------------------------------------------------------- > Priority|P1 |P4 > Status|UNCONFIRMED |NEW > Last reconfirmed| |2017-12-11 > CC| |law at redhat dot com > Ever confirmed|0 |1 > >--- Comment #3 from Jeffrey A. Law <law at redhat dot com> --- >Can't see how ppc-spe can be P1 :-) BUt will certainly confirm that >some >cleanup should happen here. It was P1 because the deal was to clean it up or the port was to be removed for GCC 8.
P1 again, note to maintainers: we'll axe powerpcspe if user-facing interfaces/docs are not cleaned up. It'll be a 100% sign of the port being not maintained.
So let's put also a deadline, if the port isn't cleaned by end of January, it is dropped. Delaying changes further would mean it won't get the testing it would deserve.
If we do keep the port, PR83691 should be fixed by someone who can test it. I can write a candidate patch if the feeling is that I broke it with r256209, but it would mean changing a core pattern like adddi3, which really needs testing on a real target.
Any progress here?
Sorry for the lack of comment from me - I only just saw this bug (I was not receiving email from bugzilla but hopefully I have fixed this now). I am part-way through the cleanup. I will commit what I have so far before the end of January if it is not finished - there may be more to come after that.
That would be appreciated. Besides killing the non-SPE relevant stuff in powerpcspe, I think a review of the rs6000 changes from the last year that might be relevant to powerpcspe is desirable too. While changes that were done for all backends usually were done for powerpcspe too, without much testing though, most of the rs6000 fixes weren't, and while lots of that has been related to ISAs powerpcspe doesn't have, some of it certainly applies even to this port.
Even rs6000 changes related to IEEE long double support are potentially relevant to powerpcspe (not anything related to binary128 in VSX, obviously, but more generic IEEE long double changes). I suspect the support for IEEE long double for 32-bit is pretty bit-rotten (old ABI passing by reference, I think), but logically it's just as meaningful for this port as for rs6000 (and powerpcspe should stay compatible with the soft-float ABI in the rs6000 port). Shared between the ports (so you don't need to do any cleanup there at present for this issue): libgcc code, documentation, testsuite/gcc.target/powerpc. As powerpcspe is neither a primary nor secondary target, you're free to apply non-regression-fix changes as you wish, but it's up to you to have the port in a stable state at the time of branching as any instability of such a port won't be relevant to choosing when to branch for a release.
I have been reading gcc-patches and keeping a list of the rs6000 changes that I will need to port. I will go through the svn log for rs6000 as well to make sure I haven't missed anything. Thanks!
Created attachment 43312 [details] Patch in progress so far
I've got most of the major chunks removed now as you can see from my work-in-progress patch, but I'm still working through a long list of little things I've noticed that need cleaning up. I'm not sure that the backend will build with the changes in their current state so I haven't committed them yet, but I expect to be able to do so by the end of the week. Thanks for your patience!
On Wed, 31 Jan 2018, andrewjenner at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 > > Andrew Jenner <andrewjenner at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |ASSIGNED > Assignee|unassigned at gcc dot gnu.org |andrewjenner at gcc dot gnu.org > > --- Comment #14 from Andrew Jenner <andrewjenner at gcc dot gnu.org> --- > I've got most of the major chunks removed now as you can see from my > work-in-progress patch, but I'm still working through a long list of little > things I've noticed that need cleaning up. I'm not sure that the backend will > build with the changes in their current state so I haven't committed them yet, > but I expect to be able to do so by the end of the week. Thanks for your > patience! As said the most important part is to have user-facing things like config/powerpcspe/*.opt pruned from irrelevant stuff as well as a general update for user-facing documentation. Documentation updates could be as simple as duplicating any rs6000 specific documentation and pruning the duplicate from irrelevant parts. This may need re-surrecting removed doc parts (if there were any) and/or pruning SPE parts from rs6000 specific documentation sections. Esp. install.texi and invoke.texi should be audited in that respect. Whether you manage to prune all unreachable code-paths from the implementation is not so important for the GCC 8 release.
I have committed a patch to the .opt files: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00114.html I have also submitted a patch to the documentation: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00115.html
I have committed another small patch to the .opt files: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00247.html and updated my docs patch per Joseph's feedback: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00248.html
Any further progress? E.g. when you've taken away all the -mcpu= options but 2, why not take away all the powerpcspe-cpus.def entries but the two, masks for other CPUs, etc. Do those CPUs support Altivec or VSX? If not, then perhaps all of altivec.md and vsx.md can go too, the intrinsic headers, etc. etc.
Similarly, config.gcc has: powerpc*-*-*spe*) cpu_type=powerpcspe extra_headers="ppc-asm.h altivec.h spe.h ppu_intrinsics.h paired.h spu2vmx.h vec_types.h si2vmx.h htmintrin.h htmxlintrin.h" case x$with_cpu in xpowerpc64|xdefault64|x6[23]0|x970|xG5|xpower[3456789]|xpower6x|xrs64a|xcell|xa2|xe500mc64|xe5500|xe6500) cpu_is_64bit=yes ;; esac extra_options="${extra_options} g.opt fused-madd.opt powerpcspe/powerpcspe-tables.opt" ;; Aren't the CPUs 32-bit only? So get rid of the above cpu_is_64bit related stuff, and replace TARGET_64BIT with 0, simplify all code. The later: powerpc*-*-* | rs6000-*-*) guarded default CPU selection allows one to configure for many CPUs powerpcspe doesn't support, so guess you need to add a powerpc*-*-*spe) entry before that and only allow there the CPUs that it supports; drop the _32 and _64 suffixed variants if it is 32-bit only.
Andrew, a friendly ping on this. The #c13 patch looks like a good progress, what happened to it?
I'm still actively working on it. The patch is close to ready for commit now, I think - I'm going to try to get it committed by the end of the week.
Another gentle ping. As has been mentioned, powerpcspe also lacks gcc-8/changes.html entry.
We aim to do GCC 8 rc1 in the middle of next week, I'm afraid if powerpcspe is still in this sorry state by then, then it is better to remove it and re-add when/if it is in better shape. Or at least declare it deprecated, to be removed in next release.
Sorry for my lack of communication on this. Realistically, it doesn't look like I'm going to be able to get the powerpcspe port to the appropriate state by the GCC 8 rc1, so please feel free to deprecate or remove as you see fit. I will continue to work on it with the aim of re-adding it in stage 1. Thanks.
Author: jakub Date: Wed Apr 18 08:47:26 2018 New Revision: 259461 URL: https://gcc.gnu.org/viewcvs?rev=259461&root=gcc&view=rev Log: PR target/81084 * config.gcc: Obsolete powerpc*-*-*spe*. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc
Port is now obsolete, will be removed in GCC9 unless sufficient maintenance is provided.
> Port is now obsolete, will be removed in GCC9 unless sufficient maintenance is provided. So, instead fixing bugs upstream projects just now tell users to go away?
Just built two weeks ago, natively: root@atlantis:~> gcc-8 -v Using built-in specs. COLLECT_GCC=gcc-8 COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc-linux-gnuspe/8/lto-wrapper Target: powerpc-linux-gnuspe Configured with: ../src/configure -v --with-pkgversion='Debian 8-20180402-1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=powerpc-linux-gnuspe- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libsanitizer --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --disable-libphobos --enable-objc-gc=auto --enable-secureplt --disable-multilib --enable-multiarch --with-cpu=8548 --enable-e500_double --disable-werror --with-long-double-128 --enable-checking=release --build=powerpc-linux-gnuspe --host=powerpc-linux-gnuspe --target=powerpc-linux-gnuspe Thread model: posix gcc version 8.0.1 20180402 (experimental) [trunk revision 259004] (Debian 8-20180402-1) root@atlantis:~> Full build log: https://buildd.debian.org/status/fetch.php?pkg=gcc-8&arch=powerpcspe&ver=8-20180402-1&stamp=1522856967&raw=0
The port is not actively maintained and contains estimated 75%-80% of dead code. The rs6000 backend had since the split around 290 commits that didn't touch the powerpcspe backend, if we just assume that only 20% of those are relevant to powerpcspe too (hard to judge exactly because the dead code from there isn't removed), then that is still significant number of known issues in the port. The announcement of the intent to obsolete the port has been posted already more than a year ago, if you look in the comments in this PR, you'll see numerous pings, despite which no (significant) action has been taken. GCC backends need active maintainance, including regular testing, reporting regressions and fixing those, otherwise they are only significant burden to other maintainers and not really useful to users.
(In reply to Jakub Jelinek from comment #29) > The rs6000 backend had since the split around 290 commits that didn't touch > the powerpcspe backend, if we just assume that only 20% of those are > relevant to powerpcspe too (hard to judge exactly because the dead code from > there isn't removed), then that is still significant number of known issues > in the port. It works fine for Debian. gcc-8 is able to build itself on powerpcspe with no apparent issues. I can also run the testsuite if necessary. We currently have turned it off to save build time as we currently have only three powerpcspe build machines. But we will add two more in the near future and then we can also enable running testsuites. > The announcement of the intent to obsolete the port has been posted already > more than a year ago, if you look in the comments in this PR, you'll see > numerous pings, despite which no (significant) action has been taken. Well, not everyone can be on every list, so it's easy to miss such announcements. There are many projects like OpenJDK, binutils, glibc, the kernel and such which want upstream attention, so you have to agree it's a bit difficult to be always everywhere to be able to answer questions. I was just pointed at your deprecation mail on IRC. In any case, Debian is probably the largest downstream user that has such a huge variety of ports. We are building always the latest versions of gcc natively on more than 20 architectures: > https://buildd.debian.org/status/package.php?p=gcc-8&suite=sid Matthias Klose is constantly uploading new versions and we always make sure gcc builds fine on all targets - natively. We also have a gcc-snapshot package that is constantly updated to the latest SVN version and built natively as well: > https://buildd.debian.org/status/package.php?p=gcc-snapshot&suite=sid We have users who are using Debian on these targets, even on m68k because retro computing is very popular around that CPU. So, I think it would be fair if important upstream projects like gcc could send a message to downstream projects like Debian in such cases, to give at least users of certain ports a notice if there are any concerns upstream. > GCC backends need active maintainance, including regular testing, reporting > regressions and fixing those, otherwise they are only significant burden to > other maintainers and not really useful to users. I am aware of that. But the thing is, the backend in question works fine at the moment. I would agree with your stance if we were seeing any serious issues with it. But that's currently not the case, so I don't understand this particular action. Is there anything specific bug that blocks things at the moment that we are missing downstream?
(In reply to John Paul Adrian Glaubitz from comment #30) > > The announcement of the intent to obsolete the port has been posted already > > more than a year ago, if you look in the comments in this PR, you'll see > > numerous pings, despite which no (significant) action has been taken. > > Well, not everyone can be on every list, so it's easy to miss such > announcements. It would have been announced in gcc-7/changes.html (linked from the announcement on gcc-announce@, I do hope you read that?), but instead of obsoleting SPE support in the rs6000 port we split off the powerpcspe port, which was promised to be maintained. Now that that does not seem to be happening, it will be obsoleted anyway. Someone needs to do the work. > We have users who are using Debian on these targets, even on m68k because > retro computing is very popular around that CPU. m68k needs some serious work, too, in the not far future (if the cc0 removal finally goes through -- that has been over ten years now). > So, I think it would be fair if important upstream projects like gcc could > send a message to downstream projects like Debian in such cases, to give at > least users of certain ports a notice if there are any concerns upstream. Read gcc-announce@. It's what it is for. Only a few posts per year :-) > > GCC backends need active maintainance, including regular testing, reporting > > regressions and fixing those, otherwise they are only significant burden to > > other maintainers and not really useful to users. > > I am aware of that. But the thing is, the backend in question works fine at > the moment. I would agree with your stance if we were seeing any serious > issues with it. But that's currently not the case, so I don't understand > this particular action. > > Is there anything specific bug that blocks things at the moment that we are > missing downstream? A port does not need maintenance only for that port, and its users, but also for GCC itself. All ports are a cost to _all_ GCC developers. If a port is not maintained it has to be removed. Segher
(In reply to Segher Boessenkool from comment #31) > It would have been announced in gcc-7/changes.html (linked from the > announcement on gcc-announce@, I do hope you read that?), but instead of > obsoleting SPE support in the rs6000 port we split off the powerpcspe port, > which was promised to be maintained. Now that that does not seem to be > happening, it will be obsoleted anyway. Andrew said he is still working on it. That is not the same as saying the promise is not going to be kept. gcc isn't a trivial project after all and that work can take some time. > Someone needs to do the work. Sure. I understand that and I am not denying that. But I don't see that this particular port is broken as it is claimed here. Otherwise it wouldn't work for Debian at all, would it? > > We have users who are using Debian on these targets, even on m68k because > > retro computing is very popular around that CPU. > > m68k needs some serious work, too, in the not far future (if the cc0 removal > finally goes through -- that has been over ten years now). Yes, I am aware of that. But there are enough people interested in such work so I think we will be able get around doing that at some point. > > So, I think it would be fair if important upstream projects like gcc could > > send a message to downstream projects like Debian in such cases, to give at > > least users of certain ports a notice if there are any concerns upstream. > > Read gcc-announce@. It's what it is for. Only a few posts per year :-) Ok, I will be subscribing to that one. > > > GCC backends need active maintainance, including regular testing, reporting > > > regressions and fixing those, otherwise they are only significant burden to > > > other maintainers and not really useful to users. > > > > I am aware of that. But the thing is, the backend in question works fine at > > the moment. I would agree with your stance if we were seeing any serious > > issues with it. But that's currently not the case, so I don't understand > > this particular action. > > > > Is there anything specific bug that blocks things at the moment that we are > > missing downstream? > > A port does not need maintenance only for that port, and its users, but also > for GCC itself. All ports are a cost to _all_ GCC developers. If a port is > not maintained it has to be removed. So, again my question is: What exactly is the with the powerpcspe target at the moment and why does upstream claim the port is broken when it apparently works for us in Debian? Am I missing something? I understand where you are coming from and I know that maintenance needs manpower. However, gcc isn't just any project, it's probably the core project besides the kernel. If you remove a target in gcc, you are killing that target for everyone and that is a problem for its users. And probably the biggest advantage of gcc over LLVM is the plethora of targets it supports. If you are going to ax most of it so that only the targets of commercial relevance would survive - i.e. x86, ARM, s390 and POWER8+ - you will be loosing one of the biggest selling points of gcc.
(In reply to John Paul Adrian Glaubitz from comment #32) > Andrew said he is still working on it. That is not the same as saying the > promise is not going to be kept. gcc isn't a trivial project after all and > that work can take some time. Yes, but the port split was done in May last year, and nothing substantial happened since then. Port maintainance is not about promises, but about doing the work. If he does the work soon, the port can be de-obsoleted in GCC9, otherwise it will be removed, which doesn't mean it can't be added at some point later. Of course, the later it will be done, the harder it will be. > > m68k needs some serious work, too, in the not far future (if the cc0 removal > > finally goes through -- that has been over ten years now). > > Yes, I am aware of that. But there are enough people interested in such work > so I think we will be able get around doing that at some point. Nobody did the work in the last 15+ years for m68k, it doesn't seem likely that all of sudden it will happen. There have been numerous posts about what to do to get rid of cc0, e.g. in 2005 and several other years. See https://gcc.gnu.org/backends.html for details, a healthy port doesn't have c (cc0), p (not using define_peephole2), has a (uses LRA). We can't maintain old reload, or cc0 support indefinitely. > > A port does not need maintenance only for that port, and its users, but also > > for GCC itself. All ports are a cost to _all_ GCC developers. If a port is > > not maintained it has to be removed. > > So, again my question is: What exactly is the with the powerpcspe target at > the moment and why does upstream claim the port is broken when it apparently > works for us in Debian? Am I missing something? Have you read all the threads mentioned in https://gcc.gnu.org/ml/gcc/2018-04/msg00102.html and all the above comments? All the details are in there.
In an unfortunate event of actually removing the port during the next stage 1, is it possible to keep related PRs open for another release cycle? This way Andrew working on bringing the port back would have an idea of what user-visible issues it had besides the needed cleanup and ordinary testsuite failures.
> A port does not need maintenance only for that port, and its users, but also > for GCC itself. All ports are a cost to _all_ GCC developers. If a port is > not maintained it has to be removed. Do you IBM guys have a hidden agenda to bury the left-overs of Freescale? ;-) The SPE port has already been moved out of the way so I don't really see the point in further hammering it like that; there are plenty of obsolete ports in the tree that would have to removed before this one if the above criterion was followed to the letter.
(In reply to Jakub Jelinek from comment #33) > Yes, but the port split was done in May last year, and nothing substantial > happened since then. Port maintainance is not about promises, but about > doing the work. If he does the work soon, the port can be de-obsoleted in > GCC9, otherwise it will be removed, which doesn't mean it can't be added at > some point later. Of course, the later it will be done, the harder it will > be. He is working on it and people are using it. It's not surprising that it takes longer than any work done by paid developers on the x86 or POWER targets. > > > m68k needs some serious work, too, in the not far future (if the cc0 removal > > > finally goes through -- that has been over ten years now). > > > > Yes, I am aware of that. But there are enough people interested in such work > > so I think we will be able get around doing that at some point. > > Nobody did the work in the last 15+ years for m68k, it doesn't seem likely > that all of sudden it will happen. There have been numerous posts about > what to do to get rid of cc0, e.g. in 2005 and several other years. > See https://gcc.gnu.org/backends.html for details, a healthy port doesn't > have > c (cc0), p (not using define_peephole2), has a (uses LRA). We can't > maintain old reload, or cc0 support indefinitely. I have been doing some research yesterday myself and couldn't find a page which documents on how to write a port. I couldn't even find documentation on the cc0 stuff. > > > A port does not need maintenance only for that port, and its users, but also > > > for GCC itself. All ports are a cost to _all_ GCC developers. If a port is > > > not maintained it has to be removed. > > > > So, again my question is: What exactly is the with the powerpcspe target at > > the moment and why does upstream claim the port is broken when it apparently > > works for us in Debian? Am I missing something? > > Have you read all the threads mentioned in > https://gcc.gnu.org/ml/gcc/2018-04/msg00102.html > and all the above comments? All the details are in there. Could you please just mention issue in question that causes trouble? The messages directly linked only mention PR81084 but I haven't run into this issue myself. Again, could you please mention an urgent issue with the powerpcspe target that causes serious issues for other users or developers? Thanks!
Not sure about IBM, I as a GCC developer and RM have major problem with the amount of dead code in the port, because anyone who makes changes to the middle-end that need backend changes will waste time adjusting code that is dead and can't be really tested (all the Altivec/VMX code, all the 64-bit support in there, all the power6/7/8/9, all the floating point modes stuff, etc.). Furthermore the lack of -mno-lra removal in it. If somebody is willing to change all backends rather than waiting on target maintainers to fix stuff up, at least the work should not be wasted on dead code. Just look e.g. how many times in the last year Richard Sandiford modified this dead code in config/powerpcspe. That is pretty much all wasted effort (others too).
(In reply to Eric Botcazou from comment #35) > Do you IBM guys have a hidden agenda to bury the left-overs of Freescale? ;-) I thought Jakub works for RedHat? > The SPE port has already been moved out of the way so I don't really see the > point in further hammering it like that; there are plenty of obsolete ports > in the tree that would have to removed before this one if the above > criterion was followed to the letter. To be honest: I made this experience already in multiple projects. IBM employees have been quite unfriendly towards PPC targets which were not POWER8 or newer. The answer was usually "Anything lower than POWER8 is no longer supported." talking as if the project in question belongs to IBM. Quite frustrating.
(In reply to Jakub Jelinek from comment #37) > Not sure about IBM, I as a GCC developer and RM have major problem with the > amount of dead code in the port, because anyone who makes changes to the > middle-end that need backend changes will waste time adjusting code that is > dead and can't be really tested (all the Altivec/VMX code, all the 64-bit > support in there, all the power6/7/8/9, all the floating point modes stuff, > etc.). It's not a waste of time if people are actually still using the code which is the case for both PowerPCSPE and m68k. I don't understand why some people think it's acceptable to kill open source stuff that is actively being used by others. > Furthermore the lack of -mno-lra removal in it. If somebody is > willing to change all backends rather than waiting on target maintainers to > fix stuff up, at least the work should not be wasted on dead code. Just > look e.g. how many times in the last year Richard Sandiford modified this > dead code in config/powerpcspe. That is pretty much all wasted effort > (others too). I think your problem lies in the fact that you are solely seeing this from the gcc maintainers perspective (which I cannot blame you for and which is not surprising). However, you have to keep in mind that - in the end - gcc is a product that people are using for productive work. So, there has to be a balance between the objective quality of the code and the usefulness of the project. If I understand Eric correctly, the PowerPCSPE backend has been split off from the other PPC code so as long as the code works and people are using it (and with someone even working on updating it), why the hurry to remove it?
Is there documentation like this for gcc? > https://llvm.org/docs/WritingAnLLVMBackend.html Would be very useful for people wanting to help with the old backends.
SPE mostly is a separate architecture that happens to share many of the basic mnemonics with PowerPC. Maintaining the SPE port was a burden to the Power/PowerPC maintainers. As discussed in the other threads, despite years of promises, the SPE port was not maintained, not even regular testsuite results. The communication mostly consisted of bug reports raised a year after the patch or release. In regard to IBM employee response to PowerPC targets older than Power8, you said yourself that these are IBM employees. They are directed to work on specific projects and patches. Sometimes IBM developers can become too focused on the Power8 and later issue and include portability in their design, but IBM also is not a general support center for all PowerPC. IBM is a business. As with all commercially-supported Open Source projects and all forms of work in general, some developers have broader interest in the project and others approach it as a job.
See e.g. https://gcc.gnu.org/onlinedocs/gccint/ https://gcc.gnu.org/onlinedocs/gccint/#toc-RTL-Representation https://gcc.gnu.org/onlinedocs/gccint/Machine-Desc.html#Machine-Desc https://kristerw.blogspot.cz/2017/08/writing-gcc-backend_4.html and many others. Don't really know how is writing a new backend relevant to maintaining an existing one.
On Thu, 19 Apr 2018, glaubitz at physik dot fu-berlin.de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 > > --- Comment #40 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> --- > Is there documentation like this for gcc? > > > https://llvm.org/docs/WritingAnLLVMBackend.html > > Would be very useful for people wanting to help with the old backends. The wiki has some material, a quick search finds https://gcc.gnu.org/wiki/WritingANewBackEnd not sure how useful or up-to-date it is.
(In reply to David Edelsohn from comment #41) > SPE mostly is a separate architecture that happens to share many of the > basic mnemonics with PowerPC. Maintaining the SPE port was a burden to the > Power/PowerPC maintainers. As discussed in the other threads, despite years > of promises, the SPE port was not maintained, not even regular testsuite > results. The communication mostly consisted of bug reports raised a year > after the patch or release. Those are apparent mistakes made in the past. I am happy to provide testsuite results starting next week. As I said, gcc-8 is stable at the moment on real PowerPCSPE hardware. > In regard to IBM employee response to PowerPC targets older than Power8, you > said yourself that these are IBM employees. They are directed to work on > specific projects and patches. Sometimes IBM developers can become too > focused on the Power8 and later issue and include portability in their > design, but IBM also is not a general support center for all PowerPC. IBM is > a business. As with all commercially-supported Open Source projects and all > forms of work in general, some developers have broader interest in the > project and others approach it as a job. I understand how that works. No one is actually asking IBM people to fix anything if they don't want to. But I have a problem with people removing working code that people are using and then dismissing it with answers like the one I received. It would be different if project X belongs to IBM. One of such examples was that POWER5 support was forcefully removed by IBM people from Golang. They claimed that this move was urgently necessary to reduce maintenance burden. Yet all that was needed to get Golang working again on POWER5 was to revert three patches and slightly modify them. I am still rebasing it regularly without any problems.
(In reply to Jakub Jelinek from comment #42) > See e.g. https://gcc.gnu.org/onlinedocs/gccint/ > https://gcc.gnu.org/onlinedocs/gccint/#toc-RTL-Representation > https://gcc.gnu.org/onlinedocs/gccint/Machine-Desc.html#Machine-Desc > https://kristerw.blogspot.cz/2017/08/writing-gcc-backend_4.html > and many others. Thank you. > Don't really know how is writing a new backend relevant to > maintaining an existing one. Well, I guess there is no documentation "How to fix an unmaintained target and bring it back into shape.", is there? Documenation which explains how to write a backend should also help fixing an existing one.
I understand the issues with Golang and have been raising the issue internally.
(In reply to Eric Botcazou from comment #35) > > A port does not need maintenance only for that port, and its users, but also > > for GCC itself. All ports are a cost to _all_ GCC developers. If a port is > > not maintained it has to be removed. > > Do you IBM guys have a hidden agenda to bury the left-overs of Freescale? ;-) > > The SPE port has already been moved out of the way so I don't really see the > point in further hammering it like that; there are plenty of obsolete ports > in the tree that would have to removed before this one if the above > criterion was followed to the letter. This is not about IBM. Believe it or not, but the rs6000 port maintainers *care* about older systems. I wanted to obsolete SPE support because it is a big burden, not in small part because no one maintains it. This has been going on for years and years. Big pushback; people still want SPE, they just don't want to spend work on it. Well neither do we, it's been enough. So I spent a week splitting off the port (also tested removing VSX etc.; removing unused code does not take that long; I just have no way to *test* it so that was not included). It was agreed the powerpcspe port would be maintained or it would be removed. Now a year later GCC 8 is on the horizon, and the powerpcspe port is still not maintained. And the RMs decided to give it *another* year: it is not removed but merely obsoleted.
(In reply to Segher Boessenkool from comment #47) > Believe it or not, but the rs6000 port maintainers *care* about older > systems. Then why is something that is still working and being used by people being deprecated? > I wanted to obsolete SPE support because it is a big burden, not in small > part > because no one maintains it. This has been going on for years and years. In what sense? Care to elaborate? I thought the codebase has already been separated out so it doesn't bother the rest of the code base. As mentioned above, it would be nice to be pointed to an actual problem the code is causing right now as-is. > Big pushback; people still want SPE, they just don't want to spend work on > it. So, does every gcc user also have to be a gcc developer? I think the number of people using gcc is magnitudes larger than the people capable of working on the gcc codebase. So I think this argument is a bit unfair. > Well neither do we, it's been enough. So I spent a week splitting off the > port > (also tested removing VSX etc.; removing unused code does not take that long; > I just have no way to *test* it so that was not included). It was agreed the > powerpcspe port would be maintained or it would be removed. Ignoring that there are people still using it. > Now a year later GCC 8 is on the horizon, and the powerpcspe port is still > not > maintained. And the RMs decided to give it *another* year: it is not removed > but merely obsoleted. Why not leave it in as long as it works and it's being used? Mark it as unsupported, broken or wontfix, but please don't remove it.
Hi Andrew! (In reply to Andrew Jenner from comment #21) > I'm still actively working on it. The patch is close to ready for commit > now, I think - I'm going to try to get it committed by the end of the week. Is there any progress on this? Is there anything we (Debian) can do to help you? Do you need access to a porterbox or do you need your own powerpcspe hardware for testing? It might be possible to arrange that, I know people who could supply such hardware. Debian got its PowerPC e500v2 boards through donations as well.
Created attachment 44056 [details] Patch in progress as of 2018/05/03 Hi John, Thanks for the offer of help. I already have hardware, but I need to get my test scripts in order. I'm attaching my current patch. If you could get some test results with and without this patch to make sure it doesn't break anything, that would be a tremendous help. Unfortunately I've been side-tracked onto other projects and haven't been able to give this the attention it deserves, but I hope to get back to it in the next couple of weeks. Thanks again!
(In reply to Andrew Jenner from comment #50), > > Thanks for the offer of help. I already have hardware, but I need to get my > test scripts in order. Ok, great! > I'm attaching my current patch. If you could get some > test results with and without this patch to make sure it doesn't break > anything, that would be a tremendous help. Absolutely. Where should I test the patch? Natively on powerpcspe? On x86_64? Or anything else? We have a wide range of architectures available for testing. > Unfortunately I've been > side-tracked onto other projects and haven't been able to give this the > attention it deserves, but I hope to get back to it in the next couple of > weeks. Thanks again! No worries. Your efforts are highly appreciated and I'm happy to help whereever I can.
(In reply to John Paul Adrian Glaubitz from comment #51) > Absolutely. Where should I test the patch? Natively on powerpcspe? On > x86_64? Or anything else? We have a wide range of architectures available > for testing. The patch only changes the powerpcspe backend - there's no need to test it against any other targets.
(In reply to Andrew Jenner from comment #52) > (In reply to John Paul Adrian Glaubitz from comment #51) > > Absolutely. Where should I test the patch? Natively on powerpcspe? On > > x86_64? Or anything else? We have a wide range of architectures available > > for testing. > > The patch only changes the powerpcspe backend - there's no need to test it > against any other targets. Ok. I will try a native build then.
Just tried a native build with gcc from trunk plus the patch, fails due to an apparent syntax error: powerpc-linux-gnuspe-g++ -std=gnu++98 -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -no-pie -o build/genmatch \ build/genmatch.o ../../build-powerpc-linux-gnuspe/libcpp/libcpp.a build/errors.o build/vec.o build/hash-table.o ../../build-powerpc-linux-gnuspe/libiberty/libiberty.a build/genmddeps ../.././gcc/common.md ../.././gcc/config/powerpcspe/powerpcspe.md > tmp-mddeps ../.././gcc/config/powerpcspe/powerpcspe.md:4362:1: unterminated construct make[3]: *** [Makefile:2306: s-mddeps] Error 1 make[3]: *** Waiting for unfinished jobs.... rm fsf-funding.pod gcov.pod gpl.pod cpp.pod gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod make[3]: Leaving directory '/srv/glaubitz/gcc/host-powerpc-linux-gnuspe/gcc' make[2]: *** [Makefile:4624: all-stage1-gcc] Error 2 make[2]: Leaving directory '/srv/glaubitz/gcc' make[1]: *** [Makefile:23666: stage1-bubble] Error 2 make[1]: Leaving directory '/srv/glaubitz/gcc' make: *** [Makefile:953: all] Error 2 Configured with ./configure --build=powerpc-linux-gnuspe --host=powerpc-linux-gnuspe --target=powerpc-linux-gnuspe --enable-obsolete --with-cpu=8548 --enable-e500_double --with-long-double-128 --disable-libphobos
This seems to help: diff --git a/gcc/config/powerpcspe/powerpcspe.md b/gcc/config/powerpcspe/powerpcspe.md index 746f2bd1ee3..2e08bcea2b5 100644 --- a/gcc/config/powerpcspe/powerpcspe.md +++ b/gcc/config/powerpcspe/powerpcspe.md @@ -4367,7 +4367,7 @@ "#" [(set_attr "type" "store,store,load,load,*,*") (set_attr "update" "yes") - (set_attr "indexed" "yes")] + (set_attr "indexed" "yes")]) (define_split [(set (match_operand:TI2 0 "nonimmediate_operand" "") @@ -4671,7 +4671,7 @@ (clobber (reg:SI LR_REGNO))])] "" [(set_attr "type" "two") - (set (attr "length") (const_int 16))] + (set (attr "length") (const_int 16))]) (define_insn_and_split "tls_gd_sysv<TLSmode:tls_sysv_suffix>" [(set (match_operand:TLSmode 0 "gpc_reg_operand" "=b")
Another issue: In file included from ../.././gcc/config/powerpcspe/powerpcspe.h:1865:0, from ./tm.h:25, from ../.././gcc/genopinit.c:24: ../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:14: error: expected ‘}’ before ‘(’ token BU_P7_MISC_2 (DIVWE, "divwe", CONST, dive_si) ^ ../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:20: error: expected ‘)’ before ‘,’ token BU_P7_MISC_2 (DIVWE, "divwe", CONST, dive_si) ^ ../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:23: error: expected unqualified-id before string constant BU_P7_MISC_2 (DIVWE, "divwe", CONST, dive_si) ^~~~~~~ In file included from ./tm.h:25:0, from ../.././gcc/genopinit.c:24: ../.././gcc/config/powerpcspe/powerpcspe.h:1868:1: error: expected declaration before ‘}’ token }; ^ In file included from ../.././gcc/config/powerpcspe/powerpcspe.h:1865:0, from ./tm.h:25, from ../.././gcc/genattrtab.c:108: ../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:14: error: expected ‘}’ before ‘(’ token BU_P7_MISC_2 (DIVWE, "divwe", CONST, dive_si) ^ ../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:20: error: expected ‘)’ before ‘,’ token BU_P7_MISC_2 (DIVWE, "divwe", CONST, dive_si) ^ ../.././gcc/config/powerpcspe/powerpcspe-builtin.def:212:23: error: expected unqualified-id before string constant BU_P7_MISC_2 (DIVWE, "divwe", CONST, dive_si) ^~~~~~~ In file included from ./tm.h:25:0, from ../.././gcc/genattrtab.c:108: ../.././gcc/config/powerpcspe/powerpcspe.h:1868:1: error: expected declaration before ‘}’ token }; ^ Here I haven't figured out yet where the syntax error is. Either in gcc/config/powerpcspe/powerpcspe.h or gcc/config/powerpcspe/powerpcspe-builtin.def. What I noticed that gcc/config/powerpcspe/powerpcspe-builtin.def has some stray control sequences "^L" around line 212. Removing them did not change anything though.
Andrew, could you refresh your patch for the current trunk branch? It doesn't fully apply for me.
(In reply to John Paul Adrian Glaubitz from comment #57) > Andrew, could you refresh your patch for the current trunk branch? > > It doesn't fully apply for me. Acknowledged. I will try to get to that later this week.
(In reply to Andrew Jenner from comment #58) > Acknowledged. I will try to get to that later this week. Any news on this? News from Debian's side is that we have upgraded build capacity for powerpcspe now with two additional e500v2 machines hosted by Turris in Czech Republic (the guys who make those open source routers).
Ping?
Sorry, once again I have been totally swamped by other work. It's now looking like I should have some time to work on this in early July.
(In reply to Andrew Jenner from comment #61) > Sorry, once again I have been totally swamped by other work. It's now > looking like I should have some time to work on this in early July. Ok, great. Let me know once you have an updated patch which can be tested. FWIW, the current PowerPCSPE backend seems to have issues with the memory management. At least we're observing gcc getting killed by the kernel's OOM killer even on machines with 8 GiB RAM and enough swap.
Just wanted to ask whether there is an updated patch available for testing?
FYI, I am setting up a PowerPCSPE porterbox the next days and hope to get it added to the gcc compile farm as a test machine. So any patches can be tested there.