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]# cat libgcc2.i
typedef int DItype __attribute__ ((mode (DI)));
DItype __muldi3 (DItype u, DItype v)
{
return u + v;
}
[root@localhost libgcc]# /upstream/build-gcc-h8300/gcc/cc1 -ms -O2 libgcc2.i
__muldi3
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> <visibility> <build_ssa_passes> <chkp_passes> <opt_local_passes> <free-inline-summary> <emutls> <whole-program>
<profile_estimate> <icf> <devirt> <cp> <inline> <pure-const> <static-var> <single-use> <comdats>Assembling functions:
__muldi3
libgcc2.i: In function '__muldi3':
libgcc2.i:5:1: internal compiler error: in as_a, at is-a.h:192
}
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 rtx objects. That's something we'll have to fix as the
type safety work moves forward, assuming we continue towards the goal of
totally separating rtx and rtx_insn objects.
Returning to the code in h8300.c, we have "F" which assumes its argument
is an rtx_insn. We should never be calling "F" will anything other than
an rtx_insn argument. The calls from "Fpa" are the only violators of
that invariant.
Given that the vectors inside the PARALLEL will always be rtx objects
and that we always want to set RTX_FRAME_RELATED on those objects, it
seems that we could just replace the call to "F" in "Fpa" with
RTX_FRAME_RELATED_P (XVECEXP (par, 0, i)) = 1;
That simplifies the code and removes a bogus as_a cast.
Can you try that and report back to me?
Thanks,
Jeff
ps. Someone should have chastised DJ for using such poor function names
as "F" and "Fpa". If you wanted to clean that up and use more
descriptive function names, that would be appreciated as a separate patch.