Description: the headline say's it all, imho a feature with known bugs shouldn't be on by default, and users should be informed about the risk when activating it. it affects e.g. bugs 124577 and 129753, stacks of 100+ cells sometimes produce wrong results on copies into the second cell from top. there are others like 98009 and 103532 up to now only 'solved wfm'. Steps to Reproduce: 1. check above mentioned bugs, 2. see errors occuring with any parallelizing option enabled, 3. see errors need recalculation, 4. see errors re-occuring on sensitive actions after recalc, 5. see errors hard to spot for normal users, 6. i suggest to protect users from running the risk of such miscalculations without warning Actual Results: wrong results until manually triggered recalc, Expected Results: correct results, autocalculate working as announced, Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.alpha0+ (x64) Build ID: 9ed75e2c65544b4f71c73e1c51a68d74e31d544b CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: CL
still a bug in 7.0.0.0.a1+, easy check: threaded or openCL or both enabled and active (restarted), A2: '=C1' B2: '=A2+1' C2: '=B2' A2:C2 - copy A3:A101 - paste (minimum length to get 100 identical formulas) copy any of A2 or A4:A101 to A3 see B3, C3 and A4:C101 wrong ctrl-shift-F9 heals but user doesn't know that it's neccessary, as you see: not reliable, shouldn't be on by defult for productive systems, (same error for copies from B2;B4:B101 to B3 or from C2;C4:C101 to C3)
*** This bug has been marked as a duplicate of bug 132451 ***