search for: n2461

...w.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2664.htm http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2429.htm http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html A working draft for the next C++ standard is also available: http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf (It incorporates some of the memory model changes.) Daveed

.... > > I also am not a STL guru; the standard says erase > "Invalidates all the iterators and references after the point of the > erase" > which is not wonderfully worded, but I take it to mean an iterator > referring to the point of the erase remains valid.... From n2461: > 8 The insert members shall not affect the validity of iterators and > references to the container, and the erase members shall invalidate > only iterators and references to the erased elements. Pretty clear. If you play with --i, be careful of iterators that point to the begin...

...m not a STL guru; the standard says erase >> "Invalidates all the iterators and references after the point of the >> erase" >> which is not wonderfully worded, but I take it to mean an iterator >> referring to the point of the erase remains valid.... > > From n2461: > >> 8 The insert members shall not affect the validity of iterators and >> references to the container, and the erase members shall invalidate >> only iterators and references to the erased elements. > > Pretty clear. In the current standard that language appears unde...

On May 27, 2008, at 2:01 PM, Dale Johannesen wrote: > On May 27, 2008, at 1:40 PM, Mike Stump wrote: >> >> From n2461: >> >>> 8 The insert members shall not affect the validity of iterators and >>> references to the container, and the erase members shall invalidate >>> only iterators and references to the erased elements. >> >> Pretty clear. > > > In the curren...

...ntities refer to the same object or not, or to put it another way, if two entities have the same address. Pointing off the end of an array doesn't necessarily yield a pointer to an object. It represents a value that can be manipulated to refer to an object, say, with p-1. I can quote n2461 if you prefer: Two pointers of the same type compare equal if and only if they are both null, both point to the same function, or both represent the same address (3.9.2). A valid value of an object pointer type represents either the address of a byte in memory (1.7) or a null pointer (4.10)....

...cope (mostly, cross-TU) correspondences. The question here can arise within a scope. > Pointing off the end of an array doesn't necessarily > yield a pointer to an object. It represents a value that can be > manipulated to refer to an object, say, with p-1. > > I can quote n2461 if you prefer: > > Two pointers of the same type compare equal if and only if they are > both > null, both point to the same function, or both represent the same > address (3.9.2). > > A valid value of an object pointer type represents either the address > of a byte in mem...

...ndefined. undefined means the code is free to rm -rf /, is this what you meant? I'm against that. The usual wording is sufficient: It is unspecified whether such a variable has an address distinct from that of any other object in the program to reuse the concept and words from 8.4p8 (n2461). This isn't quite right, but we know what is meant by it. The implementation is free to merge it with any other mergable object. > This has the following effects on current optimizers: constmerge only > merges globals marked mergeable. Only mergeable constants are emitted > in...

On Oct 15, 2008, at 3:53 PM, Mike Stump wrote: [...] > Objects are defined like so: > > Two pointers of > the same type compare equal if and only if they are both null, > both > point to the same object or function, or both point one past the > end > of the same array. > > This means they _must_ compare !=, if they are different objects. Aha! Thanks for

On Thu, Oct 16, 2008 at 12:35 PM, Mike Stump <mrs at apple.com> wrote: >> It doesn't really change the issue, though; we want the merging to be >> a front-end option, and we still need a solution which handles >> variables that gets marked by the optimizer. > > I think so. If we could get C/C++ to just bless merging and then just > support that and ignore

On May 23, 2008, at 4:10 AM, Nicolas Capens wrote: > Hi all, > > I updated from 2.2 to the latest SVN head and I now get a debug > assert in BranchFolder::RemoveBlocksWithHash: “vector iterators > incompatible”. I’m using Visual C++ 2005. I think this is the > culprit code: > > MergePotentials.erase(CurMPIter); > if (CurMPIter==B) > break; >

Hi all, I updated from 2.2 to the latest SVN head and I now get a debug assert in BranchFolder::RemoveBlocksWithHash: "vector iterators incompatible". I'm using Visual C++ 2005. I think this is the culprit code: MergePotentials.erase(CurMPIter); if (CurMPIter==B) break; The erase clears the _Mycont field (i.e. the iterator's container), while the ==

Hi Mon Wang, As I understand it the C++0x memory model will, by default, be similar to Java's in that it will assume sequential consistency, using acquire/release atomics (similar to Java's volatile), for all programs that do not contain data races. Unlike Java in the case when a program contains a data race, the program behavior is undefined. Adopting this model allows many sequential

On Oct 15, 2008, at 8:28 AM, Chris Lattner wrote: > On Oct 15, 2008, at 6:58 AM, Tatu Vaajalahti wrote: >>> Yes, but why do you think they should get a different address? I >>> can >>> understand that it is surprising that they do, but determining >>> whether >>> this is legal or not requires reading the language standard. >>> Hopefully

Hi Ben, Vacation is always a good thing. Hope you had a good one. In my mind, having a more general memory consistency model is going to be very useful in LLVM in the future. It is still a little unclear to me what we should support. I haven't looked at what C++ is considering for their model. Are they going to support different relaxations models like relaxing write to read or

https://bugs.freedesktop.org/show_bug.cgi?id=89558 Bug ID: 89558 Summary: Unknown chipset error for GeForce 840M Product: xorg Version: unspecified Hardware: Other OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at