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

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

[Jim Wilson]

	Actually, is this particular warning a really useful feature, that saves
	people from making a bug every other day? I don't think so. To the
	contrary, I've seen it several times and every time it was bogus. Perhaps
	it would be better to just get rid of this warning?

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.

Jim

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 `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

egcs 970828 and X11 on linux/x86

[H.J. Lu]

Hi,

On linux/x86, I bootstapped egcs 970828 with -O -g and used that egcs
to compile egcs with -O6 -fomit-frame-pointer. Then I used that
compiler to compile XFree86 3.3.1 with -O6 -fno-exceptions. I didn't
see any problems with the rebuilt XFree86 3.3.1.

BTW, I applied Jim's patch to i386.c:

Wed Aug 27 14:52:54 1997  Jim Wilson  

	* i386.c (ix86_expand_epilogue): Emit blockage instruction when pic.

Without it, shared libraries may be miscompiled with -O2/-O3 or above.

-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

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

[Kamil Iskra]

On Sat, 30 Aug 1997, Jim Wilson wrote:

> 	The following code gives a strange warning.
> 	~/Prog> g++ -Wall -O -c egcs-feature2.cc
> 	egcs-feature2.cc: In function `void f()':
> 	egcs-feature2.cc:15: warning: variable `int maxrows' might be clobbered by
> 	`longjmp' or `vfork'
[snip]
> This can probably be fixed by making the sjlj EH support and flow interact
> better.

Actually, is this particular warning a really useful feature, that saves
people from making a bug every other day? I don't think so. To the
contrary, I've seen it several times and every time it was bogus. Perhaps
it would be better to just get rid of this warning?

/ Kamil Iskra - AMIGA 1200, 68030 50MHz, HDD 1.6 GB, 18 MB RAM \
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
| http://student.uci.agh.edu.pl/~iskra                         |
\ PGP public key available via Finger or WWW                   /

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

[Jim Wilson]

	The following code gives a strange warning.
	~/Prog> g++ -Wall -O -c egcs-feature2.cc
	egcs-feature2.cc: In function `void f()':
	egcs-feature2.cc:15: warning: variable `int maxrows' might be clobbered by
	`longjmp' or `vfork'

This is due to problems with the setjmp/longjmp exception handler support.
It goes away if you use -fno-exceptions or -fno-sjlj-exceptions.

An exception handler block is being inserted into the program.  This involves
adding a (builtin) setjmp call.  This confuses the RTL a little, and flow
ends up thinking that the variable max is live across a setjmp call.
This can probably be fixed by making the sjlj EH support and flow interact
better.

Jim

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

[Jeffrey A Law]

  > 	The following code gives a strange warning.
  > 	~/Prog> g++ -Wall -O -c egcs-feature2.cc
  > 	egcs-feature2.cc: In function `void f()':
  > 	egcs-feature2.cc:15: warning: variable `int maxrows' might be clobbered  by
  > 	`longjmp' or `vfork'
I believe I've just fixed this problem.  The next egcs snapshot
should compile your code without that bogus warning.

Jeff

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

[Mike Stump]

> Date: Tue, 26 Aug 1997 13:14:47 +0200 (MET DST)
> From: Tobias Ringstrom <tobias@it.chalmers.se>
> To: egcs@cygnus.com

> The following code gives a strange warning.

> egcs-feature2.cc:15: warning: variable `int maxrows' might be clobbered by
> `longjmp' or `vfork'

> Is that correct?

No, the warning appears bogus in this case.  I might guess that it can
never be a valid warning, but I have yet to prove that to myself.

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

[Tobias Ringstrom]

The following code gives a strange warning.

class ios {
public:
  virtual ~ios();
};
class istream : virtual public ios {
public:
  istream() { }
};
class ifstream : public istream {
public:
  ifstream() { }
};
void f()
{
  int maxrows=20;
  ifstream file;
  while (maxrows < 100)
    maxrows *= 2;
}

When compiling using egcs-2.90.02 (970825), I get:

~/Prog> g++ -Wall -O -c egcs-feature2.cc
egcs-feature2.cc: In function `void f()':
egcs-feature2.cc:15: warning: variable `int maxrows' might be clobbered by
`longjmp' or `vfork'

Is that correct?  If yes, I would appreciate is anyone could explain why.
The warning disappears if I move the line 'ifstream file;' before the
line 'int maxrows=20;'.

	/ Tobias