similar to: [LLVMdev] -Qunused-arguments

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2574 Bug ID: 2574 Summary: configure: line 5805: syntax error near unexpected token `-Qunused-arguments' Product: Portable OpenSSH Version: 7.2p1 Hardware: amd64 OS: Linux Status: NEW Severity: critical Priority: P5

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

Am Mittwoch, den 05.03.2008, 23:03 -0800 schrieb Chris Lattner: > On Mar 3, 2008, at 2:49 AM, Joachim Durchholz wrote: > > > Hi all, > > > > I found enough to explain the behaviour that I encountered. If I'm > > correct, the bugs are just in the dejagnu-based test machinery, not in > > LLVM itself. > > Yep, I believe that. I haven't been

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

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

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

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

Here's a patch to fix some bugs in my code, plus a header file I probably forget to send in before. * Missing header file charset.h. It's not needed outside vorbis-tools/share, so I think it can live there. * There was a minor bug in the UTF-8 decoder utf8_mbtowc(). * I've added some more tests in charset_test.c in an attempt to convince myself that there aren't any more bugs.

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

Hi all. When building procstat I get this: clang -O2 -pipe -march=athlon-xp -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs

Hi all, I was installing a package *RBGL* of bioconductor. However, I had some issues while installing it. I asked the devel group of bioconductor and they told me to consult this group. Here is my conversation with the bioconductor group related to the problem *Me->* I was trying to install the RBGL package using the following command biocLite("RBGL") However, I got the

On Mar 3, 2008, at 2:49 AM, Joachim Durchholz wrote: > Hi all, > > I found enough to explain the behaviour that I encountered. If I'm > correct, the bugs are just in the dejagnu-based test machinery, not in > LLVM itself. Yep, I believe that. I haven't been following the whole thread very closely, what specific tests are affected here? Before making any significant and

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

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

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