View Single Post
Old 03 November 2016, 13:32   #41
Chain-Q
 
Posts: n/a
Hi everyone,

So, the bug which people ran into on 28 Oct. should be fixed. Try the next nightly to see what happens.

Some TL;DR details: It was a register-preservation issue. In *some* cases, the compiler didn't preserve some address register (primarily A6) contents, when it was generating code for Amiga library calls, but overwrote them. This only caused issues with complex code, like the compiler itself, where register A6 was used for a register variable as well. However, the issue was not tied to A6 register itself, but it was the most common case, because A6 is always used as libbase when generating a library call of course. Actually, the actual case was a bit more complex, because the A6-non-save issue only occured, when the function doing the Amiga library call was really small, and didn't use any other non-volatile address registers. So you needed a really complex function using A6 as address register variable calling into a really simple function, doing an Amiga library call, and not preserving the A6 meanwhile.

This was a long standing issue, but since the compiler wasn't using address registers for register variables it was hiding and caused no issues. It was exposed by the large patch known as SVN r33591, committed 1 May, this year, which introduced register variables for pointer types in address registers.

This could affect any code generated by the compiler, including the one generated by the crosscompiler as well.

The issue is now fixed in SVN r34777. Additional credits fly out to Alb42, who figured out the SVN revision introducing the issue, which really helped to track the issue.

Edit: a possible workaround is for older FPC revisions is, to use -O1 level as maximum optimization level. The issue is there from -O2 and up, below the register variables optimization is disabled.

Have fun with FPC!
 
 
Page generated in 0.08845 seconds with 11 queries