[Bug middle-end/21059] Bogus warning about clobbered variable

["wilson at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #5 from wilson at gcc dot gnu dot org  2005-12-02 04:12 -------
Created an attachment (id=10387)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10387&action=view)
Delay auto-inc generation until after determining which regs live across
setjmp.

This is my proposed untested patch.

While writing this, I realized that we have an actual optimization bug here, in
addition to the spurious warning problem.  ISO C says that if a variable is not
set in between setjmp and longjmp, then its value is preserved by the longjmp. 
GCC implements this by forcing all such variables into stack slots.  Now
suppose we have code like this, where reg100 is a user variable.
  (set reg100 ...)
  (call setjmp)
  ... (mem reg100) ...
  (set (reg101) (plus (reg100) (const_int 8)))
  ... (mem reg101) ...
  (call longjmp)
The value of reg100 should be unchanged.  On IA-64 however, gcc converts this
code to
  (set reg100 ...)
  (call setjmp)
  ... (mem (post_inc (reg100) (const_int 8)) ...
  ... (mem reg101) ...
  (call longjmp)
and now the value of reg100 is being modified, which violates the ISO C spec. 
If program execution can return to the mems after the longjmp, then the code
will not function correctly.  The wrong values will be read from memory.  This
could be a very hard bug to diagnose if it occured in real programs, and if the
longjmp call was in an exception path that rarely occured.

There is also an addition problem here that performing auto-inc optimization on
variables that are forced to stack slots is a de-optimization, as now we need
an additional memory store that we did not need before.  Without my patch, I
get
        ld8 r14 = [r15]
        ;;
        adds r14 = 8, r14
        ;;
        st8 [r15] = r14
        adds r14 = -8, r14
        ;;
        ld8 r34 = [r14], 8
        ;;
        ld8 r33 = [r14]
with my patch I get
        ld8 r15 = [r15]
        ;;
        ld8 r33 = [r15]
        adds r14 = 8, r15
        ;;
        ld8 r34 = [r14]
which is much better.  Not all cases are as lucky as this though.  In some
cases the use of auto-inc addresses would have been better.  Since this only
affects functions that call setjmp, it shouldn't be a serious problem.

One more note, I noticed that we are setting regs_live_at_setjmp, but never
clearing it.  This means it could contain more registers than it should.  But
since this only affects functions that call setjmp, I'm not going to worry
about it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21059