Re: [MVS-OE] Looking for help with an obscure C integer problem
Well I think it is a bug.
the following source:
#include stdio.h
#include stdlib.h
#include stdint.h
#include string.h
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
dcrayf...@gmail.com 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:
In51eb3a4c.8010...@gmail.com, on 07/21/2013
at 09:33 AM, David Crayforddcrayf...@gmail.com 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
The bug is in your code. Your only passing one argument to printf().
On 22/07/2013, at 8:38 PM, Tom Russell tom_russ...@sympatico.ca wrote:
Well I think it is a bug.
the following source:
#include stdio.h
#include stdlib.h
#include stdint.h
#include string.h
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
dcrayf...@gmail.com 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:
In51eb3a4c.8010...@gmail.com, on 07/21/2013
at 09:33 AM, David Crayforddcrayf...@gmail.com 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
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 dcrayf...@gmail.com
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 stdio.h
#include stdlib.h
#include stdint.h
#include string.h
int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n 32;
uint32_t c = static_castuint32_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.
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_castuint32_t(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 charl...@mcn.org 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_castunsigned long
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 charl...@mcn.org 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
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
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
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 dcrayf...@gmail.com
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 stdio.h
#include stdlib.h
#include stdint.h
#include string.h
int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n 32;
uint32_t c = static_castuint32_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.
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_castuint32_t(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 charl...@mcn.org 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_castunsigned long
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 charl...@mcn.org 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
Re: [MVS-OE] Looking for help with an obscure C integer problem
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 stdio.h
#include stdlib.h
#include stdint.h
#include string.h
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
In 51eb3a4c.8010...@gmail.com, on 07/21/2013 at 09:33 AM, David Crayford dcrayf...@gmail.com 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/2http://patriot.net/~shmuel 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
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 dcrayf...@gmail.com 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
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 dcrayf...@gmail.com 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
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
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_castuint32_t(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 charl...@mcn.org 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_castunsigned long
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 charl...@mcn.org 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
Re: [MVS-OE] Looking for help with an obscure C integer problem
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 = 0x0034LLU;
uint32_t b = n 32;
uint32_t c = static_castuint32_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
Re: [MVS-OE] Looking for help with an obscure C integer problem
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 = 0x0034LLU;
uint32_t b = n 32;
uint32_t c = static_castuint32_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
