On Thu, Mar 27, 2014 at 12:31 PM, Bernd Oppolzer <[email protected]
> wrote:
> 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;
> }
> }
>
>
Enclose memcmp in parenthesis, (memcmp)(...), to force the compile to
generate code which calls memcmp instead of generating inline code.
>
> 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 [email protected] with the message: INFO IBM-MAIN
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
