similar to: Enabling debug information for debug only

Displaying 20 results from an estimated 900 matches similar to: "Enabling debug information for debug only"

2020 Nov 15
3
[RFC] Backend for Motorola 6800 series CPU (M68k)
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
2020 Nov 03
4
[RFC] Backend for Motorola 6800 series CPU (M68k)
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.
2018 Aug 19
4
Adding minimal target support to build clang
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
2020 Nov 16
1
[RFC] Backend for Motorola 6800 series CPU (M68k)
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.
2020 Nov 15
3
[RFC] Backend for Motorola 6800 series CPU (M68k)
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 -
2020 Sep 25
1
[cfe-dev] [RFC] Backend for Motorola 6800 series CPU (M68k)
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
2020 Sep 28
2
[RFC] Backend for Motorola 6800 series CPU (M68k)
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
2020 Sep 28
3
[RFC] Backend for Motorola 6800 series CPU (M68k)
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
2020 Mar 24
3
Bountysource campaign for the M68000 backend
Hello! Almost two years ago, Artyom Goncharov submitted an initial effort for a backend for the Motorola 68000 architecture [1] which was eventually not merged, unfortunately. I elaborated why I supported the idea of such a backend [2]. Recently, we started a fundraising campaign on the platform Bountysource.com to port the M68K backend in GCC to the new MODE_CC register representation which was
2020 Sep 29
2
[RFC] Backend for Motorola 6800 series CPU (M68k)
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
2018 Nov 30
1
[PATCH RFC 00/15] Zero ****s, hugload of hugs <3
On 11/30/18 8:40 PM, Kees Cook wrote: > Better yet, since it's only 17 files, how about doing context-specific > changes? "This API is terrible", "Hateful interface", "Don't touch my > freakin' code", "What in the world were they thinking?" etc? Or just leave it as is because we're all grown up and don't freak out when a piece of
2018 Nov 30
8
[PATCH RFC 00/15] Zero ****s, hugload of hugs <3
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
2020 Nov 03
0
[RFC] Backend for Motorola 6800 series CPU (M68k)
Hi Min! On 11/3/20 6:10 PM, Min-Yih Hsu wrote: > Showing the prerequisites to become an experimental target and eventually, > an official target. We're currently struggling on setting up the buildbot > but I believe Adrian (CC-ed) is working on that. So I hope the patches can > be sorted out while waiting for the buildbot. The m68k machine is actually already up and running, I
2020 Nov 10
0
Building an LLVM cross-compiler
Hello! On 11/10/20 2:49 PM, Cág via llvm-dev wrote: > Just a quick update. Here's what worked for me here*: > 1. Get the sources. > 2. Build clang, llvm, lld. > 3. Install libc headers to a sysroot. Alternatively, use a Debian-based system which allows co-installation of system libraries for multiple architectures (Multi-Arch). Never understood why other distributions
2020 Nov 13
0
[RFC] Backend for Motorola 6800 series CPU (M68k)
Hello! On 11/3/20 6:10 PM, Min-Yih Hsu wrote: > 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. Are there any news on this? The M68k buildbot is ready
2020 Nov 15
0
[RFC] Backend for Motorola 6800 series CPU (M68k)
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 - is there anything else? Sounds good. I'll file that bug tomorrow. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz :
2020 Nov 18
0
Reviewer for a small clang Driver code change needed
Hi! I have made a small change to the clang Driver code [1] which fixes the testsuite on Linux/sparc64 Currently, more than 400 tests fail on Linux/sparc64 [2] which drops to around 70 failures with the fix applied. The reason for that is that without the fix, all 32-bit tests will fail on 64-bit Linux/sparc64 since clang is unable to find the 32-bit shared libraries on the 64-bit system. What
2020 Sep 24
7
[RFC] Backend for Motorola 6800 series CPU (M68k)
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
2020 Sep 29
3
[RFC] Backend for Motorola 6800 series CPU (M68k)
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
2012 Jul 23
9
[Bug 52398] New: nouveau: DPMS permanently turns off display when starting X.org, text console works fine
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: