Re: Optimization of conditional access to globals: thread-unsafe?

On Mon, Oct 29, 2007 at 02:39:15 -, Dave Korn wrote: > BTW, you and Tomash should get your stories in synch. He says speculative > loads are ok, just no stores, and wants a kind of half-volatile flag that > would only suppress stores. I think you're already looking one step further > down t

Re: Optimization of conditional access to globals: thread-unsafe?

From: Darryl Miles <[EMAIL PROTECTED]> Date: Mon, 29 Oct 2007 04:53:49 + > What are the issues with "speculative loads" ? The conditional might be protecting whether the pointer is valid and can be dereferenced at all. int *counter; void foo(int counter_is_valid) { if (counter_is_va

Re: Optimization of conditional access to globals: thread-unsafe?

Erik Trulsson wrote: On Sun, Oct 28, 2007 at 06:06:17PM -, Dave Korn wrote: As far as I know, there is no separate 'pthreads' spec apart from what is defined in the Threads section (2.9) of the SUS (http://tinyurl.com/2wdq2u) and what it says about the various pthread_ functions in the sy

Re: Optimization of conditional access to globals: thread-unsafe?

David Miller wrote: The compiler simply cannot speculatively load or store to variables with global visibility. s/with global visibility/with visibility outside the scope of the functional unit the compiler is able to see at compile time/ Which basically means the compiler is king for doing

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, 2007-10-28 at 20:32 -0700, David Miller wrote: > From: skaller <[EMAIL PROTECTED]> > > That is the programmers fault, they should have accessed the > > variable using a const. Failing to do so gives the compiler > > permission to write speculatively. > > I do not agree with you. Yeah,

Re: Optimization of conditional access to globals: thread-unsafe?

Dave Korn wrote: On 29 October 2007 01:38, David Miller wrote: You'll be back. Next week, you'll discover a corner case where caching a shared variable in a register can be a bad thing when one thread uses locks and the other doesn't, and you'll be back to demand that optimisation is remo

Re: Optimization of conditional access to globals: thread-unsafe?

From: skaller <[EMAIL PROTECTED]> Date: Mon, 29 Oct 2007 14:21:10 +1100 > > On Sun, 2007-10-28 at 18:37 -0700, David Miller wrote: > > Even basic correct single-threaded UNIX programs are broken by these > > speculative stores. If I use a conditional test to protect access to > > memory mmap()'d

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, 2007-10-28 at 18:37 -0700, David Miller wrote: > From: "Dave Korn" <[EMAIL PROTECTED]> > Date: Mon, 29 Oct 2007 01:16:07 - > The compiler simply cannot speculatively load or store to variables > with global visibility. I think it can. > Suggesting volatile is totally impractical and

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, 2007-10-28 at 18:34 -0700, David Miller wrote: > More importantly, you cannot break things on people out of mere > convenience. If you want a case of this .. its the ill-considered strict aliasing rules in C. WG14 seems to think C had a strong enough type system to make this rule, but it

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, 2007-10-28 at 21:43 +0100, Bart Van Assche wrote: > On 10/28/07, Robert Dewar <[EMAIL PROTECTED]> wrote: > > Bart Van Assche wrote: > > > > > My opinion is that, given the importance of multithreading, it should > > > be documented in the gcc manual which optimizations can cause trouble >

Re: Optimization of conditional access to globals: thread-unsafe?

From: "Dave Korn" <[EMAIL PROTECTED]> Date: Mon, 29 Oct 2007 02:39:15 - > On 29 October 2007 01:38, David Miller wrote: > > > Even basic correct single-threaded UNIX programs are broken by these > > speculative stores. If I use a conditional test to protect access to > > memory mmap()'d with

Re: Optimization of conditional access to globals: thread-unsafe?

From: "Dave Korn" <[EMAIL PROTECTED]> Date: Mon, 29 Oct 2007 02:39:15 - > BTW, you and Tomash should get your stories in synch. He says > speculative loads are ok, just no stores, and wants a kind of > half-volatile flag that would only suppress stores. I think you're > already looking one

RE: Optimization of conditional access to globals: thread-unsafe?

On 29 October 2007 01:38, David Miller wrote: > From: "Dave Korn" <[EMAIL PROTECTED]> > Date: Mon, 29 Oct 2007 01:16:07 - > >> Thing is, if you disable all optimisations that are potentially >> unsafe in the presence of threads, won't you just get the same >> effect as if you had used volat

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, 2007-10-28 at 22:41 +0100, Richard Guenther wrote: > > OK .. hmm .. well this is the idea, but a more formal proof > > would be cool. > > Doesn't work: Of course it works. > you cannot do such analysis without seeing the whole program. There's no need. A mutex is assumed at each funct

Re: Optimization of conditional access to globals: thread-unsafe?

David Miller wrote: From: Michael Matz <[EMAIL PROTECTED]> Date: Sun, 28 Oct 2007 18:08:23 +0100 (CET) I mean who am I to demand that people write correct code, I must be insane. Correctness is defined by pervasive common usage as much as it is by paper standards. Reading this threa

Re: Optimization of conditional access to globals: thread-unsafe?

From: "Dave Korn" <[EMAIL PROTECTED]> Date: Mon, 29 Oct 2007 01:16:07 - > Thing is, if you disable all optimisations that are potentially > unsafe in the presence of threads, won't you just get the same > effect as if you had used volatile anyway, only on every single > variable in the progr

Re: Optimization of conditional access to globals: thread-unsafe?

From: "Dave Korn" <[EMAIL PROTECTED]> Date: Mon, 29 Oct 2007 01:05:06 - > "My way is right and everyone else's is wrong". I didn't say that. I said that what users do on a broad scale is an important consideration that often trumps paper standards. And yes, users as well as the implemento

Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list

Gerald Pfeifer wrote: > On Sun, 28 Oct 2007, David Daney wrote: > >>> On i386-freebsd the number I identified earlier this year was 700MB, >>> 512MB definitely _not_ being sufficient. I'd be very interested in >>> your measurements, perhaps we can reduce the limit somewhat! >>> >> I r

RE: Optimization of conditional access to globals: thread-unsafe?

On 28 October 2007 18:03, Tomash Brechko wrote: > You got my intent all wrong. Performance matters for both sides. And > currently the only option for multithreaded programs is to use > volatile, which _greatly_ hurts performance. > > What I was trying to say, is that it would be nice to have >

RE: Optimization of conditional access to globals: thread-unsafe?

On 29 October 2007 01:01, David Miller wrote: > From: Michael Matz <[EMAIL PROTECTED]> > Date: Sun, 28 Oct 2007 18:08:23 +0100 (CET) > >> >> You mean like POSIX doesn't count very much for the kernel behaviour? >> > > Nice scarecrow. > > Linux has and will break POSIX where POSIX asks unreaso

Re: Optimization of conditional access to globals: thread-unsafe?

From: Michael Matz <[EMAIL PROTECTED]> Date: Sun, 28 Oct 2007 18:08:23 +0100 (CET) > > You mean like POSIX doesn't count very much for the kernel behaviour? > Nice scarecrow. Linux has and will break POSIX where POSIX asks unreasonable and stupid things. And in particular we will not follow P

Re: Optimization of conditional access to globals: thread-unsafe?

From: Michael Matz <[EMAIL PROTECTED]> Date: Sun, 28 Oct 2007 18:08:23 +0100 (CET) > I mean who am I to demand that people write correct code, > I must be insane. Correctness is defined by pervasive common usage as much as it is by paper standards.

Re: GNU GCC -m32 Problem?

On 10/28/07, Kai Ruottu <[EMAIL PROTECTED]> wrote: > Joseph North wrote: > >I have had a problem getting my "long double" version of > > XEphem 3.7.2 to build under Red Hat Linux Fedora 7, x86_64 > > on an AMD Athlon 64 X2 Dual-Core Processor 5600+ based > > PC. > >It builds OK under Red Ha

Re: Optimization of conditional access to globals: thread-unsafe?

On 10/28/07, skaller <[EMAIL PROTECTED]> wrote: > > On Sun, 2007-10-28 at 18:29 +0100, Richard Guenther wrote: > > On 10/28/07, Erik Trulsson <[EMAIL PROTECTED]> wrote: > > > > Unfortunately it seems that the POSIX standard for threads say that as > > > long > > > as access to a shared variable is

GNU GCC -m32 Problem?

Dear Mr. Randi J. Rost, et al.: I have a copy of your book entitled, OpenGL Shading Language, Second Edition, T 385 R665 2006 MAIN, UT Austin, and learned that you have also worked with Motif. I have had a problem getting my "long double" version of XEphem 3.7.2 to build under Red Hat Linu

Re: Optimization of conditional access to globals: thread-unsafe?

On 10/28/07, Robert Dewar <[EMAIL PROTECTED]> wrote: > Bart Van Assche wrote: > > > My opinion is that, given the importance of multithreading, it should > > be documented in the gcc manual which optimizations can cause trouble > > in multithreaded software (such as (3) and (4)). It should also be

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, 2007-10-28 at 19:36 +0100, Erik Trulsson wrote: > > Having just been pointed to that copy of the SUS, I must agree. I can't > find anything in there saying anything at all about what is required to > safely share data between threads. If that is really so it seems 'pthreads' > are even

Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list

There is something I don't understand: why the problem shows only (mainly) in jc1? If a similar increase had happened in gfortran, I (and others) would have seen it. Dominique

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, 2007-10-28 at 18:29 +0100, Richard Guenther wrote: > On 10/28/07, Erik Trulsson <[EMAIL PROTECTED]> wrote: > > Unfortunately it seems that the POSIX standard for threads say that as long > > as access to a shared variable is protected by a mutex there is no need to > > use 'volatile'. >

Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list

On Sun, 28 Oct 2007, David Daney wrote: >> On i386-freebsd the number I identified earlier this year was 700MB, >> 512MB definitely _not_ being sufficient. I'd be very interested in >> your measurements, perhaps we can reduce the limit somewhat! > I regularly bootstrap c,c++,java on a mips-linu

Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list

On Sun, 28 Oct 2007, Richard Guenther wrote: >> Don't be sorry, I can reproduce a compilation time surge for libjava on >> my machine (AMD64, 2.4 GHz, 1 GB). In particular, HTML_401F.o now >> takes 40 min to compile for each version of the library. >> >> The surge comes from the fix for PR tree-

Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list

On 10/28/07, Eric Botcazou <[EMAIL PROTECTED]> wrote: > > I'm working on it. > > Thanks. However, don't we simply void the benefit of memory partitioning by > recursing on the MPTs? Yes. At least what compile-time is concerned (we still have less VOPs). The patch I just committed avoids some/mo

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, Oct 28, 2007 at 06:06:17PM -, Dave Korn wrote: > On 28 October 2007 17:39, Erik Trulsson wrote: > > > On Sun, Oct 28, 2007 at 01:10:00PM -0400, Robert Dewar wrote: > >> Erik Trulsson wrote: > >> > >>> Unfortunately it seems that the POSIX standard for threads say that as > >>> long as

Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list

> I'm working on it. Thanks. However, don't we simply void the benefit of memory partitioning by recursing on the MPTs? -- Eric Botcazou

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, Oct 28, 2007 at 21:03:09 +0300, Tomash Brechko wrote: > What I was trying to say, is that it would be nice to have > -fno-thread-unsafe-optimization option. Rather clear -fno-speculative-store, in the light of mprotect() and non-writable memory. -- Tomash Brechko

RE: Optimization of conditional access to globals: thread-unsafe?

On 28 October 2007 17:39, Erik Trulsson wrote: > On Sun, Oct 28, 2007 at 01:10:00PM -0400, Robert Dewar wrote: >> Erik Trulsson wrote: >> >>> Unfortunately it seems that the POSIX standard for threads say that as >>> long as access to a shared variable is protected by a mutex there is no >>> need

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, Oct 28, 2007 at 17:51:57 +0100, Michael Matz wrote: > I was merely showing that this transformation _does_ matter in some cases > to refute opposite claims which seemed to be expressed too airy in this > thread. You got my intent all wrong. Performance matters for both sides. And curre

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, Oct 28, 2007 at 06:29:44PM +0100, Richard Guenther wrote: > On 10/28/07, Erik Trulsson <[EMAIL PROTECTED]> wrote: > > On Sun, Oct 28, 2007 at 03:03:46PM -, Dave Korn wrote: > > > On 28 October 2007 13:32, Bart Van Assche wrote: > > > > > > > Requiring that all > > > > thread-shared var

Re: Optimization of conditional access to globals: thread-unsafe?

Erik Trulsson <[EMAIL PROTECTED]> writes: > I don't have access to the POSIX standard itself See . Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerpr

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, Oct 28, 2007 at 01:10:00PM -0400, Robert Dewar wrote: > Erik Trulsson wrote: > >> Unfortunately it seems that the POSIX standard for threads say that as >> long >> as access to a shared variable is protected by a mutex there is no need to >> use 'volatile'. > > How does it say this, in s

Re: Optimization of conditional access to globals: thread-unsafe?

On 10/28/07, Erik Trulsson <[EMAIL PROTECTED]> wrote: > On Sun, Oct 28, 2007 at 03:03:46PM -, Dave Korn wrote: > > On 28 October 2007 13:32, Bart Van Assche wrote: > > > > > Requiring that all > > > thread-shared variables should be declared volatile is completely > > > unacceptable. > > > >

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, Oct 28, 2007 at 03:03:46PM -, Dave Korn wrote: > On 28 October 2007 13:32, Bart Van Assche wrote: > > > Requiring that all > > thread-shared variables should be declared volatile is completely > > unacceptable. > > Any variable that may be altered by an external unpredictable asyn

Re: Optimization of conditional access to globals: thread-unsafe?

Erik Trulsson wrote: Unfortunately it seems that the POSIX standard for threads say that as long as access to a shared variable is protected by a mutex there is no need to use 'volatile'. How does it say this, in some semantically precise way, or with hand waving as in this sentence. This me

Re: Optimization of conditional access to globals: thread-unsafe?

Hi, On Fri, 26 Oct 2007, David Miller wrote: > Also, it bears repeating that whatever performance argument you make for > or against this issue matters little if it breaks lots of existing and > working code. It matters insofar as that existing and working code is broken in a strict sense. A

Re: Optimization of conditional access to globals: thread-unsafe?

Hi, On Fri, 26 Oct 2007, Tomash Brechko wrote: > On Fri, Oct 26, 2007 at 21:45:03 +0400, Tomash Brechko wrote: > > Note that it doesn't cancel cmoves, as those are loads, not stores. > > I just checked with x86 instruction reference, CMOVcc is reg->reg or > mem->reg, never reg->mem. You know Go

Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list

On 10/28/07, Eric Botcazou <[EMAIL PROTECTED]> wrote: > > I never noticed that this part was so long and I was too eager to do > > something else with the CPU. Sorry for the noise. > > Don't be sorry, I can reproduce a compilation time surge for libjava on my > machine (AMD64, 2.4 GHz, 1 GB). In p

Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list

> I never noticed that this part was so long and I was too eager to do > something else with the CPU. Sorry for the noise. Don't be sorry, I can reproduce a compilation time surge for libjava on my machine (AMD64, 2.4 GHz, 1 GB). In particular, HTML_401F.o now takes 40 min to compile for each v

Re: GCC 4.3 release schedule

Dennis Clarke wrote: Is "correctness" a feature ? Yes, but not one that gets merged in during stage 1 :) I would like to see a nice clean GCC 4.2.x before GCC 4.3.zero even gets thought of. Why would one simply branch towards the next release when the previous one still needs some work

Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list

Gerald Pfeifer wrote: > On Sun, 28 Oct 2007, David Daney wrote: > >> You need at least 256MB of memory to compile HTML_401F. A lot of time >> is also useful. If the system is not thrashing, I would give it a >> couple of hours before calling it broken. >> > > Have we reduced memory consum

RE: Optimization of conditional access to globals: thread-unsafe?

On 28 October 2007 13:32, Bart Van Assche wrote: > Requiring that all > thread-shared variables should be declared volatile is completely > unacceptable. Any variable that may be altered by an external unpredictable asynchronous 'force majeure' must be declared volatile or the behaviour is un

Re: Optimization of conditional access to globals: thread-unsafe?

On Sun, Oct 28, 2007 at 09:47:36 -0400, Robert Dewar wrote: > Bart Van Assche wrote: > > >Requiring that all thread-shared variables should be declared > >volatile is completely unacceptable. > > Why is this unacceptable .. seems much better to me than writing > undefined stuff. There's a parall

Re: Optimization of conditional access to globals: thread-unsafe?

Bart Van Assche writes: > We need a solution today for the combination of C/C++ and POSIX > threads, we can't wait for the respective language standardization > committees to come up with a solution. And, in the proposed memory model, I believe we have one. If there is some reason you believe

Re: Optimization of conditional access to globals: thread-unsafe?

Bart Van Assche wrote: My opinion is that, given the importance of multithreading, it should be documented in the gcc manual which optimizations can cause trouble in multithreaded software (such as (3) and (4)). It should also be documented which compiler flags must be used to disable optimizati

Re: Optimization of conditional access to globals: thread-unsafe?

On 10/27/07, Florian Weimer <[EMAIL PROTECTED]> wrote: > > Anyway, not reordering across function calls is not sufficient to get > sane threading semantics (IIRC, this is also explained in detail in Hans > Boehm's paper). Hello Florian, In Hans Boehm's paper the following issues are identified: 1

Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list

On Sun, 28 Oct 2007, David Daney wrote: > You need at least 256MB of memory to compile HTML_401F. A lot of time > is also useful. If the system is not thrashing, I would give it a > couple of hours before calling it broken. Have we reduced memory consumption recently? On i386-freebsd the number

Re: -fno-tree-cselim not working?

On Fri, Oct 26, 2007 at 01:23:15PM -0700, Ian Lance Taylor wrote: > Andi Kleen <[EMAIL PROTECTED]> writes: > > > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > > > > > This code isn't going to be a problem, because spin_unlock presumably > > > includes a memory barrier. > > > > At least in the

Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list

David, > ... I would give it a couple of hours before calling it broken. You are right, a small "couple" of hours is need for the three stages: slightly less than two hours on my machine (1.8Ghz G5). I never noticed that this part was so long and I was too eager to do something else with the CPU.

Re: Infinite loop in compiling javax/swing/text/html/parser/HTML_401F.list

Dominique Dhumieres wrote: > On powerpc-apple-darwin8, I killed jc1 after it took over 37:29.81 at: > > ... > echo ../../../../gcc-4.3-work/libjava/classpath/lib/gnu/javax/swing/text/html/parser/HTML_401F*.class> gnu/javax/swing/text/html/parser/HTML_401F.list > /bin/sh ./libtool --tag=GCJ --mode=c