Bug report: infinite loop in gcc/cp/decl.c

Smithers, Kit kit.smithers@eds.com
Fri Dec 10 02:13:00 GMT 1999


Bug: cc1plus enters an infinite loop.

I posted this report earlier this week without bothering to mention the
following:

gcc2.95
aix4.2.1

g++ -g -ftemplate-depth-30  -Wall -Wtraditional -Wid-clash-32
-Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings
-Wconversion -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs
-Winline -Woverloaded-virtual -Wsynth -Wno-sign-compare -Wno-comment
-I/tools_fdps2/SGIstl -I/cssinteg/integ_users/kits/test_review/css
-I/cssinteg/integ_users/kits/test_review/css/public/include
-I/cssinteg/integ_users/kits/test_review/snapshots/latest/css
-I/cssinteg/integ_users/kits/test_review/snapshots/latest/css/public/include
-I/cssinteg/integ_users/kits/test_review/snapshots/stable/public/include
-Wno-unused -Wno-shadow -c -o stream_time.o ../stream_time.cxx

However, if I add "-v --save-temps" then g++ fails to lock up. However, as I
detailed in my message below I believe I have spotted an error in gcc's
code.

The problem appears to be in cc1plus which is being run with the command
line of:

/tools_fdps2/gcc/2.95/lib/gcc-lib/powerpc-ibm-aix4.2.1.0/2.95/cc1plus
/tmp/ccHGUaEK.ii -quiet -dumpbase stream_time.sm_1000.cc -g -Wall
-Wtraditional -Wid-clash-32 -Wpointer-arith -Wbad-function-cast -Wcast-align
-Wwrite-strings -Wconversion -Wstrict-prototypes -Wmissing-prototypes
-Wnested-externs -Winline -Woverloaded-virtual -Wsynth -Wno-sign-compare
-Wno-comment -Wno-unused -Wno-shadow -ftemplate-depth-30 -o /tmp/ccBGXols.s

I've copied the /tmp/ccHGUaEK.ii from the above command line and compressed
it with bzip2 but its about 110K so I'm not posting it here - I can always
email/supply it to anyone who is interested. If I feed it back to the above
command it locks up - although this time I get lots of errors printed out -
the first of which is: 

In file included from stream_time.sm.cxx:358:
stream_time.sm.cxx:0: warning: badly nested C headers from preprocessor

previous message follows:

> I'm having trouble with gcc seeming to enter an infinite 
> loop. I have some
> speculative considerations as to what may be wrong but I'm 
> aware that I
> might be completely fooled by what's happening.
> 
> It happens in cc1plus in the module gcc/cp/decl.c
> 
> line 12480. just after the comment: /* 13.4.0.8 */
> 
> The for loop here checks against "void_list_node" to see if 
> the loop should
> terminate:
> 
> for (; argtypes != void_list_node ; argtypes = TREE_CHAIN (argtypes))
> 
> This is unlike any other loop in decl.c which uses TREE_CHAIN 
> to get the
> next item. They all check for the pointer not being 0. 
> 
> When I stop cc1plus in gdb I can see that:
> 
> (gdb) p argtypes
> $5 = 0x0
> (gdb) p argtypes->common.chain
> $6 = (union tree_node *) 0x0
> (gdb) p void_list_node
> $7 = 0x200580b8
> 
> I believe TREE_CHAIN(NODE) is ((NODE)->common.chain) as defined in
> gcc/tree.h
> 
> So the loop is going to go on forever.
> 
> The code I'm passing in has been through two levels of preprocessing
> (Cantata++ and Insure++) which makes it difficult for me to 
> isolate the code
> that's causing the problem since it doesnt occur in the unprocessed
> original. But from looking at the way this loop is coded it 
> doesn't seem to
> me that it covers the possibility of "argtypes == 0" as an 
> escape condition
> for the loop. As I said other loops in the same file either 
> check for not
> null and in some cases checks are made for void_list_node as well.
> 
> So my question is:
> 
> would it be _correct_ for me to amend the for loop to check 
> for 'argtypes !=
> 0' as well as void_list_node ?
> 

-- 
Kit Smithers
 


More information about the Gcc-bugs mailing list