Flow analysis bug

[Roman Lechtchinsky <rl at cs dot tu-berlin dot de>]

Hi,

bootstrapping CVS head on Sparc Solaris with

./xgcc -B./ -B/usr/local/sparc-sun-solaris2.7/bin/ -isystem
/usr/local/sparc-sun-solaris2.7/include -O2   -DIN_GCC    -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem
./include  -fPIC -g1 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../../cvs/gcc/gcc
-I../../../cvs/gcc/gcc/. -I../../../cvs/gcc/gcc/config
-I../../../cvs/gcc/gcc/../include  -DL_clear_cache -c
../../../cvs/gcc/gcc/libgcc2.c -o libgcc/./_clear_cache.o
cc1: warning: changing search order for system directory "include"
cc1: warning:   as it has already been specified as a system directory
../../../cvs/gcc/gcc/libgcc2.c: In function `__clear_cache':
../../../cvs/gcc/gcc/libgcc2.c:2467: Virtual array basic_block_info[1]:
element 1 out of bounds
../../../cvs/gcc/gcc/libgcc2.c:2467: confused by earlier errors, bailing
out

On the Sparc, __clear_cache expands to an empty function. Such functions
have only an empty fallthru forwarder block which try_optimize_cfg tries
to delete now because of the fix to forwarder_block_p in

http://gcc.gnu.org/ml/gcc-patches/2001-06/msg01846.html

Such blocks haven't been recognized as forwarder blocks before that patch.
Deleting the only basic block exposes two problems:

  - try_optimize_cfg doesn't handle this case correctly. This is easy to
    fix.

  - The rest of the compiler can't handle functions with no basic blocks.
    A comment in count_basic_blocks suggests that this is not a bug.

I'm not sure how to fix this. I think try_optimize_cfg shouldn't try to
delete the last basic block but maybe it should replace all insns in it
with a noop? Should this be done in try_optimize_cfg or in
flow_delete_block? Or is the obvious fix - not to touch a basic block if
it is the only one - enough?

Bye

Roman