On 11/4/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> On Sun, 4 Nov 2007, Bart Van Assche wrote:
> >
> > Has it already been decided who will do this audit, and when this
> > audit will happen ? Has a target date been set when this audit should
> > be complete, or is the completion of this audi
Linus Torvalds writes:
>
>
> On Sun, 4 Nov 2007, Bart Van Assche wrote:
> >
> > Has it already been decided who will do this audit, and when this
> > audit will happen ? Has a target date been set when this audit
> > should be complete, or is the completion of this audit a
> > requiremen
On Sun, 4 Nov 2007, Bart Van Assche wrote:
>
> Has it already been decided who will do this audit, and when this
> audit will happen ? Has a target date been set when this audit should
> be complete, or is the completion of this audit a requirement for the
> release of a specific gcc version ?
On 11/2/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Bart Van Assche writes:
> > On 10/30/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
> > > That's what the proposed standard language says, kinda-sorta. There's
> > > an informal description at
> > > http://www.open-std.org/jtc1/sc22/wg21/docs/pape
> Another conclusion from the cited text is that in contrast with what
> was stated before on the gcc mailing list, it is not required to
> declare thread-shared variables volatile if that thread-shared data is
> consistently protected by calls to locking functions.
>
> Bart Van Assche.
It all de
Bart Van Assche writes:
> On 10/30/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
> > David Schwartz writes:
> > >
> > > Can we get some kind of consensus that 'optimizations' that add
> > > writes to any object that the programmer might have taken the
> > > address of are invalid on any platfor
On 10/30/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
> David Schwartz writes:
> >
> > Can we get some kind of consensus that 'optimizations' that add
> > writes to any object that the programmer might have taken the
> > address of are invalid on any platform that supports memory
> > protection?
>
>
pushl %ebp
movl%esp, %ebp
cmpl$0, 8(%ebp)
movl$1, %eax
cmove v, %eax; load (maybe)
movl%eax, v; store (always)
popl%ebp
ret
How is this even an optimization? I
David Schwartz writes:
>
> > Well, yeah. I know what you mean. However, at this moment, some
> > gcc developers are trying really hard not to be total d*ckheads
> > about this issue, but get gcc fixed. Give us a chance.
>
> Can we get some kind of consensus that 'optimizations' that add
Just a note on the attribute((acquire,release)) proposal:
It's nice to be able to annotate functions, but please don't forget to
provide a way to write such functions. Ultimately, there will be an
asm() or assignment that is the acquire or release point, and GCC needs
to know that so it can compi
On Fri, 26 Oct 2007, Giacomo Catenazzi wrote:
>
> So we have the great opportunity to change the standard, then
> gcc will change ;-)
I see the smiley, but sadly, new standards take ten years or more to
mature. Which means that even if the upcoming one is "perfect", things
will be wrong with
Linus Torvalds wrote:
> The gcc lists seem to often get to the point where people quote the
> standard, and that's that. In that environment, the paper standard (that
> hass *nothing* to do with reality) trumps any other argument. "What we do
> is _allowed_ by the standard" seems to be a good a
Alan Cox <[EMAIL PROTECTED]> writes:
>
> You can stop the compiler but not the CPU - and some processors will
> certainly speculatively load across conditionals, reorder writes etc
The difference is that the CPU knows how to cancel most[1] side effects
of these speculative accesses (e.g. by not is
On Fri, 26 Oct 2007, Alan Cox wrote:
>
> > non-volatile variables. But for asm statements this can be solved by
> > adding memory to the list of clobbered registers -- this will prevent
> > any reordering of manipulations of non-volatile variables and asm
> > statements.
>
> IFF the processor do
> Well, yeah. I know what you mean. However, at this moment, some gcc
> developers are trying really hard not to be total d*ckheads about this
> issue, but get gcc fixed. Give us a chance.
>
> Andrew.
Can we get some kind of consensus that 'optimizations' that add writes to
any object that the
> non-volatile variables. But for asm statements this can be solved by
> adding memory to the list of clobbered registers -- this will prevent
> any reordering of manipulations of non-volatile variables and asm
> statements.
IFF the processor doesn't reorder them in hardware, which on some
process
Andrew Haley wrote:
We're listening, really. It's unacceptable that gcc should break
code.
In that case a conversion of a conditional branch to an unconditional
write to a visible variable is not an acceptable behaviour. Aside from
the kernel issues, it would break any number of threaded u
On Fri, 26 Oct 2007, Andrew Haley wrote:
>
> Bart Van Assche writes:
>
> > Andrew, do you know whether gcc currently contains any optimization
> > that interchanges the order of accesses to non-volatile variables
> > and function calls ?
>
> It sure does.
Note that doing so is perfectly fin
Bart Van Assche writes:
> Andrew, do you know whether gcc currently contains any optimization
> that interchanges the order of accesses to non-volatile variables
> and function calls ?
It sure does.
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4
On 10/26/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> On Fri, 26 Oct 2007, Linus Torvalds wrote:
> >
> > On Fri, 26 Oct 2007, Bart Van Assche wrote:
> > >
> > > You can find my proposal to improve gcc here:
> > > http://gcc.gnu.org/ml/gcc/2007-10/msg00465.html
> >
> > Btw, I think this is fine
On Fri, 26 Oct 2007, Linus Torvalds wrote:
>
>
> On Fri, 26 Oct 2007, Bart Van Assche wrote:
> >
> > You can find my proposal to improve gcc here:
> > http://gcc.gnu.org/ml/gcc/2007-10/msg00465.html
>
> Btw, I think this is fine per se, but putting "__attribute__((acquire))"
> on the functi
Linus Torvalds writes:
> So my basic worry about gcc is in fact none of the individual
> technical problems themselves - those can be fixed. No, the problem
> I've seen in gcc is that _some_ of the developers seem to be total
> d*ckheads when it comes to "language definition", and seem to thi
On Fri, 26 Oct 2007, Bart Van Assche wrote:
>
> You can find my proposal to improve gcc here:
> http://gcc.gnu.org/ml/gcc/2007-10/msg00465.html
Btw, I think this is fine per se, but putting "__attribute__((acquire))"
on the functions that acquire a lock does seem to be problematic, in that
qu
On Fri, 26 Oct 2007, Bart Van Assche wrote:
> On 10/25/07, Linus Torvalds <> wrote:
> >
> > 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-lawyeri
On 10/25/07, Linus Torvalds <> wrote:
> 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.
Pl
[ I had to resend this message. Sorry if you received two copies. ]
Nick Piggin writes:
> 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 opt
Nick Piggin writes:
> 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
On Fri, Oct 26, 2007 at 01:42:37AM +0200, Andi Kleen wrote:
> On Friday 26 October 2007 01:32:53 Linus Torvalds wrote:
> >
> > On Fri, 26 Oct 2007, Andi Kleen wrote:
> > >
> > > No it can't (at least not on x86) as I have explained in the rest of the
> > > mail
> > > you conveniently snipped.
>
On Thu, 2007-10-25 at 16:57 -0700, Linus Torvalds wrote:
>
> On Fri, 26 Oct 2007, Andi Kleen wrote:
> >
> > The conditional add/sub using carry trick is not generally bogus.
> > But for registers it's a fine optimization.
>
> For registers it's fine. For memory, it's a disaster. It's more than
On Friday 26 October 2007 09:55, Andi Kleen wrote:
> > But we don't actually know what it is, and it could change with
> > different architectures or versions of gcc. I think the sanest thing
> > is for gcc to help us out here, seeing as there is this very well
> > defined requirement that we want.
On Fri, 26 Oct 2007, Andi Kleen wrote:
>
> The conditional add/sub using carry trick is not generally bogus.
> But for registers it's a fine optimization.
For registers it's fine. For memory, it's a disaster. It's more than just
dirty cachelines and introducing race conditions, it's also abou
> But we don't actually know what it is, and it could change with
> different architectures or versions of gcc. I think the sanest thing
> is for gcc to help us out here, seeing as there is this very well
> defined requirement that we want.
>
> If you really still want the optimisation to occur,
On Friday 26 October 2007 09:09, Andi Kleen wrote:
> On Friday 26 October 2007 00:49:42 Nick Piggin 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
On Friday 26 October 2007 01:32:53 Linus Torvalds wrote:
>
> On Fri, 26 Oct 2007, Andi Kleen wrote:
> >
> > No it can't (at least not on x86) as I have explained in the rest of the
> > mail
> > you conveniently snipped.
>
> I "conveniently snipped it" because it was pointless.
>
> "adc" or "c
On Fri, 26 Oct 2007, Andi Kleen wrote:
>
> No it can't (at least not on x86) as I have explained in the rest of the mail
> you conveniently snipped.
I "conveniently snipped it" because it was pointless.
"adc" or "cmov" has nothing what-so-ever to do with it. If some routine
returns 0-vs-1 an
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
Arjan van de Ven wrote:
On Wed, 24 Oct 2007 21:29:56 -0700
"David Schwartz" <[EMAIL PROTECTED]> 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 miss
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
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
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 i
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
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
perso
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
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 LL
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 t
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> On Wed, 24 Oct 2007 21:29:56 -0700
> "David Schwartz" <[EMAIL PROTECTED]> 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
Hi,
On 10/25/07, Linus Torvalds <[EMAIL PROTECTED]> 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 th
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, a
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 l
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 ca
> "Sam" == Samuel Tardieu <[EMAIL PROTECTED]> writes:
> "Nick" == Nick Piggin <[EMAIL PROTECTED]> 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 f
On Thursday 25 October 2007 11:44:28 Samuel Tardieu wrote:
> > "Nick" == Nick Piggin <[EMAIL PROTECTED]> 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
> "Nick" == Nick Piggin <[EMAIL PROTECTED]> 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 d
> "Nick" == Nick Piggin <[EMAIL PROTECTED]> 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
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 pessimizat
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
On Wed, 24 Oct 2007 21:29:56 -0700
"David Schwartz" <[EMAIL PROTECTED]> 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 c
> 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
On Thursday 25 October 2007 13:46, Arjan van de Ven wrote:
> On Thu, 25 Oct 2007 13:24:49 +1000
>
> Nick Piggin <[EMAIL PROTECTED]> 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
On Thu, 25 Oct 2007 13:24:49 +1000
Nick Piggin <[EMAIL PROTECTED]> 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
>
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
61 matches
Mail list logo
