On 1/13/15 01:32, Jeff Law wrote:
> On 01/12/15 10:01, Jeff Law wrote:
>> This indicates a violation of the type safety invariants we're adding to
>> GCC. Simply changing the code to use rtx rather than rtx_insn is
>> probably a step in the wrong direction.
>>
>> Part of the problem here is that R
On 01/12/15 10:01, Jeff Law wrote:
This indicates a violation of the type safety invariants we're adding to
GCC. Simply changing the code to use rtx rather than rtx_insn is
probably a step in the wrong direction.
Part of the problem here is that RTX_FRAME_RELATED_P is valid on both
rtx_insn and
On 01/11/15 07:02, Chen Gang S wrote:
The related commit "1a1ed14 config/h8300: Use rtx_insn" gives an extra
check for rtx, which will cause building libgcc break, after regress it,
it can still generate the correct assemble code.
The related information is below:
[root@localhost libgcc]# ca
The related commit "1a1ed14 config/h8300: Use rtx_insn" gives an extra
check for rtx, which will cause building libgcc break, after regress it,
it can still generate the correct assemble code.
The related information is below:
[root@localhost libgcc]# cat libgcc2.i
typedef int DItype __attrib
