On Mon, Mar 28, 2011 at 03:15:08PM +0100, Peter Maydell wrote:
On 14 March 2011 05:35, Nathan Froyd froy...@codesourcery.com wrote:
Oh, right. I am ambivalent as to whether passing env to such functions
is the right thing to do or not.
So did this amount to a request for a change to this
On 14 March 2011 05:35, Nathan Froyd froy...@codesourcery.com wrote:
On Fri, Mar 11, 2011 at 10:31:31PM +, Peter Maydell wrote:
On 11 March 2011 18:30, Nathan Froyd froy...@codesourcery.com wrote:
Is there a reason that you don't simply use the global env rather than
passing in an extra
On Fri, Mar 11, 2011 at 10:31:31PM +, Peter Maydell wrote:
On 11 March 2011 18:30, Nathan Froyd froy...@codesourcery.com wrote:
Is there a reason that you don't simply use the global env rather than
passing in an extra parameter everywhere?
Just following the pattern that generally
Make the Neon helper routines use the correct FP status from
the CPUEnv rather than using a dummy static one. This means
they will correctly handle denormals and NaNs and will set
FPSCR exception bits properly.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
target-arm/helpers.h |
On Fri, Mar 11, 2011 at 06:12:20PM +, Peter Maydell wrote:
Make the Neon helper routines use the correct FP status from
the CPUEnv rather than using a dummy static one. This means
they will correctly handle denormals and NaNs and will set
FPSCR exception bits properly.
Is there a reason
On 11 March 2011 18:30, Nathan Froyd froy...@codesourcery.com wrote:
On Fri, Mar 11, 2011 at 06:12:20PM +, Peter Maydell wrote:
Make the Neon helper routines use the correct FP status from
the CPUEnv rather than using a dummy static one. This means
they will correctly handle denormals and
