similar to: Segfault in llc 3.8.0 building GHC

I found a fix! The first hunk of https://reviews.llvm.org/D17533 (lib/CodeGen/TargetFrameLoweringImpl.cpp) on top of 3.8.1 does the trick. Does llvm do patch releases of old versions? Davide Italiano <davide at freebsd.org> writes: > On Fri, Oct 21, 2016 at 6:19 AM, Shea Levy via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi all, >> >> I'm hitting

Hello, I've compiled today's LLVM on ARM/Linux machine and attempted to use our GHC/ARM port (which is using LLVM as a backend for generating machine code) with it but I've failed in compiling GHC alone as LLVM fails on me with following message: llc: /export/home/karel/vcs/llvm-ghc-arm/lib/CodeGen/MachineInstr.cpp:612: void llvm::MachineInstr::addOperand(const

Hi Karel, Mind trying again with current top of tree? Owen's fixed a few things today that were manifesting with that error. -Jim On Aug 29, 2011, at 2:33 PM, Karel Gardas wrote: > Hello, > > I've compiled today's LLVM on ARM/Linux machine and attempted to use our GHC/ARM port (which is using LLVM as a backend for generating machine code) with it but I've failed in

Hi Jim and Eric! thanks a lot for your fantastically fast reply. I'm going to update and will report tomorrow when all the building is done. Thanks! Karel On 08/29/11 11:36 PM, Jim Grosbach wrote: > Hi Karel, > > Mind trying again with current top of tree? Owen's fixed a few things today that were manifesting with that error. > > -Jim > > On Aug 29, 2011, at 2:33

Hello, Would it be feasible to use the internal lld file format as the native executable format for an OS? Are there performance or space considerations that would make this a poor choice? Cheers, Shea Levy P.S. please CC me on replies, I'm not subscribed.

On 05/02/2012 01:00 PM, Dave Zarzycki wrote: > Shea, > > Feasible? Sure, anything is feasible. A good idea? Not really. The internal lld file format is an _intermediate_ data structure designed to make creating the final executable straightforward and fast. It isn't designed to be an executable format itself. In fact, the reason why linkers can often be slow is because the

Shea, Feasible? Sure, anything is feasible. A good idea? Not really. The internal lld file format is an _intermediate_ data structure designed to make creating the final executable straightforward and fast. It isn't designed to be an executable format itself. In fact, the reason why linkers can often be slow is because the intermediate and final object file formats are conflated. davez On

On 10/19/11 11:58 PM, Eli Friedman wrote: > On Wed, Oct 19, 2011 at 8:20 PM, Shea Levy<shea at shealevy.com> wrote: >> 2. Are target-specific behaviors documented for each supported target? > When anything has target-specific behavior, that fact should be > documented. Beyond that, if you have a question about what some > construct is supposed to do, please ask. What I

On 12/19/11 7:19 PM, Howard Hinnant wrote: > On Dec 19, 2011, at 7:14 PM, Shea Levy wrote: > >> Hello all, >> >> Is it possible, if using libc++ and compiler-rt, to have a clang with no >> runtime dependencies on any GCC components on Linux? If not, will this >> ever be possible? > We are working on a new libc++abi: http://libcxxabi.llvm.org/ which carries

Postgres database. I have a categories table, with two columns id, and name. I have a recipes table, with a category_ids column. I want each recipe to belong to one or more category. in recipe_controller.rb I have this: def create @recipe = Recipe.new( @params[''recipe''] ) @recipe.category_ids = @params[''recipe''][''category_ids''].map{

Thought I would share this with you guys, it brought a smile to my face this morning... So, I work for a quick American company who I won''t name, and for the past few months I have been pushing to use AJAX in some of our Web applications. This looks like its finally happening, and we are using it in an upcoming project. There was a meeting about it yesterday, which unfortunately I

Hello, I'd like write a program that performs static analysis of code at the LLVM assembly/bitcode level, and to do so I plan on extensively referencing the language reference. As I hope to eventually use this tool as part of a security analysis of untrusted code, I need to be rather strict in my interpretation of the document. As such, I have some questions about how the implementers

On Wed, Oct 19, 2011 at 8:20 PM, Shea Levy <shea at shealevy.com> wrote: > Hello, > > I'd like write a program that performs static analysis of code at the > LLVM assembly/bitcode level, and to do so I plan on extensively > referencing the language reference. As I hope to eventually use this > tool as part of a security analysis of untrusted code, I need to be >

All, I would like to submit the attached patch, which allows the GHC (Glasgow Haskell Compiler) calling convention to work on ARM targets. Could some nice person please review this code, so I can move towards getting it committed? I have thoroughly tested this patch again GHC on a Debian-ARM (armel) system. Unfortunately my understanding of LLVM is limited, so it's likely I'm not

Hi David, > Any word on this making 3.0? 3.0 already branched, and since this is not a regression, this will most probably go into 3.1. Maybe Bill (CC'ed) being the release manager has other opinion on this. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi Karel, I understand this patch has already been merged (to 3.0), so don't take my question as stopping the merge to head, I'm just making sure I got it right... The rest looks correct. + CCIfType<[v2f64], CCAssignToReg<[Q4, Q5]>>, + CCIfType<[f64], CCAssignToReg<[D8, D9, D10, D11]>>, + CCIfType<[f32], CCAssignToReg<[S16, S17, S18, S19, S20, S21, S22,

Hi Steve, I'm not an LLVM developer but am the author/maintainer of the LLVM backend in GHC. The patch looks mostly good to me (although I am not that familiar with ARM so could easily have missed something). My main concern is why are you avoiding using the R0 - R3 registers? Also, could you please update me on the status of this work. I assume you are getting GHC running in registerised

Hi all, As previously mentioned on this list the Haskell compiler GHC has a new LLVM based back-end. The back-end needs a new calling convention to efficiently use LLVM and that is what this patch does, just for X86 at the moment. Breakdown: 1) Need actual calling convention Touches: - include/llvm/CallingConv.h - lib/Target/X86/X86CallingConv.td 2) Handling new calling

Hi Duncan, > const unsigned* > ARMBaseRegisterInfo::getCalleeSavedRegs(const MachineFunction *MF) const { > + bool ghcCall = false; > + > + if (MF) { > + const Function *F = MF->getFunction(); > + ghcCall = (F ? F->getCallingConv() == CallingConv::GHC : false); > + } > This bit looks dubious. Why do you need to do it? What exactly? We need

On Mar 2, 2010, at 5:33 PM, David Terei wrote: > Hi all, > > As previously mentioned on this list the Haskell compiler GHC has a new LLVM based back-end. The back-end needs a new calling convention to efficiently use LLVM and that is what this patch does, just for X86 at the moment. Nice, > The GHC developers would love to get this included in LLVM so that we don't need to