This is the mail archive of the gcc@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]

Need advice with store_bit_field and its call chain


The ia64 XFmode patch causes this test case
(c-torture/compile/20000818-1.c)

  void
  foo (long double x)
  {
    struct {long double t;} y = {x};
  }

to abort in store_bit_field with -O2.
store_bit_field is called like so:

 store_bit_field (str_rtx=(reg/v:XF 340 [ y ]),
                  bitsize=128, 
                  bitnum=0, 
                  fieldmode=XFmode, 
                  value=(reg/v:XF 339 [ x ]),
                  total_size=16)

Intuitively, this should be handled by calling 
emit_move_insn(str_rtx, value); and we're done.  
However, store_bit_field does not think it can
do this, because that possibility is guarded by
the following test:

  if (bitpos == 0
      && bitsize == GET_MODE_BITSIZE (fieldmode)
      && (GET_CODE (op0) != MEM
	  ? ((GET_MODE_SIZE (fieldmode) >= UNITS_PER_WORD
	     || GET_MODE_SIZE (GET_MODE (op0)) == GET_MODE_SIZE (fieldmode))
	     && byte_offset % GET_MODE_SIZE (fieldmode) == 0)
	  : (! SLOW_UNALIGNED_ACCESS (fieldmode, MEM_ALIGN (op0))
	     || (offset * BITS_PER_UNIT % bitsize == 0
		 && MEM_ALIGN (op0) % GET_MODE_BITSIZE (fieldmode) == 0))))

I have not unsnarled the third clause, but it doesn't 
matter, because the second one is the problem.  The
bitsize is 128, but GET_MODE_BITSIZE (XFmode) is 96
(really should be 80, but that breaks too much other
stuff).  The bitsize is coming from store_constructor:

	  if (host_integerp (DECL_SIZE (field), 1))
	    bitsize = tree_low_cst (DECL_SIZE (field), 1);
	  else
	    bitsize = -1;

and DECL_SIZE of the field is - correctly - 128 bits.

There is a similar problem with c-torture/compile/20001212-1.c
and extract_bit_field.

I'm wondering what the right fix here is.  It is not correct to
describe XFmode as having 128 bits -- it has 96 (really 80) and a
whole bunch of padding.  Also, if I don't make the bitsize smaller
than the TFmode bitsize, other things break (like the wider_mode[]
sort in genmodes.c, for starters).  It might be correct to tell
store_bit_field that if the modes match, it doesn't matter if the
sizes don't; or it might be correct to adjust the size up in
store_constructor; or maybe nothing will work.

Ideas?

zw


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