similar to: Bountysource campaign for the M68000 backend

Its awesome to see so much progress on this! A very minor question - why is it called M680x0 and not M68K given that's what the target arch/triple is and how its usually referred to? Sorry for the bikeshedding.... Simon. On 30/09/2020 21:14, Min-Yih Hsu via llvm-dev wrote: > Hi All, > > I've composed a draft roadmap for this new target. I've decided to try >

On Sun, 27 Sep 2020 at 20:27, John Paul Adrian Glaubitz via llvm-dev < llvm-dev at lists.llvm.org> wrote: > As many of these classic systems still have very active communities, > especially the Amiga community, > development efforts are still very strong. For example, despite being the > oldest port of the Linux > kernel, the m68k port has still multiple active kernel

Hi All, We would like to contribute our supports for Motorola 68000 series CPU (also known as M68k or M680x0) into LLVM. And we want to hear feedbacks from you Here is some background for M68k: Motorola 68000 series CPU was one of the most popular CPUs used by personal computers in the ‘80, including some of the earliest Apple Macintosh. Fast-forwarding to modern days, M68k is still popular

On Tue, 29 Sep 2020 at 18:53, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > So, shall we setup a server for that or is there some existing > infrastructure > from LLVM that is used in this case? > Unfortunately, we don't have a centralised infrastructure like GCC. Each target community is responsible for maintaining their own buildbots. All we

Hi All, Just a quick update on the Motorola 6800 backend: Based on the feedback, "M68k" (with lowercase "k") will now be the canonical target name and "m68k" be the target triple name. I've updated all the patches under review to reflect this change. I'm also asking for everyone's help to review all the patches. /* Target independent changes */ 1.

As well as the actual patch reviews, has there been official approval that the M68k experimental backend can be added to trunk? I guess we need a "Backend: M68k" bugzilla component - is there anything else? On 13/11/2020 22:41, John Paul Adrian Glaubitz via llvm-dev wrote: > Hello! > > On 11/3/20 6:10 PM, Min-Yih Hsu wrote: >> Just a quick update on the Motorola 6800

Hello David! On 11/16/20 11:30 AM, David Chisnall via llvm-dev wrote: > Generally, the bar for being in-tree is fairly low, the bar to being removed > from the experimental-back-ends list is much higher. An experimental back end > is not built by default and is not in any of the binary releases. > > Experimental back ends provide a probation period for the maintainer community.

I know it's really early in the project's life, but another question I had: How does the generated 68K code perform, at least compared to modern GCC? -- Chris

On Sun, Nov 15, 2020 at 1:27 PM John Paul Adrian Glaubitz via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 11/15/20 9:33 PM, Simon Pilgrim via llvm-dev wrote: > > As well as the actual patch reviews, has there been official approval that the > > M68k experimental backend can be added to trunk? I guess we need a > > "Backend: M68k" bugzilla component -

On Mon, 28 Sep 2020 at 10:37, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > So, I think in case there was a problem with the backend in LLVM, the > community > would have enough momentum to work towards solving this issue. > Great! I agree. But we will enable the target in Debian the moment it becomes > usable > and we will expose it to as much

Hello, would it be possible to update config.sub and config.guess to the latest versions (or at least version from automake-1.13.1) in order to support new architectures based on the ARM 64 bit CPU? Patch: http://plautrba.fedorapeople.org/openssh/openssh-latest-config.sub-config.guess.patch Related Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=926284 Thanks, Petr

In order to comply with the CoC, replace **** with a hug. Jarkko Sakkinen (15): MIPS: replace **** with a hug Documentation: replace **** with a hug drm/nouveau: replace **** with a hug m68k: replace **** with a hug parisc: replace **** with a hug cpufreq: replace **** with a hug ide: replace **** with a hug media: replace **** with a hug mtd: replace **** with a hug

On Mon, 28 Sep 2020 at 19:13, Min-Yih Hsu <minyihh at uci.edu> wrote: > Thanks for all your feedback, those were extremely helpful, especially the > guidelines to split the patches. I think in my case, patch 3 ~ 6 are the > most problematic, I will rework them shortly. > Perfect, thanks! And most importantly, I'll present a roadmap regarding blockers we need to > clear

Hello friends, A couple years back I’ve started a M68K codegen port of LLVM, and then suspended it for the lack of free time. Now I finally got some time and willing to continue working on it. To keep up with LLVM changes I'd like to merge it upstream. There is already patch for it: https://reviews.llvm.org/D50314 <https://reviews.llvm.org/D50314>, but then I was reminded that adding

https://bugs.freedesktop.org/show_bug.cgi?id=70135 Priority: medium Bug ID: 70135 Assignee: nouveau at lists.freedesktop.org Summary: [nv34 PowerMac G5] gnome-shell random crashes and rendering issues QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux

Hello! I would like to debug Clang but avoid having to build LLVM with debug symbols enabled due to the size of the debug build which causes problems on the target system where I want to debug due to disk constraints. Is it possible to build LLVM and Clang but enable debug symbols for Clang only? If yes, how? Adrian PS: I'm only receiving digests on this list, so please keep me CC'ed.

https://bugs.freedesktop.org/show_bug.cgi?id=52398 Bug #: 52398 Summary: nouveau: DPMS permanently turns off display when starting X.org, text console works fine Classification: Unclassified Product: xorg Version: 7.7 (2011) Platform: PowerPC OS/Version: Linux (All) Status: NEW Severity:

Hi Anton, Thanks for the tip. I’ve moved some common code from the patch: https://reviews.llvm.org/D50784 <https://reviews.llvm.org/D50784> https://reviews.llvm.org/D50856 <https://reviews.llvm.org/D50856> https://reviews.llvm.org/D50858 <https://reviews.llvm.org/D50858> but the backend itself is still quite large. Anything more I can do to simplify reviewing? > On 15 Aug

Hi! In Debian, we have recently run into the situation that the package qttools-opensource-src has added LLVM's clang parser as a build dependency with the effect that the package can no longer be built for a couple of architectures like alpha or ia64 [1]. >From my current understanding, qttools-opensource-src is merely using the parser part in clang to parse C/C++ code for code analysis

Hi Brian, > Thank you for this collection of patches. > > How can I test them? What platforms (computers) have the ppc64 or > POWER9 processor? The IBM Bounty Source page has a list of resources: https://www.bountysource.com/teams/ibm/bounties Travis also has ppc64le support, so if you add the linux-ppc64le target then FLAC will be tested on ppc64le. Thanks, Anton