What is CARD32 data-type and where is it defined? I am reading xserver code and am unable to find definitions for CARD data type.
Since the comments on the post cite the wrong code snippet for justification, I wanted to give a proper answer.
As already noted CARD32 is an unsigned 32 bit integer.
The type is defined in a C header file in X11/Xmd.h (GitHub Permalink as of 8th Sept. 2021).
Here is the revelant excerpt:
# ifdef LONG64
typedef unsigned long CARD64;
typedef unsigned int CARD32;
# else
typedef unsigned long long CARD64;
typedef unsigned long CARD32;
# endif
Further up, the LONG64 macro is defined only for 64-bit architectures. So, CARD32 is a unsigned int on 64-bit architectures and unsigned long everywhere else.
Related
The implementation of emulated atomics in openCL following the STREAM blog works nicely for atomic add in 32bit, on CPU as well as NVIDIA and AMD GPUs.
The 64bit equivalent based on the cl_khr_int64_base_atomics extension seems to run properly on (pocl and intel) CPU as well as NVIDIA openCL drivers.
I fail to make 64bit work on AMD GPU cards though -- both on amdgpu-pro and rocm (3.5.0) environments, running on a Radeon VII and a Radeon Instinct MI50, respectively.
The implementation goes as follows:
inline void atomicAdd(volatile __global double *addr, double val)
{
union {
long u64;
double f64;
} next, expected, current;
current.f64 = *addr;
do {
expected.f64 = current.f64;
next.f64 = expected.f64 + val;
current.u64 = atomic_cmpxchg(
(volatile __global long *)addr,
(long) expected.u64,
(long) next.u64);
} while( current.u64 != expected.u64 );
}
In absence of support for atomic operations for double types, the idea is to exploit casting to long as the values just need to be stored (no arithmetics needed). Then one should be able to use long atom_cmpxchg(__global long *p, long cmp, long val) as defined in the khronos manual for int64 base atomics.
The error I receive for both AMD environments points to falling back to 32bit versions, the compiler seems not to recognise the 64bit versions despite the #pragma:
/tmp/comgr-0bdbdc/input/CompileSource:21:17: error: call to 'atomic_cmpxchg' is ambiguous
current.u64 = atomic_cmpxchg(
^~~~~~~~~~~~~~
[...]/centos_pipeline_job_3.5/rocm-rel-3.5/rocm-3.5-30-20200528/7.5/out/centos-7/7/build/amd_comgr/<stdin>:13468:12: note: candidate function
int __ovld atomic_cmpxchg(volatile __global int *p, int cmp, int val);
^
[...]/centos_pipeline_job_3.5/rocm-rel-3.5/rocm-3.5-30-20200528/7.5/out/centos-7/7/build/amd_comgr/<stdin>:13469:21: note: candidate function
unsigned int __ovld atomic_cmpxchg(volatile __global unsigned int *p, unsigned int cmp, unsigned int val);
^
1 error generated.
Error: Failed to compile opencl source (from CL or HIP source to LLVM IR).
I do find the support for cl_khr_int64_base_atomics in both environments on the clinfo extension list though.. Also cl_khr_int64_base is present in the opencl driver binary file.
Does anybody have an idea what might be going wrong here? Using the same implementation for 32bit (int and float instead of long and double) works flawlessly for me...
Thanks for any hints.
For 64-bit, the function is called atom_cmpxchg and not atomic_cmpxchg.
I am trying to convert an unsigned long long to QString by using QString::number(). But it's giving me the following error "call of overloaded 'number(long long unsigned int*&)' is ambiguous. Can anyone help me?
EDIT
GetBoardSN(0, SN);
ui->tableWidget_Ethernet->setItem(0,2,new QTableWidgetItem(QString::number(SN)));
Header file :
int GetBoardSN(int instance, unsigned long long *SN);
Your SN seems to be a pointer (unsigned long long *). Otherwise you would not be able to call GetBoardSN that way. So your code assumes the variable to have two different types. GetBoardSN requires SN to be a unsigned long long* pointer, String::number() requires SN to be a value for example of type unsigned long long.
To solve this, depending on your context, you can either declare SN as a non-pointer type and call GetBoardSn with a reference to this instance:
GetBoardSN(0, &SN);
ui->tableWidget_Ethernet->setItem(0,2,new QTableWidgetItem(QString::number(SN)));
or keep the pointer type and resolve the pointer before accessing its value:
GetBoardSN(0, SN);
ui->tableWidget_Ethernet->setItem(0,2,new QTableWidgetItem(QString::number(*SN)));
Which one is the better solution depends on your overall usage of SN.
Frama-c appears to allow unsigned integer math to wrap-around while it assumes that signed integer math won't overflow, and this is required to later be proven with the -wp-rte flag. (I am personally using Frama-C 20.0 Calcium.) I would like to somehow create an assurance/requirement that some calculation/property doesn't overflow. A simplified version of the issue I am trying to handle is:
#include <stdint.h>
struct example_struct {
unsigned int a;
unsigned int b;
};
/*#
predicate valid_example_struct_one{L}(struct example_struct ex_struct) =
ex_struct.a * ex_struct.b <= UINT_MAX;
*/
Obviously, the above predicate is always true due to wrap-around on unsigned integer math. I would like to be able to cast a, and b to be integer type that won't overflow, or somehow specify it can't overflow using another method. The following seems to somewhat work:
/*#
predicate valid_example_struct_two{L}(struct example_struct ex_struct) =
1 <= UINT_MAX / ex_struct.a / ex_struct.b;
*/
However, I'm not sure the above is really equivalent as it struggles to prove (notice the swapped a, and b):
1 <= UINT_MAX / ex_struct.b / ex_struct.a;
if I ask it to with the input being told up hold up to the predicate valid_example_struct_two. Does anyone have suggestions for saying that a * b is less than UINT_MAX (without doing wrap-around)?
Your predicate
/*#
predicate valid_example_struct_one{L}(struct example_struct ex_struct) =
ex_struct.a * ex_struct.b <= UINT_MAX;
*/
is not "always true due to wrap-around on unsigned integer math". As mentioned in the ACSL manual, all arithmetic operations in ACSL are done in the integer (or real) type, i.e. without wrap-around. It is thus the canonical way to express the absence of arithmetic overflow, and the one that is used by RTE and Eva when emitting related alarms.
That said, RTE is perfectly capable to emit assertion for unsigned overflow, but this has to be activated explicitly with the kernel option -warn-unsigned-overflow (see Frama-C user manual, section 6.3. The reason this option is not activated by default is that, contrarily to e.g. signed overflows, unsigned overflows have a perfectly defined semantics in C.
In C++ there is a way to cast a char to int and get the ascii value in return. Is there such a way to do the same with a qchar? Since unicode supports so many characters and some of them are actually looking alike, it is sometimes hard to tell what one is dealing with. An explicit code point or a number that can be used to get such would be very helpful.
I searched a the web and this site for a solution but so far no luck, Qt documentation isn't much of help either, unless I'm overlooking something.
Thank you in advance!
EDIT:
Maybe I wasn't clear enough on the matter, sorry.
Here's some code:
char chChar = 'a';
cout << (int)chChar; // will output 97, not 'a'
Also, Qt allows this:
QChar ch = 'a';
if(ch == 0x61)
//...
As far as I can tell, there has to be some information relating to the unicode codepoint in the ch object. Any possibility to get it out of there?
Took some time but I found the answer: QChar has a member named QChar::unicode which returns a ushort with its code point. Just for the record.
I saw some there are some typedef in CPython as shown below, what does ty mean in the type name? A short form of type?
typedef struct _mod *mod_ty;
typedef struct _stmt *stmt_ty;
typedef struct _expr *expr_ty;
Given that it's a typedef and the new type is simply the structure name with _ty appended, I think you've hit the nail on the head.
It's just a short form of type so that you can instantly tell that a variable of type xyzzy_ty is simply a pointer to a variable of type struct _xyyzy.
The rules you follow for this sort of thing aren't set in stone but it's useful to be consistent.
PEP7 is the style guideline for CPython C source code, similar to PEP8 for the Python source code.