ATTRIBUTE_NORETURN on sets_cc0_p
Mark Mitchell
mark@markmitchell.com
Fri Oct 16 17:50:00 GMT 1998
>>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:
Kaveh> Mark,
Kaveh> Please let me clear up a couple of things. The
Kaveh> warning *has not been installed in egcs*. Its only in my
Kaveh> local sources.
Ah, that was my main misunderstanding.
Kaveh> Second, the detection patch *does not put this warning
Kaveh> in -W -Wall*. It only gets turned on when specifically
Kaveh> asked for via -Wmissing-noreturn. (I don't recall if I
Kaveh> submitted the final version or not, but it does exactly as
Kaveh> you ask. Ie, only warn when asked for.)
Very good.
Kaveh> Third, I'm not doing this for the trivial optimization
Kaveh> it affords. My reason is because adding noreturn gives
Kaveh> more information to flow analysis which helps remove some
Kaveh> of the uninitialized variable warnings.
OK. But, those dang uninitialized variable warnings have been in such
bad shape of late that I expect that we'd be better off investigating
them directly. At this point, one C++ regression test is failing
because the compiler complains that `this' might be used uninitialized
even though it's a parameter and therefore always initialized! I
think the warning code should have some basic failsafe that checks
DECL_INITIAL and doesn't warn for PARM_DECLs to avoid getting itself
confused, but I haven't suggested this yet because implementing this
failsafe may obscure some the real problems with the
uninitialized-variable code.
--
Mark Mitchell mark@markmitchell.com
Mark Mitchell Consulting http://www.markmitchell.com
More information about the Gcc
mailing list