search for: afaikt

HI All, Keep getting the following in the messages file: Feb 28 21:24:43 hp kernel: ACPI: Unable to turn cooling device [f7d82dec] 'on' Feb 28 21:25:13 hp last message repeated 5 times Have hordes of these. All fans are working fine afaikt. Any idea how to make the beast stop reporting these messages? I am running kernel 2.6.18-53.1.13.el5 #1 SMP. Thanks in advance, Phil

Hi Everyone. is there a need to have on searching the configuration file the request for the "odd ip addresses" ? Let me explain: from /doc/pxelinux.txt : ... Next, it will search for the config file using its own IP address in upper case hexadecimal, e.g. 192.0.2.91 -> C000025B (you can use the included progam "gethostip" to compute the hexadecimal IP address for

> > > I don't agree, but this is because I fail to see how the two > representations (the GCC-like one you've outlined and the current one with > the proposed extension) aren't completely isomorphic. Your proposal is: > > Lots of data structures are completely isomorphic in the same way, and in plenty of those cases, one is completely unusable, and the other

...anchored to a particular place in the CFG (and, importantly, not be hoisted or removed). This may be useful to convey at what point in the CFG some memory is dereferenceable, thus allowing, for example, sunk accesses to be re-hoisted. In your case, however, you don't need that information (AFAIKT). Instead, you just need to know that you can widen certain loads. This is valuable information, but it can be conveyed with metadata on the relevant loads. That would be a cheaper solution. If this seems impractical, I'd certainly like to understand why. (*) CodeMetrics has a way to collec...

We've been running a samba service for many years but have stuck using 3.0.24. Every version I tried after 3.0.24 seemed to have reliability problems. But if every version since 3.0.24 was broken I assume someone would have noticed by now :-). So I'm guessing we're doing somethng idiosyncratic and/or stupid.. The config we have is that our samba server (solaris) is getting uid/gid

Hi Hal, >Are you primarily concerned with being able to widen loads later in the pipeline? Could we attached metadata to the remaining loads indicating that it would be legal to widen them? no, I don't have any concerns about intrinsic way of implementation, and intrinsic way looks safer for me since we somehow detach our information about memory from that actual load instruction. I updated

...ut > any trouble. > > The access path language described in this proposal is more complex and > complete, and directly closer to access paths you find in C/C++. It has > bitfields, vtables, and unions. > > > It is more complex, but I think this is partly in the description. AFAIKT, > only "union" has special properties under the scheme. Bit fields, vtables, > etc. are all just particular types with no particular special rules. I > don't like special rules at all for any named entities, but as there's only > one such entity right now ("union...

...s exploited by LLVM, although as I recall, all implementations of posix_memalign and similar functions potentially run afoul of the rules (because they need to store the new pointer as a void* regardless of what it actually is). I'm not sure how strict we can be here in practice. Currently, AFAIKT, Clang emits TBAA metadata which does not differentiate between pointer types (it calls them all "any pointer"). > ), whereas aliasing a T* > through an arbitrary S** is probably a bug. > > Just for contrast: I'm familiar with this problem, and my way around > this c...

<just want to focus on these parts for a second. *All* of these representations are really access path representations, just encoded slightly different ways, and, as a result, with various parts of the rules in slightly different places> Imagine that we took the enhancement we previously discussed, but instead > of implementing it directly, we just directly encoded for every access the

Hello all, The topic of plugin dependencies has come up before and it doesn''t seem to have been addressed by core or core doesn''t seem to think it''s an issue. I''ve looked at the current edge code and don''t see anything new, so if I''ve missed something *please* let me know. The following article makes mention of a require_plugin

Hi everyone, At EuroLLVM, Chandler and I chatted about the design for a potential TBAA sanitizer. Here's my attempt to summarize: C/C++ have type-based aliasing rules, and LLVM's optimizer can exploit these given TBAA metadata added by Clang. Roughly, a pointer of given type cannot be used to access an object of a different type (with, of course, certain exceptions). Unfortunately,