Omr: Remove __noinline__ from TR_ScratchBufferInfo::writeToBuffer after build compiler bug is fixed

[hzongaro]

As reported in issue #3084, there appears to be a bug in the z/OS V2.1.1 XL C/C++ compiler if a function that returns the difference of two pointers is inlined. The same problem appears to affect code built with XL C/C++ V12.1 for POWER.

The work-around was to avoid inlining TR_ScratchBufferInfo::writeToBuffer on those platforms with those build compilers. Once that build compiler bug has been fixed, that work-around should be removed.

[hzongaro]

In the process of reporting this to the IBM XL C/C++ team.

[hzongaro]

I had some discussion with developers on XL C/C++, and they indicated this was a known problem that's unlikely to be fixed soon. They suggested two different workarounds for this:

• Compile with the -qSTRICT_INDUCTION option
• Cast the return value of TR_ScratchBufferInfo::writeToBuffer to an 8 byte value.

Thinking about the latter option, if we change these various write methods to have a result type of ptrdiff_t rather than int32_t, that should have the same effect as casting the return value to an 8 byte value. That change would also have the benefit of eliminating the need to track this build compiler problem, as that workaround wouldn't need to be reverted.

@fjeremic Filip, if you agree with that, I can submit a revision of PR #3085 that eliminates the use of the __noinline__ attribute.

@gita-omr @zl-wang Gita, Julian, I could make the same change to remove the __noinline__ attribute from TR_ScratchBufferInfo::writeToBuffer for Power as well, assuming this is the same problem that was encountered on Power. Do you agree, or would you prefer that I leave the attribute alone for Power?

[zl-wang]

@hzongaro I think it is the same issue. Go ahead making the same change!

[fjeremic]

@hzongaro I think it is the same issue. Go ahead making the same change!

Green light from me as well. Thanks for making the changes!