[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-17 
12:23 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-17 
08:54 ---
Subject: Bug 17603

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-17 08:54:02

Modified files:
gcc: ChangeLog 
gcc/config/i386: i386.c 

Log message:
2004-12-17  Jan Beulich  <[EMAIL PROTECTED]>

PR target/17603
* config/i386/i386.c (enum x86_64_reg_class): Define
X86_64_COMPLEX_X87_CLASS.
(x86_64_reg_class_names): Add name for X86_64_COMPLEX_X87_CLASS.
(merge_classes): Handle X86_64_COMPLEX_X87_CLASS.
(classify_argument): XCmode is X86_64_COMPLEX_X87_CLASS.
(examine_argument): X86_64_COMPLEX_X87_CLASS requires two
registers when dealing with a return value.
(construct_container): Handle X86_64_COMPLEX_X87_CLASS.
Eliminate impossible case of two X87/X87UP pairs (this now is
being expressed by a single COMPLEX_X87).
(x86_libcall_value): XCmode gets returned in st0/st1.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6866&r2=2.6867
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.754&r2=1.755



-- 


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

[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-16 
16:33 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results

[jbeulich at novell dot com]

--- Additional Comments From jbeulich at novell dot com  2004-12-16 15:46 
---
Patch for the x86-64 long double complex part submitted.

-- 


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

[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results

[jbeulich at novell dot com]

--- Additional Comments From jbeulich at novell dot com  2004-12-16 12:59 
---
This happens when the ABI is (was) imprecise. Earlier versions did not special
case long double complex, but the current version does. Hence I have a patch
ready that partly reverses the original change (actually, implements the
original behavior for this type in a form slightly closer matching the ABI
definition); expecting to submit this later today or tomorrow (currently
building/testing).

As to the same(?) problem observed with float complex: I doubt the mentioned
patch causes this, since behavior for that type wasn't modified by it.

-- 


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

[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-16 
01:13 ---
The patch which caused it was 
.

But if I read the patch, this sounds like GCC before 4.0.0 was not implementing 
the ABI right.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-16 
01:09 ---
This patch caused it: 
 
+2004-07-09  Jan Beulich  <[EMAIL PROTECTED]> 
+ 
+   * config/i386/i386.c (classify_argument): Treat V1xx modes the same as 
+   their base modes. CTImode, TCmode, and XCmode must be passed in 
memory. 
+   TFmode (__float128) must be is an SSE/SSEUP pair. V2SImode, V4HImode, 
+   and V8QI are class SSE. All sufficiently small remaining vector modes 
+   must be passed in one or two integer registers. 
+   (ix86_libcall_value): TFmode must be returned in xmm0, XCmode must be 
+   returned in memory. 
+   (bdesc_2arg, ix86_init_mmx_sse_builtins): __builtin_ia32_pmuludq and 
+   __builtin_ia32_pmuludq128 have non-uniform argument and return types 
+   and must thus be handled explicitly. 
+   * config/i386/i386.md (*movdi_1_rex64): Add cases for moving between 
+   MMX and XMM regs. 
+   (movv8qi_internal, movv4hi_internal, movv2si_internal, 
+   movv2sf_internal): Permit moving between MMX and XMM registers (since 
+   MMX areguments and return values are passed in XMM registers). 
+   (sse2_umulsidi3): Correct type and mode. 
 

-- 
   What|Removed |Added

 CC||jbeulich at novell dot com


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

[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-16 
01:05 ---
Narrowed it down to "2004-07-10 00:00" and "2004-07-10 01:00". 

-- 


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

[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-12-15 23:51 
---
Thanks Steven. This bus is really a show stopper, in my opinion.

-- 


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

[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-15 
22:07 ---
The bug appears between "2004-07-10 00:00" and "2004-07-10 12:00".  I hope 
to reduce it a bit further to pinpoint the offending patch. 

-- 


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

[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results

[roger at eyesopen dot com]

--- Additional Comments From roger at eyesopen dot com  2004-12-05 21:24 
---
There does appear to be some form of ABI change on x86_64.  When compiling with
gcc-3.4.3 the results of cpowl are assumed to be returned on the x87 stack, but
when compiling with 4.0.0 (20041205 experimental) the generated code assumes 
that
the floating point results are returned in memory!!  I suspect that an internal
change in the representation of complex types, has broken platforms with special
parameter passing/returning conventions for complex types.


-- 


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

[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-12-05 21:02 
---
> Looking at:
> 
> it looks likes it is only for -m32 case.

Look better: is the other way 'round: -m32 is ok, 64-bit is broken (I'm 100% 
sure
because often I build --disable-multilib and the failure is always there :(



-- 


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

[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-05 
20:42 ---
Looking at:

it looks likes it is only for -m32 case.

I think this is a target problem now.
As ppc64 is fixed at least according to 
.

-- 
   What|Removed |Added

  Component|middle-end  |target


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