similar to: [LLVMdev] llc: assertion fails in bitreader.cpp

Hi all, I've used the llvmgcc to compile a quite simple bit of c-code: >short addtest(short a, short b) >{ > return a+b; >} When I'm feeding llc (llvm-2.1-version) with the resulting bytecode, it fails with this error: llc: BitcodeReader.cpp:1040: bool llvm::BitcodeReader::ParseModule(const std::string&): Assertion `Func->getFunctionType()->getParamAttrs() ==

It seems that -march=cpp is broken. the -march=cpp is very useful for people trying to understand the builder API. But, if the output of -march=cpp does not even compile, it obviously creates code that is broken, so defeats the object of helping people understand the builder API. Why isn't -march=cpp tested at all? See detail below. Kind Regards James Take a very simple example:

Dear Dev-Team, I am currently in the process of writing my bachelor thesis. The topic is about the implementation and evaluation of trace scheduling in the llvm framework for VLIW architecture. Simplifying the problem, only loop free code will be processed. Further, preparations and studies of llvm framework have shown, that, in my humble opinion, the machineScheduler::runOnMachineFunction()

So far I'm really liking the new type system -- I've been able to simplify my code generator in a number of areas. And the IR is now vastly more readable, both in the debugger (using dump()) and when printing modules via llvm-dis. It's a tremendous improvement. I do have a few comments / questions: -- I think I may be misunderstanding how named structs are supposed to be combined in

Hi there, I've been trying to build llvm2.1 this week. I remembered succeeding in doing that a month ago or so. I am kind of puzzled, what I'm doing wrong this time. I'm working on a x86/linux system. I've tried several gcc-versions (3.3, 3.4, 4.1, 4.2). make stops with the following error message: collect2: ld returned 1 exit status make[2]: ***

fixed in cvs http://sourceforge.net/tracker/?func=detail&aid=2490454&group_id=13478&atid=113478 --- On Mon, 6/1/09, Gilles Boccon-Gibod <bok at bok.net> wrote: > From: Gilles Boccon-Gibod <bok at bok.net> > Subject: [Flac-dev] Bug in bitreader for short reads? > To: flac-dev at xiph.org > Date: Monday, June 1, 2009, 10:16 AM > It seems that the bitstream

On Sun, Dec 20, 2015 at 01:30:57PM +0300, lvqcl wrote: > Erik de Castro Lopo wrote: > > > The think in and ideal world we would a: > > > > * Make it work correctly FLAC__BYTES_PER_WORD == 8 and compare the performance > > with FLAC__BYTES_PER_WORD == 4. > > * If there is an statistically measurable performance, keep it, otherwise > > remove the

you're right, this is fixed in CVS, see http://sourceforge.net/tracker/?func=detail&aid=2490454&group_id=13478&atid=113478 --- On Sun, 5/31/09, Gilles Boccon-Gibod <bok at bok.net> wrote: > From: Gilles Boccon-Gibod <bok at bok.net> > Subject: [Flac] Bug in bitreader for short reads? > To: flac at xiph.org > Date: Sunday, May 31, 2009, 10:40 PM > It

There are preprocessor definitions in bitreader.c and bitwriter.c: /* Things should be fastest when this matches the machine word size */ /* WATCHOUT: if you change this you must also change the following #defines down to SWAP_BE_WORD_TO_HOST below to match */ /* WATCHOUT: there are a few places where the code will not work unless uint32_t is >= 32 bits wide */ #define

Erik de Castro Lopo wrote: > The think in and ideal world we would a: > > * Make it work correctly FLAC__BYTES_PER_WORD == 8 and compare the performance > with FLAC__BYTES_PER_WORD == 4. > * If there is an statistically measurable performance, keep it, otherwise > remove the FLAC__BYTES_PER_WORD == 8 code all together. I'll try to do it, but I don't have a deep

On Nov 8, 2012, at 3:31 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Joe, > >> We have a tool which reads in bitcode, processes it, and re-emits it. We use >> this tool as a flexible way to integrate our tool into the Xcode, Android NDK, >> Chromium, and Linux build process. >> >> The problem we face is that bitcode changes, and when it does…

It seems that the bitstream reader is not working as it should (verified in version 1.2.0 and 1.2.1). The problem is as follows: if the data read by the read callback is not a multiple of 4, the bit reader will end up in a very bad state, where the bits_consumed field will grow without ever being reset to 0, and that causes everything to fail. This is not a case that's encountered very

Fixes typos in comments in these two files. -------------- next part -------------- A non-text attachment was scrubbed... Name: typo.patch Type: application/octet-stream Size: 1602 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20140212/f8f231cf/attachment.obj

It seems that the bitstream reader is not working as it should (verified in version 1.2.0 and 1.2.1). The problem is as follows: if the data read by the read callback is not a multiple of 4, the bit reader will end up in a very bad state, where the bits_consumed field will grow without ever being reset to 0, and that causes everything to fail. This is not a case that's encountered very

+llvmdev > On 2014 Dec 18, at 15:14, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > Currently we support reading bitcode in 3 ways: > > * Read everything upfront. > * Be lazy about reading the function bodies. > * Read the bitcode over a streaming interface. > > The first two modes are commonly used and well tested. In fact the > "read

On Mon, Jul 25, 2011 at 6:35 AM, Garrison Venn <gvenn.cfe.dev at gmail.com>wrote: > Hi Talin, > > On Jul 25, 2011, at 1:59, Talin wrote: > > > So far I'm really liking the new type system -- I've been able to > simplify my code generator in a number of areas. And the IR is now vastly > more readable, both in the debugger (using dump()) and when printing

Pending positive confirmation in http://llvm.org/PR2886, I'd recommend that r57974 and r57976 be pulled into the 2.4 release branch and configure regenerated there. Begin forwarded message: > From: Gordon Henriksen <gordonhenriksen at mac.com> > Date: October 22, 2008 08:40:40 EDT > To: llvm-commits at cs.uiuc.edu > Subject: [llvm-commits] [llvm] r57974 -

To answer my own question. The problem is that Solaris ships with very old tools, and llvmc was generating assembler that worked with a fresh (gcc-4.5) compile & install. I had them handy, just further down the path. Hopefully anyone with the same problem can find this in the archive. Thanks everyone. On Mon, Jan 31, 2011 at 10:56 AM, Lally Singh <lally.singh at gmail.com> wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tim, *! Thank you for posting your nice apache2 recipe to the wiki! It''s really good to see how others make things happen and a good example for others. One little thing though caught my notice because I''m currently making the same naughty thing on Simple Text Recipes. There is no ensure attribute. Since you already have done

On Fri, Mar 14, 2008 at 07:36:31PM +0100, Miroslav Lichvar wrote: > attached are patches that improve decoding speed a bit. The first > patch improves the bit scan macro used for decoding unary values, the > second one adds a GCC inline assembly for bswap and the third patch > replaces the read_rice_block function. The third patch has a bug causing reading past input buffer, attaching