Created attachment 3917 [details]
soft-fp op-common.h patch

I took a closer look at this during the week.  Here is an example of the code
that produces the warning (from divsf3.c):

SFtype __divsf3(SFtype a, SFtype b)
{
  FP_DECL_EX;
  FP_DECL_S(A); FP_DECL_S(B); FP_DECL_S(R);
  SFtype r;

  FP_INIT_ROUNDMODE;
  FP_UNPACK_S(A, a);
  FP_UNPACK_S(B, b);
  FP_DIV_S(R, A, B);
  FP_PACK_S(r, R);
  FP_HANDLE_EXCEPTIONS;

  return r;
}

Compiling this file produces:
  warning: ‘R_e’ may be used uninitialized in this function

I have preprocessed the source file and looked very closely at how the warning
is produced -- it is triggered by FP_PACK_S -> _FP_PACK_CANONICAL.

The data flow is quite complex and I cannot convince myself that the line X##_e
+= _FP_EXPBIAS_##fs from _FP_PACK_CANONICAL always operates on an initialised
X##_e variable.  GCC seems to agree with me.  I fear there is a bug here,
whereby R_e is being incremented on an uninitialised variable.

Subject: Re:  silence warning in soft-fp

On Fri, 8 May 2009, bje at sources dot redhat dot com wrote:

>   FP_DIV_S(R, A, B);
>   FP_PACK_S(r, R);

> Compiling this file produces:
>   warning: ‘R_e’ may be used uninitialized in this function
> 
> I have preprocessed the source file and looked very closely at how the warning
> is produced -- it is triggered by FP_PACK_S -> _FP_PACK_CANONICAL.
> 
> The data flow is quite complex and I cannot convince myself that the line X##_e
> += _FP_EXPBIAS_##fs from _FP_PACK_CANONICAL always operates on an initialised
> X##_e variable.  GCC seems to agree with me.  I fear there is a bug here,
> whereby R_e is being incremented on an uninitialised variable.

I don't think there is a bug.  Each case in _FP_DIV sets R##_c.  The code 
you refer to in _FP_PACK_CANONICAL only applies if R##_c ends up as 
FP_CLS_NORMAL.  That only applies in the 
_FP_CLS_COMBINE(FP_CLS_NORMAL,FP_CLS_NORMAL) case in _FP_DIV, which sets 
R##_e.  Every other case sets R##_c either explicitly or from the class of 
one of the operands (or using _FP_CHOOSENAN which should also set it), and 
when set from one of the operands it is FP_CLS_NAN.  I'd suppose that the 
compiler does not try to keep track of the exact set of possible values 
and so gives this warning.

Instead of initializing to 0, using "X##_e = X##_e" would silence the 
warning without generating additional initialization code.

Thanks, Joseph.  I looked at the code for a while, but could not convince myself
as you have :-)  I'll propose a patch using X=X instead.

I will post this patch:

@@ -31,7 +31,7 @@
    MA 02110-1301, USA.  */
 
 #define _FP_DECL(wc, X)                                                \
-  _FP_I_TYPE X##_c __attribute__((unused)), X##_s, X##_e;      \
+  _FP_I_TYPE X##_c __attribute__((unused)), X##_s, X##_e = X##_e;      \
   _FP_FRAC_DECL_##wc(X)
 
 /*

Created attachment 3956 [details]
Revised patch.

Is there any interest in eliminating this warning?

The proposed patch is bad, it will inhibit warnings even for the non-canonical
paths.  I guess asm ("" : "=rm" (X##_e)) hidden in some macro put into the
problematic macros would be much better, assuming it doesn't penalize generated
code.

This warning issue is still present in current sources (for both multiplication
and division, it seems).

Fixed by commit 573cd4843a9737103e6842470aea73e7687c2193.