[PATCH] Using RTL modes without front-end types.

[Roger Sayle <roger at eyesopen dot com>]

The following patch fixes a bizarre interaction between GCC's
front-end languages and back-end machine descriptions.

Mainline gcj currently generates an ICE when trying to call
java.lang.Math.log on x86 when -ffast-math is specified.  Its
currently not possible to customize command line options in
libjava's testsuite, so this problem was only uncovered by
manual testing.  [Andrew Haley and I are looking into fixing
this].

The sequence of events is that i386.md quite reasonably calls
emit_move_insn on an intermediate XFmode constant.

>  operands[2] = gen_reg_rtx (XFmode);
>  temp = standard_80387_constant_rtx (4); /* fldln2 */
>  emit_move_insn (operands[2], temp);

This eventually reaches varasm.c's "force_const_mem" that tries
to place the constant in memory.  Unfortunately, it then trips
over the following (CONSTANT_ALIGNMENT is defined).

> align = GET_MODE_ALIGNMENT (mode == VOIDmode ? word_mode : mode);
> #ifdef CONSTANT_ALIGNMENT
>   align = CONSTANT_ALIGNMENT (make_tree ((*lang_hooks.types.type_for_mode)
>                                          (mode, 0), x), align);
> #endif

Which creates no end of problems, because the Java front-end doesn't
have a type that corresponds to x86's XFmode, so the type_for_mode
returns NULL_TREE, and we rapidly go down hill from there.

This seems an unexpected coupling whereby back-ends are unable to
use MODEs that don't have a corresponding type in the host language's
front-end.  The example above is i386.md-vs-gcj specific, but I
suspect that we'll also have trouble with other front-ends, vector
modes, etc...

In the case under investigation, the x86 has a special purpose
instructon for loading this XFmode constant, hence the value is
typically never actually read/stored in memory, so in this particular
case the alignment isn't relevant anyway.


The proposed patch below decouples the front and backends, by
using the mode's MODE_ALIGNMENT when the front-end has nothing
to say about the alignment of a particular mode.  Alternative
fixes would be to document CONSTANT_ALIGNMENT as allowing
NULL exp operands, and patching the back-ends to honor this,
or requiring languages to always provide a tree type even
for non-native modes.  Neither alternative seems appropriate.


The following patch has been tested on i686-pc-linux-gnu with
a full "make bootstrap", all languages except treelang, and
regression tested with a top-level "make -k check" with no
new failures.  I'll provide a test-case in a follow-up patch
to support custom command line options in libjava/testsuite.

Ok for mainline?


2003-05-31  Roger Sayle  <roger@eyesopen.com>

	* varasm.c (force_const_mem): Handle alignment of constants not
	representable as a type in the front-end language.


Index: varasm.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/varasm.c,v
retrieving revision 1.356
diff -c -3 -p -r1.356 varasm.c
*** varasm.c	17 May 2003 01:40:41 -0000	1.356
--- varasm.c	31 May 2003 15:43:11 -0000
*************** force_const_mem (mode, x)
*** 3061,3068 ****
    /* Align the location counter as required by EXP's data type.  */
    align = GET_MODE_ALIGNMENT (mode == VOIDmode ? word_mode : mode);
  #ifdef CONSTANT_ALIGNMENT
!   align = CONSTANT_ALIGNMENT (make_tree ((*lang_hooks.types.type_for_mode)
! 					 (mode, 0), x), align);
  #endif

    pool_offset += (align / BITS_PER_UNIT) - 1;
--- 3061,3071 ----
    /* Align the location counter as required by EXP's data type.  */
    align = GET_MODE_ALIGNMENT (mode == VOIDmode ? word_mode : mode);
  #ifdef CONSTANT_ALIGNMENT
!   {
!     tree type = (*lang_hooks.types.type_for_mode) (mode, 0);
!     if (type != NULL_TREE)
!       align = CONSTANT_ALIGNMENT (make_tree (type, x), align);
!   }
  #endif

    pool_offset += (align / BITS_PER_UNIT) - 1;


Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833