EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: EPICS on Tru64unix and HP-UX
From: Kazuro FURUKAWA <[email protected]>
To: "Jeff Hill" <[email protected]>
Cc: [email protected], "'Andrew Johnson'" <[email protected]>, [email protected], "'EPICS core-talk'" <[email protected]>
Date: Sat, 23 Dec 2006 05:51:43 +0900
Hello Jeff,

Sorry for my late reply.  I've got 
  <http://www.aps.anl.gov/epics/download/base/base_R3-14_cvs.tar.gz>
dated Dec.22 06:07 GMT which include your patch, which gives 
errors in comQueSend.cpp as the following log.  And again with my 
dirty patch against comBuf.h it compiles keeping your change to  
osdWireFormat.h.  Sorry for my delay. 

=====
cxx  -c   -pthread -ieee         -DUNIX  -D_OSF_SOURCE   -std gnu  -O            -I. -I.. -I../../../include/os/osf -I../../../include         ../comQueSend.cpp 
cxx: Error: ../../../include/osiWireFormat.h, line 211: Cannot create
          variable "tmp" of incomplete type "WireAlias<const char *>".
          detected during:
            instantiation of "void WireSet(const T &, epicsUInt8 *) [with
                      T=const char *]" at line 191 of "../comBuf.h"
            instantiation of
                      "bool comBuf::push(const T &) [with T=const char *]" at
                      line 144 of "../comQueSend.h"
            instantiation of
                      "void comQueSend::push(const T &) [with T=const char *]"
                      at line 112 of "../comQueSend.cpp"
    WireAlias < T > tmp;
--------------------^
cxx: Error: ../../../include/osiWireFormat.h, line 211: Cannot create
          variable "tmp" of incomplete type "WireAlias<<error-type>>".
          detected during:
            instantiation of "void WireSet(const T &, epicsUInt8 *) [with
                      T=<error-type>]" at line 213
            instantiation of "void WireSet(const T &, epicsUInt8 *) [with
                      T=const char *]" at line 191 of "../comBuf.h"
            instantiation of
                      "bool comBuf::push(const T &) [with T=const char *]" at
                      line 144 of "../comQueSend.h"
            instantiation of
                      "void comQueSend::push(const T &) [with T=const char *]"
                      at line 112 of "../comQueSend.cpp"
    WireAlias < T > tmp;
--------------------^
cxx: Warning: ../comQueSend.cpp, line 327: pointless comparison of unsigned
          integer with zero
    if ( INVALID_DB_REQ ( dataType ) ) {
---------^
cxx: Info: 2 errors detected in the compilation of "../comQueSend.cpp".
=====

>>> On Thu, 21 Dec 2006 15:34:09 JST,  "Jeff Hill" <[email protected]> wrote;
> Hello Kazuro,
> 
> Sorry about the delay responding. Part of the reason was a closure of the
> lab here yesterday due to some significant snowfall here.
> 
> > > Ok, I'm still waiting for a comment from Jeff Hill on your patch and/or
> > > the above compile error - we committed all of your other changes, but
> > > this is Jeff's code so he gets to decide what to do about it.
> 
> The function overload supplied in the comBuf.h patch "bool push ( const char
> * value )" satisfies the compiler's quest for a function with the signature
> "bool push ( const char value [MAX_STRING_SIZE] )" but isn't 100% correct
> because the implementation pushes the value of a pointer into the stream
> instead of pushing a string of length MAX_STRING_SIZE into the stream.
> 
> I had a look at why this compiler appears to not be using "template < class
> T > bool push ( const T & value )" for T set to epicsOldString. I think I
> see the cause in osdWireFormat.h. I committed a fix to CVS. Please try the
> latest version from the R3.14 branch in CVS when you get a chance in order
> to confirm if my suspicions are correct.
> 
> Many thanks for your assistance with R3.14.9.
> 
> PS: I have attached the patch for your review.
> 
> PPS: I suspect that this matter is related to an issue detected by gcc 4.0
> several weeks ago - which apparently wasn't 100% fixed.
> 
> Best Regards,
> 
> Jeff
> 
> 
> cvs diff -r R3-14-2_branch:yesterday -r R3-14-2_branch -u -wb -i (in
> directory
> D:\users\hill\epicsMainTrunk\epics\base\src\libCom\osi\os\default\)
> cvs diff: Diffing .
> Index: osdWireFormat.h
> ===================================================================
> RCS file:
> /net/phoebus/epicsmgr/cvsroot/epics/base/src/libCom/osi/os/default/osdWireFo
> rmat.h,v
> retrieving revision 1.1.2.3
> retrieving revision 1.1.2.4
> diff -c -u -w -b -i -r1.1.2.3 -r1.1.2.4
> cvs diff: conflicting specifications of output style
> --- osdWireFormat.h	5 Dec 2006 01:22:04 -0000	1.1.2.3
> +++ osdWireFormat.h	21 Dec 2006 22:13:12 -0000	1.1.2.4
> @@ -118,10 +118,11 @@
>      dst = tmp._f;
>  }
>  
> -inline void WireGet ( 
> +template <>
> +inline void WireGet < epicsOldString > ( 
>      const epicsUInt8 * pWireSrc, epicsOldString & dst )
>  {
> -    memcpy ( & dst, pWireSrc, sizeof ( dst ) );
> +    memcpy ( dst, pWireSrc, sizeof ( dst ) );
>  }
>  
>  template <>
> @@ -147,10 +148,11 @@
>  #   endif
>  }
>  
> -inline void WireSet ( 
> +template <>
> +inline void WireSet < const epicsOldString > ( 
>      const epicsOldString & src, epicsUInt8 * pWireDst )
>  {
> -    memcpy ( pWireDst, & src, sizeof ( src ) );
> +    memcpy ( pWireDst, src, sizeof ( src ) );
>  }
>  
>  template <>
> 
> ***** CVS exited normally with code 1 *****
> 
> 
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > Sent: Wednesday, December 20, 2006 3:54 PM
> > To: Andrew Johnson
> > Cc: Kazuro FURUKAWA; [email protected]; EPICS core-talk; Jeff Hill
> > Subject: Re: EPICS on Tru64unix and HP-UX
> > 
> > Hello Andrew,
> > 
> > Thank you for detailed investigation.
> > 
> > >>> On Wed, 20 Dec 2006 16:05:53 JST,  Andrew Johnson <[email protected]>
> > wrote;
> > > Hi Kazuro,
> > >
> > > Kazuro FURUKAWA wrote:
> > > > For Tru64unix...
> > >
> > > > [1] comBuf.h
> > > > I've tried it again without comBuf.h modification.  And I've got
> > > > the following error.  I've changed the compiler features like
> > > > -std {gun,ansi,ms,arm} and they gave me the same results.  I don't
> > > > know why the error occurs, and why my change cures the compilation.
> > > >
> > > > =====
> > > > cxx  -c           -D_OSF_SOURCE -DUNIX   -std gnu -pthread -ieee  -O
> > > > -I. -I.. -I../../../include/os/osf -
> > I../../../include         ../comQueSend.cpp
> > > > cxx: Error: ../../../include/osiWireFormat.h, line 211: Cannot create
> > > >           variable "tmp" of incomplete type "WireAlias<const char *>".
> > > >           detected during:
> > > >             instantiation of "void WireSet(const T &, epicsUInt8 *)
> > [with
> > > >                       T=const char *]" at line 191 of "../comBuf.h"
> > > >             instantiation of
> > > >                       "bool comBuf::push(const T &) [with T=const char
> > *]" at
> > > >                       line 144 of "../comQueSend.h"
> > > >             instantiation of
> > > >                       "void comQueSend::push(const T &) [with T=const
> > char *]"
> > > >                       at line 112 of "../comQueSend.cpp"
> > > >     WireAlias < T > tmp;
> > > > --------------------^
> > > > cxx: Warning: ../comQueSend.cpp, line 327: pointless comparison of
> > unsigned
> > > >           integer with zero
> > > >     if ( INVALID_DB_REQ ( dataType ) ) {
> > > > ---------^
> > > > cxx: Info: 1 error detected in the compilation of "../comQueSend.cpp".
> > > > =====
> > > >
> > > > I've put the full compilation log with above error at
> > > > <URL:http://www-linac.kek.jp/jk/osf/base-3.14.9pr2-make-osf-
> > failed.log>
> > >
> > > Ok, I'm still waiting for a comment from Jeff Hill on your patch and/or
> > > the above compile error - we committed all of your other changes, but
> > > this is Jeff's code so he gets to decide what to do about it.
> > 
> > I understand.  The patch I added is nasty... There should be better
> > approach.
> > 
> > > > [2] snprintf()
> > > > It seems the definition of the return value is different on Tru64.
> > > > It simply returns the length of the buffer.  The buffer contents
> > > > are OK.  The part of the results is like this.
> > > > =====
> > > > not ok  1 - epicsSnprintf(size=1) = 0
> > > > ok  2 - buffer = ''
> > > > ok  3 - length = 0
> > > > not ok  4 - epicsSnprintf(size=2) = 1
> > > > ok  5 - buffer = 'i'
> > > > ok  6 - length = 1
> > > > =====
> > > > The return value should be 46.  We may include a version of free
> > > > snprintf() into the source tree, but...
> > >
> > > According to the C99 standard the return value from snprintf() is
> > > supposed to be the number of characters that would have been written to
> > > the buffer if it were large enough.  We're used to different operating
> > > systems having different semantics for snprintf(), which is why we make
> > > it possible for each architecture to implement their own workaround.
> > >
> > > I'm not aware of any code in Base that will fail with the above issue,
> > > but it would be good to fix this sometime - I won't hold up the R3.14.9
> > > release waiting for it though.
> > 
> > The document on Tru64unix says the current behavior.  Thus, it is a
> > feature, not a bug.  They may have misunderstood the standard, or
> > have followed a draft standard.
> > 
> > I'm thinking about a dirty wrapper around their vsnprintf(), if I
> > have time.
> > 
> > > > [3] timer
> > > > An example of the errore is like this.
> > > > =====
> > > > ./epicsTimerTest
> > > > 1..33
> > > > # Testing timer accuracy
> > > > not ok  1 - percentError < messageThresh
> > > > # delay = 1.000000 s, error = -0.007792 s (0.8 %)
> > > > not ok  2 - percentError < messageThresh
> > > > # delay = 1.100000 s, error = -0.007204 s (0.7 %)
> > > > not ok  3 - percentError < messageThresh
> > > > # delay = 1.200000 s, error = -0.007592 s (0.6 %)
> > > > not ok  4 - percentError < messageThresh
> > > > # delay = 1.300000 s, error = -0.007981 s (0.6 %)
> > > > not ok  5 - percentError < messageThresh
> > > > # delay = 1.400000 s, error = -0.007393 s (0.5 %)
> > > > not ok  6 - percentError < messageThresh
> > > > # delay = 1.500000 s, error = -0.007781 s (0.5 %)
> > > > not ok  7 - percentError < messageThresh
> > > > # delay = 1.600000 s, error = -0.008170 s (0.5 %)
> > > > ok  8 - percentError < messageThresh
> > >
> > > > Without load, software with usleep() or setitimer() normally shows
> > > > 0-2 millisecond accuracy.  So the above discrepancies are large
> > > > compared with my experiences.  We have 7 alpha machines at KEKB
> > > > and Linac.  The numbers of processes are 200 to 600, and the load
> > > > averages are 1 to 15.  The results do not change much between
> > > > machines.  I don't know the origin of the errors.
> > >
> > > I regard the earlier timer tests not so much as an error as a warning,
> > > and since your machines are running signficant numbers of processes I
> > > would not be too worried by the above failures.
> > 
> > [4] LDLIBS
> > I realized another inconsistency, as I tried R3.14-CVS dated
> > Dec.20 for native compiler (namely osf-alpha, instead of osf-alpha-gnu).
> > I should have used the flag -pthread instead of "-D_REENTRANT
> > -lpthread ..." consistently for cc and ld.
> > The rule is correctly followed for STRICT targets but not for
> > others.
> > Also as a side effect(?) -lm is not used in OP_SYS_LDLIBS for some
> > targets.  epicsCalcTest for example fails to build with CVS-source.
> > I had put "USR_SYS_LIBS += m" in CONFIG.Common.osf-alpha as a
> > work-around in my patch, but maybe that is not clean.  I may look
> > in more although I don't yet understand when OP_SYS_LDLIBS is
> > overwritten.
> > 
> > Cheers.
> > -----
> > Kazuro FURUKAWA <[email protected]>
> >  Linac&KEKB,  High Energy Accelerator Research Organization (KEK), Japan
> >  Telephone: +81-29-864-5200 x4316,  Facsimile: +81-29-864-0321
> 

よろしくお願いします。
-----
古川 和朗,  Kazuro FURUKAWA <[email protected]>
 Linac&KEKB,  High Energy Accelerator Research Organization (KEK), Japan
 Telephone: +81-29-864-5200 x4316,  Facsimile: +81-29-864-0321


Replies:
RE: EPICS on Tru64unix and HP-UX Jeff Hill
References:
RE: EPICS on Tru64unix and HP-UX Jeff Hill

Navigate by Date:
Prev: Re: EPICS on Tru64unix and HP-UX Kazuro FURUKAWA
Next: RE: EPICS on Tru64unix and HP-UX Jeff Hill
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: EPICS on Tru64unix and HP-UX Kazuro FURUKAWA
Next: RE: EPICS on Tru64unix and HP-UX Jeff Hill
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·