Re: [PATCH] config/h8300/h8300.c: Regress part of the original commit for fixing issue

[Jeff Law <law at redhat dot com>]

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.