I discussed this with the C compiler team. As was suggested, the reason for removal in Mario's case was that the compiler had no knowledge that the __asm would do anything that would effect the result. Side effects that could happen under the covers and unknown to the compiler(that could be updates to variables, printf, whatever) are simply not relevant to the discussion.
To paraphrase what I was told: In general the rule is if the compiler can see that there is no dependency on any code, the compiler is allowed to prune it. The __asm assembler text is a black box. All that the compiler sees is the C variables in the constraints. In this case, there are no identified side effects or writes to anything relevant and hence cannot affect what the compiler believes is the function's behavior (which as coded was to return "0"). I asked about how to get the __asm expanded anyway. There is already a standards proposal to do just that. So that's something to look forward to (possibly to be implemented by extending the "nodiscard" attribute). But for now, you could -- put that function in it's own translation unit (file) and compile that with no optimization. Then any call should not optimize out the asm statement. -- have a #pragma option_override(asmFunct, "OPT(LEVEL,0)") in the same source file with the function to avoid optimizing the code out Peter Relson z/OS Core Technology Design
