Hi Michael,
On Sun, 19 Nov 2017, Michael Ferguson wrote:
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.
Assuming that I have this code, where jam.[ch] are attached to the email,
require "jam.h", "jam.c";
extern proc jamu32r32(x : real(32)) : uint(32);
extern proc jamu64r64(x : real(64)) : uint(64);
extern proc jamr32u32(x : uint(32)) : real(32);
extern proc jamr64u64(x : uint(64)) : real(64);
inline proc jam(type T, x : real(32)) where T == uint(32) return jamu32r32(x);
inline proc jam(type T, x : real(64)) where T == uint(64) return jamu64r64(x);
inline proc jam(type T, x : uint(32)) where T == real(32) return jamr32u32(x);
inline proc jam(type T, x : uint(64)) where T == real(64) return jamr64u64(x);
proc fpReal(type T) type where T == uint(32) return real(32);
proc fpReal(type T) type where T == uint(64) return real(64);
// this alternative works
//
// proc fp754putZ(v : ?Zsef) : fpReal(Zsef)
// {
// return jam(fpReal(Zsef), v);
// }
// the following will not compile
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));
}
}
the compilation of this in a file 'test1.chpl' shows:
test1.chpl:33: In function 'fp754putZ':
test1.chpl:33: error: illegal size 8 for real
test1.chpl:33: error: unresolved call 'real(64)(8)'
which matches what you got.
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.
Interesting. That probably should be highlighted in the documentation or
is that a case where I have simply missed that explanation during my own
reading of the specification? I saw some words about 'conrete' but it was
not obvious.
Anyway, this behavior of automatically expanding uint(?w) / int(?w) /
real(?w) etc functions is the root cause of the behavior you observed.
Got it. Makes sense.
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).
That makes life so much easier in this day and age.
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
#ifdef CHAPEL_JAM_SOURCE
#define JAM(N, T, S) T N(S y) { return *((T *) &y); }
#else
#define JAM(N, T, S) extern T N(S y);
#endif
JAM(jamr64u64, double, unsigned long)
JAM(jamu64r64, unsigned long, double)
JAM(jamr32u32, float, unsigned int)
JAM(jamu32r32, unsigned int, float)
#define CHAPEL_JAM_SOURCE
#include "jam.h"
------------------------------------------------------------------------------
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
