On Thu, 10 Aug 2023, Jason Merrill via Gcc-patches wrote: > On 8/10/23 11:35, Jakub Jelinek wrote: > > Hi! > > > > I'd like to ping this patch. Reposting it as I found a typo in the > > documentation - s/builtin-in/built-in/. Bootstrapped/regtested again > > on x86_64-linux and i686-linux, ok for trunk? > > > > On Mon, Jun 12, 2023 at 09:57:17PM +0200, Jakub Jelinek via Gcc-patches > > wrote: > > > As mentioned in my stdckdint.h mail, __builtin_classify_type has > > > a problem that argument promotion (the argument is passed to ... > > > prototyped builtin function) means that certain type classes will > > > simply never appear. > > > I think it is too late to change how it behaves, lots of code in the > > > wild might rely on the current behavior. > > Hmm, you really think there's any code at all in the wild relying on > __builtin_classify_type + array/function decay? It's a (previously) > undocumented built-in, I wouldn't expect anyone outside the project to be > using it. So at first glance I'd be inclined to fix it whether or not we also > allow it to accept a type. But I don't actually know how it's used, so could > well be wrong...
I don't know about array / function decay, but it seems quite plausible that code checking for pointers expects those to occur. Certainly glibc's tgmath.h has code expecting booleans to be treated like other integers (i.e. subject to integer promotions because passed in ...) by __builtin_classify_type (though you'd need a fairly old glibc version to use that implementation of the tgmath.h macros with current GCC rather than one based on __builtin_tgmath). -- Joseph S. Myers jos...@codesourcery.com
