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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to