[Bug target/13132] long-double code leads to unresolved reference to __trunctfxf2

["wilson at specifixinc dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From wilson at specifixinc dot com  2003-12-05 08:33 -------
Subject: Re:  New: long-double code leads to unresolved reference
 to __trunctfxf2

davidm at hpl dot hp dot com wrote:
> Compiling the test-program below results in an undefined reference to __tructfxf2:

See attached patch and explanation.  I will try testing this tomorrow.

While looking at this, I noticed that we are generating volatile mems 
for this testcase for no apparent reason.  The bug in is 
gen_mem_addressof which does
	PUT_CODE (reg, MEM)
If the input happens to be a REG_USERVAR_P, then the output is 
MEM_VOLATILE_P.  This code definitely needs some thought.  We have to 
clear at least MEM_VOLATILE_P.  We probably have to clear all of the 
MEM_*_P flags.
We are getting an incorrect TFmode to XFmode conversion on ia64-linux.  The
problem here is that we have mode == XFmode, and there is a call to
	mode_for_size (128, MODE_FLOAT, 0)
which returns TFmode.  This is because mode_for_size despite its name actually
uses mode precisions not mode sizes, and XFmode has a precision of 96 bits,
so it thinks we need TFmode.  There are no TFmode to XFmode conversions and
the resulting code fails to link.

There is no mode_for_size equivalent that uses mode sizes instead of mode
precisions, but we don't need one.  The code that is using mode_for_size is
using subregs and simple conversions, but that only works for integers.  The
code has already been modified to exclude vector modes.  We can fix the FP
problem by excluding all modes except scalar integers.

This patch also fixes one place that uses mode_for_size that should be using
mode1.

2003-12-05  James E Wilson  <wilson@specifixinc.com>

	PR target/13132
	* expmed.c (extract_bit_field): Only call mode_for_size for scalar
	integer modes.

Index: expmed.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/expmed.c,v
retrieving revision 1.146
diff -p -r1.146 expmed.c
*** expmed.c	11 Nov 2003 20:54:38 -0000	1.146
--- expmed.c	5 Dec 2003 08:08:57 -0000
*************** extract_bit_field (rtx str_rtx, unsigned
*** 1079,1091 ****
       If that's wrong, the solution is to test for it and set TARGET to 0
       if needed.  */
  
!   mode1  = (VECTOR_MODE_P (tmode)
! 	    ? mode
! 	    : mode_for_size (bitsize, GET_MODE_CLASS (tmode), 0));
  
    if (((bitsize >= BITS_PER_WORD && bitsize == GET_MODE_BITSIZE (mode)
  	&& bitpos % BITS_PER_WORD == 0)
!        || (mode_for_size (bitsize, GET_MODE_CLASS (tmode), 0) != BLKmode
  	   /* ??? The big endian test here is wrong.  This is correct
  	      if the value is in a register, and if mode_for_size is not
  	      the same mode as op0.  This causes us to get unnecessarily
--- 1079,1096 ----
       If that's wrong, the solution is to test for it and set TARGET to 0
       if needed.  */
  
!   /* Only scalar integer modes can be converted via subregs.  There is an
!      additional problem for FP modes here in that they can have a precision
!      which is different from the size.  mode_for_size uses precision, but
!      we want a mode based on the size, so we must avoid calling it for FP
!      modes.  */
!   mode1  = (SCALAR_INT_MODE_P (mode)
! 	    ? mode_for_size (bitsize, GET_MODE_CLASS (tmode), 0)
! 	    : mode);
  
    if (((bitsize >= BITS_PER_WORD && bitsize == GET_MODE_BITSIZE (mode)
  	&& bitpos % BITS_PER_WORD == 0)
!        || (mode1 != BLKmode
  	   /* ??? The big endian test here is wrong.  This is correct
  	      if the value is in a register, and if mode_for_size is not
  	      the same mode as op0.  This causes us to get unnecessarily


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13132