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

Tomas Kalibera tom@@@k@||ber@ @end|ng |rom gm@||@com
Wed Nov 18 10:25:27 CET 2020

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.

Almost surely it is Windows/WSL related, I'm not seeing this on Ubuntu 

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.

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.


>             -Bill
> 	[[alternative HTML version deleted]]
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

More information about the R-devel mailing list