[FFmpeg-devel] [PATCH 1/2] Replace FFMIN/FFMAX by type specific macros

[Rémi Denis-Courmont]

Le lauantaina 28. kesäkuuta 2025, 17.35.17 Itä-Euroopan kesäaika Kacper 
Michajlow a écrit :
> On Mon, 2 Jun 2025 at 17:06, Rémi Denis-Courmont <remi at remlab.net> wrote:
> > Le 31 mai 2025 20:40:40 GMT+03:00, Marton Balint <cus at passwd.hu> a écrit :
> > >On Sat, 31 May 2025, Michael Niedermayer wrote:
> > >> This allows adjusting them to exactly match whatever is fastest on
> > >> a given CPU for each type.
> > >
> > >Did you use some tool to make this patch, or it was just manual work?
> > >
> > >Can't you use C11 generics to make this somewhat automatic?
> > 
> > So I tried to do exactly that, but you need multiple levels of generics.
> > In the end, either the compiler crashed or my entire build system crashed
> > because the compiler consumed too much memory.
> Could you elaborate on the problem?

No, I can't. I had neither the skills nor the time to debug my distro's C 
compiler.

> I too think that _Generic is the
> way to go here, instead error-prone manual dispatch of the MIN/MAX
> functions. Also with _Generic we can substitute with an inline
> function to fix double evaluation issues. (and whole patch would be
> few lines instead of changing whole source tree)

This is very difficult because FFMIN/FFMAX are also used for pointer 
comparisons. The float evaluations (with fmaxf/fminf and co) are invalid and 
will not compile, if the operand types are pointer types. Keep in mind that 
even not-selected cases of _Generic must compile.

IIRC, I ended up with 4 levels of nested _Generic macros.

> If you let us help you fix the problem you were facing, I think we can
> arrive at a good solution for the problem here.

Even if you can debug GCC, it'll be a decade or so before we can rely on the 
hypothetical future fixed version, so I very much doubt it.

-- 
ヅニ-クーモン・レミ
Tapiolan uusi kaupunki, Uudenmaan entinen Suomen tasavalta