Question

Maybe this was a case of bad programming, but it is manifesting itself with the upgrade of XLC++ from 6.0 to 11.1

The code looks like :

     int startAt = 140;
 startAt = parseAndSaveResponseINSTANTID_MODEL(response, startAt);
 COUT << "After tokenize INSTANTID_MODEL startAt=" <<startAt <<ENDL;

    startAt = startAt++;
    startAt = parseAndSaveResponseINSTANTID_CHRON_HISTORY(response, startAt);
COUT << "After tokenize INSTANTID_MODEL startAt=" <<startAt <<ENDL;

    startAt = startAt++;
    startAt = parseAndSaveResponseINSTANTID_FOLLOWUP_ACTION(response, startAt);
COUT << "After tokenize TSTID_INSTANTID_FOLLOWUP_ACTION startAt=" <<startAt <<ENDL;

startAt = startAt++;
    startAt = parseAndSaveResponseINSTANTID_RISK_INDICATOR(response, startAt);
COUT << "After tokenize TSTID_INSTANTID_RISK_INDICATOR startAt=" <<startAt <<ENDL;

And within each of the parse methods, we do a return (startAt + 1 + vRows * 81);

vRows is zero in all methods.

With the old compiler, the output looks like :

 After tokenize INSTANTID_MODEL startAt=141
 vRows=0
 After tokenize INSTANTID_MODEL startAt=142
 vRows=0
 After tokenize TSTID_INSTANTID_FOLLOWUP_ACTION startAt=143
 vRows=0
 After tokenize TSTID_INSTANTID_RISK_INDICATOR startAt=144

But, with the new compiler, the output looks like

 After tokenize INSTANTID_MODEL startAt=141
 vRows=0
 After tokenize INSTANTID_MODEL startAt=143
 vRows=0
 After tokenize TSTID_INSTANTID_FOLLOWUP_ACTION startAt=145
 vRows=0
 After tokenize TSTID_INSTANTID_RISK_INDICATOR startAt=147

Was there a change in the way integers/returns are handled?

Answer 1

startAt = startAt++ is undefined behaviour. Because it’s undefined, a compiler is at liberty to give any result it feels like giving, like this result in version 6.0 and a different one in version 11.1.

😉

With GCC, -Wsequence-point (or -Wall) would emit a warning for this construct. Not sure if there is an equivalent warning in XLC.