Potential small bug in egcs

[Greg Harvey]

There appears to be a small bug in egcs (tested with 1.0.3 & 1.1,
apologies if it's been fixed in a later snapshot), where, in some
cases, spurous 'might be used undefined' warnings are generated when
functions with an attribute(__noreturn__) are used. These popped up in
a few cases with guile in the time leading up to the release of 1.3,
when an effort was made to remove most of the compiler warning
messages from the code. If any extra information is needed (like the
actual functions that caused the actual warnings in guile), send me a
mail and I'll provide them.

Please cc any relevant replys, since I'm not subscribed to this list.

This is the message I sent to Jim Blandy (guile maintainer) about the
problem.
------- Start of forwarded message -------
To: Jim Blandy <jimb@red-bean.com>
Subject: Re: guile warnings
References: <199809290507.AAA05806@totoro.red-bean.com> <m3k92ncezc.fsf@behemoth.dethturd> <wwnlnn2kgh2.fsf@totoro.red-bean.com> <m3r9wsvwqd.fsf@behemoth.dethturd> <wwnbtnt73bj.fsf@totoro.red-bean.com> <m3hfxlxn8e.fsf@behemoth.dethturd> <wwnogrs5g5j.fsf@totoro.red-bean.com> <m3g1d4dp8v.fsf@behemoth.dethturd> <wwnvhllsdxz.fsf@totoro.red-bean.com>
From: Greg Harvey <Greg.Harvey@thezone.net>
Date: 16 Oct 1998 04:14:50 -0230
Message-ID: <m390ihypi5.fsf@thezone.net>

Jim Blandy <jimb@red-bean.com> writes:

> Applied your patch --- thanks!
> 
> I'm a little concerned that EGCS might be being dumb because it
> doesn't understand the SCM_NORETURN declarations (see error.h); those
> provide the control flow information that would normally allow EGCS to
> make the correct decision.  If that is indeed the problem, then we
> need to either find the correct way to tell EGCS about functions that
> never return, or send the EGCS people a bug report.

It does understand noreturn (if not, there'd probably be a lot more
warnings). It does, however, fail in the particular case that occurs
in at least scm_ithrow (and I'll assume, for now, the other places
where I added initializers, since looking at too much c code can be
dangerous and annoying >:) 

The problem only seems to be triggered by auto variables that are
conditionally initialized based on other auto variables, with the
initial initialization of the dependee being part of an if-else, where
the else will call a non-returning function (try saying that three
times fast). Since it won't occur with a return statment, I'm inclined
to think it is a bug.

The smallest test that I've come up with to demonstrate it so far is
this (also works with a new function with a noreturn attribute): 


int glb_sum;

#ifdef BE_BUGGY

#define ABORTIT abort()
#else
#define ABORTIT return
#endif

void
testit(int a)
{
	int dependee, dependent, i;
	if (a >= 0) dependee=2;
	else {
		ABORTIT;
	}
	if(dependee != 3) 
		dependent = 43;
	
	for(i=0; i<dependent; i++) {
		glb_sum= dependent+dependee;
	}
}

[greg@behemoth src]$ pgcc --version
pgcc-2.91.57
[greg@behemoth src]$ pgcc -Wall -Wundefined -O2 -c pgcc-bug.c
[greg@behemoth src]$ pgcc -DBE_BUGGY -Wall -Wundefined -O2 -c pgcc-bug.c
pgcc-bug.c: In function `testit':
pgcc-bug.c:21: warning: `dependent' might be used uninitialized in this function


(this is mostly structured after scm_ithrow, where jmpbuf was the
culprit)

Same thing happens with egcs v1.0.2

What is sort of odd about this, is that adding an else bit after the
initialization of depender (which does a bunch of stuff, with another
nested if and both branches either returning or calling a noreturn
functions, as in scm_ithrow) will stop the warning for this code, but
didn't with scm_ithrow. I'm not sure what is different about
scm_ithrow.

-- 
Greg
------- End of forwarded message -------