Charles,
Hi, here is my opinion (and this definitely falls under the category of
"obscure C"):
You are not considering the implications of "sequence points" in your C/C++.
"Sequence points" should not be confused with "operator precedence." Operator
precedence is determinate, sequence points are not.
I believe IBM XLC is at the C++11 level of C/C++. The C/C++ level is relevant
here because there are sometimes subtle, and sometimes not so subtle,
differences in how sequence points apply between various levels of C++.
While C++11 (the most recent level of C/C++) seems to a have only tiny, mostly
irrelevant and evolutionary changes from prior levels of C/C++; there are
significant differences in how "sequence points" are defined and effect
execution.
Still, C++11 and the level of the C/C++ compiler that is compiling your program
is only tangential to the situation you describe. Your code will execute with
undefined behavior regardless of what compiler you use. But, knowing the level
of the C/C++ compiler may be important if you wish to reconcile why it behaves
one way sometimes and other ways other times (e.g. on a different z/OS).
To me, your failure to consider the subtle impact of sequence points renders
your code ambiguous and subject to undefined behavior. This manifests itself,
for example, by executing differently when optimized. It is at the compiler's
and optimizer's discretion to decide the order of execution for code that the
C++ standard does not specifically define. This includes overlapping execution.
I think the C/C++ compiler and optimizer are working exactly as specified by
applicable ISO/IEC standards.
"The fault, dear Brutus, it not in our stars,But, in ourselves, that we are
underlings"
Cassius in Shakespeare's Julius Caesar
Harry
> Date: Sat, 20 Jul 2013 13:24:29 -0700
> From: charl...@mcn.org
> Subject: Looking for help with an obscure C integer problem
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Cross-posted to IBM-MAIN and MVS-OE.
>
> I have the following code fragment in an inline function, compiled by the
> IBM XLC compiler as C++:
>
> unsigned long long valueToTest;
> unsigned int testWord;
> testWord = valueToTest >> 32;
>
> It *appears* to me (from somewhat circumstantial evidence in a much more
> complex big picture) when valueToTest has a value of 0x0034000000000000 then
>
> - If I compile Opt(0),NoInline then testWord gets the value I expect,
> 0x00340000; but
> - If I compile Opt(2),Inline then testWord gets a value of 0.
>
> Questions:
>
> 1. Does that seem plausible? That the code would work as intended
> Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am
> guessing here) first cast valueToTest to an int of 0, then shift it right
> 32, and then assign it to testWord?
>
> 2. What should I code to avoid that? I guess I could shift valueToTest first
> (I don't need it again) and then in a separate statement assign it to
> testWord. Is that the "proper" coding technique?
>
> It's fairly involved to test the whole thing so I took the liberty of
> imposing on you folks rather than just trying stuff. Thanks much.
>
> Charles
>
> ----------------------------------------------------------------------
> 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
