For stm8, in the asm, it looks like in the function get_got iTemp3 (address of hash->sgot) and iTemp4 (value of hash->sgot) are spilt to the same stack location.
--dump-graphs shows them conflicting in tst_gcc-torture-execute-pr41750.dumpsalloccon_get_got.dot, though, so apparently the conflict graph is still correct.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For stm8, in the asm, it looks like in the function get_got iTemp3 (address of hash->sgot) and iTemp4 (value of hash->sgot) are spilt to the same stack location.
--dump-graphs shows them conflicting in tst_gcc-torture-execute-pr41750.dumpsalloccon_get_got.dot, though, so apparently the conflict graph is still correct.
Looks like another boost bug. The attached test program reproduces the issue.
For me, it fails using boost 1.74.0.3 on Debian Hurd, but passes using boost 1.83.0.2 on Debian GNU/Linux.
P.S.: Also passes using boost 1.81.0 on Debian Hurd.
Last edit: Philipp Klaus Krause 2024-08-27
At this point, I can't think of a good solution other than just requiring a newer boost. Implemented in [r14977].
Related
Commit: [r14977]
Last edit: Philipp Klaus Krause 2024-08-27