Difference in NA behavior in R-devel running under valgrind

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

Difference in NA behavior in R-devel running under valgrind

Jonathan Keane
Hello,

I'm debugging some valgrind issues, and noticed some odd behavior with
NA an R-devel under valgrind.

Using Winston Chang's r-debug image (and some of this reproductions form [1]):

r-devel (2021-04-27 r80232) without Valgrind returns NA:
# RD --quiet -e "sum(c(1, NA))"
> sum(c(1, NA))
[1] NA


r-devel with `-d valgrind` returns NaN:
# RD -d valgrind --quiet -e "sum(c(1, NA))"
==8901== Memcheck, a memory error detector
==8901== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==8901== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==8901== Command: /usr/local/RD/lib/R/bin/exec/R --quiet -e sum(c(1,~+~NA))
==8901==
> sum(c(1, NA))
[1] NaN


And finally release R (with valgrind) returns NA just like r-devel
while not under Valgrind:
# R -d valgrind --quiet -e "sum(c(1, NA))"
==8983== Memcheck, a memory error detector
==8983== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==8983== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==8983== Command: /usr/lib/R/bin/exec/R --quiet -e sum(c(1,~+~NA))
==8983==
> sum(c(1, NA))
[1] NA

Thanks

[1] - https://github.com/wch/r-debug/issues/18

-Jon

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

Re: Difference in NA behavior in R-devel running under valgrind

R devel mailing list
NA propagation is complicated.  I don't know whether what
you observe could be explained by the difference between
a valgrind instrumented vs. not version of R (I gather the
release version you used is not instrumented / possibly
compiled differently too from the github issue?).

Hopefully someone more knowledgeable would chime in, but
I did want to share Tomas's post that touches on the
complexity of NA_real_ propagation:

https://developer.r-project.org/Blog/public/2020/11/02/will-r-work-on-apple-silicon/#nanan-payload-propagation

Best,

B.






On Thursday, April 29, 2021, 6:04:38 PM EDT, Jonathan Keane <[hidden email]> wrote:





Hello,

I'm debugging some valgrind issues, and noticed some odd behavior with
NA an R-devel under valgrind.

Using Winston Chang's r-debug image (and some of this reproductions form [1]):

r-devel (2021-04-27 r80232) without Valgrind returns NA:
# RD --quiet -e "sum(c(1, NA))"
> sum(c(1, NA))
[1] NA


r-devel with `-d valgrind` returns NaN:
# RD -d valgrind --quiet -e "sum(c(1, NA))"
==8901== Memcheck, a memory error detector
==8901== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==8901== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==8901== Command: /usr/local/RD/lib/R/bin/exec/R --quiet -e sum(c(1,~+~NA))
==8901==
> sum(c(1, NA))
[1] NaN


And finally release R (with valgrind) returns NA just like r-devel
while not under Valgrind:
# R -d valgrind --quiet -e "sum(c(1, NA))"
==8983== Memcheck, a memory error detector
==8983== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==8983== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==8983== Command: /usr/lib/R/bin/exec/R --quiet -e sum(c(1,~+~NA))
==8983==
> sum(c(1, NA))
[1] NA

Thanks

[1] - https://github.com/wch/r-debug/issues/18

-Jon

______________________________________________
[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: Difference in NA behavior in R-devel running under valgrind

Winston Chang
Just to be clear, the RD binary that Jon used was NOT compiled with
Valgrind level 2 instrumentation. In his example, however, he did run it
with valgrind, as in:
# RD -d valgrind --quiet -e "sum(c(1, NA))"
...
> sum(c(1, NA))
[1] NaN

`RD` in that Docker image is a standard build of R-devel. The Docker image
does include a build of R-devel with valgrind level 2 instrumentation,
called `RDvalgrind`. It exhibits the same NaN behavior when run with `-d
valgrind`, but when run without `-d valgrind` it returns NA.

# RDvalgrind -d valgrind --quiet -e "sum(c(1, NA))"
> sum(c(1, NA))
[1] NaN

# RDvalgrind --quiet -e "sum(c(1, NA))"
> sum(c(1, NA))
[1] NA

In short `RDvalgrind` behaves the same as `RD`. However, adding `-d
valgrind` to either one causes it to return NaN.

-Winston


On Thu, Apr 29, 2021 at 5:27 PM brodie gaslam via R-devel <
[hidden email]> wrote:

> NA propagation is complicated.  I don't know whether what
> you observe could be explained by the difference between
> a valgrind instrumented vs. not version of R (I gather the
> release version you used is not instrumented / possibly
> compiled differently too from the github issue?).
>
> Hopefully someone more knowledgeable would chime in, but
> I did want to share Tomas's post that touches on the
> complexity of NA_real_ propagation:
>
>
> https://developer.r-project.org/Blog/public/2020/11/02/will-r-work-on-apple-silicon/#nanan-payload-propagation
>
> Best,
>
> B.
>
>
>
>
>
>
> On Thursday, April 29, 2021, 6:04:38 PM EDT, Jonathan Keane <
> [hidden email]> wrote:
>
>
>
>
>
> Hello,
>
> I'm debugging some valgrind issues, and noticed some odd behavior with
> NA an R-devel under valgrind.
>
> Using Winston Chang's r-debug image (and some of this reproductions form
> [1]):
>
> r-devel (2021-04-27 r80232) without Valgrind returns NA:
> # RD --quiet -e "sum(c(1, NA))"
> > sum(c(1, NA))
> [1] NA
>
>
> r-devel with `-d valgrind` returns NaN:
> # RD -d valgrind --quiet -e "sum(c(1, NA))"
> ==8901== Memcheck, a memory error detector
> ==8901== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==8901== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
> ==8901== Command: /usr/local/RD/lib/R/bin/exec/R --quiet -e sum(c(1,~+~NA))
> ==8901==
> > sum(c(1, NA))
> [1] NaN
>
>
> And finally release R (with valgrind) returns NA just like r-devel
> while not under Valgrind:
> # R -d valgrind --quiet -e "sum(c(1, NA))"
> ==8983== Memcheck, a memory error detector
> ==8983== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==8983== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
> ==8983== Command: /usr/lib/R/bin/exec/R --quiet -e sum(c(1,~+~NA))
> ==8983==
> > sum(c(1, NA))
> [1] NA
>
> Thanks
>
> [1] - https://github.com/wch/r-debug/issues/18
>
> -Jon
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[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: Difference in NA behavior in R-devel running under valgrind

R devel mailing list
 > On Thursday, April 29, 2021, 6:35:16 PM EDT, Winston Chang <[hidden email]> wrote:

> Just to be clear, the RD binary that Jon used was NOT compiled with
> Valgrind level 2 instrumentation. In his example, however, he did run it
> with valgrind, as in:
>
> # RD -d valgrind --quiet -e "sum(c(1, NA))"
> ...
> > sum(c(1, NA))
> [1] NaN
>
> `RD` in that Docker image is a standard build of R-devel. The Docker
> image does include a build of R-devel with valgrind level 2
> instrumentation, called `RDvalgrind`. It exhibits the same NaN behavior
> when run with `-d valgrind`, but when run without `-d valgrind` it
> returns NA.
>
> # RDvalgrind -d valgrind --quiet -e "sum(c(1, NA))"
> > sum(c(1, NA))
> [1] NaN
>
> # RDvalgrind --quiet -e "sum(c(1, NA))"
> > sum(c(1, NA))
> [1] NA
>
> In short `RDvalgrind` behaves the same as `RD`. However, adding `-d
> valgrind` to either one causes it to return NaN.
>
> -Winston

Thanks for the clarification.

Using the same revision in the e-mail I get the reported issue under -O0,
but not under -O2.  It looks like r-debug builds with -O0, and presumably
the release debian version is -O2 which is usually the default?  I'm
certainly no expert in this area but it seems like it could be an
optimization level rather than a release vs devel issue?

This is what I see:

gcc version 10.1.0 (Ubuntu 10.1.0-2ubuntu1~18.04)

    CC="gcc-10"
    CFLAGS="-g -O0 -Wall -pedantic -Wextra -std=gnu99"

    vagrant@vagrant:/vagrant/trunk$ ./bin/R -d valgrind --vanilla --quiet -e "sum(c(1,NA))"
    ==9020== Memcheck, a memory error detector
    ==9020== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
    ==9020== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
    ==9020== Command: /vagrant/trunk/bin/exec/R --vanilla --quiet -e sum(c(1,NA))
    ==9020==
    > sum(c(1,NA))
    [1] NaN

And then:

    CC="gcc-10"
    CFLAGS="-g -O2 -Wall -pedantic -Wextra -std=gnu99"

    vagrant@vagrant:/vagrant/trunk$ ./bin/R -d valgrind --vanilla --quiet -e "sum(c(1,NA))"
    ==32751== Memcheck, a memory error detector
    ==32751== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
    ==32751== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
    ==32751== Command: /vagrant/trunk/bin/exec/R --vanilla --quiet -e sum(c(1,NA))
    ==32751==
    > sum(c(1,NA))
    [1] NA

Sadly I did not think to run the -O0 version without valgrind.

Best,

B.

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

Re: Difference in NA behavior in R-devel running under valgrind

R devel mailing list
Forgot to mention, my builds were not instrumented for valgrind, and also:

vagrant@vagrant:/vagrant/trunk$ ./bin/R --version
R Under development (unstable) (2021-04-27 r80232) -- "Unsuffered Consequences"
Copyright (C) 2021 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)


 On Thursday, April 29, 2021, 8:40:21 PM EDT, brodie gaslam via R-devel <[hidden email]> wrote:


> On Thursday, April 29, 2021, 6:35:16 PM EDT, Winston Chang <[hidden email]> wrote:
> Just to be clear, the RD binary that Jon used was NOT compiled with
> Valgrind level 2 instrumentation. In his example, however, he did run it
> with valgrind, as in:
>
> # RD -d valgrind --quiet -e "sum(c(1, NA))"
> ...
> > sum(c(1, NA))
> [1] NaN
>
> `RD` in that Docker image is a standard build of R-devel. The Docker
> image does include a build of R-devel with valgrind level 2
> instrumentation, called `RDvalgrind`. It exhibits the same NaN behavior
> when run with `-d valgrind`, but when run without `-d valgrind` it
> returns NA.
>
> # RDvalgrind -d valgrind --quiet -e "sum(c(1, NA))"
> > sum(c(1, NA))
> [1] NaN
>
> # RDvalgrind --quiet -e "sum(c(1, NA))"
> > sum(c(1, NA))
> [1] NA
>
> In short `RDvalgrind` behaves the same as `RD`. However, adding `-d
> valgrind` to either one causes it to return NaN.
>
> -Winston

Thanks for the clarification.

Using the same revision in the e-mail I get the reported issue under -O0,
but not under -O2.  It looks like r-debug builds with -O0, and presumably
the release debian version is -O2 which is usually the default?  I'm
certainly no expert in this area but it seems like it could be an
optimization level rather than a release vs devel issue?

This is what I see:

gcc version 10.1.0 (Ubuntu 10.1.0-2ubuntu1~18.04)

    CC="gcc-10"
    CFLAGS="-g -O0 -Wall -pedantic -Wextra -std=gnu99"

    vagrant@vagrant:/vagrant/trunk$ ./bin/R -d valgrind --vanilla --quiet -e "sum(c(1,NA))"
    ==9020== Memcheck, a memory error detector
    ==9020== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
    ==9020== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
    ==9020== Command: /vagrant/trunk/bin/exec/R --vanilla --quiet -e sum(c(1,NA))
    ==9020==
    > sum(c(1,NA))
    [1] NaN

And then:

    CC="gcc-10"
    CFLAGS="-g -O2 -Wall -pedantic -Wextra -std=gnu99"

    vagrant@vagrant:/vagrant/trunk$ ./bin/R -d valgrind --vanilla --quiet -e "sum(c(1,NA))"
    ==32751== Memcheck, a memory error detector
    ==32751== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
    ==32751== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
    ==32751== Command: /vagrant/trunk/bin/exec/R --vanilla --quiet -e sum(c(1,NA))
    ==32751==
    > sum(c(1,NA))
    [1] NA

Sadly I did not think to run the -O0 version without valgrind.


Best,

B.

______________________________________________
[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: Difference in NA behavior in R-devel running under valgrind

Tomas Kalibera
I can reproduce on my system, running an unoptimized R build (-O0) in
valgrind produces NaN (valgrind 3.15.0, gcc 9.3.0 - Ubuntu 20.04/x86_64)
for the example, but without valgrind it produces NA.

Valgrind modifies the binary code before running it and this is probably
what is causing the different NaN payload propagation in this case. This
is not great, it seems to be yet another way how the NA/NaN distinction
may become unreliable.

Tomas

On 4/30/21 2:42 AM, brodie gaslam via R-devel wrote:

> Forgot to mention, my builds were not instrumented for valgrind, and also:
>
> vagrant@vagrant:/vagrant/trunk$ ./bin/R --version
> R Under development (unstable) (2021-04-27 r80232) -- "Unsuffered Consequences"
> Copyright (C) 2021 The R Foundation for Statistical Computing
> Platform: x86_64-pc-linux-gnu (64-bit)
>
>
>   On Thursday, April 29, 2021, 8:40:21 PM EDT, brodie gaslam via R-devel <[hidden email]> wrote:
>
>
>> On Thursday, April 29, 2021, 6:35:16 PM EDT, Winston Chang <[hidden email]> wrote:
>> Just to be clear, the RD binary that Jon used was NOT compiled with
>> Valgrind level 2 instrumentation. In his example, however, he did run it
>> with valgrind, as in:
>>
>> # RD -d valgrind --quiet -e "sum(c(1, NA))"
>> ...
>>> sum(c(1, NA))
>> [1] NaN
>>
>> `RD` in that Docker image is a standard build of R-devel. The Docker
>> image does include a build of R-devel with valgrind level 2
>> instrumentation, called `RDvalgrind`. It exhibits the same NaN behavior
>> when run with `-d valgrind`, but when run without `-d valgrind` it
>> returns NA.
>>
>> # RDvalgrind -d valgrind --quiet -e "sum(c(1, NA))"
>>> sum(c(1, NA))
>> [1] NaN
>>
>> # RDvalgrind --quiet -e "sum(c(1, NA))"
>>> sum(c(1, NA))
>> [1] NA
>>
>> In short `RDvalgrind` behaves the same as `RD`. However, adding `-d
>> valgrind` to either one causes it to return NaN.
>>
>> -Winston
> Thanks for the clarification.
>
> Using the same revision in the e-mail I get the reported issue under -O0,
> but not under -O2.  It looks like r-debug builds with -O0, and presumably
> the release debian version is -O2 which is usually the default?  I'm
> certainly no expert in this area but it seems like it could be an
> optimization level rather than a release vs devel issue?
>
> This is what I see:
>
> gcc version 10.1.0 (Ubuntu 10.1.0-2ubuntu1~18.04)
>
>      CC="gcc-10"
>      CFLAGS="-g -O0 -Wall -pedantic -Wextra -std=gnu99"
>
>      vagrant@vagrant:/vagrant/trunk$ ./bin/R -d valgrind --vanilla --quiet -e "sum(c(1,NA))"
>      ==9020== Memcheck, a memory error detector
>      ==9020== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
>      ==9020== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
>      ==9020== Command: /vagrant/trunk/bin/exec/R --vanilla --quiet -e sum(c(1,NA))
>      ==9020==
>      > sum(c(1,NA))
>      [1] NaN
>
> And then:
>
>      CC="gcc-10"
>      CFLAGS="-g -O2 -Wall -pedantic -Wextra -std=gnu99"
>
>      vagrant@vagrant:/vagrant/trunk$ ./bin/R -d valgrind --vanilla --quiet -e "sum(c(1,NA))"
>      ==32751== Memcheck, a memory error detector
>      ==32751== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
>      ==32751== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
>      ==32751== Command: /vagrant/trunk/bin/exec/R --vanilla --quiet -e sum(c(1,NA))
>      ==32751==
>      > sum(c(1,NA))
>      [1] NA
>
> Sadly I did not think to run the -O0 version without valgrind.
>
>
> Best,
>
> B.
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [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: Difference in NA behavior in R-devel running under valgrind

Tomas Kalibera
I confirm it is valgrind behavior, it does not preserve the NaN payload
when converting 80-bit and 64-bit floating point numbers on Intel (also
it treats denormals as zero, more information is in comments in valgrind
source, file guest_generic_x87.c).

The quick-hack patch below can be applied to preserve the payload and
makes that example, sum(c(1, NA)), return NA on my machine.

Best
Tomas

-- orig/valgrind-3.15.0/VEX/priv/guest_generic_x87.c 2019-04-13
12:56:21.000000000 +0200
+++ patched/valgrind-3.15.0/VEX/priv/guest_generic_x87.c 2021-04-30
12:17:44.763195785 +0200
@@ -210,6 +210,10 @@
           f80[6] = f80[5] = f80[4] = f80[3]
                  = f80[2] = f80[1] = f80[0] = 0xFF;
        }
+      f80[0] = f64[0]; /* R hack: copy NaN payload */
+      f80[1] = f64[1];
+      f80[2] = f64[2];
+      f80[3] = f64[3];
        return;
     }

@@ -310,6 +314,11 @@
           f64[6] = 0xF7;
           f64[5] = f64[4] = f64[3] = f64[2] = f64[1] = f64[0] = 0xFF;
        }
+      f64[0] = f80[0]; /* R hack: copy NaN payload */
+      f64[1] = f80[1];
+      f64[2] = f80[2];
+      f64[3] = f80[3];
+
        return;
     }

On 4/30/21 10:02 AM, Tomas Kalibera wrote:

> I can reproduce on my system, running an unoptimized R build (-O0) in
> valgrind produces NaN (valgrind 3.15.0, gcc 9.3.0 - Ubuntu
> 20.04/x86_64) for the example, but without valgrind it produces NA.
>
> Valgrind modifies the binary code before running it and this is
> probably what is causing the different NaN payload propagation in this
> case. This is not great, it seems to be yet another way how the NA/NaN
> distinction may become unreliable.
>
> Tomas
>
> On 4/30/21 2:42 AM, brodie gaslam via R-devel wrote:
>> Forgot to mention, my builds were not instrumented for valgrind, and
>> also:
>>
>> vagrant@vagrant:/vagrant/trunk$ ./bin/R --version
>> R Under development (unstable) (2021-04-27 r80232) -- "Unsuffered
>> Consequences"
>> Copyright (C) 2021 The R Foundation for Statistical Computing
>> Platform: x86_64-pc-linux-gnu (64-bit)
>>
>>
>>   On Thursday, April 29, 2021, 8:40:21 PM EDT, brodie gaslam via
>> R-devel <[hidden email]> wrote:
>>
>>
>>> On Thursday, April 29, 2021, 6:35:16 PM EDT, Winston Chang
>>> <[hidden email]> wrote:
>>> Just to be clear, the RD binary that Jon used was NOT compiled with
>>> Valgrind level 2 instrumentation. In his example, however, he did
>>> run it
>>> with valgrind, as in:
>>>
>>> # RD -d valgrind --quiet -e "sum(c(1, NA))"
>>> ...
>>>> sum(c(1, NA))
>>> [1] NaN
>>>
>>> `RD` in that Docker image is a standard build of R-devel. The Docker
>>> image does include a build of R-devel with valgrind level 2
>>> instrumentation, called `RDvalgrind`. It exhibits the same NaN behavior
>>> when run with `-d valgrind`, but when run without `-d valgrind` it
>>> returns NA.
>>>
>>> # RDvalgrind -d valgrind --quiet -e "sum(c(1, NA))"
>>>> sum(c(1, NA))
>>> [1] NaN
>>>
>>> # RDvalgrind --quiet -e "sum(c(1, NA))"
>>>> sum(c(1, NA))
>>> [1] NA
>>>
>>> In short `RDvalgrind` behaves the same as `RD`. However, adding `-d
>>> valgrind` to either one causes it to return NaN.
>>>
>>> -Winston
>> Thanks for the clarification.
>>
>> Using the same revision in the e-mail I get the reported issue under
>> -O0,
>> but not under -O2.  It looks like r-debug builds with -O0, and
>> presumably
>> the release debian version is -O2 which is usually the default? I'm
>> certainly no expert in this area but it seems like it could be an
>> optimization level rather than a release vs devel issue?
>>
>> This is what I see:
>>
>> gcc version 10.1.0 (Ubuntu 10.1.0-2ubuntu1~18.04)
>>
>>      CC="gcc-10"
>>      CFLAGS="-g -O0 -Wall -pedantic -Wextra -std=gnu99"
>>
>>      vagrant@vagrant:/vagrant/trunk$ ./bin/R -d valgrind --vanilla
>> --quiet -e "sum(c(1,NA))"
>>      ==9020== Memcheck, a memory error detector
>>      ==9020== Copyright (C) 2002-2017, and GNU GPL'd, by Julian
>> Seward et al.
>>      ==9020== Using Valgrind-3.13.0 and LibVEX; rerun with -h for
>> copyright info
>>      ==9020== Command: /vagrant/trunk/bin/exec/R --vanilla --quiet -e
>> sum(c(1,NA))
>>      ==9020==
>>      > sum(c(1,NA))
>>      [1] NaN
>>
>> And then:
>>
>>      CC="gcc-10"
>>      CFLAGS="-g -O2 -Wall -pedantic -Wextra -std=gnu99"
>>
>>      vagrant@vagrant:/vagrant/trunk$ ./bin/R -d valgrind --vanilla
>> --quiet -e "sum(c(1,NA))"
>>      ==32751== Memcheck, a memory error detector
>>      ==32751== Copyright (C) 2002-2017, and GNU GPL'd, by Julian
>> Seward et al.
>>      ==32751== Using Valgrind-3.13.0 and LibVEX; rerun with -h for
>> copyright info
>>      ==32751== Command: /vagrant/trunk/bin/exec/R --vanilla --quiet
>> -e sum(c(1,NA))
>>      ==32751==
>>      > sum(c(1,NA))
>>      [1] NA
>>
>> Sadly I did not think to run the -O0 version without valgrind.
>>
>>
>> Best,
>>
>> B.
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

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