Weddington, Eric schrieb:
From: Georg-Johann Lay
The first step would be to bisect and find the patch that lead to
PR53923. It was not a change in the avr BE, so the question goes
to the authors of the respective patch.
Up to now I didn't even try to bisect; that would take years on the
host that I have available...
My only real concern is that this is a major feature addition and
the AVR port is currently broken.
I don't know if it's the avr port or some parts of the middle end
that don't cooperate with avr.
I would really, really love to see fixed point support added in,
especially since I know that Sean has worked on it for quite a while,
and you've also done a lot of work in getting the patches in shape to
get them committed.
But, if the AVR port is currently broken (by whomever, and whatever
patch) and a major feature like this can't be tested to make sure it
doesn't break anything else in the AVR backend, then I'm hesitant to
approve (even though I really want to approve).
I don't understand enough of DF to fix PR53923. The insn that leads
to the ICE is (in df-problems.c:dead_debug_insert_temp):
(insn 328 886 866 37 (set (reg:SF 16 r16)
(unspec:SF [
(reg:SF 16 r16)
(reg/v:SF 4 r4 [orig:162 b ] [162])
] UNSPEC_COPYSIGN)) libgcc2-mulsc3.c:1307 322 {copysignsf3}
(expr_list:REG_DEAD (reg/v:SF 4 r4 [orig:162 b ] [162])
(expr_list:REG_DEAD (reg/v:SF 4 r4 [orig:162 b ] [162])
(expr_list:REG_EQUAL (unspec:SF [
(const_double:SF 0 [0] 0.0 [0x0.0p+0])
(reg/v:SF 4 r4 [orig:162 b ] [162])
] UNSPEC_COPYSIGN)
(nil)))))
The only odd thing is that REG_DEAD r4 is there twice. Dunno if that is
ok or confuses DF.
I'll defer to Denis on this one. Or, until the AVR port is fixed and
can be tested properly.
I already asked at gcc-help for that issue, but no response :-(
http://gcc.gnu.org/ml/gcc-help/2012-08/msg00014.html
Oh, an afterthought: Can this patch work on a snapshot *before* the
breakage from PR53923?
Yes, of course. It's pure avr stuff.
The patch would even work fine with 4.7, there is no reason why it
should break, provided it works fine with trunk.
I see that that bug report was only from a month ago,
and doing that might give us some indication that the
patch won't break anything else on the AVR port.
The avr port is still the same as 4.7, except PR53344 which just
changes text output in avr_assembler_integer to use binutils
PR13503 (byte relocs for __memx addresses).
Johann
