On 08/01/2017 10:26 AM, Jozef Lawrynowicz wrote: > 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? I suspect variable_size is more for things like VLAs where the size of an array may vary at runtime.
What we're dealing here is more that the size of an object varies depending on if it's in a register or in memory. > 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. I think Joseph's suggestion for looking at partial float handling may be useful, though ia64's RFmode may be more interesting as it's not a multiple of 8 in bitsize. IF/KF modes on the ppc port have similar properties. If you could declare a type that corresponds to one of those modes, then build an array of them and follow how that code works it might give you some hints on how to fix intXX. jeff