similar to: [RFC 0/2] Propose a new pointer trait.

Hi everyone, I have an idea that should allow reducing code duplication in Casting.h while making llvm::isa, llvm::cast, llvm::dyn_cast, etc more generic. Since we added unique pointers support for these template functions (see ab480f45cd23c08cb9aa3f427aad072df249135f) I propose to generalize their semantics to deal with any pointer-like type (i.e. dereferenceable and implicitly convertible to

It could be that 32-bit systems are disappearing so rapidly that nobody cares too much about this issue, but this blog post is still worth reading: http://trust-in-soft.com/objects-larger-than-ptrdiff_max-bytes/ John

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

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

Looks pretty reasonable to me - with test cases. (not sure if dereferenced_type should be defined for a type that's not dereferenceable, though?) On Tue, Jan 23, 2018 at 7:02 AM Dmitriy Borisenkov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi everyone, > > I have an idea that should allow reducing code duplication in Casting.h > while making llvm::isa, llvm::cast,

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

Chris Lattner wrote: > > inline IIty operator*() const { return BI; } > > inline IIty operator->() const { return operator*(); } > > > > So operator* works as if value_type is Instruction*, but operator-> works > > as if value_type is Instruction. Hmm ;-) > > Yeah, fishy huh? :) Yea, a bit. I've decided that before changing that I'd better

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 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 Fri, 23 Apr 2004, Vladimir Prus wrote: > Yea, I've noticed that. However, it looks like inst_iterator is iterator over > pointers. Oh, wait a minite, that's the current code: > > inline IIty operator*() const { return BI; } > inline IIty operator->() const { return operator*(); } > > So operator* works as if value_type is Instruction*, but operator->

Chris Lattner wrote: > On Fri, 23 Apr 2004, Vladimir Prus wrote: > > and since result of *it is considered to be rvalue it can't be accepted > > by this operator. The complete discussion is in > > > > http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm > > > > I'd suggest to apply the following patch which makes operator* return >

Hello, When running test-release.sh using GCC 5.4.0 we encountered this error : /home/anil/llvm1000_rc1_binary_upload/rc1/llvm-project/clang-tools-extra/clangd/Hover.cpp: In function ‘llvm::StringLiteral clang::clangd::{anonymous}::getNameForExpr(const clang::Expr*)’: /home/anil/llvm1000_rc1_binary_upload/rc1/llvm-project/clang-tools-extra/clangd/Hover.cpp:450:10: error: could not convert

Hi, here are some minor patches that for various reasons I've not submitted yet - I'm just trying to clear my list of differences before christmas... First of all the clear.patch file contains a patch that enables the JIT to drop all global mappings. I need this because when I have N threads I compile N different versions of my functions using different memory areas for global

Xapians! Did anybody wrote and would like to share a routines that parse result from doc.get_data() into some key and pair values in C++ ? Code: Xapian::Document doc = i.get_document(); string data = doc.get_data(); mymap = parse_result(data); As you know the data string contain all the data within the document delimited by "=" sign and "\n" new line and needs to be parse

Morten, The leaks.patch file introduced a static destructor ordering problem which lead to garbled output. The comment above those lines of code indicates why it needs to be the way it is. My bad for committing it in the first place. Please be careful in the future. Reid. On Mon, 2004-12-13 at 05:30, Morten Ofstad wrote: > Hi, > > here are some minor patches that for various reasons