Hmmm. Well, I beat the compiler into submission but I kind of wonder if this
is correct. Perhaps. It was apparently doing 32-bit arithmetic before
because 0x1 is implicitly a 32-bit value. I changed it to 0x1ull (and
unsigned 64-bit '1') and it works.
I changed the statement to
unsigned long long maxBit = 0x1ull << (arraySize-3);
Now it compiles in a way that is likely to work:
* unsigned long long maxBit = 0x1ull << (arraySize-3);
EX r0,HOOK..STMT
L r1,arraySize(,r13,240)
AHI r1,H'-3'
LA r2,0
LA r3,1
SLDL r2,0(r1)
LR r0,r3
LR r1,r2
ST r1,maxBit(,r13,248)
ST r0,maxBit(,r13,252)
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Charles Mills
Sent: Thursday, May 08, 2014 3:16 PM
To: [email protected]
Subject: Another C compiler shift bug?
Am I missing something here? Consider the following C statement:
unsigned long long maxBit = 0x1 << (arraySize-3);
When arraySize is 66, maxBit is ending up as zero (instead of what I would
expect, X'8000000000000000'. Am I missing something?
Here is the LIST output. (No optimization.)
* unsigned long long maxBit = 0x1 << (arraySize-3);
EX r0,HOOK..STMT
L r1,arraySize(,r13,240)
AHI r1,H'-3'
LA r2,1
LR r0,r2
SLL r0,0(r1)
LR r1,r0
SRA r1,31
ST r1,maxBit(,r13,248)
ST r0,maxBit(,r13,252)
Won't SLL R0,0(R1) yield a zero for any shift values greater than 31?
Or am I confused?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
