> 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
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
37 matches
Mail list logo
