On 31 August 2012 17:59, Richard Henderson r...@redhat.com wrote:
On 2012-08-31 07:25, Christophe Lyon wrote:
+ offset = gen_rtx_CONST_INT (VOIDmode, location);
Never call gen_rtx_CONST_INT directly. Use GEN_INT.
Here is an updated patch with that small change.
For the record, there are
On 09/03/12 09:59, Christophe Lyon wrote:
On 31 August 2012 17:59, Richard Henderson r...@redhat.com wrote:
On 2012-08-31 07:25, Christophe Lyon wrote:
+ offset = gen_rtx_CONST_INT (VOIDmode, location);
Never call gen_rtx_CONST_INT directly. Use GEN_INT.
Here is an updated patch with
On 24 August 2012 10:54, Christophe Lyon christophe.l...@linaro.org wrote:
On 24 August 2012 10:40, Richard Earnshaw rearn...@arm.com wrote:
Has this been tested for big-endian?
R.
No. I'll give a look at it and let you know.
Christophe.
Here is an updated patch, which now does no
This time with the actual patch attached.
On 31 August 2012 15:23, Christophe Lyon christophe.l...@linaro.org wrote:
On 24 August 2012 10:54, Christophe Lyon christophe.l...@linaro.org wrote:
On 24 August 2012 10:40, Richard Earnshaw rearn...@arm.com wrote:
Has this been tested for
On 2012-08-31 07:25, Christophe Lyon wrote:
+ offset = gen_rtx_CONST_INT (VOIDmode, location);
Never call gen_rtx_CONST_INT directly. Use GEN_INT.
r~
On 27 August 2012 21:29, Janis Johnson janis_john...@mentor.com wrote:
On 08/27/2012 08:02 AM, Christophe Lyon wrote:
I guess that the 'right' (portable) was of initializing a vector is to
load it from an array, right?
See http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01114.html for Richard
On 28 August 2012 16:20, Christophe Lyon christophe.l...@linaro.org wrote:
This makes writing exhaustive, portable (big and little endian),
executable tests a painful task.
For instance, considering the attached sample code, I obtain a
different result in big-endian vs little-endian, while the
[ Richard, sorry for the duplicate message where I omitted the mailing-list]
On 24 August 2012 10:40, Richard Earnshaw rearn...@arm.com wrote:
Has this been tested for big-endian?
Hi,
While improving my tests and trying to turn them into execution tests,
I realized that vector initialization
On 08/27/2012 08:02 AM, Christophe Lyon wrote:
[ Richard, sorry for the duplicate message where I omitted the mailing-list]
On 24 August 2012 10:40, Richard Earnshaw rearn...@arm.com wrote:
Has this been tested for big-endian?
Hi,
While improving my tests and trying to turn them into
Hi,
The patch below enables GCC for ARM to implement relevant constant
vector permutations using the Neon vext instruction, by extending the
support currently in place for vrev, vzip, vunzip and vtrn.
For the cases where vext and vrev would lead to the same result, I
have chosen to keep using
On 24/08/12 08:45, Christophe Lyon wrote:
Hi,
The patch below enables GCC for ARM to implement relevant constant
vector permutations using the Neon vext instruction, by extending the
support currently in place for vrev, vzip, vunzip and vtrn.
For the cases where vext and vrev would lead
On 24 August 2012 10:40, Richard Earnshaw rearn...@arm.com wrote:
Has this been tested for big-endian?
R.
No. I'll give a look at it and let you know.
Christophe.
12 matches
Mail list logo
