https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66126
Bug ID: 66126
Summary: 2-float SSE vector with vector_size(8) is passed
incorrectly to functions on x86
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tanel.kriik at outlook dot com
Target Milestone: ---
Created attachment 35532
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35532&action=edit
Preprocessed source code of the original program
GCC version: 4.8.4
System type: i386-unknown-openbsd5.7
Configured with: /usr/obj/ports/gcc-4.8.4/gcc-4.8.4/configure --enable-libgcj
--without-jar --verbose --program-transform-name='s,^,e,' --disable-nls
--with-system-zlib --disable-libmudflap --disable-libgomp --disable-tls
--with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-gnu-ld --with-gnu-as
--enable-threads=posix --enable-wchar_t --with-gmp=/usr/local
--enable-languages=c,c++,fortran,objc,java,ada --disable-libstdcxx-pch
--enable-cpp --enable-shared --prefix=/usr/local --sysconfdir=/etc
--mandir=/usr/local/man --infodir=/usr/local/info --localstatedir=/var
--disable-silent-rules --disable-gtk-doc
Defining a 2D float vector with vector_size(8) produces a type that doesn't
seem to be passed correctly to functions.
#include <stdio.h>
typedef float vec2f __attribute__ ((vector_size(8)));
static void vec2f_print(vec2f v)
{
printf("%f %f\n", v[0], v[1]);
}
int main(void)
{
vec2f v = {1, 3};
vec2f_print(v);
printf("%f %f\n", v[0], v[1]);
return 0;
}
Compiling the code above with 'gcc -msse' and running it produces the following
output:
-nan -nan
1.000000 3.000000
The first line should be same as the second line because the vector is just
passed to a function that prints the first and second float in the vector while
the second output line is the result of printing the 2 floats directly without
a function call. If I apply optimization when compiling, the result is correct,
probably due to eliminating the simple function call.
I get similar behaviour on my 64-bit Ubuntu machine when the same program is
compiled in 32-bit mode (-m32).
This bug doesn't appear on x86-64, otherwise.
