similar to: [LLVMdev] llvm (hence Clang) not compiling with Visual Studio 2008

On Thu, Jul 4, 2013 at 12:48 AM, Benoit Perrot <benoit.noe.perrot at gmail.com>wrote: > Hello, > Hi Benoit, > I have just updated my svn copy of the llvm/clang repositories after quite > a long time of inactivity, and found it not compiling on Windows with > Visual Studio 2008. > > The incriminated file is: > > llvm/lib/MC/MCModule.cpp > > Where several

There is some historical precedence for fixing the problem with VS lower_bound by changing the LLVM source - when I first got LLVM to compile with Visual Studio, patches for unsymmetric operator < were accepted into the LLVM repo, and I believe it's been done several times after that as well. m. >From: Ahmed Bougacha >Sent: Friday, July 05, 2013 1:43 AM >To: Benoit Perrot

On Thu, 31 May 2007, Chuck Rose III wrote: > Our project is cross platform and on Windows we use VStudio 2005. > VStudio presents a couple of issues related around it's STL > implementation and also it's non-respect for the no-return semantic of > abort(). Ok. We want the source to be portable, so it's goodness to get these fixes into the main tree. > I've fixed

Hola LLVMers, Our project is cross platform and on Windows we use VStudio 2005. VStudio presents a couple of issues related around it's STL implementation and also it's non-respect for the no-return semantic of abort(). I've fixed it locally, but I'd like to send a patch so I don't have to do this every time I update from the source repository. So.... if I'm

Here are the two problem areas: RegisterInfoEmitter.cpp // Emit the subregister + index mapping function based on the information // calculated above. OS << "unsigned " << ClassName << "::getSubReg(unsigned RegNo, unsigned Index) const {\n" << " switch (RegNo) {\n" << " default: abort(); break;\n"; ...

I'm not sure what causes this. Everything builds fine in Release mode but when I try to do a Debug build I get an error in Transforms (which causes all dependant projects to fail as well). I'm not exactly sure what causes the error, I'll try to investigate tomorrow (unless someone can figure out what it is by then). Below is the output from VS: ------ Build started: Project:

It compiles successfully with VC++ 7.1. You are apparently using VC++ 8.0, otherwise known as the Whidbey beta. The cause is no doubt due to bugs in Whidbey and this isn't the first one encountered. I'm sorry, but I cannot support beta Microsoft products (if only because I refuse to have them anywhere near my computer). All I can suggest is that you do a 'clean solution'

When I was trying to find yesterday's xmms-plugin bug, i have noticed that seeking in stream without seek-table isn't very good. With attached patch it is much better. -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/seekable_stream_decoder.c.orig 2003-02-26 19:41:51.000000000 +0100 +++ src/libFLAC/seekable_stream_decoder.c 2003-07-09 23:49:35.000000000 +0200

Ok, the patch from 2003 about improving seeking still didn't make it to CVS, so here is another try. I made some benchmarking with the test_seeking utility from flac sources to show how bad the current seeking is, especially without seektable. Track used for the experiment had about 50 minutes. In the following table is average number of seeks and number of decoded frames required for one

Ok, here is a patch waiting for new CVS :). It works fine for me, but please check it before commiting... -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/bitbuffer.c.orig 2003-01-30 17:36:01.000000000 +0100 +++ src/libFLAC/bitbuffer.c 2003-01-30 21:53:18.000000000 +0100 @@ -51,6 +51,25 @@ */ static const unsigned FLAC__BITBUFFER_DEFAULT_CAPACITY = ((65536 - 64) *

On Mon, Oct 30, 2006 at 11:13:25AM -0800, Josh Coalson wrote: > my apologies for not doing this before Miroslav... I will definitely > integrate it this time. Thanks. Sending latest version of the patch. Now it can seek in files that have large id3 tag (or any random data) at the end and it won't loop on streams with shuffled frames. -- Miroslav Lichvar -------------- next part

Michael, Yes, while stepping through this VS2010 `std::swap` code, `_Move` did nothing, e.g. //////////////////////////////////////////////////// void swap(_Ty& _Left, _Ty& _Right) { // exchange values stored at _Left and _Right _Ty _Tmp = _Move(_Left); _Left = _Move(_Right); _Right = _Move(_Tmp); } //////////////////////////////////////////////////// was equivalent to:

Hi all, A few days ago, there was a report of LLVM not compiling on VS 2008, because of asymmetric std::lower_bound comparators not supported there. As noted by a few people, maybe it's time to drop VS 2008 compatibility and move the requirements to VS 2010? While there, what about going further and starting using C++11? Now seems as good a time as ever; my takeaway from that few months old

On Mon, Oct 4, 2010 at 9:52 PM, Bob Floyd <bobfloyd at comcast.net> wrote: > When using MS VS2010 there is an issue with std: > > > > `SuccIterator` implements a partial assignment operator: > > > > inline const _Self &operator=(const _Self &I) { > >     assert(Term == I.Term &&"Cannot assign iterators to two different >

Hola LLVMers, We saw a problem with some code in LiveIntervalAnalysis.h/.c which we've fixed locally. We'd like to get a patch to the mainline and want to know how you'd like it fixed. A couple of things come together to cause the problem: struct Idx2MBBCompare { bool operator()(const IdxMBBPair &LHS, const IdxMBBPair &RHS) const { return LHS.first <

Hi Bob, was this issue resolved? Ciao, Duncan. > When using MS VS2010 there is an issue with std: > > `SuccIterator` implements a partial assignment operator: > > inline const _Self &operator=(const _Self &I) { > > assert(Term == I.Term &&"Cannot assign iterators to two different blocks!"); > > idx = I.idx; > > return *this; > > }

Hi Alexandra, I don't know much, maybe this topic should be bridged with polly-dev (adding it to CC) to bring it more attention. Indeed, polly uses ScopPass, that creates serious limitations in compatibility with other passes. To my understanding, scops are used because ISL loop analysis tool uses scops. In fact, just for handling OpenMP directives scops are not required, unless one need to

When using MS VS2010 there is an issue with std: `SuccIterator` implements a partial assignment operator: inline const _Self &operator=(const _Self &I) { assert(Term == I.Term &&"Cannot assign iterators to two different blocks!"); idx = I.idx; return *this; } For copy construction, MS VS2010 std reserves the right, and sometimes calls, a

Hi Anton > > > The interesting for me part of the CallInst is printf(i8* noalias %0, i32 > > 123). > > I was diging in doxygen documentation but I really can't see the easy way > to > > compare those instructions and again finish with reinvented (but working) > > wheel ;). > Ah, sorry. I missed that you're doing variadic calls, not casting >

Hi, I want to execute the iterations of a loop in parallel, by inserting calls either to pthreads or to the gomp library at the LLVM IR level. As a first step, I inserted an omp pragma in a C file and compiled it with llvm-gcc to check the generated LLVM code. If I understand correctly, to parallelize the loop in LLVM IR, I have to separate the loop in a new function, put all required parameters