formatting issue with gcc 9.3.0 on Ubuntu on WSL2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

formatting issue with gcc 9.3.0 on Ubuntu on WSL2

Bill Dunlap-2
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.




           -Bill

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: formatting issue with gcc 9.3.0 on Ubuntu on WSL2

Dirk Eddelbuettel

On 17 November 2020 at 12:34, 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.

Plain Ubuntu 20.04.1 here, current. No issue:

  > str(grep(value=TRUE, "0e", vapply((1+(0:10000)/1000)*1e-14, deparse, "")))
   chr(0)
  >

I made sure to start R as `R --vanilla` to not have anything in my dotfiles
affect printing.

Dirk

--
https://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: formatting issue with gcc 9.3.0 on Ubuntu on WSL2

Tomas Kalibera
In reply to this post by Bill Dunlap-2
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
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.

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

>
>
>
>
>             -Bill
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: formatting issue with gcc 9.3.0 on Ubuntu on WSL2

Iñaki Ucar
On Wed, 18 Nov 2020 at 10:26, Tomas Kalibera <[hidden email]> 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.

> 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

--
Iñaki Úcar

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: formatting issue with gcc 9.3.0 on Ubuntu on WSL2

Bill Dunlap-2
In reply to this post by Iñaki Ucar
Thanks all.! I was running WSL 1 instead of 2 because I ignored the error
message from 'wsl --set-default-version 2'.  The BIOS was set up correctly
but the Hypervisor wasn't enabled - enabling all the Hypervisor features in
Control Panel and then doing ' wsl --set-version Ubuntu 2' in
Poweshell fixed the problem.

This also fixed one of my test C programs: '1.0L + 1e-60L > 1.0L' was true
if I compiled with gcc -O but false with no optimization.

On Wed, Nov 18, 2020 at 3:56 AM Iñaki Ucar <[hidden email]> wrote:

> On Wed, 18 Nov 2020 at 10:26, Tomas Kalibera <[hidden email]>
> 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.
>
> > 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
>
> --
> Iñaki Úcar
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel