This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] testsuite: endianness in gnu_vector.exp
- From: jose dot marchesi at oracle dot com (Jose E. Marchesi)
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 07 Oct 2013 21:36:05 +0200
- Subject: Re: [PATCH] testsuite: endianness in gnu_vector.exp
- Authentication-results: sourceware.org; auth=none
- References: <87bo31m9r7 dot fsf at oracle dot com> <87y564kj5i dot fsf at fleche dot redhat dot com>
Jose> Small patch making gnu_vector.exp to work properly in big-endian
Jose> machines.
The patch looks reasonable enough, but is this how casting to vector
types works? That is, is the gdb result here consistent with what gcc
does? This isn't clear from the existing test.
Well, this is all I can find on the gcc manual on casting vectors:
"It is possible to cast from one vector type to another, provided they
are of the same size (in fact, you can also cast vectors to and from
other datatypes of the same size)."
No explicit mention to the endianness issue. But then the behavior of
gcc indicates that it stores the elements of the vectors in memory
ordering: the following program generates different results in x86_64 (2
0) and SPARC/BE (0 2).
typedef int __attribute__((vector_size(8))) vector_t;
void
main()
{
long i = 2;
vector_t v = (vector_t) i;
printf ("%d %d\n", v[0], v[1]);
}
So it looks like the test is now consistent with what gcc does...