[clang] [Clang] Fixes of builtin definitions after PR #68324. (PR #81022)

via cfe-commits cfe-commits at lists.llvm.org
Mon Feb 12 12:44:40 PST 2024


michele-scandale wrote:

> > There are still some differences that I haven't addressed here as they might be ok to have:
> > ```
> > * `__builtin_rint{,f,l}` were defined with the `const` attribute, now they use the `const when FP exceptions are ignored` -- this seems due to the definition of these has been merged with the corresponding library builtins `rint{,f,l}`.
> > 
> > * `__builtin_{wcschr,wcscmp,wcslen,wcsncmp}` and corresponding library builtins now are marked `pure`
> > 
> > * `__addressof` was language builtin, now is a library builtin (like `addressof`)
> > 
> > * `finite{,f,l}` were defined with `GNU_LANG` property, now they are defined with the `ALL_GNU_LANGUAGES` property
> > 
> > * `__builtin_va_{copy,end}` are now marked with the property that they are a `libc/libm function with a '__builtin_' prefix added`
> > 
> > * a bunch of C library builtins are now marked `nothrow` (e.g. `abort`, `alloca`, `bcopy`, `bzero`, `index`, `fprintf`, `memchr`, `memcpy`, `memmove`, `memset`, `rindex`, `snprintf`, `sprintf`, `stpcpy` `stpncpy`, `strcat`, `strchr`, `strcmp`, `strcpy`, `strdup`, `strlen`, `strncat`, `strncmp`, `strncpy`, `strpbrk`, `strrchr`, `strspn`, `strstr`, `vfprintf`, `vprintf`, `vsnprintf`, `vsprintf`, `wcschr`, `wcscmp`, `wcslen`, `wcsncmp`, `wmemchr`, `wmemcmp`, `wmemcpy`, `wmemmove`
> > 
> > * `snprintf`, `sprintf`, `vfprintf`, `vprintf`, `vsnprintf`, `vsprintf` have now pointer arguments marked `restrict`.
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Any comment?
> 
> Thank you for catching these mistakes! I'm of two minds: some of these changes seem valid and correct, but I don't think they were intended. For example, `printf` family functions now having pointers marked `restrict` maps to the standard signature for them and seems like a good change. But a change like with `__addressof` may be more questionable. Perhaps we should restore the old behavior in all cases, then re-land the good changes in follow-ups. That's more effort now, but it's easier for people to track down why a change was made in a few years. WDYT?

I can do that.

https://github.com/llvm/llvm-project/pull/81022


More information about the cfe-commits mailing list