Hi,
The HP-UX port on the IA-64 architecture defines the MEMBER_TYPE_FORCES_BLK
macro with this comment:
/* This needs to be set to force structure arguments with a single
integer field to be treated as structures and not as the type of
their field. Without this a structure with a single char will be
returned just like a char variable, instead of being returned at the
top of the register as specified for big-endian IA64. */
#define MEMBER_TYPE_FORCES_BLK(FIELD, MODE) \
(!FLOAT_MODE_P (MODE) || (MODE) == TFmode)
That's problematic for Ada because record types with BLKmode are far less easy
to manipulate (in particular to pack in containing records) than record types
with integer modes.
It seems to me that it's an implementation bias that can be eliminated.
Firstly, SPARC64 has the same set of constraints and doesn't define
MEMBER_TYPE_FORCES_BLK. Secondly, ia64_function_value reads:
else
{
if (BYTES_BIG_ENDIAN
&& (mode == BLKmode || (valtype && AGGREGATE_TYPE_P ('))))
{
rtx loc[8];
int offset;
int bytesize;
int i;
offset = 0;
bytesize = int_size_in_bytes (valtype);
for (i = 0; offset < bytesize; i++)
{
loc[i] = gen_rtx_EXPR_LIST (VOIDmode,
gen_rtx_REG (DImode,
GR_RET_FIRST + i),
GEN_INT (offset));
offset += UNITS_PER_WORD;
}
return gen_rtx_PARALLEL (mode, gen_rtvec_v (i, loc));
}
else
return gen_rtx_REG (mode, GR_RET_FIRST);
}
Note that we already test the type 'valtype'. Moreover, int_size_in_bytes is
invoked unconditionally on 'valtype' and would segfault if it was 0, so
valtype is set every time mode == BLKmode. So I think having a non-BLKmode
on records with a single integer field would not change anything as far as
the return value is concerned.
What do you think? Thanks in advance.
--
Eric Botcazou
