similar to: [LLVMdev] Bug in TargetRegistry.h?

On Thu, Sep 8, 2011 at 12:12 AM, Max Kazakov <max.kazakov at gmail.com> wrote: > Hi, > > The code @ line 584 of TargetRegistry.h effectively suppresses specifying any > AsmStreamer constructor function but stock createAsmStreamer one. Is it by > intention or condition should be replaced with != ? Hi Max, are you sure that you have the tip-of-tree version of

Hi Ivan, Sorry for the confusion - in the latest version it is line 760: static void RegisterAsmStreamer(Target &T, Target::AsmStreamerCtorTy Fn) { if (T.AsmStreamerCtorFn == createAsmStreamer) T.AsmStreamerCtorFn = Fn; } Best regards, Max

Hello, I'm archiving a number of bitcode files via gold plugin based on LLVM 3.4. When I find a thumbv7 bitcode with a couple of module asms, I get a segfault in ARMAsmParser::parseDirectiveFnStart because getTargetStreamer returns NULL. Frankly, I don't see how this is supposed to work because as far as I understood LTOModule::addAsmGlobalSymbols only creates a RecordStreamer

Does anyone know what is the latest version of dom0-kernel, that supports fully xenpm hypercalls? I tried from 3.0 to 3.3 with xen-4.1.3, but none of them has xenpm working. On the other hand native kernel cpufreq is OK with all of them. My CPU is Xeon family 6 on PowerEdge 1950 III box. Regards, Dimitar Kazakov

Does anyone know what is the latest version of dom0-kernel, that supports fully xenpm hypercalls? I tried from 3.0 to 3.3 with xen-4.1.3, but none of them has xenpm working. On the other hand native kernel cpufreq is OK with all of them. My CPU is Xeon family 6 on PowerEdge 1950 III box. Regards, Dimitar Kazakov

Hi all, I am emitting code for assembler which wants non-standard text for labels (not just "LABEL:"). One way would be to override all methods of AsmPrinter which call MCStreamer::EmitLabel but this is too painful. I can think of two solutions: 1) add AsmPrinter::EmitLabel which calls Streamer by default but may be overriden in target AsmPrinters 2) Register my own instance of

Hi, Can someone tell me if my understanding is right in that post-RA scheduler currently assumes no limits on a pipeline's issue width? If so, is it by design or just overlooked? I have a case for, say, 1-issue pipeline when certain pipeline resource becomes occupied a few clocks after instruction start, but hazard evaluation is done incorrectly as scheduler advances clock not for every

Hello, ahgu >I have a unisys UPS, I probed the RS232 and notice that pin 2, >(receive data) is going from -6v (OL) to 12v(OB), but I don't see the >setting for the genericups. Seems nobody else is using the RD pin? >Any driver I can use? >Thanks >-Andrew Try RX as signal name (not RD). -- Best regards, Sergiy mailto:rendol@mail.zp.ua

Hello nut-upsuser, Hope, that its might be useful for someone: 1. Kebo UPS-600A Driver: genericups UPStype: 7 Config extras: SD = -RTS or SD = -TX (don't know why but both are suitable) 2. Kebo UPS-1200M Driver: fentonups Config extras: none Note: Looks like twin brother of Microlab UPS-1200M :) Driver ask me to report ID string: "Unknown

Hi and merry X-Mas! At initialization I add some targets (e.g. LLVMInitializeX86TargetInfo()). Is this guaranteed not to allocate memory to prevent memory leaks? If you use llvm in a plug-in then it is possible to load and unload the plugin. As there is no way to clear the target registry and I do not see a "new" at the first glance I assume it does not allocate heap memory. Is this

This is from https://stackoverflow.com/questions/48360685/no-targets-in-targetregistry I have the following code, which should get the default llvm::Target. auto const targetTriple = llvm::sys::getDefaultTargetTriple(); llvm_module.setTargetTriple(targetTriple); std::string error; auto const * target = llvm::TargetRegistry::lookupTarget(targetTriple, error); if (target ==

Hi All, While trying to put together an MC-based assembler the other day, I again encountered MC's non-obvious memory ownership rules. The most egregious example of these is MCObjectStreamer's destructor: MCObjectStreamer::~MCObjectStreamer() { delete &Assembler->getBackend(); delete &Assembler->getEmitter(); delete &Assembler->getWriter(); delete Assembler;

On Sep 18, 2010, at 8:14 AM, Yuri Gribov wrote: > Hi all, > > I am emitting code for assembler which wants non-standard text for > labels (not just "LABEL:"). One way would be to override all methods > of AsmPrinter which call MCStreamer::EmitLabel but this is too > painful. I can think of two solutions: > > 1) add AsmPrinter::EmitLabel which calls Streamer by

Hi Andrew, Thank you for explaining the situation. I also do understand that introducing "pseudo" resource locked by all instructions will fix the problem for 1-issue pipeline, but see it as a bit limiting for me at the moment. Anyway, the patch is attached. BR  m On Fri, May 27, 2011 at 1:54 PM, Andrew Trick <atrick at apple.com> wrote: > On May 26, 2011, at 7:29 PM, Max

The log snippet doesn''t have the detail in it - have a look in /var/log/SMlog - you might find something more useful in there. Jon On 5 Apr 2012, at 10:23, Dimitar Kazakov wrote: > Hi, > have permanent failure when try to create VDI on local SR type=file or > type=ext. On both types it failed with the same error: > SR_BACKEND_FAILURE_78 > VDI Creation failed

I checked recent revisions 138624 and 138620 and both produce this log with gcc-4.6.0 on FreeBSD-8.2-STABLE amd64: gmake[2]: Entering directory `/usr/home/yuri/llvm-svn/llvm-objects/lib/CodeGen' llvm[2]: Compiling LLVMTargetMachine.cpp for Release build /usr/home/yuri/llvm-svn/llvm/lib/CodeGen/LLVMTargetMachine.cpp:253:3: error: ‘AsmStreamer’ does not name a type

Chris Lattner wrote: > On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: > >>>> New method of emitting object code is ok for me. But it is still >>>> experimental, isn't it? >>> Yes. >> Thank you for answers! >> >> Now there is a way to implement what I'd like to. But it would be MUCH >> better if

Thanks! I found the problem in SMlog. /usr/sbin/td-util create vhd 1024 /var/run/sr-mount/4137dc90-4ad7-ecc6-dd2f-6f05ac280fc2/247b64e4-6b7f-4b2f-bd73-50e848c78d71.vhd /usr/sbin/td-util: error while loading shared libraries: libxenctrl.so.4.0: cannot open shared object file: No such file or directory td-util from blktap-utils 2.0.90-3 (testing) is looking for libxenctrl.so.4.0, but the package

On Mar 27, 2010, at 1:50 PM, Peter Shugalev wrote: > Chris Lattner wrote: >> On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: >> >>>>> New method of emitting object code is ok for me. But it is still >>>>> experimental, isn't it? >>>> Yes. >>> Thank you for answers! >>> >>> Now there is a way to implement

Hi Craig and Rail, At Movidius, we have had to make a few changes to ‘MCAsmStreamer’ to support our assembler which is not ‘gas’ compliant. Earlier versions of LLVM (3.1 and 3.2) did have a separate header for ‘MCAsmStreamer’, and we had previously sub-classed this. The following are modifications that we have had to make because although ‘MCAsmStreamer’ does most of what we need,