search for: libdummi

Dear NUT users and developers, Like the other years, before taking a small rest, here are some news related to NUT. * First, you should have seen the 2.0.5-pre1 release announcement. I don't think 2.0.5 is very far, but I realized that I've made an archive including the .svn directory (bad, bad me. I should know that release are made against exported svn, not checked out!) * Next,

Dear NUT users and developers, Like the other years, before taking a small rest, here are some news related to NUT. * First, you should have seen the 2.0.5-pre1 release announcement. I don't think 2.0.5 is very far, but I realized that I've made an archive including the .svn directory (bad, bad me. I should know that release are made against exported svn, not checked out!) * Next,

On Wed, 21 Jul 2004, Chris Lattner wrote: > > Yes, this makes a tremendous amount of sense. Do you think you could > prepare some patches to make this happen? If you have any questions, feel > free to ask :) Ok, a patch[1] is attached. I didn't care to coerce the offset, since I assume that it is an uint, but maybe I should? Hopefully I've understood the llvm source

How can I do function profiling and BB profiling with current llvm and llvm-gcc4? runtime/libprofile is disabled when using llvm-gcc4, but... is there any alternative to linking with libprofile_rt.so? How can I use llvm-prof? is utils/profile.pl obsolete? Thanks in advance, josem

On Mon, 10 Sep 2007, Jose M. Moya wrote: > How can I do function profiling and BB profiling with current llvm and > llvm-gcc4? > > runtime/libprofile is disabled when using llvm-gcc4, but... is there any > alternative to linking with libprofile_rt.so? > > How can I use llvm-prof? is utils/profile.pl obsolete? The profiling support in LLVM hasn't been used for quite a

El lun, 10-09-2007 a las 11:55 -0700, Chris Lattner escribió: > The profiling support in LLVM hasn't been used for quite a while, so it > may have bitrotted slightly. However, the support should basically work, > so it shouldn't take much to bring it back to life. Thank you, it seems working again with this simple patch: Index: runtime/Makefile

Hello, At 09:24 -0400 on 2014-5-23 Charles Lepple wrote: > > See attached. Still doesn't have the writable V_interval values, > but I probably won't have time to test that until later. Thank you for the patch. > Don't worry about the battery physical properties for now - the > problem there is that we don't have enough information from the UPS > to do a

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Hi, I'm thinking out loud, please give me some feedback. > > Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are > implemented as: > > llvm.gcread(sbyte** object, uint offset) > llvm.gcwrite(sbyte* data, sbyte** object, uint offset) > > Where you also have the offset into the object. In

Ok, that makes sense :). , Tobias On Wed, 21 Jul 2004, Chris Lattner wrote: > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > return *FieldPtr; > > > } > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > cases? > > For the field pointer, one

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > return *FieldPtr; > > } > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > cases? For the field pointer, one could use the getelementptr instruction: %pairty = { sbyte, sbyte, int* } %pairPtr = ... %fieldptr = getelementptr

Ok, here's the new patch. (Please tell me if I shouldn't mail patches directly on the mailing list.) While I was editing LowerGC.cpp I made a little test (not part of this patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer directly instead and transforms it into an alloca. The idea is the

Aaron, Could you send me the libiberty.a file? Please gzip it. I would like to make sure this isn't an llvm-ranlib bug. Thanks, Reid. On Thu, 2005-05-19 at 15:36 +0100, Aaron Gray wrote: > Hi, > > Got everything built but am now experiencing new errors on making the > symbol tables and on 'make check'. > > Here's the errors I am experiencing :- > >

On May 22, 2014, at 10:03 AM, Stefan Bruda wrote: >> >> Does battery_voltage_nominal get set correctly? Theoretically, it >> should be 48, since the 2nd and 3rd digits of ups.debug.V are 08, >> and that gets multiplied by 6. > > Yes, as it appear as 48V in the output of upsc. Good. > >> Might be useful to have an intermediate value that doesn't scale

Hi, Got everything built but am now experiencing new errors on making the symbol tables and on 'make check'. Here's the errors I am experiencing :- Aaron Gray at AMD-LAPTOP-1 /usr/llvm-gcc/lib $ ls gcc libdummy.a libiberty.a libstdc++.a libsupc++.la libc.a libgcc.a libm.a libstdc++.la libtrace.a libcrtend.a libgcsemispace.a

Hello, At 22:19 -0400 on 2014-5-19 Charles Lepple wrote: > > On May 19, 2014, at 7:12 PM, Stefan Bruda wrote: > > > Therefore as far as my UPS is concerned s_value[5] is wildly > > incorrect. > > So it turns out that the RM15002U also does not report anything useful for s_value[5]: > >