[Bug c/13132] New: long-double code leads to unresolved reference to __trunctfxf2

[Bug c/13132] New: long-double code leads to unresolved reference to __trunctfxf2

[davidm at hpl dot hp dot com]

Compiling the test-program below results in an undefined reference to __tructfxf2:

$ gcc -v
Reading specs from /opt/gcc-pre3.4/lib/gcc/ia64-hp-linux/3.4/specs
Configured with:  : (reconfigured)  : (reconfigured)  : (reconfigured) 
Thread model: posix
gcc version 3.4 20031119 (experimental)
$ cat t.c
long double f (int g)
{
        union {
                int g;
                long double d;
        } u;
        u.g = g;
        return u.d;
}

int main (int argc, char **argv)
{
        return f(argc);
}
$ gcc -O /tmp/t.c
/tmp/cc6b8Pzg.o(.text+0x32): In function `f':
: undefined reference to `__trunctfxf2'
collect2: ld returned 1 exit status

It doesn't matter whether -O or -O2 is specified.  Dropping -O makes the problem
disppear, however.

I discovered this problem while trying to compile libc with gcc-pre3.4.

-- 
           Summary: long-double code leads to unresolved reference to
                    __trunctfxf2
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: davidm at hpl dot hp dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: ia64-hp-linux
  GCC host triplet: ia64-hp-linux
GCC target triplet: ia64-hp-linux


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2003-11-19 22:15 -------
Zack do you know why this would happen?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zack at codesourcery dot com
          Component|c                           |target


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

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

[wilson at specifixinc dot com]

------- 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

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

[zack at codesourcery dot com]

------- Additional Comments From zack at codesourcery dot com  2003-12-05 16:54 -------
Subject: Re:  long-double code leads to unresolved
 reference to __trunctfxf2


Thanks for fixing this.

zw


-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2003-12-06 09:08 -------
Jim confirmed this.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |pessimizes-code, wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2003-12-06 09:08:19
               date|                            |
   Target Milestone|---                         |3.4


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

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

[wilson at gcc dot gnu dot org]

------- Additional Comments From wilson at gcc dot gnu dot org  2003-12-08 08:40 -------
The initial patch caused a testsuite failure.  The SCALAR_INT_MODE_P test needs
to be against tmode not mode.  That patch passed the testsuite.

-- 


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

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

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2003-12-08 22:39 -------
Subject: Bug 13132

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	wilson@gcc.gnu.org	2003-12-08 22:39:53

Modified files:
	gcc            : ChangeLog expmed.c 

Log message:
	Fix IA-64 glibc ICE
	PR target/13132
	* expmed.c (extract_bit_field): Only call mode_for_size for scalar
	integer modes.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.1964&r2=2.1965
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expmed.c.diff?cvsroot=gcc&r1=1.146&r2=1.147



-- 


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

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

[wilson at gcc dot gnu dot org]

------- Additional Comments From wilson at gcc dot gnu dot org  2003-12-09 00:48 -------
Mine.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |wilson at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED


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

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

[wilson at gcc dot gnu dot org]

------- Additional Comments From wilson at gcc dot gnu dot org  2003-12-09 00:55 -------
The voltile mem problem seems to be an IA-64 specific issue.  The IA-64 port
calls gen_mem_addressof during reload, to fix XFmode GR/FR moves.  It passes no
decl when it does this.  In all other cases, we have a decl, and the flag bits
are set by the set_mem_attributes call.  Nowadays, REGs can have a decl in the
reg attributes field, but I am uncertain of what will happen if I try to use it.
 I also doubt that the decl will always be there.  So the simplest fix is to
just clear the fields manually.  Since this happens in reload, taking the same
action as alter_reg seems to be correct.  Here is an as yet untested patch.

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

        * function.c (gen_mem_addressof): When no decl, explicitly clear flag
        bits.

Index: function.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/function.c,v
retrieving revision 1.471
diff -p -r1.471 function.c
*** function.c  1 Dec 2003 13:07:12 -0000       1.471
--- function.c  9 Dec 2003 00:46:34 -0000
*************** gen_mem_addressof (rtx reg, tree decl, i
*** 2851,2857 ****
        fixup_var_refs (reg, GET_MODE (reg), TREE_UNSIGNED (type), reg, 0);
      }
    else if (rescan)
!     fixup_var_refs (reg, GET_MODE (reg), 0, reg, 0);

    return reg;
  }
--- 2851,2867 ----
        fixup_var_refs (reg, GET_MODE (reg), TREE_UNSIGNED (type), reg, 0);
      }
    else if (rescan)
!     {
!       /* This can only happen during reload.  Clear the same flag bits as
!        reload.  */
!       MEM_VOLATILE_P (reg) = 0;
!       RTX_UNCHANGING_P (reg) = 0;
!       MEM_IN_STRUCT_P (reg) = 0;
!       MEM_SCALAR_P (reg) = 0;
!       MEM_ATTRS (reg) = 0;
!
!       fixup_var_refs (reg, GET_MODE (reg), 0, reg, 0);
!     }

    return reg;
  }


-- 


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

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

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2003-12-11 19:04 -------
Subject: Bug 13132

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	wilson@gcc.gnu.org	2003-12-11 19:04:08

Modified files:
	gcc            : ChangeLog function.c 

Log message:
	Fix for problem with unnecessary volatile mems.
	PR target/13132
	* function.c (gen_mem_addressof): When no decl, explicitly clear flag
	bits.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.1980&r2=2.1981
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcc&r1=1.475&r2=1.476



-- 


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

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

[wilson at gcc dot gnu dot org]

------- Additional Comments From wilson at gcc dot gnu dot org  2003-12-11 19:11 -------
I have checked in patches to fix both problems exposed by this testcase.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

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

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-02-05 11:43 -------
Subject: Bug 13132

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	hammer-3_3-branch
Changes by:	amodra@gcc.gnu.org	2004-02-05 11:43:19

Modified files:
	gcc            : ChangeLog.hammer expr.c expmed.c 

Log message:
	Backport from mainline
	2004-01-26  Fariborz Jahanian <fjahanian@apple.com>
	PR middle-end/13779
	* expr.c (emit_group_load): split constant
	correctly into register components of PARALLEL insn.
	
	2003-12-08  James E Wilson  <wilson@specifixinc.com>
	PR target/13132
	* expmed.c (extract_bit_field): Only call mode_for_size for scalar
	integer modes.
	
	2003-04-29  Aldy Hernandez  <aldyh@redhat.com>
	* expr.c (emit_group_load): Dump parallels of simd types to
	memory.
	
	2003-04-21  Olivier Hainque  <hainque@act-europe.fr>
	* expmed.c (extract_bit_field): Reverse operands of && condition to
	prevent a potential division by zero in the previously first branch.
	
	2003-04-18  Richard Kenner  <kenner@vlsi1.ultra.nyu.edu>
	* expmed.c (mask_rtx): Avoid undefined shifts for BITSIZE of 0.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.hammer.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.1.2.307&r2=1.1.2.308
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.492.2.25&r2=1.492.2.26
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expmed.c.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.125.2.4&r2=1.125.2.5



-- 


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