Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')

Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')

[Joe Buck]

[ setjmp warnings with exceptions ]
> The warning is correct and useful.  It warns for a situation where programs
> using setjmp may fail at runtime because of how setjmp works.
> 
> This warning may be triggered for C++ programs using the setjmp/longjmp
> exception handling support.  However, this is clearly a bug in the sjlj EH
> support.  We should not remove a useful and correct warning to work around
> bugs in the EH support.  We should fix the EH support.

It is not clear to me that it represents an actual bug (that is, that in
the execution of the programs where we've seen these messages, that any
flow is possible that accesses the automatic variables being warned about
after setjmp catches a longjmp.  The compiler issues the warning because
it cannot prove this; it may be being overly conservative.

I am not enough of a backend wizard to answer this question definitively,
but I feel we must answer it before releasing this sucker.  STL programs
with -O and -Wall spew loads of warnings.

For example, cd to egcs-97XXXX/libstdc++/tests and say

gcc -c -O -Wall tmap.cc

on sparc-sun-solaris2.5.1

You will get the following.  (the msgs about lock_instance and member
initializers are fixed by a patch I sent in before).  The "may be used
uninitialized" messages all go away if exceptions are disabled.  Almost
any use of the STL map template will give these messages.

So, are they real (can the variables in question be used uninitialized,
and can longjmp clobber them)?


/u/jbuck/egcs/include/g++/alloc.h: In function `static void * __default_alloc_template ::allocate(unsigned int)':
In file included from /u/jbuck/egcs/include/g++/tree.h:55,
                 from /u/jbuck/egcs/include/g++/map.h:30,
                 from tmap.cc:1:
/u/jbuck/egcs/include/g++/alloc.h:394: warning: unused variable `class __default_alloc_template ::lock lock_instance'
/u/jbuck/egcs/include/g++/alloc.h: In function `static void __default_alloc_template ::deallocate(void *, unsigned int)':
/u/jbuck/egcs/include/g++/alloc.h:417: warning: unused variable `class __default_alloc_template ::lock lock_instance'
/u/jbuck/egcs/include/g++/tree.h: In method `rb_tree ,select1st >,int_less,__default_alloc_template >::rb_tree(const struct int_less & = Compare())':
/u/jbuck/egcs/include/g++/tree.h:460: warning: member initializers for `unsigned int rb_tree ,select1st >,int_less,__default_alloc_template >::node_count'
/u/jbuck/egcs/include/g++/tree.h:462: warning:   and `struct int_less rb_tree ,select1st >,int_less,__default_alloc_template >::key_compare'
/u/jbuck/egcs/include/g++/tree.h:514: warning:   will be re-ordered to match declaration order
/u/jbuck/egcs/include/g++/tree.h: In method `rb_tree ,select1st >,str_less,__default_alloc_template >::rb_tree(const struct str_less & = Compare())':
/u/jbuck/egcs/include/g++/tree.h:460: warning: member initializers for `unsigned int rb_tree ,select1st >,str_less,__default_alloc_template >::node_count'
/u/jbuck/egcs/include/g++/tree.h:462: warning:   and `struct str_less rb_tree ,select1st >,str_less,__default_alloc_template >::key_compare'
/u/jbuck/egcs/include/g++/tree.h:514: warning:   will be re-ordered to match declaration order
/u/jbuck/egcs/include/g++/tree.h: In method `struct __rb_tree_iterator ,pair &> rb_tree ,select1st >,int_less,__default_alloc_template >::__insert(struct __rb_tree_node_base *, struct __rb_tree_node_base *, const struct pair &)':
/u/jbuck/egcs/include/g++/tree.h:431: warning: `struct __rb_tree_node > * tmp' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/tree.h:431: warning: variable `struct __rb_tree_node > * tmp' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/tree.h:435: warning: `struct pair * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/tree.h:435: warning: variable `struct pair * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/algobase.h:554: warning: `void * place' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/algobase.h:554: warning: variable `void * place' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/tree.h:440: warning: `struct __rb_tree_node > * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/tree.h:440: warning: variable `struct __rb_tree_node > * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/tree.h:428: warning: `struct __rb_tree_node > * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/tree.h:428: warning: variable `struct __rb_tree_node > * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/alloc.h:218: warning: `void * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/alloc.h:218: warning: variable `void * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/alloc.h:411: warning: `void * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/alloc.h:411: warning: variable `void * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/tree.h:431: warning: `struct __rb_tree_node > * tmp' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/tree.h:431: warning: variable `struct __rb_tree_node > * tmp' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/tree.h:435: warning: `struct pair * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/tree.h:435: warning: variable `struct pair * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/algobase.h:554: warning: `void * place' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/algobase.h:554: warning: variable `void * place' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/tree.h:440: warning: `struct __rb_tree_node > * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/tree.h:440: warning: variable `struct __rb_tree_node > * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/tree.h:428: warning: `struct __rb_tree_node > * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/tree.h:428: warning: variable `struct __rb_tree_node > * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/alloc.h:218: warning: `void * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/alloc.h:218: warning: variable `void * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/alloc.h:411: warning: `void * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/alloc.h:411: warning: variable `void * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/tree.h: In method `struct __rb_tree_iterator ,pair &> rb_tree ,select1st >,str_less,__default_alloc_template >::__insert(struct __rb_tree_node_base *, struct __rb_tree_node_base *, const struct pair &)':
/u/jbuck/egcs/include/g++/tree.h:431: warning: `struct __rb_tree_node > * tmp' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/tree.h:431: warning: variable `struct __rb_tree_node > * tmp' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/tree.h:435: warning: `struct pair * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/tree.h:435: warning: variable `struct pair * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/algobase.h:554: warning: `void * place' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/algobase.h:554: warning: variable `void * place' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/tree.h:440: warning: `struct __rb_tree_node > * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/tree.h:440: warning: variable `struct __rb_tree_node > * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/tree.h:428: warning: `struct __rb_tree_node > * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/tree.h:428: warning: variable `struct __rb_tree_node > * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/alloc.h:218: warning: `void * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/alloc.h:218: warning: variable `void * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/alloc.h:411: warning: `void * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/alloc.h:411: warning: variable `void * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/tree.h:431: warning: `struct __rb_tree_node > * tmp' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/tree.h:431: warning: variable `struct __rb_tree_node > * tmp' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/tree.h:435: warning: `struct pair * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/tree.h:435: warning: variable `struct pair * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/algobase.h:554: warning: `void * place' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/algobase.h:554: warning: variable `void * place' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/tree.h:440: warning: `struct __rb_tree_node > * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/tree.h:440: warning: variable `struct __rb_tree_node > * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/tree.h:428: warning: `struct __rb_tree_node > * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/tree.h:428: warning: variable `struct __rb_tree_node > * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/alloc.h:218: warning: `void * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/alloc.h:218: warning: variable `void * p' might be clobbered by `longjmp' or `vfork'
/u/jbuck/egcs/include/g++/alloc.h:411: warning: `void * p' might be used uninitialized in this function
/u/jbuck/egcs/include/g++/alloc.h:411: warning: variable `void * p' might be clobbered by `longjmp' or `vfork'

Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')

[Jim Wilson]

It is not a bug in user programs.  It is a bug in gcc'c EH support.

I have discussed this in other mesages, but the basic problem is that flow
can't understand the RTL emitted when exception handling is enabled.  This
causes the dataflow info computed by flow to be incorrect.  This incorrect
info is know to cause at least two problems:
1) Some C++ programs get compiler core dumps due to unallocated pseudos.
2) Some C++ programs get bogus warnings when -Wall is used.
Both of these are the same problem.  The bogus warning is more common;
the core dump is more serious.

Other parts of the compiler that compute flow graphs suffer the same
problem, e.g. haifa-sched.c and profile.c, but since these are much less
critical than flow, we haven't noticed problems with them yet.

Until this problem is fixed, I can not say for sure whether any of
these warnings are legitimate.

In the short term, the easiest solution is probably to just admit that the
EH support isn't ready for production use yet, and make it disabled by
default.  If people think it is important that we have EH support enabled
by default in the first EGCS release, then someone (me?) will have to spend
time looking into this real soon.

Jim

Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')

[John Carr]

> If people think it is important that we have EH support enabled
> by default in the first EGCS release, then someone (me?) will have to spend
> time looking into this real soon.

I consider exception handling important.  I don't know how hard the
bugs will be to fix so I can't say whether it is worth delaying the
release.

Re: Strange warning (variable might be clobbered by `longjmp' or`vfork')

[Toon Moene]

Jim Wilson wrote:

> If people think it is important that we have EH support enabled
> by default in the first EGCS release, then someone (me?) will have 
> to spend time looking into this real soon.

And John Carr replied:

>  I consider exception handling important.  I don't know
>  how hard the bugs will be to fix so I can't say whether
>  it is worth delaying the release.

Let me second this.  Joe Buck has made it abundantly clear that the  
one major selling point of the first egcs release is a reliable C++  
compiler reasonably close to the draft standard, with working  
exception handling support.

Although I cannot personally speak for the Fortran community on  
this list, I think that all other goals can be made subordinate to  
that one.  I have the feeling the g77 crowd can wait, especially if  
we (i.e. the g77-dev `inner circle') can produce a g77-0.5.21 to go  
together with gcc-2.7.2.3 that at least solves all the known bugs in  
g77-0.5.20 and then some - which we _can_ *iff* the GNU machines at  
MIT stay on the 'net reliably.

Toon.

Re: Strange warning (variable might be clobbered by `longjmp' or

[Joe Buck]

> > If people think it is important that we have EH support enabled
> > by default in the first EGCS release, then someone (me?) will have 
> > to spend time looking into this real soon.

Please, Jim, if you can spare the time, I would call this the highest
priority item for the C++ compiler.  I wish I were competent to take
this on myself, but I don't really know the back end internals, only
the C++ front end and only parts of that.

> Let me second this.  Joe Buck has made it abundantly clear that the  
> one major selling point of the first egcs release is a reliable C++  
> compiler reasonably close to the draft standard, with working  
> exception handling support.

Yes, I do think that this is the case.  Not to have it would be kind
of humiliating.

One possibility you might consider as you do the analysis:

From what I understand of the flow, for a setjmp/longjmp pair that
are used to implement exceptions, the automatic variables that may
be in registers will not be accessed after the setjmp is caught.
Rather, code in destructors and catch blocks will be executed and
then a return will take place.  No other code is reachable.

But perhaps the backend does not "know" this and is therefore warning
about execution paths that can never be taken.  One possibility would
then be to annotate the setjmp call as "special".

Another possibility is, of course, that there is a bug and there is
a case where a needed variable will be clobbered.  But I doubt it,
except for one situation: where a try block and a catch block have
an automatic variable in common, and the catch block accesses it.
It's possible that MRS's code does not handle this case correctly:

int foo() {
    int common = 1;
    try {
	// code ...
    }
    catch ( ... ) {
	return common;
    }
}

[ because catch is implemented with a setjmp, common is in a register,
and this register is clobbered ]

But the warnings that we're getting for other places are not of this
type, I don't think (whoops: unless inlining results in something like
this).

Joe

Re: Strange warning (variable might be clobbered by `longjmp' or

[Jim Wilson]

I understand the importance of the EH support, however, I fear that there
are serious flaws with the current code which can not be fixed quickly enough
to avoid impacting our planned for initial release.

From just looking at the RTL, and without trying to understand in detail what
the EH code is doing, I have seen the following problems:
1) There is no indication that control can flow from function calls to the
   code that catches exceptions.  This needs to be handled similarly to how
   nonlocal gotos from nested functions work.  Since there is already code
   to do this, this should be easy to fix.
2) There are indirect jumps (computed gotos) in the EH RTL.  I do not know
   why these are present, however, because they are present, flow must make
   worst case assumptions that these indirect jumps can branch to any label
   in the function whose address is taken.  The setjmp handlers must take
   the address of a label, and hence flow assumes that this indirect jump
   can reach any handler.  This results in a flow graph which is not
   particularly useful, because it contains too many paths which are not
   physically possible.
3) The builtin setjmp/longjmp RTL sends both execution paths to a conditional
   branch, which then tests a pseudo which has been either set to zero or to
   one.  This will branch to the catch routine if this was a longjmp, or
   fall through to the normal code if this was a setjmp.  Since flow does not
   keep track of data values, it can not know this distinction, so it can only
   see that it is possible for the setjmp path to reach both the catch routine
   and the normal code, and likewise for the longjmp.

While looking at flow, I noticed another problem:
4) There is code in flow which handles the case of basic blocks which are
   known to be reachable, but it is unknown how they are reached.  This code
   fixed the problem by adding a bogus execution path from the previous block.
   It should instead abort.

Jim

Re: Strange warning (variable might be clobbered by `longjmp' or

[Joe Buck]

> I understand the importance of the EH support, however, I fear that there
> are serious flaws with the current code which can not be fixed quickly enough
> to avoid impacting our planned for initial release.

Sigh.  Then I guess it has to go out without it at first, but I hope that
time can be devoted to finding a fix.  This is going to disappoint a lot
of people, I'm afraid.

> 3) The builtin setjmp/longjmp RTL sends both execution paths to a conditional
>    branch, which then tests a pseudo which has been either set to zero or to
>    one.  This will branch to the catch routine if this was a longjmp, or
>    fall through to the normal code if this was a setjmp.

I'm confused.  Why aren't setjmp and longjmp two different RTL patterns?

Re: Strange warning (variable might be clobbered by `longjmp' or

[Jim Wilson]

	I'm confused.  Why aren't setjmp and longjmp two different RTL patterns?

I don't understand what the RTL is doing, so it is difficult for me to
describe what is going on.

However, I can point out that there is no RTL for setjmp or longjmp.  There
are just relatively normal looking move insns which implement the functionality
of setjmp/longjmp.  Unfortunately, this is done in a somewhat confusing way.
It appears that the sequences for setjmp/longjmp are setting a pseudo to
0/1, and then branching to the same place which then branches off to the
handler if this pseudo is 1.  This just confuses the control flow.  I have
no idea why it is doing this, or whether my understanding is correct.

Jim

Re: Strange warning (variable might be clobbered by `longjmp' or

[Jeffrey A Law]

  In message < 199709022224.PAA12532@cygnus.com >you write:
  > of setjmp/longjmp.  Unfortunately, this is done in a somewhat confusing way.
  > It appears that the sequences for setjmp/longjmp are setting a pseudo to
  > 0/1, and then branching to the same place which then branches off to the
  > handler if this pseudo is 1.  This just confuses the control flow.  I have
  > no idea why it is doing this, or whether my understanding is correct.
That is how setjmp/longjmp generally work.

When one calls setjmp it saves the state into a jmp_buf and returns zero.

When you longjmp control returns to the site of the setjmp; and the register
state is set up such that it appears that the setjmp call returned a second
time with a return value of one.

I don't know if it's relavent, but gcc knows that certain functions return
twice (setjmp, sigsetjmp, savectx, qsetjmp, etc etc).   By emitting rtl
itself to perform the actions of setjmp/longjmp we may be defeating the
purpose of the code to determine that some calls may return twice.


Jeff

Re: Strange warning (variable might be clobbered by `longjmp' or

[Richard Henderson]

> I don't know if it's relavent, but gcc knows that certain functions return
> twice (setjmp, sigsetjmp, savectx, qsetjmp, etc etc).   By emitting rtl
> itself to perform the actions of setjmp/longjmp we may be defeating the
> purpose of the code to determine that some calls may return twice.

But in those cases, there's an actual call in the RTL.  In this
case there is not. 

In any case, what's the point of setting a pseudo and testing when
you have more or less direct control over the assembly and can arrange
for things to jump the right place directly.


r~

Re: Strange warning (variable might be clobbered by `longjmp' or

[Jeffrey A Law]

  In message < 199709030232.TAA00482@rtl.cygnus.com >you write:
  > > I don't know if it's relavent, but gcc knows that certain functions return
  > > twice (setjmp, sigsetjmp, savectx, qsetjmp, etc etc).   By emitting rtl
  > > itself to perform the actions of setjmp/longjmp we may be defeating the
  > > purpose of the code to determine that some calls may return twice.
  > 
  > But in those cases, there's an actual call in the RTL.  In this
  > case there is not. 
Exactly my point.  Is the lack of a call, and thus the lack of knowledge that
the "EH setjmp" returns twice part of the problem?

  > In any case, what's the point of setting a pseudo and testing when
  > you have more or less direct control over the assembly and can arrange
  > for things to jump the right place directly.
Does jumping back to the setjmp code make the implementation easier?  I don't
really know since I've never looked at the sjlj exception code.

Jeff

Re: Strange warning (variable might be clobbered by `longjmp' or

[Richard Henderson]

> Exactly my point.  Is the lack of a call, and thus the lack of knowledge that
> the "EH setjmp" returns twice part of the problem?

No, there is a NOTE_INSN_SETJMP emitted, which folks examine.  Whether
they do exactly the right thing is still in question though.

> Does jumping back to the setjmp code make the implementation easier?  I don't
> really know since I've never looked at the sjlj exception code.

The sjlj exception code calls expand_builtin_setjmp, which if it
is to replace the function of the same name, must arrive at a 
single location with a value.

However, there is a more efficient way to do this.  I don't know
if it is possible to do in general, since I'm not sure how jumps
get folded and whatnot from normal if statements.

What we want is for there not to be a test zero/non-zero, we want
the setjmp expander to send flow the proper place without a test,
since it knows already due to its construction. 

Perhaps the easiest thing to do is pass expand_builtin_setjmp two
more arguments that say where to go for true and false control flows. 
In sjlj, we give it the labels we already have; in expand_builtin,
we pass it the same label for both so it still looks like a function.


r~

Wrong debug info on pc-linux-gnu ?

[Oleg Krivosheev]

Hi, All

looks like i cannot print the content of simpliest classes
in gdb 4.16, pc-linux-gnu, glibc 2.04. GDB reports
<error type>. The same gdb/-g option works just
fine under sparc-solaris2.5.1

Is is known problem?

regards

OK

Re: Wrong debug info on pc-linux-gnu ?

[Bernd Schmidt]

Hi,
> 
> looks like i cannot print the content of simpliest classes
> in gdb 4.16, pc-linux-gnu, glibc 2.04. GDB reports
> <error type>. The same gdb/-g option works just
> fine under sparc-solaris2.5.1

It kind of is. It's not a bug in GCC, but in gdb-4.16. You can do
one of two things:

a) Download a binary of a recent gdb snapshot from one of HJ Lu's
   usual places.
b) Put a "#undef DBX_USE_BINCL" in dbxout.c just before the first
   reference of that macro.

Bernd

Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')

[Andreas Schwab]

Jim Wilson <wilson@cygnus.com> writes:

|> It is not a bug in user programs.  It is a bug in gcc'c EH support.
|> I have discussed this in other mesages, but the basic problem is that flow
|> can't understand the RTL emitted when exception handling is enabled.  This
|> causes the dataflow info computed by flow to be incorrect.  This incorrect
|> info is know to cause at least two problems:
|> 1) Some C++ programs get compiler core dumps due to unallocated pseudos.
|> 2) Some C++ programs get bogus warnings when -Wall is used.

Another problem is that -fdefer-pop breaks due to sjlj EH, especially
visible when a complicated expression involves multiple EH regions.

Andreas.

Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')

[Jeffrey A Law]

  In message <9709010239.AA21568@beeblebrox-84.synopsys.com>you write:
  > It is not clear to me that it represents an actual bug (that is, that in
  > the execution of the programs where we've seen these messages, that any
  > flow is possible that accesses the automatic variables being warned about
  > after setjmp catches a longjmp.  The compiler issues the warning because
  > it cannot prove this; it may be being overly conservative.
Just a note -- I've fixed the flow control problems, so many/most
of the bogus warnings about clobbered by setjmp and such should
be gone in the next snapshot.

  > For example, cd to egcs-97XXXX/libstdc++/tests and say
  > 
  > gcc -c -O -Wall tmap.cc
Well, I get the following on my linux box after fixing the flow
control problems.  So, there's still at least one problem with the
flow control graph, but it's a whole lot better than before!

/usr/egcs/include/g++/tree.h: In method `struct __rb_tree_node<pair<const int,int> > * rb_tree<int,pair<const int,int>,select1st<pair<const int,int> >,int_less,__default_alloc_template<false,0> >::create_node(const struct pair<const int,int> &)':
/usr/egcs/include/g++/tree.h:447: warning: control reaches end of non-void function `rb_tree<int,pair<const int,int>,select1st<pair<const int,int> >,int_less,__default_alloc_template<false,0> >::create_node(const pair<const int,int> &)'
/usr/egcs/include/g++/tree.h: In method `struct __rb_tree_node<pair<char *const,int> > * rb_tree<char *,pair<char *const,int>,select1st<pair<char *const,int> >,str_less,__default_alloc_template<false,0> >::create_node(const struct pair<char *const,int> &)':
/usr/egcs/include/g++/tree.h:447: warning: control reaches end of non-void function `rb_tree<char *,pair<char *const,int>,select1st<pair<char *const,int> >,str_less,__default_alloc_template<false,0> >::create_node(const pair<char *const,int> &)'
% 

Jeff