BTW:

I think I remember from an old book on C programming:

"if the target of an assignment is int, all operands on the right side
are converted to int - if the target of an assignment is long, all operands
on the right side are converted to long"

If I remember correctly, this would perfectly explain the behaviour you see
(of course, it makes more sense for data types being shorter than the
type of the assignment target, but if it's done as written above, you have it
for longer types, too).

Kind regards

Bernd




Am 21.07.2013 18:32, schrieb Bernd Oppolzer:
Sorry for jumping late into this thread.

Why not spend another variable of type long long to do the shift there?

like

unsigned long long valueToTest;
unsigned int testWord;
unsigned long long x;

x = valueToTest >> 32;   /* here */
testWord = (int) x;


If now in the expression marked with /* here */ the compiler
does not do the shift as a true 64 bit shift, there is no excuse
and you should report this as a bug. The cast to int is done
in the next statement.

In the other case there may be some strange language rules
that allow the long long variable to be casted to int before the
shift - I don't know, but why lose time and think much about it?

Kind regards

Bernd




Am 20.07.2013 22:24, schrieb Charles Mills:
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


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to