[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #64 from John Paul Adrian Glaubitz --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #63 from John Paul Adrian Glaubitz --- Just wanted to ask whether there is an updated patch available for testing?
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #62 from John Paul Adrian Glaubitz --- (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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #61 from Andrew Jenner --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #60 from John Paul Adrian Glaubitz --- Ping?
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #59 from John Paul Adrian Glaubitz --- (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).
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #58 from Andrew Jenner --- (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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #57 from John Paul Adrian Glaubitz --- Andrew, could you refresh your patch for the current trunk branch? It doesn't fully apply for me.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #56 from John Paul Adrian Glaubitz --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #55 from John Paul Adrian Glaubitz --- 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" [(set (match_operand:TLSmode 0 "gpc_reg_operand" "=b")
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #54 from John Paul Adrian Glaubitz --- 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
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #53 from John Paul Adrian Glaubitz --- (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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #52 from Andrew Jenner --- (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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #51 from John Paul Adrian Glaubitz --- (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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 Andrew Jenner changed: What|Removed |Added Attachment #43312|0 |1 is obsolete|| --- Comment #50 from Andrew Jenner --- Created attachment 44056 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44056&action=edit 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!
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #49 from John Paul Adrian Glaubitz --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #48 from John Paul Adrian Glaubitz --- (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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #47 from Segher Boessenkool --- (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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #46 from David Edelsohn --- I understand the issues with Golang and have been raising the issue internally.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #45 from John Paul Adrian Glaubitz --- (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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #44 from John Paul Adrian Glaubitz --- (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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #43 from rguenther at suse dot de --- 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 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #42 from Jakub Jelinek --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #41 from David Edelsohn --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #40 from John Paul Adrian Glaubitz --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #39 from John Paul Adrian Glaubitz --- (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?
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #38 from John Paul Adrian Glaubitz --- (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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #37 from Jakub Jelinek --- 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).
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #36 from John Paul Adrian Glaubitz --- (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!
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #35 from Eric Botcazou --- > 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #34 from Arseny Solokha --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #33 from Jakub Jelinek --- (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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #32 from John Paul Adrian Glaubitz --- (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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #31 from Segher Boessenkool --- (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
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #30 from John Paul Adrian Glaubitz --- (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?
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #29 from Jakub Jelinek --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #28 from John Paul Adrian Glaubitz --- 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
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 John Paul Adrian Glaubitz changed: What|Removed |Added CC||glaubitz at physik dot fu-berlin.d ||e --- Comment #27 from John Paul Adrian Glaubitz --- > 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?
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #26 from Jakub Jelinek --- Port is now obsolete, will be removed in GCC9 unless sufficient maintenance is provided.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #25 from Jakub Jelinek --- 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
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #24 from Andrew Jenner --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #23 from Jakub Jelinek --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #22 from Jakub Jelinek --- Another gentle ping. As has been mentioned, powerpcspe also lacks gcc-8/changes.html entry.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #21 from Andrew Jenner --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #20 from Jakub Jelinek --- Andrew, a friendly ping on this. The #c13 patch looks like a good progress, what happened to it?
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #19 from Jakub Jelinek ---
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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #18 from Jakub Jelinek --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #17 from Andrew Jenner --- 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
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #16 from Andrew Jenner --- 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
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #15 from rguenther at suse dot de --- On Wed, 31 Jan 2018, andrewjenner at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 > > Andrew Jenner 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 --- > 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 Andrew Jenner 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 --- 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!
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 Andrew Jenner 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 --- 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!
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #13 from Andrew Jenner --- Created attachment 43312 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43312&action=edit Patch in progress so far
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #12 from Andrew Jenner --- 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!
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #11 from joseph at codesourcery dot com --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #10 from Jakub Jelinek --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #9 from Andrew Jenner --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #8 from Jakub Jelinek --- Any progress here?
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #7 from rsandifo at gcc dot gnu.org --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 Richard Biener changed: What|Removed |Added Priority|P4 |P1 --- Comment #5 from Richard Biener --- 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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #4 from rguenther at suse dot de --- On December 12, 2017 12:51:35 AM GMT+01:00, law at redhat dot com wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 > >Jeffrey A. Law 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 --- >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.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 Jeffrey A. Law 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 --- Can't see how ppc-spe can be P1 :-) BUt will certainly confirm that some cleanup should happen here.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 Richard Biener changed: What|Removed |Added CC||andrewjenner at gcc dot gnu.org, ||charlet at gcc dot gnu.org --- Comment #2 from Richard Biener --- CCing Mentor / AdaCore folks who stepped up as maintainers.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #1 from Richard Biener --- port is also unmaintained (no MAINTAINERS entry)
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |8.0
