Experimental Physics and
Industrial Control System

"Lawrence T. Hoff" <[email protected]> · Tue, 8 Feb 2005 08:00:50 -0500


> -----Original Message-----
> From: Dirk Zimoch [mailto:[email protected]] 
> Sent: Tuesday, February 08, 2005 7: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);

	Perhaps there is some other task which is doing floating
point operations which is *not* declared as floating point.
Such a task could "step on" the register containing "scan_period".
VxWorks does not restore FP registers when re-scheduling a FP task
unless there has been another FP task scheduled since the previous
FP task had run. I.e. if VxWorks thinks that only non-FP tasks
have run, the FP registers will not be restored, even if they 
have changed for some reason.

	Worse yet, on the PPC, the compiler will (under certain
optimization settings) use the 64-bit FP registers to store
64-bit integer data structures. An example of such data structures
are "struct timeval" and "struct timespec" (each of which consists
of 2 32-bit integer values). 

	If I recall correctly, this optimization is not used if:

	1) All optimization is turned off (-O0)
	2) The -mstrict-align option is used

	You could try recompiling with these options enabled, and/or
ensuring that *all* tasks are FP tasks, and see if the problem goes 
away.

HTH -- Larry

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System