Re: ATTRIBUTE_NORETURN on sets_cc0_p

[Mark Mitchell <mark at markmitchell dot com>]

>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:

    Jeffrey>   In message
    Jeffrey> <199810161737.KAA07180@smtp.earthlink.net>you write:
    >> 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.
    Jeffrey> Well, I know where most of them are comming from.  It's
    Jeffrey> not an easy problem to resolve.


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

    Jeffrey> That one is a little more interesting.  Can you get me a
    Jeffrey> testcase I can look at?  Even C++ is OK :-)

Sure.  g++.robertl/eb132.C on x86-linux-gnu trips this warning for me.
You can run `runtest -tool g++ old-deja.exp=eb132.C' and then look at
the log to see the right set of flags to pass to cc1plus.

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

    Jeffrey> Interesting idea.  If a VAR_DECL has a DECL_INITIAL, then
    Jeffrey> it can't be uninitialized.  It doesn't solve all the
    Jeffrey> problems, but would kill some of the false positives
    Jeffrey> created by global optimizations.

    Jeffrey> I'm less sure about PARM_DECLs.  Seems to me that a
    Jeffrey> PARM_DECL is always implicitly initialized by the caller
    Jeffrey> and we should never warn about them.

That's what I meant.  A VAR_DECL with DECL_INITIAL or a PARM_DECL
should never be warned about.  That's not a complete solution, but it
would be a failsafe, and would get rid of some of the most obvious
false positives. 

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com