similar to: [LLVMdev] /include/llvm/Bitcode/BitstreamReader.h

Hello, Could you look at current implementation of AtomicIncrement/AtomicDecrement? I think there is a error in version for MSVC. -- Иван Сорокин mailto:sorokin at rain.ifmo.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: application/octet-stream Size: 827 bytes Desc: not available URL:

This should fix this warning from Visual Studio 2010: 33>..\..\..\llvm-2.8svn-build\lib\MC\MachObjectWriter.cpp(772): warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) Index: lib/MC/MachObjectWriter.cpp =================================================================== --- lib/MC/MachObjectWriter.cpp (revision 111120) +++

Hello, Samuel Crow wrote: > It is possible to write an endian-agnostic bitcode file but I don't think all modern LLVM compilers support it. > Which ones llvm assembler instructions is not endian-agnostic? -- Ivan

Hello Vladimir, While this is great for platforms that use the current gas style assembler macros your patch also changes the existing support for darwin that does not use these style of assembler macros. Could you please update your patch that leaves the assembler macros unchanged for darwin. Then we can review the updated patch. Thanks, Kev On Feb 5, 2012, at 1:43 PM, Vladimir Sorokin

Hello! I tryed to configure Debian Linux file server as Windows 2003 domain member using samba with security = ADS mode and stucked with such problem: File server (fs) succesfully joined my domain with correct user and group mapping (i'm using idmap rid). Users from domain have their unix accounts with <DOMAIN_NAME>\ prefix, i.e for domain user "andrey" i have local unix

Hello Kevin, I thinking about this, but there are some problems: 1) Differrent interpretation of $[:number:] in macro body: source: .macro test par1 movl $0, %eax .endm test %ebx translated to: original llvm => movl %ebx, %eax with patch => movl $0, %ebx 2) Different parsing of space in macro parameters: source: test2 a + b,c parsed as: original llvm => macro test2 with two

Hi all, BitstreamReader is the only in-tree client of the DataStreamer and MemoryObject interfaces. In practice when using user-facing LLVM tools, the bitcode will normally either be in memory or in a file, so the best way to access it is through memory, either directly or memory mapped. As part of some refactorings I am making to BitstreamReader, I would like to simplify it by changing it to

Helper function: template<typename InsnType> static InsnType fieldFromInstruction(InsnType insn, unsigned startBit, unsigned numBits) { assert(startBit + numBits <= (sizeof(InsnType)*8) && "Instruction field out of bounds!"); InsnType fieldMask; if (numBits == sizeof(InsnType)*8) fieldMask =

And on a separate thread [0] Derek indicated he'd be fine with removing it. I'll leave this thread open until end of Monday to receive any other opinions, then proceed to remove it. Peter [0] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161024/400754.html On Fri, Oct 28, 2016 at 10:08 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi all, > >

Hey there, I'm relatively new to the llvm scene, and so far I'm liking it quite a bit. I'm a bit perplexed as to what llvm-gcc's role is in everything. I've used it to create .bc files for really simple functions and it seems to do quite well at that, but I've been trying to figure out how to take the output from llvm-gcc and actually use it in another program.

Awesome! Thanks, Rafael On 28 October 2016 at 13:14, Peter Collingbourne <peter at pcc.me.uk> wrote: > And on a separate thread [0] Derek indicated he'd be fine with removing it. > I'll leave this thread open until end of Monday to receive any other > opinions, then proceed to remove it. > > Peter > > [0] >

Hi Danny, On 2007-12-26, at 15:39, Danny wrote: > I've noticed that the BitcodeReader appears to be an internal > module, but the BitstreamReader is public. Should I be using the > BitstreamReader? If so how. The generic BitstreamReader class is public because it's used in other projects, including clang, to serialize data structures other than LLVM IR. The coding of

Hi all, This is about https://reviews.llvm.org/D26100 That change moves the block info block state from BitstreamReader to BitstreamCursor in order to accommodate multiple block info blocks (the idea is that the cursor would store the block info block state for whichever block info block is active for that cursor). Duncan objected to it on the grounds that we should aim for a design that would

> On Oct 28, 2016, at 6:00 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi all, > > This is about https://reviews.llvm.org/D26100 <https://reviews.llvm.org/D26100> > > That change moves the block info block state from BitstreamReader to BitstreamCursor in order to accommodate multiple block info blocks (the idea is that the cursor would store the

That worked quite well. Thank you. One question as a follow up: is there a nice/standard way of including the pre-made bitcode chunks in with the binaries that are being created which read them? Bascially, I'd like to have the same functionality, but rather than having one or more .bc files running around which need to be read at runtime by an executable, moving that into the code

Hi Sunil, I had filed a bug and saw your response stating that it would be fixed in version 14. In the meanwhile , what we want to know is whether this bug is a minor bug and can be ignored for now. Does reporting 100% inodes cause any problem for the OCFS file system or can we ignore this bug and go into production. Also can you tell us by when version 14 would be released. R'gds

> On 2016-Oct-31, at 20:30, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Oct 28, 2016, at 6:00 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >> >> Hi all, >> >> This is about https://reviews.llvm.org/D26100 >> >> That change moves the block info block state from BitstreamReader to BitstreamCursor in order to

>> Apparently BitcodeReader.h is only in lib/Bitcode/Reader/ but not in >> include, so a make install does not install it. >I'm not sure what you mean... the header is in include/llvm/Bitcode. >> Is it supposed to be accessible from applications? How exactly? I feel that >> some install rule is missing; after a sudo make install, >> grep -rn BitcodeReader

Hello. Could you please tell me why am I not able to recognize (with LLVM built from the SVN code in Apr 25, 2018) the LLVM IR intrinsic ctpop (described at https://llvm.org/docs/LangRef.html#llvm-ctpop-intrinsic) in the following program: int PopCnt_Simple(int x) { int numBits = 0; int i; //for (i = 0; i < 32; i++) { for (i = 0; x !=

hi all how do i turn on Listener? from justin > On Oct 23, 2015, at 2:29 PM, Dmitrijs Sorokins <dv.sorokins at googlemail.com> wrote: > > Hello Justin. Can you be more specific? What is the problem? > > 23.10.2015 22:27, Justin Bergers ?????: >> hi all >> >> why i?m not Listening my icecast? i need help please with setting up icecast server. >>