Yes, that is a common one, though it was more prevalent in early MSVC7
(.NET) than in MSVC6. Another common problem is nested for loops.
If you just can't figure out why a particular function is generating bad
asm code, it is also possible to use #pragma optimize("off",0) (syntax
might be slightly off) around just the function(s) that is failing, rather
than turn off optimizations globally. But then you have to remember to go
fix it some day and remove the #pragma.
michael
At 02:58 PM 1/15/2003 +0100, Andy Polyakov via RT wrote:
> > One is that AES using 192 or 256 bit ciphers produces the wrong result.
> >
> > > Have you traced into it at all?
>
>Try this:-)
>
>--- ./crypto/aes/aes_core.c.orig Wed Nov 13 15:01:18 2002
>+++ ./crypto/aes/aes_core.c Wed Jan 15 01:54:08 2003
>@@ -750,7 +750,7 @@
> rk[2] = GETU32(userKey + 8);
> rk[3] = GETU32(userKey + 12);
> if (bits == 128) {
>- for (;;) {
>+ while (1) {
> temp = rk[3];
> rk[4] = rk[0] ^
> (Te4[(temp >> 16) & 0xff] & 0xff000000) ^
>@@ -770,7 +770,7 @@
> rk[4] = GETU32(userKey + 16);
> rk[5] = GETU32(userKey + 20);
> if (bits == 192) {
>- for (;;) {
>+ while (1) {
> temp = rk[ 5];
> rk[ 6] = rk[ 0] ^
> (Te4[(temp >> 16) & 0xff] & 0xff000000) ^
>@@ -792,7 +792,7 @@
> rk[6] = GETU32(userKey + 24);
> rk[7] = GETU32(userKey + 28);
> if (bits == 256) {
>- for (;;) {
>+ while (1) {
> temp = rk[ 7];
> rk[ 8] = rk[ 0] ^
> (Te4[(temp >> 16) & 0xff] & 0xff000000) ^
>
>Well, just to get through the ms\test, only last change is sufficient.
>No, it doesn't make sense, compiler bugs don't usually do. This is
>already second occasion when I run into such problem. I.e. when
>compiler generates bad code for "for(;;)," but not for "while(1)."
>Last time it was egcs... A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
