[Bug target/7285] [ia64] unsigned-to-floating conversion not spec conformant

[Bug target/7285] [ia64] unsigned-to-floating conversion not spec conformant

[zack at gcc dot gnu dot org]

------- Additional Comments From zack at gcc dot gnu dot org  2004-01-28 21:41 -------
I'll take responsibility for this one.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
   Last reconfirmed|0000-00-00 00:00:00         |2004-01-28 21:41:27
               date|                            |


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

[Bug target/7285] [ia64] unsigned-to-floating conversion not spec conformant

[zack at gcc dot gnu dot org]

------- Additional Comments From zack at gcc dot gnu dot org  2004-01-28 21:41 -------
bleh

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |zack at gcc dot gnu dot org
                   |dot org                     |


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

[Bug target/7285] [ia64] unsigned-to-floating conversion not spec conformant

[zack at gcc dot gnu dot org]

------- Additional Comments From zack at gcc dot gnu dot org  2004-03-18 00:30 -------
HP's acc compiler produces the following code for test:

 4000920:       0a 30 80 00 e1 18       [MMI]       setf.sig f6=r32;;
 4000926:       00 00 00 02 00 00                   nop.m 0x0
 400092c:       00 00 04 00                         nop.i 0x0
 4000930:       1d 00 00 00 01 00       [MFB]       nop.m 0x0
 4000936:       80 00 18 02 40 80                   fnorm.s0 f8=f6
 400093c:       08 00 84 00                         br.ret.sptk.many b0;;

It appears to me from this that acc should exhibit the same problem (i.e.
raising inappropriate exceptions) but I cannot reproduce the effect -- calling
this function does not cause delivery of hardware traps or change bits in
ar.fpsr.  Please clarify how, exactly, one should reproduce the problem.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING


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

[Bug target/7285] [ia64] unsigned-to-floating conversion not spec conformant

[zack at gcc dot gnu dot org]

------- Additional Comments From zack at gcc dot gnu dot org  2004-03-18 00:36 -------
I should add that GCC 3.4 produces code which is identical modulo bundle packing:

   0:   02 30 80 00 e1 18       [MII]       setf.sig f6=r32
   6:   00 00 00 02 00 00                   nop.i 0x0;;
   c:   00 00 04 00                         nop.i 0x0
  10:   1d 00 00 00 01 00       [MFB]       nop.m 0x0
  16:   80 00 18 02 40 80                   fnorm.s0 f8=f6
  1c:   08 00 84 00                         br.ret.sptk.many b0;;


-- 


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

[Bug target/7285] [ia64] unsigned-to-floating conversion not spec conformant

[jbeulich at novell dot com]

------- Additional Comments From jbeulich at novell dot com  2004-03-18 08:08 -------
Just to clarify: I saw the problem on an OS project that is no longer alive
(hence the cross compiler), and I don't have access to an IA64 box that would
permit me installing Linux on it. Thus I can't at present redo the full analysis
(but of course, you should almost always see a denormal exception, since
setf.sig's output, unless having full 64 significant bits, is always denormal).
Nevertheless, the current way of generating code is not in line with fcvt.xf,
and is not in line with the Intel (on Windows - again, I don't have a suitable
Linux system at hand) compiler (I'm not sure why the HP compiler would serve as
a [better] reference, or why it not behaving consistently would be a reason for
gcc to also fail to do so).

Actually, looking at this again, I believe the behavior should even further be
corrected (even in Intel's compiler): When the result is not 'long double', it
should first normalize the setf.sig output to full precision using sf1, then
normalize it to target precision using sf0:

     setf.sig f6 = r32;;
     fcvt.xuf.sf1 f7 = f6;;
     fnorm.[sd] f8 = f7

thus hiding the denormal exception, but raising a potential inexcat one. I'll
contact Intel on that, too. The normalizing-to-target-precision appears to be
done correctly in both (.xf and .xuf) cases in gcc, so it is really the
intermediate normalize-to-full-precision step that is missing for other than
'long double' results, and only for 'long double' results the entire
normalization would need to be replaced by the one using sf1.

-- 


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

[Bug target/7285] [ia64] unsigned-to-floating conversion not spec conformant

[zack at codesourcery dot com]

------- Additional Comments From zack at codesourcery dot com  2004-03-18 10:08 -------
Subject: Re:  [ia64] unsigned-to-floating conversion not
 spec conformant


Thanks for the additional detail, but I am still not seeing exactly
what should happen.  (For the record, I used the HP compiler as a
reference because it's the non-GCC compiler for IA64 that I have
convenient access to; I wasn't expecting its output necessarily to be
correct.)

This code

static __float80 floatunsdixf(unsigned long long x) { return x; }

void main(void)
{ 
  __float80 v = floatunsdixf(12);
  printf("%qf\n", v); 
  return 0; 
}

does _not_ trigger a denormal exception when executed on ia64-hpux.
(On this target "long double" is a software-emulated 128-bit type, you
have to use __float80 to get IEEE extended.)  I determined this by
running the program under GDB, stepi-ing through floatunsdixf(), and
printing the value of ar40 (= ar.fpsr) at each step.  What gives?  Did
I pick a bad test constant or something?

zw


-- 


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

[Bug target/7285] [ia64] unsigned-to-floating conversion not spec conformant

[jbeulich at novell dot com]

------- Additional Comments From jbeulich at novell dot com  2004-03-18 10:59 -------
Hmm, that's a little strange. While certainly the denormal exception would be
masked in most cases, did you make sure the denormal flag wasn't already set in
sf0? And even if so, are you sure the software assist fault handler didn't get
into the picture here? I am certain I saw the flag get set when I was initially
observing/researching this (but then again this was on an Itanium, you're most
likely using an Itanium2, and even though there is no statement about different
behavior of the two in this respect - who knows)...

-- 


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

[Bug target/7285] [ia64] unsigned-to-floating conversion not spec conformant

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-25 23:43 -------
Is there any news on this one?

-- 


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

[Bug target/7285] [ia64] unsigned-to-floating conversion not spec conformant

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-25 16:36 -------
Closing as there have no feedback for 6 months.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


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

[Bug target/7285] [ia64] unsigned-to-floating conversion not spec conformant

[jbeulich at novell dot com]

------- Additional Comments From jbeulich at novell dot com  2004-12-17 14:28 -------
Now that I have an Itanium2 system to test with, I can confirm that the problem
still exists in 3.4.3, and looking at the delta to 4.0.0's ia64.md there is no
reason to believe the problem would have been fixed there.
fnorm.d.s0 (as example, I tested with double) does set ar.fpsr.sf0.d, and thus
would raise an exception if that was unmasked, and even if it's masked may
confuse subsequent code in making it incorrectly assume some floating point
operation happened on denormal input(s).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


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

[Bug target/7285] [ia64] unsigned-to-floating conversion not spec conformant

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-05 02:13 -------
Unassigning from Zack since he is now gone from GCC development.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|zack at codesourcery dot com|unassigned at gcc dot gnu
                   |                            |dot org
             Status|REOPENED                    |NEW


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

[Bug target/7285] [ia64] unsigned-to-floating conversion not spec conformant

[ehrhardt@mathematik.uni-ulm.de]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


ehrhardt@mathematik.uni-ulm.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW


------- Additional Comments From ehrhardt@mathematik.uni-ulm.de  2003-05-22 11:39 -------
Feedback received. Submitter says this is still present in 3.3.




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.