[Rd] formatting issue with gcc 9.3.0 on Ubuntu on WSL2

[Tomas Kalibera]

On 11/18/20 12:56 PM, Iñaki Ucar wrote:
> On Wed, 18 Nov 2020 at 10:26, Tomas Kalibera <tomas.kalibera using gmail.com> wrote:
>> On 11/17/20 9:34 PM, Bill Dunlap wrote:
>>> I just got a new Windows laptop (i7, 10th generation CPU), installed
>>> 'Windows Subsystem for Linux 2' and then installed Ubuntu 20.04 and
>>> used 'apt-get install' to install packages that the R build seems
>>> to require.  In particular, I am using gcc version 9.3.0.   The
>>> build went without a hitch but the tests showed that deparse(1e-16)
>>> produced "1.00000000000000e-16" instead of the expected "1e-16".
>>>
>>> It looks like the problem is in src/main/format.c:scientific().  The
>>> lowest two+ bytes in the fractional part of the long double (80-bit)
>>> return value of powl(10.0L, -30L), seem to be corrupted.  I made a
>>> standalong program to test powl and saw no problem - it gives the
>>> same results for the fractional part as bc does.
>>>
>>>           bc: A2425FF7 5E14FC31 A125...
>>> standalone: 22425FF7 5E14FC32
>>>            R: 22425FF7 5E151800
>>>
>>> There are lots of other small numbers with the same problem:
>>>
>>>
>>>                                > grep(value=TRUE, "0e",
>>> vapply((1+(0:10000)/1000)*1e-15, deparse, ""))
>>> [1] "8.56000000000000e-15" "8.71700000000000e-15" "8.77800000000000e-15"
>>> [4] "8.93500000000000e-15" "9.50800000000000e-15" "9.83800000000000e-15"
>>> [7] "9.89900000000000e-15" "9.93400000000000e-15" "9.99500000000000e-15"
>>>> str(grep(value=TRUE, "0e", vapply((1+(0:10000)/1000)*1e-14, deparse, "")))
>>>    chr [1:295] "8.00200000000000e-14" "8.00500000000000e-14" ...
>>>
>>> Has anyone else seen this?  I am wondering if this is an oddity in WSL2
>>>
>>>                                or Ubuntu's gcc-9.3.0.
> I cannot reproduce this issue (version 20H2, build 19042.630; Ubuntu
> 20.04 installed from the store). Are you sure you are running on WSL2?
> (You can check this with `wsl --list --verbose`).
>
>> Almost surely it is Windows/WSL related, I'm not seeing this on Ubuntu
>> 20.04.
>>
>> One thing to check might be the FPU control word. In a Windows build, R
>> will set as it is on Unix, to use all 80 bits when values stay in FPU
>> registers, which is not the Windows default. This should not matter with
>> SSE anymore, but maybe something is still using the FPU. This is just
>> using inline assembly, so one could enable it as experiment. In
>> principle, this could be also due to some other things specific to
>> Windows that R works around in Windows builds, but doesn't in Linux
>> builds assuming they will not run on Windows.
> It does run on Linux. WSL2 runs a modified version of the Linux kernel
> on top of Hyper-V. Unless Bill is running WSL1, which runs on top of
> the Windows kernel with a syscall translation layer.
Yes, those experiments were with WSL 1.

I can reproduce the issue with "deparse(1e-16)" in Ubuntu 18.04 running 
in WSL 1, using r-base-core (not building R from source).

After upgrading the image to WSL 2 using "wsl --set-version Ubuntu-18.04 
2",  "deparse(1e-16)" works as it should on my system.

Best
Tomas

>
>> Other issues I had with WSL in the past (trying to build R and run
>> checks) included time-zones and surprising encodings, but I didn't check
>> recently. I would not use R on WSL unless my goal was to diagnose these
>> issues and see if they could be overcome on the R side.
>>
>> Best
>> Tomas