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

2023-10-31 Thread Jens Gustedt via cfe-commits

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 would also change the 
return value for clang to the year whenever the first version of gcc-11 with 
that feature was released, that would really be helpful.

https://github.com/llvm/llvm-project/pull/68059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


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

2023-10-31 Thread Jens Gustedt via cfe-commits

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 (= which version) do you expect 
this patch to hit distribution? Will it be in clang-18 once that is released?

Can we expect a similar feature, let's Call it clang::deallocator_function in a 
future version?
Thanks
 Jens
-- 
Jens Gustedt - INRIA & ICube, Strasbourg, France 

https://github.com/llvm/llvm-project/pull/68059
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


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

2024-11-23 Thread Jens Gustedt via cfe-commits


@@ -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.getBoolWidth()));
+  // The macro is specifying the number of bits in the value representation,
+  // not the number of bits in the object representation, which is what
+  // getBoolWidth() will return. For the bool/_Bool data type, there is only

gustedt wrote:

Yes, on modern architectures, `bool` and `_BitInt` should be the only integer 
types that have padding bits.

https://github.com/llvm/llvm-project/pull/117364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits