Hi,
On Thu, 6 Mar 2008, Andi Kleen wrote:
> To be realistic it is very unlikely anybody will measure a difference
> from a few more or a few less clds in a program.
Only an assumption, and in fact wrong. See upthread for a benchmark.
IIRC Uros also made measurements to justify the removal of
On Mar 6, 2008, at 2:06 PM, Andi Kleen wrote:
On Thu, Mar 06, 2008 at 12:56:16PM -0800, H. Peter Anvin wrote:
Richard Guenther wrote:
A patched GCC IMHO makes only sense if it is always-on, yet
another option
won't help in corner cases. And corner cases is exactly what
people seem
to ca
On Thu, Mar 6, 2008 at 11:06 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> On Thu, Mar 06, 2008 at 12:56:16PM -0800, H. Peter Anvin wrote:
> > Richard Guenther wrote:
> > >
> > >A patched GCC IMHO makes only sense if it is always-on, yet another option
> > >won't help in corner cases. And corn
On Thu, Mar 06, 2008 at 12:56:16PM -0800, H. Peter Anvin wrote:
> Richard Guenther wrote:
> >
> >A patched GCC IMHO makes only sense if it is always-on, yet another option
> >won't help in corner cases. And corner cases is exactly what people seem
> >to care about. For this reason that we have th
Richard Guenther wrote:
A patched GCC IMHO makes only sense if it is always-on, yet another option
won't help in corner cases. And corner cases is exactly what people seem
to care about. For this reason that we have this single release, 4.3.0, that
behaves "bad" is already a problem.
The op
On Thu, Mar 6, 2008 at 6:34 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
>
> On Thu, Mar 06, 2008 at 01:06:17PM +0100, Richard Guenther wrote:
> > On 06 Mar 2008 12:45:57 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > Andrew Haley <[EMAIL PROTECTED]> writes:
> > > >
> > > > I suppose one could
On Thu, Mar 06, 2008 at 01:06:17PM +0100, Richard Guenther wrote:
> On 06 Mar 2008 12:45:57 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Andrew Haley <[EMAIL PROTECTED]> writes:
> > >
> > > I suppose one could apply the precautionary principle, but those systems
> > that
> > > don't update
On 06 Mar 2008 12:45:57 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Andrew Haley <[EMAIL PROTECTED]> writes:
> >
> > I suppose one could apply the precautionary principle, but those systems
> that
> > don't update kernels won't update gcc either, so the solution won't work.
>
> You seem to
Andrew Haley <[EMAIL PROTECTED]> writes:
>
> I suppose one could apply the precautionary principle, but those systems that
> don't update kernels won't update gcc either, so the solution won't work.
You seem to assume that running a gcc 4.3 compiled binary requires a
gcc update. That is not nece
Aurelien Jarno wrote:
> H. Peter Anvin a écrit :
>> Michael Matz wrote:
>>>
>>> On Wed, 5 Mar 2008, Aurelien Jarno wrote:
>>>
> So I think gcc at least needs an *option* to revert to the old
> behavior,
> and there's a good argument to make it the default for now, at least
> for
>>>
Aurelien Jarno writes:
> On Wed, Mar 05, 2008 at 11:58:34AM -0800, Joe Buck wrote:
> >
> > Aurelien Jarno wrote:
> > > >Since version 4.3, gcc changed its behaviour concerning the x86/x86-64
> > > >ABI and the direction flag, that is it now assumes that the direction
> > > >flag is cleared
From: Aurelien Jarno <[EMAIL PROTECTED]>
Date: Wed, 05 Mar 2008 21:52:14 +0100
> H. Peter Anvin a écrit :
> > The best would be if this could be controlled by a flag, which we can
> > flip once kernel fixes has been around for long enough.
>
> I have to agree there. Whatever the decision that gcc
Jan Hubicka wrote:
Yes, if there are four kernels that get it "wrong", that effectively means
that the ABI document doesn't describe reality and gcc has to adjust.
Kernels almost never follow ABI used by applications to last detail.
Linux kernel is disabling red zone and use kernel code model,
Hi,
On Wed, 5 Mar 2008, Jan Hubicka wrote:
> Kernels almost never follow ABI used by applications to last detail.
But we aren't talking about the ABI the kernel uses internally, but about
what is exposed to user-space via signal handlers. _That_ part needs to
be followed, and if it isn't it'
H. Peter Anvin a écrit :
> Michael Matz wrote:
>> Hi,
>>
>> On Wed, 5 Mar 2008, Aurelien Jarno wrote:
>>
So I think gcc at least needs an *option* to revert to the old
behavior,
and there's a good argument to make it the default for now, at least
for
x86/x86-64 on Linux.
>>
> On Wed, Mar 05, 2008 at 09:38:13PM +0100, Michael Matz wrote:
> > Hi,
> >
> > On Wed, 5 Mar 2008, Aurelien Jarno wrote:
> >
> > > > So I think gcc at least needs an *option* to revert to the old behavior,
> > > > and there's a good argument to make it the default for now, at least for
> > > > x
Michael Matz wrote:
Hi,
On Wed, 5 Mar 2008, Aurelien Jarno wrote:
So I think gcc at least needs an *option* to revert to the old behavior,
and there's a good argument to make it the default for now, at least for
x86/x86-64 on Linux.
And for other kernels. I tested OpenBSD 4.1, FreeBSD 6.3, Net
On Wed, Mar 05, 2008 at 09:38:13PM +0100, Michael Matz wrote:
> Hi,
>
> On Wed, 5 Mar 2008, Aurelien Jarno wrote:
>
> > > So I think gcc at least needs an *option* to revert to the old behavior,
> > > and there's a good argument to make it the default for now, at least for
> > > x86/x86-64 on Lin
Hi,
On Wed, 5 Mar 2008, Aurelien Jarno wrote:
> > So I think gcc at least needs an *option* to revert to the old behavior,
> > and there's a good argument to make it the default for now, at least for
> > x86/x86-64 on Linux.
>
> And for other kernels. I tested OpenBSD 4.1, FreeBSD 6.3, NetBSD 4.
On Wed, Mar 05, 2008 at 11:58:34AM -0800, Joe Buck wrote:
>
> Aurelien Jarno wrote:
> > >Since version 4.3, gcc changed its behaviour concerning the x86/x86-64
> > >ABI and the direction flag, that is it now assumes that the direction
> > >flag is cleared at the entry of a function and it doesn'
Aurelien Jarno wrote:
> >Since version 4.3, gcc changed its behaviour concerning the x86/x86-64
> >ABI and the direction flag, that is it now assumes that the direction
> >flag is cleared at the entry of a function and it doesn't clear once
> >more if needed.
> >...
> >I guess this has to be fi
Hi,
According to i386 psABI,
---
The direction flag must be set "forward" direction before entry and
upon exit from
a function.
---
So, asm statement should make sure that the direction flag is cleared before
function returns and kernel should make sure that the direction flag is cleared
when ca
Aurelien Jarno wrote:
Hi all,
Since version 4.3, gcc changed its behaviour concerning the x86/x86-64
ABI and the direction flag, that is it now assumes that the direction
flag is cleared at the entry of a function and it doesn't clear once
more if needed.
This causes some problems with the
23 matches
Mail list logo
