FPC 3.2.4-rc1 available

[PeterBB]

Breaking code is likely BASM anyway and caused by mr and/or mrs knowitall's "programming skills" eventually.

Hi Thaddy,

Presumably not a reference to the Buddhist Association of Southwest Michigan 
The failing routines were not written by me BTW.

Anyway, I have only found two uses of constref in the entire codebase,
so its turned out to be rather a storm in a teacup.

Cheers,
Peter

[marcov]

Presumably not a reference to the Buddhist Association of Southwest Michigan 

The inline assembler was originally called BASM in TP/Delphi. It was a mind jump for me too, but I think he means that only when you use it from assembler you get no compiler warning.

Nevertheless that it is fixable, it is a breakage. Which is unfortunate, but sometimes it simply has to happen because otherwise a whole lot of other fixes are also held up, specially with the current release rate.

[440bx]

question about v3.2.4...

does it support using an underscore (_) as thousands separator ?

thank you.

[Thaddy]

No. See new features trunk.
https://wiki.freepascal.org/FPC_New_Features_Trunk#Support_for_Digit_Separator
To my knowledge it is not back-ported, because it is a feature, not a bug-fix,

[440bx]

Thank you Thaddy.

That's really too bad.  That's a simple feature but, it really enhances code readability.

[flowCRANE]

Is there any tentative (approximate) release date for this FPC version as stable, included with a stable future version of Lazarus?

[Martin_fr]

Is there any tentative (approximate) release date for this FPC version as stable, included with a stable future version of Lazarus?

Don't know about the FPC schedule.

Lazarus will most likely release a next minor update, within weeks of the release of fpc 3.2.4.

If you are on Windows, there is a non-official build of the current Lazarus 4.2 with the 3.2.4RC https://sourceforge.net/projects/lazarus-snapshots/files/Window%2064/2025-07%20Lazarus%204.2%20with%20FPC%203.2.4-RC1%20(56baf314b5eb)/
(32 bit version is also there)

[flowCRANE]

I didn't know there were unofficial releases — I'll definitely check out this version. Thanks!

[Martin_fr]

I didn't know there were unofficial releases — I'll definitely check out this version. Thanks!

"build" not "release", aka snapshot. Albeit, its been build the same as the release, and with the same Lazarus files. (and it's even code signed, same as the release).  Personally, I think the 3.2.4RC is already better than the 3.2.2.

And the IDE has been used with it for some time as well. E.g. I build my IDE most of the time with 3.2.3 (which is close to the RC).

It's possible that some packages will require updates, if they haven't been tested yet (though I expect the majority to be fine). If any needs to be adjusted then that is a matter of bug reporting it (I.e. the team simple can't test all OPM packages themself, this will and has always relayed on feedback)

[Thaddy]

Only known breaking change is the constref --> const issue in rtl-generics.

[cdbc]

Hi
Please, would someone be so kind and backport 'RTLString' from trunk into 3.2.4 final... Pretty Please 
It has to happen sooner or later, so why not now...?
Regards Benny

[440bx]

I'd like to see a _formal_ release made of all the bug fixes and _simple_ features.

Such a release would not require many documentation changes and would not require as much testing as a release that includes advanced/complex features.

t would also be a good stepping stone to the next "large" formal release since it would help uncover bugs by having a larger number of users (than an informal version.)

[Thaddy]

Benny,
Why do you need it? Unless you are one of the few (inc. me, but I keep it separate) that compiles the rtl with namespaces and therefor UTF16 string, it is just AnsiString, also for UTF8.(with cp_utf8). Unless you port a lot of code from modern Delphi's.

The feature relies on more new feautures and these would also have to be back-ported and those carry a risk, because they are complex.
That won't happen. 3.2.4. is a bug fix release.

[cdbc]

Hi Thaddy
Ok, I understand  ...and I know all that, but still had a naïve wish... 
I'll just keep on "IfDef'ing" 
Regards Benny

[Martin_fr]

Likely affecting the RC / Found in 3.2.3 420f7af213

There is an issue in the code generator.

Under some circumstances inlined code will use the same physical memory in its stackframe for one of its own locals (params), as the containing code does use for one of its locals.

Actually, it overwrites the local var of the caller, that is the var the caller passed as arguments. So it behaves as if the param was a "var param" => but it is not...

This happens with peephole disabled.

----
More to follow.