Hello, Maybe there is a gcc bug, according to Joel's comment in the "Forwarded Message" section at the end of this mail.
$ bison -o parse.c parse.y $ gcc -v -save-temps -Os -Wall -Werror -c parse.c -o parse.o Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c ++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070925 (Red Hat 4.1.2-33) /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1 -E -quiet -v parse.c -mtune=generic -Wall -Werror -Os -fpch-preprocess ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../x86_64-redhat-linux/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include /usr/include End of search list. Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c ++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070925 (Red Hat 4.1.2-33) /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1 -fpreprocessed /home/kwchen/.ccache/parse.tmp.test64.16477.i -quiet -dumpbase parse.tmp.test64.16477.i -mtune=generic -auxbase-strip /home/kwchen/.ccache/tmp.hash.test64.16477.o -Os -Wall -Werror -version -o parse.tmp.test64.16477.s GNU C version 4.1.2 20070925 (Red Hat 4.1.2-33) (x86_64-redhat-linux) compiled by GNU C version 4.1.2 20070925 (Red Hat 4.1.2-33). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 9f833c3d322ccff4b0d52ae42234eccc cc1: warnings being treated as errors parse.c: In function ‘yyparse’: parse.c:1247: warning: ‘yylval’ is used uninitialized in this function $ cat parse.tmp.test64.16477.s .file "parse.c" .ident "GCC: (GNU) 4.1.2 20070925 (Red Hat 4.1.2-33)" .section .note.GNU-stack,"",@progbits $ uname -a Linux test64 2.6.21-2950.fc8xen #1 SMP Tue Oct 23 12:23:33 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux $ gcc --version gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ bison --version bison (GNU Bison) 2.3 Written by Robert Corbett and Richard Stallman. Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ cat parse.y %{ #define YYSTYPE int static int yylex(YYSTYPE *lvalp); static int yyerror(char const *s); %} %pure-parser %start t %% t: 'a' %% static int yylex(YYSTYPE *lvalp) { return YYEOF; } static int yyerror(char const *s) { return 0; } int main() { return yyparse(); } Thanks, Kaiwang -------- Forwarded Message -------- From: Joel E. Denny <[EMAIL PROTECTED]> To: Kaiwang Chen <[EMAIL PROTECTED]> Cc: help-bison@gnu.org Subject: Re: pure-parser warning: ‘yylval’ is used uninitialized in this function Date: Sat, 10 May 2008 19:43:29 -0400 (EDT) On Thu, 8 May 2008, Kaiwang Chen wrote: > GCC with "-Os -Wall -Werror" complains in the case of pure-parser, while > without -Os it works well. Any help? Thanks in advance. > > $ bison -o parse.c parse.y > $ gcc -Os -Wall -Werror -c parse.c -o parse.o > cc1: warnings being treated as errors > parse.c: In function ‘yyparse’: > parse.c:1247: warning: ‘yylval’ is used uninitialized in this function According to the gcc documentation, -Wuninitialized (implied by -Wall) is affected by the optimization level. > static int yylex(YYSTYPE *lvalp) > { > return YYEOF; > } The warning seems legitimate to me because you're not setting *lvalp in yylex. If yylex is not declared static, the warning goes away. I'm thinking that gcc believes yylex is capable of initializing yylval, but gcc gives up when it sees that yylex could have external linking. When I keep yylex static and initialize *lvalp within it, the warning line number moves to 1035, which is the declaration of yylval. I don't understand what that means. I would've guessed the warning should always have the line number of a usage of yylval. Maybe gcc has a bug. I don't have time to pursue this further right now. Maybe someone can take this to the gcc maintainers for advice. If you find an answer, please let us know. As a workaround, you can add this to your definitions section: %initial-action { $$ = 0; } _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison