On 8/22/19 8:40 AM, Martin Sebor wrote:
> On 8/21/19 4:47 PM, Jeff Law wrote:
>> On 8/19/19 7:57 AM, Richard Biener wrote:
>>
>>>
>>> +static tree
>>> +objsize_from_type (tree object)
>>> +{
>>> + if (TREE_CODE (object) != ADDR_EXPR)
>>> + return NULL_TREE;
>>> +
>>> + tree type = TREE_TYPE (object);
>>> + if (POINTER_TYPE_P (type))
>>>
>>> that if looks suspicious... I'd say
>>> if (!POINTER_TYPE_P (type))
>>> return NULL_TREE;
>>>
>>> is better
>> Sure. But we may not be able to use this anyway as you noted later,
>> depending on the type is not safe.
>>
>>>
>>> + type = TREE_TYPE (type);
>>>
>>> + if (TREE_CODE (type) == ARRAY_TYPE && !array_at_struct_end_p
>>> (object))
>>> + {
>>>
>>> array_at_struct_end_p will never return true here since you pass it
>>> an ADDR_EXPR... you wanted to pass TREE_OPERAND (object, 0) here?
>> I think you're right. Given this was cribbed from the tail of another
>> function elsewhere, I suspect that other function has the same issue.
>>
>> I suspect ultimately we want to fix that other copy and drop
>> objsize_from_type.
>
> Is the other copy compute_objsize in builtins.c? The function
> has a comment that says it "is intended for diagnostics a should
> not be used to influence code generation or optimization."
> I added that comment on your request, not because the function
> relies the type of objects but because it conservatively uses
> the lower bound of ranges of offsets into arrays to determine
> the minimum size.
That's the one. What's sad here is when I copied the tail of that
routine I noted the comment. By the time I came back to the changes
several days (or weeks?) later the issue had been totally wiped from my
working memory.
I think I can just call get_base_address on the 0th operand of the
ADDR_EXPR and if I get back a _DECL node extract its DECL_UNIT_SIZE.
Jeff
