On Jan 13, 2012, at 10:59 PM, DJ Delorie wrote:
>
>> That should not be necessary as there is a mode check below. Do you
>> hit the issue only when the VOID_TYPE_P check is true? In that case
>> simply delete it - it has become obsolete.
>
> That seems to be happening, yes, but there are other checks
> that might let differing modes through...
>
> /* Changes in machine mode are never useless conversions unless we
> deal with aggregate types in which case we defer to later checks. */
> if (TYPE_MODE (inner_type) != TYPE_MODE (outer_type)
> && !AGGREGATE_TYPE_P (inner_type))
> return false;
>
> Later,
>
> else if (POINTER_TYPE_P (inner_type)
> && POINTER_TYPE_P (outer_type))
> {
> /* Do not lose casts to function pointer types. */
> if ((TREE_CODE (TREE_TYPE (outer_type)) == FUNCTION_TYPE
> || TREE_CODE (TREE_TYPE (outer_type)) == METHOD_TYPE)
> && !(TREE_CODE (TREE_TYPE (inner_type)) == FUNCTION_TYPE
> || TREE_CODE (TREE_TYPE (inner_type)) == METHOD_TYPE))
> return false;
>
> /* We do not care for const qualification of the pointed-to types
> as const qualification has no semantic value to the middle-end. */
>
> /* Otherwise pointers/references are equivalent. */
> return true;
> }
>
> So two different sized pointers to aggregate types will also have a problem?
No, because pointers are not aggregate types.
>
> I'm a little paranoid here because TPF uses different sized pointers a
> *lot* so if we can't guarantee that the rest of the logic keeps the
> conversion, I'd rather keep the explicit check.
For the record, what is TPF ?
Tristan.
