Thank you all for your valuable suggestions.
The compiler is z/OS XL/C V1.13 and V1.11 -
well, in fact, I didn't test it with the 1.11. version.
I observed the problem on the site with the 1.13 version.
This is part of the PL/1 interface for my XML parser.
I had to do a rollout today on three different sites of my
customers; that's why there are different versions of the compiler.
The site with the 1.11. compiler is on z/OS v1.13, but still uses
the old compiler.
I found a workaround in the meantime, this way:
/**********************************************************/
/* */
/* PLI/1 NULL () => SYSNULL () */
/* */
/**********************************************************/
static void pli_null_to_sysnull (void *pptr)
{
char *cp = pptr;
if (memcmp (cp, "\xff\x00\x00\x00", 4) == 0)
{
*cp = 0x00;
}
}
of course, this is completely different and avoids
the unsigned int comparison completely, but that
solves my problem :-)
For the error, I observed by looking at the PSEUDO ASSEMBLY
LISTING, that the IBM compiler removed the function calls and the
function completely. There was only the source statements in the
ASSEMBLY LISTING, no code produced. I didn't check if the function
was inlined in the printf case, but I think so.
Kind regards
Bernd
Am 27.03.2014 18:05, schrieb Thomas David Rivers:
Bernd Oppolzer wrote:
Hello mainframe C users,
That looks as if the compiler guessed that the condition
(ppli == 0xff000000u) can never be true. But because ppli is
an unsigned int, and int has size 32, of course it can (and
it does, as we can see in the case when printf is present).
The value 0xff000000 is also an unsigned int, if 'ppli' is an
unsigned int (with an indeterminant value) then the comparison
is quite valid and can't be elided.
Recall that hex constants (those beginning with 0x) are unsigned-int
by definition in the C standard.
And, certainly, when you cast a pointer to an unsigned it, the compiler
should not apply an special consideration to the definition of pointers
in 31-bit mode. Although, you _could_ decide that a pointer can't
have its upper bit set, it's quite clear that it often does.
The IBM compiler could be misapplying range optimizations, assuming
that a 31-pointer is in the range [0x0 .. 0x7fffffff] and therefor could
never be equal to 0xff000000... but, that would be quite a stretch.
If they are doing this, I can bet your report to IBM will cause
an option to be added to quit doing it :-)
You might want to check to see if the function has been in-lined,
and if so, perhaps the parameter was a known constant or a value
of a known range... which would give the compiler the flexibility
to do what you observed.
When I compiled your example (removing the 'static' modifier)
I got this with the Dignus compiler:
* *** if (ppli == 0xff000000u)
C 2,@lit_217_2
BNE @L3
(where @lit_217_2 was your value) and I doing the same with the
IBM compiler, I got this:
000021 | * if (ppli == 0xff000000u)
000068 5520 3052 000021 | CL r2,=F'-16777216'
00006C 4770 303E 000021 | BNE @1L1
which looks rather similar (both compiled with -O.)
Which version of the IBM compiler are you using?
- Dave Rivers -
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
