This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: x86-64 XFmode long doubles


Jan Hubicka <hubicka@ucw.cz> writes:

> ... trivial fix to real.c to avoid uninitialized memory being output
> at fourth word of 128-bit XFmode constants.  (I noticed this while
> comparing assembly output from old and new compiler)

I don't doubt the problem, but this change is wrong on two grounds.

> *** real.c	13 Oct 2003 21:16:18 -0000	1.129
> --- real.c	30 Oct 2003 20:32:45 -0000
> *************** encode_ieee_extended (const struct real_
> *** 3030,3035 ****
> --- 3030,3040 ----
>       buf[0] = image_hi << 16, buf[1] = sig_hi, buf[2] = sig_lo;
>     else
>       buf[0] = sig_lo, buf[1] = sig_hi, buf[2] = image_hi;
> + 
> +   /* Avoid uninitialized data to be output by compiler when XFmode is extended
> +      to 128 bits.  */
> +   if (GET_MODE_SIZE (XFmode) == 16)
> +     buf[3] = 0;
>   }
>   
>   static void

First, this breaks bootstrap for all targets that do not define
XFmode.  Second, the uninitialized word is supposed to be cleared by
encode_ieee_extended_128, and doing it here will overwrite memory
beyond the end of the array on machines where FLOAT_WORDS_BIG_ENDIAN
is true and encode_ieee_extended_128 is used.  (There may not be any
such machines, but we should not introduce a latent bug like that.)

Please back this patch out and investigate why encode_ieee_extended_128
is not clearing the uninitialized word properly.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]