ATTRIBUTE_NORETURN on sets_cc0_p

[Jeffrey A Law]

  In message < 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.
Well, I know where most of them are comming from.  It's 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!
That one is a little more interesting.  Can you get me a testcase I can look
at?  Even C++ is OK :-)

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

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

Another thought is to perform the necessary analysis before gcse so that
gcse's actions don't confuse things.  That's a pretty heavyweight solution
though.

jeff