Experimental Physics and
Industrial Control System

"Williams Jr, Ernest L." <[email protected]> · Tue, 16 Nov 2004 07:52:54 -0500

-----Original Message-----
From: Singleton, SJ (Steve) [mailto:[email protected]]
Sent: Tue 11/16/2004 4:14 AM
To: 'Geoff Savage'
Cc: '[email protected]'
Subject: RE: calc and calcout records in EPICS 3.14.6

Hello,

I met the same problem some time ago; it is associated with the -O
optimisation flag in the gcc cross compiler supplied with Tornado 2.2; I met
it while using the version of gcc 2.9.6 for a Linux development platform
supplied by Dave Thompson, but was also able to reproduce it with the
compiler supplied by Wind River for a Solaris development platform.  It does
not occur with the gcc 2.7.2 supplied with Tornado 2.0.2   The exact 'c'
syntax that fails to compile correctly is 

double *pstacktop;
   .
   . 
   .
case EQUAL:
   .
   .
*pstacktop == (*pstacktop == *(pstacktop + 1));

which occurs in function calcPerform (in base/src/libCom/calcPerform.c on
EPICS 3.13 or base/src/libCom/calc/calcPerform.c on EPICS 3.14). 

Adding:
unsigned char testResult;

and replacing the condition test line by

testResult = (*pstacktop == *(pstacktop + 1));
*pstacktop = (double)testResult;

is a work-around for the problem in this particular case.

Alternatively, if performance is not an issue for you, you can remove the -O
optimisation flag from the definitions of GCC_OPT_YES, G++_OPT_YES and
CCC_OPT_YES in config/CONFIG.Vx.  As performance is not an issue in our
case, we have followed the latter approach to guard against other
occurrences of the same syntax.

We will also check with WindRiver for a patch related to this issue.

Regards
Steve  

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Geoff Savage
Sent: 16 November 2004 01:21
To: EPICS Tech-Talk
Subject: calc and calcout records in EPICS 3.14.6

Hi,

We noticed some changed behaviour in calc and calcout records from 
v3.13.4 to v3.14.6 and were unable to identify the cause.  Take a simple 
calc record, maybe too simple:
record(calc,"CTL_TEST_66/CALC") {
   field(CALC, "1=0")
   field(SCAN, "1 second")
}
In v3.13.4 VAL is the expected value of zero.  In v3.14.6 VAL is one.   
The same applies for the calcout record.

What are we missing?

Geoff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System