Given b and p both uint(32) and b >> p >> 1, then compiling
param B = 10 + b / 2 - (p - 1) / 2;
param k = (b + 1) / 4 + v:uint(32) / 2;
with the above flag is silent. It should complain a lot because it does things like make the types of both those params have a type of int, These numbers are associated with real(w) numbers.
For a real(32), (b, p, v) is (127, 24, 32). For real(64) that tuple is (1023, 53, 64)
What am I missing please? Or is it just silly me ,,, again. Chapel is 2.0.0.
Thanks in advance.
I changed it to
param B = 9 + b >> 1 - (p - 1) >> 1;
param k = (b + 1) >> 2 + v >> 1;
and the problem with B went away. Not quite sure why.
I can understand that v >> 1 is an int(64) because v itself is an int(64) but I do not understand why the increment of b is not a uint(32) given that b is a uint(32).
Mind you, still none the wiser about the lack of warnings.
None of these warning messages work. How do I turn them on?
Do integral literals ever affect the type of an expression, change the type to something different to that determined by the identifiers in the expression?
I just spent a day putting type debug statements throughout code to figure out where I had a bug.
Also, what is are the rules about index variables. Sometimes I can use either signed or unsigned integers as an index. Other times, the compiler complains.
Thanks.
The need for these warning is tracking down what I believe are errors n Chapel's implicit type promotions. Or errors in my own code. For example, given a small param uint(32), actually 127, I cannot understand why the expression
param j = b + 1;
has type int(64). Baffling. I cannot reproduce the error in a small piece of code. Very lost.
Code chunk:
param B = (9 + (b / 2) - (p - 1) / 2):U;
param j = b + 1;
param l = v / 2;
param k = (j/ 4 + l):U;
// param k = ((b + 1) / 4 + v / 2):U;
param _U = _reifyExponent(b + B);
param _L = _reifyExponent(b - B);
const hf2 : R; // the blend of half * f2
assert(b.type == uint(32));
assert(v.type == uint(32));
assert(j.type == int(64));
assert(l.type == int(64));
Sorry I used the variable name of lower case L.
Hi Damian —
I haven't had the time to fully digest this thread and attempt to turn your examples into compilable codes (and don't tonight either), but I think the issue as to why you aren't getting warnings may relate to the --warn-param-implicit-numeric-conversions flag wanting other flags to also be used to specify which types of conversions you want to be warned of.
Specifically, see this part of the man page:
When used in conjunction with warn-int-uint, --warn-real-real, or
--warn-integral-integral, this flag enables [or disables] these
compilation warnings about implicitly converting between numeric
types to also apply when the converted value is a param.
I've been bit by this before as well ("Where's my output?") and think it would be reasonable to have the compiler issue a warning if the one flag is used but none of the accompanying supporting flags are (or at least, I don't know of a reason why such a warning would be a bad idea).
I think this could be worth an issue if you find it to be the cause of your confusion and agree.
As for rationalizing the behavior, I'll need more cycles for that, or hope someone else will beat me to it,
-Brad
1 Like
Thanks. I will investigate further, I thought the Easter bunny had run off with my brain.
Thanks. That got me the messages.
I will post some further detail about the source of my confusion. However it is related to the fact that the type of the expression
p + 1
does not necessarily have the type of p and the type of expression
v - 1
does not necessarily have the type of v whereas the type of the expression
7 - 2 * j
has the type of j.
The type of each of the params v and p above is uint(32) while that of the const j is int(32).
1 Like
Part of the problem is my reading of that table about Implicit conversions. My head hurts.
I will document the underlying problem in an issue. Maybe this weekend. Maybe next.
I figured out those integer warning options.