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

Reply via email to