...
// Compute x*2**n with minimum work (e.g. multiplications)
// The C version of this is 43 lines of assembler with GCC 11
// So using this as an inline routine is probably justifiable
inline proc scale(in x : real(?w), n : int(w))
{
...
// blah-blah-blah
...
}
proc main
{
writef("scale %12.6xr\n", scale(0x1.5p+127:real(32), -270));
return(0);
}
I compiled this and it complains:
scale.chpl:66: In function 'main':
scale.chpl:68: warning: deprecated use of implicit conversion when passing to a generic formal
scale.chpl:68: note: actual with type 'real(32)'
scale.chpl:15: note: is passed to formal with type 'real(?w)'
note: consider adding a cast to 'real(64)' or an overload to handle 'real(32)'
That is clearly wrong. The issue has nothing to do with the real(?w) parameter. The issue is the integer. If I change int(?w) tp integral, the complaint disappears.
I can post the entire code but the issue has nothing to with the internals of scale().
|... // Compute x*2**n with minimum work (e.g. multiplications) // The
C version of this is 43 lines of assembler with GCC 11 // So using
this as an inline routine is probably justifiable inline proc scale(in
x : real(?w), n : int(w)) { ... // blah-blah-blah ... } proc main {
writef("scale %12.6xr\n", scale(0x1.5p+127:real(32), -270)); return(0); } |
I compiled this and it complains:
|scale.chpl:66: In function 'main': scale.chpl:68: warning: deprecated
use of implicit conversion when passing to a generic formal
scale.chpl:68: note: actual with type 'real(32)' scale.chpl:15: note:
is passed to formal with type 'real(?w)' note: consider adding a cast
to 'real(64)' or an overload to handle 'real(32)' |
That is clearly wrong. The issue has nothing to do with the real(?/w/) parameter. The issue is the integer. If I change int(?/w/) tp integral, the complaint disappears.
I can post the entire code but the issue has nothing to with the
internals of /scale/().
I was hoping for some insight into the problem so that I could submit a more intelligent sounding issue. If nobody replies before Monday, I will submit the issue as-is. When I get what looks like a very odd error, I always worry that it is the programmer who is triggering the error that is the odd part of the puzzle.
I agree with Lydia, this deserves an issue. Meanwhile here is some background.
We have decided to deprecate the interpretation of a real(?w) formal as stamping out one overload for real(32) and one for real(64). See this comment in #20011. So the warning you are observing is the compiler's way to say that. The warning was added in #22769.
I am more concerned that the compiler dispatches to the overload for (64, 64)-bit arguments. My expectation and probably your intention as well are to invoke the one for (32, 32). I could not tell why this happens upon a cursory look a the resolution rules in the spec .
The closest I got was this clause: "Discard any candidates that have more formals that require param narrowing conversions than another candidate." However it is unclear to me from the text whether the conversion of -270 to int(32) is "narrowing" or not. @mppf - any insights here?
One of the things that attracted me to Chapel was that I could write a generic routine for an algorithm that would work if I fed it a floating point number of any size - 32-bit, 64-bit or even 128-bit. I only had to write one piece of code. Are you saying this is no longer true? Generally, a 32 bit integer serves my needs. If it does not, there is normally a comment why not.
The compile accepts my code if I declare that integer parameter to be int(32) (which is quite sound from a mathematical perspective even for a real(256)), i.e. the following works well and does not create any warnings:
proc scale(in x : real(?w), n : int(32))
{
...
}
I guess I found the original error message a bit strange because the compiler was complaining about the real parameter rather than the int parameter which is where I actually had the problem. But you are talking about something else again so I am not sure I really have a total grasp of the underlying issue. Ho-ho.
That confusion was why I did not file an issue. I was worried my interpretation of the problem was twisted the wrong way. I was not even sure what the title of the issue should be. My own knowledge of the intricacies of dispatching to an overload is inadequate and parameter narrowing or widening sends my head spinning. So until I understood a bit more, I did not want to be writing waffle. I can do enough of that already without trying.