Re: [PATCH v2 1/8] minmax: Put all the clamp() definitions together

Arnd Bergmann
2024-07-30T10:11:27Z

On Tue, Jul 30, 2024, at 05:59, Linus Torvalds wrote:
> On Mon, 29 Jul 2024 at 16:21, Linus Torvalds <torvalds@linuxfoundation.org> wrote:
>>
>> Attached is the patch I have in my tree right now - it complains about
>> a 'bcachefs' comparison between an 'u16' and a 's64', because I also
>> removed the 'implicit integer promotion is ok' logic, because I think
>> it's wrong.

I'm giving this a spin on the randconfig test setup now to see
if there are some other cases like the bcachefs one. So far I've
seen one failure, but I can't make sense of it yet:

drivers/gpu/drm/i915/display/intel_backlight.c: In function 'scale':
include/linux/compiler_types.h:510:45: error: call to '__compiletime_assert_905' declared with attribute error: clamp() low limit source_min greater than high limit source_max
include/linux/minmax.h:107:9: note: in expansion of macro 'BUILD_BUG_ON_MSG'
107 | BUILD_BUG_ON_MSG(statically_true(ulo > uhi), \
drivers/gpu/drm/i915/display/intel_backlight.c:47:22: note: in expansion of macro 'clamp'
47 | source_val = clamp(source_val, source_min, source_max);

See https://pastebin.com/raw/yLJ5ZqVw for the x86-64 .config
that triggered this.

>> I don't think a min(u16,s64) is a valid minimum, for exactly the same
>> reason a min(u32,s64) is not valid.
>
> Oh, and I noticed that it screws up the 32-bit case, and that does
> need a workaround for that.
>
> So here's a better version. The patch contains one possible fix to
> bcachefs for the type confusion there, but I'll wait for Kent to
> respond on that.

That's still a typo in the 32-bit case, right?
I've changed

__builtin_choose_expr(sizeof(ux)>32,1LL,1L))

to check for sizeof(ux)>4 for my testing.

Arnd