* Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')
@ 1997-08-31 1:23 Jim Wilson
1997-11-01 21:16 ` Jeffrey A Law
0 siblings, 1 reply; 12+ messages in thread
From: Jim Wilson @ 1997-08-31 1:23 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')
1997-08-31 1:23 Strange warning (variable might be clobbered by `longjmp' or `vfork') Jim Wilson
@ 1997-11-01 21:16 ` Jeffrey A Law
0 siblings, 0 replies; 12+ messages in thread
From: Jeffrey A Law @ 1997-11-01 21:16 UTC (permalink / raw)
To: Tobias Ringstrom; +Cc: egcs
> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')
1997-08-31 23:12 Joe Buck
1997-09-01 12:09 ` Jim Wilson
@ 1997-11-01 21:24 ` Jeffrey A Law
1 sibling, 0 replies; 12+ messages in thread
From: Jeffrey A Law @ 1997-11-01 21:24 UTC (permalink / raw)
To: Joe Buck; +Cc: Jim Wilson, iskra, egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')
1997-09-01 12:09 ` Jim Wilson
1997-09-01 12:23 ` John Carr
@ 1997-09-03 2:29 ` Andreas Schwab
1 sibling, 0 replies; 12+ messages in thread
From: Andreas Schwab @ 1997-09-03 2:29 UTC (permalink / raw)
To: Jim Wilson; +Cc: jbuck, egcs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Strange warning (variable might be clobbered by `longjmp' or`vfork')
1997-09-01 12:23 ` John Carr
@ 1997-09-01 15:32 ` Toon Moene
0 siblings, 0 replies; 12+ messages in thread
From: Toon Moene @ 1997-09-01 15:32 UTC (permalink / raw)
To: egcs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')
1997-09-01 12:09 ` Jim Wilson
@ 1997-09-01 12:23 ` John Carr
1997-09-01 15:32 ` Strange warning (variable might be clobbered by `longjmp' or`vfork') Toon Moene
1997-09-03 2:29 ` Strange warning (variable might be clobbered by `longjmp' or `vfork') Andreas Schwab
1 sibling, 1 reply; 12+ messages in thread
From: John Carr @ 1997-09-01 12:23 UTC (permalink / raw)
To: Jim Wilson; +Cc: egcs
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')
1997-08-31 23:12 Joe Buck
@ 1997-09-01 12:09 ` Jim Wilson
1997-09-01 12:23 ` John Carr
1997-09-03 2:29 ` Strange warning (variable might be clobbered by `longjmp' or `vfork') Andreas Schwab
1997-11-01 21:24 ` Jeffrey A Law
1 sibling, 2 replies; 12+ messages in thread
From: Jim Wilson @ 1997-09-01 12:09 UTC (permalink / raw)
To: Joe Buck; +Cc: egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')
@ 1997-08-31 23:12 Joe Buck
1997-09-01 12:09 ` Jim Wilson
1997-11-01 21:24 ` Jeffrey A Law
0 siblings, 2 replies; 12+ messages in thread
From: Joe Buck @ 1997-08-31 23:12 UTC (permalink / raw)
To: egcs
[ 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'
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')
@ 1997-08-31 22:48 Jim Wilson
0 siblings, 0 replies; 12+ messages in thread
From: Jim Wilson @ 1997-08-31 22:48 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')
1997-08-31 2:07 egcs 970828 and X11 on linux/x86 H.J. Lu
@ 1997-08-31 18:57 ` Kamil Iskra
0 siblings, 0 replies; 12+ messages in thread
From: Kamil Iskra @ 1997-08-31 18:57 UTC (permalink / raw)
To: egcs
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 /
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Strange warning (variable might be clobbered by `longjmp' or `vfork')
@ 1997-08-26 15:53 Mike Stump
0 siblings, 0 replies; 12+ messages in thread
From: Mike Stump @ 1997-08-26 15:53 UTC (permalink / raw)
To: egcs
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Strange warning (variable might be clobbered by `longjmp' or `vfork')
@ 1997-08-26 13:14 Tobias Ringstrom
0 siblings, 0 replies; 12+ messages in thread
From: Tobias Ringstrom @ 1997-08-26 13:14 UTC (permalink / raw)
To: egcs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1997-11-01 21:24 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-08-31 1:23 Strange warning (variable might be clobbered by `longjmp' or `vfork') Jim Wilson
1997-11-01 21:16 ` Jeffrey A Law
-- strict thread matches above, loose matches on Subject: below --
1997-08-31 23:12 Joe Buck
1997-09-01 12:09 ` Jim Wilson
1997-09-01 12:23 ` John Carr
1997-09-01 15:32 ` Strange warning (variable might be clobbered by `longjmp' or`vfork') Toon Moene
1997-09-03 2:29 ` Strange warning (variable might be clobbered by `longjmp' or `vfork') Andreas Schwab
1997-11-01 21:24 ` Jeffrey A Law
1997-08-31 22:48 Jim Wilson
1997-08-31 2:07 egcs 970828 and X11 on linux/x86 H.J. Lu
1997-08-31 18:57 ` Strange warning (variable might be clobbered by `longjmp' or `vfork') Kamil Iskra
1997-08-26 15:53 Mike Stump
1997-08-26 13:14 Tobias Ringstrom
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).