On Wed, Nov 21, 2007 at 09:19:05PM +0500, Alexander E. Patrakov wrote:
> And on IRC, they explained that it is a piece of code that never gets
> called. So not a hit.
It's still a hit. If the code is never called it should not be there in
the first place.
--
Len Sorensen
-
To unsubscribe from
I wrote:
Nix wrote:
Possible hits (I'm not sure what the folder would do with this: the
extra level of brackets in the way might affect things but I don't think
so):
./libtheora/libtheora/lib/enc/pp.c: TmpMod = 32 + QValue -
2*(abs(Src[j+Pitch]-Src[j]));
Nix wrote:
I've grepped all the source on my system (1148 expanded upstream source
tarballs or git/cvs/svn trees including the Linux kernel, most of GNOME,
and all of KDE and X.org) and found that hits are extremely rare: not as
rare as calls to seekdir() and telldir() :) but rare. (Quite a lot
Nix wrote:
I've grepped all the source on my system (1148 expanded upstream source
tarballs or git/cvs/svn trees including the Linux kernel, most of GNOME,
and all of KDE and X.org) and found that hits are extremely rare: not as
rare as calls to seekdir() and telldir() :) but rare. (Quite a lot
I wrote:
Nix wrote:
Possible hits (I'm not sure what the folder would do with this: the
extra level of brackets in the way might affect things but I don't think
so):
./libtheora/libtheora/lib/enc/pp.c: TmpMod = 32 + QValue -
2*(abs(Src[j+Pitch]-Src[j]));
On Wed, Nov 21, 2007 at 09:19:05PM +0500, Alexander E. Patrakov wrote:
And on IRC, they explained that it is a piece of code that never gets
called. So not a hit.
It's still a hit. If the code is never called it should not be there in
the first place.
--
Len Sorensen
-
To unsubscribe from
On 20 Nov 2007, H. Peter Anvin outgrape:
> This one is definitely messy. There is absolutely no way to know what
> gcc has miscompiled.
Actually, since this only affects abs() calls containing multiplications
or divisions by negative constants, you can at least make a pretty good
guess as to its
On Tue, Nov 20, 2007 at 13:52:52 +0100, Alessandro Suardi wrote:
> On Nov 20, 2007 7:52 AM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> > On Mon, Nov 19, 2007 at 10:47:59PM -0800, H. Peter Anvin wrote:
> > >
> > > This one is definitely messy. There is absolutely no way to know what
> > > gcc has
On Nov 20, 2007 7:52 AM, Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 19, 2007 at 10:47:59PM -0800, H. Peter Anvin wrote:
> >
> > This one is definitely messy. There is absolutely no way to know what
> > gcc has miscompiled. It looks to me that both gcc 4.2 and 4.3 are
> > affected, any
On Nov 20, 2007 7:52 AM, Herbert Xu [EMAIL PROTECTED] wrote:
On Mon, Nov 19, 2007 at 10:47:59PM -0800, H. Peter Anvin wrote:
This one is definitely messy. There is absolutely no way to know what
gcc has miscompiled. It looks to me that both gcc 4.2 and 4.3 are
affected, any others?
I
On Tue, Nov 20, 2007 at 13:52:52 +0100, Alessandro Suardi wrote:
On Nov 20, 2007 7:52 AM, Herbert Xu [EMAIL PROTECTED] wrote:
On Mon, Nov 19, 2007 at 10:47:59PM -0800, H. Peter Anvin wrote:
This one is definitely messy. There is absolutely no way to know what
gcc has miscompiled. It
On 20 Nov 2007, H. Peter Anvin outgrape:
This one is definitely messy. There is absolutely no way to know what
gcc has miscompiled.
Actually, since this only affects abs() calls containing multiplications
or divisions by negative constants, you can at least make a pretty good
guess as to its
On Mon, Nov 19, 2007 at 10:47:59PM -0800, H. Peter Anvin wrote:
>
> This one is definitely messy. There is absolutely no way to know what
> gcc has miscompiled. It looks to me that both gcc 4.2 and 4.3 are
> affected, any others?
I just tested it here and gcc 3.3 is also affected so
Herbert Xu wrote:
David Miller <[EMAIL PROTECTED]> wrote:
Because the compiler knows things about the inputs and can
thus apply optimizations that a static implementation in glibc
that has to handle all forms of inputs cannot.
On an unrelated note, I wonder if distros will be treating this
David Miller <[EMAIL PROTECTED]> wrote:
>
> Because the compiler knows things about the inputs and can
> thus apply optimizations that a static implementation in glibc
> that has to handle all forms of inputs cannot.
On an unrelated note, I wonder if distros will be treating this
with the same
From: WANG Cong <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 13:39:05 +0800
> And you mean abs() is not in glibc, then where is it? Built in gcc?
> And what's more, why not put it in glibc?
Because the compiler knows things about the inputs and can
thus apply optimizations that a static
On Tue, Nov 20, 2007 at 02:03:12PM +0800, Li Zefan wrote:
>WANG Cong wrote:
>> On Mon, Nov 19, 2007 at 09:10:44PM -0800, H. Peter Anvin wrote:
>>> WANG Cong wrote:
On Tue, Nov 20, 2007 at 10:13:42AM +0800, zhengyi wrote:
> Is there any relevance to the kernel ?
>
> I found the
WANG Cong wrote:
> On Mon, Nov 19, 2007 at 09:10:44PM -0800, H. Peter Anvin wrote:
>> WANG Cong wrote:
>>> On Tue, Nov 20, 2007 at 10:13:42AM +0800, zhengyi wrote:
Is there any relevance to the kernel ?
I found the folowing code here:
WANG Cong wrote:
This is an urgent bug, I think.
And you mean abs() is not in glibc, then where is it? Built in gcc?
And what's more, why not put it in glibc?
If you need answers to this type of questions, this is not the place for it.
-hpa
-
To unsubscribe from this list: send the
On Mon, Nov 19, 2007 at 09:10:44PM -0800, H. Peter Anvin wrote:
>WANG Cong wrote:
>>On Tue, Nov 20, 2007 at 10:13:42AM +0800, zhengyi wrote:
>>>Is there any relevance to the kernel ?
>>>
>>>I found the folowing code here:
>>>http://linux.solidot.org/article.pl?sid=07/11/19/0512218=rss
>>>
WANG Cong wrote:
On Tue, Nov 20, 2007 at 10:13:42AM +0800, zhengyi wrote:
Is there any relevance to the kernel ?
I found the folowing code here:
http://linux.solidot.org/article.pl?sid=07/11/19/0512218=rss
---
int main( void )
{
On Tue, Nov 20, 2007 at 10:13:42AM +0800, zhengyi wrote:
>Is there any relevance to the kernel ?
>
>I found the folowing code here:
>http://linux.solidot.org/article.pl?sid=07/11/19/0512218=rss
>
>---
>int main( void )
>{
> int i=2;
On Tue, Nov 20, 2007 at 10:13:42AM +0800, zhengyi wrote:
Is there any relevance to the kernel ?
I found the folowing code here:
http://linux.solidot.org/article.pl?sid=07/11/19/0512218from=rss
---
int main( void )
{
int i=2;
if(
WANG Cong wrote:
On Tue, Nov 20, 2007 at 10:13:42AM +0800, zhengyi wrote:
Is there any relevance to the kernel ?
I found the folowing code here:
http://linux.solidot.org/article.pl?sid=07/11/19/0512218from=rss
---
int main( void
WANG Cong wrote:
This is an urgent bug, I think.
And you mean abs() is not in glibc, then where is it? Built in gcc?
And what's more, why not put it in glibc?
If you need answers to this type of questions, this is not the place for it.
-hpa
-
To unsubscribe from this list: send the
On Mon, Nov 19, 2007 at 09:10:44PM -0800, H. Peter Anvin wrote:
WANG Cong wrote:
On Tue, Nov 20, 2007 at 10:13:42AM +0800, zhengyi wrote:
Is there any relevance to the kernel ?
I found the folowing code here:
http://linux.solidot.org/article.pl?sid=07/11/19/0512218from=rss
From: WANG Cong [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 13:39:05 +0800
And you mean abs() is not in glibc, then where is it? Built in gcc?
And what's more, why not put it in glibc?
Because the compiler knows things about the inputs and can
thus apply optimizations that a static implementation
On Tue, Nov 20, 2007 at 02:03:12PM +0800, Li Zefan wrote:
WANG Cong wrote:
On Mon, Nov 19, 2007 at 09:10:44PM -0800, H. Peter Anvin wrote:
WANG Cong wrote:
On Tue, Nov 20, 2007 at 10:13:42AM +0800, zhengyi wrote:
Is there any relevance to the kernel ?
I found the folowing code here:
WANG Cong wrote:
On Mon, Nov 19, 2007 at 09:10:44PM -0800, H. Peter Anvin wrote:
WANG Cong wrote:
On Tue, Nov 20, 2007 at 10:13:42AM +0800, zhengyi wrote:
Is there any relevance to the kernel ?
I found the folowing code here:
http://linux.solidot.org/article.pl?sid=07/11/19/0512218from=rss
On Mon, Nov 19, 2007 at 10:47:59PM -0800, H. Peter Anvin wrote:
This one is definitely messy. There is absolutely no way to know what
gcc has miscompiled. It looks to me that both gcc 4.2 and 4.3 are
affected, any others?
I just tested it here and gcc 3.3 is also affected so presumably
Herbert Xu wrote:
David Miller [EMAIL PROTECTED] wrote:
Because the compiler knows things about the inputs and can
thus apply optimizations that a static implementation in glibc
that has to handle all forms of inputs cannot.
On an unrelated note, I wonder if distros will be treating this
with
David Miller [EMAIL PROTECTED] wrote:
Because the compiler knows things about the inputs and can
thus apply optimizations that a static implementation in glibc
that has to handle all forms of inputs cannot.
On an unrelated note, I wonder if distros will be treating this
with the same level of
32 matches
Mail list logo
