EPICS Base

casDGIntfOS.cc does not compile with vxWorks 6.6 for ppc

Bug #1702298 reported by Dirk Zimoch on 2017-07-04

This bug affects 1 person

	Status	Importance	Assigned to	Milestone
EPICS Base	Status tracked in 7.0
3.14	Fix Released	Low	Andrew Johnson	EPICS Base 3.14.12.7
3.15	Fix Released	Low	Andrew Johnson	EPICS Base 3.15.6
3.16	Fix Released	Low	Andrew Johnson	EPICS Base 3.16.2
7.0	Fix Released	Low	Andrew Johnson

Bug Description

I get the following compiler error when building R3.16.1 with vxWorks 6.6 for ppc.
The same problem occurs when building R3.15.5 or R3.14.12.4 with vxWorks 6.6.
Other vxWorks versions (6.2, 6.3, 6.7) have no problem with this code. The code does not look particularly strange.

/afs/psi.ch/project/vxworks/VxWorks6.6/gnu/4.1.2-vxworks-6.6/x86-linux2/bin/ccppc -DUSE_TYPED_RSET -DCPU=PPC604 -DvxWorks=vxWorks -include /afs/psi.ch/project/vxworks/VxWorks6.6/vxworks-6.6/target/h/vxWorks.h -O2 -Wall -fno-strict-aliasing -mcpu=604 -mstrict-align -fno-implicit-fp -mlongcall -fno-builtin -I. -I../O.Common -I. -I. -I.. -I../../../../../../src/ca/legacy/pcas/generic -I../../../../../../src/ca/legacy/pcas/io/bsdSocket -I../../../../../../src/ca/legacy/pcas/generic/st -I../../../../../../src/ca/client -I/usr/local/epics/base-3.16.1/include/compiler/gcc -I/usr/local/epics/base-3.16.1/include/os/vxWorks -I/usr/local/epics/base-3.16.1/include -I/afs/psi.ch/project/vxworks/VxWorks6.6/vxworks-6.6/target/h -I/afs/psi.ch/project/vxworks/VxWorks6.6/vxworks-6.6/target/h/wrn/coreip -c ../../../../../../src/ca/legacy/pcas/generic/st/casDGIntfOS.cc
../../../../../../src/ca/legacy/pcas/generic/st/casDGIntfOS.cc: In member function 'virtual epicsTimerNotify::expireStatus casDGEvWakeup::expire(const epicsTime&)':
../../../../../../src/ca/legacy/pcas/generic/st/casDGIntfOS.cc:153: error: unable to find a register to spill in class 'FLOAT_REGS'
../../../../../../src/ca/legacy/pcas/generic/st/casDGIntfOS.cc:153: error: this is the insn:
(insn:HI 50 49 127 3 (set (reg:DF 124 [ D.20502 ])
        (mem/s/c:DF (plus:SI (reg/f:SI 113 sfp)
                (const_int 16 [0x10])) [0 D.20499+0 S8 A128])) 301 {*movdf_hardfloat32} (insn_list:REG_DEP_ANTI 49 (nil))
    (nil))
../../../../../../src/ca/legacy/pcas/generic/st/casDGIntfOS.cc:153: confused by earlier errors, bailing out

Revision history for this message

Dirk Zimoch (dirk.zimoch) wrote on 2017-07-05:

It seems to be a gcc bug that EPICS probably should not care about:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7426
Instead document that the vxWorks 6.6 compiler is buggy as a "known problem".

Revision history for this message

Andrew Johnson (anj) wrote on 2017-07-05:

If you look in src/ca/legacy/pcas/build/Makefile you'll see that we already have one workaround for a similar VxWorks compiler bug in gcc 4.1.2 for the casStreamOS source file, which we handle by turning off optimization for that file. Please try the same fix for the casDGIntfOS file. I'm OK with applying that if it works for you.

Revision history for this message

Dirk Zimoch (dirk.zimoch) wrote on 2017-07-06:

Even with -O0 it does not compile. Still tying other options...

Revision history for this message

Dirk Zimoch (dirk.zimoch) wrote on 2017-07-06:

-fno-inline helps. I will see how to tweak inlining for vxWorks 6.6.

Revision history for this message

Dirk Zimoch (dirk.zimoch) wrote on 2017-07-06:

> we already have one workaround for a similar VxWorks compiler bug in gcc 4.1.2 for the casStreamOS source file

This is the code:
ifeq ($(VX_GNU_VERSION), 4.1.2)
  casStreamOS_CXXFLAGS_vxWorks-ppc604_altivec = -O0
  casStreamOS_CXXFLAGS_vxWorks-ppc604_long = -O0
  casStreamOS_CXXFLAGS_vxWorks-ppc604 = -O0
endif

This does not work nicely. If you use a different T_A, as I do when I compile for up to 7 different vxWorks versions and which just include the vxWorks-ppc604_* configs, this does not work.
However, I neither need it for vxWorks 6.6 nor for 6.7 which both use gcc 4.1.2.

Acrually 3 vxWorks versions (6.6, 6.7, 6.8) use slightly different gcc 4.1.2 versions. Maybe only one has the problem:
6.6: gcc version 4.1.2 (Wind River VxWorks G++ 4.1-82)
6.7: gcc version 4.1.2 (Wind River VxWorks G++ DWARF-EH 4.1-131)
Compiler SPR fixes: cq107091 cq111298 cq111124 cq111139 cq111312 cq111576 cq113600 cq118973 cq126167 cq127961 cq128197 cq130491 (Fixes! Whatever they are.)
6.8: ?

The following worked for me (vxWorks 6.6 for ppc604_long):
# There is a bug in the vxWorks 6.6 C++ compiler that these work around:
# See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7426
ifeq ($(VXWORKS_VERSION), 6.6)
casDGIntfOS_CXXFLAGS_$(T_A) = -fno-inline
casStreamOS_CXXFLAGS_$(T_A) = -fno-inline
endif

Revision history for this message

Dirk Zimoch (dirk.zimoch) wrote on 2017-07-06:

Actually $(T_A) is not needed
ifeq ($(VXWORKS_VERSION), 6.6)
casDGIntfOS_CXXFLAGS = -fno-inline
casStreamOS_CXXFLAGS = -fno-inline
endif

I wonder if other g++ targets than -mcpu=604 need this?
If not better check ARCH_CLASS filter for -m options in ARCH_DEP_CFLAGS.

Revision history for this message

Dirk Zimoch (dirk.zimoch) wrote on 2017-07-06:

ppc603 is fine.
Using ppc604_long or ppc604_altivec makes no difference.

Thus I added a filter for ppc604:
ifeq ($(VXWORKS_VERSION)$(filter -mcpu=604,$(ARCH_DEP_CFLAGS)), 6.6-mcpu=604)
casDGIntfOS_CXXFLAGS = -fno-inline
casStreamOS_CXXFLAGS = -fno-inline
endif