similar to: [LLVMdev] [PATCH] fix "32-bit shift" warning in MSVC

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

Daniel somehow replied to one of my previous commits on llvm-commits instead of this thread. On Mon, Jul 26, 2010 at 12:41 AM, Daniel Dunbar <daniel at zuster.org> wrote: > Hi Michael, > > Two minor notes: > -- >> diff --git a/lib/Target/X86/X86AsmBackend.cpp b/lib/Target/X86/X86AsmBackend.cpp >> index 2cf65c1..02ac2be 100644 >> ---

On Mon, Jul 26, 2010 at 7:25 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > Daniel somehow replied to one of my previous commits on llvm-commits > instead of this thread. > > On Mon, Jul 26, 2010 at 12:41 AM, Daniel Dunbar <daniel at zuster.org> wrote: >> Hi Michael, >> >> Two minor notes: >> -- >>> diff --git

I have been working on getting ELF object file writing working for the MBlaze backend. Currently, each supported backend calls ELFObjectWriter::createELFObjectWriter from within the backend's TargetAsmBackend::createObjectWriter method. The createELFObjectWriter method then creates a new backend specific ELFObjectWriter class (either X86ELFObjectWriter or ARMELFObjectWriter) by decoding a

On Fri, Jul 30, 2010 at 1:28 PM, Daniel Dunbar <daniel at zuster.org> wrote: > On Mon, Jul 26, 2010 at 7:25 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: >> Daniel somehow replied to one of my previous commits on llvm-commits >> instead of this thread. >> >> On Mon, Jul 26, 2010 at 12:41 AM, Daniel Dunbar <daniel at zuster.org> wrote:

In llvm/lib/MC/MachObjectWriter.cpp, there's assert(OS.tell() - Start == is64Bit() ? macho::Header64Size : macho::Header32Size); Shouldn't that be assert(OS.tell() - Start == (is64Bit() ? macho::Header64Size : macho::Header32Size)); MSVC emits a warning, and it doesn't seem right to compare a boolean with a difference of two integers. Csaba -- GCS a+

Hi, I've been slowly but steadily working towards enabling the Mach-O/PPC backend for MC, starting with the mach-o relocation entry translation. patches/logs: http://www.csl.cornell.edu/~fang/sw/llvm/ git: http://github.com/fangism/llvm/tree/powerpc-darwin8 git: http://github.com/fangism/clang/tree/powerpc-darwin8 I've managed to get the simplest single-function-call hello-world

On 26 July 2010 18:08, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Mon, Jul 26, 2010 at 12:04 PM, Aaron Gray <aaronngray.lists at gmail.com> > wrote: > > You probably want to add Cygwin and MinGW32 Triples as well :- > > case Triple::Win32: > > + case Triple::Cygwin: > > + case Triple::MinGW32: > > return new

On Mon, Jul 26, 2010 at 12:04 PM, Aaron Gray <aaronngray.lists at gmail.com> wrote: > You probably want to add Cygwin and MinGW32 Triples as well :- >    case Triple::Win32: > +  case Triple::Cygwin: > +  case Triple::MinGW32: >      return new WindowsX86AsmBackend (T); > Aaron Can someone test this on those platforms? That change would effect quite a few people. -

> Are there other names that are poor choices and are lingering in our > codebases? I'm willing to sign up to do more renames while I'm at > this, so this is a chance to get someone else to do the heavy lifting. > =] Class names too, not just file/directory names? I've been trolling through the integrated assembler lately, and had a real "can't tell the players

+llvmdev On Fri, Nov 12, 2010 at 7:57 AM, Jim Grosbach <grosbach at apple.com> wrote: > > On Nov 10, 2010, at 9:57 AM, Jason Kim wrote: > >> Refactoring the x86 dependent code from ELFObjectWriter class has >> repercussions among several (conflicting) axes of consideration, >> >> 1. namespace pollution - minimize pollution of the llvm:  namespace >> 2.

Dear R-experts! I am currently running a meta-analysis with the help of the great metafor package. However I have some difficulties setting up my raw data to enter it to the meta-analysis models. I have a group of subjects that have been measured in two continuous variables (A & B). I have the information about the mean of the two variables, the group size (n) and the standard deviations of

On Fri, Jul 30, 2010 at 11:05 AM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Fri, Jul 30, 2010 at 1:28 PM, Daniel Dunbar <daniel at zuster.org> wrote: >> On Mon, Jul 26, 2010 at 7:25 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: >>> Daniel somehow replied to one of my previous commits on llvm-commits >>> instead of this thread.

Some boring style comments: - whack trailing whitespace - spaces, not tabs - the methods in MCJITStreamer.cpp should probably have blank lines between them There seems to be an ownership problem of the MCJITObjectWriter. If I understand the code correctly, the assembler Finish method takes ownership of the Writer parameter, which presumably is needed to JIT two functions. +1 for separate

> In the context of the JIT, there really is no such thing as a > relocation, just fixups. I'm not completely sure what the right > approach is, but the JIT should be able to fully resolve all of the > symbols that are being used in the module. We may need some extra > interfaces to allow the JIT to tell the MCAssembler about the address > of some external symbols though.

Hello, I'm compiling LLVM with MSVC at the moment, I've got the following warning: BitstreamReader.h(327) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) in line uint64_t Piece = Read(NumBits); if ((Piece & (1U << (NumBits-1))) == 0) Is this warning relevant? Is also Read64()

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

Together with Jan Sjodin (in copy of this email), we begin an implementation of the JIT with MC. The idea, suggested by Jan, is to develop a MCJIT in parallel of the current JIT and to keep the two implementations until (at least) the new MC one is mature enough. Currently code is kept on gitorious (http://gitorious.org/llvm-mc-jit/llvm-mc-jit). Following this, a boolean "bool MCJIT =

I have a warning when building with MSVC2k5, a benign warning, but I am trying to get rid of them. ..\..\..\..\trunk\lib\Transforms\Utils\AddrModeMatcher.cpp(208) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) The line of code is: Scale = 1 << Scale; Where Scale is an int64_t, however, 1 is an int32_t (since

I have a warning when building with MSVC2k5, a benign warning, but I am trying to get rid of them. ..\..\..\..\trunk\lib\Transforms\Utils\AddrModeMatcher.cpp(208) : warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) The line of code is: Scale = 1 << Scale; Where Scale is an int64_t, however, 1 is an int32_t (since