similar to: [LLVMdev] Urgent fix for MSVC

Please commit... Best Olaf Krzikalla -- Olaf Krzikalla Technische Universitaet Dresden Zentrum fuer Informationsdienste und Hochleistungsrechnen Abteilung Verteiltes und Datenintensives Rechnen Zellescher Weg 12, 01069 Dresden Willersbau, Zimmer A105 Telefonnr.: +49 351 463-32442 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: twine.patch

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

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

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, 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, 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

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 >

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

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, 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 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 >

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

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 >

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 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

MSVC 9 asserts that the comparision function is symmetric, because of what was unclear wording in the standard (there are posts explaining this in the boost archive for those interested). The workaround is to supply the other overload of the comparator. Sorry Jacob, didn't reply all last time. On Wed, Mar 9, 2011 at 7:20 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > On Mar

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

On Tue, Jul 24, 2012 at 3:06 AM, Olaf Krzikalla <Olaf.Krzikalla at tu-dresden.de> wrote: > 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).

Hi Olaf, This patch looks good to me. I just have a few minor comments: > + inline df_iterator() { CurrentTopNode = 0; /* End is when stack is empty */ } Should the comment here be updated to say that the End is reached when the stack is empty and when CurrentTopNode is null? > + inline void toNext() > + { LLVM style puts the open brace on the same line as the function name.