similar to: [LLVMdev] The system library is gone for a long time.

OK, I'll resubmit it. 2013/5/26 David Majnemer <david.majnemer at gmail.com>: > This patch has changed "System V IPC" to "Support V IPC". This seems to be an accident caused by some sort of automation. > > Sent from my iPhone > > On May 25, 2013, at 7:27 AM, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com> wrote: > >>

This patch has changed "System V IPC" to "Support V IPC". This seems to be an accident caused by some sort of automation. Sent from my iPhone On May 25, 2013, at 7:27 AM, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com> wrote: > 0b5c0c9c868213fee1a8e3b571a96e2e099e8e1e > docs/SupportLibrary.rst | 247 ++++++++++++++++++++++++++++++++++++++++++++++++ >

On 25 May 2013 15:30, Sean Silva <silvas at purdue.edu> wrote: > This will break existing URLs. Until we have a way to set up redirects the > file name should stay the same. Would a SystemLibrary.rst saying it was replaced with the support library be ok? > -- Sean Silva Cheers, Rafael

>From 1d658dd52ca3973109e370103a7dd3485a4ee11f Mon Sep 17 00:00:00 2001 From: Yonggang Luo <luoyonggang at gmail.com> Date: Mon, 27 May 2013 00:07:16 +0800 Subject: [PATCH] The System library is merged into Support library. --- docs/SystemLibrary.rst | 104 ++++++++++++++++++++++++------------------------- docs/index.rst | 4 +- 2 files changed, 54 insertions(+), 54

ping,is there any other problems in this patch? 在 2013-5-27 上午12:09，"罗勇刚(Yonggang Luo)" <luoyonggang at gmail.com>写道： > From 1d658dd52ca3973109e370103a7dd3485a4ee11f Mon Sep 17 00:00:00 2001 > From: Yonggang Luo <luoyonggang at gmail.com> > Date: Mon, 27 May 2013 00:07:16 +0800 > Subject: [PATCH] The System library is merged into Support library. > > ---

>> Ideally we would have a >> docs/SystemLibrary.rst that would just says "this library has been >> merged to lib/Support" and docs/SupportLibrary.rst documents whatever >> is in lib/Support. > > > Considering our OS portability layer to be it's own separate thing, even if > it isn't its own lib/* directory is probably a good distinction to

I hit upon docs/SystemLibrary.rst today. Is this documentation useful to anyone? Can I delete it? Most of the guidelines seem like common sense: Keeping LLVM Portable, High Level Interface, No Unused Functionality, No Duplicate Implementations, etc. Some are not really true, like "Minimize Soft Errors". We currently propagate a lot of file-related soft errors up as

> Ah, ok. In that case, I think that it would be best to make a new page for > libSupport, and have it defer to SystemLibrary.rst for discussion of the > "libSystem" parts of libSupport. The major necessary changes for > SystemLibrary.rst would then be to mention its inclusion in libSupport > (important) and fix file paths (mechanical, less important). Sorry, but at least

> AFAIK, libSupport does more than what this document describes (for example, > it contains ADT, which are portable and not system-specific, contrary to the > second paragraph of the document). Does it make sense to just globally > replace "Support" for "System"? I wasn't around when the transition was > made, so I don't know. Please get a confirmation

On Mon, May 27, 2013 at 5:47 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > AFAIK, libSupport does more than what this document describes (for > example, > > it contains ADT, which are portable and not system-specific, contrary to > the > > second paragraph of the document). Does it make sense to just globally > > replace "Support"

On Mon, May 27, 2013 at 7:36 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > Ah, ok. In that case, I think that it would be best to make a new page > for > > libSupport, and have it defer to SystemLibrary.rst for discussion of the > > "libSystem" parts of libSupport. The major necessary changes for > > SystemLibrary.rst would then be to

Hi Daniel, Daniel Dunbar <daniel <at> zuster.org> writes: > > Ultimately I think a better API would be to provide a generic class > which represents an executed operating system process, and includes > operations to wait for its completion, redirect its IO, communicate > with it, etc. This would be a big improvement over the current > monolithic function. I agree,

Cygwin's <stdint.h> defines uint32_t as "unsigned long". I think this is valid, but it causes various problems like this when building LLVM with GCC 3.4.4: .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:3440: error: call of overloaded `AddInteger(uint32_t)' is ambiguous .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1429: error: no matching function for call to `max(long

> I've attached a patch to fix these. This allows me to build LLVM on cygwin. Sorry, I didn't mean to include this hunk: Index: CMakeLists.txt =================================================================== --- CMakeLists.txt (revision 58429) +++ CMakeLists.txt (working copy) @@ -31,8 +31,13 @@ ) if(WIN32) - set(LLVM_ON_WIN32 1) - set(LLVM_ON_UNIX 0) + if(CYGWIN) +

So ever since syzbot discovered fbcon, we have solid proof that it's full of bugs. And often the solution is to just delete code and remove features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code"). Now the problem is that most modern-ish drivers really only treat fbcon as an dumb kernel console until userspace takes over, and Oops printer for some emergencies. Looking at

Aaron Gray wrote: > On Sat, Feb 21, 2009 at 7:14 PM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca>> wrote: > > Aaron Gray wrote: > > On Thu, Feb 19, 2009 at 6:55 PM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca> > > <mailto:nicholas at mxc.ca <mailto:nicholas at mxc.ca>>> wrote:

Hi, I am trying to install llvm 2.5 in my PowerPC machine. I have already installed XCode Tools 2.4.1. I can compile programs using gcc run them. I try to configure llvm 2.5, the configuration aborts with following message: checking build system type... powerpc-apple-darwin8.11.0 checking host system type... powerpc-apple-darwin8.11.0 checking target system type... powerpc-apple-darwin8.11.0

On 29/10/2020 15:22, Daniel Vetter wrote: > So ever since syzbot discovered fbcon, we have solid proof that it's > full of bugs. And often the solution is to just delete code and remove > features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code"). > > Now the problem is that most modern-ish drivers really only treat > fbcon as an dumb kernel console until

On Thu, Jul 16, 2009 at 7:48 PM, Mikhail Glushenkov<foldr at codedgers.com> wrote: > Hi Daniel, > > Daniel Dunbar <daniel <at> zuster.org> writes: > >> >> Ultimately I think a better API would be to provide a generic class >> which represents an executed operating system process, and includes >> operations to wait for its completion, redirect

On Sat, Feb 21, 2009 at 7:14 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Aaron Gray wrote: > > On Thu, Feb 19, 2009 at 6:55 PM, Nick Lewycky <nicholas at mxc.ca > > <mailto:nicholas at mxc.ca>> wrote: > > > > Aaron Gray wrote: > > > On Thu, Feb 19, 2009 at 5:52 PM, Nick Lewycky <nicholas at mxc.ca > >