From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-106088-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 20461 invoked by alias); 7 Oct 2013 19:34:21 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Received: (qmail 20448 invoked by uid 89); 7 Oct 2013 19:34:20 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS,UNPARSEABLE_RELAY autolearn=ham version=3.3.2
X-HELO: aserp1040.oracle.com
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 07 Oct 2013 19:34:20 +0000
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])	by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r97JYG1L013408	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);	Mon, 7 Oct 2013 19:34:17 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85])	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r97JYFpB025749	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);	Mon, 7 Oct 2013 19:34:16 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])	by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r97JYFso025731;	Mon, 7 Oct 2013 19:34:15 GMT
Received: from termi.oracle.com (/10.175.34.9)	by default (Oracle Beehive Gateway v4.0)	with ESMTP ; Mon, 07 Oct 2013 12:34:14 -0700
From: jose.marchesi@oracle.com (Jose E. Marchesi)
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] testsuite: endianness in gnu_vector.exp
References: <87bo31m9r7.fsf@oracle.com> <87y564kj5i.fsf@fleche.redhat.com>
Date: Mon, 07 Oct 2013 19:34:00 -0000
In-Reply-To: <87y564kj5i.fsf@fleche.redhat.com> (Tom Tromey's message of "Mon,	07 Oct 2013 12:52:57 -0600")
Message-ID: <87txgslvq2.fsf@oracle.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-IsSubscribed: yes
X-SW-Source: 2013-10/txt/msg00201.txt.bz2


    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...