Re: ATTRIBUTE_NORETURN on sets_cc0_p

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: Mark Mitchell <mark@markmitchell.com>
 > 
 > >>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:
 > 
 >     Jeffrey> I'm very tempted to punt it for now since marking
 >     Jeffrey> sets_cc0_p as noreturn is strictly an optimization.
 > 
 > I don't really think the `function not marked noreturn but doesn't
 > return' warning is very good.  This warnings means that to get gcc to
 > shut up, I *must* use a gcc extension on perfectly valid, unambiguous,
 > unconfusing code.  That's unreasonable.  This warning attempts to
 > force me to give the compiler an additional optimization hint, not to
 > in any way clarify the function.  (It's not like signed/unsigned
 > comparison, for example, which is well-defined but wicked confusing.)
 > 
 > I think the right solution is no pull this warning out of -W -Wall,
 > and only enable it with a special -Wnoreturn flag or some such.
 > -- 
 > Mark Mitchell 			mark@markmitchell.com


Mark,

	Please let me clear up a couple of things.  The warning *has not
been installed in egcs*.  Its only in my local sources.  I've just been
cleaning up the spots it detects. 

	Second, the detection patch *does not put this warning in -W
-Wall*.  It only gets turned on when specifically asked for via
-Wmissing-noreturn.  (I don't recall if I submitted the final version or
not, but it does exactly as you ask.  Ie, only warn when asked for.)

	Third, I'm not doing this for the trivial optimization it
affords.  My reason is because adding noreturn gives more information to
flow analysis which helps remove some of the uninitialized variable
warnings. 

	I'll submit the detection patch to egcs-patches so you can see
what I mean.  I hope this helps allay your concerns. 

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.