[Bf-committers] Support for 32-bit architectures

Brecht Van Lommel brechtvanlommel at gmail.com
Tue Nov 17 18:39:51 CET 2020

On Tue, Nov 17, 2020 at 2:40 PM Sybren A. Stüvel via Bf-committers <
bf-committers at blender.org> wrote:

> I'm assuming you mean D9577 with "this specific case", as that's where
> this discussion started before I moved it to this list, and that
> you're talking about a problem that 32-bit Linux can't be compiled
> because some code uses 64-bit atomic functions that are not defined.
> It may be my personal limitation, but somehow I can't combine a patch
> where 64-bit atomics are going to be exposed on 32-bit platforms with
> "Tweak the code to not use 64 bit atomics".

We need to fix a regression, it doesn't have to be the particular solution
in the patch. Eliminating the architecture-specific code is a solution too.

> I tried to steer away from discussing the specifics of that patch
> here, though, as I'm more interested in getting a clearer picture of
> the general policy on how we handle incompatibilities with unsupported
> platforms.

Implementing a fallback: if it's clear what a function should do (via
> unit tests for example) then no, that's fine.
> Understanding how exactly things get unwinded on a specific platform
> the developer doesn't have access to -- yes, it is too much.

I'm talking about processor architectures, not platforms more generally.
And if you look at the handful of actual cases where that matters, it's
just not that hard to ensure there is a working architecture-independent
code path. Either by understanding the behavior, or finding a solution that
doesn't require understanding it.

More information about the Bf-committers mailing list