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 <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <string.h>
int main( int argc, char **argv )
{
uint64_t n = 0x0034000000000000LLU;
uint32_t b = n >> 32;
uint32_t c = static_cast<uint32_t>(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
