search for: subtlely

Kernel news :) ---------- Forwarded message ---------- To: opensuse-offtopic <opensuse-offtopic at opensuse.org> From: Basil Chupin <blchupin at iinet.net.au> Subject: [opensuse-offtopic] Linus Torvalds delays Linux 3.0 launch due to a subtle bug *LINUX FOUNDER* Linus Torvalds has said that he's delaying the release of Linux 3.0 due to the discovery of a bug. Torvalds

I have been running the 20010112 version of wine with "Agent" in order to read all my mail and news. This seemed to work fine. In order to try and get a game (Grand Prix Legends) to work I have installed the Transgaming patch, which including patching wine to the 29th Jan version. Since that time, some subtle changes seems to have occurred. These are a) Previously wine had been

I updated my from LLVM 2.7 to 2.8/trunk tonight and was mystified as to why my GC plugin silently stopped working. The problem was that the signature of the virtual function GCMetadataPrinter::finishAssembly (and beginAssembly) changed. This change would probably be an excellent candidate for the "gotchas" section of the 2.8 release notes. Thanks! -- Ben -------------- next part

Hi Ben, > I updated my from LLVM 2.7 to 2.8/trunk tonight and was mystified as to why my > GC plugin silently stopped working. > > The problem was that the signature of the virtual function > GCMetadataPrinter::finishAssembly (and beginAssembly) changed. > > This change would probably be an excellent candidate for the "gotchas" section > of the 2.8 release notes.

Hi guys, In porting our project over to LLVM-2.8 today I ran into a change that should probably go in the 2.8 release notes. After r100485, the MemoryBuffer::getMemBuffer went from: /// getMemBuffer - Open the specified memory range as a MemoryBuffer. Note /// that EndPtr[0] must be a null byte and be accessible!

On Mon, Sep 13, 2010 at 5:17 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Ben, > > > I updated my from LLVM 2.7 to 2.8/trunk tonight and was mystified as to > why my > > GC plugin silently stopped working. > > > > The problem was that the signature of the virtual function > > GCMetadataPrinter::finishAssembly (and beginAssembly) changed. >

On 05/17/2013 08:08 PM, Rafael Espíndola wrote: > My understanding is that with the new attribute system we should > deprecate and eventually remove the codegen command line options. How is that possible? > On 17 May 2013 06:04, reed kotler <rkotler at mips.com> wrote: >> I can't say this is a bug it is changed behavior from before the new >> attribute scheme.

On Tue, 27 Apr 2004, Vladimir Prus wrote: > > Yeah, fishy huh? :) > > Yea, a bit. I've decided that before changing that I'd better find other > problems, if any, so I run inst_iterator via checks provided by > Boost.Iterators. > > First problem is that inst_iterator (and actually InstIterator class template) > is not Assignable, because it has a reference data

On Tue, Jan 17, 2017 at 04:20:49PM +0000, Rolf Neugebauer wrote: > Commits: > > fd2a0437dc33 virtio_net: introduce virtio_net_hdr_{from,to}_skb > e858fae2b0b8 virtio_net: use common code for virtio_net_hdr and skb > GSO conversion > > introduced a subtle (but unexplained) difference in how virtio_net > flags are derived from skb->ip_summed fields on transmit from the

Hello all, I have a peculiar and particular bug that I stumbled across with ggplot2. I cannot seem to replicate it with anything other than my specific data set. Here is the problem: - when I try to plot a histogram, allowing for ggplot2 to decide the binwidths itself, I get the following error: - stat_bin: binwidth defaulted to range/30. Use 'binwidth = x' to

Hello, I think there's a rather subtle problem with the inst_iterator. It declares its iterator category as std::bidirectional_iterator_tag but C++ standard requirements for forward iterator (which are included in requirements for bidirection iterator), say that the type of expression *r; should be T&, where 'r' is the iterator and T is its value type. The inst_iterator,

My understanding is that with the new attribute system we should deprecate and eventually remove the codegen command line options. On 17 May 2013 06:04, reed kotler <rkotler at mips.com> wrote: > I can't say this is a bug it is changed behavior from before the new > attribute scheme. > > This issue may appear with other attributes. (there are other attributes > that clang

On Fri, 23 Apr 2004, Vladimir Prus wrote: > and since result of *it is considered to be rvalue it can't be accepted by > this operator. The complete discussion is in > > http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm > > I'd suggest to apply the following patch which makes operator* return > reference to pointer. It makes my code compile and the rest

Hello, I've been wondering why my no-optimization R-devel builds have been hanging during "building/updating package indices ...". I tracked it down with gdb to this line from do_basename in utils.c: while ( *(p = buf + strlen(buf) - 1) == fsp ) *p = '\0'; Now, imagine if your compiler places the variable fsp immediately before buf on the stack, and strlen(buf) is 0.

Commits: fd2a0437dc33 virtio_net: introduce virtio_net_hdr_{from,to}_skb e858fae2b0b8 virtio_net: use common code for virtio_net_hdr and skb GSO conversion introduced a subtle (but unexplained) difference in how virtio_net flags are derived from skb->ip_summed fields on transmit from the guest to the host/backend. Prior to the patches the flags would be set to VIRTIO_NET_HDR_F_NEEDS_CSUM if

Commits: fd2a0437dc33 virtio_net: introduce virtio_net_hdr_{from,to}_skb e858fae2b0b8 virtio_net: use common code for virtio_net_hdr and skb GSO conversion introduced a subtle (but unexplained) difference in how virtio_net flags are derived from skb->ip_summed fields on transmit from the guest to the host/backend. Prior to the patches the flags would be set to VIRTIO_NET_HDR_F_NEEDS_CSUM if

Hello: Is there any documentation dealing with the functional differences between R 1.1 and R 1.2. I have noticed some strange behavior in what is, I guess, the namespace of libraries as well as some changes in reading in tables. In a library, I don't seem to be able to declare a global variable and then use it in that same library. e.g. > blah <<- 0 > print(blah) will

On Fri, Apr 24, 2015 at 02:56:42PM -0400, Waiman Long wrote: > In the pv_scan_next() function, the slow cmpxchg atomic operation is > performed even if the other CPU is not even close to being halted. This > extra cmpxchg can harm slowpath performance. > > This patch introduces the new mayhalt flag to indicate if the other > spinning CPU is close to being halted or not. The

On Fri, Apr 24, 2015 at 02:56:42PM -0400, Waiman Long wrote: > In the pv_scan_next() function, the slow cmpxchg atomic operation is > performed even if the other CPU is not even close to being halted. This > extra cmpxchg can harm slowpath performance. > > This patch introduces the new mayhalt flag to indicate if the other > spinning CPU is close to being halted or not. The

Chris Lattner wrote: > > inline IIty operator*() const { return BI; } > > inline IIty operator->() const { return operator*(); } > > > > So operator* works as if value_type is Instruction*, but operator-> works > > as if value_type is Instruction. Hmm ;-) > > Yeah, fishy huh? :) Yea, a bit. I've decided that before changing that I'd better