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
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
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
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
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
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
On Tue, Dec 2, 2014 at 2:01 PM, Kyrill Tkachov kyrylo.tkac...@arm.com 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 Nov 26, 2014, at 4:24 AM, Andrew Stubbs andrew_stu...@mentor.com 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
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 27, 2014, at 9:28 AM, Andrew Stubbs a...@codesourcery.com 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:
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.
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?
To: 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 7
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
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 have
On 15/09/14 14:29, Richard Earnshaw wrote:
Yep, that's fine.
Committed, thanks.
Andrew
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 Thumb1 or
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 a...@codesourcery.com
* gcc/config/arm/arm.c (arm_option_override):
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.
23 matches
Mail list logo
