Michael Veksler writes:
> In this case, how is it possible to copy the objects? Will things just
> crash at run-time?
Although people have been discussing copying the objects, I should point
out that my original proposal suggests not copying. Instead the code
can always access the objects via p
Joe Buck wrote:
On Mon, Mar 02, 2009 at 12:16:42PM -0800, Mark Mitchell wrote:
The C++ standard limits the compiler's ability to introduce copies. It
says "Here are where copies occur; some of these can be optimized away."
It doesn't say anything about inserting more copies. So, depending
On Mon, Mar 02, 2009 at 12:16:42PM -0800, Mark Mitchell wrote:
> Ian Lance Taylor wrote:
>
> > Daniel showed how this can fail for objects with internal pointers.
> > This includes __gnu_cxx::__vstring, which is likely to be the default
> > std::string class in libstdc++ 7, so this is not an unlik
Ian Lance Taylor wrote:
> Daniel showed how this can fail for objects with internal pointers.
> This includes __gnu_cxx::__vstring, which is likely to be the default
> std::string class in libstdc++ 7, so this is not an unlikely occurrence.
The C++ standard limits the compiler's ability to introd
John Regehr writes:
> This effort is relevant:
>
> http://research.microsoft.com/en-us/um/people/jcondit/capriccio-sosp-2003.pdf
Yes. Unfortunately, their analysis which lets them avoid testing at the
entry to each function requires a complete call graph, which is not
something gcc can assume i
This effort is relevant:
http://research.microsoft.com/en-us/um/people/jcondit/capriccio-sosp-2003.pdf
John Regehr
Mathieu Lacage writes:
> On Fri, 2009-02-27 at 08:54 -0800, Ian Lance Taylor wrote:
>
>> > It would be totally awesome to do this if you could provide an option to
>> > delegate to a user-provided function the allocation and deallocation of
>> > the stack blobs needed by threads.
>>
>> Yes, this
On Fri, 2009-02-27 at 08:54 -0800, Ian Lance Taylor wrote:
> > It would be totally awesome to do this if you could provide an option to
> > delegate to a user-provided function the allocation and deallocation of
> > the stack blobs needed by threads.
>
> Yes, this would be a goal.
The main reaso
Mathieu Lacage writes:
> On Thu, 2009-02-26 at 14:05 -0800, Ian Lance Taylor wrote:
>> I've put a project proposal for split stacks on the wiki at
>> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
>> of a single thread to be split into discontiguous segments, thus
>> permi
Andi Kleen writes:
> Ian Lance Taylor writes:
>
>> I've put a project proposal for split stacks on the wiki at
>> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
>> of a single thread to be split into discontiguous segments, thus
>> permitting many more threads to be activ
On Fri, Feb 27, 2009 at 09:10:10AM +0100, Mathieu Lacage wrote:
> - if you want to use the stack protector and split stacks, it should
> be fairly trivial to extend the data structure which contains the stack
> protector with a new field, no ?
The stack protector is just a word, not a pointer.
Mathieu Lacage wrote:
> It would be totally awesome to do this if you could provide an option to
> delegate to a user-provided function the allocation and deallocation of
> the stack blobs needed by threads.
> Ideally, I would even be able to use heap memory for that stack space if
> I wanted to.
Ian Lance Taylor wrote:
> Joel Sherrill writes:
>
>> Ian Lance Taylor wrote:
>>> I've put a project proposal for split stacks on the wiki at
>>> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
>>> of a single thread to be split into discontiguous segments, thus
>>> permitti
comments below,
On Thu, 2009-02-26 at 14:05 -0800, Ian Lance Taylor wrote:
> I've put a project proposal for split stacks on the wiki at
> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
> of a single thread to be split into discontiguous segments, thus
> permitting many mor
Ian Lance Taylor writes:
> I've put a project proposal for split stacks on the wiki at
> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
> of a single thread to be split into discontiguous segments, thus
> permitting many more threads to be active at one time without worryi
Joel Sherrill writes:
> Ian Lance Taylor wrote:
>> I've put a project proposal for split stacks on the wiki at
>> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
>> of a single thread to be split into discontiguous segments, thus
>> permitting many more threads to be active
Ian Lance Taylor wrote:
I've put a project proposal for split stacks on the wiki at
http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
of a single thread to be split into discontiguous segments, thus
permitting many more threads to be active at one time without worrying
about
I've put a project proposal for split stacks on the wiki at
http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
of a single thread to be split into discontiguous segments, thus
permitting many more threads to be active at one time without worrying
about stack overflow or about wa
18 matches
Mail list logo
