I just tried without optimization and did a -W c,LIST to get the assembler. It looks like unoptimized will work because all the code is there (even without the -DCOMPERR argument)
On Thu, Mar 27, 2014 at 11:26 AM, Farley, Peter x23353 < peter.far...@broadridge.com> wrote: > Perhaps turn off optimization and see what the "raw" compiler produces? > That may provide a hint to a solution, or it may just leave the function > to do what you want and you will have accomplished your task. > > BTW, why a "static" function? Could that be affecting the way the > compiler optimization treats the code? > > HTH > > Peter > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Bernd Oppolzer > Sent: Thursday, March 27, 2014 11:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Compiler error in z/OS C compiler > > Hello mainframe C users, > > today I observed an error in the C compiler, > which made me think again about the optimization strategy > of the z/OS C compiler. > > I wrote a small C function; the purpose was to translate > pointer values coming from PL/1 modules from NULL() values > - PL/1 builtin NULL() yields 0xFF000000 - to "real" NULLs > - 0x00000000 - or PL/1 SYSNULL. > > This is what I did: > > > /**********************************************************/ > /* */ > /* PLI/1 NULL () => SYSNULL () */ > /* */ > /**********************************************************/ > > static void *pli_null_to_sysnull (void *ptr) > > { > unsigned int ppli = (unsigned int) ptr; > > #ifdef COMPERR > printf ("Ausgabe in pli_null_to_sysnull " > "wg. Comp-Fehler: %x\n", ppli); > #endif > > if (ppli == 0xff000000u) > { > return NULL; > } > else > { > return ptr; > } > } > > > the caller then did something like > > ptr = pli_null_to sysnull (ptr); > > now: > > if the printf inside the function was there (that is, > COMPERR was #defined), all went OK; the ptr was translated > as desired. > > but: > > if the printf was not there (no #define for COMPERR), the > function was completely thrown away by the optimizer, and > the ptr remained unchanged. > > 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). > > What happens here? > > I believe that the compiler THINKS that because the value > of ppli comes from a casted pointer and pointers have 31 > bits in z/OS, the value of ppli can never have the high order > bit on. But that's just plain wrong, as we see here, if the > pointer comes from a PL/1 module, for example, and contains > NULL(). That's just the case that I want to deal with, here. > > We had such problems before, when, for example, pointers coming > from outside into C modules had the high order bit on, and > the C runtime got into serious troubles with this. Is this > a variant of that same old story? > > What do you think? > > I found a workaround in the meantime, and I asked our compiler > people to send the problem to IBM. But I would like to hear some > opinions from the list, too: do you consider the function valid > in the z/OS context or not? After all, I expect C to help me > even in the systems programming business; I would be very > disappointed if for such easy tasks already I had to use > ASSEMBLER subprograms. > > Kind regards > > Bernd > -- > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by > e-mail and delete the message and any attachments from your system. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
