http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49068
Summary: Failure to auto-cast in expression, results in broken code Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: thomas.ev...@nrl.navy.mil Subject: Target: i686-apple-darwin10 Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5666) (dot 3) ========================================================= Predicate: the code: int gnome, jape[20]; char buff[888]; gnome = sscanf(buff," %d %d %d %d %d %d %d %d %d",jape+0, jape+1, jape+2, & jape+3, jape+4, jape+5, jape+6, jape+7, jape+8); generates the following warning: warning: format '%d' expects type 'int *', but argument 6 has type 'int (*)[20]' also, the code does not work properly -- the values in jape[] are not the same as those in the buff[] array. The cause apears to be the expression jape+0 (or maybeso jape+5, but that makes much less sense from my naive perspective) being prematurely optimized by removal of the +0, which would otherwise force a quiet cast of jape from 'int (*)[20]' to 'int *'.