EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  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  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: calc and calcout records in EPICS 3.14.6
From: "Singleton, SJ (Steve)" <[email protected]>
To: "'Geoff Savage'" <[email protected]>
Cc: "'[email protected]'" <[email protected]>
Date: Tue, 16 Nov 2004 09:14:04 -0000
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.

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

Navigate by Date:
Prev: Re: calc and calcout records in EPICS 3.14.6 Dirk Zimoch
Next: RE: calc and calcout records in EPICS 3.14.6 Williams Jr, Ernest L.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: calc and calcout records in EPICS 3.14.6 Mark Rivers
Next: RE: calc and calcout records in EPICS 3.14.6 Williams Jr, Ernest L.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·