[clang] [clang] Ignore GCC 11 `[[malloc(x)]]` attribute (PR #68059)

gustedt wrote: I see that the fix is almost ready, good. But generally it would also have helped if the `__has_c_attribute` feature test for this type of borrowed attributes would provide means to distinguish different versions. Here gcc as well as clang only have the value 1. So if the patch

[clang] [clang] Ignore GCC 11 `[[malloc(x)]]` attribute (PR #68059)

gustedt wrote: Hi, yes the really bad choice here is by gcc to have the same name for basically two different attributes. For the value, they also missed the opportunity to do something sensible when moving to C++ attributes, what a pitty. For a concrete guideline in that jungle, when (= whi

[clang] [C23] Fixed the value of BOOL_WIDTH (PR #117364)

@@ -1103,7 +1103,15 @@ static void InitializePredefinedMacros(const TargetInfo &TI, assert(TI.getCharWidth() == 8 && "Only support 8-bit char so far"); Builder.defineMacro("__CHAR_BIT__", Twine(TI.getCharWidth())); - Builder.defineMacro("__BOOL_WIDTH__", Twine(TI.getBool