similar to: bug fixes in vorbis-tools/share

Here's a propsed heavy-duty solution for your UTF-8 problems. I'm including a patch in this message, but I'll put the new files on my web site at http://rano.org/tmp/xiph_files.tar.gz I've tested this by running vorbiscomment with and without -DHAVE_ICONV=1 in vorbis-tools/share/Makefile. It seems to work. Changed files: acinclude.m4: Add a test for nl_langinfo(CODESET). This

I just got this error message from the GNU assembler: Error: alignment too large: 15 assumed Which made me laugh at first. The corresponding input line was: .align 16 Apparently what's going on here is that ".align 16" is ambiguous: on some architectures it means ".balign 16", and on some it means ".p2align 16", which would mean ".balign 65536" if

I'm getting a lot of this from make check: g++: unrecognized option `-Qunused-arguments' This presumably comes from commit 94666 (test/LLVMC/ExternOptions.td and other files). That option is specific to clang, isn't it? Should %compile_cxx be picking up clang instead of my system's g++? -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and

According to the few tests I did, .ll.gz is more compact: 1.00 LLVM bitcode (.bc) 0.80 Gzipped LLVM bitcode (.bc.gz) 4.13 LLVM assembly (.ll) 0.68 Gzipped LLVM assembly (.ll.gz) However, there's not much in it, considering that a stripped native binary is about 0.40 on the same scale. So, seeing as projects such as PNaCl want to send LLVM bitcode over the network, are there any proposed

I think this test case demonstrates it: ; RUN: llc -march=thumb -mcpu=cortex-a8 -mtriple=thumbv7-eabi -float-abi=hard < %s | FileCheck %s define <4 x i64> @f_4_i64(<4 x i64> %a, <4 x i64> %b) nounwind { ; CHECK: vadd.i64 %y = add <4 x i64> %a, %b ret <4 x i64> %y } (I hope I got that right.) -- IMPORTANT NOTICE: The contents of this email and any

The log message for revision 122213 says: > Change the X86 backend to stop using the evil ADDC/ADDE/SUBC/SUBE nodes (which > their carry depenedencies with MVT::Flag operands) and use clean and beautiful > EFLAGS dependences instead. (MVT::Flag has since been renamed to MVT::Glue.) That revision made bug 8404 go away. Am I right in thinking that one of the problems with MVT::Glue is

I don't think this has ever worked. Evan On May 13, 2010, at 10:03 AM, Edmund Grimley-Evans wrote: > I think this test case demonstrates it: > > ; RUN: llc -march=thumb -mcpu=cortex-a8 -mtriple=thumbv7-eabi -float-abi=hard < %s | FileCheck %s > > define <4 x i64> @f_4_i64(<4 x i64> %a, <4 x i64> %b) nounwind { > ; CHECK: vadd.i64 > %y = add <4

It used to. I just checked with r90370. deep On Thu, May 13, 2010 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> wrote: > I don't think this has ever worked. > > Evan > > On May 13, 2010, at 10:03 AM, Edmund Grimley-Evans wrote: > >> I think this test case demonstrates it: >> >> ; RUN: llc -march=thumb -mcpu=cortex-a8 -mtriple=thumbv7-eabi

Could some kind soul point me at the documentation, or the appropriate header file, or an example of the best way to write a pass that modifies the IR? Suppose, for example, that I wanted to replace every call to the intrinsic i1 with a call to i2 followed by a call to i3: i1(X) -> i3(i2(X)) I'm currently playing around with a class that inherits from FunctionPass and InstVisitor and I

> Having a look at clang's source, you can find in > "lib/CodeGen/BackendUtil.cpp" the functions where clang builds the > passes to emit code. The optimization passes used are there and you can > simulate them via the "opt" utility, by running each pass one at a time. > LLVM also declares standard module/function passes on >

With a modified copy of LLVM (so it's probably my fault) I'm getting an assertion failure because isTwoAddrUse (in TwoAddressInstructionPass.cpp) is being called with a MachineInstr MI such that MI.getNumOperands() is 2, but MI.getDesc().getNumOperands() is 5. The assertion fails when that function calls MI.getOperand(2). My question is: is isTwoAddrUse doing the right thing here? static

Using GCC 3.4.6 20060404 (Red Hat 3.4.6-11) I've had this problem with the ALWAYS_INLINE directive in SelectionDAGISel.cpp: /arm/scratch/egrimley/llvm.svn/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp: In function `bool CheckChildType(const unsigned char*, unsigned int&, llvm::SDValue, const llvm::TargetLowering&, unsigned int)':

My experimental code calls DAG.getNode to construct a unary node with a flag result. Unfortunately the argument turns out to be constant, so lib/CodeGen/SelectionDAG/SelectionDAG.cpp:2332 calls VT.getSizeInBits on the flag type, which isSimple(), so we call V.getSizeInBits at ValueTypes.h:560 and fail at ValueTypes.h:240: clang: .../include/llvm/CodeGen/ValueTypes.h:240: unsigned int

Hello. Attached are some patches that some Debian users of vorbis-tools have sent to our BTS over the years (numbers refer to Debian bugs). It'd be nice to see them integrated. They apply cleanly to SVN as of today. The largefile_support one is a bit bigger than just the configure.ac since the submitter adviced that config.h got included in all C source files before the standard includes,

Hello. Attached are some patches that some Debian users of vorbis-tools have sent to our BTS over the years (numbers refer to Debian bugs). It'd be nice to see them integrated. They apply cleanly to SVN as of today. The largefile_support one is a bit bigger than just the configure.ac since the submitter adviced that config.h got included in all C source files before the standard includes,

When I'm trying to understand how or why the back end does something I've found the -view-* options to llc to be useful. It's not ideal, because "clang" doesn't take those options, so I have to invoke first "clang" and then "llc", and sometimes that combination gives different final code from invoking just "clang", but usually I can construct

Assuming you're working with an ARM target, you may also hit a problem with the alignment option on the .comm directive. Attached is a first-cut patch for this latter problem. deep On Mon, Jan 25, 2010 at 5:42 PM, Edmund Grimley Evans <Edmund.Grimley-Evans at arm.com> wrote: > I just got this error message from the GNU assembler: > > Error: alignment too large: 15 assumed

2010/1/25 Edmund Grimley Evans <Edmund.Grimley-Evans at arm.com>: > I just got this error message from the GNU assembler: > > Error: alignment too large: 15 assumed > > Which made me laugh at first. The corresponding input line was: > >        .align  16 > > Apparently what's going on here is that ".align 16" is ambiguous: on > some architectures

On Tue, 14 Dec 2010 10:55:09 -0000 "Edmund Grimley-Evans" <Edmund.Grimley-Evans at arm.com> wrote: > According to the few tests I did, .ll.gz is more compact: > > 1.00 LLVM bitcode (.bc) > 0.80 Gzipped LLVM bitcode (.bc.gz) > 4.13 LLVM assembly (.ll) > 0.68 Gzipped LLVM assembly (.ll.gz) > > However, there's not much in it, considering that a

Hi all, I added -Wmissing-prototypes -Wstrict-prototypes to the CFLAGS and found that there were a number warnings generated. The patch below fixes those warnings and adds the two -W flags to configure.in. Cheers, Erik ----------------------8<----------------------8<---------------------- --- src/metaflac/operations_shorthand.h 1970-01-01 00:00:00 +0000 +++