On 14/01/15 08:21, Ramana Radhakrishnan wrote:
Ok, that should be enough. Please watch out for any testing fallout this
week.
Committed, thanks.
Andrew
On 13/01/15 21:01, Andrew Stubbs wrote:
On 12/01/15 13:50, Ramana Radhakrishnan wrote:
In principle ok, but I'd like a comment in there explaining why we've
done this. Can you also post under what configurations these have been
tested ?
Is this better?
I tested it by running the vect.exp te
On 12/01/15 13:50, Ramana Radhakrishnan wrote:
In principle ok, but I'd like a comment in there explaining why we've
done this. Can you also post under what configurations these have been
tested ?
Is this better?
I tested it by running the vect.exp tests with a variety of -mcpu flags.
Andrew
Sorry about the slow response- have been on holiday and still catching
up on email.
On 12/01/15 13:16, Andrew Stubbs wrote:
Ping.
On 23/12/14 16:46, Andrew Stubbs wrote:
On 03/12/14 15:03, Andrew Stubbs wrote:
The tools have always allowed us to drop down the arch to
march=armv5te along with
Ping.
On 23/12/14 16:46, Andrew Stubbs wrote:
On 03/12/14 15:03, Andrew Stubbs wrote:
The tools have always allowed us to drop down the arch to
march=armv5te along with using -mfpu=neon. We are now changing command
line behaviour, so an inform in terms of diagnostics to the user would
be useful
On 03/12/14 15:03, Andrew Stubbs wrote:
The tools have always allowed us to drop down the arch to
march=armv5te along with using -mfpu=neon. We are now changing command
line behaviour, so an inform in terms of diagnostics to the user would
be useful as it states that we don't really have mfpu=neo
On 02/12/14 21:45, Ramana Radhakrishnan wrote:
I've spent some time this evening pondering over your patch. Firstly
it appears that the current behaviour is going to cause more breakage
than originally expected. If this is to go in we'd have a number of
users having to add -mfloat-abi=soft to the
On Tue, Dec 2, 2014 at 2:01 PM, Kyrill Tkachov wrote:
>
> On 23/09/14 09:27, James Greenhalgh wrote:
>>
>> On Mon, Sep 15, 2014 at 11:56:03AM +0100, Andrew Stubbs wrote:
>>>
>>> On 15/09/14 10:46, Richard Earnshaw wrote:
Hmm, I wonder if arm_override_options should reject neon + (arch <
On 23/09/14 09:27, James Greenhalgh wrote:
On Mon, Sep 15, 2014 at 11:56:03AM +0100, Andrew Stubbs wrote:
On 15/09/14 10:46, Richard Earnshaw wrote:
Hmm, I wonder if arm_override_options should reject neon + (arch < 7).
Is this more to your taste?
Is this really such a good idea? It causes c
On Nov 27, 2014, at 9:28 AM, Andrew Stubbs wrote:
> On 27/11/14 17:05, Mike Stump wrote:
>> Could you include a link or the patch. If the test suite, I'll review it if
>> no one else steps up.
>
> The original patch is here:
>
> https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01119.html
Sorry,
On 27/11/14 17:05, Mike Stump wrote:
Could you include a link or the patch. If the test suite, I'll review it if no
one else steps up.
The original patch is here:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01119.html
Thanks
Andrew
On Nov 26, 2014, at 4:24 AM, Andrew Stubbs wrote:
> On 14/11/14 11:12, Andrew Stubbs wrote:
>> On 07/11/14 10:35, Andrew Stubbs wrote:
if armv6 never co-exist with NEON, personally I think your original
patch is better
because TARGET_NEON generally will be used when all options
On 14/11/14 11:12, Andrew Stubbs wrote:
On 07/11/14 10:35, Andrew Stubbs wrote:
if armv6 never co-exist with NEON, personally I think your original
patch is better
because TARGET_NEON generally will be used when all options are
processed.
any way, this needs gate keeper's approval.
P
On 07/11/14 10:35, Andrew Stubbs wrote:
if armv6 never co-exist with NEON, personally I think your original
patch is better
because TARGET_NEON generally will be used when all options are
processed.
any way, this needs gate keeper's approval.
Ping, Richard.
Ping.
if armv6 never co-exist with NEON, personally I think your original
patch is better
because TARGET_NEON generally will be used when all options are
processed.
any way, this needs gate keeper's approval.
Ping, Richard.
Andrew
On 15/10/14 17:58, Andrew Stubbs wrote:
On 15/10/14 17:34, Jiong Wang wrote:
On 23/09/14 16:22, Stubbs, Andrew wrote:
Maybe the original patch is better? Or maybe it should reconfigure the
FPU instead of erroring out? But reconfigure it to what?
Andrew,
are you still working on this?
On 15/10/14 17:34, Jiong Wang wrote:
On 23/09/14 16:22, Stubbs, Andrew wrote:
Maybe the original patch is better? Or maybe it should reconfigure the
FPU instead of erroring out? But reconfigure it to what?
Andrew,
are you still working on this?
a bunch of tests on my local environment
: Stubbs, Andrew
Cc: Richard Earnshaw; gcc-patches@gcc.gnu.org
Subject: Re: [arm][patch] fix arm_neon_ok check on !arm_arch7
On Mon, Sep 15, 2014 at 11:56:03AM +0100, Andrew Stubbs wrote:
On 15/09/14 10:46, Richard Earnshaw wrote:
Hmm, I wonder if arm_override_options should reject neon + (arch <
; gcc-patches@gcc.gnu.org
Subject: Re: [arm][patch] fix arm_neon_ok check on !arm_arch7
On Mon, Sep 15, 2014 at 11:56:03AM +0100, Andrew Stubbs wrote:
> On 15/09/14 10:46, Richard Earnshaw wrote:
> > Hmm, I wonder if arm_override_options should reject neon + (arch < 7).
>
> Is
On Mon, Sep 15, 2014 at 11:56:03AM +0100, Andrew Stubbs wrote:
> On 15/09/14 10:46, Richard Earnshaw wrote:
> > Hmm, I wonder if arm_override_options should reject neon + (arch < 7).
>
> Is this more to your taste?
Is this really such a good idea? It causes carnage throughout the
testsuite if you
On 15/09/14 14:29, Richard Earnshaw wrote:
Yep, that's fine.
Committed, thanks.
Andrew
On 15/09/14 11:56, Andrew Stubbs wrote:
> On 15/09/14 10:46, Richard Earnshaw wrote:
>> Hmm, I wonder if arm_override_options should reject neon + (arch < 7).
>
> Is this more to your taste?
>
Yep, that's fine.
> Andrew
>
> P.S. arm_override_options was renamed in 2010.
I'm getting old :-(
R
On 15/09/14 10:46, Richard Earnshaw wrote:
Hmm, I wonder if arm_override_options should reject neon + (arch < 7).
Is this more to your taste?
Andrew
P.S. arm_override_options was renamed in 2010.
2014-09-15 Andrew Stubbs
* gcc/config/arm/arm.c (arm_option_override): Reject -mfpu=neon
wh
On 13/09/14 22:39, Andrew Stubbs wrote:
> Hi,
>
> I get a lot of "vect/*" and "neon-*" test failure in my armv5te testing
> because the arm_neon_ok test incorrectly detects that NEON is valid on
> arm926ej-s.
>
> It turns out that the reason is that the compiler only disallows NEON
> for Thumb
Hi,
I get a lot of "vect/*" and "neon-*" test failure in my armv5te testing
because the arm_neon_ok test incorrectly detects that NEON is valid on
arm926ej-s.
It turns out that the reason is that the compiler only disallows NEON
for Thumb1 or soft-float configurations. Otherwise it just take
25 matches
Mail list logo
