Michael Ferguson
Michael Ferguson
@arezaii - is this still an issue? I thought we had a flag that was working to do this.
OK, I'll try to summarize/clarify. If I have Lib.chpl ``` chpl module Lib { public use C_Lib; proc fn() { c_fn(); } } ``` C_Lib.chpl ``` chpl module C_Lib {...
PR #11570 has some related changes. See https://github.com/chapel-lang/chapel/pull/11570#discussion_r230961816
Here is a link to the test we'd like to get to pass for this issue to close: https://github.com/chapel-lang/chapel/pull/5277/files#diff-c60cb09d88210e77db2f5c34662d065d
As @vasslitvinov pointed out in the [related discourse thread](https://chapel.discourse.group/t/implicit-generic-parameter-conversion-odd-error-message/35500) the compiler is currently stamping out `scale` overloads for each possible value of `w` (32 and 64) and then doing overload...
``` static inline float int16ToFloat32(const int16_t* p) { return (float)(*((_Float16*)((void*)p))); } ``` This might well work but it's type-punning which C compilers don't allow. IMO the best way to write...
I expect that we won't need any resolution changes to add `real(16)` (or `real(128)`).
I have a pretty good guess as to what the problem is (I think it has to do with the part of the code trying to skip ahead if the...
@bradcray - I don't necessarily understand all of the details but my expectation is that a signal is raised by the hardware and exceptional enough not to impact optimization. The...
They almost certainly don't (Edit: but I don't have any details)