Re: Looking for help with an obscure C integer problem

[Bernd Oppolzer]

Charles,

I agree, that this may be too long for you to wait, but ...
I believe that this is quite normal for compiler errors;
they are not very common, and if you discover one, you are normally
forced to work around it, because the fix will not appear within hours,
as we have it with user programs. And: it's normally possible ... compiler
errors are hard to find and, as in this case, hard to prove, because 
compilers
normally are very well tested - that is, the errors appear in rare 
situations.


For me, the primary goal, why I invested some time in explaining this error
to IBM and provide example jobs to them, was: to get the error fixed for
other users which will fall into this trap later - including maybe myself.
If I discover errors in any software - be it mine or others - I always 
try to
get it fixed, if I see a chance to get it done - and in this case it 
seemed possible

without too much effort on my part.

And of course: compiler construction and diagnosing errors in this area 
is fun ...

at least for me. This may be special :-)

Kind regards

Bernd



Am 26.09.2013 17:12, schrieb Charles Mills:

I was the OP. I'm going to take the liberty of replying here. I coded around it.

This is the problem for me with IBM fixes. Not complaining, just stating a 
fact: I could not have waited this long for a fix.

It's too bad IBM does not have some more-established process whereby one could 
report a bug

a. Without the "burden of proof" required for a PMR.
b. In return, without any expectation of a timely fix.

Just the way one of your co-workers might say "you now, I was running your code the 
other day, and here's something you might want to take a look at ..."

Would work for me anyway.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bernd Oppolzer
Sent: Thursday, September 26, 2013 6:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fwd: Re: Looking for help with an obscure C integer problem

Hello,

I told you at end of July that an IBM employee took this problem and sent it to 
IBM maintenance, although there was no formal requirement to do so, only the 
discussions in this list. Thanks from this place for this help.

In the meantime there is a solution, and I was asked if someone needs an 
Interim fix (a PTF, I think), which could be made available, but only for z/OS 
1.12 and 1.13, as far as I understood.

If you need such a fix, would you please respond me offline?

Thank you, kind regards

Bernd



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

Re: Looking for help with an obscure C integer problem

[Charles Mills]

I was the OP. I'm going to take the liberty of replying here. I coded around it.

This is the problem for me with IBM fixes. Not complaining, just stating a 
fact: I could not have waited this long for a fix.

It's too bad IBM does not have some more-established process whereby one could 
report a bug 

a. Without the "burden of proof" required for a PMR.
b. In return, without any expectation of a timely fix.

Just the way one of your co-workers might say "you now, I was running your code 
the other day, and here's something you might want to take a look at ..."

Would work for me anyway.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bernd Oppolzer
Sent: Thursday, September 26, 2013 6:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fwd: Re: Looking for help with an obscure C integer problem

Hello,

I told you at end of July that an IBM employee took this problem and sent it to 
IBM maintenance, although there was no formal requirement to do so, only the 
discussions in this list. Thanks from this place for this help.

In the meantime there is a solution, and I was asked if someone needs an 
Interim fix (a PTF, I think), which could be made available, but only for z/OS 
1.12 and 1.13, as far as I understood.

If you need such a fix, would you please respond me offline?

Thank you, kind regards

Bernd




 Original-Nachricht --------
Betreff:    Re: Looking for help with an obscure C integer problem
Datum:  Sat, 27 Jul 2013 21:11:38 +0200
Von:Bernd Oppolzer 
An: IBM Mainframe Discussion List 



Hello,

I would like to tell you about the steps needed until I discovered the HGPR 
option as the source of the problem.

First I tried the function below, but the value in lwert was constant.
The compiler simply optimized all the computation away and simply printed the 
result, so there was no computation at all, and no error, so I had to read the 
value for lwert from a file, so that the compiler could not throw away the 
computation.

Then, when I changed this, there was again no error. But, as I remarked, the 
compiler used no LG etc. instructions. So there must be some different options.

I had different ARCH and TUNE settings, so I changed my options to the same 
settings that Charles had, but that didn't change anything.
I got no LG etc. instructions, anyway - and computation still was right, 
without the error.

Then I discovered the HGPR option ...

Now for informing IBM:

I'm a freelancer actually working at a big company. I will try to ask the 
people which are responsible for compiler installation etc., but I can imagine, 
what they will tell me:

"do we use this option? do we have a problem with this error?
No? So we will take no action on this ..."

So I think we will not do anything about this, sorry.

Sorry; I'm not involved in the decision processes there; if I were, I would act 
different.

If some IBM people hanging around here read this:
wouldn't it be possible that they take action based on my description of the 
error? I would appreciate it, and the C/C++ community here, too, I believe.

Kind regards

Bernd



Am 27.07.2013 18:07, schrieb Bernd Oppolzer:
> I was able to reproduce the problem with a little test program:
>
>
> #include 
> #include 
>
> static void longtest (long long lwert) {
>int test;
>test = lwert & 0xLL;
>if (test != 0)
>{
>   printf ("lwert right = %x\n", test);
>}
>else
>{
>   test = lwert >> 32;
>   printf ("lwert left = %x\n", test);
>}
> }
>
> int main (void)
> {
>long long lwert;
>int l1;
>int l2;
>int *p;
>char zeile [85];
>fgets (zeile, 80, stdin);
>l1 = atoi (zeile);
>fgets (zeile, 80, stdin);
>l2 = atoi (zeile);
>lwert = l1;
>lwert <<= 32;
>lwert += l2;
>p = (int *) (&lwert);
>printf ("long long first part = %x\n", *p);
>printf ("long long second part = %x\n", *(p + 1));
>longtest (lwert);
> }
>
>
> this was compiled using z/OS XL C version 1.11.
>
> The error only showed up when using the compile option HGPR, that is, 
> when the compiler used the G-instructions, like SRAG etc.
>
> results with HGPR:
>
> long long first part = 8000
> long long second part = 0
> lwert left = 0
>
> results without HGPR:
>
> long long first part = 8000
> long long second part = 0
> lwert left = 8000
>
> this can be confirmed by looking at the ASSEMBLER code generated in 
> both cases:
>
> with HGPR:
>
> * longtest (lwert);
>   LG   r0,lwert(,r13,304)
>   ST   r0,lwert%2=>1(,r13,316)
> TEST LONG LONG:
>

Fwd: Re: Looking for help with an obscure C integer problem

[Bernd Oppolzer]

Hello,

I told you at end of July that an IBM employee took this problem and
sent it to IBM maintenance, although there was no formal requirement
to do so, only the discussions in this list. Thanks from this place for 
this help.


In the meantime there is a solution, and I was asked if someone needs an
Interim fix (a PTF, I think), which could be made available, but only for
z/OS 1.12 and 1.13, as far as I understood.

If you need such a fix, would you please respond me offline?

Thank you, kind regards

Bernd




 Original-Nachricht 
Betreff:Re: Looking for help with an obscure C integer problem
Datum:  Sat, 27 Jul 2013 21:11:38 +0200
Von:Bernd Oppolzer 
An: IBM Mainframe Discussion List 



Hello,

I would like to tell you about the steps needed until I discovered the
HGPR option as the source of the problem.

First I tried the function below, but the value in lwert was constant.
The compiler simply optimized all the computation away and simply
printed the result, so there was no computation at all, and no error,
so I had to read the value for lwert from a file, so that the compiler
could not throw away the computation.

Then, when I changed this, there was again no error. But, as I remarked,
the compiler used no LG etc. instructions. So there must be some
different options.

I had different ARCH and TUNE settings, so I changed my options to
the same settings that Charles had, but that didn't change anything.
I got no LG etc. instructions, anyway - and computation still was right,
without the error.

Then I discovered the HGPR option ...

Now for informing IBM:

I'm a freelancer actually working at a big company. I will try to ask
the people which are responsible for compiler installation etc.,
but I can imagine, what they will tell me:

"do we use this option? do we have a problem with this error?
No? So we will take no action on this ..."

So I think we will not do anything about this, sorry.

Sorry; I'm not involved in the decision processes there; if I were,
I would act different.

If some IBM people hanging around here read this:
wouldn't it be possible that they take action based on
my description of the error? I would appreciate it,
and the C/C++ community here, too, I believe.

Kind regards

Bernd



Am 27.07.2013 18:07, schrieb Bernd Oppolzer:

I was able to reproduce the problem with a little test program:


#include 
#include 

static void longtest (long long lwert)
{
   int test;
   test = lwert & 0xLL;
   if (test != 0)
   {
  printf ("lwert right = %x\n", test);
   }
   else
   {
  test = lwert >> 32;
  printf ("lwert left = %x\n", test);
   }
}

int main (void)
{
   long long lwert;
   int l1;
   int l2;
   int *p;
   char zeile [85];
   fgets (zeile, 80, stdin);
   l1 = atoi (zeile);
   fgets (zeile, 80, stdin);
   l2 = atoi (zeile);
   lwert = l1;
   lwert <<= 32;
   lwert += l2;
   p = (int *) (&lwert);
   printf ("long long first part = %x\n", *p);
   printf ("long long second part = %x\n", *(p + 1));
   longtest (lwert);
}


this was compiled using z/OS XL C version 1.11.

The error only showed up when using the compile option HGPR,
that is, when the compiler used the G-instructions, like SRAG etc.

results with HGPR:

long long first part = 8000
long long second part = 0
lwert left = 0

results without HGPR:

long long first part = 8000
long long second part = 0
lwert left = 8000

this can be confirmed by looking at the ASSEMBLER code generated in
both cases:

with HGPR:

* longtest (lwert);
  LG   r0,lwert(,r13,304)
  ST   r0,lwert%2=>1(,r13,316)
TEST LONG LONG:
  SRAG r0,r0,32
  ST   r0,lwert%2=>1(,r13,312)
+ LG   r0,lwert%2=>1(,r13,312)
+ LTR  r0,r0
+ BE   @1L6
+ LA   r1,+CONSTANT_AREA(,r2,55)
+ ST   r0,#MX_TEMP1(,r13,228)
+ LGF  r15,=V(PRINTF)(,r3,362)
+ ST   r1,#MX_TEMP1(,r13,224)
+ LA   r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+ B@1L7
+@1L6 DS   0H
+ LA   r0,+CONSTANT_AREA(,r2,73)
+ ST   r0,#MX_TEMP1(,r13,224)
+ LGHI r0,H'0'
+ LGF  r15,=V(PRINTF)(,r3,362)
+ LA   r1,#MX_TEMP1(,r13,224)
+ ST   r0,#MX_TEMP1(,r13,228)
+ BASR r14,r15
+@1L7 DS   0H

without HGPR:

* longtest (lwert);
  Lr4,(,r13,240)
TEST LONG LONG:
  ICM  r0,b'',(r13,244
+ BE   @1L6
+ LA   r1,+CONSTANT_AREA(,r2,55)
+ ST   r0,#MX_TEMP1(,r13,228)
+ Lr15,=V(PRINTF)(,r3,302)
+ ST   r1,#MX_TEMP1(,r13,224)
+ LA   r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+ B@1L7
+@1L6 DS   0H
+ LA   r0,+CONST

Re: Looking for help with an obscure C integer problem

[Charles Mills]

Lizette tells me offline that I have beat this topic up enough :-) so this
will probably be my last post in this thread.

I wanted just to address two things:

- The cost/benefit decision was mine alone. My employer would certainly
support me if I decided to PMR the problem.
- Yes, the decision to accept FIN was mine but after 8 months of tolerating
the problem what else could I say to the question "can you live without a
real fix?" I guess this kind of goes to the heart of my problem with IBM
support. In my experience they generally will not accept a Sev 1 for a
development problem -- never mind that development is the only "production"
that we do. So I *have* to find a workaround. And once I do, a fix hardly
matters; I have moved on. Perhaps not IBM's "fault" but it is my reality.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John McKown
Sent: Sunday, July 28, 2013 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem

Sounds almost like we work for the same company. It is all about cost,
nothing about quality. This is why Wintel is "the best thing in the market".
 On Jul 28, 2013 9:07 AM, "Bernd Oppolzer" 
wrote:

> I understand Charles' attitude fully and respect it; it's driven by 
> the experiences he made in the past.
> I for myself have made other experiences, and so for the moment I 
> (still) act differently, but that is subject to change in the future, 
> too.
>
> I would like to tell you about a talk I had with the guy who is 
> responsible for the compiler at our site; I met him by accident on a 
> bike tour some hours ago. It's weekend, after all.
>
> As I predicted, he is not willing to act on this problem, because we 
> do not have this option HGPR active, and so we don't have a problem 
> with this. At our site, we also have a strong cost/benefit thinking - 
> in fact, it's worse: the managers only look at the cost and don't even 
> see that for different cost you may get different benefit. They always 
> choose the solution with minimal cost - and ignore the possible 
> benefit. (Often you cannot tell the benefit beforehand, but most of 
> the time you know the cost). So the quality of service is going down 
> from day to day ...
> which leads to higher cost in the end ... but they don't see that.
>
> I believe this kind of problem is not limited to IT; you see it 
> everywhere in the industry.

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

Re: Looking for help with an obscure C integer problem

[Steve Comstock]

Excellent work Bernd!

-Steve Comstock

On 7/27/2013 10:07 AM, Bernd Oppolzer wrote:

I was able to reproduce the problem with a little test program:


#include 
#include 

static void longtest (long long lwert)
{
int test;
test = lwert & 0xLL;
if (test != 0)
{
   printf ("lwert right = %x\n", test);
}
else
{
   test = lwert >> 32;
   printf ("lwert left = %x\n", test);
}
}

int main (void)
{
long long lwert;
int l1;
int l2;
int *p;
char zeile [85];
fgets (zeile, 80, stdin);
l1 = atoi (zeile);
fgets (zeile, 80, stdin);
l2 = atoi (zeile);
lwert = l1;
lwert <<= 32;
lwert += l2;
p = (int *) (&lwert);
printf ("long long first part = %x\n", *p);
printf ("long long second part = %x\n", *(p + 1));
longtest (lwert);
}


this was compiled using z/OS XL C version 1.11.

The error only showed up when using the compile option HGPR,
that is, when the compiler used the G-instructions, like SRAG etc.

results with HGPR:

long long first part = 8000
long long second part = 0
lwert left = 0

results without HGPR:

long long first part = 8000
long long second part = 0
lwert left = 8000

this can be confirmed by looking at the ASSEMBLER code generated in both cases:

with HGPR:

* longtest (lwert);
   LG   r0,lwert(,r13,304)
   ST   r0,lwert%2=>1(,r13,316)
 TEST LONG LONG:
   SRAG r0,r0,32
   ST   r0,lwert%2=>1(,r13,312)
+ LG   r0,lwert%2=>1(,r13,312)
+ LTR  r0,r0
+ BE   @1L6
+ LA   r1,+CONSTANT_AREA(,r2,55)
+ ST   r0,#MX_TEMP1(,r13,228)
+ LGF  r15,=V(PRINTF)(,r3,362)
+ ST   r1,#MX_TEMP1(,r13,224)
+ LA   r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+ B@1L7
+@1L6 DS   0H
+ LA   r0,+CONSTANT_AREA(,r2,73)
+ ST   r0,#MX_TEMP1(,r13,224)
+ LGHI r0,H'0'
+ LGF  r15,=V(PRINTF)(,r3,362)
+ LA   r1,#MX_TEMP1(,r13,224)
+ ST   r0,#MX_TEMP1(,r13,228)
+ BASR r14,r15
+@1L7 DS   0H

without HGPR:

* longtest (lwert);
   Lr4,(,r13,240)
 TEST LONG LONG:
   ICM  r0,b'',(r13,244
+ BE   @1L6
+ LA   r1,+CONSTANT_AREA(,r2,55)
+ ST   r0,#MX_TEMP1(,r13,228)
+ Lr15,=V(PRINTF)(,r3,302)
+ ST   r1,#MX_TEMP1(,r13,224)
+ LA   r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+ B@1L7
+@1L6 DS   0H
+ LA   r0,+CONSTANT_AREA(,r2,73)
+ LA   r5,0
+ ST   r0,#MX_TEMP1(,r13,224)
+ SRDA r4,32
+ Lr15,=V(PRINTF)(,r3,302)
+ ST   r5,#MX_TEMP1(,r13,228)
+ LA   r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+@1L7 DS   0H
*  }
   LA   r15,0

look at the SRDA instrunction, which is missing in the other case.

This is a compiler error and should be repaired by IBM support.

Kind regards

Bernd




Am 27.07.2013 17:03, schrieb Bernd Oppolzer:

don't know for C, but for problems or questions concerning
the PL/1 compiler, IBM support was always very responsive
and helpful. That's my experience, at least.

You could help them by isolating the problem with a small
test program (containing for example only this function and
a little main with a test call). Provide the compile list
with the LIST option, together with the problem description.

Kind regards

Bernd


--
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: Looking for help with an obscure C integer problem

[Shmuel Metz (Seymour J.)]

In <001001ce8b97$9def20a0$d9cd61e0$@mcn.org>, on 07/28/2013
   at 09:37 AM, Charles Mills  said:

>Here was the first battle I had to fight. The program in question is
>a STC that installs exits and so I implemented Signal handling so
>that in the event of a problem it could shut down gracefully. To test
>that code I added an undocumented MODIFY command to force a S0C4. I
>encountered the problem while testing that intentional S0C4/signal
>handling code. That was how I could reproduce the problem. I went
>around and around with the level 1 folks saying "we found your
>problem -- you are trying to store into low core" and me saying "I am
>doing that on purpose to force this problem.

The magic word is "escalate".

>Then IBM came back to me and said "do you really, really, REALLY
>need this fixed?" and I said "no, of course not, I've been living
>for eight months with it not fixed."

That was the wrong answer if FIN was not acceptable. I can't blame IBM
for taking you at your word.

Of course, I do blame Level 1 for not reading the record before
responding )-:

-- 
 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: Looking for help with an obscure C integer problem

[Shmuel Metz (Seymour J.)]

In <3399683725614169.wa.paulgboulderaim@listserv.ua.edu>, on
07/27/2013
   at 02:08 PM, Paul Gilmartin  said:

>Thinking back on the recent "SR Policy" thread which I started, 
>and to which you contributed, should the customer entertain the 
>question, "...let me know what impact this issue has on your day 
>to day business...", or should the customer expect a repair 
>because it's The Right Thing To Do, and because it may spare a 
>peer customer "hours of searching and testing"? 

Both. The answer should affect the timing of the repair, not whether
IBM fixes the bug at all.

-- 
 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: Looking for help with an obscure C integer problem

[Shmuel Metz (Seymour J.)]

In <51f3e14d.20...@t-online.de>, on 07/27/2013
   at 05:03 PM, Bernd Oppolzer  said:

>don't know for C, but for problems or questions concerning the PL/1
>compiler, IBM support was always very responsive and helpful. That's
>my experience, at least.

My experience is that the quality of the support depends very much on
the component, and that there are a lot of careless or inexperienced
people at the bottom of the food chain, e.g., asking for data that are
already in the record. However, I've rarely had to escalate.

The last time that I had to deal with PL/I issues the support was
excellent, but I haven't dealt with the Enterprise compiler.

-- 
 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: Looking for help with an obscure C integer problem

[Charles Mills]

No, no, no offense taken at all. I am harder to offend than that! Was using 
"beat up" in jest. Longer reply to follow. 

Charles
Composed on a mobile: please excuse my brevity 

Lizette Koehler  wrote:

>Charles,
>
>First let me apologize if it seemed I was beating you up.  That was not my 
>intent.  Unfortunately in email the reader cannot always determine how the 
>words are being said.  It was more of a help a vendor out type commentary.  
>Not do it or else type commentary.  But if I did offend - I am sorry.
>
>I am also sorry you have had some issues in the past.  I think most on this 
>list can quote similar events.  Not with just IBM but other vendors as well.  
>And as for IBM, they have to recreate the problem in a vanilla IBM only 
>software.  They do not always have OEM software in their testing environment.  
>Therefore, they rely on the reporter to help with the diagnosis sometimes.  
>And I guess the bottom line is - sometimes software will work and sometimes it 
>has problems.  
>
>When it doesn’t work then it becomes - how important is it to get it fixed and 
>how repeatable the failure.
>
>FIN (Fixed in next) is sometimes acceptable.  Fix it now is sometimes 
>acceptable in others.  You have to decide which is more important at the time.
>
>I usually will continue with the vendor until the resolution is found; I then 
>determine which way I go.
>
>
>I believe that all Vendor Support groups want to fix issues as quickly as they 
>can. Based on priority, willingness of the customer to work with them, and the 
>complexity of the code that needs to be validated and/or corrected; it can be 
>an extraordinary effort.  Then they have to balance that with how many 
>customers are reporting it, is it isolated or more common.  A lot of factors 
>go into working on reported issues.  Having worked both sides - IBM level 2 
>support and customer, I can understand some of the constraints IBM has with 
>correcting problems.  Some are really easy to identify and fix.  Others are 
>head scratchers.  And if there are OEM products involved, they have to get 
>documentation from the customer and have the customer validate through parm 
>changes or other data collection.
>
>I just finished working on a problem with EMC on their storage array.  It took 
>a couple of months and it turned out this particular issue when back a couple 
>of code levels for them.  But they were not aware of it until I had my issue.  
>I spent time sending in a lot of RMF and LOGREC data on my issue, but they 
>found it and eventually fixed it.  They have  also retrofitted it to the older 
>release.  But it was an effort on both of our parts to resolve this.
>
>One more story.  I was support our DR testing when Top Secret would not come 
>up at IPL time.  Took an S0C4-04.  This is around 5pm.  I looked at the 
>summary dump and called in a Sev1 to CA.  They were able to quickly identify 
>the issue and provide a work around (there was a ptf but we could not apply it 
>at DR).  So the secondary workaround - disable PDS Member Security.  It turned 
>out that 9 months before another shop running ACF2 had the same issue.  They 
>ran the problem with CA for several months (I think about 4) before CA was 
>able to determine that a new instruction was used that only ran on z9 and 
>above.  We were running on a z890 at DR but a z9 in our home.  If that other 
>shop had not pursued and fixed, our DR test would have failed.  So I am very 
>grateful they did what they had to do to get it fixed.  
>
>I understand that some shops do not have the time to pursue issues with 
>vendors.  I always hope they have the foresight to open the case, collect some 
>doc, and then if needed, defer to pursue.  Then there is a record in the 
>vendor's shop and if more show up, they are likely to pursue more quickly.  Or 
>if the support team is bored, they have something to work on that might be 
>interesting.
>
>I  hope your future interactions are better.
>
>
>Lizette
>
>-----Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Charles Mills
>Sent: Sunday, July 28, 2013 6:38 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Looking for help with an obscure C integer problem
>
>Okay, everyone is beating me up for not reporting this problem. Let me tell 
>you the story that put me off to PMRs.
>
>In January of 2012 or so I sent a note to IBMMAIN saying that that CEE3DMP was 
>printing garbage and then S0C4ing. You can probably find my post if you 
>search. At the urging of this group I opened a PMR on February 3. 
>
>Here was the first battle I had to fight. The program in question is a STC 
>that installs exits and so I implemented Signal handlin

Re: Looking for help with an obscure C integer problem

[John McKown]

Sounds almost like we work for the same company. It is all about cost,
nothing about quality. This is why Wintel is "the best thing in the
market".
 On Jul 28, 2013 9:07 AM, "Bernd Oppolzer" 
wrote:

> I understand Charles' attitude fully and respect it;
> it's driven by the experiences he made in the past.
> I for myself have made other experiences, and so
> for the moment I (still) act differently, but that is subject
> to change in the future, too.
>
> I would like to tell you about a talk I had with the guy who
> is responsible for the compiler at our site; I met him by
> accident on a bike tour some hours ago. It's weekend,
> after all.
>
> As I predicted, he is not willing to act on this problem,
> because we do not have this option HGPR active, and so we
> don't have a problem with this. At our site, we also have
> a strong cost/benefit thinking - in fact, it's worse: the managers
> only look at the cost and don't even see that for different cost
> you may get different benefit. They always choose the solution
> with minimal cost - and ignore the possible benefit. (Often you
> cannot tell the benefit beforehand, but most of the time you know
> the cost). So the quality of service is going down from day to day ...
> which leads to higher cost in the end ... but they don't see that.
>
> I believe this kind of problem is not limited to IT; you see it
> everywhere in the industry.
>
> Kind regards
>
> Bernd
>
>
>
> Am 28.07.2013 15:37, schrieb Charles Mills:
>
>> Okay, everyone is beating me up for not reporting this problem. Let me
>> tell you the story that put me off to PMRs.
>>
>> In January of 2012 or so I sent a note to IBMMAIN saying that that
>> CEE3DMP was printing garbage and then S0C4ing. You can probably find my
>> post if you search. At the urging of this group I opened a PMR on February
>> 3.
>>
>> Here was the first battle I had to fight. The program in question is a
>> STC that installs exits and so I implemented Signal handling so that in the
>> event of a problem it could shut down gracefully. To test that code I added
>> an undocumented MODIFY command to force a S0C4. I encountered the problem
>> while testing that intentional S0C4/signal handling code. That was how I
>> could reproduce the problem. I went around and around with the level 1
>> folks saying "we found your problem -- you are trying to store into low
>> core" and me saying "I am doing that on purpose to force this problem. Look
>> at the PMR description. I know what causes the original S0C4 -- it's the
>> garbage and the S0C4 in CEE3DMP that I am PMRing" and they would come back
>> and say "your problem is you are trying to store into low core."
>>
>> After I got past that IBM wanted dump after dump after dump from me. They
>> did not reproduce the problem -- it was all "change this option, try it
>> again, and send us the dump." I sent them a total of nine different tersed
>> dumps and similar files over the course of three months. Not a trivial
>> thing with an STC that is intertwined with the z/OS kernel. Finally they
>> said "okay, we have this figured out, we're going to work on it" and then
>> in OCTOBER they sent me a local fix to test. I tested it and confirmed that
>> they had fixed it.
>>
>> Then IBM came back to me and said "do you really, really, REALLY need
>> this fixed?" and I said "no, of course not, I've been living for eight
>> months with it not fixed." They said "good, because if we really issue a
>> PTF for this, we need to do regression testing and everything which is a
>> lot of work. How about if we just roll the fix into the next release of LE
>> (z/OS 2.0!)." At that point I said "sure, whatever." Whereupon IBM said "by
>> the way, there's no guarantee your local fix won't go away if we happen to
>> issue some other PTF that impacts it."
>>
>> Needless to say I am not very encouraged to open PMRs based on that
>> experience.
>>
>> I think those of you who say "don't you care about the customers?" have
>> it totally backwards. Of course I care about the customers. If someone
>> posted here "that CorreLog SIEM agent is okay but it seems to S0C4 from
>> time to time" I would be all over it. I would track the OP down, find out
>> what he was doing, duplicate the problem, and fix it. I would not wait
>> until the customer jumped through some particular process hoop before I
>> acknowledged the problem, or prove how much the S0C4 was hurting their
>> production. I care about MY customers, and I care about IBM's customers,
>> but you can't push a piece of string: I can't care about IBM's customers
>> more than IBM does.
>>
>> What IBM SHOULD be doing IMHO -- and I was shocked that for the first
>> time in my experience they did it in the case of the error of this thread
>> -- is have someone, an ombudsman, monitoring this list and with authority
>> to open problems and get them fixed. I am very, very pleased to see that
>> that is what is happening in this one particular case.
>>
>> Note that I was ver

Re: Looking for help with an obscure C integer problem

[Lizette Koehler]

Charles,

First let me apologize if it seemed I was beating you up.  That was not my 
intent.  Unfortunately in email the reader cannot always determine how the 
words are being said.  It was more of a help a vendor out type commentary.  Not 
do it or else type commentary.  But if I did offend - I am sorry.

I am also sorry you have had some issues in the past.  I think most on this 
list can quote similar events.  Not with just IBM but other vendors as well.  
And as for IBM, they have to recreate the problem in a vanilla IBM only 
software.  They do not always have OEM software in their testing environment.  
Therefore, they rely on the reporter to help with the diagnosis sometimes.  And 
I guess the bottom line is - sometimes software will work and sometimes it has 
problems.  

When it doesn’t work then it becomes - how important is it to get it fixed and 
how repeatable the failure.

FIN (Fixed in next) is sometimes acceptable.  Fix it now is sometimes 
acceptable in others.  You have to decide which is more important at the time.

I usually will continue with the vendor until the resolution is found; I then 
determine which way I go.


I believe that all Vendor Support groups want to fix issues as quickly as they 
can. Based on priority, willingness of the customer to work with them, and the 
complexity of the code that needs to be validated and/or corrected; it can be 
an extraordinary effort.  Then they have to balance that with how many 
customers are reporting it, is it isolated or more common.  A lot of factors go 
into working on reported issues.  Having worked both sides - IBM level 2 
support and customer, I can understand some of the constraints IBM has with 
correcting problems.  Some are really easy to identify and fix.  Others are 
head scratchers.  And if there are OEM products involved, they have to get 
documentation from the customer and have the customer validate through parm 
changes or other data collection.

I just finished working on a problem with EMC on their storage array.  It took 
a couple of months and it turned out this particular issue when back a couple 
of code levels for them.  But they were not aware of it until I had my issue.  
I spent time sending in a lot of RMF and LOGREC data on my issue, but they 
found it and eventually fixed it.  They have  also retrofitted it to the older 
release.  But it was an effort on both of our parts to resolve this.

One more story.  I was support our DR testing when Top Secret would not come up 
at IPL time.  Took an S0C4-04.  This is around 5pm.  I looked at the summary 
dump and called in a Sev1 to CA.  They were able to quickly identify the issue 
and provide a work around (there was a ptf but we could not apply it at DR).  
So the secondary workaround - disable PDS Member Security.  It turned out that 
9 months before another shop running ACF2 had the same issue.  They ran the 
problem with CA for several months (I think about 4) before CA was able to 
determine that a new instruction was used that only ran on z9 and above.  We 
were running on a z890 at DR but a z9 in our home.  If that other shop had not 
pursued and fixed, our DR test would have failed.  So I am very grateful they 
did what they had to do to get it fixed.  

I understand that some shops do not have the time to pursue issues with 
vendors.  I always hope they have the foresight to open the case, collect some 
doc, and then if needed, defer to pursue.  Then there is a record in the 
vendor's shop and if more show up, they are likely to pursue more quickly.  Or 
if the support team is bored, they have something to work on that might be 
interesting.

I  hope your future interactions are better.


Lizette

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Sunday, July 28, 2013 6:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem

Okay, everyone is beating me up for not reporting this problem. Let me tell you 
the story that put me off to PMRs.

In January of 2012 or so I sent a note to IBMMAIN saying that that CEE3DMP was 
printing garbage and then S0C4ing. You can probably find my post if you search. 
At the urging of this group I opened a PMR on February 3. 

Here was the first battle I had to fight. The program in question is a STC that 
installs exits and so I implemented Signal handling so that in the event of a 
problem it could shut down gracefully. To test that code I added an 
undocumented MODIFY command to force a S0C4. I encountered the problem while 
testing that intentional S0C4/signal handling code. That was how I could 
reproduce the problem. I went around and around with the level 1 folks saying 
"we found your problem -- you are trying to store into low core" and me saying 
"I am doing that on purpose to force this problem. Look at the PMR description. 
I know what causes the original S0C4 -- it&#

Re: Looking for help with an obscure C integer problem

[Bernd Oppolzer]

I understand Charles' attitude fully and respect it;
it's driven by the experiences he made in the past.
I for myself have made other experiences, and so
for the moment I (still) act differently, but that is subject
to change in the future, too.

I would like to tell you about a talk I had with the guy who
is responsible for the compiler at our site; I met him by
accident on a bike tour some hours ago. It's weekend,
after all.

As I predicted, he is not willing to act on this problem,
because we do not have this option HGPR active, and so we
don't have a problem with this. At our site, we also have
a strong cost/benefit thinking - in fact, it's worse: the managers
only look at the cost and don't even see that for different cost
you may get different benefit. They always choose the solution
with minimal cost - and ignore the possible benefit. (Often you
cannot tell the benefit beforehand, but most of the time you know
the cost). So the quality of service is going down from day to day ...
which leads to higher cost in the end ... but they don't see that.

I believe this kind of problem is not limited to IT; you see it
everywhere in the industry.

Kind regards

Bernd



Am 28.07.2013 15:37, schrieb Charles Mills:

Okay, everyone is beating me up for not reporting this problem. Let me tell you 
the story that put me off to PMRs.

In January of 2012 or so I sent a note to IBMMAIN saying that that CEE3DMP was 
printing garbage and then S0C4ing. You can probably find my post if you search. 
At the urging of this group I opened a PMR on February 3.

Here was the first battle I had to fight. The program in question is a STC that installs exits and so I 
implemented Signal handling so that in the event of a problem it could shut down gracefully. To test that 
code I added an undocumented MODIFY command to force a S0C4. I encountered the problem while testing that 
intentional S0C4/signal handling code. That was how I could reproduce the problem. I went around and around 
with the level 1 folks saying "we found your problem -- you are trying to store into low core" and 
me saying "I am doing that on purpose to force this problem. Look at the PMR description. I know what 
causes the original S0C4 -- it's the garbage and the S0C4 in CEE3DMP that I am PMRing" and they would 
come back and say "your problem is you are trying to store into low core."

After I got past that IBM wanted dump after dump after dump from me. They did not reproduce the 
problem -- it was all "change this option, try it again, and send us the dump." I sent 
them a total of nine different tersed dumps and similar files over the course of three months. Not 
a trivial thing with an STC that is intertwined with the z/OS kernel. Finally they said "okay, 
we have this figured out, we're going to work on it" and then in OCTOBER they sent me a local 
fix to test. I tested it and confirmed that they had fixed it.

Then IBM came back to me and said "do you really, really, REALLY need this fixed?" and I said "no, of course not, 
I've been living for eight months with it not fixed." They said "good, because if we really issue a PTF for this, we 
need to do regression testing and everything which is a lot of work. How about if we just roll the fix into the next release of 
LE (z/OS 2.0!)." At that point I said "sure, whatever." Whereupon IBM said "by the way, there's no guarantee 
your local fix won't go away if we happen to issue some other PTF that impacts it."

Needless to say I am not very encouraged to open PMRs based on that experience.

I think those of you who say "don't you care about the customers?" have it totally 
backwards. Of course I care about the customers. If someone posted here "that CorreLog SIEM 
agent is okay but it seems to S0C4 from time to time" I would be all over it. I would track 
the OP down, find out what he was doing, duplicate the problem, and fix it. I would not wait until 
the customer jumped through some particular process hoop before I acknowledged the problem, or 
prove how much the S0C4 was hurting their production. I care about MY customers, and I care about 
IBM's customers, but you can't push a piece of string: I can't care about IBM's customers more than 
IBM does.

What IBM SHOULD be doing IMHO -- and I was shocked that for the first time in 
my experience they did it in the case of the error of this thread -- is have 
someone, an ombudsman, monitoring this list and with authority to open problems 
and get them fixed. I am very, very pleased to see that that is what is 
happening in this one particular case.

Note that I was very forthcoming with information here even after my particular 
problem went away. I am not selfish. I posted the listings that enabled some 
very clever people to find the problem for IBM. I am very willing to contribute 
effort to solving problems on behalf of the community. I have just come to the 
conclusion that the PMR process is simply not sufficiently cost/benefit 
effective to work for

Re: Looking for help with an obscure C integer problem

[Charles Mills]

Okay, everyone is beating me up for not reporting this problem. Let me tell you 
the story that put me off to PMRs.

In January of 2012 or so I sent a note to IBMMAIN saying that that CEE3DMP was 
printing garbage and then S0C4ing. You can probably find my post if you search. 
At the urging of this group I opened a PMR on February 3. 

Here was the first battle I had to fight. The program in question is a STC that 
installs exits and so I implemented Signal handling so that in the event of a 
problem it could shut down gracefully. To test that code I added an 
undocumented MODIFY command to force a S0C4. I encountered the problem while 
testing that intentional S0C4/signal handling code. That was how I could 
reproduce the problem. I went around and around with the level 1 folks saying 
"we found your problem -- you are trying to store into low core" and me saying 
"I am doing that on purpose to force this problem. Look at the PMR description. 
I know what causes the original S0C4 -- it's the garbage and the S0C4 in 
CEE3DMP that I am PMRing" and they would come back and say "your problem is you 
are trying to store into low core."

After I got past that IBM wanted dump after dump after dump from me. They did 
not reproduce the problem -- it was all "change this option, try it again, and 
send us the dump." I sent them a total of nine different tersed dumps and 
similar files over the course of three months. Not a trivial thing with an STC 
that is intertwined with the z/OS kernel. Finally they said "okay, we have this 
figured out, we're going to work on it" and then in OCTOBER they sent me a 
local fix to test. I tested it and confirmed that they had fixed it.

Then IBM came back to me and said "do you really, really, REALLY need this 
fixed?" and I said "no, of course not, I've been living for eight months with 
it not fixed." They said "good, because if we really issue a PTF for this, we 
need to do regression testing and everything which is a lot of work. How about 
if we just roll the fix into the next release of LE (z/OS 2.0!)." At that point 
I said "sure, whatever." Whereupon IBM said "by the way, there's no guarantee 
your local fix won't go away if we happen to issue some other PTF that impacts 
it."

Needless to say I am not very encouraged to open PMRs based on that experience.

I think those of you who say "don't you care about the customers?" have it 
totally backwards. Of course I care about the customers. If someone posted here 
"that CorreLog SIEM agent is okay but it seems to S0C4 from time to time" I 
would be all over it. I would track the OP down, find out what he was doing, 
duplicate the problem, and fix it. I would not wait until the customer jumped 
through some particular process hoop before I acknowledged the problem, or 
prove how much the S0C4 was hurting their production. I care about MY 
customers, and I care about IBM's customers, but you can't push a piece of 
string: I can't care about IBM's customers more than IBM does.

What IBM SHOULD be doing IMHO -- and I was shocked that for the first time in 
my experience they did it in the case of the error of this thread -- is have 
someone, an ombudsman, monitoring this list and with authority to open problems 
and get them fixed. I am very, very pleased to see that that is what is 
happening in this one particular case. 

Note that I was very forthcoming with information here even after my particular 
problem went away. I am not selfish. I posted the listings that enabled some 
very clever people to find the problem for IBM. I am very willing to contribute 
effort to solving problems on behalf of the community. I have just come to the 
conclusion that the PMR process is simply not sufficiently cost/benefit 
effective to work for me.

Thanks for listening.

Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, July 27, 2013 10:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem

On Sat, 27 Jul 2013 14:59:15 -0500, Ed Gould wrote:
>
>This is in my opinion a fuzzy error. Where the C issue is a classic
>bug(probably) your SR Policy is a gray area and it is harder to define 
>a right/wrong answer (although probably you are right).
>Spelling & such is a issue but not a real bug. It is a soft issue, in 
>my opinion and a lot harder to get IBM interested.
> 
I certainly did not say that my "SR Policy" thread was motivated by the 
response to a report of a spelling error.
In fact, it was a report of the misbehavior I discussed in the
"Buffering: stdout ..." thread.  I suppose you're free to deem it cosmetic or 
not as you choose.

The good news is that IBM has reproduced 

Re: Looking for help with an obscure C integer problem

[Paul Gilmartin]

On Sat, 27 Jul 2013 14:59:15 -0500, Ed Gould wrote:
>
>This is in my opinion a fuzzy error. Where the C issue is a classic
>bug(probably) your SR Policy is a gray area and it is harder to
>define a right/wrong answer (although probably you are right).
>Spelling & such is a issue but not a real bug. It is a soft issue, in
>my opinion and a lot harder to get IBM interested.
> 
I certainly did not say that my "SR Policy" thread was
motivated by the response to a report of a spelling error.
In fact, it was a report of the misbehavior I discussed in the
"Buffering: stdout ..." thread.  I suppose you're free to deem
it cosmetic or not as you choose.

The good news is that IBM has reproduced the problem, even
while prodding me for a statement of business impact (which
I supplied, acknowledging that I was working on a PoC).

-- gil

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

Re: Looking for help with an obscure C integer problem

[Bernd Oppolzer]

... he is in fact an IBM employee,
and we hopefully will be informed when there is a PTF for this problem ...

Thanks again

Bernd


Am 27.07.2013 23:07, schrieb Bernd Oppolzer:

Hello,

another follower of IBM main just informed me offline,
that he open a problem with IBM support and included my documentation.
So there is no need to discuss this further.

Thank you, kind regards

Bernd



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

Re: Looking for help with an obscure C integer problem

[Bernd Oppolzer]

Hello,

another follower of IBM main just informed me offline,
that he open a problem with IBM support and included my documentation.
So there is no need to discuss this further.

Thank you, kind regards

Bernd


Am 27.07.2013 21:11, schrieb Bernd Oppolzer:


So I think we will not do anything about this, sorry.

Sorry; I'm not involved in the decision processes there; if I were,
I would act different.

If some IBM people hanging around here read this:
wouldn't it be possible that they take action based on
my description of the error? I would appreciate it,
and the C/C++ community here, too, I believe.


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

Re: Looking for help with an obscure C integer problem

[Ed Gould]

On Jul 27, 2013, at 2:08 PM, Paul Gilmartin wrote:


Thinking back on the recent "SR Policy" thread which I started, and  
to which
you contributed, should the customer entertain the question,  
"...let me know
what impact this issue has on your day to day business...", or  
should the
customer expect a repair because it's The Right Thing To Do, and  
because
it may spare a peer customer "hours of searching and testing"?   
Note that

when Charles has a circumvention, he must honestly answer that the
"impact ... on [his] day to day business" has been reduced to zero.
---Deleted


Paul:

This is in my opinion a fuzzy error. Where the C issue is a classic  
bug(probably) your SR Policy is a gray area and it is harder to  
define a right/wrong answer (although probably you are right).  
Spelling & such is a issue but not a real bug. It is a soft issue, in  
my opinion and a lot harder to get IBM interested.


Ed

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

Re: Looking for help with an obscure C integer problem

[Lizette Koehler]

I am thinking that even if Charles opens an issue, and then they come back and 
say - do this and that, he could close it at that point.  And for this one, a 
lot of research and analysis has already gone into this problem.  I think it 
might be worth just opening the case.

All the documentation he has supplied would be available should someone else 
come across this issue and want to pursue.

I have done this in the past.  I had all the doc needed, but could not get a 
consistence recreation.  So the issue was opened, doc supplied, then closed.  
Later on I learned someone else had the issue and was able to have a more 
consistent recreation.  With my doc and theirs, the problem was easier to 
isolate.

Lizette.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, July 27, 2013 12:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem

On Sat, 27 Jul 2013 10:22:55 -0700, Lizette Koehler wrote:

>Charles,
>
>You are a vendor and may have found a problem with the C integer process.  It 
>would be of benefit to the community when you find something like this to 
>report even if you do not get benefit directly.
>
>Instead you get an indirect benefit of helping the community and preventing 
>someone else hours of searching and testing.
>
>If there was something wrong with one of your processes, would you want your 
>customer to say - it is not worth it.  Or would you want it reported so you 
>can fix it.
>
>Just my 2 cents worth
> 
Thinking back on the recent "SR Policy" thread which I started, and to which 
you contributed, should the customer entertain the question, "...let me know 
what impact this issue has on your day to day business...", or should the 
customer expect a repair because it's The Right Thing To Do, and because it may 
spare a peer customer "hours of searching and testing"?  Note that when Charles 
has a circumvention, he must honestly answer that the "impact ... on [his] day 
to day business" has been reduced to zero.

-- gil

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

Re: Looking for help with an obscure C integer problem

[Bernd Oppolzer]

Hello,

I would like to tell you about the steps needed until I discovered the
HGPR option as the source of the problem.

First I tried the function below, but the value in lwert was constant.
The compiler simply optimized all the computation away and simply
printed the result, so there was no computation at all, and no error,
so I had to read the value for lwert from a file, so that the compiler
could not throw away the computation.

Then, when I changed this, there was again no error. But, as I remarked,
the compiler used no LG etc. instructions. So there must be some
different options.

I had different ARCH and TUNE settings, so I changed my options to
the same settings that Charles had, but that didn't change anything.
I got no LG etc. instructions, anyway - and computation still was right,
without the error.

Then I discovered the HGPR option ...

Now for informing IBM:

I'm a freelancer actually working at a big company. I will try to ask
the people which are responsible for compiler installation etc.,
but I can imagine, what they will tell me:

"do we use this option? do we have a problem with this error?
No? So we will take no action on this ..."

So I think we will not do anything about this, sorry.

Sorry; I'm not involved in the decision processes there; if I were,
I would act different.

If some IBM people hanging around here read this:
wouldn't it be possible that they take action based on
my description of the error? I would appreciate it,
and the C/C++ community here, too, I believe.

Kind regards

Bernd



Am 27.07.2013 18:07, schrieb Bernd Oppolzer:

I was able to reproduce the problem with a little test program:


#include 
#include 

static void longtest (long long lwert)
{
   int test;
   test = lwert & 0xLL;
   if (test != 0)
   {
  printf ("lwert right = %x\n", test);
   }
   else
   {
  test = lwert >> 32;
  printf ("lwert left = %x\n", test);
   }
}

int main (void)
{
   long long lwert;
   int l1;
   int l2;
   int *p;
   char zeile [85];
   fgets (zeile, 80, stdin);
   l1 = atoi (zeile);
   fgets (zeile, 80, stdin);
   l2 = atoi (zeile);
   lwert = l1;
   lwert <<= 32;
   lwert += l2;
   p = (int *) (&lwert);
   printf ("long long first part = %x\n", *p);
   printf ("long long second part = %x\n", *(p + 1));
   longtest (lwert);
}


this was compiled using z/OS XL C version 1.11.

The error only showed up when using the compile option HGPR,
that is, when the compiler used the G-instructions, like SRAG etc.

results with HGPR:

long long first part = 8000
long long second part = 0
lwert left = 0

results without HGPR:

long long first part = 8000
long long second part = 0
lwert left = 8000

this can be confirmed by looking at the ASSEMBLER code generated in 
both cases:


with HGPR:

* longtest (lwert);
  LG   r0,lwert(,r13,304)
  ST   r0,lwert%2=>1(,r13,316)
TEST LONG LONG:
  SRAG r0,r0,32
  ST   r0,lwert%2=>1(,r13,312)
+ LG   r0,lwert%2=>1(,r13,312)
+ LTR  r0,r0
+ BE   @1L6
+ LA   r1,+CONSTANT_AREA(,r2,55)
+ ST   r0,#MX_TEMP1(,r13,228)
+ LGF  r15,=V(PRINTF)(,r3,362)
+ ST   r1,#MX_TEMP1(,r13,224)
+ LA   r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+ B@1L7
+@1L6 DS   0H
+ LA   r0,+CONSTANT_AREA(,r2,73)
+ ST   r0,#MX_TEMP1(,r13,224)
+ LGHI r0,H'0'
+ LGF  r15,=V(PRINTF)(,r3,362)
+ LA   r1,#MX_TEMP1(,r13,224)
+ ST   r0,#MX_TEMP1(,r13,228)
+ BASR r14,r15
+@1L7 DS   0H

without HGPR:

* longtest (lwert);
  Lr4,(,r13,240)
TEST LONG LONG:
  ICM  r0,b'',(r13,244
+ BE   @1L6
+ LA   r1,+CONSTANT_AREA(,r2,55)
+ ST   r0,#MX_TEMP1(,r13,228)
+ Lr15,=V(PRINTF)(,r3,302)
+ ST   r1,#MX_TEMP1(,r13,224)
+ LA   r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+ B@1L7
+@1L6 DS   0H
+ LA   r0,+CONSTANT_AREA(,r2,73)
+ LA   r5,0
+ ST   r0,#MX_TEMP1(,r13,224)
+ SRDA r4,32
+ Lr15,=V(PRINTF)(,r3,302)
+ ST   r5,#MX_TEMP1(,r13,228)
+ LA   r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+@1L7 DS   0H
*  }
  LA   r15,0

look at the SRDA instrunction, which is missing in the other case.

This is a compiler error and should be repaired by IBM support.

Kind regards

Bernd 


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

Re: Looking for help with an obscure C integer problem

[Paul Gilmartin]

On Sat, 27 Jul 2013 10:22:55 -0700, Lizette Koehler wrote:

>Charles,
>
>You are a vendor and may have found a problem with the C integer process.  It 
>would be of benefit to the community when you find something like this to 
>report even if you do not get benefit directly.
>
>Instead you get an indirect benefit of helping the community and preventing 
>someone else hours of searching and testing.
>
>If there was something wrong with one of your processes, would you want your 
>customer to say - it is not worth it.  Or would you want it reported so you 
>can fix it.
>
>Just my 2 cents worth
> 
Thinking back on the recent "SR Policy" thread which I started, and to which
you contributed, should the customer entertain the question, "...let me know
what impact this issue has on your day to day business...", or should the
customer expect a repair because it's The Right Thing To Do, and because
it may spare a peer customer "hours of searching and testing"?  Note that
when Charles has a circumvention, he must honestly answer that the
"impact ... on [his] day to day business" has been reduced to zero.

-- gil

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

Re: Looking for help with an obscure C integer problem

[Charles Mills]

I hear you. If I get the time I will explain my thoughts. 

Charles
Composed on a mobile: please excuse my brevity 

Lizette Koehler  wrote:

>Charles,
>
>You are a vendor and may have found a problem with the C integer process.  It 
>would be of benefit to the community when you find something like this to 
>report even if you do not get benefit directly.
>
>Instead you get an indirect benefit of helping the community and preventing 
>someone else hours of searching and testing.
>
>If there was something wrong with one of your processes, would you want your 
>customer to say - it is not worth it.  Or would you want it reported so you 
>can fix it.
>
>Just my 2 cents worth
>
>
>Lizette
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Charles Mills
>Sent: Saturday, July 27, 2013 7:22 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Looking for help with an obscure C integer problem
>
>last bug I reported I invested hours and hours and ultimately received zero 
>benefit.
>
>Charles
>Composed on a mobile: please excuse my brevity 
>
>Bernd Oppolzer  wrote:
>
>>If this were a problem that I had to solve, I would now contact IBM 
>>support and tell them that in the second call to ffs the compiler 
>>always puts a zero argument into the call argument list, although it 
>>should put the result of the
>>32 bit right shift there. There is clear evidence for this from the 
>>ASSEMBLER resolution that you posted yesterday. This is a compiler bug 
>>IMHO. There were no differing opinions from others so far.
>>
>>Kind regards
>>
>>Bernd
>>
>>
>>
>>Am 27.07.2013 13:59, schrieb Charles Mills:
>>> It's not formatted terrifically for copying and  pasting here but 
>>> LONGLONG shows up in the listing as one of the suboptions of LANGLVL 
>>> under Compiler Options.
>>>
>>> LANGLVL(ANONSTRUCT,ANONUNION,ANSIFOR,ANSISINIT,NOAUTOTYPEDEDUCTION,C9
>>> 9VLA,C9
>>> 9__F
>>> NOC99LONGLONG,NOC99PREPROCESSOR,NOCOMPATRVALUEBINDING,NODBCS,NODECLTY
>>> PE,NODE
>>> LEGA
>>> DEPENDENTBASELOOKUP,NODOLLARINNAMES,EMPTYSTRUCT,NOEXTENDEDFRIEND,NOEX
>>> TENDEDI
>>> NTEG
>>> EXTERNTEMPLATE,ILLPTOM,IMPLICITINT,NOINLINENAMESPACE,LIBEXT,LONGLONG,
>>> NONEWEX
>>> CP,O
>>> NOOLDDIGRAPH,OLDFRIEND,NOOLDMATH,NOOLDSTR,OLDTEMPACC,NOOLDTMPLALIGN,O
>>> LDTMPLS
>>> PEC,
>>> NOTEMPSASLOCALS,NOTEXTAFTERENDIF,GNU_LABELVALUE,GNU_COMPUTEDGOTO,TRAI
>>> LENUM,T
>>> YPED
>>> VARARGMACROS,NOVARIADICTEMPLATES,GNU_INCLUDE_NEXT,ZEROEXTARRAY,NOC99C
>>> OMPLEX,
>>> NOC9
>>> NOGNU_COMPLEX,GNU_SUFFIXIJ)
>>>
>>>
>>> Charles
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>>> On Behalf Of David Crayford
>>> Sent: Thursday, July 25, 2013 7:42 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Looking for help with an obscure C integer problem
>>>
>>> I think I see your problem. Try compiling with LANGLVL(LONGLONG).
>
>--
>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: Looking for help with an obscure C integer problem

[Lizette Koehler]

Charles,

You are a vendor and may have found a problem with the C integer process.  It 
would be of benefit to the community when you find something like this to 
report even if you do not get benefit directly.

Instead you get an indirect benefit of helping the community and preventing 
someone else hours of searching and testing.

If there was something wrong with one of your processes, would you want your 
customer to say - it is not worth it.  Or would you want it reported so you can 
fix it.

Just my 2 cents worth


Lizette

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Saturday, July 27, 2013 7:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem

last bug I reported I invested hours and hours and ultimately received zero 
benefit.

Charles
Composed on a mobile: please excuse my brevity 

Bernd Oppolzer  wrote:

>If this were a problem that I had to solve, I would now contact IBM 
>support and tell them that in the second call to ffs the compiler 
>always puts a zero argument into the call argument list, although it 
>should put the result of the
>32 bit right shift there. There is clear evidence for this from the 
>ASSEMBLER resolution that you posted yesterday. This is a compiler bug 
>IMHO. There were no differing opinions from others so far.
>
>Kind regards
>
>Bernd
>
>
>
>Am 27.07.2013 13:59, schrieb Charles Mills:
>> It's not formatted terrifically for copying and  pasting here but 
>> LONGLONG shows up in the listing as one of the suboptions of LANGLVL 
>> under Compiler Options.
>>
>> LANGLVL(ANONSTRUCT,ANONUNION,ANSIFOR,ANSISINIT,NOAUTOTYPEDEDUCTION,C9
>> 9VLA,C9
>> 9__F
>> NOC99LONGLONG,NOC99PREPROCESSOR,NOCOMPATRVALUEBINDING,NODBCS,NODECLTY
>> PE,NODE
>> LEGA
>> DEPENDENTBASELOOKUP,NODOLLARINNAMES,EMPTYSTRUCT,NOEXTENDEDFRIEND,NOEX
>> TENDEDI
>> NTEG
>> EXTERNTEMPLATE,ILLPTOM,IMPLICITINT,NOINLINENAMESPACE,LIBEXT,LONGLONG,
>> NONEWEX
>> CP,O
>> NOOLDDIGRAPH,OLDFRIEND,NOOLDMATH,NOOLDSTR,OLDTEMPACC,NOOLDTMPLALIGN,O
>> LDTMPLS
>> PEC,
>> NOTEMPSASLOCALS,NOTEXTAFTERENDIF,GNU_LABELVALUE,GNU_COMPUTEDGOTO,TRAI
>> LENUM,T
>> YPED
>> VARARGMACROS,NOVARIADICTEMPLATES,GNU_INCLUDE_NEXT,ZEROEXTARRAY,NOC99C
>> OMPLEX,
>> NOC9
>> NOGNU_COMPLEX,GNU_SUFFIXIJ)
>>
>>
>> Charles
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of David Crayford
>> Sent: Thursday, July 25, 2013 7:42 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Looking for help with an obscure C integer problem
>>
>> I think I see your problem. Try compiling with LANGLVL(LONGLONG).

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

Re: Looking for help with an obscure C integer problem

[Bernd Oppolzer]

I was able to reproduce the problem with a little test program:


#include 
#include 

static void longtest (long long lwert)
{
   int test;
   test = lwert & 0xLL;
   if (test != 0)
   {
  printf ("lwert right = %x\n", test);
   }
   else
   {
  test = lwert >> 32;
  printf ("lwert left = %x\n", test);
   }
}

int main (void)
{
   long long lwert;
   int l1;
   int l2;
   int *p;
   char zeile [85];
   fgets (zeile, 80, stdin);
   l1 = atoi (zeile);
   fgets (zeile, 80, stdin);
   l2 = atoi (zeile);
   lwert = l1;
   lwert <<= 32;
   lwert += l2;
   p = (int *) (&lwert);
   printf ("long long first part = %x\n", *p);
   printf ("long long second part = %x\n", *(p + 1));
   longtest (lwert);
}


this was compiled using z/OS XL C version 1.11.

The error only showed up when using the compile option HGPR,
that is, when the compiler used the G-instructions, like SRAG etc.

results with HGPR:

long long first part = 8000
long long second part = 0
lwert left = 0

results without HGPR:

long long first part = 8000
long long second part = 0
lwert left = 8000

this can be confirmed by looking at the ASSEMBLER code generated in both 
cases:


with HGPR:

* longtest (lwert);
  LG   r0,lwert(,r13,304)
  ST   r0,lwert%2=>1(,r13,316)
TEST LONG LONG:
  SRAG r0,r0,32
  ST   r0,lwert%2=>1(,r13,312)
+ LG   r0,lwert%2=>1(,r13,312)
+ LTR  r0,r0
+ BE   @1L6
+ LA   r1,+CONSTANT_AREA(,r2,55)
+ ST   r0,#MX_TEMP1(,r13,228)
+ LGF  r15,=V(PRINTF)(,r3,362)
+ ST   r1,#MX_TEMP1(,r13,224)
+ LA   r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+ B@1L7
+@1L6 DS   0H
+ LA   r0,+CONSTANT_AREA(,r2,73)
+ ST   r0,#MX_TEMP1(,r13,224)
+ LGHI r0,H'0'
+ LGF  r15,=V(PRINTF)(,r3,362)
+ LA   r1,#MX_TEMP1(,r13,224)
+ ST   r0,#MX_TEMP1(,r13,228)
+ BASR r14,r15
+@1L7 DS   0H

without HGPR:

* longtest (lwert);
  Lr4,(,r13,240)
TEST LONG LONG:
  ICM  r0,b'',(r13,244
+ BE   @1L6
+ LA   r1,+CONSTANT_AREA(,r2,55)
+ ST   r0,#MX_TEMP1(,r13,228)
+ Lr15,=V(PRINTF)(,r3,302)
+ ST   r1,#MX_TEMP1(,r13,224)
+ LA   r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+ B@1L7
+@1L6 DS   0H
+ LA   r0,+CONSTANT_AREA(,r2,73)
+ LA   r5,0
+ ST   r0,#MX_TEMP1(,r13,224)
+ SRDA r4,32
+ Lr15,=V(PRINTF)(,r3,302)
+ ST   r5,#MX_TEMP1(,r13,228)
+ LA   r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+@1L7 DS   0H
*  }
  LA   r15,0

look at the SRDA instrunction, which is missing in the other case.

This is a compiler error and should be repaired by IBM support.

Kind regards

Bernd




Am 27.07.2013 17:03, schrieb Bernd Oppolzer:

don't know for C, but for problems or questions concerning
the PL/1 compiler, IBM support was always very responsive
and helpful. That's my experience, at least.

You could help them by isolating the problem with a small
test program (containing for example only this function and
a little main with a test call). Provide the compile list
with the LIST option, together with the problem description.

Kind regards

Bernd 


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

Re: Looking for help with an obscure C integer problem

[Bernd Oppolzer]

don't know for C, but for problems or questions concerning
the PL/1 compiler, IBM support was always very responsive
and helpful. That's my experience, at least.

You could help them by isolating the problem with a small
test program (containing for example only this function and
a little main with a test call). Provide the compile list
with the LIST option, together with the problem description.

Kind regards

Bernd



Am 27.07.2013 16:21, schrieb Charles Mills:

last bug I reported I invested hours and hours and ultimately received zero 
benefit.

Charles
Composed on a mobile: please excuse my brevity

Bernd Oppolzer  wrote:


If this were a problem that I had to solve, I would now contact IBM support
and tell them that in the second call to ffs the compiler always puts a
zero argument into the call argument list, although it should put the
result of the
32 bit right shift there. There is clear evidence for this from the
ASSEMBLER
resolution that you posted yesterday. This is a compiler bug IMHO. There
were
no differing opinions from others so far.

Kind regards

Bernd




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

Re: Looking for help with an obscure C integer problem

[Charles Mills]

last bug I reported I invested hours and hours and ultimately received zero 
benefit.

Charles
Composed on a mobile: please excuse my brevity 

Bernd Oppolzer  wrote:

>If this were a problem that I had to solve, I would now contact IBM support
>and tell them that in the second call to ffs the compiler always puts a
>zero argument into the call argument list, although it should put the 
>result of the
>32 bit right shift there. There is clear evidence for this from the 
>ASSEMBLER
>resolution that you posted yesterday. This is a compiler bug IMHO. There 
>were
>no differing opinions from others so far.
>
>Kind regards
>
>Bernd
>
>
>
>Am 27.07.2013 13:59, schrieb Charles Mills:
>> It's not formatted terrifically for copying and  pasting here but LONGLONG
>> shows up in the listing as one of the suboptions of LANGLVL under Compiler
>> Options.
>>
>> LANGLVL(ANONSTRUCT,ANONUNION,ANSIFOR,ANSISINIT,NOAUTOTYPEDEDUCTION,C99VLA,C9
>> 9__F
>> NOC99LONGLONG,NOC99PREPROCESSOR,NOCOMPATRVALUEBINDING,NODBCS,NODECLTYPE,NODE
>> LEGA
>> DEPENDENTBASELOOKUP,NODOLLARINNAMES,EMPTYSTRUCT,NOEXTENDEDFRIEND,NOEXTENDEDI
>> NTEG
>> EXTERNTEMPLATE,ILLPTOM,IMPLICITINT,NOINLINENAMESPACE,LIBEXT,LONGLONG,NONEWEX
>> CP,O
>> NOOLDDIGRAPH,OLDFRIEND,NOOLDMATH,NOOLDSTR,OLDTEMPACC,NOOLDTMPLALIGN,OLDTMPLS
>> PEC,
>> NOTEMPSASLOCALS,NOTEXTAFTERENDIF,GNU_LABELVALUE,GNU_COMPUTEDGOTO,TRAILENUM,T
>> YPED
>> VARARGMACROS,NOVARIADICTEMPLATES,GNU_INCLUDE_NEXT,ZEROEXTARRAY,NOC99COMPLEX,
>> NOC9
>> NOGNU_COMPLEX,GNU_SUFFIXIJ)
>>
>>
>> Charles
>> -Original Message-----
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of David Crayford
>> Sent: Thursday, July 25, 2013 7:42 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Looking for help with an obscure C integer problem
>>
>> I think I see your problem. Try compiling with LANGLVL(LONGLONG).
>>
>> --
>> 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: Looking for help with an obscure C integer problem

[Bernd Oppolzer]

If this were a problem that I had to solve, I would now contact IBM support
and tell them that in the second call to ffs the compiler always puts a
zero argument into the call argument list, although it should put the 
result of the
32 bit right shift there. There is clear evidence for this from the 
ASSEMBLER
resolution that you posted yesterday. This is a compiler bug IMHO. There 
were

no differing opinions from others so far.

Kind regards

Bernd



Am 27.07.2013 13:59, schrieb Charles Mills:

It's not formatted terrifically for copying and  pasting here but LONGLONG
shows up in the listing as one of the suboptions of LANGLVL under Compiler
Options.

LANGLVL(ANONSTRUCT,ANONUNION,ANSIFOR,ANSISINIT,NOAUTOTYPEDEDUCTION,C99VLA,C9
9__F
NOC99LONGLONG,NOC99PREPROCESSOR,NOCOMPATRVALUEBINDING,NODBCS,NODECLTYPE,NODE
LEGA
DEPENDENTBASELOOKUP,NODOLLARINNAMES,EMPTYSTRUCT,NOEXTENDEDFRIEND,NOEXTENDEDI
NTEG
EXTERNTEMPLATE,ILLPTOM,IMPLICITINT,NOINLINENAMESPACE,LIBEXT,LONGLONG,NONEWEX
CP,O
NOOLDDIGRAPH,OLDFRIEND,NOOLDMATH,NOOLDSTR,OLDTEMPACC,NOOLDTMPLALIGN,OLDTMPLS
PEC,
NOTEMPSASLOCALS,NOTEXTAFTERENDIF,GNU_LABELVALUE,GNU_COMPUTEDGOTO,TRAILENUM,T
YPED
VARARGMACROS,NOVARIADICTEMPLATES,GNU_INCLUDE_NEXT,ZEROEXTARRAY,NOC99COMPLEX,
NOC9
NOGNU_COMPLEX,GNU_SUFFIXIJ)


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

I think I see your problem. Try compiling with LANGLVL(LONGLONG).

--
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: Looking for help with an obscure C integer problem

[Charles Mills]

It's not formatted terrifically for copying and  pasting here but LONGLONG
shows up in the listing as one of the suboptions of LANGLVL under Compiler
Options.

LANGLVL(ANONSTRUCT,ANONUNION,ANSIFOR,ANSISINIT,NOAUTOTYPEDEDUCTION,C99VLA,C9
9__F
NOC99LONGLONG,NOC99PREPROCESSOR,NOCOMPATRVALUEBINDING,NODBCS,NODECLTYPE,NODE
LEGA
DEPENDENTBASELOOKUP,NODOLLARINNAMES,EMPTYSTRUCT,NOEXTENDEDFRIEND,NOEXTENDEDI
NTEG
EXTERNTEMPLATE,ILLPTOM,IMPLICITINT,NOINLINENAMESPACE,LIBEXT,LONGLONG,NONEWEX
CP,O
NOOLDDIGRAPH,OLDFRIEND,NOOLDMATH,NOOLDSTR,OLDTEMPACC,NOOLDTMPLALIGN,OLDTMPLS
PEC,
NOTEMPSASLOCALS,NOTEXTAFTERENDIF,GNU_LABELVALUE,GNU_COMPUTEDGOTO,TRAILENUM,T
YPED
VARARGMACROS,NOVARIADICTEMPLATES,GNU_INCLUDE_NEXT,ZEROEXTARRAY,NOC99COMPLEX,
NOC9
NOGNU_COMPLEX,GNU_SUFFIXIJ)


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

I think I see your problem. Try compiling with LANGLVL(LONGLONG). 

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

Re: Looking for help with an obscure C integer problem

[David Crayford]

On 26/07/2013 8:36 AM, Bernd Oppolzer wrote:

I guess that LANGLVL(LONGLONG) is already in effect,
because LANGLVL(LONGLONG) is implicitly set with LANGLVL(EXTENDED);
if not, the compiler would not accept the long long declarations, I 
guess,

and it handles the long long variables in the beginning of the function
as 64 bit values (see the SRAG). 
I agree. I couldn't see a LANGLVL(LONGLONG). I compile using 
LANGLVL(EXTENDED0X) and LONGLONG is not the default.


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

Re: Looking for help with an obscure C integer problem

[Bernd Oppolzer]

I guess that LANGLVL(LONGLONG) is already in effect,
because LANGLVL(LONGLONG) is implicitly set with LANGLVL(EXTENDED);
if not, the compiler would not accept the long long declarations, I guess,
and it handles the long long variables in the beginning of the function
as 64 bit values (see the SRAG).

I examined the whole ASSEMBLER resolution of the function, and everything
is fine IMO with the only exception that the shift of the original 64 
bit value
in the else part yielding testWord is not present - instead ffs in the 
else part

is called with a constant zero parameter.

If this is really the ASSEMBLER resolution of the C source, this is a 
compiler

error IMO.

For further examination Charles could maybe send me the compile listing
of this function offline (if it is not too large) - with the LIST option 
set.


Or: if this is really a matter of the missing LANGLVL(LONGLONG), we should
see how the ASSEMBLER resolution changes when LANGLVL(LONGLONG)
is added.

Kind regards

Bernd



Am 26.07.2013 01:41, schrieb David Crayford:

I think I see your problem. Try compiling with LANGLVL(LONGLONG).

On 22/07/2013, at 12:17 PM, Charles Mills  wrote:


Perhaps more to the point, here are my exact options, minus only some
comments:

   TARG(LE,zOSV1R9)
#  On 1/10/11 X Y wrote that Z was on z990s
   ARCH(6)
#  Force most enums to be integers for consistency
   ENUMSIZ(INT)
#  Test of several optimization options
   AGGRCOPY HGPR LIBANSI
#  Some new optimization -- suspect these if problem!
   ROCONST
#  TEST Seems to hose up the linker if CSECT also specified
#  Uncomment to show macros -- *** V1R13 and above ***
#  SHOWM LIST PPONLY
#  Try suppressing the multi-character literal warning for Events
   SUPP(CCN5802)
#  NODLL may be necessary to make the program COBOL-loadable
   NODLL
#  XPL(OSCALL(U)) OBJECTMODEL(IBM)
#  Set the following based on optimization desired
#  0 and NOINLINE TEST or 2 and INLINE NOTEST
#  OPT(0) NOINLINE   TEST   GONUMBER
   OPT(2)   INLINE NOTEST NOGONUMBER COMPRESS
#  Turn on the LIST option - "pseudo-assembler" listing
#  LIST
#  Experiment for  - does not seem to hurt anything
   DLL(CBA)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 8:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem

Here is exact cut and paste with zero editing, complete with a typo in the
second comment. The code is unit tested on MS Visual Studio -- hence the two
#ifdef's.

// Find First Set
static inline int Ffs64(unsigned long long valueToTest)
{
// returns index of first set bit. Uses UNIX convention
where bit 1 is LSB of word for compatibilit with z/OS ffs()

static const unsigned long long lswMask =
0x;

// note Windows provides a _BitScanForward64() but I did it
this way to make it more z/OS-like for test purposes
// if we ever needed Windows efficiency, or if IBM provides
an ffs64(), then this should be re-written to take advantage

if ( valueToTest == 0 ) return 0;

unsigned int testWord;
testWord = valueToTest & lswMask;
if ( testWord != 0 )
{
// _BitScanForward returns base 0
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+1;
#else
return ffs(testWord);
#endif
}
else
{
testWord = valueToTest >> 32;
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+33;
#else
return ffs(testWord) + 32;
#endif

}
}

I have strong -- but not utterly conclusive; you know what debugging a
complex program is like -- that for the value I had in the OP --
0x0034? -- the method returns 32, implying that the final ffs()
was called with testWord = 0.

Charles

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

I'm struggling to see what is wrong with testWord = valueToTest >> 32.
There are no side effects and the sequence point is at the end of the full
expression. Can anybody enlighten me?
Charles, is the code snippet you supplied the exact test cast that is
resulting in undefined behaviour? I cannot recreate the problem and I've
tried it on five different C++ compilers, including z/OS v1.13.

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

--

Re: Looking for help with an obscure C integer problem

[David Crayford]

I think I see your problem. Try compiling with LANGLVL(LONGLONG). 

On 22/07/2013, at 12:17 PM, Charles Mills  wrote:

> Perhaps more to the point, here are my exact options, minus only some
> comments:
> 
>   TARG(LE,zOSV1R9)
> #  On 1/10/11 X Y wrote that Z was on z990s   
>   ARCH(6) 
> #  Force most enums to be integers for consistency 
>   ENUMSIZ(INT)
> #  Test of several optimization options
>   AGGRCOPY HGPR LIBANSI   
> #  Some new optimization -- suspect these if problem!  
>   ROCONST 
> #  TEST Seems to hose up the linker if CSECT also specified
> #  Uncomment to show macros -- *** V1R13 and above *** 
> #  SHOWM LIST PPONLY   
> #  Try suppressing the multi-character literal warning for Events  
>   SUPP(CCN5802)   
> #  NODLL may be necessary to make the program COBOL-loadable   
>   NODLL   
> #  XPL(OSCALL(U)) OBJECTMODEL(IBM) 
> #  Set the following based on optimization desired 
> #  0 and NOINLINE TEST or 2 and INLINE NOTEST  
> #  OPT(0) NOINLINE   TEST   GONUMBER   
>   OPT(2)   INLINE NOTEST NOGONUMBER COMPRESS  
> #  Turn on the LIST option - "pseudo-assembler" listing
> #  LIST
> #  Experiment for  - does not seem to hurt anything
>   DLL(CBA)
> 
> Charles
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Charles Mills
> Sent: Sunday, July 21, 2013 8:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Looking for help with an obscure C integer problem
> 
> Here is exact cut and paste with zero editing, complete with a typo in the
> second comment. The code is unit tested on MS Visual Studio -- hence the two
> #ifdef's.
> 
>// Find First Set
>static inline int Ffs64(unsigned long long valueToTest)
>{
>// returns index of first set bit. Uses UNIX convention
> where bit 1 is LSB of word for compatibilit with z/OS ffs()
> 
>static const unsigned long long lswMask =
> 0x;
> 
>// note Windows provides a _BitScanForward64() but I did it
> this way to make it more z/OS-like for test purposes
>// if we ever needed Windows efficiency, or if IBM provides
> an ffs64(), then this should be re-written to take advantage
> 
>if ( valueToTest == 0 ) return 0;
> 
>unsigned int testWord;
>testWord = valueToTest & lswMask;
>if ( testWord != 0 )
>{
>// _BitScanForward returns base 0
> #ifdef WIN32
>unsigned long index;
>_BitScanForward(&index, testWord);
>return index+1;
> #else
>return ffs(testWord);
> #endif
>}
>else
>{
>testWord = valueToTest >> 32;
> #ifdef WIN32
>unsigned long index;
>_BitScanForward(&index, testWord);
>return index+33;
> #else
>return ffs(testWord) + 32;
> #endif
> 
>}
>}
> 
> I have strong -- but not utterly conclusive; you know what debugging a
> complex program is like -- that for the value I had in the OP --
> 0x0034? -- the method returns 32, implying that the final ffs()
> was called with testWord = 0.
> 
> Charles
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of David Crayford
> Sent: Sunday, July 21, 2013 8:31 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Looking for help with an obscure C integer problem
> 
> I'm struggling to see what is wrong with testWord = valueToTest >> 32. 
> There are no side effects and the sequence point is at the end of the full
> expression. Can anybody enlighten me?
> Charles, is the code snippet you supplied the exact test cast that is
> resulting in undefined behaviour? I cannot recreate the problem and I've
> tried it on five different C++ compilers, including z/OS v1.13.
> 
> --
> 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: Looking for help with an obscure C integer problem

[Bernd Oppolzer]

the error on the part of the optimizer could be:

an unsigned int value shifted right by 32 is always zero
(which is right, if there are no 64 bit values around,
but wrong in this case).

Could this be the reason for the optimizer deciding here
that the argument in this case will always be zero?
That is: optimizer's fault?

Kind regards

Bernd



Am 25.07.2013 17:06, schrieb Bernd Oppolzer:

Hello Charles,

when looking at this code:

+@32L1395 DS   0H
+ LM   r15,r0,&EPA_&WSA(r1,8)
+ LGHI r2,H'0'
+ ST   r0,_CEECAA_(,r12,500)
+ ST   r2,#MX_TEMP32(,r13,196)
+ LA   r1,#MX_TEMP32(,r13,196)
+ BASR r14,r15
+ AHI  r15,H'32'

it looks to me as if the optimizer decided to always call ffs with a
constant zero argument in the second case, see the LGHI to R2,
and ST R2 into the argument list - which is wrong IMO.

in the C code we have:

if ( testWord != 0 )
{
// _BitScanForward returns base 0
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+1;
#else
return ffs(testWord);
#endif
}
else
{
testWord = valueToTest >> 32;
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+33;
#else
return ffs(testWord) + 32;
#endif

}

that is: if testWord is zero, then
it is computed to be the result of the shift,
but the generated machine code acts as if it stays as zero;
the shift and assignment to testWord is - for some reason -
moved out of the if - which is wrong, I believe.

What do others on the list who read ASSEMBLER and C think of this?

Maybe indeed a compiler problem?

Kind regards

Bernd





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

Re: Looking for help with an obscure C integer problem

[Bernd Oppolzer]

Hello Charles,

when looking at this code:

+@32L1395 DS   0H
+ LM   r15,r0,&EPA_&WSA(r1,8)
+ LGHI r2,H'0'
+ ST   r0,_CEECAA_(,r12,500)
+ ST   r2,#MX_TEMP32(,r13,196)
+ LA   r1,#MX_TEMP32(,r13,196)
+ BASR r14,r15
+ AHI  r15,H'32'


it looks to me as if the optimizer decided to always call ffs with a
constant zero argument in the second case, see the LGHI to R2,
and ST R2 into the argument list - which is wrong IMO.

in the C code we have:

if ( testWord != 0 )
{
// _BitScanForward returns base 0
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+1;
#else
return ffs(testWord);
#endif
}
else
{
testWord = valueToTest >> 32;
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+33;
#else
return ffs(testWord) + 32;
#endif

}


that is: if testWord is zero, then
it is computed to be the result of the shift,
but the generated machine code acts as if it stays as zero;
the shift and assignment to testWord is - for some reason -
moved out of the if - which is wrong, I believe.

What do others on the list who read ASSEMBLER and C think of this?

Maybe indeed a compiler problem?

Kind regards

Bernd



Am 25.07.2013 13:27, schrieb Charles Mills:

If anyone is better at this than I am and wants to bother with more
analysis, here is the LIST output of compiling the below. (Note that it is
inline, so here is where it is invoked.)

*int index = Utility::Ffs64(key);
   LG   r1,#SPILL0(,r13,448)
   SRAG r0,r1,32
   ST   r0,valueToTest%33=>32(,r13,416)
   ST   r1,valueToTest%33=>32(,r13,420)
+ LG   r0,valueToTest%33=>32(,r13,416)
+ LTGR r0,r0
+ LGR  r14,r0
+ BNE  @32L1392
   LGHI r3,H'0'
   B@32L1393
+@32L1392 DS   0H
   Lr1,ffs_ptr(,r6,908)
+ LTR  r14,r14
+ BE   @32L1395
+ ST   r0,#MX_TEMP32(,r13,196)
+ LM   r15,r0,&EPA_&WSA(r1,8)
+ ST   r0,_CEECAA_(,r12,500)
+ LA   r1,#MX_TEMP32(,r13,196)
+ BASR r14,r15
   LGFR r3,r15
   B@32L1393
+@32L1395 DS   0H
+ LM   r15,r0,&EPA_&WSA(r1,8)
+ LGHI r2,H'0'
+ ST   r0,_CEECAA_(,r12,500)
+ ST   r2,#MX_TEMP32(,r13,196)
+ LA   r1,#MX_TEMP32(,r13,196)
+ BASR r14,r15
+ AHI  r15,H'32'
   LGFR r3,r15
  @32L1393 DS   0H

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 11:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem

Here is exact cut and paste with zero editing, complete with a typo in the
second comment. The code is unit tested on MS Visual Studio -- hence the two
#ifdef's.

// Find First Set
static inline int Ffs64(unsigned long long valueToTest)
{
// returns index of first set bit. Uses UNIX convention
where bit 1 is LSB of word for compatibilit with z/OS ffs()

static const unsigned long long lswMask =
0x;

// note Windows provides a _BitScanForward64() but I did it
this way to make it more z/OS-like for test purposes
// if we ever needed Windows efficiency, or if IBM provides
an ffs64(), then this should be re-written to take advantage

if ( valueToTest == 0 ) return 0;

unsigned int testWord;
testWord = valueToTest & lswMask;
if ( testWord != 0 )
{
// _BitScanForward returns base 0
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+1;
#else
return ffs(testWord);
#endif
}
else
{
testWord = valueToTest >> 32;
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+33;
#else
return ffs(testWord) + 32;
#endif

}
}

I have strong -- but not utterly conclusive; you know what debugging a
complex program is like -- that for the value I h

Re: Looking for help with an obscure C integer problem

[David Crayford]

Need to see more of the code before the function was invoked. What's 
happening with key, where is it loaded etc.

On 25/07/2013 7:27 PM, Charles Mills wrote:

If anyone is better at this than I am and wants to bother with more
analysis, here is the LIST output of compiling the below. (Note that it is
inline, so here is where it is invoked.)

*int index = Utility::Ffs64(key);
   LG   r1,#SPILL0(,r13,448)
   SRAG r0,r1,32
   ST   r0,valueToTest%33=>32(,r13,416)
   ST   r1,valueToTest%33=>32(,r13,420)
+ LG   r0,valueToTest%33=>32(,r13,416)
+ LTGR r0,r0
+ LGR  r14,r0
+ BNE  @32L1392
   LGHI r3,H'0'
   B@32L1393
+@32L1392 DS   0H
   Lr1,ffs_ptr(,r6,908)
+ LTR  r14,r14
+ BE   @32L1395
+ ST   r0,#MX_TEMP32(,r13,196)
+ LM   r15,r0,&EPA_&WSA(r1,8)
+ ST   r0,_CEECAA_(,r12,500)
+ LA   r1,#MX_TEMP32(,r13,196)
+ BASR r14,r15
   LGFR r3,r15
   B@32L1393
+@32L1395 DS   0H
+ LM   r15,r0,&EPA_&WSA(r1,8)
+ LGHI r2,H'0'
+ ST   r0,_CEECAA_(,r12,500)
+ ST   r2,#MX_TEMP32(,r13,196)
+ LA   r1,#MX_TEMP32(,r13,196)
+ BASR r14,r15
+ AHI  r15,H'32'
   LGFR r3,r15
  @32L1393 DS   0H

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 11:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem

Here is exact cut and paste with zero editing, complete with a typo in the
second comment. The code is unit tested on MS Visual Studio -- hence the two
#ifdef's.

// Find First Set
static inline int Ffs64(unsigned long long valueToTest)
{
// returns index of first set bit. Uses UNIX convention
where bit 1 is LSB of word for compatibilit with z/OS ffs()

static const unsigned long long lswMask =
0x;

// note Windows provides a _BitScanForward64() but I did it
this way to make it more z/OS-like for test purposes
// if we ever needed Windows efficiency, or if IBM provides
an ffs64(), then this should be re-written to take advantage

if ( valueToTest == 0 ) return 0;

unsigned int testWord;
testWord = valueToTest & lswMask;
if ( testWord != 0 )
{
// _BitScanForward returns base 0
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+1;
#else
return ffs(testWord);
#endif
}
else
{
testWord = valueToTest >> 32;
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+33;
#else
return ffs(testWord) + 32;
#endif

}
}

I have strong -- but not utterly conclusive; you know what debugging a
complex program is like -- that for the value I had in the OP --
0x0034? -- the method returns 32, implying that the final ffs()
was called with testWord = 0.

--
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: Looking for help with an obscure C integer problem

[Charles Mills]

If anyone is better at this than I am and wants to bother with more
analysis, here is the LIST output of compiling the below. (Note that it is
inline, so here is where it is invoked.)

*int index = Utility::Ffs64(key);  
  LG   r1,#SPILL0(,r13,448)
  SRAG r0,r1,32
  ST   r0,valueToTest%33=>32(,r13,416) 
  ST   r1,valueToTest%33=>32(,r13,420) 
+ LG   r0,valueToTest%33=>32(,r13,416) 
+ LTGR r0,r0   
+ LGR  r14,r0  
+ BNE  @32L1392
  LGHI r3,H'0' 
  B@32L1393
+@32L1392 DS   0H  
  Lr1,ffs_ptr(,r6,908) 
+ LTR  r14,r14 
+ BE   @32L1395
+ ST   r0,#MX_TEMP32(,r13,196) 
+ LM   r15,r0,&EPA_&WSA(r1,8)  
+ ST   r0,_CEECAA_(,r12,500)   
+ LA   r1,#MX_TEMP32(,r13,196) 
+ BASR r14,r15 
  LGFR r3,r15  
  B@32L1393
+@32L1395 DS   0H  
+ LM   r15,r0,&EPA_&WSA(r1,8)  
+ LGHI r2,H'0' 
+ ST   r0,_CEECAA_(,r12,500)   
+ ST   r2,#MX_TEMP32(,r13,196) 
+ LA   r1,#MX_TEMP32(,r13,196) 
+ BASR r14,r15 
+ AHI  r15,H'32'   
  LGFR r3,r15  
 @32L1393 DS   0H  

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 11:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem

Here is exact cut and paste with zero editing, complete with a typo in the
second comment. The code is unit tested on MS Visual Studio -- hence the two
#ifdef's.

// Find First Set
static inline int Ffs64(unsigned long long valueToTest)
{
// returns index of first set bit. Uses UNIX convention
where bit 1 is LSB of word for compatibilit with z/OS ffs()

static const unsigned long long lswMask =
0x;

// note Windows provides a _BitScanForward64() but I did it
this way to make it more z/OS-like for test purposes
// if we ever needed Windows efficiency, or if IBM provides
an ffs64(), then this should be re-written to take advantage

if ( valueToTest == 0 ) return 0;

unsigned int testWord;
testWord = valueToTest & lswMask;
if ( testWord != 0 )
{
// _BitScanForward returns base 0
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+1;
#else
return ffs(testWord);
#endif
}
else
{
testWord = valueToTest >> 32;
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+33;
#else
return ffs(testWord) + 32;
#endif

}
}

I have strong -- but not utterly conclusive; you know what debugging a
complex program is like -- that for the value I had in the OP --
0x0034? -- the method returns 32, implying that the final ffs()
was called with testWord = 0.

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

Re: Looking for help with an obscure C integer problem

[Charles Mills]

Thanks all!

I decided to go with an implementation of David's algorithm below. No
external calls, and completely unit testable in Visual C++.

If I get the time I will start a new thread "why I am not reporting my
latest C compiler bug to IBM."

Charles

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

I can see nothing obviously wrong with your code.  Because the function is
inlined there could be a subtle bug near where the function is called. Can
you reproduce the problem with a simple test driver?

FWIW, I implemented ffs64() like this.

static inline int ffs64( uint64_t word ) {
 if ( word == 0 ) return 0;
 int bit = 1;
 if ( ( word & 0x ) == 0 )
 {
 word >>= 32;
 bit += 32;
 }
 if ( ( word & 0x ) == 0 )
 {
 word >>= 16;
 bit += 16;
 }
 if ( ( word & 0xFF ) == 0 )
 {
 word >>= 8;
 bit += 8;
 }
 if ( ( word & 0xF ) == 0 )
 {
 word >>= 4;
 bit += 4;
 }
 if ( ( word & 0x3 ) == 0 )
 {
 word >>= 2;
 bit += 2;
 }
 if ( ( word & 0x1 ) == 0 )
 {
 bit += 1;
 }
 return bit;
}

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

Re: Looking for help with an obscure C integer problem

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

When performing integer (not int) arithmetic with integer operands of rank 
lower than int, the operands will be promoted to either int or unsigned int.  
When adding two short or two char or a char and a short, both operands will be 
promoted to int before the addition and the result will be an int.

When any operand is of rank greater or equal to int, all operands are promoted 
to the highest rank in the expression and the arithmetic is performed on that 
type.

Operands of rank greater than int are not demoted to int.  The expression in 
question involves shifting an unsigned long long and the result will be an 
unsigned long long.  When the result is assigned to the left operand, it will 
be converted to the type of that operand.  This is true regardless of the type 
of the left operand.


- Original Message -
From: "Bernd Oppolzer" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Monday, July 22, 2013 12:18:25 PM
Subject: Re: Looking for help with an obscure C integer problem

That is another case, because the right side operands are not ints.

For ints, I saw references that all operands are promoted to ints,
if they can be represented as an int (that is true for chars, shorts etc.).

Don't know for sure about longs, for example; if long differs in size
from int, and there are longs on the right side, will they be promoted 
(that is: truncated)
to int, if there is an int on the left side, or will they be evaluated as
longs? That's the key question IMHO, and there should be a reference
in the C language description that makes it clear without doubt - but I
did not yet find such a reference - had not much time to look for it.

(IMO, it would be no good language design if such a core question
is left to the compiler builder - I don't believe it is so).

Kind regards

Bernd



Am 22.07.2013 18:27, schrieb retired-mainfra...@q.com:
> The right operand in this case is the result of evaluating the expression.  
> The quoted text is not meant to imply that operands are converted before the 
> right hand expression is evaluated.  If that were the case, then
> int x = 14.0/2.1;
> would evaluate to 7 which is demonstrably not the case.
>

--
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: Looking for help with an obscure C integer problem

[Bernd Oppolzer]

That is another case, because the right side operands are not ints.

For ints, I saw references that all operands are promoted to ints,
if they can be represented as an int (that is true for chars, shorts etc.).

Don't know for sure about longs, for example; if long differs in size
from int, and there are longs on the right side, will they be promoted 
(that is: truncated)

to int, if there is an int on the left side, or will they be evaluated as
longs? That's the key question IMHO, and there should be a reference
in the C language description that makes it clear without doubt - but I
did not yet find such a reference - had not much time to look for it.

(IMO, it would be no good language design if such a core question
is left to the compiler builder - I don't believe it is so).

Kind regards

Bernd



Am 22.07.2013 18:27, schrieb retired-mainfra...@q.com:

The right operand in this case is the result of evaluating the expression.  The 
quoted text is not meant to imply that operands are converted before the right 
hand expression is evaluated.  If that were the case, then
int x = 14.0/2.1;
would evaluate to 7 which is demonstrably not the case.



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

Re: Looking for help with an obscure C integer problem

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

The right operand in this case is the result of evaluating the expression.  The 
quoted text is not meant to imply that operands are converted before the right 
hand expression is evaluated.  If that were the case, then 
   int x = 14.0/2.1;
would evaluate to 7 which is demonstrably not the case.

- Original Message -
From: "Charles Mills" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Sunday, July 21, 2013 1:26:54 PM
Subject: Re: Looking for help with an obscure C integer problem

You are 100% correct. You nailed it. Stroustrup p. 263: "If both operands
have arithmetic type, the right operand is converted to the type of the left
preparatory to the assignment."

That explains why it fails, but not why it works Opt(0). I am going to
*guess* that Opt(0) it compiles as though I had coded testWord =
static_cast(valueToTest >> 32) while with Opt(2) it compiles
as though I had coded testWord = static_cast(valueToTest) >>
32;

In your earlier post you suggested "wasting" another long long. Yes, that's
an approach. Actually I am finished with valueToTest and can just do things
in two steps without "wasting" a variable:

valueToTest >>= 32;
testWord = valueToTest;

I am busy with other things perhaps until sometime this week but the first
thing I am going to try is simply using parentheses to attempt to "force"
the "Opt(0)" interpretation:

testWord = (valueToTest >> 32);

If that fails I will move on to more elaborate approaches. The "two
statement" approach will either work or else it is a very clear bug and I
will re-group. Will probably try the union approach at that point.

Thanks!

Charles

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

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;

--
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: Looking for help with an obscure C integer problem

[Bernd Oppolzer]

Before complaining somewhere about a compiler error,
I would strongly recommend to take a look at the assembly listing.
Not one look, but better: have another person take a second look.
It once happened to me that by looking at the assembly listing
I believed to see the evidence of a compiler error, when another person
- maybe on this list - showed me that the IMO missing instruction appeared
some thirty instructions later which made the code correct. And the error
finally turned out to be a very simple error on my part.

Kind regards

Bernd


Am 22.07.2013 16:54, schrieb Charles Mills:

Update:

- parentheses did not fix the problem: testWord = (valueToTest >>= 32);

- splitting it into two instructions did not fix the problem:

valueToTest >>= 32;
testWord = valueToTest;

- recompiling just the single module with Opt(0) rather than Opt(2) did fix
the problem.

Everything else 100% the same. It may well be the surrounding code that
causes the problem but I don't have the time at this point to try a hundred
different test cases.

I think we definitely have a compiler bug here.

I may try the union approach, or the "pure C" (no call to ffs()) code that
David suggested. I might try un-inlining the function, although that is
basically a part of the "try a hundred different things" approach.

Also, thanks David, not sure why I pulled that GONUMBER out of there. I will
give that some thought.

Charles



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

Re: Looking for help with an obscure C integer problem

[Paul Gilmartin]

On Sun, 21 Jul 2013 17:03:55 -0400, John Gilmore wrote:
>
>
>It is at the compiler's and optimizer's discretion to decide the order
>of execution for code that the C++ standard does not specifically
>define. This includes overlapping execution.
>
>
>and this may be conceded.  What is not "in the compiler's and
>optimizer's discretion" is to produce different final numerical or
>string results for different levels of optimization.
>
Agreed, with an exception.

Long ago, with a different language from a different vendor
my program program checked when optimized.  In debug
mode it ran successfully and produced the result I intended.

Reported to vendor who replied (correctly) that I had relied
(inadvertently) on a construct described the reference as
undefined, allowing the behavior to differ between different
levels of optimization.  I went away unsatisfied.

The only permissible exception is that an error should be
reported in debugging mode when the result is undefined
and no error is reported in optimized mode.

( the problem occurred because in debugging mode the
compiler generated the sequence:

STH(truncating the value)
LH   (lest a breakpoint be set here)
SLA

In optimized mode, only the:

SLA(with fixed-point overflow detected,)

I consider it a shortcoming of aboriginal S/360 design that
neither MH nor STH generates a fixed-point overflow error
when appropriate.)

-- gil

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

Re: Looking for help with an obscure C integer problem

[Charles Mills]

Update:

- parentheses did not fix the problem: testWord = (valueToTest >>= 32);

- splitting it into two instructions did not fix the problem:

valueToTest >>= 32;
testWord = valueToTest;

- recompiling just the single module with Opt(0) rather than Opt(2) did fix
the problem. 

Everything else 100% the same. It may well be the surrounding code that
causes the problem but I don't have the time at this point to try a hundred
different test cases.

I think we definitely have a compiler bug here.

I may try the union approach, or the "pure C" (no call to ffs()) code that
David suggested. I might try un-inlining the function, although that is
basically a part of the "try a hundred different things" approach.

Also, thanks David, not sure why I pulled that GONUMBER out of there. I will
give that some thought.

Charles

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

On 22/07/2013 12:17 PM, Charles Mills wrote:
>
> #  0 and NOINLINE TEST or 2 and INLINE NOTEST
> #  OPT(0) NOINLINE   TEST   GONUMBER
> OPT(2)   INLINE NOTEST NOGONUMBER COMPRESS

Are you concerned about the size of your load modules? I can understand that
in C++ code that uses STL templates but I would trade off bigger load
modules for the better diagnostics that OFFSET GONUMBER give me.

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

Re: Looking for help with an obscure C integer problem

[Charles Mills]

C++ per OP.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of retired-mainfra...@q.com
Sent: Monday, July 22, 2013 6:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem

Are you coding in C or C++?  static_cast is a C++ feature.

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

Re: Looking for help with an obscure C integer problem

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

You remember incorrectly.  The expr4essions of the right are evaluated 
accoriding to the "normal rules".  Only the final result is coerced into the 
type of the left operand.

- Original Message -
From: "Bernd Oppolzer" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Sunday, July 21, 2013 11:44:11 AM
Subject: Re: Looking for help with an obscure C integer problem

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

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

Re: Looking for help with an obscure C integer problem

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

Are you coding in C or C++?  static_cast is a C++ feature.

- Original Message -
From: "Charles Mills" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Saturday, July 20, 2013 5:36:01 PM
Subject: Re: Looking for help with an obscure C integer problem

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

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

Re: Looking for help with an obscure C integer problem

[David Crayford]

On 22/07/2013 12:17 PM, Charles Mills wrote:
   
#  0 and NOINLINE TEST or 2 and INLINE NOTEST

#  OPT(0) NOINLINE   TEST   GONUMBER
OPT(2)   INLINE NOTEST NOGONUMBER COMPRESS


Are you concerned about the size of your load modules? I can understand 
that in C++ code that uses STL templates but I would trade off bigger 
load modules

for the better diagnostics that OFFSET GONUMBER give me.


#  Turn on the LIST option - "pseudo-assembler" listing
#  LIST
#  Experiment for  - does not seem to hurt anything
DLL(CBA)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 8:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem

Here is exact cut and paste with zero editing, complete with a typo in the
second comment. The code is unit tested on MS Visual Studio -- hence the two
#ifdef's.

// Find First Set
static inline int Ffs64(unsigned long long valueToTest)
{
// returns index of first set bit. Uses UNIX convention
where bit 1 is LSB of word for compatibilit with z/OS ffs()

static const unsigned long long lswMask =
0x;

// note Windows provides a _BitScanForward64() but I did it
this way to make it more z/OS-like for test purposes
// if we ever needed Windows efficiency, or if IBM provides
an ffs64(), then this should be re-written to take advantage

if ( valueToTest == 0 ) return 0;

unsigned int testWord;
testWord = valueToTest & lswMask;
if ( testWord != 0 )
{
// _BitScanForward returns base 0
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+1;
#else
return ffs(testWord);
#endif
}
else
{
testWord = valueToTest >> 32;
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+33;
#else
return ffs(testWord) + 32;
#endif

}
}

I have strong -- but not utterly conclusive; you know what debugging a
complex program is like -- that for the value I had in the OP --
0x0034? -- the method returns 32, implying that the final ffs()
was called with testWord = 0.

Charles

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

I'm struggling to see what is wrong with testWord = valueToTest >> 32.
There are no side effects and the sequence point is at the end of the full
expression. Can anybody enlighten me?
Charles, is the code snippet you supplied the exact test cast that is
resulting in undefined behaviour? I cannot recreate the problem and I've
tried it on five different C++ compilers, including z/OS v1.13.

--
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: Looking for help with an obscure C integer problem

[David Crayford]

I can see nothing obviously wrong with your code.  Because the function 
is inlined there could be a subtle bug near where the function is 
called. Can you reproduce the problem with a simple test driver?


FWIW, I implemented ffs64() like this.

static inline int ffs64( uint64_t word )
{
if ( word == 0 ) return 0;
int bit = 1;
if ( ( word & 0x ) == 0 )
{
word >>= 32;
bit += 32;
}
if ( ( word & 0x ) == 0 )
{
word >>= 16;
bit += 16;
}
if ( ( word & 0xFF ) == 0 )
{
word >>= 8;
bit += 8;
}
if ( ( word & 0xF ) == 0 )
{
word >>= 4;
bit += 4;
}
if ( ( word & 0x3 ) == 0 )
{
word >>= 2;
bit += 2;
}
if ( ( word & 0x1 ) == 0 )
{
bit += 1;
}
return bit;
}


On 22/07/2013 11:57 AM, Charles Mills wrote:

Here is exact cut and paste with zero editing, complete with a typo in the
second comment. The code is unit tested on MS Visual Studio -- hence the two
#ifdef's.

// Find First Set
static inline int Ffs64(unsigned long long valueToTest)
{
// returns index of first set bit. Uses UNIX convention
where bit 1 is LSB of word for compatibilit with z/OS ffs()

static const unsigned long long lswMask =
0x;

// note Windows provides a _BitScanForward64() but I did it
this way to make it more z/OS-like for test purposes
// if we ever needed Windows efficiency, or if IBM provides
an ffs64(), then this should be re-written to take advantage

if ( valueToTest == 0 ) return 0;

unsigned int testWord;
testWord = valueToTest & lswMask;
if ( testWord != 0 )
{
// _BitScanForward returns base 0
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+1;
#else
return ffs(testWord);
#endif
}
else
{
testWord = valueToTest >> 32;
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+33;
#else
return ffs(testWord) + 32;
#endif

}
}

I have strong -- but not utterly conclusive; you know what debugging a
complex program is like -- that for the value I had in the OP --
0x0034? -- the method returns 32, implying that the final ffs()
was called with testWord = 0.

Charles

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

I'm struggling to see what is wrong with testWord = valueToTest >> 32.
There are no side effects and the sequence point is at the end of the full
expression. Can anybody enlighten me?
Charles, is the code snippet you supplied the exact test cast that is
resulting in undefined behaviour? I cannot recreate the problem and I've
tried it on five different C++ compilers, including z/OS v1.13.

On 22/07/2013 2:33 AM, Charles Mills wrote:

Right. There are two things here:

1. Resolving the immediate problem (and understanding exactly why it
fails might be a good first step).

2. The quality of the code. You are right; it is poor code. I try to
write pretty good code. I take no pride in avoiding the use of
unnecessary parentheses. I confess, I (a.) failed to consider that
testWord = valueToTest >> 32 would not reliably operate as intended;
and (b.) I was completely satisfied when the function passed basic
unit tests and though no more of it. Lesson learned, hopefully. Not
certain exactly what the lesson is, but I will be more careful in the
future. I have learned to be cautious about integer type conversions,
but obviously not cautious enough. I guess the lesson is just like for
sequences of logical operators: use parentheses to force what you expect.

Charles

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

Charles,
Hi, here is my opinion (and this definitely falls under the category
of "obscure C"):
You are not considering the implications of "sequence points" in your

C/C++.

"Sequence points" should not be confused with "operator precedence."
Operator precedence is determinate, sequence points are not.
I believe IBM XLC is at the C++11 level of C/C++. The C/C

Re: Looking for help with an obscure C integer problem

[Bernd Oppolzer]

Should be this way in a perfect world. But this reminds me of
the Pascal compiler on the IBM PC-RT (RS-6000 predecessor),
which produced correct results on opt level 0, incorrect results
on opt level 1 and a crashing program on opt level 2. We stopped
trying to use this machine and waited for the RS-6000; the RS-6000
Pascal was OK.

Kind regards

Bernd



Am 21.07.2013 23:03, schrieb John Gilmore:


What is not "in the compiler's and
optimizer's discretion" is to produce different final numerical or
string results for different levels of optimization.




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

Re: Looking for help with an obscure C integer problem

[Charles Mills]

Perhaps more to the point, here are my exact options, minus only some
comments:

   TARG(LE,zOSV1R9)
#  On 1/10/11 X Y wrote that Z was on z990s   
   ARCH(6) 
#  Force most enums to be integers for consistency 
   ENUMSIZ(INT)
#  Test of several optimization options
   AGGRCOPY HGPR LIBANSI   
#  Some new optimization -- suspect these if problem!  
   ROCONST 
#  TEST Seems to hose up the linker if CSECT also specified
#  Uncomment to show macros -- *** V1R13 and above *** 
#  SHOWM LIST PPONLY   
#  Try suppressing the multi-character literal warning for Events  
   SUPP(CCN5802)   
#  NODLL may be necessary to make the program COBOL-loadable   
   NODLL   
#  XPL(OSCALL(U)) OBJECTMODEL(IBM) 
#  Set the following based on optimization desired 
#  0 and NOINLINE TEST or 2 and INLINE NOTEST  
#  OPT(0) NOINLINE   TEST   GONUMBER   
   OPT(2)   INLINE NOTEST NOGONUMBER COMPRESS  
#  Turn on the LIST option - "pseudo-assembler" listing
#  LIST
#  Experiment for  - does not seem to hurt anything
   DLL(CBA)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 8:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem

Here is exact cut and paste with zero editing, complete with a typo in the
second comment. The code is unit tested on MS Visual Studio -- hence the two
#ifdef's.

// Find First Set
static inline int Ffs64(unsigned long long valueToTest)
{
// returns index of first set bit. Uses UNIX convention
where bit 1 is LSB of word for compatibilit with z/OS ffs()

static const unsigned long long lswMask =
0x;

// note Windows provides a _BitScanForward64() but I did it
this way to make it more z/OS-like for test purposes
// if we ever needed Windows efficiency, or if IBM provides
an ffs64(), then this should be re-written to take advantage

if ( valueToTest == 0 ) return 0;

unsigned int testWord;
testWord = valueToTest & lswMask;
if ( testWord != 0 )
{
// _BitScanForward returns base 0
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+1;
#else
return ffs(testWord);
#endif
}
else
{
testWord = valueToTest >> 32;
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+33;
#else
return ffs(testWord) + 32;
#endif

}
}

I have strong -- but not utterly conclusive; you know what debugging a
complex program is like -- that for the value I had in the OP --
0x0034? -- the method returns 32, implying that the final ffs()
was called with testWord = 0.

Charles

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

I'm struggling to see what is wrong with testWord = valueToTest >> 32. 
There are no side effects and the sequence point is at the end of the full
expression. Can anybody enlighten me?
Charles, is the code snippet you supplied the exact test cast that is
resulting in undefined behaviour? I cannot recreate the problem and I've
tried it on five different C++ compilers, including z/OS v1.13.

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

Re: Looking for help with an obscure C integer problem

[Charles Mills]

Here is exact cut and paste with zero editing, complete with a typo in the
second comment. The code is unit tested on MS Visual Studio -- hence the two
#ifdef's.

// Find First Set
static inline int Ffs64(unsigned long long valueToTest)
{
// returns index of first set bit. Uses UNIX convention
where bit 1 is LSB of word for compatibilit with z/OS ffs()

static const unsigned long long lswMask =
0x;

// note Windows provides a _BitScanForward64() but I did it
this way to make it more z/OS-like for test purposes
// if we ever needed Windows efficiency, or if IBM provides
an ffs64(), then this should be re-written to take advantage

if ( valueToTest == 0 ) return 0;

unsigned int testWord;
testWord = valueToTest & lswMask;
if ( testWord != 0 )
{
// _BitScanForward returns base 0
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+1;
#else
return ffs(testWord);
#endif
}
else
{
testWord = valueToTest >> 32;
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+33;
#else
return ffs(testWord) + 32;
#endif

}
}

I have strong -- but not utterly conclusive; you know what debugging a
complex program is like -- that for the value I had in the OP --
0x0034? -- the method returns 32, implying that the final ffs()
was called with testWord = 0.

Charles

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

I'm struggling to see what is wrong with testWord = valueToTest >> 32. 
There are no side effects and the sequence point is at the end of the full
expression. Can anybody enlighten me?
Charles, is the code snippet you supplied the exact test cast that is
resulting in undefined behaviour? I cannot recreate the problem and I've
tried it on five different C++ compilers, including z/OS v1.13.

On 22/07/2013 2:33 AM, Charles Mills wrote:
> Right. There are two things here:
>
> 1. Resolving the immediate problem (and understanding exactly why it 
> fails might be a good first step).
>
> 2. The quality of the code. You are right; it is poor code. I try to 
> write pretty good code. I take no pride in avoiding the use of 
> unnecessary parentheses. I confess, I (a.) failed to consider that 
> testWord = valueToTest >> 32 would not reliably operate as intended; 
> and (b.) I was completely satisfied when the function passed basic 
> unit tests and though no more of it. Lesson learned, hopefully. Not 
> certain exactly what the lesson is, but I will be more careful in the 
> future. I have learned to be cautious about integer type conversions, 
> but obviously not cautious enough. I guess the lesson is just like for 
> sequences of logical operators: use parentheses to force what you expect.
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Harry Wahl
> Sent: Sunday, July 21, 2013 11:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Looking for help with an obscure C integer problem
>
> Charles,
> Hi, here is my opinion (and this definitely falls under the category 
> of "obscure C"):
> You are not considering the implications of "sequence points" in your
C/C++.
> "Sequence points" should not be confused with "operator precedence."
> Operator precedence is determinate, sequence points are not.
> I believe IBM XLC is at the C++11 level of C/C++. The C/C++ level is 
> relevant here because there are sometimes subtle, and sometimes not so 
> subtle, differences in how sequence points apply between various 
> levels of
> C++.
> While C++11 (the most recent level of C/C++) seems to a have only 
> tiny, mostly irrelevant and evolutionary changes from prior levels of 
> C/C++; there are significant differences in how "sequence points" are 
> defined and effect execution.
> Still, C++11 and the level of the C/C++ compiler that is compiling 
> your program is only tangential to the situation you describe. Your 
> code will execute with undefined behavior regardless of what compiler 
> you use. But, knowing the level of the C/C++  compiler may be 
> important if you wish

Re: Looking for help with an obscure C integer problem

[David Crayford]

I'm struggling to see what is wrong with testWord = valueToTest >> 32. 
There are no side effects and the sequence point is at the end of the 
full expression. Can anybody enlighten me?
Charles, is the code snippet you supplied the exact test cast that is 
resulting in undefined behaviour? I cannot recreate the problem and I've 
tried it on five different C++ compilers, including z/OS v1.13.


On 22/07/2013 2:33 AM, Charles Mills wrote:

Right. There are two things here:

1. Resolving the immediate problem (and understanding exactly why it fails
might be a good first step).

2. The quality of the code. You are right; it is poor code. I try to write
pretty good code. I take no pride in avoiding the use of unnecessary
parentheses. I confess, I (a.) failed to consider that testWord =
valueToTest >> 32 would not reliably operate as intended; and (b.) I was
completely satisfied when the function passed basic unit tests and though no
more of it. Lesson learned, hopefully. Not certain exactly what the lesson
is, but I will be more careful in the future. I have learned to be cautious
about integer type conversions, but obviously not cautious enough. I guess
the lesson is just like for sequences of logical operators: use parentheses
to force what you expect.

Charles

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

Charles,
Hi, here is my opinion (and this definitely falls under the category of
"obscure C"):
You are not considering the implications of "sequence points" in your C/C++.
"Sequence points" should not be confused with "operator precedence."
Operator precedence is determinate, sequence points are not.
I believe IBM XLC is at the C++11 level of C/C++. The C/C++ level is
relevant here because there are sometimes subtle, and sometimes not so
subtle, differences in how sequence points apply between various levels of
C++.
While C++11 (the most recent level of C/C++) seems to a have only tiny,
mostly irrelevant and evolutionary changes from prior levels of C/C++; there
are significant differences in how "sequence points" are defined and effect
execution.
Still, C++11 and the level of the C/C++ compiler that is compiling your
program is only tangential to the situation you describe. Your code will
execute with undefined behavior regardless of what compiler you use. But,
knowing the level of the C/C++  compiler may be important if you wish to
reconcile why it behaves one way sometimes and other ways other times (e.g.
on a different z/OS).
To me, your failure to consider the subtle impact of sequence points renders
your code ambiguous and subject to undefined behavior. This manifests
itself, for example, by executing differently when optimized. It is at the
compiler's and optimizer's discretion to decide the order of execution for
code that the C++ standard does not specifically define. This includes
overlapping execution.
I think the C/C++ compiler and optimizer are working exactly as specified by
applicable ISO/IEC standards.
"The fault, dear Brutus, it not in our stars,But, in ourselves, that we are
underlings"
Cassius in Shakespeare's Julius Caesar

--
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: Looking for help with an obscure C integer problem

[John Gilmore]

Harry Wahl wrote:


It is at the compiler's and optimizer's discretion to decide the order
of execution for code that the C++ standard does not specifically
define. This includes overlapping execution.


and this may be conceded.  What is not "in the compiler's and
optimizer's discretion" is to produce different final numerical or
string results for different levels of optimization.

Even notionally strange behavior, which violates naif notions of
minimal surprise, may be entirely appropriate   Inconsistent behavior
as a function of optimization level is not.

Viewed as a black box, the behavior of a a program must be
deterministic in the sense that that a set I of inputs always produces
the same set O of outputs.   (If there are pseudo-random number
generators or the like somewhere in the stew it may be necessary to
specify O probabilistically, but nothing of that sort is involved
here.)

Moreover, 'sequence points' as I understand them do not differ from
one compilation of an unaltered source program to another (although
their treatment by different compilers may).

Finally, the phrase "This includes overlapping execution" is a
diversion here.  The only sort of overlapping execution that this
compiler and optimizer support, indirectly, is that realized by
explicit execution-time multiprogramming.  In a word, this phrase is
not seriös here.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Looking for help with an obscure C integer problem

[Charles Mills]

Right. There are two things here:

1. Resolving the immediate problem (and understanding exactly why it fails
might be a good first step).

2. The quality of the code. You are right; it is poor code. I try to write
pretty good code. I take no pride in avoiding the use of unnecessary
parentheses. I confess, I (a.) failed to consider that testWord =
valueToTest >> 32 would not reliably operate as intended; and (b.) I was
completely satisfied when the function passed basic unit tests and though no
more of it. Lesson learned, hopefully. Not certain exactly what the lesson
is, but I will be more careful in the future. I have learned to be cautious
about integer type conversions, but obviously not cautious enough. I guess
the lesson is just like for sequences of logical operators: use parentheses
to force what you expect.

Charles

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

Charles,
Hi, here is my opinion (and this definitely falls under the category of
"obscure C"):
You are not considering the implications of "sequence points" in your C/C++.
"Sequence points" should not be confused with "operator precedence."
Operator precedence is determinate, sequence points are not.
I believe IBM XLC is at the C++11 level of C/C++. The C/C++ level is
relevant here because there are sometimes subtle, and sometimes not so
subtle, differences in how sequence points apply between various levels of
C++. 
While C++11 (the most recent level of C/C++) seems to a have only tiny,
mostly irrelevant and evolutionary changes from prior levels of C/C++; there
are significant differences in how "sequence points" are defined and effect
execution. 
Still, C++11 and the level of the C/C++ compiler that is compiling your
program is only tangential to the situation you describe. Your code will
execute with undefined behavior regardless of what compiler you use. But,
knowing the level of the C/C++  compiler may be important if you wish to
reconcile why it behaves one way sometimes and other ways other times (e.g.
on a different z/OS).
To me, your failure to consider the subtle impact of sequence points renders
your code ambiguous and subject to undefined behavior. This manifests
itself, for example, by executing differently when optimized. It is at the
compiler's and optimizer's discretion to decide the order of execution for
code that the C++ standard does not specifically define. This includes
overlapping execution.
I think the C/C++ compiler and optimizer are working exactly as specified by
applicable ISO/IEC standards.
"The fault, dear Brutus, it not in our stars,But, in ourselves, that we are
underlings"
Cassius in Shakespeare's Julius Caesar

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

Re: Looking for help with an obscure C integer problem

[Charles Mills]

You are 100% correct. You nailed it. Stroustrup p. 263: "If both operands
have arithmetic type, the right operand is converted to the type of the left
preparatory to the assignment."

That explains why it fails, but not why it works Opt(0). I am going to
*guess* that Opt(0) it compiles as though I had coded testWord =
static_cast(valueToTest >> 32) while with Opt(2) it compiles
as though I had coded testWord = static_cast(valueToTest) >>
32;

In your earlier post you suggested "wasting" another long long. Yes, that's
an approach. Actually I am finished with valueToTest and can just do things
in two steps without "wasting" a variable:

valueToTest >>= 32;
testWord = valueToTest;

I am busy with other things perhaps until sometime this week but the first
thing I am going to try is simply using parentheses to attempt to "force"
the "Opt(0)" interpretation:

testWord = (valueToTest >> 32);

If that fails I will move on to more elaborate approaches. The "two
statement" approach will either work or else it is a very clear bug and I
will re-group. Will probably try the union approach at that point.

Thanks!

Charles

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

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;

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

Re: Looking for help with an obscure C integer problem

[Harry Wahl]

Charles,
Hi, here is my opinion (and this definitely falls under the category of 
"obscure C"):
You are not considering the implications of "sequence points" in your C/C++. 
"Sequence points" should not be confused with "operator precedence." Operator 
precedence is determinate, sequence points are not.
I believe IBM XLC is at the C++11 level of C/C++. The C/C++ level is relevant 
here because there are sometimes subtle, and sometimes not so subtle, 
differences in how sequence points apply between various levels of C++. 
While C++11 (the most recent level of C/C++) seems to a have only tiny, mostly 
irrelevant and evolutionary changes from prior levels of C/C++; there are 
significant differences in how "sequence points" are defined and effect 
execution. 
Still, C++11 and the level of the C/C++ compiler that is compiling your program 
is only tangential to the situation you describe. Your code will execute with 
undefined behavior regardless of what compiler you use. But, knowing the level 
of the C/C++  compiler may be important if you wish to reconcile why it behaves 
one way sometimes and other ways other times (e.g. on a different z/OS).
To me, your failure to consider the subtle impact of sequence points renders 
your code ambiguous and subject to undefined behavior. This manifests itself, 
for example, by executing differently when optimized. It is at the compiler's 
and optimizer's discretion to decide the order of execution for code that the 
C++ standard does not specifically define. This includes overlapping execution.
I think the C/C++ compiler and optimizer are working exactly as specified by 
applicable ISO/IEC standards.
"The fault, dear Brutus, it not in our stars,But, in ourselves, that we are 
underlings"
Cassius in Shakespeare's Julius Caesar

Harry



> Date: Sat, 20 Jul 2013 13:24:29 -0700
> From: charl...@mcn.org
> Subject: Looking for help with an obscure C integer problem
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> 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?
> 
> 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

Re: Looking for help with an obscure C integer problem

[Bernd Oppolzer]

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

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

Re: Looking for help with an obscure C integer problem

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

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

Re: Looking for help with an obscure C integer problem

[Charles Mills]

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

Re: Looking for help with an obscure C integer problem

[David Crayford]

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