Quoting Bernd Schmidt <ber...@codesourcery.com>:
I'm not getting the point of the use of attribute((transparent_union)).
Without that attribute, lots of ABIs add a lot of overhead for function
argument and return value passing. E.g. instead of putting the argument
in a register, put it on the stack, and place a pointer to that stack
location in a register; instead of returning the result in a register,
have the caller pass a pointer to a location in the stack, then have the
callee write the result via that pointer into the stack, and return the
pointer.
With the transparent union attribute, you get the same straigtforward
compiled code as before with CUMULATIVE_ARGS used throughout.
That should be removed to eliminate potential differences when compiling
other compilers,
I'm not sure what you mean here. Do you want to have compilation units
of ENABLE_CHECKING compilers be compatible with !ENABLE_CHECKING ones?
In that case, we'd have to revamp vec.h, among others.
and to eliminate a potential source of bugs when
passing cumulative_args_t arguments.
Is that about not trusting the bootstrap gcc to implement that attribute
correctly?
Or do you want the integrity check from the ENABLE_CHECKING case to be
always present?
[fr30.c:fr30_setup_incoming_varargs]
- if (targetm.calls.strict_argument_naming (arg_regs_used_so_far))
+ /* ??? the code inside is a pointer increment. */
+ if (targetm.calls.strict_argument_naming (arg_regs_used_so_far_v))
What does this comment mean?
It means that the code inside the if clause. i.e.:
arg_regs_used_so_far += fr30_num_arg_regs (mode, type);
is nonsense. arg_regs_used_so_far is a pointer to int. The pointed-to int
is supposed to record the number of words used for argument passing.
The statement increments the pointer.
