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 & 0x00000000ffffffffLL;
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);
L r4,<a1:d240:l4>(,r13,240)
TEST LONG LONG:
ICM r0,b'1111',<a1:d244:l4>(r13,244
+ BE @1L6
+ LA r1,+CONSTANT_AREA(,r2,55)
+ ST r0,#MX_TEMP1(,r13,228)
+ L r15,=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
+ L r15,=V(PRINTF)(,r3,302)
+ ST r5,#MX_TEMP1(,r13,228)
+ LA r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+@1L7 DS 0H
* }
LA r15,0
look at the SRDA instrunction, which is missing in the other case.
This is a compiler error and should be repaired by IBM support.
Kind regards
Bernd
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
