Assignment of -1 to unsigned variables
Status: Beta
Brought to you by:
seranian
Menu
▾
▴
#15 Assignment of -1 to unsigned variables
The PGI/NVHPC 22.5 compiler gives persistent errors about assigning -1 to variables declared as unsigned. I can fix these with changes to the following files:
perf_examples/perf_util.c
273c273
< return -1;
---
> return (size_t) -1;
283c283
< return -1;
---
> return (size_t) -1;
291c291
< return -1;
---
> return (size_t) -1;
574c574
< grp.id = -1;
---
> grp.id = (uint64_t) -1;
lib/pfmlib_intel_nhm_unc.c
215c215
< ret = pfm_intel_x86_add_defaults(this, e, ugrpmsk, &umask, -1, -1);
---
> ret = pfm_intel_x86_add_defaults(this, e, ugrpmsk, &umask, (unsigned short) -1, -1);
lib/pfmlib_perf_event_pmu.c
388c388
< p->id = -1;
---
> p->id = (unsigned) -1;
lib/events/perf_events.h
33c33
< .umask_ovfl_idx = -1,\
---
> .umask_ovfl_idx = (unsigned long) -1,\
42c42
< .umask_ovfl_idx = -1,\
---
> .umask_ovfl_idx = (unsigned long) -1,\
53c53
< .umask_ovfl_idx = -1,\
---
> .umask_ovfl_idx = (unsigned long) -1,\
62c62
< .umask_ovfl_idx = -1,\
---
> .umask_ovfl_idx = (unsigned long) -1,\
74c74
< .umask_ovfl_idx = -1,\
---
> .umask_ovfl_idx = (unsigned long) -1,\
83c83
< .umask_ovfl_idx = -1,\
---
> .umask_ovfl_idx = (unsigned long) -1,\
161c161
< .umask_ovfl_idx = -1,
---
> .umask_ovfl_idx = (unsigned long) -1,
201c201
< .umask_ovfl_idx = -1,
---
> .umask_ovfl_idx = (unsigned long) -1,
236c236
< .umask_ovfl_idx = -1,
---
> .umask_ovfl_idx = (unsigned long) -1,
276c276
< .umask_ovfl_idx = -1,
---
> .umask_ovfl_idx = (unsigned long) -1,
316c316
< .umask_ovfl_idx = -1,
---
> .umask_ovfl_idx = (unsigned long) -1,
346c346
< .umask_ovfl_idx = -1,
---
> .umask_ovfl_idx = (unsigned long) -1,
376c376
< .umask_ovfl_idx = -1,
---
> .umask_ovfl_idx = (unsigned long) -1,
The original failure-messages looked like this:
Offhand I don't see a compiler-flag to enable these kinds of assignments.
Another option would be to use explicit bit-masks like
0xFFFFFFFFetc.However you look at it, though, it seems like some implicit type-information has to be expressed in the assignment, either in the explicit cast or in the expression of the constant.
I think C++ has some hacks where you could overload an assignment operator based on the type of the LVAL and apply a different cast with each specialization of the template.
If you're interested in that, I can try to work out the details, but suspect that it's more trouble than it's worth.