Re: [PATCH] PR50325 store_bit_field: Fix for big endian targets

[Richard Sandiford <rdsandiford at googlemail dot com>]

Eric Botcazou <ebotcazou@adacore.com> writes:
>> OK, I see how the two are different now, but I still don't get why the
>> current version is right.  If we say words are 16 bits for simplicity,
>> and we're storing VALUE == 0x0001_2345 into a 3-byte BLKmode bitfield,
>> surely we want to store 0x01_2345 rather than 0x00_0123?
>
> Why?  If you want this semantics, you need to use a bitfield with integer mode

It's the interpretation and mode of VALUE that I'm worried about.
Doesn't FIELDMODE describe STR_RTX (the stored bitfield) instead?

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);

> In Ada, the following case is frequent: you have a record type with BLKmode and 
> an alignment that causes it to padded (because the size is always a multiple 
> of the alignment).  You have a field in another record type whose type is the 
> first record type but with a representation clause that prescribes the size 
> without the padding.  The Ada compiler must accept that.  So the field is made 
> a BLKmode bitfield, with DECL_SIZE (size w/o padding) smaller than TYPE_SIZE 
> (size w/ padding).  When you're assigning a value to the field, you drop the 
> rightmost bytes in memory order, which are junk since padding.

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.)
Must VALUE be a memory?  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?

Since Andreas was fixing C++ bugs, I assume the same situation occurs there.
What does it look like in a C++ context?

Richard