similar to: [LLVMdev] Yet another MSVC fix

Sorry, I was too fast. There is more... But now all compiles fine. However I'm not very satisfied with the Constants.patch since I don't know for 100% sure what's going on. OK, I know that MSVC tries to instantiate the virtual member function FoldingSet<MDNode>::GetNodeProfile where gcc seems to be more relaxed on the instantiation of template functions. But I have no idea

Hi @llvm, what I have here is a library named clangAddons which is tightly coupled to clang and LLVM. This lib provides a single external function only which is then used by my actual application (a QT project). Of course the clangAddons lib needs to be compiled using the LLVM build infrastructure to get all the compiler flags right (you can see it as a lib similiar to clangAST aso.).

Hi @llvm, I've already asked the following questions to the clang dev list but got no response. Maybe there is a wider audience at llvmdev and someone here can help me. The question actually boils down to: How can I compile clang with rtti enabled? And this was my original mail (with some points now better explained) to clang: <--BEGIN--> Hi @clang, I'm somewhat puzzled about

Hi @llvm, building a debug version under MSVC 9 leads to a compiler error due to a mix of different types in a call to upper_bound. I have attached a hot-fix but I'm rather unsure if it should be applied as it is, since IMHO the reason is a MSVC library bug ("IMHO", because I don't know the requirements imposed to the predicate by the standard). Best regards Olaf Krzikalla

Hi @llvm, Am 08.03.2011 20:14, schrieb Jakob Stoklund Olesen: > Is that extra method getting called? What happens if you stick assert(0) in there? That won't work either (that is, the assert fires). In debug mode the MSVC lib tries to test the ordering of the sequence. And it uses the yielded predicate for this (which in this particular case is a very bad idea). > I hoped the

Hi llvm, it's for sure an obvious idea to use llvm as IR for heterogenous platforms (e.g. CPU+GPU). In theory someone could write plain C/C++ code, which by clang is translated to llvm-IL and then together with JIT-backends packed in an appropriate executable. Thus all the limitations and hassles of openCL or CUDA could be avoided. I wonder if there already is a related project? Of course in

Hi, I've done all the minor changes you recommended and have attached a new patch including both files again (even if po_iterator didn't change). However: Dan Gohman schrieb: > The plural of "child" is "children"; please rename this function > accordingly. Is "childs" just sloppy, is it american english or is it just a misconception of foreigners

On Mar 9, 2011, at 2:32 AM, Olaf Krzikalla <Olaf.Krzikalla at tu-dresden.de> wrote: > Hi @llvm, > > Am 08.03.2011 20:14, schrieb Jakob Stoklund Olesen: >> Is that extra method getting called? What happens if you stick assert(0) in there? > That won't work either (that is, the assert fires). In debug mode the MSVC lib tries to test the ordering of the sequence. And it

Hi @llvm, below is a copy of a message I sent to clang a hour before. I guess it's more appropriate here. --snip-- While trying to eleminate as much std::tr1::function as possible I stumbled over a design flaw in llvm::df_iterator. Consider the following code: void for_all_stmts(Stmt* S, const std::tr1::function<void(Stmt*)>& fn) { if (S) { fn(S); for

See the patch and the documentation: http://msdn.microsoft.com/en-us/library/ms686818(VS.85).aspx With the patch all compiles fine. Otherwise MSVC breaks rightly. Best Olaf Krzikalla -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: assertfix.patch URL:

Chris, attached you will find a patch implementing the approach I've posted yesterday. I don't want the topic fall by the wayside*. *Note that this patch here contains the df_iterator changes only, some (IMHO non-critical but needed) po_iterator changes are still in the pipeline and posted by me in another thread. I hope, the current approach fits all needs. Chris Lattner schrieb:

Hi @llvm, I stumbled over a strange behavior if a float containing a NaN is printed (e.g. in the clang rewriter). The local template method "append" in APFloat.cpp deduces the size from the char array, which for "NaN" is 4 (including the trailing zero). If APFloat::toString is called with a SmallString and then SmallString::str() is called, it returns "NaN\0". I

On Jun 15, 2009, at 4:33 AM, Olaf Krzikalla wrote: > While trying to eleminate as much std::tr1::function as possible I > stumbled over a design flaw in llvm::df_iterator. Ok. > However if fn replaces childrens of a just processed statement > (which happens a lot), the iteration may crash. Looking at > df_iterator reveals the reason: the first child of a particular >

Am 24.07.2012 18:50, schrieb David Blaikie: > Do you have a test case to go along with this? Unfortunately not. It just popped up as a result of a programming error made by me. > The simpler fix seems to be to untemplate this code& have "append" > take a StringRef. We can just rely on the compiler to optimize away > the strlen in StringRef's (const char*) ctor as

Hello, we are using Sambadav[1] with Samba 4.4 in our university, which relays on authentication-file with giving it a file descriptor. After 4.4 this does not any more and requires a filename. Is there something documented about this behaviour? Is there a new way to pass a file descriptor for authentication? Kind regards Philipp rehs [

Hi @clang and @llvm, attached you'll find a patch dealing with some iterator issues I already mentioned in both lists. Since there was no reaction I cross-post again - now IMHO production-ready code. The patch is considered to get checked-in out of the box. It should not affect the behavior of existing and working code. I really need it for clang AST processing. Changes: 1. Both

Hi Olaf, On Fri, Sep 11, 2009 at 5:24 AM, Olaf Krzikalla <Olaf.Krzikalla at tu-dresden.de> wrote: > Hi @clang, > > I'm somewhat puzzled about using rtti when building clang under gcc (gcc > 4.3.3, linux/ubuntu). > (There is no problem under MSVC since rtti seems to be active there anyway). > The appropriate line 348 in llvm/makefile.rules is commented out meaning >

On Mar 8, 2011, at 1:07 AM, Olaf Krzikalla wrote: > Hi @llvm, > > building a debug version under MSVC 9 leads to a compiler error due to a > mix of different types in a call to upper_bound. I have attached a > hot-fix but I'm rather unsure if it should be applied as it is, since > IMHO the reason is a MSVC library bug ("IMHO", because I don't know the >

Dear all, i have noticed some strange behaviour in the ?jitter? function in R. On the help page for jitter it is stated that "The result, say r, is r <- x + runif(n, -a, a) where n <- length(x) and a is the amount argument (if specified).? and "If amount is NULL (default), we set a <- factor * d/5 where d is the smallest difference between adjacent unique (apart from fuzz) x

Dear all, i have noticed some strange behaviour in the ?jitter? function in R. On the help page for jitter it is stated that "The result, say r, is r <- x + runif(n, -a, a) where n <- length(x) and a is the amount argument (if specified).? and "If amount is NULL (default), we set a <- factor * d/5 where d is the smallest difference between adjacent unique (apart from fuzz) x