kicad-developers team mailing list archive
Mailing list archive
Re: RTree implementation
Am 2018-10-22 10:08, schrieb Tomasz Wlostowski:
On 22/10/2018 14:54, Wayne Stambaugh wrote:
I tend to side with JP on this. Our luck with boost has not been the
best over the years. We seem to have an issue every few boost
with something getting broken so I would tread cautiously and require
lots of testing with many different boost versions back to 1.54 which
our current minimum version.
I side with Wayne and JP. We've had numerous troubles with the less
mainstream Boost libraries in the past (e.g. geometry, polygon) and in
would rather see Kicad going fully for C++11/newer STL features only.
As for the R-Tree crash, I would simply use doubles instead of floats
spend some time to hack the current R-tree implementation to use fixed
No worries. Happy to proceed without extra Boost libs.
After digging around some more with my 32-bit Buster VM, it appears that
this particular issue is caused by excess floating point precision in
the x86 registers. Turning on -ffloat-store for 32-bit builds fixes it
as far as I can tell.
Now, the downside of this is that the flag prevents all floating points
values from being stored in registers, leading to slightly slower
performance of KiCad. For small boards, it is not noticeable. The CIACC
board is substantially slower with clicks taking about 100-200ms to
register in pcbnew (in a VM). This is up from about 75ms without the
Given that this would be a change _only_ for the 32-bit compiles, this
may be acceptable. Also, I haven't seen any MSW reports of this issue,
so I'm inclined to limit the change to linux only.
Does anyone see potential issues with this change?