Forum > FPC development

Two compiler issues detected - advise needed

(1/3) > >>

MathMan:
Hello all,

First things first

- machine: Intel Core i5 M430 (Nehalem architecture) @ 2.266 GHz, 4 GByte RAM
- system: Windows 7 Home Edition, Service Pack 1, 64 bit
- compiler: FPC 3.2.2 x86_64 in 64 bit mode

I have implemented some larger algebra stuff and discovered two compiler issues (I think)

* an assert in the code, when compiled with {$assertions on}, leads to a call of a sub-function two source lines later with an incorrect value handed over (and a subsequent SIGSEGV) - only happens with -O2 or higher optimisation settings
** I inspected the generated asm and it looks like the compiler is loosing track of register allocation
** my current work-around is to comment the assert out and everything works ok under all optimisation levels then

* a function declaration as inline leads to incorrect calculations - happens on all optimisation level settings
** I have not drilled down this one further, as the inlined function has ~50 LOC and following that in asm is a bit tedious
** current work-around - remove inline decoration and all computations work correct

Bringing the two above to minimum compilable demos will take me a couple of days (if feasible at all), and the result will still have a couple of 1.000 LOC in both cases. I'm willing to spent the effort if this helps. However I have two questions on this

* are the compiler devs aware of such/similar issue
** maybe working on it already, or
** in desperate hunt for a reproducible demo, to inspect this

* can somebody help me generate a ticket, once I have created a minimal compilable demo?

Cheers,
MathMan

AlexTP:
Please provide full compilable examples (small) to reproduce.
Please then try the same on FPC 'latest' Git.

Fibonacci:

--- Quote from: MathMan on September 06, 2023, 09:01:05 am ---* a function declaration as inline leads to incorrect calculations - happens on all optimisation level settings
** I have not drilled down this one further, as the inlined function has ~50 LOC and following that in asm is a bit tedious
** current work-around - remove inline decoration and all computations work correct

--- End quote ---

As for inline, here is a litte demo


--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---function is_int_even(i: integer): boolean; inline;begin  i := i mod 2; //here internal copy of "i" is actualy used byref instead of byval  result := i=0;end; procedure intshow; inline;var  i: integer;begin  i := 10;   if is_int_even(i) then begin    i := i*10;     writeln('i = ', i); //prints 0, expected 10*10=100  end;   readln;end; begin  intshow;end. 
The bug is reported but nothing is done about it. Actually the patch was submitted, but not merged.

Martin_fr:

--- Quote from: MathMan on September 06, 2023, 09:01:05 am ---* an assert in the code, when compiled with {$assertions on}, leads to a call of a sub-function two source lines later with an incorrect value handed over (and a subsequent SIGSEGV) - only happens with -O2 or higher optimisation settings
** I inspected the generated asm and it looks like the compiler is loosing track of register allocation
** my current work-around is to comment the assert out and everything works ok under all optimisation levels then

--- End quote ---

There has been an issue that matches this description, it is fixed in 3.2.3.
It is not related to the assert. I guess the assert just happens to generate the asm for which the issue occurs.


Afaik one or two other bugs in the code generator were fixed. So I would advice to test with 3.2.3.



MathMan:

--- Quote from: Martin_fr on September 06, 2023, 10:16:35 am ---
--- Quote from: MathMan on September 06, 2023, 09:01:05 am ---* an assert in the code, when compiled with {$assertions on}, leads to a call of a sub-function two source lines later with an incorrect value handed over (and a subsequent SIGSEGV) - only happens with -O2 or higher optimisation settings
** I inspected the generated asm and it looks like the compiler is loosing track of register allocation
** my current work-around is to comment the assert out and everything works ok under all optimisation levels then

--- End quote ---

There has been an issue that matches this description, it is fixed in 3.2.3.
It is not related to the assert. I guess the assert just happens to generate the asm for which the issue occurs.


Afaik one or two other bugs in the code generator were fixed. So I would advice to test with 3.2.3.

--- End quote ---

Thanks Martin - sounds promising. Can I get a compiled / installable 3.2.3 from somewhere? I'm a "conservative" user of releases who never tinkered with Git or self compiling FPC or Lazarus - hell, I don't even have Internet access at home  :-X

Navigation

[0] Message Index

[#] Next page

Go to full version