This is the mail archive of the
mailing list for the GCC project.
Re: store_bit_field, CONCATs and subregs
- From: Eric Botcazou <ebotcazou at libertysurf dot fr>
- To: Richard Sandiford <rsandifo at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 7 Dec 2004 22:48:34 +0100
- Subject: Re: store_bit_field, CONCATs and subregs
- References: <email@example.com>
> In the testcases, store_bit_field is trying to store a CHImode CONCAT to
> an unaligned address. It first tries to mode-pun the value to SImode:
> /* If VALUE is a floating-point mode, access it as an integer of the
> corresponding size. This can occur on a machine with 64 bit registers
> that uses SFmode for float. This can also occur for unaligned float
> structure fields. */
> orig_value = value;
> if (GET_MODE_CLASS (GET_MODE (value)) != MODE_INT
> && GET_MODE_CLASS (GET_MODE (value)) != MODE_PARTIAL_INT)
> value = gen_lowpart ((GET_MODE (value) == VOIDmode
> ? word_mode : int_mode_for_mode (GET_MODE (value))),
> and the problem is with the rtx that gen_lowpart returns.
> Things first go wrong because:
> simplify_subreg (SImode, (concat:CHImode X Y), CHImode, 0)
> returns (subreg:SI X 0), i.e. a paradoxical SImode subreg of the
> real part. This is caused by the CONCAT case picking either the
> real or imaginary part without checking whether the requested subreg
> is entirely contained within it.
Same on the SPARC.
> These two hunks stop us generating the invalid subreg, but gen_lowpart
> has nothing to fall back on, so the call quoted above now fails. The
> right fix for that depends on where we're headed. Is this something
> that gen_lowpart_general should handle, or should store_bit_field
> not be asking for this lowpart in the first place?
> The third hunk adds a case to gen_lowpart_general. It creates an integer
> pseudo of the lowpart mode, takes a paradoxical complex subreg of it,
> then moves the CONCAT into that subreg. This works correctly thanks
> to the new emit_move_insn handling.
And this fixes all the remaining struct-layout-1 failures, both on SPARC
32-bit and SPARC 64-bit! Congratulations. :-)