Bug 46050 - gcc/c-parser.c fails to build with -O2 -finline-functions
Summary: gcc/c-parser.c fails to build with -O2 -finline-functions
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-16 16:10 UTC by Witold Baryluk
Modified: 2010-10-17 18:00 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
move some initializations (568 bytes, patch)
2010-10-16 16:23 UTC, Uroš Bizjak
Details | Diff
Move initializations patch of incr and cond (against gcc-4.6-20101009) (511 bytes, patch)
2010-10-17 12:18 UTC, Witold Baryluk
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Witold Baryluk 2010-10-16 16:10:56 UTC
gcc-4.6-20101009 snapshot. I think it was working in previous snapshot (there were other errors, but this no). With only -O2 build is ok. So inlineing is a problem?



root@tytus:/scratch/obiekty# export FLAGS="-O2 -finline-functions"
root@tytus:/scratch/obiekty# export CFLAGS=$FLAGS
root@tytus:/scratch/obiekty# export CXXFLAGS=$FLAGS
root@tytus:/scratch/obiekty#  /scratch/gcc-4.6-20101009/configure \
	--enable-languages=c,c++,java \
	--enable-checking=yes \
	CFLAGS="$CFLAGS" CXXFLAGS="$CXXFLAGS"
root@tytus:/scratch/obiekty# make "BOOT_CFLAGS=$CFLAGS" bootstrap


...

/scratch/obiekty/./prev-gcc/xgcc -B/scratch/obiekty/./prev-gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include    -c  -DIN_GCC_FRONTEND -O2 -finline-functions -gtoggle -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I. -I/scratch/gcc-4.6-20101009/gcc -I/scratch/gcc-4.6-20101009/gcc/. -I/scratch/gcc-4.6-20101009/gcc/../include -I/scratch/gcc-4.6-20101009/gcc/../libcpp/include  -I/scratch/gcc-4.6-20101009/gcc/../libdecnumber -I/scratch/gcc-4.6-20101009/gcc/../libdecnumber/bid -I../libdecnumber  -DCLOOG_PPL_BACKEND  -I/usr/include/libelf  /scratch/gcc-4.6-20101009/gcc/c-parser.c -o c-parser.o
/scratch/gcc-4.6-20101009/gcc/c-parser.c: In function ‘c_parser_statement_after_labels’:
/scratch/gcc-4.6-20101009/gcc/c-parser.c:4672:19: error: ‘incr’ may be used uninitialized in this function [-Werror=uninitialized]
/scratch/gcc-4.6-20101009/gcc/c-parser.c:4525:21: note: ‘incr’ was declared here
cc1: all warnings being treated as errors

make[3]: *** [c-parser.o] Błąd 1
make[3]: Opuszczenie katalogu `/scratch/obiekty/gcc'
make[2]: *** [all-stage2-gcc] Błąd 2
make[2]: Opuszczenie katalogu `/scratch/obiekty'
make[1]: *** [stage2-bubble] Błąd 2
make[1]: Opuszczenie katalogu `/scratch/obiekty'
make: *** [bootstrap] Błąd 2
root@tytus:/scratch/obiekty#


Thanks.
Comment 1 Uroš Bizjak 2010-10-16 16:23:14 UTC
Created attachment 22063 [details]
move some initializations

Does attached patch fix the failure for you?
Comment 2 Witold Baryluk 2010-10-17 12:16:25 UTC
Not exactly your patch. In true-branch of if, there is no assigment to incr (so error is correct).

But moving else assigments, before if, resolves problem. Modified patch agains snapshot 20101009 attached.

If you have been genereting against SVN trunk, that it is possible that it is already fixed there (as comment in your patch indicates also).
Comment 3 Witold Baryluk 2010-10-17 12:18:15 UTC
Created attachment 22069 [details]
Move initializations patch of incr and cond (against gcc-4.6-20101009)
Comment 4 Uroš Bizjak 2010-10-17 18:00:58 UTC
(In reply to comment #2)
> Not exactly your patch. In true-branch of if, there is no assigment to incr (so
> error is correct).
> 
> But moving else assigments, before if, resolves problem. Modified patch agains
> snapshot 20101009 attached.
> 
> If you have been genereting against SVN trunk, that it is possible that it is
> already fixed there (as comment in your patch indicates also).

Yeah, my patch was against latest SVN trunk. But anyway, an assignment in both arms on an if can surely be CSE'd out of the "if" entirely.

So, fixed in latest SVN.