I guess that LANGLVL(LONGLONG) is already in effect,
because LANGLVL(LONGLONG) is implicitly set with LANGLVL(EXTENDED);
if not, the compiler would not accept the long long declarations, I guess,
and it handles the long long variables in the beginning of the function
as 64 bit values (see the SRAG).
I examined the whole ASSEMBLER resolution of the function, and everything
is fine IMO with the only exception that the shift of the original 64
bit value
in the else part yielding testWord is not present - instead ffs in the
else part
is called with a constant zero parameter.
If this is really the ASSEMBLER resolution of the C source, this is a
compiler
error IMO.
For further examination Charles could maybe send me the compile listing
of this function offline (if it is not too large) - with the LIST option
set.
Or: if this is really a matter of the missing LANGLVL(LONGLONG), we should
see how the ASSEMBLER resolution changes when LANGLVL(LONGLONG)
is added.
Kind regards
Bernd
Am 26.07.2013 01:41, schrieb David Crayford:
I think I see your problem. Try compiling with LANGLVL(LONGLONG).
On 22/07/2013, at 12:17 PM, Charles Mills <charl...@mcn.org> wrote:
Perhaps more to the point, here are my exact options, minus only some
comments:
TARG(LE,zOSV1R9)
# On 1/10/11 Xxxxx Yyyyy wrote that Zzzzz was on z990s
ARCH(6)
# Force most enums to be integers for consistency
ENUMSIZ(INT)
# Test of several optimization options
AGGRCOPY HGPR LIBANSI
# Some new optimization -- suspect these if problem!
ROCONST
# TEST Seems to hose up the linker if CSECT also specified
# Uncomment to show macros -- *** V1R13 and above ***
# SHOWM LIST PPONLY
# Try suppressing the multi-character literal warning for Events
SUPP(CCN5802)
# NODLL may be necessary to make the program COBOL-loadable
NODLL
# XPL(OSCALL(U)) OBJECTMODEL(IBM)
# Set the following based on optimization desired
# 0 and NOINLINE TEST or 2 and INLINE NOTEST
# OPT(0) NOINLINE TEST GONUMBER
OPT(2) INLINE NOTEST NOGONUMBER COMPRESS
# Turn on the LIST option - "pseudo-assembler" listing
# LIST
# Experiment for XXXXXXXX - does not seem to hurt anything
DLL(CBA)
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 8:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
Here is exact cut and paste with zero editing, complete with a typo in the
second comment. The code is unit tested on MS Visual Studio -- hence the two
#ifdef's.
// Find First Set
static inline int Ffs64(unsigned long long valueToTest)
{
// returns index of first set bit. Uses UNIX convention
where bit 1 is LSB of word for compatibilit with z/OS ffs()
static const unsigned long long lswMask =
0x00000000ffffffff;
// note Windows provides a _BitScanForward64() but I did it
this way to make it more z/OS-like for test purposes
// if we ever needed Windows efficiency, or if IBM provides
an ffs64(), then this should be re-written to take advantage
if ( valueToTest == 0 ) return 0;
unsigned int testWord;
testWord = valueToTest & lswMask;
if ( testWord != 0 )
{
// _BitScanForward returns base 0
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+1;
#else
return ffs(testWord);
#endif
}
else
{
testWord = valueToTest >> 32;
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+33;
#else
return ffs(testWord) + 32;
#endif
}
}
I have strong -- but not utterly conclusive; you know what debugging a
complex program is like -- that for the value I had in the OP --
0x0034000000000000? -- the method returns 32, implying that the final ffs()
was called with testWord = 0.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Sunday, July 21, 2013 8:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
I'm struggling to see what is wrong with testWord = valueToTest >> 32.
There are no side effects and the sequence point is at the end of the full
expression. Can anybody enlighten me?
Charles, is the code snippet you supplied the exact test cast that is
resulting in undefined behaviour? I cannot recreate the problem and I've
tried it on five different C++ compilers, including z/OS v1.13.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
