On Thu, May 20, 2010 at 08:59:32PM -0700, Mark Mitchell wrote:
> David Edelsohn wrote:
> > No one disagrees with the potential benefit of the feature.
>
> OK; I must have misremembered.
>
> I believe our current implementation keeps track of FP usage through the
> front-end, and then disables any
David Edelsohn wrote:
>>> It is of course a feature much
>>> less valuable on a workstation/server class operating system than on the
>>> VxWorks/RTEMS class of RTOS systems.
> No one disagrees with the potential benefit of the feature.
OK; I must have misremembered.
I believe our current imple
On Thu, May 20, 2010 at 9:35 PM, Alan Modra wrote:
> On Thu, May 20, 2010 at 09:40:47AM -0700, Mark Mitchell wrote:
>> It is of course a feature much
>> less valuable on a workstation/server class operating system than on the
>> VxWorks/RTEMS class of RTOS systems.
>
> Even on servers this option
On Thu, May 20, 2010 at 09:40:47AM -0700, Mark Mitchell wrote:
> It is of course a feature much
> less valuable on a workstation/server class operating system than on the
> VxWorks/RTEMS class of RTOS systems.
Even on servers this option may be quite valuable. I recall seing
figures that showed u
Joel Sherrill wrote:
> I know RTEMS users have asked about this option before.
> We have the same problem since we also support floating
> point as an optional task attribute. On some tasks we implicitly
> make the port force all tasks to have FP contexts.
>
> Why was this rejected and not merge
On 05/20/2010 11:21 AM, Mark Mitchell wrote:
Robert Grimm wrote:
Actually, I saw some old posts that talked about a -fno-implicit-fp option
[I know this is a very old post, but I noticed it in old email and felt
it might still be useful to reply.]
CodeSourcery has a -fno-implicit-
Robert Grimm wrote:
> Actually, I saw some old posts that talked about a -fno-implicit-fp option
[I know this is a very old post, but I noticed it in old email and felt
it might still be useful to reply.]
CodeSourcery has a -fno-implicit-fp option that does exactly what you
have requested in so
Am Samstag, den 16.01.2010, 23:14 + schrieb Paul Brook:
> > > > Is there a way to get GCC to only use the FPU when we explicitly want
> > > > to use it (i.e. when we use doubles/floats)? Is -msoft-float my only
> > > > option here? Is there any sort of #pragma that could do the same
> > >
> > > Is there a way to get GCC to only use the FPU when we explicitly want
> > > to use it (i.e. when we use doubles/floats)? Is -msoft-float my only
> > > option here? Is there any sort of #pragma that could do the same
> > > thing as -msoft-float (I didn't see one)?
> >
> > To absolutely
Thanks to all who have responded so far. Thanks to Martin for the
-mfloat-abi=softfp option as that could be useful to us.
On Jan 16, 2010, at 6:23 AM, David Edelsohn wrote:
> On Fri, Jan 15, 2010 at 6:42 PM, Robert Grimm wrote:
>> Greetings all,
>>
>> I'm working with the powerpc-eabi archit
On 1/16/10, David Edelsohn wrote:
> > Is there a way to get GCC to only use the FPU when we explicitly want to
> use it (i.e. when we use doubles/floats)? Is -msoft-float my only option
> here? Is there any sort of #pragma that could do the same thing as
> -msoft-float (I didn't see one)?
>
On Fri, Jan 15, 2010 at 6:42 PM, Robert Grimm wrote:
> Greetings all,
>
> I'm working with the powerpc-eabi architecture (specifically, the MPC563
> processor). For some time we have been using GCC 3.4.3 and I noticed gcc
> generating code that makes use of the floating point registers for 64-b
On 01/15/2010 05:42 PM, Robert Grimm wrote:
Greetings all,
I'm working with the powerpc-eabi architecture (specifically, the MPC563
processor). For some time we have been using GCC 3.4.3 and I noticed gcc
generating code that makes use of the floating point registers for 64-bit
integer loads
13 matches
Mail list logo
