Re: optimising recursive functions

On Fri, 2007-10-26 at 20:26 -0400, Robert Dewar wrote: > skaller wrote: > > > So I am guessing the Felix version is lucky there are > > no gratuitous temporaries to be saved when this happens, > > and the C code is unlucky and there are. > > > > Maybe someone who knows how the optimiser works ca

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

On Fri, 2007-10-26 at 17:19 -0700, David Daney wrote: > skaller wrote: > > On Fri, 2007-10-26 at 14:24 -0700, Ian Lance Taylor wrote: > >> Michael Matz <[EMAIL PROTECTED]> writes: > > > >> This is basically a public relations exercise. I doubt this > >> optimization is especially important, so I

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

David Daney wrote: They did use pthreads though. Code correctness in this case does not depend on the number of processor cores. True, but in practice "real" multiprocessing shows up such bugs more often ... David Daney

Re: optimising recursive functions

skaller wrote: So I am guessing the Felix version is lucky there are no gratuitous temporaries to be saved when this happens, and the C code is unlucky and there are. Maybe someone who knows how the optimiser works can comment? One problem with departing from the ABI even on a local level lik

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

skaller wrote: On Fri, 2007-10-26 at 14:24 -0700, Ian Lance Taylor wrote: Michael Matz <[EMAIL PROTECTED]> writes: This is basically a public relations exercise. I doubt this optimization is especially important, so I think it's OK to disable it to keep people happy. Even though the optimiz

[tuples] Merge with mainline @129659

Had to disable the new structure reorg pass for now. Tested on x86_64.

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

On Fri, 2007-10-26 at 14:24 -0700, Ian Lance Taylor wrote: > Michael Matz <[EMAIL PROTECTED]> writes: > This is basically a public relations exercise. I doubt this > optimization is especially important, so I think it's OK to disable it > to keep people happy. Even though the optimization has b

Re: -fno-tree-cselim not working?

Samuel Tardieu <[EMAIL PROTECTED]> writes: > Would a patch such as the following be acceptable? > > http://article.gmane.org/gmane.comp.gcc.patches/151261 No. There is nothing wrong with applying these optimizations to pseudo-regs, which is the common case. Ian

optimising recursive functions

I have occasionally examined asm generated by gcc on my amd64, and it appears gcc is not optimising recursive functions very well, though I'm not sure. I find in code like: int f(int x) { ... f(y) ... } that gcc generates an extern ABI compliant function f, which is recursively called w

Re: -fno-tree-cselim not working?

On Fri, 2007-10-26 at 13:23 -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 Linux

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

On Fri, 2007-10-26 at 23:03 +0400, Tomash Brechko wrote: > On Sat, Oct 27, 2007 at 03:06:21 +1000, skaller wrote: > > And what do you do if you do not KNOW what the storage class is, > > which is the case 99.99% of the time in C++ member functions? > > I'm not quite sure what you mean here. If

Re: -fno-tree-cselim not working?

> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: Dave> I certainly won't object to any move to prohibit the Dave> read-conditional-add-write (and related) optimisation(s) when Dave> compiling with an option that explicitly specifies that we are Dave> compiling multi-threaded code. There are

Re: Removal of pre-ISO C++ items from include/backwards

On Fri, 2007-10-26 at 19:41 +0100, Jonathan Wakely wrote: > On 26/10/2007, skaller <[EMAIL PROTECTED]> wrote: > > This would not be correct. When you deprecate C++2000 features, > > you should retain them in such a way that a compiler switch > > such as --std=C++2000 will ensure they're visible i

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

From: Michael Matz <[EMAIL PROTECTED]> Date: Fri, 26 Oct 2007 19:04:10 +0200 (CEST) > Certainly some suggestions for another memory model look quite > similar to considering all non-automatic objects as volatile, at > which point the question should be allowed why not simply using > 'volatile'. T

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

On 26 Oct 2007 15:20:01 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > It appears that the draft C++0x memory model prohibits speculative > stores. Well, sure, might as well. Though the final form of the standard may be different, I doubt that this case will change significantly.

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

Jakub Jelinek <[EMAIL PROTECTED]> writes: > On Fri, Oct 26, 2007 at 02:24:21PM -0700, Ian Lance Taylor wrote: > > What do people think of this patch? This seems to fix the problem > > case without breaking Michael's case. It basically avoids store > > speculation: we don't write to a MEM unless

gcc-4.3-20071026 is now available

Snapshot gcc-4.3-20071026 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20071026/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk

Re: -fno-tree-cselim not working?

From: "Dave Korn" <[EMAIL PROTECTED]> Date: Fri, 26 Oct 2007 17:35:44 +0100 > On 26 October 2007 17:28, Andrew Haley wrote: > > > Richard Guenther writes: > > > > > > > > This is legal POSIX threads code: counter is not accessed when we do > > > > not hold the mutex. According to POSIX we do

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

On 26 Oct 2007 15:20:01 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > It appears that the draft C++0x memory model prohibits speculative > stores. > > Therefore I now think we should aim toward prohibiting them > unconditionally. That memory model is just a draft. But I think we > should

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

"Diego Novillo" <[EMAIL PROTECTED]> writes: > On 26 Oct 2007 14:24:21 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > > What do people think of this patch? This seems to fix the problem > > case without breaking Michael's case. It basically avoids store > > speculation: we don't write to

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

On Fri, Oct 26, 2007 at 02:24:21PM -0700, Ian Lance Taylor wrote: > What do people think of this patch? This seems to fix the problem > case without breaking Michael's case. It basically avoids store > speculation: we don't write to a MEM unless the function > unconditionally writes to the MEM an

Re: GCC 4.3 release schedule

On Fri, Oct 26, 2007 at 10:28:35PM +0200, Martin Michlmayr wrote: > * Joe Buck <[EMAIL PROTECTED]> [2007-10-26 11:44]: > > You might want to hold off on investing the work in fixing those 550 > > packages, because I think it's premature to consider the header > > "cleanup" final. > > > > Can you e

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

On Fri, Oct 26, 2007 at 02:24:21PM -0700, Ian Lance Taylor wrote: > What do people think of this patch? This seems to fix the problem > case without breaking Michael's case. It basically avoids store > speculation: we don't write to a MEM unless the function > unconditionally writes to the MEM an

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

On 26 Oct 2007 14:24:21 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > What do people think of this patch? This seems to fix the problem > case without breaking Michael's case. It basically avoids store > speculation: we don't write to a MEM unless the function > unconditionally writes to

Re: -fno-tree-cselim not working?

Andrew Haley <[EMAIL PROTECTED]> writes: > Ian Lance Taylor writes: > > > As I understand it, the draft C++0x memory model has acquire release > > semantics for annotated variables. Of course, it wouldn't help the > > originalk test case unless the global variable was annotated. > > Mmm, but

Re: How widely used are and ?

On Thu, Oct 25, 2007 at 09:40:06PM -0700, Joe Buck wrote: > The thread arguing about this has gone on for a while, so I think > it's time to gather some data to answer the question of just how bad > it will be if we accept the decision to move ext/hash_set and ext_hash_map > into a different direct

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

Michael Matz <[EMAIL PROTECTED]> writes: > Both, the assessment of far-stretchedness and these numbers seem to be > invented ad hoc. The latter is irrelevant (it's not interesting how many > cases there are, but how important those cases which occur are, for some > metric, let's say performanc

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

* Andrew Haley: > The core problem here seems to be that the "C with threads" memory > model isn't sufficiently well-defined to make a determination > possible. You're assuming that you have no resposibility to mark > shared memory protected by a mutex as volatile, but I know of nothing > in the

Re: GCC 4.3 release schedule

> I added more entries to gcc-4.2/buildstat.html. > > Bootstrap and test results for 4.2.2: > > i686-pc-linux-gnu (Slackware 12.0, kernel 2.6.22, glibc 2.5) > > Test results for 4.2.2: > > hppa2.0w-hp-hpux11.11 > hppa64-hp-hpux11.11 > hppa-unknown-linux-gnu > i386-unknown-freebsd5.5 > i

Re: Creating a live, all-encompassing architectural document for GCC

On 10/26/07, Eric Weddington <[EMAIL PROTECTED]> wrote: > > It certainly meets the navigable requirement. I'm sure all of you have seen > other examples as well. Thanks. I'll take a look. > > But you also want the user to be able to change an inter

Re: GCC 4.3 release schedule

Mark Mitchell wrote: Andrew MacLeod wrote: we can at least make projected dates known so we have something firmer than "at some point in the future" :-) As RM, I try to take into account what I know about when distributors will be applying effort, but I must absolutely avoid in any wa

Re: GCC 4.3 release schedule

On Fri, 2007-10-26 at 19:54 +0200, Eric Botcazou wrote: > > When I look at the Build status page I see no one has posted a result > > there for GCC 4.2.2 : > > > > Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html > > Here are a couple of posts by Kaveh: > http://gcc.gnu.org/ml/gcc-testre

Re: GCC 4.3 release schedule

* Joe Buck <[EMAIL PROTECTED]> [2007-10-26 11:44]: > You might want to hold off on investing the work in fixing those 550 > packages, because I think it's premature to consider the header > "cleanup" final. > > Can you estimate how many of the broken packages use > or ? Sorry I wasn't being clea

Re: -fno-tree-cselim not working?

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 Linux kernel and also in glibc for mutexes locks are just > plain > function call

Re: problem with iv folding

> you cannot add two pointers. Please create a PR for this and assign it > to me. Done, pr 33915 Note that m32c-elf needs --with-newlib Thanks!

Re: -fno-tree-cselim not working?

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 Linux kernel and also in glibc for mutexes locks are just plain function calls, which are not necessarily full memory barriers. -Andi

RE: Creating a live, all-encompassing architectural document for GCC

> -Original Message- > From: Diego Novillo [mailto:[EMAIL PROTECTED] > Sent: Friday, October 26, 2007 11:10 AM > To: gcc@gcc.gnu.org > Subject: RFC: Creating a live, all-encompassing architectural > document for GCC > > > It should be easy for an individual maintainer (or even user)

Re: -fno-tree-cselim not working?

"Richard Guenther" <[EMAIL PROTECTED]> writes: > > I hope we're not trying to support such w/o volatile counter. Whatever > POSIX says, this would pessimize generic code too much. It is dubious this transformation is an optimization at all for memory. e.g. consider the case counter is not in ca

Re: RTL/VCG inconsistency (the check_match.7758 case)

On 10/24/07, Sunzir Deepur <[EMAIL PROTECTED]> wrote: > Any idea on why this inconsistency happen and how to solve it > (probably the VCG dumper should somehow use "check_match.7758" as the base > of the function name and not "check_match") ? Feel free to offer patches to fix this inconsistency.

Re: RFC: Creating a live, all-encompassing architectural document for GCC

On 10/26/07, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: > Maybe a possible approach would be to use literate programming > techniques; By previous experience (still limited), I would believe that > it would be more worthwhile on the interface files (ie the *.h files, > some *.opt, etc...) tha

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

On Sat, Oct 27, 2007 at 03:06:21 +1000, skaller wrote: > err .. what about the heap?? The heap are objects for which the addresses were taken. So they can be shared. But I haven't yet seen that the optimization we discuss is being applied to the object accessed though the pointer (see my reply t

Re: GCC 4.3 release schedule

On Fri, Oct 26, 2007 at 08:20:02PM +0200, Martin Michlmayr wrote: > * Richard Guenther <[EMAIL PROTECTED]> [2007-10-26 17:51]: > > Yes. I think Ubuntu is on track for 4.3 as well, most likely Debian, too. > > I've been testing 4.3 on a number of architectures Debian supports and > filings bugs.

Re: Removal of pre-ISO C++ items from include/backwards

On 26/10/2007, skaller <[EMAIL PROTECTED]> wrote: > On Thu, 2007-10-25 at 22:56 +0100, Jonathan Wakely wrote: > > The plan is to also move auto_ptr and the old bind1st/bind2nd function > > binders to backward, if/when they are deprecated in C++0x, which would > > give them the same status as (depr

Re: GCC 4.3 release schedule

>> Why isn't the main page for build reports updated ? > > Will do. > >> It *looks* like no one ( me too ) is getting clean builds. > > The GCC 4.2.x compiler is in pretty good shape on SPARC/Solaris, modulo the > libgomp problems on Solaris 10 with the Sun tools. You need to use the GNU > tools

Re: GCC 4.3 release schedule

* Richard Guenther <[EMAIL PROTECTED]> [2007-10-26 17:51]: > Yes. I think Ubuntu is on track for 4.3 as well, most likely Debian, too. I've been testing 4.3 on a number of architectures Debian supports and filings bugs. There are still many that haven't been resolved yet. Of course, gcc 4.3 also

Re: GCC 4.3 release schedule

> Why isn't the main page for build reports updated ? Will do. > It *looks* like no one ( me too ) is getting clean builds. The GCC 4.2.x compiler is in pretty good shape on SPARC/Solaris, modulo the libgomp problems on Solaris 10 with the Sun tools. You need to use the GNU tools if you care

Re: GCC 4.3 release schedule

>> When I look at the Build status page I see no one has posted a result >> there for GCC 4.2.2 : >> >> Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html > > Here are a couple of posts by Kaveh: > http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00388.html > http://gcc.gnu.org/ml/gcc-te

Re: GCC 4.3 release schedule

> When I look at the Build status page I see no one has posted a result > there for GCC 4.2.2 : > > Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html Here are a couple of posts by Kaveh: http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00388.html http://gcc.gnu.org/ml/gcc-testresults/20

Re: RFC: Creating a live, all-encompassing architectural document for GCC

On Fri, 2007-10-26 at 19:34 +0200, Basile STARYNKEVITCH wrote: > Diego Novillo wrote: > I am more thinking loud than actually believing that it would be a good > idea to switch to literate programming; I have mixed feelings towards > this approach, which has been extensively used in the C-- com

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

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 God's deed when you see it. :) -- Tomash Brechko

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

On Fri, Oct 26, 2007 at 19:04:10 +0200, Michael Matz wrote: > int f(int M, int *mc, int *mpp, int *tpmm, int *ip, int *tpim, int *dpp, > int *tpdm, int xmb, int *bp, int *ms) > { > int k, sc; > for (k = 1; k <= M; k++) > { > mc[k] = mpp[k-1] + tpmm[k-1]; > if ((sc = ip[k

Re: Removal of pre-ISO C++ items from include/backwards

On Thu, 25 Oct 2007, Joe Buck wrote: > > Has anyone checked yet on the impact on a Debian distribution of > > these proposed changes (and even for things that are checked in, > > they should only be thought of as "proposed" at this point)? On Fri, Oct 26, 2007 at 10:21:57AM +0200, Richard Guenthe

Re: How widely used are and ?

I wrote: > > The thread arguing about this has gone on for a while, so I think > > it's time to gather some data to answer the question of just how bad > > it will be if we accept the decision to move ext/hash_set and ext_hash_map > > into a different directory and to deprecate them. > > > > Any

Re: -fno-tree-cselim not working?

Ian Lance Taylor writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > > The problem is code like this: > > > > int counter; > > > > ... > > > > if (we_hold_counters_mutex) > > counter++; > > > > This is legal POSIX threads code: counter is not accessed when we do > > not h

Re: RFC: Creating a live, all-encompassing architectural document for GCC

Diego Novillo wrote: This idea is still very raw in my mind, so apologies in advance for being deliberately vague. For the last few weeks I have been thinking on ways to address the sorry state of our internal documentation. We all agree that none of us has global knowledge of all aspects of th

RE: -fno-tree-cselim not working?

On Fri, 2007-10-26 at 17:31 +0100, Dave Korn wrote: > On 26 October 2007 17:11, Andrew Haley wrote: > Is the problem that POSIX doesn't make the distinction between as-if and > actual behaviour that is such an essential part of the C standard? The 'as-if' rule is present in ALL Standards of al

Re: -fno-tree-cselim not working?

skaller <[EMAIL PROTECTED]> writes: > On Fri, 2007-10-26 at 08:27 -0700, Ian Lance Taylor wrote: > > skaller <[EMAIL PROTECTED]> writes: > > > > > > I understand that's the common meaning .. but the semantics > > > aren't specified for ISO C/C++. > > > > Sure they are. In the C99 standard look

Re: -fno-tree-cselim not working?

Andrew Haley <[EMAIL PROTECTED]> writes: > The problem is code like this: > > int counter; > > ... > > if (we_hold_counters_mutex) > counter++; > > This is legal POSIX threads code: counter is not accessed when we do > not hold the mutex. According to POSIX we do not have to declare > v

RFC: Creating a live, all-encompassing architectural document for GCC

This idea is still very raw in my mind, so apologies in advance for being deliberately vague. For the last few weeks I have been thinking on ways to address the sorry state of our internal documentation. We all agree that none of us has global knowledge of all aspects of the compiler. It's just

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

On Fri, 2007-10-26 at 20:17 +0400, Tomash Brechko wrote: > cases. Only globals, or locals which address was passed to some > function, should be treated specially. err .. what about the heap?? And what do you do if you do not KNOW what the storage class is, which is the case 99.99% of the ti

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

Hi, On Fri, 26 Oct 2007, Tomash Brechko wrote: > It was already said that instead of disallowing all optimization with > volatile, the optimization itself may be made a bit differently. > Besides, the concern that it will hurt performance at large is a bit > far-stretched. You still may speculat

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

I thought it was pretty clear in intent: the compiler will emit exactly one machine load/store operation for any rvalue reference/lvalue assignment (respectively) in the source, at the exact sequence point in the generated code corresponding to the location of the reference

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

> "Sam" == Samuel Tardieu <[EMAIL PROTECTED]> writes: Sam> In the following example, is the access to "Shared" considered Sam> unsynchronized even though what looks like a proper lock is used Sam> around it? Call to Always_Unlock was incorrect in the previous example, a fixed one exhibiting t

RE: -fno-tree-cselim not working?

Dave Korn writes: > On 26 October 2007 17:11, Andrew Haley wrote: > > > > Perhaps I've jumped into the wrong one of the two near-identical > > > threads we have going on this, but my understanding of the original > > > complaint was that gcc writes to the variable regardless of whether

Re: GCC 4.3 release schedule

> Mark Mitchell wrote: >> As I said in >> my status report, our practice has been to cut the release branch when >> we reach 100 regressions, and release 2-4 months after that point, >> depending on quality on the branch. To be honest, I'd rather wait >> longer to make the branch -- but there ten

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

Hi, On Sat, 27 Oct 2007, skaller wrote: > The point is -- there is no new rule here, and no definition > of what a volatile semantics is: volatile variables have > the SAME 'semantics' as any other variable. If I write: > > int a = 1; > printf("%d", a); > int b = 2; > pri

RE: -fno-tree-cselim not working?

On 26 October 2007 17:28, Andrew Haley wrote: > Richard Guenther writes: > > > > > > This is legal POSIX threads code: counter is not accessed when we do > > > not hold the mutex. According to POSIX we do not have to declare > > > volatile memory that we only access when we hold a mutex. > >

Re: GCC 4.3 release schedule

> On 10/26/07, Dennis Clarke <[EMAIL PROTECTED]> wrote: >>On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: >> >> Richard Guenther wrote: >> >> > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: >> >> >> >> >> > >> > ... when we think it's ready. It doesn't help anyone to declare victor

RE: -fno-tree-cselim not working?

On 26 October 2007 17:11, Andrew Haley wrote: > > Perhaps I've jumped into the wrong one of the two near-identical > > threads we have going on this, but my understanding of the original > > complaint was that gcc writes to the variable regardless of whether > > it needs an update or not, an

Re: -fno-tree-cselim not working?

On Fri, 2007-10-26 at 08:27 -0700, Ian Lance Taylor wrote: > skaller <[EMAIL PROTECTED]> writes: > > > I understand that's the common meaning .. but the semantics > > aren't specified for ISO C/C++. > > Sure they are. In the C99 standard look at the definition of sequence > points (5.1.2.3) an

Re: -fno-tree-cselim not working?

Richard Guenther writes: > > > > This is legal POSIX threads code: counter is not accessed when we do > > not hold the mutex. According to POSIX we do not have to declare > > volatile memory that we only access when we hold a mutex. > > I hope we're not trying to support such w/o volatile c

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

On Fri, 2007-10-26 at 16:24 +0100, Dave Korn wrote: > On 26 October 2007 16:15, Robert Dewar wrote: > > > One problem at the language standards level is that you can't easily > > talk about loads and stores, since you are defining an as-if semantic > > model, and if you make a statement about loa

Re: -fno-tree-cselim not working?

On 10/26/07, Andrew Haley <[EMAIL PROTECTED]> wrote: > Dave Korn writes: > > On 26 October 2007 16:27, Andrew Haley wrote: > > > > > Dave Korn writes: > > > > On 26 October 2007 15:59, Ian Lance Taylor wrote: > > > > > > > Sure. But the argument that gcc is doing something wrong stands up

Re: GCC 4.3 release schedule

Mark Mitchell wrote: As I said in my status report, our practice has been to cut the release branch when we reach 100 regressions, and release 2-4 months after that point, depending on quality on the branch. To be honest, I'd rather wait longer to make the branch -- but there tends to be intense

Re: GCC 4.3 release schedule

On 10/26/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > I've found schedules for GCC to be very hard to predict. As I said in > my status report, our practice has been to cut the release branch when > we reach 100 regressions, and release 2-4 months after that point, > depending on quality on th

RE: -fno-tree-cselim not working?

Dave Korn writes: > On 26 October 2007 16:27, Andrew Haley wrote: > > > Dave Korn writes: > > > On 26 October 2007 15:59, Ian Lance Taylor wrote: > > > > > Sure. But the argument that gcc is doing something wrong stands up > > > > just fine even we just test a global variable. The arg

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

On Fri, Oct 26, 2007 at 17:00:28 +0100, Dave Korn wrote: > > * Disallow speculative stores on potentially shared objects. > > * Disallow reading and re-writing of unrelated objects. (For > > instance, if you have struct S{ char a,b; }; it is not OK to > > modify b by rea

Re: GCC 4.3 release schedule

On 10/26/07, Dennis Clarke <[EMAIL PROTECTED]> wrote: > > > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > >> Richard Guenther wrote: > >> > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > >> >> > > > > > ... when we think it's ready. It doesn't help anyone to declare victory >

Re: GCC 4.3 release schedule

Andrew MacLeod wrote: > we can at least make projected dates known so we have something firmer > than "at some point in the future" :-) The canonical rule of project management is: "Features, Schedule, Cost: Pick At Most 2." :-) In other words, you can decide what features you want and when you

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

On Fri, 2007-10-26 at 16:05 +0200, Bart Van Assche wrote: > On 10/22/07, Andrew Haley wrote: > I agree that according to the C and C++ language standards, any > variable shared over threads should be declared volatile. No, they say nothing about multi-threaded programs. > My opinion is that it

Re: GCC 4.3 release schedule

> On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: >> Richard Guenther wrote: >> > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: >> >> > > ... when we think it's ready. It doesn't help anyone to declare victory > and release 4.3.0 when it still miscompiles the kernel (not that I k

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

On 26 October 2007 16:51, Tomash Brechko wrote: > On Fri, Oct 26, 2007 at 08:32:07 -0700, Ian Lance Taylor wrote: >> The language standard does not forbid speculative stores to non-atomic >> objects. > * Disallow speculative stores on potentially shared objects. > * Disallow reading a

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

On 26/10, Robert Dewar wrote: | Of course in Ada there is a clear notion of threads semantic, and | a clear definition of what the meaning of code is in the presence | of threads, so the specific situation discussed here is easy to | deal with (though Ada takes the view that unsychronized shared a

RE: -fno-tree-cselim not working?

On 26 October 2007 16:27, Andrew Haley wrote: > Dave Korn writes: > > On 26 October 2007 15:59, Ian Lance Taylor wrote: > > > Sure. But the argument that gcc is doing something wrong stands up > > > just fine even we just test a global variable. The argument that gcc > > > is doing somethin

Re: GCC 4.3 release schedule

On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > >> > >> Nov 14th - we'd like to start building F9 with a 4.3 compiler. Ideally > >> we'd have a branch cut no later than that and starting to stabilize > >>

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

On Fri, Oct 26, 2007 at 08:32:07 -0700, Ian Lance Taylor wrote: > The language standard does not forbid speculative stores to non-atomic > objects. That's why there's a proposal to refine the language. I was meaning the folloing: http://www.artima.com/cppsource/threads_meeting.html: Hans Bo

Re: -fno-tree-cselim not working?

Ian Lance Taylor writes: > As I understand it, the draft C++0x memory model has acquire release > semantics for annotated variables. Of course, it wouldn't help the > originalk test case unless the global variable was annotated. Mmm, but one of the authors of the draft C++0x memory model tell

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

Tomash Brechko <[EMAIL PROTECTED]> writes: > - the compiler should not introduce speculative stores to the shared > objects. This is what my original question was about. I haven't > read all the papers yet, so one thing is still unclear to me: it > seems like atomic variables will

Re: -fno-tree-cselim not working?

skaller <[EMAIL PROTECTED]> writes: > On Fri, 2007-10-26 at 07:58 -0700, Ian Lance Taylor wrote: > > skaller <[EMAIL PROTECTED]> writes: > > > > > As I understand it volatile is typically used as a 'hint' > > > to the compiler that there could be aliases it cannot see. > > > This is independent o

RE: -fno-tree-cselim not working?

Dave Korn writes: > On 26 October 2007 15:59, Ian Lance Taylor wrote: > > > Andreas Schwab <[EMAIL PROTECTED]> writes: > > > >> Ian Lance Taylor <[EMAIL PROTECTED]> writes: > >> > >>> The above code happens to use pthread_mutex_trylock, but there is no > >>> need for that. > >> > >> p

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

On 26 October 2007 16:15, Robert Dewar wrote: > One problem at the language standards level is that you can't easily > talk about loads and stores, since you are defining an as-if semantic > model, and if you make a statement about loads and stores, any other > sequence which behaves as if that se

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

"Bart Van Assche" <[EMAIL PROTECTED]> writes: > * As known the compiler may reorder function calls and assignments > to non-volatile variables if the compiler can prove that the called > function won't modify that variable. This becomes problematic if the > variable is modified by more than one

RE: -fno-tree-cselim not working?

On 26 October 2007 15:59, Ian Lance Taylor wrote: > Andreas Schwab <[EMAIL PROTECTED]> writes: > >> Ian Lance Taylor <[EMAIL PROTECTED]> writes: >> >>> The above code happens to use pthread_mutex_trylock, but there is no >>> need for that. >> >> pthread_mutex_trylock is special, because POSIX s

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

Andrew Haley wrote: Hmmm. This is an interesting idea, but it sounds to me as though it's somewhat at variance with what is proposed by the C++ threads working group. In any case, gcc will certainly implement whatever the standards committees come up with, but that is probably two years away.

Re: -fno-tree-cselim not working?

On Fri, 2007-10-26 at 07:58 -0700, Ian Lance Taylor wrote: > skaller <[EMAIL PROTECTED]> writes: > > > As I understand it volatile is typically used as a 'hint' > > to the compiler that there could be aliases it cannot see. > > This is independent of the use suggesting asynchronous changes > > in

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

Bart Van Assche writes: > On 10/22/07, Andrew Haley wrote: > > > The core problem here seems to be that the "C with threads" memory > > model isn't sufficiently well-defined to make a determination > > possible. You're assuming that you have no responsibility to mark > > shared memory prot

Re: -fno-tree-cselim not working?

Andreas Schwab <[EMAIL PROTECTED]> writes: > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > > The above code happens to use pthread_mutex_trylock, but there is no > > need for that. > > pthread_mutex_trylock is special, because POSIX says it is a memory > synchronisation point (see section 4.1

Re: -fno-tree-cselim not working?

skaller <[EMAIL PROTECTED]> writes: > As I understand it volatile is typically used as a 'hint' > to the compiler that there could be aliases it cannot see. > This is independent of the use suggesting asynchronous changes > in a hardware port for example, although the effect is the same. Not real

Re: -fno-tree-cselim not working?

David Miller <[EMAIL PROTECTED]> writes: > This is not a game or some fun theoretical discussion about language > semantics. People will be harmed and lose lots of their own personal > time debugging these kinds of things if GCC generates code like this. > It's unreasonable, regardless of what th

Re: -fno-tree-cselim not working?

Jakub Jelinek <[EMAIL PROTECTED]> writes: > Unsafe optimizations in loop IM, if conversion, etc. really either need > to be conditionalized on some new switch whether code should be thread > safe or not, or just need to be disabled altogether. Of course if > gcc can prove the variable is written

  1   2   >