On 07/06/13 04:00, Alan Modra wrote:
> force_const_mem() isn't supposed to handle VOIDmode or BLKmode, so the
> check for VOIDmode when aligning is needless. If we ever did get one
> of these modes in a constant pool, this
>
> pool->offset += GET_MODE_SIZE (mode);
Hi Alan,
the assertion is triggered on S/390 during bootstrap.
The S/390 movmem_short expander emits the following insn:
(insn 793 3147 795 93 (parallel [
(set (mem:BLK (reg/f:SI 509 [ gi_filename ]) [0 A8])
(mem:BLK (reg/f:SI 510 [ gcov_prefix ]) [0 A8]))
(use (reg:SI 511 [ prefix_length ]))
(use (const:BLK (unspec:BLK [
(const_int 0 [0])
] UNSPEC_INSN)))
(clobber (reg:SI 1288))
])
For machines without larl (load address relative long) the RTX:
(const:BLK (unspec:BLK [
(const_int 0 [0])
] UNSPEC_INSN))
is supposed to be pushed into the literal pool. The expression represents the
target of the execute
instruction. It doesn't matter that the literal pool offset calculation doesn't
work with this RTX
the backend does this in machine dependent reorg anyway on its own.
Picking a different mode wouldn't be correct for our purposes since the size
depends on the pattern
containing the expression.
So from a S/390 perspective I think the !BLKmode assertion should be removed.
Bye,
-Andreas-
>
> won't add to the pool size, and output_constant_pool_2() will hit a
> gcc_unreachable(). Bootstrapped etc. powerpc64-linux.
>
> * varasm.c (force_const_mem): Assert mode is not VOID or BLK.
>
> Index: gcc/varasm.c
> ===================================================================
> --- gcc/varasm.c (revision 199718)
> +++ gcc/varasm.c (working copy)
> @@ -3567,7 +3575,8 @@
> *slot = desc;
>
> /* Align the location counter as required by EXP's data type. */
> - align = GET_MODE_ALIGNMENT (mode == VOIDmode ? word_mode : mode);
> + gcc_checking_assert (mode != VOIDmode && mode != BLKmode);
> + align = GET_MODE_ALIGNMENT (mode);
> #ifdef CONSTANT_ALIGNMENT
> {
> tree type = lang_hooks.types.type_for_mode (mode, 0);
>
