[Bf-committers] Support for 32-bit architectures

[Brecht Van Lommel]

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.