Re: Looking for help with an obscure C integer problem
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
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 bernd.oppol...@t-online.de
An: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
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 stdio.h
#include stdlib.h
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,a1:d240:l4(,r13,240)
TEST LONG LONG:
ICM r0,b'',a1:d244:l4(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
Re: Looking for help with an obscure C integer problem
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 bernd.oppol...@t-online.de
An: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU
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 stdio.h
#include stdlib.h
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
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'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 the problem, even while prodding me for a statement of business impact (which I supplied, acknowledging that I was working on a PoC). -- For IBM-MAIN subscribe / signoff / archive access
Re: Looking for help with an obscure C integer problem
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 me. Thanks for
Re: Looking for help with an obscure C integer problem
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's the garbage and the S0C4
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 bernd.oppol...@t-online.de 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 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
Re: Looking for help with an obscure C integer problem
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 stars...@mindspring.com 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 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
Re: Looking for help with an obscure C integer problem
In 51f3e14d.20...@t-online.de, on 07/27/2013 at 05:03 PM, Bernd Oppolzer bernd.oppol...@t-online.de 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/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
In 3399683725614169.wa.paulgboulderaim@listserv.ua.edu, on 07/27/2013 at 02:08 PM, Paul Gilmartin paulgboul...@aim.com 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/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
In 001001ce8b97$9def20a0$d9cd61e0$@mcn.org, on 07/28/2013 at 09:37 AM, Charles Mills charl...@mcn.org 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/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
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 stdio.h
#include stdlib.h
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,a1:d240:l4(,r13,240)
TEST LONG LONG:
ICM r0,b'',a1:d244:l4(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
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 bernd.oppol...@t-online.de 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
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
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
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 bernd.oppol...@t-online.de 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
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 bernd.oppol...@t-online.de 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
I was able to reproduce the problem with a little test program:
#include stdio.h
#include stdlib.h
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,a1:d240:l4(,r13,240)
TEST LONG LONG:
ICM r0,b'',a1:d244:l4(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
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 bernd.oppol...@t-online.de 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
I hear you. If I get the time I will explain my thoughts. Charles Composed on a mobile: please excuse my brevity Lizette Koehler stars...@mindspring.com 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 bernd.oppol...@t-online.de 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
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
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
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
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
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
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
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
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 had in the OP --
0x0034? -- the method returns 32, implying that the final ffs()
was called with testWord = 0
Re: Looking for help with an obscure C integer problem
I think I see your problem. Try compiling with LANGLVL(LONGLONG).
On 22/07/2013, at 12:17 PM, Charles Mills charl...@mcn.org 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
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 charl...@mcn.org 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
Re: Looking for help with an obscure C integer problem
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
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
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++ 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
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.
# 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: [MVS-OE] Looking for help with an obscure C integer problem
Well I think it is a bug.
the following source:
#include stdio.h
#include stdlib.h
#include stdint.h
#include string.h
int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n 32;
printf( %08X %08X\n, b);
}
With OPT(0) it generated:
LARL r5,F'46'
* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
ST r0,n(,r13,160)
LA r2,0
ST r2,n(,r13,164)
* uint32_t b = n 32;
Lr6,n(,r13,160)
Lr7,n(,r13,164)
SRDL r6,32
LR r0,r7
ST r0,b(,r13,168)
*
* printf( %08X %08X\n, b);
Lr15,=V(PRINTF)(,r3,102)
LR r4,r5
LA r1,#MX_TEMP1(,r13,152)
ST r4,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
BASR r14,r15
LR r15,r2
and printed: 0034*0034*
With OPT(3) it generated:
* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
* uint32_t b = n 32;
*
* printf( %08X %08X\n, b);
LARL r1,F'26'
Lr15,=V(PRINTF)(,r3,74)
ST r1,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
LA r1,#MX_TEMP1(,r13,152)
BASR r14,r15* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
* uint32_t b = n 32;
*
* printf( %08X %08X\n, b);
LARL r1,F'26'
Lr15,=V(PRINTF)(,r3,74)
ST r1,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
LA r1,#MX_TEMP1(,r13,152)
BASR r14,r15
* }
LA r15,0
and printed: 0034 *1000*
This is z/OS 1.13. I am not sure about the C compiler maintenance
level, but I can check.
regards, Tom
On 2013-07-22 12:00 AM, IBM-MAIN automatic digest system wrote:
Date: Sun, 21 Jul 2013 20:42:54 +0800 From: David Crayford
dcrayf...@gmail.com Subject: Re: [MVS-OE] Looking for help with an
obscure C integer problem On 21/07/2013 8:40 PM, Shmuel Metz (Seymour
J.) wrote:
In51eb3a4c.8010...@gmail.com, on 07/21/2013
at 09:33 AM, David Crayforddcrayf...@gmail.com said:
I don't like it because it's a hack to work around an puzzling
issue. I want to know why the optimizer is not generating the
correct code.
Why not report it as a bug?
We don't know if it is a bug without seeing Charles code asis.
--
G. Tom Russell
“Stay calm. Be brave. Wait for the signs.” — Jasper FriendlyBear
“... and remember to leave good news alone.” — Gracie HeavyHand
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [MVS-OE] Looking for help with an obscure C integer problem
The bug is in your code. Your only passing one argument to printf().
On 22/07/2013, at 8:38 PM, Tom Russell tom_russ...@sympatico.ca wrote:
Well I think it is a bug.
the following source:
#include stdio.h
#include stdlib.h
#include stdint.h
#include string.h
int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n 32;
printf( %08X %08X\n, b);
}
With OPT(0) it generated:
LARL r5,F'46'
* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
ST r0,n(,r13,160)
LA r2,0
ST r2,n(,r13,164)
* uint32_t b = n 32;
Lr6,n(,r13,160)
Lr7,n(,r13,164)
SRDL r6,32
LR r0,r7
ST r0,b(,r13,168)
*
* printf( %08X %08X\n, b);
Lr15,=V(PRINTF)(,r3,102)
LR r4,r5
LA r1,#MX_TEMP1(,r13,152)
ST r4,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
BASR r14,r15
LR r15,r2
and printed: 0034*0034*
With OPT(3) it generated:
* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
* uint32_t b = n 32;
*
* printf( %08X %08X\n, b);
LARL r1,F'26'
Lr15,=V(PRINTF)(,r3,74)
ST r1,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
LA r1,#MX_TEMP1(,r13,152)
BASR r14,r15* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
* uint32_t b = n 32;
*
* printf( %08X %08X\n, b);
LARL r1,F'26'
Lr15,=V(PRINTF)(,r3,74)
ST r1,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
LA r1,#MX_TEMP1(,r13,152)
BASR r14,r15
* }
LA r15,0
and printed: 0034 *1000*
This is z/OS 1.13. I am not sure about the C compiler maintenance level, but
I can check.
regards, Tom
On 2013-07-22 12:00 AM, IBM-MAIN automatic digest system wrote:
Date: Sun, 21 Jul 2013 20:42:54 +0800 From: David Crayford
dcrayf...@gmail.com Subject: Re: [MVS-OE] Looking for help with an obscure
C integer problem On 21/07/2013 8:40 PM, Shmuel Metz (Seymour J.) wrote:
In51eb3a4c.8010...@gmail.com, on 07/21/2013
at 09:33 AM, David Crayforddcrayf...@gmail.com said:
I don't like it because it's a hack to work around an puzzling
issue. I want to know why the optimizer is not generating the
correct code.
Why not report it as a bug?
We don't know if it is a bug without seeing Charles code asis.
--
G. Tom Russell
“Stay calm. Be brave. Wait for the signs.” — Jasper FriendlyBear
“... and remember to leave good news alone.” — Gracie HeavyHand
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
Are you coding in C or C++? static_cast is a C++ feature.
- Original Message -
From: Charles Mills charl...@mcn.org
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_castunsigned long long(valueToTest
32) might not solve the problem because that cast seems to me to imply
that the expression inside the parentheses is *not* 64 bits.
Frankly, I am now leaning toward
union {
unsigned long long ll;
struct {unsigned int hi; unsigned int lo} s; } u;
u.ll = valueToTest;
and then using u.s.hi where I now use testWord.
I generally avoid unions because they can be a tad problematic. I think the
above actually violates the C standard which says you can't assign to member
x and then read member y (which pretty much negates the whole purpose of
unions other than, as Stroustrup suggests, saving space in memory).
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Saturday, July 20, 2013 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
As a general ROT I always use explicit casts.
On 21/07/2013, at 4:24 AM, Charles Mills charl...@mcn.org wrote:
Cross-posted to IBM-MAIN and MVS-OE.
I have the following code fragment in an inline function, compiled by
the IBM XLC compiler as C++:
unsigned long long valueToTest;
unsigned int testWord;
testWord = valueToTest 32;
It *appears* to me (from somewhat circumstantial evidence in a much
more complex big picture) when valueToTest has a value of
0x0034 then
- If I compile Opt(0),NoInline then testWord gets the value I expect,
0x0034; but
- If I compile Opt(2),Inline then testWord gets a value of 0.
Questions:
1. Does that seem plausible? That the code would work as intended
Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am
guessing here) first cast valueToTest to an int of 0, then shift it
right 32, and then assign it to testWord?
2. What should I code to avoid that? I guess I could shift valueToTest
first (I don't need it again) and then in a separate statement assign
it to testWord. Is that the proper coding technique?
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: [MVS-OE] Looking for help with an obscure C integer problem
Since the evaluated expression is automatically converted to the type of the
left operand aspart of the assignment process, what purpose does the cast serve?
- Original Message -
From: David Crayford dcrayf...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Saturday, July 20, 2013 8:06:37 PM
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
Your casting a uint64_t to a uint64_t which is pointless. You should
cast to the return value (uint32_t).
I've just tried your example and I can't recreate the problem, with or
without casts and compiled with both OPT and NOOPT.
#include stdio.h
#include stdlib.h
#include stdint.h
#include string.h
int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n 32;
uint32_t c = static_castuint32_t(n 32);
printf( %08X %08X\n, b, c );
}
I can only assume that the optimizer is throwing away valueToTest for
some arcane reason. I've seen this happen with convoluted code with lots
of pointers to pointers etc.
Try qualifying valueToTest with volatile, which should disable
optimizations on that variable.
On 21/07/2013 8:27 AM, Charles Mills wrote:
Hmmm. Not following your logic but I may give it a try.
Charles
-Original Message-
From: MVS OpenEdition [mailto:mvs...@vm.marist.edu] On Behalf Of David
Crayford
Sent: Saturday, July 20, 2013 4:51 PM
To: mvs...@vm.marist.edu
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
If static_castuint32_t(valueToTest 32) doesn't fix it then the compiler
is broken. Note the cast to uint32_t not uint64_t.
On 21/07/2013, at 6:36 AM, Charles Mills charl...@mcn.org wrote:
Thanks. How would I solve this with a cast? I can force it to be wrong
LOL but can I force it to be right?
It seems to me like testWord = static_castunsigned long
long(valueToTest
32) might not solve the problem because that cast seems to me to
imply
that the expression inside the parentheses is *not* 64 bits.
Frankly, I am now leaning toward
union {
unsigned long long ll;
struct {unsigned int hi; unsigned int lo} s; } u;
u.ll = valueToTest;
and then using u.s.hi where I now use testWord.
I generally avoid unions because they can be a tad problematic. I
think the above actually violates the C standard which says you can't
assign to member x and then read member y (which pretty much negates
the whole purpose of unions other than, as Stroustrup suggests, saving
space in memory).
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of David Crayford
Sent: Saturday, July 20, 2013 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
As a general ROT I always use explicit casts.
On 21/07/2013, at 4:24 AM, Charles Mills charl...@mcn.org wrote:
Cross-posted to IBM-MAIN and MVS-OE.
I have the following code fragment in an inline function, compiled by
the IBM XLC compiler as C++:
unsigned long long valueToTest;
unsigned int testWord;
testWord = valueToTest 32;
It *appears* to me (from somewhat circumstantial evidence in a much
more complex big picture) when valueToTest has a value of
0x0034 then
- If I compile Opt(0),NoInline then testWord gets the value I expect,
0x0034; but
- If I compile Opt(2),Inline then testWord gets a value of 0.
Questions:
1. Does that seem plausible? That the code would work as intended
Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am
guessing here) first cast valueToTest to an int of 0, then shift it
right 32, and then assign it to testWord?
2. What should I code to avoid that? I guess I could shift
valueToTest first (I don't need it again) and then in a separate
statement assign it to testWord. Is that the proper coding technique?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [MVS-OE] Looking for help with an obscure C integer problem
I use them so that the reader of the code knows for certain sure that I did intend to change from one precision to another, with possible loss of information. Also, I like to compile with all messages enabled and still get no warnings. I do a fair amount of unnecessary coding to get an RC of 0, rather than 4. I'm a bit OCD about that. I compile open source software on Linux some times and just cringe at all the warnings that are produced. On Mon, Jul 22, 2013 at 8:23 AM, retired-mainfra...@q.com retired-mainfra...@q.com wrote: Since the evaluated expression is automatically converted to the type of the left operand aspart of the assignment process, what purpose does the cast serve? -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
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 bernd.oppol...@t-online.de 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: [MVS-OE] Looking for help with an obscure C integer problem
No purpose at all. Merely clutching at straws trying to circumvent Charles
rather baffling problem. It's not uncommon to see casts like that but it is
unnecessary. Of course going the other way does require casts for conversion.
unsigned int anUInt = 0xc000;
long long aLongLong = (long long)anUInt 2; // 0x3 (correct)
C/C++ integral promotion rules can be a pitfall for the novice.
On 22/07/2013, at 9:23 PM, retired-mainfra...@q.com
retired-mainfra...@q.com wrote:
Since the evaluated expression is automatically converted to the type of the
left operand aspart of the assignment process, what purpose does the cast
serve?
- Original Message -
From: David Crayford dcrayf...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Saturday, July 20, 2013 8:06:37 PM
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
Your casting a uint64_t to a uint64_t which is pointless. You should
cast to the return value (uint32_t).
I've just tried your example and I can't recreate the problem, with or
without casts and compiled with both OPT and NOOPT.
#include stdio.h
#include stdlib.h
#include stdint.h
#include string.h
int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n 32;
uint32_t c = static_castuint32_t(n 32);
printf( %08X %08X\n, b, c );
}
I can only assume that the optimizer is throwing away valueToTest for
some arcane reason. I've seen this happen with convoluted code with lots
of pointers to pointers etc.
Try qualifying valueToTest with volatile, which should disable
optimizations on that variable.
On 21/07/2013 8:27 AM, Charles Mills wrote:
Hmmm. Not following your logic but I may give it a try.
Charles
-Original Message-
From: MVS OpenEdition [mailto:mvs...@vm.marist.edu] On Behalf Of David
Crayford
Sent: Saturday, July 20, 2013 4:51 PM
To: mvs...@vm.marist.edu
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
If static_castuint32_t(valueToTest 32) doesn't fix it then the compiler
is broken. Note the cast to uint32_t not uint64_t.
On 21/07/2013, at 6:36 AM, Charles Mills charl...@mcn.org wrote:
Thanks. How would I solve this with a cast? I can force it to be wrong
LOL but can I force it to be right?
It seems to me like testWord = static_castunsigned long
long(valueToTest
32) might not solve the problem because that cast seems to me to
imply
that the expression inside the parentheses is *not* 64 bits.
Frankly, I am now leaning toward
union {
unsigned long long ll;
struct {unsigned int hi; unsigned int lo} s; } u;
u.ll = valueToTest;
and then using u.s.hi where I now use testWord.
I generally avoid unions because they can be a tad problematic. I
think the above actually violates the C standard which says you can't
assign to member x and then read member y (which pretty much negates
the whole purpose of unions other than, as Stroustrup suggests, saving
space in memory).
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of David Crayford
Sent: Saturday, July 20, 2013 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
As a general ROT I always use explicit casts.
On 21/07/2013, at 4:24 AM, Charles Mills charl...@mcn.org wrote:
Cross-posted to IBM-MAIN and MVS-OE.
I have the following code fragment in an inline function, compiled by
the IBM XLC compiler as C++:
unsigned long long valueToTest;
unsigned int testWord;
testWord = valueToTest 32;
It *appears* to me (from somewhat circumstantial evidence in a much
more complex big picture) when valueToTest has a value of
0x0034 then
- If I compile Opt(0),NoInline then testWord gets the value I expect,
0x0034; but
- If I compile Opt(2),Inline then testWord gets a value of 0.
Questions:
1. Does that seem plausible? That the code would work as intended
Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am
guessing here) first cast valueToTest to an int of 0, then shift it
right 32, and then assign it to testWord?
2. What should I code to avoid that? I guess I could shift
valueToTest first (I don't need it again) and then in a separate
statement assign it to testWord. Is that the proper coding technique?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email
Re: Looking for help with an obscure C integer problem
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
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
On Sun, 21 Jul 2013 17:03:55 -0400, John Gilmore wrote: begin extract 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. /end extract 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: [MVS-OE] Looking for help with an obscure C integer problem
With the constant 0x0034... as a literal in the code the compiler is able to
short-circuit the shift entirely.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Russell
Sent: Monday, July 22, 2013 5:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
Well I think it is a bug.
the following source:
#include stdio.h
#include stdlib.h
#include stdint.h
#include string.h
int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n 32;
printf( %08X %08X\n, b);
}
With OPT(0) it generated:
LARL r5,F'46'
* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
ST r0,n(,r13,160)
LA r2,0
ST r2,n(,r13,164)
* uint32_t b = n 32;
Lr6,n(,r13,160)
Lr7,n(,r13,164)
SRDL r6,32
LR r0,r7
ST r0,b(,r13,168)
*
* printf( %08X %08X\n, b);
Lr15,=V(PRINTF)(,r3,102)
LR r4,r5
LA r1,#MX_TEMP1(,r13,152)
ST r4,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
BASR r14,r15
LR r15,r2
and printed: 0034*0034*
With OPT(3) it generated:
* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
* uint32_t b = n 32;
*
* printf( %08X %08X\n, b);
LARL r1,F'26'
Lr15,=V(PRINTF)(,r3,74)
ST r1,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
LA r1,#MX_TEMP1(,r13,152)
BASR r14,r15* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
* uint32_t b = n 32;
*
* printf( %08X %08X\n, b);
LARL r1,F'26'
Lr15,=V(PRINTF)(,r3,74)
ST r1,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
LA r1,#MX_TEMP1(,r13,152)
BASR r14,r15
* }
LA r15,0
and printed: 0034 *1000*
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
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
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 charl...@mcn.org 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_castunsigned int(valueToTest 32) while with Opt(2) it compiles as though I had coded testWord = static_castunsigned int(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
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
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 bernd.oppol...@t-online.de 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: [MVS-OE] Looking for help with an obscure C integer problem
In 51eb3a4c.8010...@gmail.com, on 07/21/2013 at 09:33 AM, David Crayford dcrayf...@gmail.com said: I don't like it because it's a hack to work around an puzzling issue. I want to know why the optimizer is not generating the correct code. Why not report it as a bug? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [MVS-OE] Looking for help with an obscure C integer problem
On 21/07/2013 8:40 PM, Shmuel Metz (Seymour J.) wrote: In 51eb3a4c.8010...@gmail.com, on 07/21/2013 at 09:33 AM, David Crayford dcrayf...@gmail.com said: I don't like it because it's a hack to work around an puzzling issue. I want to know why the optimizer is not generating the correct code. Why not report it as a bug? We don't know if it is a bug without seeing Charles code asis. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [MVS-OE] Looking for help with an obscure C integer problem
Went that route on the last C compiler problem I found. Life is too short. Or at the very least, the project deadline is too short. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Sunday, July 21, 2013 5:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem In 51eb3a4c.8010...@gmail.com, on 07/21/2013 at 09:33 AM, David Crayford dcrayf...@gmail.com said: I don't like it because it's a hack to work around an puzzling issue. I want to know why the optimizer is not generating the correct code. Why not report it as a bug? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [MVS-OE] Looking for help with an obscure C integer problem
That was my attitude last time. No, I am not the least worried about competitors. One, it's a big world with room for everyone; two, the two products I work on have no head-to-head competition; and three, my impression is that an awful lot of Z commercial products are written in assembler, not C. I am just worried about my own time and sanity. In any event, even if I were to spend a bunch of my life arguing my case with IBM, I *need* a timely solution. You can't push a piece of string. I have lost patience with being more generous to IBM's customers than IBM is. They seem not to want to fix the problem (however that might be defined) so much as make their numbers by closing the ticket. IMHO. At least the level one folks; much less so once you get through to someone who knows anything. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Sunday, July 21, 2013 7:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem On Sun, 21 Jul 2013 07:08:08 -0700, Charles Mills wrote: Went that route on the last C compiler problem I found. Life is too short. Or at the very least, the project deadline is too short. View it as an act of generosity to others who may encounter the problem. Of course, if they're likely to be your competitors you may be disinclined to be generous. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
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
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
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
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_castunsigned int(valueToTest 32) while with Opt(2) it compiles as though I had coded testWord = static_castunsigned int(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
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
Harry Wahl wrote: begin extract 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. /end extract 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
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
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 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
Re: Looking for help with an obscure C integer problem
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
Looking for help with an obscure C integer problem
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
Re: Looking for help with an obscure C integer problem
As a general ROT I always use explicit casts. On 21/07/2013, at 4:24 AM, Charles Mills charl...@mcn.org wrote: Cross-posted to IBM-MAIN and MVS-OE. I have the following code fragment in an inline function, compiled by the IBM XLC compiler as C++: unsigned long long valueToTest; unsigned int testWord; testWord = valueToTest 32; It *appears* to me (from somewhat circumstantial evidence in a much more complex big picture) when valueToTest has a value of 0x0034 then - If I compile Opt(0),NoInline then testWord gets the value I expect, 0x0034; but - If I compile Opt(2),Inline then testWord gets a value of 0. Questions: 1. Does that seem plausible? That the code would work as intended Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am guessing here) first cast valueToTest to an int of 0, then shift it right 32, and then assign it to testWord? 2. What should I code to avoid that? I guess I could shift valueToTest first (I don't need it again) and then in a separate statement assign it to testWord. Is that the proper coding technique? 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
Thanks. How would I solve this with a cast? I can force it to be wrong LOL
but can I force it to be right?
It seems to me like testWord = static_castunsigned long long(valueToTest
32) might not solve the problem because that cast seems to me to imply
that the expression inside the parentheses is *not* 64 bits.
Frankly, I am now leaning toward
union {
unsigned long long ll;
struct {unsigned int hi; unsigned int lo} s; } u;
u.ll = valueToTest;
and then using u.s.hi where I now use testWord.
I generally avoid unions because they can be a tad problematic. I think the
above actually violates the C standard which says you can't assign to member
x and then read member y (which pretty much negates the whole purpose of
unions other than, as Stroustrup suggests, saving space in memory).
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Saturday, July 20, 2013 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
As a general ROT I always use explicit casts.
On 21/07/2013, at 4:24 AM, Charles Mills charl...@mcn.org wrote:
Cross-posted to IBM-MAIN and MVS-OE.
I have the following code fragment in an inline function, compiled by
the IBM XLC compiler as C++:
unsigned long long valueToTest;
unsigned int testWord;
testWord = valueToTest 32;
It *appears* to me (from somewhat circumstantial evidence in a much
more complex big picture) when valueToTest has a value of
0x0034 then
- If I compile Opt(0),NoInline then testWord gets the value I expect,
0x0034; but
- If I compile Opt(2),Inline then testWord gets a value of 0.
Questions:
1. Does that seem plausible? That the code would work as intended
Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am
guessing here) first cast valueToTest to an int of 0, then shift it
right 32, and then assign it to testWord?
2. What should I code to avoid that? I guess I could shift valueToTest
first (I don't need it again) and then in a separate statement assign
it to testWord. Is that the proper coding technique?
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: [MVS-OE] Looking for help with an obscure C integer problem
Hmmm. Not following your logic but I may give it a try.
Charles
-Original Message-
From: MVS OpenEdition [mailto:mvs...@vm.marist.edu] On Behalf Of David
Crayford
Sent: Saturday, July 20, 2013 4:51 PM
To: mvs...@vm.marist.edu
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
If static_castuint32_t(valueToTest 32) doesn't fix it then the compiler
is broken. Note the cast to uint32_t not uint64_t.
On 21/07/2013, at 6:36 AM, Charles Mills charl...@mcn.org wrote:
Thanks. How would I solve this with a cast? I can force it to be wrong
LOL but can I force it to be right?
It seems to me like testWord = static_castunsigned long
long(valueToTest
32) might not solve the problem because that cast seems to me to
imply
that the expression inside the parentheses is *not* 64 bits.
Frankly, I am now leaning toward
union {
unsigned long long ll;
struct {unsigned int hi; unsigned int lo} s; } u;
u.ll = valueToTest;
and then using u.s.hi where I now use testWord.
I generally avoid unions because they can be a tad problematic. I
think the above actually violates the C standard which says you can't
assign to member x and then read member y (which pretty much negates
the whole purpose of unions other than, as Stroustrup suggests, saving
space in memory).
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of David Crayford
Sent: Saturday, July 20, 2013 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
As a general ROT I always use explicit casts.
On 21/07/2013, at 4:24 AM, Charles Mills charl...@mcn.org wrote:
Cross-posted to IBM-MAIN and MVS-OE.
I have the following code fragment in an inline function, compiled by
the IBM XLC compiler as C++:
unsigned long long valueToTest;
unsigned int testWord;
testWord = valueToTest 32;
It *appears* to me (from somewhat circumstantial evidence in a much
more complex big picture) when valueToTest has a value of
0x0034 then
- If I compile Opt(0),NoInline then testWord gets the value I expect,
0x0034; but
- If I compile Opt(2),Inline then testWord gets a value of 0.
Questions:
1. Does that seem plausible? That the code would work as intended
Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am
guessing here) first cast valueToTest to an int of 0, then shift it
right 32, and then assign it to testWord?
2. What should I code to avoid that? I guess I could shift
valueToTest first (I don't need it again) and then in a separate
statement assign it to testWord. Is that the proper coding technique?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [MVS-OE] Looking for help with an obscure C integer problem
Okay. What do you think of the union approach?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Saturday, July 20, 2013 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
Your casting a uint64_t to a uint64_t which is pointless. You should cast to
the return value (uint32_t).
I've just tried your example and I can't recreate the problem, with or
without casts and compiled with both OPT and NOOPT.
#include stdio.h
#include stdlib.h
#include stdint.h
#include string.h
int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n 32;
uint32_t c = static_castuint32_t(n 32);
printf( %08X %08X\n, b, c );
}
I can only assume that the optimizer is throwing away valueToTest for some
arcane reason. I've seen this happen with convoluted code with lots of
pointers to pointers etc.
Try qualifying valueToTest with volatile, which should disable optimizations
on that variable.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [MVS-OE] Looking for help with an obscure C integer problem
I don't like it because it's a hack to work around an puzzling issue. I
want to know why the optimizer is not generating the correct code. It's
disconcerting and I've experienced it myself,
but only in situations where the code was convoluted (double pointers
and casts). I ended up rewriting that code! The optimizer takes no
prisoners. In my experience it finds bugs.
On 21/07/2013 9:24 AM, Charles Mills wrote:
Okay. What do you think of the union approach?
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Saturday, July 20, 2013 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
Your casting a uint64_t to a uint64_t which is pointless. You should cast to
the return value (uint32_t).
I've just tried your example and I can't recreate the problem, with or
without casts and compiled with both OPT and NOOPT.
#include stdio.h
#include stdlib.h
#include stdint.h
#include string.h
int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n 32;
uint32_t c = static_castuint32_t(n 32);
printf( %08X %08X\n, b, c );
}
I can only assume that the optimizer is throwing away valueToTest for some
arcane reason. I've seen this happen with convoluted code with lots of
pointers to pointers etc.
Try qualifying valueToTest with volatile, which should disable optimizations
on that variable.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
