Re: [MVS-OE] Looking for help with an obscure C integer problem

[Charles Mills]

With the constant 0x0034... as a literal in the code the compiler is able to 
short-circuit the shift entirely.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Russell
Sent: Monday, July 22, 2013 5:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem

Well I think it is a bug.
the following source:
#include 
#include 
#include 
#include 
int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n >> 32;

printf( "%08X %08X\n", b);
}


With OPT(0) it generated:
   LARL r5,F'46'
*  {
* uint64_t n = 0x0034LLU;
   IILL r0,H'0'
   IILH r0,H'52'
   ST   r0,n(,r13,160)
   LA   r2,0
   ST   r2,n(,r13,164)
* uint32_t b = n >> 32;
   Lr6,n(,r13,160)
   Lr7,n(,r13,164)
   SRDL r6,32
   LR   r0,r7
   ST   r0,b(,r13,168)
*
* printf( "%08X %08X\n", b);
   Lr15,=V(PRINTF)(,r3,102)
   LR   r4,r5
   LA   r1,#MX_TEMP1(,r13,152)
   ST   r4,#MX_TEMP1(,r13,152)
   ST   r0,#MX_TEMP1(,r13,156)
   BASR r14,r15
   LR   r15,r2

and printed: 0034*0034*

With OPT(3) it generated:
*  {
* uint64_t n = 0x0034LLU;
   IILL r0,H'0'
   IILH r0,H'52'
* uint32_t b = n >> 32;
*
* printf( "%08X %08X\n", b);
   LARL r1,F'26'
   Lr15,=V(PRINTF)(,r3,74)
   ST   r1,#MX_TEMP1(,r13,152)
   ST   r0,#MX_TEMP1(,r13,156)
   LA   r1,#MX_TEMP1(,r13,152)
   BASR r14,r15* {
* uint64_t n = 0x0034LLU;
   IILL r0,H'0'
   IILH r0,H'52'
* uint32_t b = n >> 32;
*
* printf( "%08X %08X\n", b);
   LARL r1,F'26'
   Lr15,=V(PRINTF)(,r3,74)
   ST   r1,#MX_TEMP1(,r13,152)
   ST   r0,#MX_TEMP1(,r13,156)
   LA   r1,#MX_TEMP1(,r13,152)
   BASR r14,r15
*  }
   LA   r15,0

and printed: 0034 *1000*

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

Re: [MVS-OE] Looking for help with an obscure C integer problem

[David Crayford]

No purpose at all. Merely clutching at straws trying to circumvent Charles 
rather baffling problem. It's not uncommon to see casts like that but it is 
unnecessary. Of course going the other way does require casts for conversion. 

unsigned int anUInt = 0xc000;
long long aLongLong = (long long)anUInt << 2; // 0x3 (correct)

C/C++ integral promotion rules can be a pitfall for the novice. 


On 22/07/2013, at 9:23 PM, "retired-mainfra...@q.com" 
 wrote:

> Since the evaluated expression is automatically converted to the type of the 
> left operand aspart of the assignment process, what purpose does the cast 
> serve?
> 
> - Original Message -
> From: "David Crayford" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Saturday, July 20, 2013 8:06:37 PM
> Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
> 
> Your casting a uint64_t to a uint64_t which is pointless. You should 
> cast to the return value (uint32_t).
> 
> I've just tried your example and I can't recreate the problem, with or 
> without casts and compiled with both OPT and NOOPT.
> 
> #include 
> #include 
> #include 
> #include 
> 
> int main( int argc, char **argv )
> {
>   uint64_t n = 0x0034LLU;
>   uint32_t b = n >> 32;
>   uint32_t c = static_cast(n >> 32);
>   printf( "%08X %08X\n", b, c );
> }
> 
> I can only assume that the optimizer is throwing away valueToTest for 
> some arcane reason. I've seen this happen with convoluted code with lots 
> of pointers to pointers etc.
> Try qualifying valueToTest with volatile, which should disable 
> optimizations on that variable.
> 
> On 21/07/2013 8:27 AM, Charles Mills wrote:
>> Hmmm. Not following your logic but I may give it a try.
>> 
>> Charles
>> 
>> -Original Message-----
>> From: MVS OpenEdition [mailto:mvs...@vm.marist.edu] On Behalf Of David
>> Crayford
>> Sent: Saturday, July 20, 2013 4:51 PM
>> To: mvs...@vm.marist.edu
>> Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
>> 
>> If static_cast(valueToTest >> 32) doesn't fix it then the compiler
>> is broken. Note the cast to uint32_t not uint64_t.
>> 
>> On 21/07/2013, at 6:36 AM, Charles Mills  wrote:
>> 
>>> Thanks. How would I solve this with a cast? I can force it to be wrong
>>> LOL but can I force it to be right?
>>> 
>>> It seems to me like testWord = static_cast>> long>(valueToTest
>>>>> 32) might not solve the problem because that cast seems to me to
>>>>> imply
>>> that the expression inside the parentheses is *not* 64 bits.
>>> 
>>> Frankly, I am now leaning toward
>>> 
>>> union {
>>> unsigned long long ll;
>>> struct {unsigned int hi; unsigned int lo} s; } u;
>>> 
>>> u.ll = valueToTest;
>>> 
>>> and then using u.s.hi where I now use testWord.
>>> 
>>> I generally avoid unions because they can be a tad problematic. I
>>> think the above actually violates the C standard which says you can't
>>> assign to member x and then read member y (which pretty much negates
>>> the whole purpose of unions other than, as Stroustrup suggests, saving
>> space in memory).
>>> Charles
>>> 
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>>> On Behalf Of David Crayford
>>> Sent: Saturday, July 20, 2013 2:28 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Looking for help with an obscure C integer problem
>>> 
>>> As a general ROT I always use explicit casts.
>>> 
>>> On 21/07/2013, at 4:24 AM, Charles Mills  wrote:
>>> 
>>>> 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
>>>> 0x0034 then
>>>> 
>>>> - If I compile Opt(0),NoInline then testWord gets the value I expect,
>>>> 0x0034; but
>>>> - If I compile Opt(2),Inline then testWord gets a value of 0.
>>>> 
>>>> Questions:
>>>> 
>>>> 1. 

Re: [MVS-OE] Looking for help with an obscure C integer problem

[John McKown]

I use them so that the reader of the code knows for certain sure that I did
intend to change from one precision to another, with possible loss of
information. Also, I like to compile with all messages enabled and still
get no warnings. I do a fair amount of "unnecessary" coding to get an RC of
0, rather than 4. I'm a bit OCD about that. I compile open source software
on Linux some times and just cringe at all the warnings that are produced.

On Mon, Jul 22, 2013 at 8:23 AM, retired-mainfra...@q.com <
retired-mainfra...@q.com> wrote:

> Since the evaluated expression is automatically converted to the type of
> the left operand aspart of the assignment process, what purpose does the
> cast serve?
>
>
-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

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

Re: [MVS-OE] Looking for help with an obscure C integer problem

[retired-mainfra...@q.com]

Since the evaluated expression is automatically converted to the type of the 
left operand aspart of the assignment process, what purpose does the cast serve?

- Original Message -
From: "David Crayford" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Saturday, July 20, 2013 8:06:37 PM
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem

Your casting a uint64_t to a uint64_t which is pointless. You should 
cast to the return value (uint32_t).

I've just tried your example and I can't recreate the problem, with or 
without casts and compiled with both OPT and NOOPT.

#include 
#include 
#include 
#include 

int main( int argc, char **argv )
{
   uint64_t n = 0x0034LLU;
   uint32_t b = n >> 32;
   uint32_t c = static_cast(n >> 32);
   printf( "%08X %08X\n", b, c );
}

I can only assume that the optimizer is throwing away valueToTest for 
some arcane reason. I've seen this happen with convoluted code with lots 
of pointers to pointers etc.
Try qualifying valueToTest with volatile, which should disable 
optimizations on that variable.

On 21/07/2013 8:27 AM, Charles Mills wrote:
> Hmmm. Not following your logic but I may give it a try.
>
> Charles
>
> -Original Message-
> From: MVS OpenEdition [mailto:mvs...@vm.marist.edu] On Behalf Of David
> Crayford
> Sent: Saturday, July 20, 2013 4:51 PM
> To: mvs...@vm.marist.edu
> Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
>
> If static_cast(valueToTest >> 32) doesn't fix it then the compiler
> is broken. Note the cast to uint32_t not uint64_t.
>
> On 21/07/2013, at 6:36 AM, Charles Mills  wrote:
>
>> Thanks. How would I solve this with a cast? I can force it to be wrong
>> LOL but can I force it to be right?
>>
>> It seems to me like testWord = static_cast> long>(valueToTest
>>>> 32) might not solve the problem because that cast seems to me to
>>>> imply
>> that the expression inside the parentheses is *not* 64 bits.
>>
>> Frankly, I am now leaning toward
>>
>> union {
>> unsigned long long ll;
>> struct {unsigned int hi; unsigned int lo} s; } u;
>>
>> u.ll = valueToTest;
>>
>> and then using u.s.hi where I now use testWord.
>>
>> I generally avoid unions because they can be a tad problematic. I
>> think the above actually violates the C standard which says you can't
>> assign to member x and then read member y (which pretty much negates
>> the whole purpose of unions other than, as Stroustrup suggests, saving
> space in memory).
>> Charles
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of David Crayford
>> Sent: Saturday, July 20, 2013 2:28 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Looking for help with an obscure C integer problem
>>
>> As a general ROT I always use explicit casts.
>>
>> On 21/07/2013, at 4:24 AM, Charles Mills  wrote:
>>
>>> 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
>>> 0x0034 then
>>>
>>> - If I compile Opt(0),NoInline then testWord gets the value I expect,
>>> 0x0034; 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?
> --
> 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

Re: [MVS-OE] Looking for help with an obscure C integer problem

[David Crayford]

The bug is in your code. Your only passing one argument to printf(). 

On 22/07/2013, at 8:38 PM, Tom Russell  wrote:

> Well I think it is a bug.
> the following source:
> #include 
> #include 
> #include 
> #include 
> int main( int argc, char **argv )
> {
>   uint64_t n = 0x0034LLU;
>   uint32_t b = n >> 32;
> 
>   printf( "%08X %08X\n", b);
> }
> 
> 
> With OPT(0) it generated:
>  LARL r5,F'46'
> *  {
> * uint64_t n = 0x0034LLU;
>  IILL r0,H'0'
>  IILH r0,H'52'
>  ST   r0,n(,r13,160)
>  LA   r2,0
>  ST   r2,n(,r13,164)
> * uint32_t b = n >> 32;
>  Lr6,n(,r13,160)
>  Lr7,n(,r13,164)
>  SRDL r6,32
>  LR   r0,r7
>  ST   r0,b(,r13,168)
> *
> * printf( "%08X %08X\n", b);
>  Lr15,=V(PRINTF)(,r3,102)
>  LR   r4,r5
>  LA   r1,#MX_TEMP1(,r13,152)
>  ST   r4,#MX_TEMP1(,r13,152)
>  ST   r0,#MX_TEMP1(,r13,156)
>  BASR r14,r15
>  LR   r15,r2
> 
> and printed: 0034*0034*
> 
> With OPT(3) it generated:
> *  {
> * uint64_t n = 0x0034LLU;
>  IILL r0,H'0'
>  IILH r0,H'52'
> * uint32_t b = n >> 32;
> *
> * printf( "%08X %08X\n", b);
>  LARL r1,F'26'
>  Lr15,=V(PRINTF)(,r3,74)
>  ST   r1,#MX_TEMP1(,r13,152)
>  ST   r0,#MX_TEMP1(,r13,156)
>  LA   r1,#MX_TEMP1(,r13,152)
>  BASR r14,r15* {
> * uint64_t n = 0x0034LLU;
>  IILL r0,H'0'
>  IILH r0,H'52'
> * uint32_t b = n >> 32;
> *
> * printf( "%08X %08X\n", b);
>  LARL r1,F'26'
>  Lr15,=V(PRINTF)(,r3,74)
>  ST   r1,#MX_TEMP1(,r13,152)
>  ST   r0,#MX_TEMP1(,r13,156)
>  LA   r1,#MX_TEMP1(,r13,152)
>  BASR     r14,r15
> *  }
>      LA   r15,0
> 
> and printed: 0034 *1000*
> 
> This is z/OS 1.13.  I am not sure about the C compiler maintenance level, but 
> I can check.
> 
> regards, Tom
> 
> 
> 
> On 2013-07-22 12:00 AM, IBM-MAIN automatic digest system wrote:
>> Date: Sun, 21 Jul 2013 20:42:54 +0800 From: David Crayford 
>>  Subject: Re: [MVS-OE] Looking for help with an obscure 
>> C integer problem On 21/07/2013 8:40 PM, Shmuel Metz (Seymour J.) wrote:
>>> >In<51eb3a4c.8010...@gmail.com>, on 07/21/2013
>>> > at 09:33 AM, David Crayford  said:
>>> >
>>>> >>I don't like it because it's a hack to work around an puzzling
>>>> >>issue. I  want to know why the optimizer is not generating the
>>>> >>correct code.
>>> >Why not report it as a bug?
>>> >
>> We don't know if it is a bug without seeing Charles code asis.
> 
> -- 
> G. Tom Russell
> 
> “Stay calm. Be brave. Wait for the signs.” — Jasper FriendlyBear
> “... and remember to leave good news alone.” — Gracie HeavyHand
> 
> --
> 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

Re: [MVS-OE] Looking for help with an obscure C integer problem

[Tom Russell]

Well I think it is a bug.
the following source:
#include 
#include 
#include 
#include 
int main( int argc, char **argv )
{
   uint64_t n = 0x0034LLU;
   uint32_t b = n >> 32;

   printf( "%08X %08X\n", b);
}


With OPT(0) it generated:
  LARL r5,F'46'
*  {
* uint64_t n = 0x0034LLU;
  IILL r0,H'0'
  IILH r0,H'52'
  ST   r0,n(,r13,160)
  LA   r2,0
  ST   r2,n(,r13,164)
* uint32_t b = n >> 32;
  Lr6,n(,r13,160)
  Lr7,n(,r13,164)
  SRDL r6,32
  LR   r0,r7
  ST   r0,b(,r13,168)
*
* printf( "%08X %08X\n", b);
  Lr15,=V(PRINTF)(,r3,102)
  LR   r4,r5
  LA   r1,#MX_TEMP1(,r13,152)
  ST   r4,#MX_TEMP1(,r13,152)
  ST   r0,#MX_TEMP1(,r13,156)
  BASR r14,r15
  LR   r15,r2

and printed: 0034*0034*

With OPT(3) it generated:
*  {
* uint64_t n = 0x0034LLU;
  IILL r0,H'0'
  IILH r0,H'52'
* uint32_t b = n >> 32;
*
* printf( "%08X %08X\n", b);
  LARL r1,F'26'
  Lr15,=V(PRINTF)(,r3,74)
  ST   r1,#MX_TEMP1(,r13,152)
  ST   r0,#MX_TEMP1(,r13,156)
  LA   r1,#MX_TEMP1(,r13,152)
  BASR r14,r15* {
* uint64_t n = 0x0034LLU;
  IILL r0,H'0'
  IILH r0,H'52'
* uint32_t b = n >> 32;
*
* printf( "%08X %08X\n", b);
  LARL r1,F'26'
  Lr15,=V(PRINTF)(,r3,74)
  ST   r1,#MX_TEMP1(,r13,152)
  ST   r0,#MX_TEMP1(,r13,156)
  LA   r1,#MX_TEMP1(,r13,152)
  BASR r14,r15
*  }
  LA   r15,0

and printed: 0034 *1000*

This is z/OS 1.13.  I am not sure about the C compiler maintenance 
level, but I can check.


regards, Tom



On 2013-07-22 12:00 AM, IBM-MAIN automatic digest system wrote:
Date: Sun, 21 Jul 2013 20:42:54 +0800 From: David Crayford 
 Subject: Re: [MVS-OE] Looking for help with an 
obscure C integer problem On 21/07/2013 8:40 PM, Shmuel Metz (Seymour 
J.) wrote:

>In<51eb3a4c.8010...@gmail.com>, on 07/21/2013
> at 09:33 AM, David Crayford  said:
>

>>I don't like it because it's a hack to work around an puzzling
>>issue. I  want to know why the optimizer is not generating the
>>correct code.

>Why not report it as a bug?
>

We don't know if it is a bug without seeing Charles code asis.


--
G. Tom Russell

“Stay calm. Be brave. Wait for the signs.” — Jasper FriendlyBear
“... and remember to leave good news alone.” — Gracie HeavyHand

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

Re: [MVS-OE] Looking for help with an obscure C integer problem

[Charles Mills]

That was my attitude last time. No, I am not the least worried about 
competitors. One, it's a big world with room for everyone; two, the two 
products I work on have no head-to-head competition; and three, my impression 
is that an awful lot of Z commercial products are written in assembler, not C.

I am just worried about my own time and sanity. In any event, even if I were to 
spend a bunch of my life arguing my case with IBM, I *need* a timely solution.

You can't push a piece of string. I have lost patience with being more generous 
to IBM's customers than IBM is. They seem not to want to fix the "problem" 
(however that might be defined) so much as make their numbers by closing the 
ticket. IMHO. At least the level one folks; much less so once you get through 
to someone who knows anything.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Sunday, July 21, 2013 7:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem

On Sun, 21 Jul 2013 07:08:08 -0700, Charles Mills wrote:

>Went that route on the last C compiler problem I found. Life is too short.
>Or at the very least, the project deadline is too short.
> 
View it as an act of generosity to others who may encounter the problem.
Of course, if they're likely to be your competitors you may be disinclined to 
be generous.

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

Re: [MVS-OE] Looking for help with an obscure C integer problem

[Paul Gilmartin]

On Sun, 21 Jul 2013 07:08:08 -0700, Charles Mills wrote:

>Went that route on the last C compiler problem I found. Life is too short.
>Or at the very least, the project deadline is too short.
> 
View it as an act of generosity to others who may encounter the problem.
Of course, if they're likely to be your competitors you may be disinclined
to be generous.

-- gil

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

Re: [MVS-OE] Looking for help with an obscure C integer problem

[Charles Mills]

Went that route on the last C compiler problem I found. Life is too short.
Or at the very least, the project deadline is too short.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: Sunday, July 21, 2013 5:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem

In <51eb3a4c.8010...@gmail.com>, on 07/21/2013
   at 09:33 AM, David Crayford  said:

>I don't like it because it's a hack to work around an puzzling issue. I  
>want to know why the optimizer is not generating the correct code.

Why not report it as a bug? 

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

Re: [MVS-OE] Looking for help with an obscure C integer problem

[David Crayford]

On 21/07/2013 8:40 PM, Shmuel Metz (Seymour J.) wrote:

In <51eb3a4c.8010...@gmail.com>, on 07/21/2013
at 09:33 AM, David Crayford  said:


I don't like it because it's a hack to work around an puzzling
issue. I  want to know why the optimizer is not generating the
correct code.

Why not report it as a bug?


We don't know if it is a bug without seeing Charles code asis.

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

Re: [MVS-OE] Looking for help with an obscure C integer problem

[Shmuel Metz (Seymour J.)]

In <51eb3a4c.8010...@gmail.com>, on 07/21/2013
   at 09:33 AM, David Crayford  said:

>I don't like it because it's a hack to work around an puzzling 
>issue. I  want to know why the optimizer is not generating the
>correct code.

Why not report it as a bug? 

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: [MVS-OE] Looking for help with an obscure C integer problem

[David Crayford]

I don't like it because it's a hack to work around an puzzling  issue. I 
want to know why the optimizer is not generating the correct code. It's 
disconcerting and I've experienced it myself,
but only in situations where the code was convoluted (double pointers 
and casts). I ended up rewriting that code! The optimizer takes no 
prisoners. In my experience it finds bugs.


On 21/07/2013 9:24 AM, Charles Mills wrote:

Okay. What do you think of the union approach?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Saturday, July 20, 2013 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem

Your casting a uint64_t to a uint64_t which is pointless. You should cast to
the return value (uint32_t).

I've just tried your example and I can't recreate the problem, with or
without casts and compiled with both OPT and NOOPT.

#include 
#include 
#include 
#include 

int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n >> 32;
uint32_t c = static_cast(n >> 32);
printf( "%08X %08X\n", b, c );
}

I can only assume that the optimizer is throwing away valueToTest for some
arcane reason. I've seen this happen with convoluted code with lots of
pointers to pointers etc.
Try qualifying valueToTest with volatile, which should disable optimizations
on that variable.

--
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

Re: [MVS-OE] Looking for help with an obscure C integer problem

[Charles Mills]

Okay. What do you think of the union approach?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Saturday, July 20, 2013 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem

Your casting a uint64_t to a uint64_t which is pointless. You should cast to
the return value (uint32_t).

I've just tried your example and I can't recreate the problem, with or
without casts and compiled with both OPT and NOOPT.

#include 
#include 
#include 
#include 

int main( int argc, char **argv )
{
   uint64_t n = 0x0034LLU;
   uint32_t b = n >> 32;
   uint32_t c = static_cast(n >> 32);
   printf( "%08X %08X\n", b, c );
}

I can only assume that the optimizer is throwing away valueToTest for some
arcane reason. I've seen this happen with convoluted code with lots of
pointers to pointers etc.
Try qualifying valueToTest with volatile, which should disable optimizations
on that variable.

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

Re: [MVS-OE] Looking for help with an obscure C integer problem

[David Crayford]

Your casting a uint64_t to a uint64_t which is pointless. You should 
cast to the return value (uint32_t).


I've just tried your example and I can't recreate the problem, with or 
without casts and compiled with both OPT and NOOPT.


#include 
#include 
#include 
#include 

int main( int argc, char **argv )
{
  uint64_t n = 0x0034LLU;
  uint32_t b = n >> 32;
  uint32_t c = static_cast(n >> 32);
  printf( "%08X %08X\n", b, c );
}

I can only assume that the optimizer is throwing away valueToTest for 
some arcane reason. I've seen this happen with convoluted code with lots 
of pointers to pointers etc.
Try qualifying valueToTest with volatile, which should disable 
optimizations on that variable.


On 21/07/2013 8:27 AM, Charles Mills wrote:

Hmmm. Not following your logic but I may give it a try.

Charles

-Original Message-
From: MVS OpenEdition [mailto:mvs...@vm.marist.edu] On Behalf Of David
Crayford
Sent: Saturday, July 20, 2013 4:51 PM
To: mvs...@vm.marist.edu
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem

If static_cast(valueToTest >> 32) doesn't fix it then the compiler
is broken. Note the cast to uint32_t not uint64_t.

On 21/07/2013, at 6:36 AM, Charles Mills  wrote:


Thanks. How would I solve this with a cast? I can force it to be wrong
LOL but can I force it to be right?

It seems to me like testWord = static_cast(valueToTest

32) might not solve the problem because that cast seems to me to
imply

that the expression inside the parentheses is *not* 64 bits.

Frankly, I am now leaning toward

union {
unsigned long long ll;
struct {unsigned int hi; unsigned int lo} s; } u;

u.ll = valueToTest;

and then using u.s.hi where I now use testWord.

I generally avoid unions because they can be a tad problematic. I
think the above actually violates the C standard which says you can't
assign to member x and then read member y (which pretty much negates
the whole purpose of unions other than, as Stroustrup suggests, saving

space in memory).

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of David Crayford
Sent: Saturday, July 20, 2013 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem

As a general ROT I always use explicit casts.

On 21/07/2013, at 4:24 AM, Charles Mills  wrote:


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
0x0034 then

- If I compile Opt(0),NoInline then testWord gets the value I expect,
0x0034; 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?

--
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

Re: [MVS-OE] Looking for help with an obscure C integer problem

[Charles Mills]

Hmmm. Not following your logic but I may give it a try.

Charles

-Original Message-
From: MVS OpenEdition [mailto:mvs...@vm.marist.edu] On Behalf Of David
Crayford
Sent: Saturday, July 20, 2013 4:51 PM
To: mvs...@vm.marist.edu
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem

If static_cast(valueToTest >> 32) doesn't fix it then the compiler
is broken. Note the cast to uint32_t not uint64_t. 

On 21/07/2013, at 6:36 AM, Charles Mills  wrote:

> Thanks. How would I solve this with a cast? I can force it to be wrong 
> LOL but can I force it to be right?
> 
> It seems to me like testWord = static_cast long>(valueToTest
>>> 32) might not solve the problem because that cast seems to me to 
>>> imply
> that the expression inside the parentheses is *not* 64 bits.
> 
> Frankly, I am now leaning toward
> 
> union {
> unsigned long long ll;
> struct {unsigned int hi; unsigned int lo} s; } u;
> 
> u.ll = valueToTest;
> 
> and then using u.s.hi where I now use testWord.
> 
> I generally avoid unions because they can be a tad problematic. I 
> think the above actually violates the C standard which says you can't 
> assign to member x and then read member y (which pretty much negates 
> the whole purpose of unions other than, as Stroustrup suggests, saving
space in memory).
> 
> Charles
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of David Crayford
> Sent: Saturday, July 20, 2013 2:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Looking for help with an obscure C integer problem
> 
> As a general ROT I always use explicit casts.
> 
> On 21/07/2013, at 4:24 AM, Charles Mills  wrote:
> 
>> 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
>> 0x0034 then
>> 
>> - If I compile Opt(0),NoInline then testWord gets the value I expect, 
>> 0x0034; 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?

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