Mark Mitchell wrote:
Chao-Ying, I'm also interested in whether or not these changes have any
impact on C++. With your changes, does GNU C++ now accept any
fixed-point constructs?
Chao-ying's on vacation this week. AFAIK Chao-ying's code does nothing explicit
to support, or not support, C++
Richard Sandiford wrote:
Nigel Stephens <[EMAIL PROTECTED]> writes:
I notice that at least the 32-bit rs6000, i386, sparc, frv, sh, cris,
mcore, score, arm & pa backends still implement adddi3 as either a
define_insn which outputs two instructions or an explicit define_expand
Richard Sandiford wrote:
Nigel Stephens <[EMAIL PROTECTED]> writes:
While I agree with you philosophically, it feels like (b) might be quite
a major task. A number of optimisation passes which currently recognise
and MUL and PLUS separately (e.g. loop strength reduction) would now
Richard Sandiford wrote:
Nigel Stephens <[EMAIL PROTECTED]> writes:
While I agree with you philosophically, it feels like (b) might be quite
a major task. A number of optimisation passes which currently recognise
and MUL and PLUS separately (e.g. loop strength reduction) would now
Richard Sandiford wrote:
As far as madd goes, I think it would be better to either
(a) get combine to handle this situation or (b) get expand
to generate a fused multiply-add from the outset.
(b) sounds like it might be useful in its own right. At the moment we
treat the generation of floati
Fu, Chao-Ying wrote:
> Hello,
>
> I think there is a bug in mips_pass_by_reference when the mips abi
> is EABI to pass TImode parameters.
>
>
> The following code is from the mainline GCC "mips.c".
> -
> mips_pass_by_reference (CUMULATIVE_ARGS *cum ATTRIBUTE_UNUSED,
>
