EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: Any News on EPICS 3.14.11 with vxWorks 6.7
From: "Ernest L. Williams Jr." <[email protected]>
To: Jeff Hill <[email protected]>
Cc: "'Yves Lussignol'" <[email protected]>, "Williams Jr., Ernest L." <[email protected]>, "'Jean-Francois Gournay'" <[email protected]>, "'Eric Bjorklund'" <[email protected]>, [email protected]
Date: Thu, 10 Dec 2009 22:03:06 -0800
Hi Jeff,

Awesome!!!

I am able to see this now.

I have submitted a new case with WindRiver and will raise the priority to get things resolved as soon as possible.
They are working on this as we speak. :)

Thanks again for isolating this compiler bug.
I still don't understand why our colleagues that use PPC604 and EPICS R3.14.11 with vxWorks 6.6/6.7 don't see this problem.

Well, in any case do you have a work-around that will step around this in order to build cas and excas?



Cheers,
Ernest



Jeff Hill wrote:
Ernest,

The following code reproduces the vxWorks 6.6 gcc compiler bug (as seen with
EPICS R3.14.11).

[hill@integrity cas]$
/ade/vxWorks/6/gnu/4.1.2-vxworks-6.6/x86-linux2/bin/ccppc -c
-DCPU=PPC604  -DvxWorks      -O2   -Wall     -mcpu=604 -mstrict-align
-fno-implicit-fp    -fno-builtin   -MMD -I. -I../O.Common -I. -I..
-I../../../../src/cas/generic -I../../../../src/cas/io/bsdSocket
-I../../../../src/cas/generic/st -I../../../../src/cas/../ca
-I../../../../include/os/vxWorks -I../../../../include
-I/ade/vxWorks/6/vxworks-6.6/target/h
-I/ade/vxWorks/6/vxworks-6.6/target/h/wrn/coreip -v
Using built-in specs.
Target: powerpc-wrs-vxworks
Configured with: /scratch/nathan/vxworks/src/gcc-4.1/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=powerpc-wrs-vxworks --enable-threads --disable-libmudflap
--disable-libssp --disable-libgomp --disable-libstdcxx-pch
--enable-sjlj-exceptions --disable-hosted-libstdcxx
--enable-version-specific-runtime-libs --with-gnu-as --with-gnu-ld
--enable-languages=c,c++ --disable-shared --disable-hosted-libstdcxx
--with-cxxabi=/scratch/nathan/vxworks/src/dinkum-20021215/include
--with-pkgversion='Wind River VxWorks G++ 4.1-82'
[email protected] --disable-nls --prefix=/opt/codesourcery
--exec-prefix='/opt/codesourcery/x86-linux2'
--libdir='/opt/codesourcery/lib'
--program-transform-name='s,^gcc$,cc,;s,$,ppc,'
--with-gxx-include-dir=''\''/opt/codesourcery/'\''include/c++/4.1'
--with-license=/scratch/nathan/vxworks/powerpc/obj/host-libs-4.1-82-powerpc-
wrs-vxworks-i686-pc-linux-gnu/usr --with-csl-license-version=20071015
--with-csl-license-feature=gcc_Power_VxWorks
--enable-poison-system-directories
Thread model: vxworks
gcc version 4.1.2 (Wind River VxWorks G++ 4.1-82)

[hill@integrity cas]$
/ade/vxWorks/6/gnu/4.1.2-vxworks-6.6/x86-linux2/bin/ccppc -c
-DCPU=PPC604  -DvxWorks      -O2   -Wall     -mcpu=604 -mstrict-align
-fno-implicit-fp    -fno-builtin   -MMD -I. -I../O.Common -I. -I..
-I../../../../src/cas/generic -I../../../../src/cas/io/bsdSocket
-I../../../../src/cas/generic/st -I../../../../src/cas/../ca
-I../../../../include/os/vxWorks -I../../../../include
-I/ade/vxWorks/6/vxworks-6.6/target/h
-I/ade/vxWorks/6/vxworks-6.6/target/h/wrn/coreip tmp.cc

tmp.cc: In member function 'DblRet Cat::meow()':
tmp.cc:49: error: unable to find a register to spill in class 'FLOAT_REGS'
tmp.cc:49: error: this is the insn:
(insn:HI 30 29 85 3 (set (reg:DF 121 [ D.1042 ])
        (mem/s/c:DF (plus:SI (reg/f:SI 113 sfp)
                (const_int 8 [0x8])) [9 D.1040+0 S8 A64])) 301
{*movdf_hardfloat32} (insn_list:REG_DEP_ANTI 29 (nil))
    (nil))

------------------------snip-snip------------------

class DblRet {
public:
    DblRet ();
private:
    double delay;
};

struct Cow {
    void milk ();
private:
    void moo ();
};

class Fish
{
public:
    Fish ( int & );
    ~Fish ();
};

inline Fish :: Fish ( int & )
{
}

inline Fish :: ~Fish ()
{
}

inline void Cow :: milk ()
{
    extern int & fishy;
    Fish fish ( fishy );
    moo ();
}

class Cat {
public:
    DblRet meow ();
private:
    Cow * m_pCow;
};

DblRet Cat :: meow ()
{
    m_pCow->milk ();
    return DblRet ();
}

------------------------snip-snip------------------

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA


-----Original Message-----
From: Ernest L. Williams Jr. [mailto:[email protected]]
Sent: Wednesday, December 09, 2009 12:46 PM
To: Jeff Hill
Cc: 'Andrew Johnson'; 'Yves Lussignol'; [email protected]; 'Jean-
Francois Gournay'; [email protected]; 'Eric Bjorklund'; Ernest L.
Williams Jr.
Subject: Re: Any News on EPICS 3.14.11 with vxWorks 6.7

Jeff Hill wrote:
Hi Ernest,

Executive summary:
1) Apparently, GCC doesn’t fail with the MVME550 but this is very
similar
processor. What -mcpu flag was used with the MVME5500?

Not sure, if they have a separate CONFIG file for MVME5500
What we have with the distribution of BASE from APS is the following:
<>/configure/os/CONFIG.Common.vxWorks-ppc604

The flag is :
ARCH_DEP_CFLAGS_4 = -mcpu=604 -mstrict-align -fno-implicit-fp


2) I will need to try to reproduce it here with our vxWorks 6.6. That
will
require installation of EPICS R3.14.11 onto a new host here.

Okay, be sure to use the latest GNU Compiler patches from Windriver:

3) I wonder if -mcpu=604e or -mcpu=7450 would a closer match to the
board;
perhaps that’s worth a try.

I tried both options; still does not work. Fails the same way.


Sorry about the delay responding, Los Alamos was, for all practical
purposes, in stasis yesterday due to snow, wind, and power outages (I
spent
most of the day shoveling out three driveways).

A quick review of the current situation is in order. There was a no-
altivec
flag for the C++ compiler that might have helped, but it didn’t, and now
we
see that the issue does not occur with the MVME5500 but does occur with
the
MVME6600. The MVME5500 has an MPC7455 processor chip and the MVME6100
has an
MPC7457 processor chip. We are using -mcpu=604 when the compiler fails,
and
I am not sure what -mcpu option was used for the MVME5500 when it did
compile. Perhaps -mcpu=604e or -mcpu=7450 would be worth trying?

Again, I tried the different mcpu flags that you recommended. Still no
change; build fails.

By the way build for PPC603 architecture builds just fine. :)
I am only having a problem with PPC604



http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC7457

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC7455

I don’t claim to have read up on the subtle differences between these
chips.
Nevertheless, the compiler should produce object code for the supported
CPU
architecture that we select so we have a compiler bug; we are just
looking
for a workaround when selecting different architectures.

I need some work-around in the cas source code; I definitely need this
because of the PV Gateway dependencies.


I _have_ tried to reproduce this in a small code but this is time
consuming
because we have been using Ernest's compiler to test. I will need to try
to
reproduce it here.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA



-----Original Message-----
From: Ernest L. Williams Jr. [mailto:[email protected]]
Sent: Tuesday, December 08, 2009 10:27 AM
To: Jeff Hill
Cc: Andrew Johnson; Yves Lussignol; [email protected]; Jean-
Francois
Gournay; [email protected]; Ernest L. Williams Jr.
Subject: Any News on EPICS 3.14.11 with vxWorks 6.7

Hi Jeff,

Just wanted to follow up on the issue with vxWorks GNU compiler:

I don't understand why our colleagues don't see this problem?


/afs/slac/package/vxworks/devel/6.7/gnu/4.1.2-vxworks-6.7/x86-
linux2/bin/ccppc
-c            -DCPU=PPC604  -DvxWorks -DBSD=44     -g   -Wall
-mcpu=604 -mstrict-align -fno-implicit-fp -mlongcall    -fno-builtin
-DBSD=44  -I. -I../O.Common -I. -I.. -I../../../../src/cas/generic
-I../../../../src/cas/io/bsdSocket -I../../../../src/cas/generic/st
-I../../../../src/cas/../ca -I../../../../include/os/vxWorks
-I../../../../include
-I/afs/slac/package/vxworks/devel/6.7/vxworks-6.7/target/h
-I/afs/slac/package/vxworks/devel/6.7/vxworks-6.7/target/h/wrn/coreip
../../../../src/cas/generic/st/casStreamOS.cc
In file included from
/afs/slac/package/vxworks/devel/6.7/vxworks-6.7/target/h/taskLib.h:257,
                 from
/afs/slac/package/vxworks/devel/6.7/vxworks-
6.7/target/h/private/selectLibP.h:24,
                 from
/afs/slac/package/vxworks/devel/6.7/vxworks-
6.7/target/h/selectLib.h:75,
                 from ../../../../include/os/vxWorks/osdSock.h:35,
                 from ../../../../include/osiSock.h:21,
                 from ../../../../include/fdManager.h:28,
                 from ../../../../src/cas/generic/st/casStreamOS.cc:18:
/afs/slac/package/vxworks/devel/6.7/vxworks-
6.7/target/h/vsbConfig.h:42:2:
warning: #warning "VxWorks Source Build (VSB) project not specified;
using default VxWorks UP configuration under
$WIND_BASE/target/lib/h/config"
../../../../src/cas/generic/st/casStreamOS.cc: In member function
'virtual epicsTimerNotify::expireStatus casStreamIOWakeup::expire(const
epicsTime&)':
../../../../src/cas/generic/st/casStreamOS.cc:283: error: unable to
find
a register to spill in class 'FLOAT_REGS'
../../../../src/cas/generic/st/casStreamOS.cc:283: error: this is the
insn:
(insn 162 161 163 9 ../../../../src/cas/generic/st/casStreamOS.cc:280
(set (reg:DF 119 [ D.21342 ])
        (mem/s/c:DF (plus:SI (reg/f:SI 113 sfp)
                (const_int 24 [0x18])) [0 D.21330+0 S8 A64])) 301
{*movdf_hardfloat32} (nil)
    (nil))
../../../../src/cas/generic/st/casStreamOS.cc:283: confused by earlier
errors, bailing out
make[4]: *** [casStreamOS.o] Error 1
make[4]: Leaving directory
`/afs/slac.stanford.edu/g/lcls/vol8/epics/base/base-R3-14-
11/src/cas/build/O.vxWorks-ppc604_long'
make[3]: *** [install.vxWorks-ppc604_long] Error 2
make[3]: Leaving directory
`/afs/slac.stanford.edu/g/lcls/vol8/epics/base/base-R3-14-
11/src/cas/build'
make[2]: *** [build.install] Error 2
make[2]: Leaving directory
`/afs/slac.stanford.edu/g/lcls/vol8/epics/base/base-R3-14-11/src/cas'
make[1]: *** [cas.install] Error 2
make[1]: Leaving directory
`/afs/slac.stanford.edu/g/lcls/vol8/epics/base/base-R3-14-11/src'


Thanks,
Ernest





References:
RE: Any News on EPICS 3.14.11 with vxWorks 6.7 Jeff Hill

Navigate by Date:
Prev: Reading an array of strings from a Waveform record Simon Hoyle
Next: Re: OMS MAXv driver Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Any News on EPICS 3.14.11 with vxWorks 6.7 Jeff Hill
Next: EPICS database comparison Pam Gurd
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·