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

Oops, sorry for that. Somehow I still think about these modes as defined
always.

The problem is that I set format to encode_ieee_extended for 128bit
XFmode too. I now notice that IA-64 does use encode_ieee_extended_128.
The problem is that for i386 I do have both formats possible, so I need
runtime way choosing in between those two.

I guess we need init_adjust_machine_modes extension for this.  What
interface would you preffer for that? (adding FLOAT_MODE_RUNTIME or
ADJUST_FLOAT_MODE comes into mind)

Or alternatively we can kill ieee_extended_intel_128_format completely
and make the code to pass around size of entity it is storing into and
decide whether to clear output bit itself.

Honza

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