similar to: problems with objects larger than PTRDIFF_MAX

I've come across this issue before and came to the following conclusion: - We are not obligated to support objects that large, C11 5.2.4.1/1 only requires that we support objects of size 65535! Their guidance for maximum object size is stated to be half of SIZE_MAX in C11 K.3.4/4 which is typically equivalent to PTRDIFF_MAX. - The expectation that PTRDIFF_MAX is more or less a proxy for the

On 2016-05-20 19:58, David Majnemer via llvm-dev wrote: > I've come across this issue before and came to the following conclusion: > - We are not obligated to support objects that large, C11 5.2.4.1/1 only > requires that we support objects of size 65535! Right, the standard doesn't require it. But I guess you don't imply that it's fine for clang to silently miscompile

On Sun, May 29, 2016 at 6:18 AM, Alexander Cherepanov <ch3root at openwall.com> wrote: > On 2016-05-20 19:58, David Majnemer via llvm-dev wrote: > >> I've come across this issue before and came to the following conclusion: >> - We are not obligated to support objects that large, C11 5.2.4.1/1 only >> requires that we support objects of size 65535! >> >

Hi all, Just tried to build from svn sources with Visual Studio 2008, mostly OK but fails building the X86AsmParser lib - I see a few commits from yesterday that may have something to do with it, but no idea what the solution is. -David See MSVC's beautiful and concise output below; Compiling... X86AsmParser.cpp C:\dev\MSVisualStudio\VC\include\xutility(313) : error C2664: 'bool

On Sep 6, 2010, at 10:50 PM, David Shipman wrote: > Hi all, > > Just tried to build from svn sources with Visual Studio 2008, mostly > OK but fails > building the X86AsmParser lib - > > I see a few commits from yesterday that may have something to do with it, but no > idea what the solution is. Wow, that's a pretty terrible diagnostic. Does r113198 help? -Chris

That source file was removed from LLVM in r232397 on March 16, 2015. It looks like lljvm hasn't been updated in a long time. LLVM's C++ APIs are not stable, so there is no expectation that a project built against LLVM's C++ API in 2015 would build or reasonably function against LLVM trunk. The project probably works against LLVM 3.6.2 which was (I believe) the last LLVM release to

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'

Hi, I'm part of an engineering team doing research on persistent memory support and we have stumbled upon an interesting problem. The issue is, we would like to be able to use the standard library containers in a persistent memory context (think NVDIMM-N). What I mean is that you allocate a container from said memory, use it like you normally would. After the application terminates, expectedly

Hi list, I have several questions about LLVM pass. 1) Is building a custom LLVM pass out-of-source not recommended? The official document only contains instructions about in-source build (http://llvm.org/docs/WritingAnLLVMPass.html <http://llvm.org/docs/WritingAnLLVMPass.html>). 2) opt (ver >= 4) with custom pass libraries does not work as before. When I have a simple custom LLVM pass

On 04/05/2014 02:30, Tom Stellard wrote: > On Sat, May 03, 2014 at 12:32:02AM +0100, Alp Toker wrote: >> On 02/05/2014 20:45, Tuncer Ayaz wrote: >>> Bump. >>> >>> Is it really unsupported to build llvm from scratch with gcc 4.9 and >>> libstdc++ 4.9? Should I file a bugzilla ticket instead? >> Obviously LLVM/clang should compile out of the box

Hello, Our llvm::iterator_range is quite minimalist in design, it does not even have an "empty" method. Is that because we want it to work on all iterators (including those dirty OutputIterator)? Maybe we can add a little bit to it? I recently needed: - bool empty() - value_type& font() - value_type& back() - void advance_begin(difference_type n) - void

>On 11/8/2017 9:24 AM, Nuno Lopes via llvm-dev wrote: >> Hi, >> >> I was looking into the semantics of GEP inbounds and some BasicAA rules >> and I'm wondering if it's valid in LLVM IR to allocate more than half of >> the address space with a global variable or an alloca. >> If that's a scenario want to consider, then we have problems :)

On Mon, May 5, 2014 at 10:47 AM, Chandler Carruth <chandlerc at google.com>wrote: > On Mon, May 5, 2014 at 8:11 AM, Alp Toker <alp at nuanti.com> wrote: > >> I suspect that pulling in clang header fixes r201729, r202911 and r207606 >> to 3.4.1 will resolve libstdc++ / glibc compatibility issues people have >> been having with 3.4: >> >> r201729:

Hi, in include/share/alloc.h there is this section: #ifndef SIZE_MAX # ifndef SIZE_T_MAX # ifdef _MSC_VER # define SIZE_T_MAX SIZE_MAX # else # error # endif # endif # define SIZE_MAX SIZE_T_MAX #endif So, if we are on MSVC and have neither SIZE_MAX nor SIZE_T_MAX, we'll define SIZE_T_MAX to mean SIZE_MAX and SIZE_MAX to mean SIZE_T_MAX. I'm afraid this won't work ... It

Hello, I was trying to compile Flac on MinGW/Msys but got an error stating SIZE_T_MAX is undefined. To fix this error I edited the file "flac-1.2.1/include/share/alloc.h" and made the following change: Starting at line #36 I changed: #ifndef SIZE_MAX # ifndef SIZE_T_MAX # ifdef _MSC_VER # define SIZE_T_MAX UINT_MAX # else # error # endif # endif # define SIZE_MAX SIZE_T_MAX

On 13 July 2016 at 10:19, Luis de Bethencourt <luisbg at osg.samsung.com> wrote: > On 11/07/16 23:46, Markus Mayer wrote: > > Hi Markus, > > Amazing. I see this happening as well, but I know it shouldn't. > > The reason the #ifndef guards in headers are there is precisely to allow > circular dependencies. > > The problem in your output reads as: >

Hello, I've been building Clang under Windows 7 and Visual Studio 2008 for a while now, but had not touched it in a few months. Last night I wiped my build tree to do a full rebuild with the latest version, and got the identical error as David Shipman was seeing last September. Are others able to build under VS9 right now? Thanks, John > Subject: Re: [LLVMdev] MS VS2008 build fails -

On Mon, Jul 15, 2019 at 2:43 PM Siva Chandra <sivachandra at google.com> wrote: > > > On 7/15/19 1:22 PM, Aaron Ballman via llvm-dev wrote: > > > On Mon, Jul 15, 2019 at 1:02 PM Siva Chandra <sivachandra at google.com> wrote: > > >> On Fri, Jul 12, 2019 at 8:32 AM Aaron Ballman <aaron at aaronballman.com> wrote: > > >>>> llvm-libc

On 7/15/19 1:22 PM, Aaron Ballman via llvm-dev wrote: > On Mon, Jul 15, 2019 at 1:02 PM Siva Chandra <sivachandra at google.com> wrote: >> On Fri, Jul 12, 2019 at 8:32 AM Aaron Ballman <aaron at aaronballman.com> wrote: >>>> llvm-libc is an implementation of the C standard library targeting C11 >>>> and above. >>> Any particular reason for C11