[Rcpp-devel] Typecasting bug in Rcpp::List (generic_name_proxy) when using clang
Hi,
the following testcase exposes a difference in gcc and clang
snip
#include Rcpp.h
#include RInside.h
int main(int argc, char *argv[]) {
// We need some kind of R environment to create a List.
RInside R;
Rcpp::List list;
list[a] = 42;
int a_auto = list[a];
int a_cast = Rcpp::asint(list[a]);
std::cout list[\a\]= a_auto std::endl;
std::cout Rcpp::asint(list[\a\]) = a_cast std::endl;
}
snip
Results:
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
list[a]= 42
Rcpp::asint(list[a]) = 42
Ubuntu clang version 3.5-1ubuntu1 (trunk) (based on LLVM 3.5)
list[a]= 1
Rcpp::asint(list[a]) = 42
list[a] returns a Rcpp::internal::generic_name_proxy19, which has
the following typecasting operators: (rcpp/vector/proxy.h)
snip
template typename T
operator T() const {
#if RCPP_DEBUG_LEVEL 0
SEXP res = get() ;
RCPP_DEBUG_1( generic_name_proxy::get() = %p , res ) ;
return ::Rcpp::asT( res ) ;
#else
return ::Rcpp::asT( get() ) ;
#endif
}
operator bool() const{
return ::Rcpp::asbool(get());
}
snip
A few sprinkled printf's reveal that clang will call the bool typecast,
while gcc calls the template as intended.
Now that I know, I can easily work around it by using Rcpp::as where
needed (and I'm posting here so maybe others can find the information),
but maybe it should be fixed. ;)
I don't know all the intricacies of the C++ standard. Is this a bug in
clang? Or is clang free to use any conversion operator it likes, and
Rcpp is at fault for relying on implementation details of gcc?
If the former, I'll create a reduced testcase and file a bug with clang.
If the latter, I noticed that removing the bool typecast altogether will
cause clang to correctly return 42. Unless there is a good reason for
its existence (say, to suppress logging for bool casts), we could just
remove it.
Grep'ping all the includes suggest that this is the only class with
redundant typecast operators.
Ciao,
Christian
--
Christian Authmann
Philipps-Universität Marburg
Fachbereich Mathematik und Informatik
AG Datenbanksysteme
Hans-Meerwein-Straße
D-35032 Marburg
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Typecasting bug in Rcpp::List (generic_name_proxy) when using clang
This is likely to be a bug in Rcpp, don't go bother clang about it:)
Perhaps you can try to remove the bool cast and run the test suite. If
everything works, then it either means that there are no tests for the
particular case or that the overload is useless.
You probably have to consider what happens with :
list[a] = false ;
bool a = list[a] ;
i.e. does it work when the overload is removed, etc ...
Also, it will be more useful if the example was not using RInside, as this has
nothing to do with RInside really. You can easily demonstrate the problem with
a cppFunction or a sourceCpp without having to go through RInside.
I'd recommend to go here for bug submission:
https://github.com/RcppCore/Rcpp/issues
Romain
Le 29 juil. 2014 à 10:36, Christian Authmann
authm...@mathematik.uni-marburg.de a écrit :
Hi,
the following testcase exposes a difference in gcc and clang
snip
#include Rcpp.h
#include RInside.h
int main(int argc, char *argv[]) {
// We need some kind of R environment to create a List.
RInside R;
Rcpp::List list;
list[a] = 42;
int a_auto = list[a];
int a_cast = Rcpp::asint(list[a]);
std::cout list[\a\]= a_auto std::endl;
std::cout Rcpp::asint(list[\a\]) = a_cast std::endl;
}
snip
Results:
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
list[a]= 42
Rcpp::asint(list[a]) = 42
Ubuntu clang version 3.5-1ubuntu1 (trunk) (based on LLVM 3.5)
list[a]= 1
Rcpp::asint(list[a]) = 42
list[a] returns a Rcpp::internal::generic_name_proxy19, which has the
following typecasting operators: (rcpp/vector/proxy.h)
snip
template typename T
operator T() const {
#if RCPP_DEBUG_LEVEL 0
SEXP res = get() ;
RCPP_DEBUG_1( generic_name_proxy::get() = %p , res ) ;
return ::Rcpp::asT( res ) ;
#else
return ::Rcpp::asT( get() ) ;
#endif
}
operator bool() const{
return ::Rcpp::asbool(get());
}
snip
A few sprinkled printf's reveal that clang will call the bool typecast, while
gcc calls the template as intended.
Now that I know, I can easily work around it by using Rcpp::as where needed
(and I'm posting here so maybe others can find the information), but maybe it
should be fixed. ;)
I don't know all the intricacies of the C++ standard. Is this a bug in clang?
Or is clang free to use any conversion operator it likes, and Rcpp is at
fault for relying on implementation details of gcc?
If the former, I'll create a reduced testcase and file a bug with clang.
If the latter, I noticed that removing the bool typecast altogether will
cause clang to correctly return 42. Unless there is a good reason for its
existence (say, to suppress logging for bool casts), we could just remove it.
Grep'ping all the includes suggest that this is the only class with redundant
typecast operators.
Ciao,
Christian
--
Christian Authmann
Philipps-Universität Marburg
Fachbereich Mathematik und Informatik
AG Datenbanksysteme
Hans-Meerwein-Straße
D-35032 Marburg
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Typecasting bug in Rcpp::List (generic_name_proxy) when using clang
I've removed the bool cast from last week's git, reinstalled the
package, ran the test suite with --allTests, recompiled my own codes,
everything seems to work.
If the bool cast is missing, the code should just fall back to the
templated operator T(), with T=bool. Unless RCPP_DEBUG_LEVEL is enabled,
those are identical.
RUNIT TEST PROTOCOL -- Tue Jul 29 13:20:29 2014
***
Number of test functions: 439
Number of errors: 0
Number of failures: 0
Sorry, due to a restrictive firewall on my dev computer, I cannot access
github from it. A mail will have to suffice for now.
Ciao,
Christian
On 29.07.2014 10:44, Romain Francois wrote:
This is likely to be a bug in Rcpp, don't go bother clang about it:)
Perhaps you can try to remove the bool cast and run the test suite. If
everything works, then it either means that there are no tests for the
particular case or that the overload is useless.
You probably have to consider what happens with :
list[a] = false ;
bool a = list[a] ;
i.e. does it work when the overload is removed, etc ...
Also, it will be more useful if the example was not using RInside, as this has
nothing to do with RInside really. You can easily demonstrate the problem with
a cppFunction or a sourceCpp without having to go through RInside.
I'd recommend to go here for bug submission:
https://github.com/RcppCore/Rcpp/issues
Romain
Le 29 juil. 2014 à 10:36, Christian Authmann
authm...@mathematik.uni-marburg.de a écrit :
Hi,
the following testcase exposes a difference in gcc and clang
snip
#include Rcpp.h
#include RInside.h
int main(int argc, char *argv[]) {
// We need some kind of R environment to create a List.
RInside R;
Rcpp::List list;
list[a] = 42;
int a_auto = list[a];
int a_cast = Rcpp::asint(list[a]);
std::cout list[\a\]= a_auto std::endl;
std::cout Rcpp::asint(list[\a\]) = a_cast std::endl;
}
snip
Results:
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
list[a]= 42
Rcpp::asint(list[a]) = 42
Ubuntu clang version 3.5-1ubuntu1 (trunk) (based on LLVM 3.5)
list[a]= 1
Rcpp::asint(list[a]) = 42
list[a] returns a Rcpp::internal::generic_name_proxy19, which has the
following typecasting operators: (rcpp/vector/proxy.h)
snip
template typename T
operator T() const {
#if RCPP_DEBUG_LEVEL 0
SEXP res = get() ;
RCPP_DEBUG_1( generic_name_proxy::get() = %p , res ) ;
return ::Rcpp::asT( res ) ;
#else
return ::Rcpp::asT( get() ) ;
#endif
}
operator bool() const{
return ::Rcpp::asbool(get());
}
snip
A few sprinkled printf's reveal that clang will call the bool typecast, while
gcc calls the template as intended.
Now that I know, I can easily work around it by using Rcpp::as where needed
(and I'm posting here so maybe others can find the information), but maybe it
should be fixed. ;)
I don't know all the intricacies of the C++ standard. Is this a bug in clang?
Or is clang free to use any conversion operator it likes, and Rcpp is at fault
for relying on implementation details of gcc?
If the former, I'll create a reduced testcase and file a bug with clang.
If the latter, I noticed that removing the bool typecast altogether will cause
clang to correctly return 42. Unless there is a good reason for its existence
(say, to suppress logging for bool casts), we could just remove it.
Grep'ping all the includes suggest that this is the only class with redundant
typecast operators.
Ciao,
Christian
--
Christian Authmann
Philipps-Universität Marburg
Fachbereich Mathematik und Informatik
AG Datenbanksysteme
Hans-Meerwein-Straße
D-35032 Marburg
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Typecasting bug in Rcpp::List (generic_name_proxy) when using clang
Thanks. Hopefully someone will pick it up or at least create an issue by proxy
for you.
Romain
Le 29 juil. 2014 à 12:17, Christian Authmann
authm...@mathematik.uni-marburg.de a écrit :
I've removed the bool cast from last week's git, reinstalled the package, ran
the test suite with --allTests, recompiled my own codes, everything seems to
work.
If the bool cast is missing, the code should just fall back to the templated
operator T(), with T=bool. Unless RCPP_DEBUG_LEVEL is enabled, those are
identical.
RUNIT TEST PROTOCOL -- Tue Jul 29 13:20:29 2014
***
Number of test functions: 439
Number of errors: 0
Number of failures: 0
Sorry, due to a restrictive firewall on my dev computer, I cannot access
github from it. A mail will have to suffice for now.
Ciao,
Christian
On 29.07.2014 10:44, Romain Francois wrote:
This is likely to be a bug in Rcpp, don't go bother clang about it:)
Perhaps you can try to remove the bool cast and run the test suite. If
everything works, then it either means that there are no tests for the
particular case or that the overload is useless.
You probably have to consider what happens with :
list[a] = false ;
bool a = list[a] ;
i.e. does it work when the overload is removed, etc ...
Also, it will be more useful if the example was not using RInside, as this
has nothing to do with RInside really. You can easily demonstrate the
problem with a cppFunction or a sourceCpp without having to go through
RInside.
I'd recommend to go here for bug submission:
https://github.com/RcppCore/Rcpp/issues
Romain
Le 29 juil. 2014 à 10:36, Christian Authmann
authm...@mathematik.uni-marburg.de a écrit :
Hi,
the following testcase exposes a difference in gcc and clang
snip
#include Rcpp.h
#include RInside.h
int main(int argc, char *argv[]) {
// We need some kind of R environment to create a List.
RInside R;
Rcpp::List list;
list[a] = 42;
int a_auto = list[a];
int a_cast = Rcpp::asint(list[a]);
std::cout list[\a\]= a_auto std::endl;
std::cout Rcpp::asint(list[\a\]) = a_cast std::endl;
}
snip
Results:
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
list[a]= 42
Rcpp::asint(list[a]) = 42
Ubuntu clang version 3.5-1ubuntu1 (trunk) (based on LLVM 3.5)
list[a]= 1
Rcpp::asint(list[a]) = 42
list[a] returns a Rcpp::internal::generic_name_proxy19, which has the
following typecasting operators: (rcpp/vector/proxy.h)
snip
template typename T
operator T() const {
#if RCPP_DEBUG_LEVEL 0
SEXP res = get() ;
RCPP_DEBUG_1( generic_name_proxy::get() = %p , res ) ;
return ::Rcpp::asT( res ) ;
#else
return ::Rcpp::asT( get() ) ;
#endif
}
operator bool() const{
return ::Rcpp::asbool(get());
}
snip
A few sprinkled printf's reveal that clang will call the bool typecast,
while gcc calls the template as intended.
Now that I know, I can easily work around it by using Rcpp::as where needed
(and I'm posting here so maybe others can find the information), but maybe
it should be fixed. ;)
I don't know all the intricacies of the C++ standard. Is this a bug in
clang? Or is clang free to use any conversion operator it likes, and Rcpp
is at fault for relying on implementation details of gcc?
If the former, I'll create a reduced testcase and file a bug with clang.
If the latter, I noticed that removing the bool typecast altogether will
cause clang to correctly return 42. Unless there is a good reason for its
existence (say, to suppress logging for bool casts), we could just remove
it.
Grep'ping all the includes suggest that this is the only class with
redundant typecast operators.
Ciao,
Christian
--
Christian Authmann
Philipps-Universität Marburg
Fachbereich Mathematik und Informatik
AG Datenbanksysteme
Hans-Meerwein-Straße
D-35032 Marburg
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Typecasting bug in Rcpp::List (generic_name_proxy) when using clang
Sent a PR. Everything was pretty well explained in the original email. Le 29 juil. 2014 à 13:51, Dirk Eddelbuettel e...@debian.org a écrit : On 29 July 2014 at 12:17, Christian Authmann wrote: | Sorry, due to a restrictive firewall on my dev computer, I cannot access | github from it. A mail will have to suffice for now. Can you email me a proper patch, created the usual way via diff -u, or git diff ? Thanks, Dirk ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Typecasting bug in Rcpp::List (generic_name_proxy) when using clang
On 29 July 2014 at 15:09, Romain François wrote: | Sent a PR. Thanks, merged. | Everything was pretty well explained in the original email. Sure. But I wasn't involved in that discussion, and it makes more sense if those closer to the issue take initiative -- so thanks for sending the PR. Dirk | Le 29 juil. 2014 à 13:51, Dirk Eddelbuettel e...@debian.org a écrit : | | | On 29 July 2014 at 12:17, Christian Authmann wrote: | | Sorry, due to a restrictive firewall on my dev computer, I cannot access | | github from it. A mail will have to suffice for now. | | Can you email me a proper patch, created the usual way via diff -u, or git diff ? | | Thanks, Dirk | -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
