similar to: [LLVMdev] Problem linking and JITing code through C++-API

Yes. It appears that a bad reference to DataLayout was passed to MachineJumpTableInfo::getEntrySize. I'm using LLVM as a pre-compiled Ubuntu package for this work, so I can't do much more in GDB without building from source. Program received signal SIGSEGV, Segmentation fault. 0x00000000007565f0 in llvm::MachineJumpTableInfo::getEntrySize(llvm::DataLayout const&) const () (gdb)

Hi Andy, It looks like you're using LLVM's old JIT, rather than MCJIT? The old JIT has been removed from the mainline, and is no longer supported. I'd recommend building your own copy of LLVM from the development branch (as Reed suggested) where MCJIT is used by default - this may fix your issue. If you want to stick with the precompiled binaries, then you should change: #include

Hi guys, I have written a rails plugin/gem to generate css sprite image automatically. The project repository is here: http://github.com/flyerhzm/css_sprite It is based on RMagick and you need only define a rule from what source images to a destination image, as follows: forum_icon_vertical.gif: # destination image file sources: # source image file list - good_topic.gif

Running "rake assets:clobber assets:precompile" will generate files like "application-xxx.css" with incorrect urls after upgrading to Rails 4. For example url(/fields/xxx.png) when it should be url(/assets/fields/xxx.png). For some unknown reason it worked once in development mode, but after running rake assets:clobber I can''t get it to work again... Any ideas

Dear all, Below is some code where I try to get plotmath symbols in an rgl plot. Duncan Murdoch kindly suggested to use a "sprite" for this. As you can see, on can get it to work, but my knowledge about grid and rgl is too limited to perfectly solve the problem. 1) As you can see (please rotate the plot a little bit so that (0,0,0) is "in front"), the quality of the .png

I was trying to run one of my kids favourite games with Wine, alas it crashes accessing a null pointer, early on while loading one of the sprite files (not corrupted). I guess the program should be doing better memory checking but since this works on Windows, maybe Wine has fed him before some broken data. Unfortunately, the terminal output doesn't seem much helpful:

Hi Jay - I see the slow, small accesses using an older clang [Apple LLVM version 7.0.0 (clang-700.1.76)], but this looks fixed on trunk. I made a change that comes into play if you don't specify a particular CPU: http://llvm.org/viewvc/llvm-project?view=revision&revision=245950 $ ./clang -O1 -mavx copy.c -S -o - ... movslq %edi, %rax movq _spr_dynamic at GOTPCREL(%rip),

So this is the original code I used, and it worked send_file ''vendor/sprites/not-found.png'', {:filename => "sprite-not-found.png", :type => "image/png", :disposition => "inline"} Now I switched it to this (going to be adding imageMagick) send_data File.read(''vendor/sprites/not-found.png''), {:filename =>

On Thu, Jul 30, 2009 at 05:44:05PM +0200, Andreas Neustifter wrote: > Well it does look not too good the text is getting to small in this > case, what do you think of this 128x128 version? It looks like an sprite coming from a Megaman game :). My humble opinion is that while the dragon looks nice when large, when small it just feels childish and unprofessional. My 2 cents. -- Felipe.

Ignore the suggested fix in my earlier post. How about this? diff --git a/lib/Target/X86/X86ISelLowering.cpp b/lib/Target/X86/X86ISelLowering.cpp index 20c81c3..b8ebf42 100644 --- a/lib/Target/X86/X86ISelLowering.cpp +++ b/lib/Target/X86/X86ISelLowering.cpp @@ -1632,10 +1632,11 @@ X86TargetLowering::X86TargetLowering(const X86TargetMachine &TM, if (!Subtarget.is64Bit()) { // These

Looks like I have run into the same issue reported in: https://bugs.llvm.org/show_bug.cgi?id=20871 Is there a fix or work-around for it? The bug report seems to be still open. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/46c1282d/attachment.html>

On Tue, Jun 7, 2016 at 1:57 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Tim, > > Currently, I have to do multiple things: > > 1) create some setLibcallNames in XXXISelLowering.cpp to generate correct > naming for RTLIBS. > 2) lower ISD down to an RTLIB for some calls (and then do solution 1 on > those to get correct names) These solve a related but different -

Tim, Are you referring to setLibcallName? That is target specific yes but there isn't RTLIB for most of the libm functions, for example, for acos this doesn't apply. Ideally what I would like is to create a libc with functions like acos called something like __xxx_acos that can still be recognized to be optimized. RTLIB is pretty limited but it works fine, I can just use

Use a better icon for RHEL guests, still provided by redhat-logos (or equivalent in downstream distributions), and which fits a better definition of logo for the distribution. Thanks to Ray Strode for the hints. --- lib/inspect-icon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/inspect-icon.c b/lib/inspect-icon.c index e785a2172..5c7da0476 100644 ---

LLVM appears to support Library functions for ISD::SRA ,ISD::SHL, and ISD::SRL, as they are properly defined in RuntimeLibCalls.def. The library functions defined in RuntimeLibCalls.def (among others) are these: HANDLE_LIBCALL(SRA_I16, "__ashrhi3") HANDLE_LIBCALL(SRA_I32, "__ashrsi3") HANDLE_LIBCALL(SRA_I64, "__ashrdi3") However, setting

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

If I do T.getArch() == xxx TLI.setUnavailable(LibFunc::copysign) then this works at generating a call instead of not being able to select the ISD::FCOPYSIGN, but I don't know why I don't need to do this for other LibFunc functions (such as floor, etc... these generate call just fine)? Thanks, Ryan On Tue, Jun 14, 2016 at 11:58 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:

libswfdec/Makefile.am | 2 libswfdec/swfdec_root_movie.c | 10 +- libswfdec/swfdec_root_sprite.c | 178 ----------------------------------------- libswfdec/swfdec_root_sprite.h | 65 -------------- libswfdec/swfdec_swf_decoder.c | 64 ++++++++++++++ libswfdec/swfdec_swf_decoder.h | 20 ++++ libswfdec/swfdec_tag.c | 65 ++++++++++++++ 7 files changed, 149

On 1/30/15 1:17 PM, Saleem Abdulrasool wrote: > Although this has been discussed in the past, I think that given a few > conversations, it seems that it unfortunately needs to be brought up again. > > There seems to be some disagreement over the ideal location of the > unwinder (libunwind). Currently, libunwind resides in a subdirectory of > libc++abi. There seems to be some