Bug 237067 - _mm_cmpord_ss compiles as _mm_cmpunord_ss
Summary: _mm_cmpord_ss compiles as _mm_cmpunord_ss
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc4
Version: 6
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-04-19 08:25 UTC by Ali Erol
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-04-20 21:30:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
The output of g++ -S compord.C (1.34 KB, application/octet-stream)
2007-04-19 08:25 UTC, Ali Erol
no flags Details

Description Ali Erol 2007-04-19 08:25:03 UTC
gcc version: 4.1.1 fedora core 6

The _mm_cmpord_ss intrinsic is not compiled correctly. It generates CMPUNORDSS
instread of CMPORDSS  in assembly.

The following code 

#include <xmmintrin.h>

int main() {
 __m128 d1 = _mm_cmpord_ss(_mm_set_ss(2.1f), _mm_set_ss(3.2f));
}

when compiled with "g++ -S"  generates the assembly code in the attachment,
which does not contain any cmpordss instruction. Instead, in line 30 there is
a "cmpunordss	%xmm0, %xmm2"  instruction. In fact this code should have been 
"cmpordss	%xmm0, %xmm2".

We checked the source code of gcc 4.1.2 and guessed that changing the
config/i386/i386.c line 14036 from 

....IX86_BUILTIN_CMPORDSS, UNORDERED, 0}

to 

....IX86_BUILTIN_CMPORDSS, ORDERED, 0}

could be a part of the fix to the problem.

Comment 1 Ali Erol 2007-04-19 08:25:03 UTC
Created attachment 152984 [details]
The output of g++ -S compord.C

Comment 2 Ali Erol 2007-04-19 08:29:22 UTC
gcc version 3.4.4 compiles the sample code correctly. The instruction 
"cmpordss %xmm0, %xmm2" was generated correctly.


Comment 3 Jakub Jelinek 2007-04-20 21:30:39 UTC
Should be fixed in gcc-4.1.2-10 (and upstream 4.1/4.2/trunk).


Note You need to log in before you can comment on or make changes to this bug.