There’s a little history about it buried in this message:
https://lists.rtems.org/pipermail/users/2005-November/013467.html
Cygnus or Codesourcery must have added it for VxWorks to use, but it never got into the official tree. There’s a long thread about it here but it doesn’t end with a final decision.
Note that the EPICS build only uses that flag for the vxWorks-ppc604 target, which we don’t use at APS. Maybe it’s time to go through and deprecate some of our older build targets…
- Andrew
On Jun 4, 2020, at 8:30 AM, Michael Davidsaver via Core-talk < core-talk at aps.anl.gov> wrote:
On 6/4/20 6:10 AM, Zimoch Dirk (PSI) via Core-talk wrote:
The problem seems to be that -fno-implicit-fp forbids to inline floating point functions into non-floating point
functions. In case of expire, the function uses no float/double explicitly:
I had wondered about that option. It doesn't appear in the gcc docs.
I guess it is a vxworks patch?
https://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Option-Summary.html#Option-Summary
epicsTimerNotify::expireStatus timerForOldFdmgr::expire ( const epicsTime & )
{
(*this->pFunc) (this->pParam);
return noRestart;
}
But epicsTimerNotify::expireStatus is a class containing a double. As the error happens at the closing } it probably
inlining the implicit operator= of the return value.
What I did now to solve the problem is to remove -fno-implicit-fp from ARCH_DEP_CFLAGS (which is used for C and C++) and
to add it to CODE_CFLAGS, which is used for C but not for C++. This is under the assumption that interrupt handlers are
written in C, not C++. But this does not cover extern "C" ISRs in C++.
Maybe using __attribute__((optimize ("-fno-implicit-fp"))) or #pragma GCC ("-fno-implicit-fp") would be a better choice
to treat ISRs, but unfortunately both are not understood by the VxWorks 6.9 compiler. At least it warns: "'optimize'
attribute directive ignored".
On Thu, 2020-06-04 at 09:24 +0000, Zimoch Dirk (PSI) via Core-talk wrote:
It was on TechTalk in 2014 already: https://epics.anl.gov/tech-talk/2014/msg01579.php
On Thu, 2020-06-04 at 08:55 +0000, Zimoch Dirk (PSI) via Core-talk wrote:
I found that the option -fno-implicit-fp causes the problem. When adding it to the generic ppc32 configuration, I get
the same "unable to find a register to spill in class 'FLOAT_REGS'" error unless I add -fno-expensive-optimizations as
well.
I had originally added this option when I ran into strange run-time errors because an interrupt handler of some driver
had used floating point registers without being asked to do so for moving "long long" values. As the floating point
registers are not saved when entering interrupt mode, bad things happened to the interrupted thread.
On Wed, 2020-06-03 at 17:51 +0000, Johnson, Andrew N. wrote:
I suspect that the CPU-specific code in gcc for the ppc604 target is older than for the ppc32 target and can’t cope with newer constructs, we’ve had similar issues before. That’s why I really want to encourage you try the ppc32
targets, I don’t think they will show these errors at all and switching will save you time investigating the problems.
- Andrew
On Jun 3, 2020, at 12:30 PM, Zimoch Dirk (PSI) via Core-talk <core-talk at aps.anl.gov> wrote:
3 files have problems implementing the pure virtual function epicsTimerNotify::expire(): fdmgr.cc line 152, epicsTime.cpp line 62 and epicsTimerTest.cpp line 319. What helps is -O1 or -no-expensive-optimizations.
As I expect problems with any code that implements expire() I have now added 'CXXFLAGS += -fno-expensive-optimizations' to the general options for that architecture, not only for the 3 failing files.
This does not yet solve the problem with typeCast.h.
More tests tomorrow.
-----Ursprüngliche Nachricht-----
Von: Michael Davidsaver <mdavidsaver at gmail.com>
Gesendet: Mittwoch, 3. Juni 2020 18:48
An: Zimoch Dirk (PSI) <dirk.zimoch at psi.ch>; 'core-talk at aps.anl.gov' <core-
talk at aps.anl.gov>
Betreff: Re: AW: EPICS 7 and VxWorks 6.9 for PPC604?
On 6/3/20 8:31 AM, Zimoch Dirk (PSI) wrote:
I will try the selective -fno-inline ...
If vxworks 6.7 had gcc 4.1 then the threshold for using
__attribute__((always_inline)) is now being crossed.
https://github.com/epics-
base/pvDataCPP/blob/0fa927afa7d92f490f92eb4906e27046080309e2/src/misc
/pv/templateMeta.h#L15-L16
-----Ursprüngliche Nachricht-----
Von: Zimoch Dirk (PSI)
Gesendet: Mittwoch, 3. Juni 2020 17:30
An: 'Michael Davidsaver' <mdavidsaver at gmail.com>; 'core-
talk at aps.anl.gov'
<core-talk at aps.anl.gov>
Betreff: AW: EPICS 7 and VxWorks 6.9 for PPC604?
It's gcc 4.3.3.
Using -O0 (as used to fix bug 1702298) in helps for fdmgr.cpp but not for
typeCast.h.
-----Ursprüngliche Nachricht-----
Von: Michael Davidsaver <mdavidsaver at gmail.com>
Gesendet: Mittwoch, 3. Juni 2020 17:13
An: Zimoch Dirk (PSI) <dirk.zimoch at psi.ch>; 'core-talk at aps.anl.gov' <core-
talk at aps.anl.gov>
Betreff: Re: EPICS 7 and VxWorks 6.9 for PPC604?
For those of us who aren't so familiar with vxworks, which GCC version(s)
are
involved.
You may remember https://bugs.launchpad.net/epics-base/+bug/1702298
On 6/3/20 8:04 AM, Zimoch Dirk (PSI) via Core-talk wrote:
Has anyone already compiled EPICS 7 for VxWorks 6.9 for PPC604?
I have problems:
With -O2 it fails here:
../fdmgr/fdmgr.cpp: In member function 'virtual
epicsTimerNotify::expireStatus timerForOldFdmgr::expire(const
epicsTime&)':
../fdmgr/fdmgr.cpp:152: error: unable to find a register to spill in class
'FLOAT_REGS'
../fdmgr/fdmgr.cpp:152: error: this is the insn:
(insn:HI 16 15 17 2 ../fdmgr/fdmgr.cpp:151 (set (reg:DF 126 [
D.11913.delay
])
(mem/s/j/c:DF (plus:SI (reg/f:SI 113 sfp)
(const_int 8 [0x8])) [0 D.11913.delay+0 S8 A64])) 336
{*movdf_hardfloat32} (expr_list:REG_EQUIV (mem/s/j/c:DF (plus:SI (reg/f:SI
113
sfp)
(const_int 8 [0x8])) [0 D.11913.delay+0 S8 A64])
(nil)))
../fdmgr/fdmgr.cpp:152: confused by earlier errors, bailing out
With -O1 (or lower) it comliles the above but then fails here:
../../src/misc/pv/typeCast.h: In function
'void<unnamed>::castVTyped(size_t,
void*, const void*) [with TO = std::basic_string<char, std::char_traits<char>,
std::allocator<char> >, FROM = float]':
../../src/misc/pv/typeCast.h:195: sorry, unimplemented: inlining failed in
call
to 'TO epics::pvData::castUnsafe(const FROM&) [with TO =
std::basic_string<char, std::char_traits<char>, std::allocator<char> >, FROM
=
float]': recursive inlining
../../src/misc/typeCast.cpp:38: sorry, unimplemented: called from here
At least the compiler is "sorry". I feel much better.
BTW: VxWorks 6.7 has no such problems.
Dirk
--
Complexity comes for free, simplicity you have to work for.
--
Complexity comes for free, simplicity you have to work for.
|