> It's the interpretation and mode of VALUE that I'm worried about. > Doesn't FIELDMODE describe STR_RTX (the stored bitfield) instead?
Yes, FIELDMODE is the mode of the target field. > If so, it seems odd that we're using a property of STR_RTX to determine > the interpretation/justification of VALUE. That is, we're using > FIELDMODE before, rather than after: > > /* This is the mode we must force value to, so that there will be > enough subwords to extract. Note that fieldmode will often (always?) be > VOIDmode, because that is what store_field uses to indicate that this is a > bit field, but passing VOIDmode to operand_subword_force > is not allowed. */ > fieldmode = GET_MODE (value); > if (fieldmode == VOIDmode) > fieldmode = smallest_mode_for_size (nwords * BITS_PER_WORD, MODE_INT); First of all, reusing FIELDMODE here is clearly very confusing, this should be VALUEMODE instead. OK, I understand the concern. But what if VALUE has VOIDmode and the field BLKmode? In this case, VALUEMODE may be integral and using it to determine the justification will be wrong. > In this sort of assignment, what does VALUE look like? Does it need to be > BLKmode? Or can it have an integer mode? (I assume the former, since the > latter seems contrary to what you said about integer modes above.) I think it must be BLKmode or VOIDmode. > Must VALUE be a memory? Or a constant probably. > Could we assert: > > gcc_assert ((fieldmode == BLKmode) == (GET_MODE (value) == BLKmode)); > gcc_assert (fieldmode != BLKmode || MEM_P (value)); > > at the beginning of store_bit_field_1? We could indeed try, modulo constants I think. -- Eric Botcazou
