> From: David Daney
> Sent: Tuesday, November 15, 2005 11:44 AM
> To: Mike Stump
> Cc: gcc@gcc.gnu.org; [EMAIL PROTECTED]
> Subject: Re: Null pointer check elimination
>
>
> Mike Stump wrote:
> > On Nov 14, 2005, at 11:36 PM, David Daney wrote:
> >
> >> Perhaps not in general, but one unstated p
I'm clearly with Torvald here.
The original set of problems here is very clearly addressed by the C+11/C11
memory model. It clearly implies, among other things:
- Updating a bit-field may interfere (create a data race with) other updates to
that same contiguous sequence of bit-fields, but not
> From: Linus Torvalds
> >
> > We need a proper memory model.
>
> Not really.
>
> The fact is, the kernel will happily take the memory model of the
> underlying hardware. Trying to impose some compiler description of the
> memory model is actually horribly bad, because it automatically also
> inv
> From: Linus Torvalds
> Don't try to make it anything more complicated. This has *nothing* to
> do with threads or functions or anything else.
>
> If you do massive inlining, and you don't see any barriers or
> conditionals or other reasons not to write to it, just write to it.
>
> Don't try to
> From: Torvald Riegel
> > Oh, one of my favorite (NOT!) pieces of code in the kernel is the
> > implementation of the
> >
> >smp_read_barrier_depends()
> >
> > macro, which on every single architecture except for one (alpha) is a
> no-op.
> >
> > We have basically 30 or so empty definitions fo
> -Original Message-
> From: Lawrence Crowl [mailto:cr...@google.com]
> The problem is that gcc does support 80386. It also supports
> other processors that have less-than-complete support for
> concurrency. Just in the x86 line, we get some additional
> capability in many new laye
> From: Lawrence Crowl [mailto:cr...@google.com]
>
> On 8/20/09, Boehm, Hans wrote:
> > > -Original Message-
> > > From: Lawrence Crowl [mailto:cr...@google.com] The
> problem is that
> > > gcc does support 80386. It also supports other
I would still love to get a reaction to this from the gcc folks (now included):
1) Is it intended that inconsistent use of -fexceptions can cause pthread
cleanup handlers to be skipped (since exception based cleanup is not invoked if
thread exit is triggered from a context without exceptions),
I'm not up on the details here. But I want to point out that C++0x and C1x
require atomic operations on all platforms, with the expectation that they will
be emulated (most likely with an address-indexed table of locks) on platforms
that don't provide them. If I understand this correctly, it s
> From: Laurent GUERBY
> Wether C++, Java or Ada, a new language requirement looks the same to
> me: having a good enough base compiler and runtime installed
> for the language, I do not see anything special to Java or
> Ada over C++ here. The base compiler I use for building GCC
> has only c,
10 matches
Mail list logo
