Re: ATTRIBUTE_NORETURN on sets_cc0_p

[Mark Mitchell <mark at markmitchell dot com>]

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