https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430
--- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Jürgen Reuter from comment #27) > Well, the valgrind output actually exactly that the comparison is optimized > away. > I actually would have to regenerate all the debug output, but the point is > that for the first appearance in the random seed chain, the code must not > run into the second part of the if clause: > else if (prt%child1%is_quark ()) then > !!! 1: q->qg > prt%type = prt%child1%type > prt%child2%type = GLUON > prt%child2%t = abs(prt%t) > call integral_over_z_part_isr & > (shower, prt,otherprt, shat, minz, maxz, integral, final) > if (integral > final) then > return > else > !!! 2: g->qqbar > prt%type = GLUON > prt%child2%type = -prt%child1%type > prt%child2%t = abs(prt%t) > call integral_over_z_part_isr & > (shower, prt,otherprt, shat, minz, maxz, integral, final) > end if > end if > so the return should be executed. We checked explicitly that the condition > integral > final was fulfilled, for the value of final as calculated inside > the routine integral_over_z_part_isr, but then the if clause did not > correctly execute the return, and the reason seemed to be that the value of > integral was not available anymore. It is of course possible that in the debugger you see some variables as no longer available, especially if they aren't used afterwards. But, as integral_over_z_part_isr is not inlined into this function (while the containing function is inlined ultimately into shower_generate_next_isr_branching, if you add a breakpoint on the call integral_over_z_part_isr insn and on the insn immediately after it and on the call you stepi into the function, as both final and integral are passed by reference, you should see the arguments (i.e. address where the final long double value is stored and address into which integral will be stored). Then immediately after the call returns, you can again inspect both, and on the fucomi instruction see if it compares the values you expect, and then where it branches afterwards. As the current function is inlined into others, the return doesn't actually mean return from function, but just branching to code that does something from other inlined functions.
