similar to: Is MCRelocationInfo::createExprForRelocation used out of tree?

Deleting LGTM. It is a leftover of MCAnalysis. Cheers, Rafael On 14 January 2016 at 16:54, Pete Cooper <peter_cooper at apple.com> wrote: > Hi Jim, Rafael > > As respective code owner and frequent committer to MC, any thoughts on this? > > Cheers, > Pete >> On Jan 12, 2016, at 1:07 PM, Pete Cooper <peter_cooper at apple.com> wrote: >> >> Hi all

Seems to be largely untested... anyone using this? (cc'ing Kevin as he's the most likely candidate). At the least for MCAnalysis this appears to be unused, any ideas on what else can be deleted? I'll remove just this file unless there are objections tomorrow (or earlier if I get an ack from Kevin about it). -eric

Oops sorry. lib/MC/MCAnalysis/MCObjectDisassembler.CPP Thanks. -eric On Jul 31, 2014 1:21 PM, "Kevin Enderby" <enderby at apple.com> wrote: > Eric, what file are your referring to? The path > lib/MC/MCObjectDisassembler does not end in a .cpp or .h and is not a > directory . > > Just a bit more info and I can get back to you if I’m using what your > asking

Any chance of adding some missing test coverage here? That code was dead (& evidently untested) before... On Thu, Jul 31, 2014 at 11:37 AM, Eric Christopher <echristo at gmail.com> wrote: > I believe you are correct. Fixed thusly: > > dzur:~/sources/llvm> git svn dcommit > Committing to https://llvm.org/svn/llvm-project/llvm/trunk ... > M

my compiler gave me a warning in MCObjectDisassembler.cpp. it found a self-comparation in loop condition. I think it's a typo. the suspicious code was introduced by this patch: >From f176482752fbea3139394e280adfb10270dd3aac Mon Sep 17 00:00:00 2001 From: Ahmed Bougacha <ahmed.bougacha at gmail.com> Date: Wed, 21 Aug 2013 07:28:55 +0000 Subject: MC CFG: Support disassembly at

Hi Gents, For those of us with out-of-tree backends which are not 32bit, the msp430 backend is a useful vehicle for examining changes and testing out ideas. So I was wondering about enabling debug output on the MSP430 backend so that I can illustrate a few issues to Adrian and you on the variable pieces side. (there doesn't appear to be any specific person claiming the msp430 code right

Hi, I've run Clang Static Analyzer checker alpha.cplusplus.NewDeleteLeaks over LLVM codebase to detect false-positives and at the same time eliminate memory leaks. The majority of leaks were detected in lib/Target/* and lib/MC/*. In all cases the similar trick was detected as a leak (example from lib/Target/Sparc/MCTargetDesc/SparcMCTargetDesc.cpp) : static MCStreamer

This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 It also fixes a test which was requiring the *wrong* output. I'm relatively happy with this part, and it even solves most of the hard part of feature request for .code16 in bug 8684 — which was actually why I started prodding at this. But I could do with some help with the 16-bit signed relocation handling, which I've

File: trunk/llvm/lib/Target/Hexagon/CMakeLists.txt set(LLVM_TARGET_DEFINITIONS Hexagon.td) tablegen(LLVM HexagonGenRegisterInfo.inc -gen-register-info) tablegen(LLVM HexagonGenInstrInfo.inc -gen-instr-info) tablegen(LLVM HexagonGenAsmWriter.inc -gen-asm-writer) tablegen(LLVM HexagonGenDAGISel.inc -gen-dag-isel) tablegen(LLVM HexagonGenCallingConv.inc -gen-callingconv) tablegen(LLVM

Hello, I run into a problem that llvm can't write the correct ELFHeaderEFlags for hexagonv4. The following patch can fix it. Index: lib/Target/Hexagon/MCTargetDesc/HexagonMCTargetDesc.cpp =================================================================== --- lib/Target/Hexagon/MCTargetDesc/HexagonMCTargetDesc.cpp (revision 265917) +++

Hi This patch fixes code generation bug - 586-class CPUs don't support the nopl instruction and some 686-class CPUs don't support it too. I created bug 17792 for that. BTW. I think you should also optimize padding on these CPUs - instead of a stream of 0x90 nops, you should generate variants of "lea (%esi), %esi" instruction like gcc. This patch disables generation of

Hi, I'm from Intel compiler department. I am proposing the integration of a backend targeting Nios II processor architecture. Nios II is a 32-bit general-purpose RISC processor core designed specifically for the Altera family of FPGAs. All information at about Nios II can be found at Altera website https://www.altera.com/products/processors/support.html, including the current ISA

hi, i just try to build llvm-3.0 (stable) on linux ppc32 (CRUX PPC 2.7) with gcc-4.5.3, binutils-2.21.1, glibc-2.12.2 . As this suggestion: http://llvm.org/bugs/show_bug.cgi?id=10969 I applied a patch like this one: --- llvm-3.0.src/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.h 2011-07-26 01:24:55.000000000 +0200 +++ llvm-3.0.src/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.h

On Tue, Feb 24, 2015 at 1:09 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Tue Feb 24 2015 at 1:03:43 PM Keno Fischer < > kfischer at college.harvard.edu> wrote: > >> Hello everyone, >> >> in http://reviews.llvm.org/D7696 bhushan added a mips64 UnwindAssembly >> plugin (a plugin that looks at assembly code to find out how to unwind

I am having an issue with MCJIT on the ppc64 machine architecture. The symptom is that for a particular IR function the target machine won't emit neither an object nor an assembly file and subsequent calling the pointer to function results in a segfault. My application generates on the fly several functions with the builder and executes them with the MCJIT engine. I came across this

Mehdi, Teresa, Not sure if this is caused by one of your recent commits, or by someone else's, please excuse me if that's unrelated to your work... http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/542/steps/check-llvm%20asan/logs/stdio ==26383==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x000002ef41d8 at pc 0x0000009d1aa5 bp 0x7ffd0cd72b50 sp

My apologies. Shouldn't it just be removed since it is now in a subdirectory? On 12/15/2011 11:38 PM, Marc J. Driftmeyer wrote: > File: trunk/llvm/lib/Target/Hexagon/CMakeLists.txt > > set(LLVM_TARGET_DEFINITIONS Hexagon.td) > > tablegen(LLVM HexagonGenRegisterInfo.inc -gen-register-info) > tablegen(LLVM HexagonGenInstrInfo.inc -gen-instr-info) > tablegen(LLVM

Nico, There is a third place that '#undef PPC' is needed (at the top of PPCFixupKinds.h). Alternatively, you can run configure with -UPPC in your CPPFLAGS. I'll try to get this fixed in trunk shortly. -Hal On Fri, 2011-12-02 at 12:30 +0100, acrux_it at libero.it wrote: > hi, i just try to build llvm-3.0 (stable) on linux ppc32 (CRUX PPC 2.7) with > gcc-4.5.3, binutils-2.21.1,

On Fri, 2011-12-02 at 06:58 -0600, Hal Finkel wrote: > Nico, > > There is a third place that '#undef PPC' is needed (at the top of > PPCFixupKinds.h). Alternatively, you can run configure with -UPPC in > your CPPFLAGS. I'll try to get this fixed in trunk shortly. I just tested this, and I was wrong: passing -UPPC to configure in CPPFLAGS does not work for some reason.

Please include a testcase with the patch. gas uses " nopl 0x0(%eax)" for k6_2. Are you sure it is a gas bug? On 3 November 2013 13:50, Mikulas Patocka <mikulas at artax.karlin.mff.cuni.cz> wrote: > Hi > > This patch fixes code generation bug - 586-class CPUs don't support the > nopl instruction and some 686-class CPUs don't support it too. > > I