On 01/08/2017 00:08, Joseph Myers wrote:
On Wed, 26 Jul 2017, Jeff Law wrote:
TYPE_SIZE, according to my understanding, should be a tree for the size
of the expression in bits.
The problem is for msp430 that size varies depending on where it's used.
ie, in a register an object might have a bitsize of 20 bits, but in
memory its size is 32 bits.
I don't think that TYPE_SIZE has any concept that the use context is
relevant to selecting the proper size.
TYPE_SIZE_UNIT is unambiguously the memory size, including padding; it's
used for sizeof. TYPE_SIZE may be less clear. We've had issues before
with unions with x87 long double, which has 80-bit precision in registers
but is 12-byte or 16-byte in memory; that was wrong code (bug 71522)
rather than an ICE, but the long double case may be useful for comparison
of what various type properties are set to in such cases.
Thanks for the responses.
Could it be possible to use "variable_size" to help the compiler choose
which size to use for TYPE_SIZE? Although the problem I see with this
right away is that variable_size is never executed on an INTEGER_CST,
perhaps this is part of the problem?
Zooming out a bit from TYPE_SIZE, the value that ends up being incorrect
as a result of TYPE_SIZE is rli->bitpos, this value is used a lot in
stor_layout.c:place_field, perhaps I need to look deeper in there.
For this specific bug, rli->bitpos is 20*ARRAY_SIZE, if I modify it in
a GDB session to be 32*ARRAY_SIZE, the case no longer ICEs.
Any suggestions on where I should be looking given this information?
Is this fix for this likely to be in the back-end?
