EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: compiler bug in gcc version 2.8.1 (Tornado1) for PPC corrupts floationg point constants?
From: "Jeff Hill" <[email protected]>
To: "'Dirk Zimoch'" <[email protected]>, "'TECHTALK'" <[email protected]>
Date: Wed, 9 Feb 2005 08:13:42 -0700
Dirk,

I don't know if anyone has made this suggestion, but
watch out for a driver that uses floating point in its
interrupt service routines as, on vxWorks, the FP
register contents are not saved / restored when entering
/ exiting interrupt context. The driver must do this
manually if it finds a need to use FP in its ISR.

Jeff

> -----Original Message-----
> From: Dirk Zimoch [mailto:[email protected]]
> Sent: Tuesday, February 08, 2005 5:51 AM
> To: TECHTALK
> Subject: compiler bug in gcc version 2.8.1 (Tornado1)
> for PPC corrupts floationg point constants?
> 
> Hi all,
> 
> I have some driver software that contains
> 
> double scan_period;
> scan_period = 0.05;
> 
> The function is executed from startup script, i.e. the
> executing task is
> a floating point task.
> 
> However, sometimes when booting R3.13.2, the ioc
> crashes with "floating
> point underflow" while executing
> 
> printf ("init_record_generic: scan_period=%f\n",
> scan_period);
> 
> I couldn't even look at the registers, because ti also
> crashes when it
> tries to print the register containing scan_period.
> 
> According to the bitpattern, scan_period is not 0.05,
> but some
> denormalized value.
> 
> Even more astonishing is that the error only happens
> sometimes! In rare
> cases, everything is OK. When I boot R3.13.5, also
> everything is OK. I
> have compared the driver library compiled for both
> EPICS versions. It is
> exactly the same object code.
> 
> We load the driver library in the startup script.
> Maybe there is
> something wrong with the ld command, corrupting
> constants?
> 
> But how can this depend on the EPICS release? Maybe
> the code is loaded
> to another location, but does the location matter?
> 
> Why does this only happen with one driver?
> 
> Any ideas or solutions?
> 
> 
> Dirk
> 
> --
> Dr. Dirk Zimoch
> Swiss Light Source
> Paul Scherrer Institut
> Computing and Controls
> phone +41 56 310 5182
> fax   +41 56 310 4413



Replies:
Re: compiler bug in gcc version 2.8.1 (Tornado1) for PPC corrupts floationg point constants? Ralph Lange
References:
compiler bug in gcc version 2.8.1 (Tornado1) for PPC corrupts floationg point constants? Dirk Zimoch

Navigate by Date:
Prev: Re: R3.14.7 next build error ?! Ralph Lange
Next: Re: compiler bug in gcc version 2.8.1 (Tornado1) for PPC corrupts floationg point constants? Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: compiler bug in gcc version 2.8.1 (Tornado1) for PPC corrupts floationg point constants? Lawrence T. Hoff
Next: Re: compiler bug in gcc version 2.8.1 (Tornado1) for PPC corrupts floationg point constants? Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·