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,
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
followed
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
need
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
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
need
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,
