Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe
Hi! On 5/9/20 12:15 AM, Segher Boessenkool wrote: > I can do both, if you want, or just the first group? Your choice. > > But let's hear other opinions first. These bugs document the current issues with the backend as it existed in gcc-8 (or was it -9)? The bugs are still in the removed code, so I don't really understand what you gain by closing bugs? Is it important to keep the number of open issues low? I don't consider bug reports a bad thing, they document the code quality and are a useful resource to anyone working on the code or using these versions. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe
On 5/9/20 10:31 AM, Jonathan Wakely wrote: > If you mean for PR reasons or good apeparances, no. But it's wrong to > have bugs left open that only refer to unsupported versions of GCC. If > none of the supported releases has the bug (either because it's been > fixed, or the relevant code has been removed) then the bug should be > closed. > > If the bug is still present in supported versions (like gcc-8 or > gcc-9) but will never be fixed (like SPE ones) they might as well be > closed now as WONTFIX. Suggesting anything else will happen to them is > misleading. If you don't accept my opinion, why did you ask for it in the first place. Please do whatever you want. I will still continue to contribute to GCC and start BountySource campaigns to support, despite my opinion not being of any relevance. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe
On 5/9/20 12:31 PM, Arseny Solokha wrote: > I'd also like to nominate the following two: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158 > > which I also cannot close myself. There won't be any further revisions of this > list by me. They affect given older versions, so if you just close them, that would imply that the bug in question in gcc-4.5.3 has been dealt with - which I assume is not the case. So, again, I'm not sure what you gain by closing these bugs. Having them marked as open means that someone has observed the issue with a certain gcc version and target. Moving it to "closed" just expresses that some people don't care about this bug anymore. But it doesn't change the fact that the bug still exists. The only thing you gain by closing such bugs is that you are reducing the number of open bug reports and you can somehow claim you fixed a bug. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: AVR CC0 transition
Hello! > I'm thinking about attempting to do the CC0 transition for the > AVR port in my spare time. I've read the CC0Transition gcc wiki > page, and as the AVR ISA does not have non-condition-code > clobbering arithmetic instructions, concluded that I'd have to > follow the steps outlined for case #2. If you are working on it, it might be a good idea to log in to Bountysource.com and mark the issue as being worked on [1], so you can get the bounty in case the conversion has been successful. Adrian > [1] > https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: AVR CC0 transition
Hi! On 5/25/20 2:56 PM, John Paul Adrian Glaubitz wrote: >> I'm thinking about attempting to do the CC0 transition for the >> AVR port in my spare time. I've read the CC0Transition gcc wiki >> page, and as the AVR ISA does not have non-condition-code >> clobbering arithmetic instructions, concluded that I'd have to >> follow the steps outlined for case #2. > > If you are working on it, it might be a good idea to log in to > Bountysource.com > and mark the issue as being worked on [1], so you can get the bounty in case > the conversion has been successful. Important update: Bountysource has announced that they will let bounties expire in the future if not claimed after two years [1]. So, unless someone claims the money with the next two years, the money will be gone. It would therefore be good for anyone working on the AVR MODE_CC conversion (Senthil?) that they submit a claim for this bounty [2] after the patches to convert the AVR backend have been accepted upstream. It would be a shame if the money would be taken by Bountysource in the end. If the developer who submits the claim, cannot take the money for legal reasons (i.e. because worked on it during company time), I would suggest donating the money to a good cause. The same applies to the campaign for the VAX backend [3]. Adrian > [1] https://news.ycombinator.com/item?id=23551098 > [2] > https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases > [3] > https://www.bountysource.com/issues/91495157-vax-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bountysource campaign for AVR backend now at $7,150
Hello! I just got a notification that the Bountysource campaign I created to modernize the AVR backend - primarily converting it to MODE_CC - has been bumped to $7,150 by Microchip [1]. I hope this will finally convince someone to complete the task :-). Adrian > [1] > https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Registers used for exception handling on Linux/m68k?
Hello! I'm looking for an information regarding exception handling on Linux/m68k, in particular I need to know what registers are used by the ABI in order to implement the functions "getExceptionPointerRegister" and "getExceptionSelectorRegister" in the M680x0 backend in LLVM [1], [2]. I looked into the GCC source code to find the corresponding parts but I could only find the macros prefixed with "EH_" [4] which I didn't fully understand. Can any of the experienced GCC/m68k folks tell me which registers in [5] I need to use? Adrian > [1] https://github.com/M680x0/M680x0-mono-repo/issues/15 > [2] > https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/Sparc/SparcISelLowering.h#L107 > [3] > https://github.com/llvm/llvm-project/blob/ee34d9b210cb5a6d14fe069e2e2ae75b0548dba9/llvm/lib/Target/Sparc/SparcRegisterInfo.td#L151 > [4] https://github.com/gcc-mirror/gcc/blob/master/gcc/config/m68k/m68k.h#L741 > [5] > https://github.com/M680x0/M680x0-mono-repo/blob/master/llvm/lib/Target/M680x0/M680x0RegisterInfo.td -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Fwd: Re: Registers used for exception handling on Linux/m68k?
Hi Nathan! On 9/29/20 7:58 PM, Nathan Sidwell wrote: > On 9/29/20 11:22 AM, John Paul Adrian Glaubitz wrote: >> >> I'm looking for an information regarding exception handling on Linux/m68k, >> in particular >> I need to know what registers are used by the ABI in order to implement the >> functions >> "getExceptionPointerRegister" and "getExceptionSelectorRegister" in the >> M680x0 backend >> in LLVM [1], [2]. > > I don;t know what those functions are, but from their names they seem to be > related to figuring out the exception object and type? I think so. I'm not a compiler expert hence my questions :-). > Do you understand the itanium ABI's unwinding mechanism -- > 1) follow stack to get to landing pad. > 2) invoke landing pad to see if it wants to catch > 3) if not, continue following stack > 4) once we've found one to catch it, we need to unwind properly, which > involves invoking cleanups. and eventually getting to the catcher > > invoking the landing pad means passing (a) an integer telling it what's > happening, and (b) a pointer to data. This seems to be the data that I need. I just need to understand how that works. >> I looked into the GCC source code to find the corresponding parts but I >> could only find >> the macros prefixed with "EH_" [4] which I didn't fully understand. > > Those are the bits you want. one of those is the selector (0?) and the other > is the data pointer (1?). OK. But aren't they passed through particular registers on m68k? Or is this something specific to LLVM? Thanks for the help! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Fwd: Re: Registers used for exception handling on Linux/m68k?
Hi Nathan!
Thanks for the explanations!
On 10/1/20 2:27 PM, Nathan Sidwell wrote:
> do you know what those 2 functions you mention provide on say x86? Then it
> might be easier to map onto 68k.
>From [1]:
Register X86TargetLowering::getExceptionPointerRegister(
const Constant *PersonalityFn) const {
if (classifyEHPersonality(PersonalityFn) == EHPersonality::CoreCLR)
return Subtarget.isTarget64BitLP64() ? X86::RDX : X86::EDX;
return Subtarget.isTarget64BitLP64() ? X86::RAX : X86::EAX;
}
Register X86TargetLowering::getExceptionSelectorRegister(
const Constant *PersonalityFn) const {
// Funclet personalities don't use selectors (the runtime does the selection).
assert(!isFuncletEHPersonality(classifyEHPersonality(PersonalityFn)));
return Subtarget.isTarget64BitLP64() ? X86::RDX : X86::EDX;
}
Adrian
> [1]
> https://raw.githubusercontent.com/llvm/llvm-project/master/llvm/lib/Target/X86/X86ISelLowering.cpp
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Fwd: Re: Registers used for exception handling on Linux/m68k?
On 10/1/20 2:46 PM, Nathan Sidwell wrote: > Aha! it is EH_RETURN :) and it appears stack adjustment is something > different. > > for x86, gcc has: > #define EH_RETURN_DATA_REGNO(N) ((N) <= DX_REG ? (N) : INVALID_REGNUM) > > thus N can either be AX_REG or DX_REG. (which is eax/rax and edx/rdx > depending on compilation mode) > > for m68k gcc has: > #define EH_RETURN_DATA_REGNO(N) \ > ((N) < 2 ? (N) : INVALID_REGNUM) > > so that's registers d0 and d1 > > I'm guessing EHPersonality:CoreCLR is a different ABI that you're not > concerned with. Yeah, it also seems to be present in the X86 backend only (at least not in the Sparc backend). > Thus I think you want: > > getExceptionPointerRegister to return d0 and getExceptionSelectorRegister to > return d1. > > give that a go, and see if you can throw/catch exceptions between code > compiled by your llvm port and a gcc Perfect, thanks. > hope that helps. I'll give it a try. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFC: Support non-standard extension (call via casted function pointer)
Hi Richard! On 01/26/2016 08:01 AM, Richard Biener wrote: >> I developed a gcc patch that does not change the code generation for >> conforming programs but fixes this non-conforming use-case by always >> taking the actual return type in the call expression into account, even >> if the function declaration to be called is known. Please comment >> whether such a patch has any chance to be applied to either gcc >> upstream >> or gcc in Debian. > > Without looking at the patch this is already how GCC should behave for all > targets. So, would you actually favor the inclusion of Michael's changes? Having gcc allow to work with such code would actually allow us to bootstrap ghc on m68k again which would be awesome :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFC: Support non-standard extension (call via casted function pointer)
On 01/26/2016 11:07 AM, Andreas Schwab wrote: > John Paul Adrian Glaubitz writes: > >> Having gcc allow to work with such code would actually allow us >> to bootstrap ghc on m68k again which would be awesome :). > > The ghc code just needs to be fixed to not lie in such a blatant way. > Just like it was changed when ppc64le flagged this as crap code. I could just find one bug report which mentions a fix for ppc64el [1], are you talking about this one? If this bug is actually the same as the m68k bug, why is ghc still working fine on ppc64el? Does ppc64el actually have separate address and data registers? Adrian > [1] https://ghc.haskell.org/trac/ghc/ticket/8965 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFC: Support non-standard extension (call via casted function pointer)
On 01/26/2016 12:07 PM, Andreas Schwab wrote: >> If this bug is actually the same as the m68k bug, > > Where did I say that? > The ghc code just needs to be fixed to not lie in such a blatant way. > Just like it was changed when ppc64le flagged this as crap code. ^ But I don't want to argue anyway. I was assuming ppc64le might have similarities to m68k in that regard. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFC: Support non-standard extension (call via casted function pointer)
On 01/28/2016 09:55 AM, Andreas Schwab wrote: > Richard Biener writes: > >> I think that's reasonable and what GHC expects - declare "there is a function >> foo defined, no idea what prototype yet", unfortunately C requires to specify >> a return type. > > Like void, f.ex. Wait. Do you think this would actually allow ghc to determine the return type later? If I remember correctly, ghc currently initially declares the function prototype with return type void*, doesn't it? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
gcc Testsuite Results - was: Re: [PATCH] Deprecate ia64*-*-*
Hi! I just stumbled over [1] and just wanted to add that Debian is reguarly building snapshots of all current gcc versions for a large number of targets, including the testsuites (except for m68k and sh4 at the moment). The results can always be found on buildd.debian.org. gcc-7: https://buildd.debian.org/status/package.php?p=gcc-7&suite=sid gcc-8: https://buildd.debian.org/status/package.php?p=gcc-8&suite=sid gcc-9: https://buildd.debian.org/status/package.php?p=gcc-9&suite=sid gcc-snapshot: https://buildd.debian.org/status/package.php?p=gcc-snapshot&suite=sid So gcc is tested regularly on ia64 and co and it's actively being used to build the whole Debian archive. Thanks, Adrian [1] https://gcc.gnu.org/ml/gcc/2019-06/msg00158.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
BountySource campaign for gcc PR/91851
Hello! For anyone who isn't aware of it yet, there is an ongoing BountySource campaign for gcc PR/91851 [1] which seeks to convert the m68k backend to MODE_CC so that it can be kept in gcc versions beyond version 11. The campaign is currently at $3,290 and can be found at [2]. Thanks, Adrian > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851 > [2] > https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: BountySource campaign for gcc PR/91851
On 10/31/19 10:00 PM, Georg-Johann Lay wrote: >>> I didn't follow the lists for some time... At least neither v9 or v10 >>> release notes caveats mention such deprecation, neither is there >>> respective PRs for the cc0 targets. >> >> https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html >> >> Peter > > Ah, thanks. > > So finally, the time has come to move to clang/llvm ? Not quite. Motorola 68k is currently not officially supported by LLVM/Clang. There is a port that is half-finished though [1] and there is also one guy from Czech Republic who wrote a Bachelor thesis on an m68k backend for LLVM [2]. I have not been able to contact him though as his university address bounces. I would love to see the code that was written there. I have also played around with Rust on m68k based on the LLVM code on [1], but it doesn't really work yet. I think finishing LLVM for m68k would be another idea for a Bountysource campaign. Adrian > [1] https://github.com/M680x0/M680x0-llvm/ > [2] https://www.vutbr.cz/en/students/final-thesis?zp_id=34902 > [3] https://github.com/glaubitz/rust/tree/m68k-linux -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Deprecation of powerpc*-*-*spe*
Hi Jakub! As has been discussed in the https://gcc.gnu.org/ml/gcc/2017-02/msg00041.html https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01227.html https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00810.html threads and in https://gcc.gnu.org/PR81084 the powerpc*-*-*spe* support which has been split into a separate backend hasn't been given enough maintainance and so is deprecated in GCC 8. I'm surprised that these topics are hardly ever discussed with downstream projects like Debian. I am maintaining powerpcspe in Debian and the port is very stable for us. There are people running the port on embedded PowerPC e500 systems like A-EON Tabor A1222 or the powerpc-based Turris router so killing off gcc support would mean that these people can no longer run an updated version of Debian on their machines. I also don't know why the port is considered to be broken. I haven't run the testsuite for binutils or gcc recently, true, but gcc-8 works just fine on powerpcspe and is actually the only current compiler we have since the powerpcspe support in LLVM is incomplete. Here's the build log of gcc-8 (20180402) built natively on PowerPC e500 just two weeks ago: https://buildd.debian.org/status/fetch.php?pkg=gcc-8&arch=powerpcspe&ver=8-20180402-1&stamp=1522856967&raw=0 Is there anything in the powerpcspe port that is currently making life for the users or developers of other code harder? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Incorrect linker paths for building gcc on 32-bit PowerPC
ecnumber/decBasic.c: In function 'decDivide':
../../../libgcc/../libdecnumber/decBasic.c:626:7: warning: array subscript -1
is outside array bounds of 'uint8_t[47]' {aka 'unsigned char[47]'}
[-Warray-bounds]
626 | *(num.msd-1)=0; /* in case of left carry, or make 0
*/
| ^~~~
../../../libgcc/../libdecnumber/decBasic.c:184:10: note: while referencing
'bcdacc'
184 | uByte bcdacc[(DIVOPLEN+1)*9+2]; /* for quotient in BCD, +1, +1 */
| ^~
make[2]: Leaving directory
'/home/glaubitz/gccrs/build/powerpc-unknown-linux-gnu/libgcc'
make[1]: *** [Makefile:13143: all-target-libgcc] Error 2
make[1]: Leaving directory '/home/glaubitz/gccrs/build'
make: *** [Makefile:944: all] Error 2
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
