IBM Z and LinuxONE IBM Z

  • 1.  XLC complains CCN3277, CCN3485, CCN3045 but gcc on z/Linux does not complain

    Posted Wed January 19, 2022 08:06 AM
    Hi,

    Trying to compile a program on OMVS. The same code compile fine on z/Linux with gcc . Run the same compile on OMVS using XLC and XLC chocks with;

    ERROR CCN3277 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:58    Syntax error: possible missing ';' or ','?
    ERROR CCN3485 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:57    Parameter declaration list is incompatible with declarator for inline.
    ERROR CCN3045 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:67    Undeclared identifier pp.
    ERROR CCN3277 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:76    Syntax error: possible missing ';' or ','?
    ERROR CCN3485 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:75    Parameter declaration list is incompatible with declarator for inline.
    ERROR CCN3045 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:100   Undeclared identifier ip.
    ERROR CCN3045 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:100   Undeclared identifier size.
    ERROR CCN3277 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:170   Syntax error: possible missing ';' or ','?
    ERROR CCN3485 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:169   Parameter declaration list is incompatible with declarator for inline.
    ERROR CCN3045 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:177   Undeclared identifier pp.
    ERROR CCN3277 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:185   Syntax error: possible missing ';' or ','?
    ERROR CCN3485 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:184   Parameter declaration list is incompatible with declarator for inline.
    ERROR CCN3045 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:193   Undeclared identifier ppp.
    ERROR CCN3277 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:198   Syntax error: possible missing ';' or ','?
    ERROR CCN3485 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:198   Parameter declaration list is incompatible with declarator for inline.
    ERROR CCN3045 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:199   Undeclared identifier p.
    ERROR CCN3277 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:208   Syntax error: possible missing ';' or ','?
    ERROR CCN3485 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:207   Parameter declaration list is incompatible with declarator for inline.
    ERROR CCN3045 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:238   Undeclared identifier p.
    ERROR CCN3045 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:239   Undeclared identifier pptr.
    ERROR CCN3277 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:244   Syntax error: possible missing ';' or ','?
    ERROR CCN3485 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:243   Parameter declaration list is incompatible with declarator for inline.
    ERROR CCN3045 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:253   Undeclared identifier p.
    ERROR CCN3045 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:253   Undeclared identifier off.
    ERROR CCN3045 /u/tonyi/svn/branches/18.0/svn/apl/allos/src/p_macros.h:254   Undeclared identifier len.

    The p_macros.h file is;  Note I have only highlighted the first coupler of errors 


    #ifndef _P_MACROS_H
    #define _P_MACROS_H


    #define SPOCKS_SZ 0

    #define initlarg(htype) initsget(&LARG,&kLarg,htype)
    #define initlargx(htype,dmx) initsgetx(&LARG,&kLarg,htype,dmx)
    #define initrarg(htype) initsget(&RARG,&kRarg,htype)
    #define initrargx(htype,dmx) initsgetx(&RARG,&kRarg,htype,dmx)
    #define inittemp(htype) initsget(&TEMP,&kTemp,htype)
    #define inittempx(htype,dmx) initsgetx(&TEMP,&kTemp,htype,dmx)
    #define initsptr(S) ((S)->ptr.sp=(S)->firstelt.sp,(S)->boolmask=initbool)


    #define relqref(ppp) (--(*ppp)->REFCOUNT, *ppp = 0)


    #define relQref(ppp) \
    { \
    if (*ppp) \
    { \
    if (--(*(ppp))->REFCOUNT) \
    *(ppp) = 0; \
    else \
    { \
    ++(*(ppp))->REFCOUNT; \
    relpref(ppp); \
    } \
    } \
    }

    #define MIN_PTR 512
    // double coercion below is just for the benefit of the wsdump code
    #define ispntr(P) ((UPTR)(uintptr_t)(P) >= MIN_PTR)

    #if !AP_BUILD && !BRIDGE_BUILD


    extern void _relpref(PP *pptr);

    static FORCEINLINE void relpock(PP *pp)                    // stmt 57
    {                                                                                       // stmt 58
    if (*pp)
    _relpref(pp);
    }



    static FORCEINLINE void relkeep(PP *pp)
    {
    if (*pp)                                                           //stmt 67
    {
    ((KEEPSTR*)pp)->keeptr.cp = 0; // zap PTR
    ((KEEPSTR*)pp)->keepsp = 0; // zap SERIAL*.
    _relpref(pp);
    }
    }

    static FORCEINLINE void relpref(PP *pp)
    {                                                                                       // stmt 76                                                             
    if (ispntr(*pp))
    {
    if (pp > &KEEP(0) && pp <= &KEEP(NKEEPS - 1)) // It's a KEEP,
    {
    ((KEEPSTR*)pp)->keeptr.cp = 0; // zap PTR
    ((KEEPSTR*)pp)->keepsp = 0; // zap SERIAL*.
    }
    _relpref(pp);
    }
    else *pp=0;
    }

    ////////////////////////////////////////////////////////////////////////////////
    //      //
    // Low-level heap-manager (aka memory-manager) pocket-release code.      //
         //
    #if SPOCKS_SZ
    extern void add_spock (MEMORYINT *p); // memory1.h not yet included

    extern void wsptr_dragback(MEMORYINT *ip, MEMORYINT size);
    static FORCEINLINE void mm_free(MEMORYINT *ip, MEMORYINT size)      //
    {      //
    *ip = size;      //
    wsptr_dragback(ip,size);
    (void)MM_GUI_FREED(ip,size);
    #if SPOCKS_SZ
    if (size <= SPOCKS_SZ)
    add_spock (ip);
    }      //
         //
    ////////////////////////////////////////////////////////////////////////////////

    #endif //!AP_BUILD && !BRIDGE_BUILD

    #define rellarg() relkeep(&Larg)
    #define relrarg() relkeep(&Rarg)
    #define reltemp() relkeep(&Temp)
    #define relrslt() relkeep(&Rslt)
    #define reldesp() relpref(&DESPERATE)

    #define pocktyp(pock) ((pock)->TYPE)
    #define typesym(pock) ((pock)->TYPE==TYPESYMBOL)
    #define typefun(pock) ((pock)->TYPE==TYPEDEFUNCT)
    #define typefptr(pock) ((pock)->TYPE==TYPEFPTR)
    #define typegen(pock) ((pock)->TYPE==TYPEGEN)
    #define typesim(pock) ((pock)->TYPE==TYPESIMPLE)

    #define DUP(to,from) ++(*(to) = *(from))->REFCOUNT
    #define DUPV(to,from) ++(*(to) =  (from))->REFCOUNT
    #define DUPC(to,from) (from) ? ++(*(to) =  (from))->REFCOUNT : 0

    #if !AP_BUILD && !_MANAGED && !defined(JAVA_BRIDGE)

    extern BOUND bndcalc(MEMORYUNS rank,BOUND *sptr);
    extern unsigned int IsRef(PP ref);

    #define Bound1(p) ((p)->SHAPETC[affirm ((p)->RANK == 1), 0])
    #define Bound01(p) ((p)->RANK==0?1:Bound1(p))

    #define Bound(p) ((p) ? (IsRef(p)?1:fast_bndcalc(p)) : 0)

    #endif //!AP_BUILD && !_MANAGED

    #if WANT_REFCOUNTS && !BRIDGE_BUILD

    //////////////////////////////////////////////////////////////////
    // //
    // note the use of PP macros/functions: //
    // //
    // ref(PP) bump refcount and return ptr to value. //
    // zap(PP) zero ptr and return its old value. //
    // rel(PP) release lvalue and return ptr to its addr. //
    // //
    // eg: //
    // Temp = ref(Larg); // DUPV(&Temp, Larg); //
    // Temp = zap(Larg); // MOVEPP(Temp, Larg); //
    // rel(Temp) = ref(Larg); // reltemp(), DUVP(&Temp, Larg);//
    // //
    // refc() is a conditional version of ref(), //
    // which can accommodate non-ptr args. //
    // //
    //////////////////////////////////////////////////////////////////

    #if AP_BUILD

    extern C_EXTERN void relpref(PP *pp);    // DWA has no direct access to relpref/_relpref needs to call back
    // into the interpreter

    static FORCEINLINE PP ref(PP pp) // DUPV(&to,fm)  => to=ref(fm)
    {
    ++pp->REFCOUNT;
    return pp;
    }

    static FORCEINLINE PP refc(PP pp) // DUPC(&to,fm)  => to=ref(fm)
    {
    return ispntr(pp) ? ref(pp) : pp;
    }

    #define zap(pp) _zap(&(pp)) // MOVEPP(to,fm) => to=zap(fm)

    #define rel(pp) (*_rel(&(pp))) // e.g. rel(Larg)=ref(p)

    static FORCEINLINE PP *_rel(PP *ppp)
    {
    if (ispntr(*ppp))
    relpref(ppp);
    return ppp;
    }

    static FORCEINLINE PP _zap(PP *ppp)
    {
    PP pp = *ppp;
    *ppp = 0;
    return pp;
    }

    static FORCEINLINE void reset_nonsquoze(PP p) { p->SORTED_UP = p->SORTED_DOWN = 0; }
    static FORCEINLINE void reset_flags(PP p) { p->SQUOZE = 0; reset_nonsquoze(p); }
    #define reuse_arr(pp) (reset_flags(pp), zap(pp))
    #define reuse_keepsquoze(pp) (reset_nonsquoze(pp), zap(pp))

    #if !AP_BUILD // APs don't know about keeps

    #define zapk(pp) _zapk(&(pp))

    static FORCEINLINE PP _zapk(PP *ppp)
    {
    PP pp;
    ZAPSP(*ppp);
    pp = *ppp;
    *ppp = 0;
    return pp;
    }

    #endif // !AP_BUILD

    //////////////////////////////////////////////////////////////////////////
    // //
    // The following (inlined) fn should be slightly slicker than a macro, //
    // Only WE know that relpref can't move pptr;    the optimiser //
    // would have to evaluate pptr twice. //
    // //
    //////////////////////////////////////////////////////////////////////////

    // GRS 2017-08-18. This code is dubious in a number of ways.
    // 1. relpref is sensitive to REFCOUNT values and the pre-increment could
    //   cause issues
    // 2. Whereas relpref worries about KEEPs it does not worry about LOCALP
    //   both have pointers to SERIAL.
    // I tried a version that allocated a local PP and relpref'd that. However,
    // 1. Windows compiler thought that might change 4 bytes beyond (because it
    //   might be a KEEP
    // 2. If it really was a KEEP it would not do the necessary with KEEPSP

    static FORCEINLINE void REPLACE(PP *pptr, PP p)
    {
    ++p->REFCOUNT;  // pre-increment in case *pptr==p
    relpref(pptr);
    *pptr = p;
    }

    static FORCEINLINE void REPLACEC(PP *pptr, PP p)
    {
    if (ispntr(p)) ++p->REFCOUNT;   // pre-increment in case *pptr==p
    relpref(pptr);
    *pptr = p;
    }


    static INLINE void increfs(PP p, BOUND off, BOUND len)
    {
    PP *refs = p->PSHAPETC + off;
    for (BOUND i=0; i<len; i++)
    ref(refs[i]);
    }
    #define increfs_coalesce(pock, off, len) do { \
    increfs(pock, off, len);      \
    coalesce(&pock);              \
    } while (0)

    #endif // WANT_REFCOUNTS

    #endif // _P_MACROS_H



    Now I am almost bald with frustration over this. So if anybody can shed any light onto what the problem is or why XLC gets upset, please, please enlighten me.

    Thanks in advance

    Tony Innes


  • 2.  RE: XLC complains CCN3277, CCN3485, CCN3045 but gcc on z/Linux does not complain

    Posted Wed January 19, 2022 10:32 AM
    Hi, Tony,

    is it possible that you're using different versions of the C standard?

    You can find the parameters of GCC to define the version of C being used here:

    C Dialect Options (Using the GNU Compiler Collection (GCC))
    Gnu remove preview
    C Dialect Options (Using the GNU Compiler Collection (GCC))
    The following options control the dialect of C (or languages derived from C, such as C++, Objective-C and Objective-C++) that the compiler accepts: In C mode, this is equivalent to -std=c90. In C++ mode, it is equivalent to-std=c++98.
    View this on Gnu >


    The corresponding options in XLC you can find here:

    LANGLVL
    Ibm remove preview
    LANGLVL
    View this on Ibm >


    Yours,

    VB.



    ------------------------------
    Volker Birk
    p≡p project
    https://pEp.software
    ------------------------------

    Original Message


  • 3.  RE: XLC complains CCN3277, CCN3485, CCN3045 but gcc on z/Linux does not complain

    Posted Thu January 20, 2022 08:28 AM
    Hi Volker, 
    As I stated I am using IBM's XLC compiler. I am running on z/OS OMVS platform.

    Thanks for replying.

    Tony

    ------------------------------
    Tony Innes
    ------------------------------

    Original Message


  • 4.  RE: XLC complains CCN3277, CCN3485, CCN3045 but gcc on z/Linux does not complain

    Posted Thu January 20, 2022 12:51 PM

    Then what gcc (or MS, for that matter) does is irrelevant. You have to take these errors one at a time and resolve them.

     

    Charles

     




    Original Message


  • 5.  RE: XLC complains CCN3277, CCN3485, CCN3045 but gcc on z/Linux does not complain

    Posted Thu January 20, 2022 04:08 PM
    Hi Charles.

    Thanks for this, but what errors do you see, All the errors are listed and I do not see one that I understand.

    Regards
    Tony

    ------------------------------
    Tony Innes
    ------------------------------

    Original Message


  • 6.  RE: XLC complains CCN3277, CCN3485, CCN3045 but gcc on z/Linux does not complain

    Posted Fri January 21, 2022 04:23 AM
    Given the pattern of the error messages I would suspect that your z/OS compilation environment lacks a macro definition for the FORCEINLINE symbol.
    I would be inclined to perform a command line compilation of just this file, using the -E switch, for force just the preprocessor to run. This will write the preprocessed form of the file to the standard output stream, so you will want to redirect that to a file (it will be huge as all of the includes will be pulled in). Then compile this generated file and go and look at the actual source being compiled after preprocessing for the location that the error occurs. If you are still seeing references in the error messages to the original source then you will need to remove the #line statements from the preprocessed source, I am not sure if xlC puts them in when invoked with the -E switch. Looking at the actual source that is being compiled will give you a hint as to the nature of the issue. If you are seeing the FORCEINLINE symbol in the preprocessed source then this is the issue, it is not part of standard C++ and needs to be defined appropriately.
    ​​​

    ------------------------------
    Chris Hill
    ------------------------------

    Original Message


  • 7.  RE: XLC complains CCN3277, CCN3485, CCN3045 but gcc on z/Linux does not complain

    Posted Fri January 21, 2022 12:55 PM
    Is GCC available for OMVS?

    ------------------------------
    Ron Hilton
    CEO
    Proximal Systems Corporation
    Holladay UT
    8012720058
    ------------------------------

    Original Message


  • 8.  RE: XLC complains CCN3277, CCN3485, CCN3045 but gcc on z/Linux does not complain

    IBM Champion
    Posted Fri January 21, 2022 12:58 PM
    Hi Tony,

    On z/Linux, why don't you dump out the value for FORCEINLINE then create a #define in your code on OMVS at the very top, above your #includes for FORCEINLINE with the same value.  That should shut-up XLC.

    later
    Roger

    ​​​

    ------------------------------
    Roger Lacroix
    CTO
    Capitalware Inc.
    London ON Canada
    https://capitalware.com
    ------------------------------

    Original Message


  • 9.  RE: XLC complains CCN3277, CCN3485, CCN3045 but gcc on z/Linux does not complain

    Posted Tue January 25, 2022 02:48 PM
    Edited by Milos Lalovic Tue January 25, 2022 03:06 PM
    Hi Tony,

    It seems that PP type is not defined so the compiler can not determine the type of pp variable, hence the error "Undeclared identifier pp."
    Make sure PP is defined before the first reference. Also, try passing -DFORCEINLINE=_Inline on the command line that invokes the compiler.


    ------------------------------
    Milos Lalovic
    Software Developer
    IBM Canada
    Markham, Ontario
    (905) 413-3675
    ------------------------------

    Original Message