H2077 inside try finally block with goto - is it Tokyo's compiler defect?

Question

After upgrading to 10.2 Tokyo one of third-party components started throwing a lot of exceptions. Debugging showed problematic part of code, that can be represented by this (hopefully) minimal code:

function foo(i: Integer): Boolean;
label bar;
begin
  try
  if i=1 then goto bar;
  Result:=False;
  EXIT;
bar:
  Result:=True;  //<~~ H2077 Value assigned to 'foo' never used with Optimization on
  finally
  end;
end;

With Optimization in compiler options set to

• True (default for Release configuration) - foo(1) returns False
• False (default for Debug configuration) - foo(1) returns True

Such problem does not occur in XE7. This answer explaining changes in Tokyo's compiler is probably related - but maybe fixing some of the problems introduced new.

My question is: is it Tokyo's compiler defect? I am pretty sure it is, but I am new to programming in Delphi and it would be great to get confirmation from more experienced users.

If it is compiler's defect then I have a follow up question: is there any quick way to fix this code? I know how to remove goto in my MCVE with simple if then else statement, but real code is way more complicated:

if cond1 then goto bar;
if cond2 then goto bar;
if cond3 then goto bar;
...
if condN then goto bar;

And some of the if blocks also contain loops with inner goto. I know how to rewrite all of this logic to nested if then else blocks, but maybe there is an easier way to fix it without waiting for compiler's defect or third-party component to be fixed (I know any of those won't happen soon).

Graeco

it's been over 20 years since i saw someone using goto again. I thought we finaly got rid of that... – Exigible

Answer 1

This is a compiler defect. foo(1) should return True. It looks like the optimiser is confused by this particular use of goto.

Submit a bug report to Embarcadero. To get past the problem in the meantime you can:

• Contact the third party component vendor and ask for a workaround, or
• re-write the code to avoid the goto which appears to confuse the optimiser, or
• revert to an older version of the compiler that is not defective, or
• disable optimisation for any functions affected by the defect.

Dissociate

Followed your advice and submitted RSP-19110. – Graeco