similar to: [LLVMdev] Offset to C++ structure members

On Mon, Oct 1, 2012 at 9:33 PM, Paul J. Lucas <paul at lucasmail.org> wrote: > Given the C++ struct: > > struct S { > string a; > string b; > }; > > I also have C "thunk" functions that I call from LLVM code: > > // calls S::S() > void* T_S_M_new( void *heap ); > > // call

On Oct 1, 2012, at 9:58 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > Using GEP on an i8* is a bit nicer to the optimizer, though, because > using ptrtoint/inttoptr has effects on alias analysis. My understanding is that, in order to use GEP, you have to provide the LLVM code with the struct layout, i.e., build a StructType object. In my case, that struct is declared in C++

On Tue, Oct 2, 2012 at 11:33 AM, Paul J. Lucas <paul at lucasmail.org> wrote: > On Oct 1, 2012, at 9:58 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > >> Using GEP on an i8* is a bit nicer to the optimizer, though, because >> using ptrtoint/inttoptr has effects on alias analysis. > > My understanding is that, in order to use GEP, you have to provide the

On Oct 2, 2012, at 2:34 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Oct 2, 2012 at 11:33 AM, Paul J. Lucas <paul at lucasmail.org> wrote: > >> My understanding is that, in order to use GEP, you have to provide the LLVM code with the struct layout, i.e., build a StructType object. In my case, that struct is declared in C++ code already and, in order to

I have some security alert log data that I'm parsing and doing some stats on. One of the fields is the "Classtype" which is the enumerated value of the type of alert found. classtypes = factor( alerts$Classtype ) fclass_types = table( classtypes ) fclass_types gives me a frequency table of the intrusion types: fclass_types classtypes

Hi all-- I tried building the ARM-optimized theora codec from the theorarm- merge-branch, and encountered the following compile and runtime problems before getting something to run. If there is another way to build it, it would be nice to know, but I got the sense that its current state in svn is incomplete. I'm using a gcc cross-compiler for ARM on an x86 Linux PC. After running

We have code that processes a buffer in the forward or backwards direction. It looks similar to the following (https://github.com/weidai11/cryptopp/blob/master/adv-simd.h#L1138): uint8_t * ptr = ... size_t len = ... size_t inc = 16; if (flags & REVERSE_DIRECTION) { ptr += len - inc; inc = 0-inc; } while (len > 16) { // process blocks ptr += inc; len -= 16; } Clang

On 31-Dec-15 09:00, Erik de Castro Lopo wrote: > Brian Willoughby wrote: > >> What's wrong with something incredible simple, like: >> >> #define FLAC__BYTES_PER_WORD (sizeof(int)) > The fact that it actually is not correct. We want to determine > the size in bits of the CPU registers. > > Here's what I know: > > sizeof(int)

Hi I found a weird problem in testthat while working with an ALTREP package. The package name is AltWrapper. My ALTREP serialize function is called even when I'm trying to serialize a non-ALTREP object. Here is an example ``` context("altrep") length_func<-function(x){ return(length(x)) } setAltClass(className = "test", classType = "real")

Hi, I wanted to ask if people have good advice on how to debug M1Mac package check errors when you don?t have a Mac? Is a cloud machine the best option or is there something else? Thanks Holger [[alternative HTML version deleted]]

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

Hi, I?ve gone through the mailing list archives and hereby want to resubmit my pending patches. Most are independent of each other, except the m68k patch which will only be complete if sigsuspend is also fixed. (It can be applied before that, though.) http://www.zytor.com/pipermail/klibc/2012-January/003173.html [PATCH] fix m68k support Resubmitted here as 0005. While there was a question from

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

Hi, We are developing a bounded model checker for C/C++ programs (http://baldur.iti.kit.edu/llbmc/) that operates on LLVM's intermediate representation. While checking a C++ program that uses STL containers we noticed that llvm-gcc and clang handle pointer differences in disagreeing ways. Consider the following C function: int f(int *p, int *q) { return q - p; } Here's the

VS has a 64-bit portability mode, where it will complain when it sees non-portable code. I haven't tried it yet on LLVM, but in my experience it will generate a *lot* of warnings. Every time a size_t or ptrdiff_t is assigned to an int or even a long it will complain (Microsoft defines long as 32-bits, even in win64). On the other hand, gcc defines long as 64-bits on 64-bit Unix (so

Hi Stephan, > We are developing a bounded model checker for C/C++ programs > (http://baldur.iti.kit.edu/llbmc/) that operates on LLVM's intermediate > representation. While checking a C++ program that uses STL containers > we noticed that llvm-gcc and clang handle pointer differences in > disagreeing ways. > > Consider the following C function: > int f(int *p, int *q)

On Dec 30, 2015, at 3:09 AM, Thomas Zander <thomas.e.zander at googlemail.com> wrote: > On 29 December 2015 at 21:50, lvqcl <lvqcl.mail at gmail.com> wrote: >> So, does it make sense to #define FLAC__BYTES_PER_WORD (in bitreader.c) >> as 4 for 32-bit and as 8 for 64-bit targets? > > Your tests so far imply this is a sensible default. > I'd say go ahead. We

FYI, looks like support for Racoon is ending. Does anyone have any experience with the version in ipsec-tools ? ---Mike >Racoon users, > >This is the announcement that the kame project will quit providing >a key management daemon, the racoon, and that "ipsec-tools" will become >the formal team to release the racoon. >The final release of the racoon in the

On 02/12/2010 09:51 AM, Chris Lattner wrote: > I think that the point is that you can define your own standard runtime interfaces: > > void *myopen(const char*path) { > return fopen(path, ...); > } Maybe my experience hand-coding LLVM will actually be of some help. What I did for this case is what I think Chris is suggesting--I have a .c file with functions that return

Jeff Cohen wrote: > VS has a 64-bit portability mode, where it will complain when it sees > non-portable code. I haven't tried it yet on LLVM, but in my experience > it will generate a *lot* of warnings. Every time a size_t or ptrdiff_t > is assigned to an int or even a long it will complain (Microsoft defines > long as 32-bits, even in win64). On the other hand, gcc