Hi Damian -
Generally speaking, it's important to show a complete reproducer (attaching to
the email or using a GitHub gist or something similar would be reasonable
ways). Additionally, you didn't say *how* it fails (fails to compile? or ...?).
Lastly, generally speaking, it's best to create a GitHub issue if you can for
something that appears to be a bug.
Anyway, I tried some simple simplifications of what you had to get something
that might be a smaller but representative test case. I have this program:
proc fp754putZ(v : uint(?w)) : real(w)
{
var x:real(w) = v:real(w);
//return jam(real(w), v);
writeln(v.type:string);
writeln(x.type:string);
return x;
}
proc test() {
type R = real(32);
type U = uint(numBits(R));
const zero = 0:U;
writeln(fp754putZ(zero));
}
test();
This fails to compile with the error:
d.chpl:3: error: illegal size 16 for real
d.chpl:3: error: illegal size 8 for real
The reason this happens is that a function declared with arguments like v :
uint(?w) actually creates concrete (not generic) functions for each uint width.
Moreover, due to some pass ordering issues in the compiler, that error is
occurring during the normalize pass (vs in resolution) - that just means that
simple strategies like using a 'where' clause on fp754putZ or using a
conditional comparing w to 32 (say) and expecting the compiler to fold it -
these don't work currently. I've created this issue to describe that problem:
https://github.com/chapel-lang/chapel/issues/7836
The error is just indicating that the compiler created a version of fp754putZ
for 16-bit and 8-bit uints and that we don't currently support 16-bit or 8-bit
reals.
Anyway, this behavior of automatically expanding uint(?w) / int(?w) / real(?w)
etc functions is the root cause of the behavior you observed. I don't have the
complete example with the fpReal(type T) version but I suspect it simply
changed your function into an actually generic function. Lastly, proc
fp754getZ(v : real(?w)) : uint(w) worked because there are integer types for
every real type bit width (at least at the moment).
Cheers,
-michael
Hi All,
I am playing around with a mocked-up recast facility.
The following fails.
proc fp754putZ(v : uint(?w)) : real(w)
{
return jam(real(w), v);
}
module T
{
proc main()
{
type R = real(32);
type U = uint(numBits(R));
const zero = 0:U;
writeln(fp754putZ(zero));
}
}
However, if I use
proc fpReal(type T) type where T == uint(32) return real(32);
proc fpReal(type T) type where T == uint(64) return real(64);
to provide the types of the variable and return for fp754putZ, then
this works.
proc fp754putZ(v : ?Zsef) : fpReal(Zsef)
{
return jam(fpReal(Zsef), v);
}
module T
{
proc main()
{
type R = real(32);
type U = uint(numBits(R));
const zero = 0:U;
writeln(fp754putZ(zero));
}
}
What am I doing wrong?
Happy to share the full test code. What is the protocol for sharing a
total of 3 files, a .chpl, a .c and a .h. Put a shar-file in the body or
just attach the stuff. Total line count is 61 lines.
For the record, the mirror image which follows of the offensive little
nuisance above, works!
proc fp754getZ(v : real(?w)) : uint(w)
{
return jam(uint(w), v);
}
Regards - Damian
Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers