[Bug rtl-optimization/21970] [3.4 only] Inline keyword causes computation to erroneously reduce to a constant

[para at cfl dot rr dot com]

--- Additional Comments From para at cfl dot rr dot com  2005-07-05 14:40 
---
The analysis is slightly flawed. For example:

UINT32 r0045025C = opt_and(ic, r004501D4);// N = and (_, M)   :00022108
UINT32 r00450994 = opt_not(r0045025C);// b = not (N)  :fffddef7

Since you are using 1s to represent bits that are known to be 0 and 0s to 
represent bits whose value are completely unknown, b should be . All 
known 0s flip to 1s, and you can say nothing about the other bits because their 
values are all unknown.

However, I ran my own analysis and came to the same conclusion. It seems that 
the mistake was mine as I was using and (&) instead of add (+) for the round 
key. My appologies. Interestingly, GCC 4.0 does *not* catch this optimization 
opportunity.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21970

[Bug c/21970] New: Inline keyword causes computation to erroneously reduce to a constant

[para at cfl dot rr dot com]

I have a function which evaluates the SHA-1 cryptographic hash function. It 
takes as parameters the 160-bit state and 64 bytes to hash and produces an 
output 160-bit state. When compiling at -O0, it is horrendously slow, but it 
(as far as I know) produces correct behavior. For quick reference, a (brief) 
function definition follows:


typedef unsigned long UINT32;

typedef struct
{
UINT32 a, b, c, d, e;
} SHA1_STATE;

void sha1(SHA1_STATE *pState, void const *pvBuf);


At -O1 and above, the SHA-1 function is reduced to the following code:


_sha1:
pushl   %ebp
movl%esp, %ebp
movl8(%ebp), %eax
movl$0, (%eax)
movl$0, 4(%eax)
movl$0, 8(%eax)
movl$0, 12(%eax)
movl$0, 16(%eax)
popl%ebp
ret


Because this file is autogenerated, I generate function calls to do trivial 
operations such as addition and rely on function inlining to preserve 
performance. If these functions are not marked with the inline keyword, then 
this bug does not trigger. Also, I tried removing roughly half of the code from 
the function, and it cause the bug to no longer trigger. I removed all code 
below line 316 and simply copied the final 5 keys from the key schedule (w75, 
w76, w77, w78, w79) to the output state.

I have observed the same behavior on MinGW GCC versions 3.3.1 and 3.4.2. The 
output of gcc -v for the version I am reporting against is as follows:

Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: /var/tmp/portage/gcc-3.4.4/work/gcc-3.4.4/configure --enable-
version-specific-runtime-libs --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-
bin/3.4.4 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include --
datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4 --mandir=/usr/share/gcc-
data/i686-pc-linux-gnu/3.4.4/man --infodir=/usr/share/gcc-data/i686-pc-linux-
gnu/3.4.4/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-
gnu/3.4.4/include/g++-v3 --host=i686-pc-linux-gnu --disable-altivec --enable-
nls --without-included-gettext --with-system-zlib --disable-checking --disable-
werror --disable-libunwind-exceptions --disable-multilib --disable-libgcj --
enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-
__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.4 (Gentoo Hardened 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)

-- 
   Summary: Inline keyword causes computation to erroneously reduce
to a constant
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: para at cfl dot rr dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21970

[Bug c/21970] Inline keyword causes computation to erroneously reduce to a constant

[para at cfl dot rr dot com]

--- Additional Comments From para at cfl dot rr dot com  2005-06-08 23:01 
---
Created an attachment (id=9047)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9047&action=view)
The stand-alone source file


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21970