> Yes. In practice the usual question is whether the compiler will
> evaluate the operands from left to right or from right to left,
> but the compiler is within its rights to evaluate the operands in
> any order it wants.
For ia64, it would be good to evaluate the operands in parallel.
One coul
([EMAIL PROTECTED]) nobly encouraged empiricism thusly...
> Just to encourage empiricism, I usually check stuff like that with
>
> % cat > foo.c
> main(){
> int i;
> i = 1 , 2;
> printf("%d\n",i);
> }
> % gcc foo.c
> % ./a.out
> 1
>
> or similar if I'm confused.
Indeed. Furt
[CC trimmed]
Bill Wendling wrote:
>
> Also sprach Tom Leete:
> }
> } You are correct that in C the rightmost argument is always
> } at the open end of the stack, and that varargs require that.
> } The opposite is called the Pascal convention.
> }
> Where in the standard does it say this? It's pr
On Tue, Oct 17, 2000 at 07:42:31AM +, Peter Samuelson wrote:
> So, if you choose left-to-right, how do you implement varargs? Keep in
> mind that prototypes are optional. I bet anything your solution is
> slower and more complex than right-to-left, as all known compilers do.
Calling a varar
> [Matti Aarnio]
> > > That depends mainly on question: Does your stack grow up or down ?
Actually a combination -- which direction do arguments grow in relation
to stack growth direction, and do you have a stack push instruction.
> [Ben Pfaff]
> > No it doesn't. It depends mainly on wheth
On Tue, Oct 17, 2000 at 10:40:12AM +0100, Bernd Schmidt wrote:
> > I compiled using "gcc -S -Wall -O2 -fomit-frame-pointer -m486" to generate
> > the assembler code. The old code is 17 instructions long and the new code
> > is 11 instructions. As well as being shorter, simple timing test indic
Bill Wendling <[EMAIL PROTECTED]> writes:
> Also sprach Bernd Schmidt:
> } > Looking at the above code, I noticed that there are a lot of ++
> } > operations. I rewrote the code as:
> } >
> } > setup_from[0] = setup_from[1] = eaddrs[0];
> } > setup_from[2] = setup_from[3] = eaddrs[1];
On Tue, 17 Oct 2000, Horst von Brand wrote:
> Richard Guenther <[EMAIL PROTECTED]> said:
> > The following one is wrong, tho - should be rather
> > str[i] = dn[i]; i++;
>
> > > diff -x log.build -x .* -dru linux-2.4/drivers/isdn/sc/debug.c linux-2.4-fixe
> > d/drivers/isdn/sc/deb
Also sprach Tom Leete:
}
} You are correct that in C the rightmost argument is always
} at the open end of the stack, and that varargs require that.
} The opposite is called the Pascal convention.
}
Where in the standard does it say this? It's probably done most of the
time in this fashion for c
Also sprach Bernd Schmidt:
} > Looking at the above code, I noticed that there are a lot of ++
} > operations. I rewrote the code as:
} >
} > setup_from[0] = setup_from[1] = eaddrs[0];
} > setup_from[2] = setup_from[3] = eaddrs[1];
} > setup_from[4] = setup_from[5] = eaddrs[2];
}
Also sprach Mark Montague:
}
} dn[i], i++ evaluates to i, but str[i] = dn[i], i++ sets str[i] to
} dn[i] first, then increments i returning its previous value, which is
} discarded. Which was probably specified this way so
}
} for(i=1,j=2; something; something else)
}
} works as expected, rathe
Bernd Schmidt <[EMAIL PROTECTED]> said:
> On Tue, 17 Oct 2000, Richard Guenther wrote:
> > On Tue, 17 Oct 2000, Bernd Schmidt wrote:
> > > On Tue, 17 Oct 2000, Richard Guenther wrote:
> > > > The following one is wrong, tho - should be rather
> > > > str[i] = dn[i]; i++;
> > >
> >
Richard Guenther <[EMAIL PROTECTED]> said:
> On Mon, 16 Oct 2000, Bernd Schmidt wrote:
> The following one is wrong, tho - should be rather
> str[i] = dn[i]; i++;
> > diff -x log.build -x .* -dru linux-2.4/drivers/isdn/sc/debug.c linux-2.4-fixe
> d/drivers/isdn/sc/debug.c
> > ---
Peter Samuelson wrote:
>
> [Matti Aarnio]
> > > That depends mainly on question: Does your stack grow up or down ?
>
> [Ben Pfaff]
> > No it doesn't. It depends mainly on whether the ABI for the machine
> > says that arguments are pushed onto the stack in left-to-right or
> > right-to-left
Richard Guenther <[EMAIL PROTECTED]> writes:
> On Tue, 17 Oct 2000, Bernd Schmidt wrote:
>
> > On Tue, 17 Oct 2000, Richard Guenther wrote:
> >
> > > On Mon, 16 Oct 2000, Bernd Schmidt wrote:
> > >
> > > > I've been playing with some gcc patches to detect code with undefined
> > > > behaviour
On Tue, 17 Oct 2000, Richard Guenther wrote:
> On Tue, 17 Oct 2000, Bernd Schmidt wrote:
> > On Tue, 17 Oct 2000, Richard Guenther wrote:
> > > The following one is wrong, tho - should be rather
> > > str[i] = dn[i]; i++;
> >
> > Nope. (Well, at least you need to add extra braces
On Tue, 17 Oct 2000, Bernd Schmidt wrote:
> On Tue, 17 Oct 2000, Richard Guenther wrote:
>
> > On Mon, 16 Oct 2000, Bernd Schmidt wrote:
> >
> > > I've been playing with some gcc patches to detect code with undefined
> > > behaviour of the i = i++ variety. The patch below fixes all places in
>
> Looking at the above code, I noticed that there are a lot of ++
> operations. I rewrote the code as:
>
> setup_from[0] = setup_from[1] = eaddrs[0];
> setup_from[2] = setup_from[3] = eaddrs[1];
> setup_from[4] = setup_from[5] = eaddrs[2];
> setup_from += 6;
>
> I compiled
On Tue, 17 Oct 2000, Helge Hafting wrote:
> Bernd Schmidt wrote:
> >
> > I've been playing with some gcc patches to detect code with undefined
> > behaviour of the i = i++ variety. The patch below fixes all places in
> > the kernel that I could find. Note that in some cases, it wasn't
> > enti
On Tue, 17 Oct 2000, Richard Guenther wrote:
> On Mon, 16 Oct 2000, Bernd Schmidt wrote:
>
> > I've been playing with some gcc patches to detect code with undefined
> > behaviour of the i = i++ variety. The patch below fixes all places in
> > the kernel that I could find. Note that in some cas
On Mon, 16 Oct 2000, Bernd Schmidt wrote:
> I've been playing with some gcc patches to detect code with undefined
> behaviour of the i = i++ variety. The patch below fixes all places in
> the kernel that I could find. Note that in some cases, it wasn't
> entirely clear what the code intended, s
Bernd Schmidt wrote:
>
> I've been playing with some gcc patches to detect code with undefined
> behaviour of the i = i++ variety. The patch below fixes all places in
> the kernel that I could find. Note that in some cases, it wasn't
> entirely clear what the code intended, so I had to guess.
[Matti Aarnio]
> > That depends mainly on question: Does your stack grow up or down ?
[Ben Pfaff]
> No it doesn't. It depends mainly on whether the ABI for the machine
> says that arguments are pushed onto the stack in left-to-right or
> right-to-left order. You could do either on x86, fo
Matti Aarnio <[EMAIL PROTECTED]> writes:
> On Mon, Oct 16, 2000 at 04:55:08PM -0400, Ben Pfaff wrote:
> > Yes. In practice the usual question is whether the compiler will
> > evaluate the operands from left to right or from right to left,
> > but the compiler is within its rights to evaluate the
On Mon, Oct 16, 2000 at 04:55:08PM -0400, Ben Pfaff wrote:
> > > $ The order of evaluation of the function designator, the
> > > $ arguments, and subexpressions within the arguments is
> > > $ unspecified, ...
> >
> > I sit surprised and corrected. With every version of every C compiler on
On Mon, 16 Oct 2000, Mike Castle wrote:
> On Mon, Oct 16, 2000 at 04:47:09PM -0400, Alexander Viro wrote:
> > tmp = *p++;
> > *q = f(tmp, *p++);
> > return p;
> >
> > is equivalent to more idiomatic
> >
> > *q = f(p[0], p[1]);
> > return p+2;
>
>
> Which gets better assembler out of various
On Mon, Oct 16, 2000 at 04:47:09PM -0400, Alexander Viro wrote:
> tmp = *p++;
> *q = f(tmp, *p++);
> return p;
>
> is equivalent to more idiomatic
>
> *q = f(p[0], p[1]);
> return p+2;
Which gets better assembler out of various versions of gcc?
mrc
--
Mike Castle Life is like a
>-Original Message-
>From: Alexander Viro [mailto:[EMAIL PROTECTED]]
[snip]
>
>No arguments here, but proposed fixes were remarkably ugly. Example:
>
>tmp = *p++;
>*q = f(tmp, *p++);
>return p;
>
>is equivalent to more idiomatic
>
>*q = f(p[0], p[1]);
>return p+2;
>
>And example with copyi
Jonathan George <[EMAIL PROTECTED]> writes:
> > $ The order of evaluation of the function designator, the
> > $ arguments, and subexpressions within the arguments is
> > $ unspecified, ...
> >--
>
> I sit surprised and corrected. With every version of every C compiler on
> every OS
-Original Message-
From: Ben Pfaff [mailto:[EMAIL PROTECTED]]
>Jonathan George <[EMAIL PROTECTED]> writes:
>
>> This patch has many bogus corrections where new variables were created,
but
>> the order of evaluation is already unambiguous.
>>
>> For example each comma separated clause in a
On 16 Oct 2000, Ben Pfaff wrote:
> Jonathan George <[EMAIL PROTECTED]> writes:
>
> > This patch has many bogus corrections where new variables were created, but
> > the order of evaluation is already unambiguous.
> >
> > For example each comma separated clause in an expression is guaranteed t
Jonathan George <[EMAIL PROTECTED]> writes:
> This patch has many bogus corrections where new variables were created, but
> the order of evaluation is already unambiguous.
>
> For example each comma separated clause in an expression is guaranteed to be
> completely evaluated before the next comm
Also sprach Abramo Bagnara:
}
} Isn't this more efficient?
} n = (x>>32) | (x<<32);
} n = ((n & 0xLL)<<16) | (n & 0xLL)>>16;
} n = ((n & 0x00ff00ff00ff00ffLL)<<8) | (n & 0xff00ff00ff00ff00LL)>>8;
}
} 6 shift
} 4 and
} 3 or
}
Plus 3 assigns...but they may
At 01:21 PM 10/16/00, Jeff Garzik wrote:
>Bernd Schmidt wrote:
> > diff -x log.build -x .* -dru linux-2.4/drivers/net/tulip/tulip_core.c
> linux-2.4-fixed/drivers/net/tulip/tulip_core.c
> > --- linux-2.4/drivers/net/tulip/tulip_core.cMon Oct 16 13:51:23 2000
> > +++ linux-2.4-fixed/drivers/ne
This patch has many bogus corrections where new variables were created, but
the order of evaluation is already unambiguous.
For example each comma separated clause in an expression is guaranteed to be
completely evaluated before the next comma separated clause Including
Assignments.
It seems as
Bernd Schmidt wrote:
>
> +
> +#define ___swab64(x) \
> +({ \
> + __u64 __x = (x); \
> + ((__u64)( \
> + (__u64)(((__u64)(__x) & (__u64)0x00ffULL) << 56) | \
> + (__u64)(((__u64)(__x) & (__u64)0xff00ULL) << 40) | \
> + (
On Mon, 16 Oct 2000, Jeff Garzik wrote:
> > --- linux-2.4/drivers/scsi/aha152x.cMon Oct 16 13:51:24 2000
> > +++ linux-2.4-fixed/drivers/scsi/aha152x.c Mon Oct 16 14:51:29 2000
> > @@ -1280,7 +1280,8 @@
> > scsi_unregister(shpnt);
> > regis
Bernd Schmidt wrote:
> diff -x log.build -x .* -dru linux-2.4/drivers/net/tulip/tulip_core.c
>linux-2.4-fixed/drivers/net/tulip/tulip_core.c
> --- linux-2.4/drivers/net/tulip/tulip_core.cMon Oct 16 13:51:23 2000
> +++ linux-2.4-fixed/drivers/net/tulip/tulip_core.c Mon Oct 16 15:40:12 200
I've been playing with some gcc patches to detect code with undefined
behaviour of the i = i++ variety. The patch below fixes all places in
the kernel that I could find. Note that in some cases, it wasn't
entirely clear what the code intended, so I had to guess.
I haven't tested this patch at a
39 matches
Mail list logo
