Here's an example program that fails to compile with gcc-10 for me:
https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c
So I think we can conclude this is a gcc-10 bug. It also fails with
the contracts branch of gcc on godbolt (although with a different
error):
https://godbolt.or
On 8 February 2020 at 16:59, Kevin Ushey wrote:
| It seems like a bug in gcc 10 to me. IIUC, static local variables in
| inline functions should still have internal linkage, and so name
| collisions like this should not occur.
|
| I can work around this by making sure that 'fun' is given differen
It seems like a bug in gcc 10 to me. IIUC, static local variables in
inline functions should still have internal linkage, and so name
collisions like this should not occur.
I can work around this by making sure that 'fun' is given different
names in the RcppEigen stubs; e.g. fun1 and fun2 and so o
On Sat, 8 Feb 2020 at 23:50, Dirk Eddelbuettel wrote:
>
>
> On 8 February 2020 at 22:36, Iñaki Ucar wrote:
> | lme4 fails to compile with this misterious message in Fedora Rawhide
> | with gcc10 (see the build log and more details in [1]). There is no
> | "fun" in lme4, but there are several local
On 8 February 2020 at 22:36, Iñaki Ucar wrote:
| lme4 fails to compile with this misterious message in Fedora Rawhide
| with gcc10 (see the build log and more details in [1]). There is no
| "fun" in lme4, but there are several local definitions of "fun" in
| RcppEigen, used by lme4, under inst/inc
On Sat, Feb 08, 2020 at 01:44:51PM -0800, Kevin Ushey wrote:
> On Sat, Feb 8, 2020 at 12:52 PM Joshua N Pritikin wrote:
> > If I'm reading it correctly,
> > rcpp_set_stack_trace(Shield(stack_trace()))
> > will work equally well in either location. R can't introspect about
> > the C++ stack; It mu
On Sat, Feb 8, 2020 at 12:52 PM Joshua N Pritikin wrote:
>
> On Sat, Feb 08, 2020 at 03:47:49PM -0500, JJ Allaire wrote:
> >On Sat, Feb 8, 2020 at 3:45 PM Joshua N Pritikin
> ><[1]jpriti...@pobox.com> wrote:
> > Sure, but does it *have* to be that way? It seems to me that
> > exc
Hi,
lme4 fails to compile with this misterious message in Fedora Rawhide
with gcc10 (see the build log and more details in [1]). There is no
"fun" in lme4, but there are several local definitions of "fun" in
RcppEigen, used by lme4, under inst/include/RcppEigenStubs.h. These
are the relevant lines
On Sat, Feb 08, 2020 at 03:47:49PM -0500, JJ Allaire wrote:
>On Sat, Feb 8, 2020 at 3:45 PM Joshua N Pritikin
><[1]jpriti...@pobox.com> wrote:
> Sure, but does it *have* to be that way? It seems to me that
> exceptions.h line 40,
>rcpp_set_stack_trace(Shield(stack_trace())
On Sat, Feb 8, 2020 at 3:45 PM Joshua N Pritikin
wrote:
> On Sat, Feb 08, 2020 at 03:28:22PM -0500, JJ Allaire wrote:
> >Agreed that it would be good to have more clear docs here. Note
> >that as Dirk pointed out both Writing R Extensions and
> >RcppParallel docs are pretty clear abou
On Sat, Feb 08, 2020 at 03:28:22PM -0500, JJ Allaire wrote:
>Agreed that it would be good to have more clear docs here. Note
>that as Dirk pointed out both Writing R Extensions and
>RcppParallel docs are pretty clear about the fact that you
>shouldn't call any R APIs when in a ba
I think the point is that the *only* reason Rcpp::stop exists is to do
forwarding to Rf_error. If that isn't your intention it's strictly worse
than a normal C++ exception.
Agreed that it would be good to have more clear docs here. Note that as
Dirk pointed out both Writing R Extensions and RcppPa
On Sat, Feb 08, 2020 at 02:55:06PM -0500, JJ Allaire wrote:
>Yes, the only reason to use Rcpp::stop is because you want a C++
>exception translated safely into an Rf_error at the SEXP call level. If
>you are trying to signal an error from a background thread you would
>want to use a
Yes, the only reason to use Rcpp::stop is because you want a C++ exception
translated safely into an Rf_error at the SEXP call level. If you are
trying to signal an error from a background thread you would want to use a
regular C++ exception rather than Rcpp::stop.
On Sat, Feb 8, 2020 at 1:56 PM I
On Fri, 7 Feb 2020 at 14:24, Joshua N Pritikin wrote:
>
> On Thu, Feb 06, 2020 at 08:40:02PM -0600, Dirk Eddelbuettel wrote:
> > On 6 February 2020 at 20:47, Joshua N Pritikin wrote:
> > | The Rcpp::exception constructor does,
> > |
> > | rcpp_set_stack_trace(Shield(stack_trace()))
> > |
> > | T
On Fri, Feb 07, 2020 at 07:56:40AM -0600, Dirk Eddelbuettel wrote:
> See several (extended) discussions at GitHub around the issues that
> changed and improved exception handling and stack traces. A fair
> amount of very nice work made Rcpp more robust here.
>
> In short, it not a trivial issue.
16 matches
Mail list logo
