Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Linux>
  3. Kernel
1 2 3  View All
Is gcc thread-unsafe?
nickpiggin at yahoo
Oct 24, 2007, 8:24 PM
Post #1 of 61 (5763 views)
Permalink
Hi,

Andi spotted this exchange on the gcc list. I don't think he's
brought it up here yet, but it worries me enough that I'd like
to discuss it.

Starts here
http://gcc.gnu.org/ml/gcc/2007-10/msg00266.html

Concrete example here
http://gcc.gnu.org/ml/gcc/2007-10/msg00275.html

Basically, what the gcc developers are saying is that gcc is
free to load and store to any memory location, so long as it
behaves as if the instructions were executed in sequence.

I guess that dynamically allocated memory and computed pointers
are more difficult for gcc to do anything unsafe with, because
it is harder to tell if a given function has deallocated the
memory. However even that could theoretically happen in future
if the compiler can work out the address comes from a global
variable or is not changed intermediately.

Linux makes extensive use of both trylocks and interruptible
locks (ie. which automatically result in divergant code paths,
one of which holds the lock, the other doesn't). However there
are also other code paths which will either hold a particular
lock or will not hold it, depending on context or some flags
etc. barrier() doesn't help.

For x86, obviously the example above shows it can be miscompiled,
but it is probably relatively hard to make it happen for a non
trivial sequence. For an ISA with lots of predicated instructions
like ia64, it would seem to be much more likely. But of course
we don't want even the possibility of failures.

The gcc guys seem to be saying to mark everything volatile that
could be touched in a critical section. This is insane for Linux.

Any thoughts?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
arjan at infradead
Oct 24, 2007, 8:46 PM
Post #2 of 61 (5654 views)
Permalink
On Thu, 25 Oct 2007 13:24:49 +1000
Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> Hi,
>
> Andi spotted this exchange on the gcc list. I don't think he's
> brought it up here yet, but it worries me enough that I'd like
> to discuss it.
>
> Starts here
> http://gcc.gnu.org/ml/gcc/2007-10/msg00266.html
>
> Concrete example here
> http://gcc.gnu.org/ml/gcc/2007-10/msg00275.html
>
> Basically, what the gcc developers are saying is that gcc is
> free to load and store to any memory location, so long as it
> behaves as if the instructions were executed in sequence.
>


this optimization btw is a serious mis-optimization, it makes memory
more dirty and causes cachelines to become unshared.... I'm sure it
works great on microbenchmarks but it sucks bigtime for anything real
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
nickpiggin at yahoo
Oct 24, 2007, 8:58 PM
Post #3 of 61 (5652 views)
Permalink
On Thursday 25 October 2007 13:46, Arjan van de Ven wrote:
> On Thu, 25 Oct 2007 13:24:49 +1000
>
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> > Hi,
> >
> > Andi spotted this exchange on the gcc list. I don't think he's
> > brought it up here yet, but it worries me enough that I'd like
> > to discuss it.
> >
> > Starts here
> > http://gcc.gnu.org/ml/gcc/2007-10/msg00266.html
> >
> > Concrete example here
> > http://gcc.gnu.org/ml/gcc/2007-10/msg00275.html
> >
> > Basically, what the gcc developers are saying is that gcc is
> > free to load and store to any memory location, so long as it
> > behaves as if the instructions were executed in sequence.
>
> this optimization btw is a serious mis-optimization, it makes memory
> more dirty and causes cachelines to become unshared.... I'm sure it
> works great on microbenchmarks but it sucks bigtime for anything real

Well that's exactly right. For threaded programs (and maybe even
real-world non-threaded ones in general), you don't want to be
even _reading_ global variables if you don't need to. Cache misses
and cacheline bouncing could easily cause performance to completely
tank in some cases while only gaining a cycle or two in
microbenchmarks for doing these funny x86 predication things.

I'm not sure about ia64 -- I _hope_ that for most of their
predication stuff, they also predicate the stores, rather than
just store unconditionally and rely on the source operand not
changing in the case they didn't intend the memory to change.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Is gcc thread-unsafe? [ In reply to ]
davids at webmaster
Oct 24, 2007, 9:29 PM
Post #4 of 61 (5662 views)
Permalink
> Well that's exactly right. For threaded programs (and maybe even
> real-world non-threaded ones in general), you don't want to be
> even _reading_ global variables if you don't need to. Cache misses
> and cacheline bouncing could easily cause performance to completely
> tank in some cases while only gaining a cycle or two in
> microbenchmarks for doing these funny x86 predication things.

For some CPUs, replacing an conditional branch with a conditional move is a
*huge* win because it cannot be mispredicted. In general, compilers should
optimize for unshared data since that's much more common in typical code.
Even for shared data, the usual case is that you are going to access the
data few times, so pulling the cache line to the CPU is essentially free
since it will happen eventually.

Heuristics may show that the vast majority of such constructs write anyway.
So the optimization may also be valid based on such heuristics.

A better question is whether it's legal for a compiler that claims to
support POSIX threads. I'm going to post on comp.programming.threads, where
the threading experts hang out.

A very interesting case to be sure.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
arjan at infradead
Oct 24, 2007, 9:35 PM
Post #5 of 61 (5656 views)
Permalink
On Wed, 24 Oct 2007 21:29:56 -0700
"David Schwartz" <davids@webmaster.com> wrote:

>
> > Well that's exactly right. For threaded programs (and maybe even
> > real-world non-threaded ones in general), you don't want to be
> > even _reading_ global variables if you don't need to. Cache misses
> > and cacheline bouncing could easily cause performance to completely
> > tank in some cases while only gaining a cycle or two in
> > microbenchmarks for doing these funny x86 predication things.
>
> For some CPUs, replacing an conditional branch with a conditional
> move is a *huge* win because it cannot be mispredicted.

please name one...
Hint: It's not one made by either Intel or AMD in the last 4 years...


> In general,
> compilers should optimize for unshared data since that's much more
> common in typical code. Even for shared data, the usual case is that
> you are going to access the data few times, so pulling the cache line
> to the CPU is essentially free since it will happen eventually.

it's not about pulling it to the CPU, it's pulling it *out* of all the
other cpus AS WELL. (and writing it back to memory, taking away memory
bandwidth)


--
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
nickpiggin at yahoo
Oct 24, 2007, 9:47 PM
Post #6 of 61 (5654 views)
Permalink
Hi David,

[BTW. can you retain cc lists, please?]

On Thursday 25 October 2007 14:29, David Schwartz wrote:
> > Well that's exactly right. For threaded programs (and maybe even
> > real-world non-threaded ones in general), you don't want to be
> > even _reading_ global variables if you don't need to. Cache misses
> > and cacheline bouncing could easily cause performance to completely
> > tank in some cases while only gaining a cycle or two in
> > microbenchmarks for doing these funny x86 predication things.
>
> For some CPUs, replacing an conditional branch with a conditional move is a
> *huge* win because it cannot be mispredicted.

A *conditional* store should no be a problem.

However the funny trick of doing this conditional add (implemented with
unconditional store), is what is going to cause breakage.

On the CPUs where predicated instructions are a big win, I'd expect
they should also implement a conditional store for use here. However
they might be slower than an unconditional store (eg. x86's cmov),
and in those cases, gcc might just do the non-conditional store.


> In general, compilers should
> optimize for unshared data since that's much more common in typical code.
> Even for shared data, the usual case is that you are going to access the
> data few times, so pulling the cache line to the CPU is essentially free
> since it will happen eventually.

This is not just a question of data that you were going to use anyway.
gcc generates memory accesses to locations that would never be accessed
Even stores. It is basically impossible to say that this is a real
performance win. Even on single threaded code: consider that cache
misses take the vast majority of time in many loads, which gives a
little hint that maybe it's a bad idea to do this ;)


> Heuristics may show that the vast majority of such constructs write anyway.
> So the optimization may also be valid based on such heuristics.

I'd never say the optimisation would always be useless. But it's a nasty
thing to have on by default, and apparently even with no good way to
supress it even if we want to.


> A better question is whether it's legal for a compiler that claims to
> support POSIX threads. I'm going to post on comp.programming.threads, where
> the threading experts hang out.

Either way, I think we really need a way to turn it off for Linux.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
ak at suse
Oct 25, 2007, 12:15 AM
Post #7 of 61 (5650 views)
Permalink
On Thursday 25 October 2007 05:24, Nick Piggin wrote:

> Basically, what the gcc developers are saying is that gcc is
> free to load and store to any memory location, so long as it
> behaves as if the instructions were executed in sequence.

This case is clearly a bug, a very likely code pessimization.
I guess it wasn't intentional, just an optimization that is useful
for local register values doing too much.

> I guess that dynamically allocated memory and computed pointers
> are more difficult for gcc to do anything unsafe with, because
> it is harder to tell if a given function has deallocated the
> memory.

Often accesses happen without function calls inbetween.
Also I think newer gcc (not 3.x) can determine if a pointer
"escapes" or not so that might not protect against it.

> Any thoughts?

We don't have much choice: If such a case is found it has to be marked
volatile or that particular compiler version be unsupported.

It might be useful to come up with some kind of assembler pattern
matcher to check if any such code is generated for the kernel
and try it with different compiler versions.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
sam at rfc1149
Oct 25, 2007, 2:40 AM
Post #8 of 61 (5645 views)
Permalink
>>>>> "Nick" == Nick Piggin <nickpiggin@yahoo.com.au> writes:

Nick> Hi David, [BTW. can you retain cc lists, please?]

Nick> On Thursday 25 October 2007 14:29, David Schwartz wrote:
>> > Well that's exactly right. For threaded programs (and maybe even
>> > real-world non-threaded ones in general), you don't want to be >
>> even _reading_ global variables if you don't need to. Cache misses
>> > and cacheline bouncing could easily cause performance to
>> completely > tank in some cases while only gaining a cycle or two
>> in > microbenchmarks for doing these funny x86 predication things.
>>
>> For some CPUs, replacing an conditional branch with a conditional
>> move is a *huge* win because it cannot be mispredicted.

Nick> A *conditional* store should no be a problem.

Nick> However the funny trick of doing this conditional add
Nick> (implemented with unconditional store), is what is going to
Nick> cause breakage.

Nick> On the CPUs where predicated instructions are a big win, I'd
Nick> expect they should also implement a conditional store for use
Nick> here. However they might be slower than an unconditional store
Nick> (eg. x86's cmov), and in those cases, gcc might just do the
Nick> non-conditional store.


>> In general, compilers should optimize for unshared data since
>> that's much more common in typical code. Even for shared data, the
>> usual case is that you are going to access the data few times, so
>> pulling the cache line to the CPU is essentially free since it will
>> happen eventually.

Nick> This is not just a question of data that you were going to use
Nick> anyway. gcc generates memory accesses to locations that would
Nick> never be accessed Even stores. It is basically impossible to say
Nick> that this is a real performance win. Even on single threaded
Nick> code: consider that cache misses take the vast majority of time
Nick> in many loads, which gives a little hint that maybe it's a bad
Nick> idea to do this ;)


>> Heuristics may show that the vast majority of such constructs write
>> anyway. So the optimization may also be valid based on such
>> heuristics.

Nick> I'd never say the optimisation would always be useless. But it's
Nick> a nasty thing to have on by default, and apparently even with no
Nick> good way to supress it even if we want to.


>> A better question is whether it's legal for a compiler that claims
>> to support POSIX threads. I'm going to post on
>> comp.programming.threads, where the threading experts hang out.

Nick> Either way, I think we really need a way to turn it off for
Nick> Linux.

--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
sam at rfc1149
Oct 25, 2007, 2:44 AM
Post #9 of 61 (5646 views)
Permalink
>>>>> "Nick" == Nick Piggin <nickpiggin@yahoo.com.au> writes:

Nick> Either way, I think we really need a way to turn it off for
Nick> Linux.

Someone would need to add an option to disable the "cselim" pass in
GCC tree-ssa-phiopt.c as far as I can tell from reading GCC source.

Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
sam at rfc1149
Oct 25, 2007, 2:54 AM
Post #10 of 61 (5663 views)
Permalink
>>>>> "Sam" == Samuel Tardieu <sam@rfc1149.net> writes:
>>>>> "Nick" == Nick Piggin <nickpiggin@yahoo.com.au> writes:

Nick> Either way, I think we really need a way to turn it off for
Nick> Linux.

Sam> Someone would need to add an option to disable the "cselim" pass
Sam> in GCC tree-ssa-phiopt.c as far as I can tell from reading GCC
Sam> source.

Mmm, it looks like there is an option already (-fno-tree-cselim), but
it looks like it has no visible effect in my version of GCC
(yesterday's SVN). I'll ask on the GCC mailing-list.

Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
ak at novell
Oct 25, 2007, 2:55 AM
Post #11 of 61 (5648 views)
Permalink
On Thursday 25 October 2007 11:44:28 Samuel Tardieu wrote:
> >>>>> "Nick" == Nick Piggin <nickpiggin@yahoo.com.au> writes:
>
> Nick> Either way, I think we really need a way to turn it off for
> Nick> Linux.
>
> Someone would need to add an option to disable the "cselim" pass in
> GCC tree-ssa-phiopt.c as far as I can tell from reading GCC source.

Note the test case was for 3.4.x which doesn't have tree-ssa at all.
It does if-conversion on the RTL level

-Andi


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
linux-os at analogic
Oct 25, 2007, 4:58 AM
Post #12 of 61 (5642 views)
Permalink
On Thu, 25 Oct 2007, Andi Kleen wrote:

> On Thursday 25 October 2007 05:24, Nick Piggin wrote:
>
>> Basically, what the gcc developers are saying is that gcc is
>> free to load and store to any memory location, so long as it
>> behaves as if the instructions were executed in sequence.
>
> This case is clearly a bug, a very likely code pessimization.
> I guess it wasn't intentional, just an optimization that is useful
> for local register values doing too much.


I don't think it is a BUG, but one should certainly be able
to turn it off. Gcc is correct in that the 'C' language allows
a lot of implimentation details that are not covered by the
language. In other words, 'C' is not assembly-language.


>
>> I guess that dynamically allocated memory and computed pointers
>> are more difficult for gcc to do anything unsafe with, because
>> it is harder to tell if a given function has deallocated the
>> memory.
>
> Often accesses happen without function calls inbetween.
> Also I think newer gcc (not 3.x) can determine if a pointer
> "escapes" or not so that might not protect against it.
>
>> Any thoughts?
>
> We don't have much choice: If such a case is found it has to be marked
> volatile or that particular compiler version be unsupported.
>
> It might be useful to come up with some kind of assembler pattern
> matcher to check if any such code is generated for the kernel
> and try it with different compiler versions.
>
> -Andi

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.59 BogoMips).
My book : http://www.AbominableFirebug.com/
_


****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
ak at novell
Oct 25, 2007, 5:16 AM
Post #13 of 61 (5642 views)
Permalink
On Thursday 25 October 2007 13:58:56 linux-os (Dick Johnson) wrote:
>
> On Thu, 25 Oct 2007, Andi Kleen wrote:
>
> > On Thursday 25 October 2007 05:24, Nick Piggin wrote:
> >
> >> Basically, what the gcc developers are saying is that gcc is
> >> free to load and store to any memory location, so long as it
> >> behaves as if the instructions were executed in sequence.
> >
> > This case is clearly a bug, a very likely code pessimization.
> > I guess it wasn't intentional, just an optimization that is useful
> > for local register values doing too much.
>
>
> I don't think it is a BUG,

Bug as in an optimization that makes the code slower than it was
before. That is clearly a bug in a compiler.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
torvalds at linux-foundation
Oct 25, 2007, 7:55 AM
Post #14 of 61 (5642 views)
Permalink
On Thu, 25 Oct 2007, Nick Piggin wrote:
>
> Andi spotted this exchange on the gcc list. I don't think he's
> brought it up here yet, but it worries me enough that I'd like
> to discuss it.

Are you surprised?

The gcc developers seem to have had a total disregard for what people
want or need, and every time some code generation issue comes up, there's
a lot of people on the list that do language-lawyering, rather than admit
that there might be a problem.

It's happened before, it will happen again. I don't think it's true of all
gcc developers (or even most, I hope), but it's common enough. For some
reason, compiler developers seem to be far enough removed from "real life"
that they have a tendency to talk in terms of "this is what the spec says"
rather than "this is a problem".

Happily, at least in this kind of situation, threading is a real issue for
other projects than just the kernel, so maybe it gets solved properly.

But I have to admit that for the last five years or so, I've really wanted
some other compiler team to come up with a good open-source compiler.
Exactly due to issues like this (Q: "Gcc creates bogus code that doesn't
work!" A: "It's not bogus, it's technically allowed by the language specs
that don't talk about xyz, the fact that it doesn't work isn't our
problem").

I think the OpenBSD people decided to actually do something about this,
and I suspect it had *nothing* to do with license issues, and everything
to do with these kinds of problems. I wish them all the luck, although
personally I think LLVM is a much more interesting project.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
penberg at cs
Oct 25, 2007, 8:12 AM
Post #15 of 61 (5640 views)
Permalink
Hi,

On 10/25/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> I think the OpenBSD people decided to actually do something about this,
> and I suspect it had *nothing* to do with license issues, and everything
> to do with these kinds of problems. I wish them all the luck, although
> personally I think LLVM is a much more interesting project.

The BSD people are adopting pcc [1] which is a rewritten version of
some C compiler originally developed in the late 70s. And yeah, it's
basically because they think gcc is becoming too painful to live with
[2].

Pekka

1. http://pcc.ludd.ltu.se/
2. http://www.thejemreport.com/mambo/content/view/369/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
mans at mansr
Oct 25, 2007, 11:45 AM
Post #16 of 61 (5640 views)
Permalink
Arjan van de Ven <arjan@infradead.org> writes:

> On Wed, 24 Oct 2007 21:29:56 -0700
> "David Schwartz" <davids@webmaster.com> wrote:
>
>>
>> > Well that's exactly right. For threaded programs (and maybe even
>> > real-world non-threaded ones in general), you don't want to be
>> > even _reading_ global variables if you don't need to. Cache misses
>> > and cacheline bouncing could easily cause performance to completely
>> > tank in some cases while only gaining a cycle or two in
>> > microbenchmarks for doing these funny x86 predication things.
>>
>> For some CPUs, replacing an conditional branch with a conditional
>> move is a *huge* win because it cannot be mispredicted.
>
> please name one...
> Hint: It's not one made by either Intel or AMD in the last 4 years...

ARM. On ARM1136 (used in the Nokia N800) a mispredicted branch takes
5-7 cycles (a correctly predicted branch takes 0-4 cycles), while a
conditional load, store or arithmetic instruction always takes one
cycle.

--
Måns Rullgård
mans@mansr.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Is gcc thread-unsafe? [ In reply to ]
davids at webmaster
Oct 25, 2007, 2:42 PM
Post #17 of 61 (5643 views)
Permalink
I asked a collection of knowledgeable people I know about the issue. The
consensus is that the optimization is not permitted in POSIX code but that
it is permitted in pure C code. The basic argument goes like this:

To make POSIX-compliant code even possible, surely optimizations that add
writes to variables must be prohibited. That is -- if POSIX prohibits
writing to a variable in certain cases only the programmer can detect, then
a POSIX-compliant compiler cannot write to a variable except where
explicitly told to do so. Any optimization that *adds* a write to a variable
that would not otherwise occur *must* be prohibited.

Otherwise, it is literally impossible to comply with the POSIX requirement
that concurrent modifications and reads to shared variables take place while
holding a mutex.

The simplest solution is simply to ditch the optimization. If it really
isn't even an optimization, then that's an easy way out.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
ismail at pardus
Oct 25, 2007, 3:26 PM
Post #18 of 61 (5642 views)
Permalink
Thursday 25 October 2007 Tarihinde 17:55:00 yazmıştı:
> I think the OpenBSD people decided to actually do something about this,
> and I suspect it had *nothing* to do with license issues, and everything
> to do with these kinds of problems. I wish them all the luck, although
> personally I think LLVM is a much more interesting project.

And on the LLVM side all hopes for clang [0] at least for better C++ error
reporting ;-)

[0] http://clang.llvm.org/

--
Faith is believing what you know isn't so -- Mark Twain
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
nickpiggin at yahoo
Oct 25, 2007, 3:49 PM
Post #19 of 61 (5639 views)
Permalink
On Thursday 25 October 2007 17:15, Andi Kleen wrote:
> On Thursday 25 October 2007 05:24, Nick Piggin wrote:
> > Basically, what the gcc developers are saying is that gcc is
> > free to load and store to any memory location, so long as it
> > behaves as if the instructions were executed in sequence.
>
> This case is clearly a bug, a very likely code pessimization.
> I guess it wasn't intentional, just an optimization that is useful
> for local register values doing too much.

Although there can be cases where it looks much more like an
optimisation (eg. where the branch and increment occurs much
more often), but it would still be a bug. Granted they are
rather constructed cases, but I don't think you want to rely on
the fact that most of the time it's OK.


> > I guess that dynamically allocated memory and computed pointers
> > are more difficult for gcc to do anything unsafe with, because
> > it is harder to tell if a given function has deallocated the
> > memory.
>
> Often accesses happen without function calls inbetween.
> Also I think newer gcc (not 3.x) can determine if a pointer
> "escapes" or not so that might not protect against it.
>
> > Any thoughts?
>
> We don't have much choice: If such a case is found it has to be marked
> volatile or that particular compiler version be unsupported.

Marking volatile I think is out of the question. To start with,
volatile creates really poor code (and most of the time we actually
do want the code in critical sections to be as tight as possible).
But also because I don't think these bugs are just going to be
found easily.


> It might be useful to come up with some kind of assembler pattern
> matcher to check if any such code is generated for the kernel
> and try it with different compiler versions.

Hard to know how to do it. If you can, then it would be interesting.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
jeff at garzik
Oct 25, 2007, 3:56 PM
Post #20 of 61 (5642 views)
Permalink
Ismail Dönmez wrote:
> Thursday 25 October 2007 Tarihinde 17:55:00 yazmıştı:
>> I think the OpenBSD people decided to actually do something about this,
>> and I suspect it had *nothing* to do with license issues, and everything
>> to do with these kinds of problems. I wish them all the luck, although
>> personally I think LLVM is a much more interesting project.
>
> And on the LLVM side all hopes for clang [0] at least for better C++ error
> reporting ;-)
>
> [0] http://clang.llvm.org/

Someone should take 'sparse' and use that as a C language front-end to
LLVM...

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
jeff at garzik
Oct 25, 2007, 4:04 PM
Post #21 of 61 (5641 views)
Permalink
Jeff Garzik wrote:
> Ismail Dönmez wrote:
>> Thursday 25 October 2007 Tarihinde 17:55:00 yazmıştı:
>>> I think the OpenBSD people decided to actually do something about this,
>>> and I suspect it had *nothing* to do with license issues, and everything
>>> to do with these kinds of problems. I wish them all the luck, although
>>> personally I think LLVM is a much more interesting project.
>>
>> And on the LLVM side all hopes for clang [0] at least for better C++
>> error reporting ;-)
>>
>> [0] http://clang.llvm.org/
>
> Someone should take 'sparse' and use that as a C language front-end to
> LLVM...

Among clang's "features":
"A single unified parser for C/ObjC/C++"

bleh. I cannot imagine how ugly a C parser gets, after being taught
C++. IMO since you can basically redefine everything in C++, it's not a
language but a proto-language.

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
ak at novell
Oct 25, 2007, 4:09 PM
Post #22 of 61 (5644 views)
Permalink
On Friday 26 October 2007 00:49:42 Nick Piggin wrote:
> On Thursday 25 October 2007 17:15, Andi Kleen wrote:
> > On Thursday 25 October 2007 05:24, Nick Piggin wrote:
> > > Basically, what the gcc developers are saying is that gcc is
> > > free to load and store to any memory location, so long as it
> > > behaves as if the instructions were executed in sequence.
> >
> > This case is clearly a bug, a very likely code pessimization.
> > I guess it wasn't intentional, just an optimization that is useful
> > for local register values doing too much.
>
> Although there can be cases where it looks much more like an
> optimisation (eg. where the branch and increment occurs much
> more often), but it would still be a bug. Granted they are
> rather constructed cases, but I don't think you want to rely on
> the fact that most of the time it's OK.
>
>
> > > I guess that dynamically allocated memory and computed pointers
> > > are more difficult for gcc to do anything unsafe with, because
> > > it is harder to tell if a given function has deallocated the
> > > memory.
> >
> > Often accesses happen without function calls inbetween.
> > Also I think newer gcc (not 3.x) can determine if a pointer
> > "escapes" or not so that might not protect against it.
> >
> > > Any thoughts?
> >
> > We don't have much choice: If such a case is found it has to be marked
> > volatile or that particular compiler version be unsupported.
>
> Marking volatile I think is out of the question. To start with,
> volatile creates really poor code (and most of the time we actually
> do want the code in critical sections to be as tight as possible).

Poor code is better than broken code I would say. Besides
the cross CPU synchronization paths are likely dominated by
cache misses anyways; it's unlikely they're actually limited
by the core CPU. So it'll probably not matter all that much
if the code is poor or not.

But it's all theoretical for now.

> But also because I don't think these bugs are just going to be
> found easily.
>
>
> > It might be useful to come up with some kind of assembler pattern
> > matcher to check if any such code is generated for the kernel
> > and try it with different compiler versions.
>
> Hard to know how to do it. If you can, then it would be interesting.

I checked my kernel for "adc" at least (for the trylock/++ pattern)
and couldn't find any (in fact all of them were in
data the compiler thought to be code). That was not a allyesconfig build,
so i missed some code.

For cmov it's at first harder because they're much more frequent
and cmov to memory is a multiple instruction pattern (the instruction
does only support memory source operands). Luckily gcc
doesn't know the if (x) mem = a; => ptr = cmov(x, &a, &dummy); *ptr = a;
transformation trick so I don't think there are actually any conditional
stores on current x86.

It might be a problem on other architectures which support true
conditional stores though (like IA64 or ARM)

Also I'm not sure if gcc doesn't know any other tricks like the
conditional add using carry, although I cannot think of any related
to stores from the top of my hat.

Anyways, if it's only conditional add if we ever catch such a case
it could be also handled with inline assembly similar to local_inc()

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
torvalds at linux-foundation
Oct 25, 2007, 4:14 PM
Post #23 of 61 (5644 views)
Permalink
On Fri, 26 Oct 2007, Andi Kleen wrote:
> >
> > Marking volatile I think is out of the question. To start with,
> > volatile creates really poor code (and most of the time we actually
> > do want the code in critical sections to be as tight as possible).
>
> Poor code is better than broken code I would say.

No. A *working*compiler* is better than broken code.

There's no way to use volatile for these things, since it can hit
*anything*. When the compiler generates buggy code, it's buggy code. We
can't add volatiles to every single data structure. We'd be better off
having a million monkeys on crack try to hand-assemble the thing, than
having a totally buggy compiler do it for us.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
ak at suse
Oct 25, 2007, 4:16 PM
Post #24 of 61 (5644 views)
Permalink
On Friday 26 October 2007 01:14:41 Linus Torvalds wrote:
>
> On Fri, 26 Oct 2007, Andi Kleen wrote:
> > >
> > > Marking volatile I think is out of the question. To start with,
> > > volatile creates really poor code (and most of the time we actually
> > > do want the code in critical sections to be as tight as possible).
> >
> > Poor code is better than broken code I would say.
>
> No. A *working*compiler* is better than broken code.
>
> There's no way to use volatile for these things, since it can hit
> *anything*.

No it can't (at least not on x86) as I have explained in the rest of the mail
you conveniently snipped.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe? [ In reply to ]
nickpiggin at yahoo
Oct 25, 2007, 4:22 PM
Post #25 of 61 (5637 views)
Permalink
Can you retain cc list, please?

On Friday 26 October 2007 07:42, David Schwartz wrote:
> I asked a collection of knowledgeable people I know about the issue. The
> consensus is that the optimization is not permitted in POSIX code but that
> it is permitted in pure C code. The basic argument goes like this:
>
> To make POSIX-compliant code even possible, surely optimizations that add
> writes to variables must be prohibited. That is -- if POSIX prohibits
> writing to a variable in certain cases only the programmer can detect, then
> a POSIX-compliant compiler cannot write to a variable except where
> explicitly told to do so. Any optimization that *adds* a write to a
> variable that would not otherwise occur *must* be prohibited.
>
> Otherwise, it is literally impossible to comply with the POSIX requirement
> that concurrent modifications and reads to shared variables take place
> while holding a mutex.

Now all you have to do is tell this to the gcc developers ;)


> The simplest solution is simply to ditch the optimization. If it really
> isn't even an optimization, then that's an easy way out.

For some things, I'd expect it will be an optimisation, which is why
they're even doing it. Even on x86 perhaps, where they do tricks with
sbb/adc. If it avoids an unpredictable branch, it could help. Actually
a silly microbenchmark shows it's worth 10% to do a cmov vs an
unpredictable conditional jump, but another 2.5% to do the adc and
unconditional store (which is the problematic bit).

And for unshared things like local variables where their address
hasn't escaped, it's fine.

Still, I guess that for most non-stack variables, you would actually
_want_ to do a cmov rather than the adc, even in a single threaded
program. Because you don't want to touch the cacheline if possible,
let alone dirty it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
1 2 3  View All

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal