Intel Fortran compiler returns a -1 TRUE value

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Intel Fortran compiler returns a -1 TRUE value

barry rowlingson
I have access to a cluster on which I have been supplied with R 3.1.0 which
appears to have been built using the intel compiler tools.

The following minimal Fortran file:

      subroutine truth(lind)
      logical lind
      lind = .TRUE.
      end

Compiles thusly:

arcadia> R CMD SHLIB truth.f
ifort   -fpic  -O3 -xHOST -axCORE-AVX-I -fp-model precise  -c truth.f -o
truth.o
ifort: command line warning #10212: -fp-model precise evaluates in source
precision with Fortran.
icc -std=gnu99 -shared -L/usr/local/lib64 -o truth.so truth.o -lifport
-lifcore -limf -lsvml -lm -lipgo -lirc -lpthread -lirc_s -ldl


And runs so:

 > dyn.load("truth.so")
 > z = .Fortran("truth",as.logical(TRUE))
 > z[[1]]
 [1] TRUE
 > as.numeric(z[[1]])
 [1] -1
 > z[[1]] == TRUE
 [1] FALSE
 > all(z[[1]])
 [1] TRUE
 > identical(z[[1]],TRUE)
 [1] FALSE

The value generated by Fortran's .TRUE. evaluates as "truthy" -- as in
all(z[[1]]) -- but is neither equal to nor identical to TRUE. Its numeric
conversion to -1 is most unusual, every other system I've tried converts to
+1.

So.... wrong compiler flag on build? User error - never try comparing
truthy values, as with the various flavours of NA? Or something else?

If its a compiler/config problem I'll pass it on to the cluster admin -
I've had a good look for stuff on building R on Intel compilers, nothing
stood out. I might try building R myself this afternoon but as I implied I
don't have admin on this cluster so I might have to track down a bunch of
library sources to build R from source.

If its a user error then I'll track down every instance of "if(foo==TRUE)"
and shoot it, and it would be nice to have a note in ?TRUE

Some useful info:

> sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-unknown-linux-gnu (64-bit)

arcadia> ifort -v
ifort version 13.0.0


Thanks

Barry

        [[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: Intel Fortran compiler returns a -1 TRUE value

Duncan Murdoch-2
On 30/09/2014, 7:41 AM, Barry Rowlingson wrote:

> I have access to a cluster on which I have been supplied with R 3.1.0 which
> appears to have been built using the intel compiler tools.
>
> The following minimal Fortran file:
>
>       subroutine truth(lind)
>       logical lind
>       lind = .TRUE.
>       end
>
> Compiles thusly:
>
> arcadia> R CMD SHLIB truth.f
> ifort   -fpic  -O3 -xHOST -axCORE-AVX-I -fp-model precise  -c truth.f -o
> truth.o
> ifort: command line warning #10212: -fp-model precise evaluates in source
> precision with Fortran.
> icc -std=gnu99 -shared -L/usr/local/lib64 -o truth.so truth.o -lifport
> -lifcore -limf -lsvml -lm -lipgo -lirc -lpthread -lirc_s -ldl
>
>
> And runs so:
>
>  > dyn.load("truth.so")
>  > z = .Fortran("truth",as.logical(TRUE))
>  > z[[1]]
>  [1] TRUE
>  > as.numeric(z[[1]])
>  [1] -1
>  > z[[1]] == TRUE
>  [1] FALSE
>  > all(z[[1]])
>  [1] TRUE
>  > identical(z[[1]],TRUE)
>  [1] FALSE
>
> The value generated by Fortran's .TRUE. evaluates as "truthy" -- as in
> all(z[[1]]) -- but is neither equal to nor identical to TRUE. Its numeric
> conversion to -1 is most unusual, every other system I've tried converts to
> +1.
>
> So.... wrong compiler flag on build? User error - never try comparing
> truthy values, as with the various flavours of NA? Or something else?
>
> If its a compiler/config problem I'll pass it on to the cluster admin -
> I've had a good look for stuff on building R on Intel compilers, nothing
> stood out. I might try building R myself this afternoon but as I implied I
> don't have admin on this cluster so I might have to track down a bunch of
> library sources to build R from source.
>
> If its a user error then I'll track down every instance of "if(foo==TRUE)"
> and shoot it, and it would be nice to have a note in ?TRUE
>
> Some useful info:
>
>> sessionInfo()
> R version 3.1.0 (2014-04-10)
> Platform: x86_64-unknown-linux-gnu (64-bit)
>
> arcadia> ifort -v
> ifort version 13.0.0

This appears to be user error.  According to Writing R Extensions, the
Fortran type corresponding to R logical is INTEGER, not LOGICAL.

Duncan Murdoch

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

Re: Intel Fortran compiler returns a -1 TRUE value

barry rowlingson
In reply to this post by barry rowlingson
On Tue, Sep 30, 2014 at 12:53 PM, Duncan Murdoch <[hidden email]>
wrote:

>
> This appears to be user error.  According to Writing R Extensions, the
> Fortran type corresponding to R logical is INTEGER, not LOGICAL.
>

Oh yes, a very old and long-standing user error. I assume the CRAN checks
don't check this. Has it ever been okay to pass logicals to Fortran?

 I shall inform the package maintainer....

Thanks

Barry

        [[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: Intel Fortran compiler returns a -1 TRUE value

Duncan Murdoch-2
On 30/09/2014 8:39 AM, Barry Rowlingson wrote:

>
>
> On Tue, Sep 30, 2014 at 12:53 PM, Duncan Murdoch
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>
>     This appears to be user error.  According to Writing R Extensions, the
>     Fortran type corresponding to R logical is INTEGER, not LOGICAL.
>
>
> Oh yes, a very old and long-standing user error. I assume the CRAN
> checks don't check this.

The checks can't really see that kind of thing:  they don't understand
the external languages.  It's up to the user to follow the instructions
in most cases.

> Has it ever been okay to pass logicals to Fortran?
>
It's okay to pass R logicals to Fortran (where they become INTEGER),
it's just not okay to pass Fortran LOGICALs to R. The gcc Fortran
compilers treat logicals the same as C does (i.e. 0 and 1 for FALSE and
TRUE), but others don't, as you found out.

Duncan Murdoch

>  I shall inform the package maintainer....
>
> Thanks
>
> Barry
>

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

Re: Intel Fortran compiler returns a -1 TRUE value

William Dunlap
In reply to this post by barry rowlingson
In S+ and S it was valid to pass logicals to .Fortran, where they got
mapped into the
appropriate bit pattern.  (The trouble was that 'appropriate' was
compiled into the program -
so you were locked into our compiler vendor's choice).   Passing them
between Fortran
code and C code has always been a problem (as has passing character
data between them).

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Tue, Sep 30, 2014 at 5:39 AM, Barry Rowlingson
<[hidden email]> wrote:

> On Tue, Sep 30, 2014 at 12:53 PM, Duncan Murdoch <[hidden email]>
> wrote:
>
>>
>> This appears to be user error.  According to Writing R Extensions, the
>> Fortran type corresponding to R logical is INTEGER, not LOGICAL.
>>
>
> Oh yes, a very old and long-standing user error. I assume the CRAN checks
> don't check this. Has it ever been okay to pass logicals to Fortran?
>
>  I shall inform the package maintainer....
>
> Thanks
>
> Barry
>
>         [[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: Intel Fortran compiler returns a -1 TRUE value

barry rowlingson
In reply to this post by barry rowlingson
On Tue, Sep 30, 2014 at 6:25 PM, William Dunlap <[hidden email]> wrote:

> In S+ and S it was valid to pass logicals to .Fortran, where they got
> mapped into the
> appropriate bit pattern.  (The trouble was that 'appropriate' was
> compiled into the program -
> so you were locked into our compiler vendor's choice).   Passing them
> between Fortran
> code and C code has always been a problem (as has passing character
> data between them).
>

 That makes sense. The code was originally written for S-plus, and the
accompanying R code is still in files with a .S extension....

 The maintainer has now fixed it.

Barry

        [[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: Intel Fortran compiler returns a -1 TRUE value

Ei-ji Nakama
In reply to this post by barry rowlingson
Hello

> The value generated by Fortran's .TRUE. evaluates as "truthy" -- as in
> all(z[[1]]) -- but is neither equal to nor identical to TRUE. Its numeric
> conversion to -1 is most unusual, every other system I've tried converts to
> +1.

Please read the -fpscomp logicals option of ifort.

--
"\u4e2d\u9593\u6804\u6cbb"  <nakama (a) ki.rim.or.jp>

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

Re: Intel Fortran compiler returns a -1 TRUE value

barry rowlingson
In reply to this post by barry rowlingson
On Thu, Oct 2, 2014 at 4:25 PM, Ei-ji Nakama <[hidden email]> wrote:

> Hello
>
> > The value generated by Fortran's .TRUE. evaluates as "truthy" -- as in
> > all(z[[1]]) -- but is neither equal to nor identical to TRUE. Its numeric
> > conversion to -1 is most unusual, every other system I've tried converts
> to
> > +1.
>
> Please read the -fpscomp logicals option of ifort.
>

 Wow that's an interesting read, and the line

"Intel recommends that you avoid coding practices that
              depend on the internal representation of LOGICAL values"

says it all with regard to R and Fortran LOGICALS, I think!

Barry

        [[alternative HTML version deleted]]

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