search for: therne

Yep, quite right, Evan. Any regalloc differences due to that patch are purely coincidence; -Jim > On Jun 16, 2014, at 10:13 AM, Evan Cheng <evan.cheng at apple.com> wrote: > > Hi Niklas, > > The attached patch has nothing to do with register allocation. r206094 changes how cpu auto-detection is done. I believe it's now the responsibility of the tools (e.g. llc) to

I think we have located the revision which fixes this regression: r206094 (or commit 6bb00df in llvm-mirror on GitHub). I have attached a patch which can be applied to the current release_34 branch (tested against the release_34 branch in llvm-mirror). With this patch the attached reg-alloc-test.ll file doesn't fail with the "LLVM ERROR: ran out of registers during register

I can confirm that this regression has been fixed in trunk. Should I report this as a bug in 3.4? On Thu, Apr 24, 2014 at 10:17 PM, Quentin Colombet <qcolombet at apple.com>wrote: > Hi Niklas, > > This works for me with trunk r207129. > > We did fix some register allocation issues recently, don’t know which > change fixes the issue though. > > Thanks, > -Quentin

Hi, The RoboVM project recently upgraded from LLVM 3.3 to 3.4 and with the new version we are sometimes seeing "ran out of registers during register allocation" errors when targeting x86 32-bit that we haven't seen before. Nothing has changed in our bitcode generator. I have attached an IR file which can be used to reproduce this problem. The problem occurs with -O2 and

Xen Community: As you are aware, the Xen Cloud Platform has been available for download since last November and is becoming a very successful release for Xen.org. In fact, we are seeing substantial network traffic for this solution as we had 26 TB of data from XCP downloads in the past 4 weeks. Of course, this amount of traffic is forcing a re-examination of our co-location agreements as we are

Xen Community: As you are aware, the Xen Cloud Platform has been available for download since last November and is becoming a very successful release for Xen.org. In fact, we are seeing substantial network traffic for this solution as we had 26 TB of data from XCP downloads in the past 4 weeks. Of course, this amount of traffic is forcing a re-examination of our co-location agreements as we are

Dear Community, I have been using two types of survival programs to analyse a data set. The first one is an R function called aftreg. The second one an STATA function called streg. Both of them include the same analyisis with a weibull distribution. Yet, results are very different. Shouldn't the results be the same? Kind regards, J -- View this message in context:

...g to restrict the range of some output. But at the end of the function I'd like to turn it off, i.e., so that a subsequent use of legend(), text() or whatever is not affected. I don't quite see how to do this -- it seems that the only way to turn off clip is with a new plot. -- Terry M Therneau, PhD Department of Health Science Research Mayo Clinic therneau at mayo.edu "TERR-ree THUR-noh" [[alternative HTML version deleted]]

...es and so was discovered in my test suite.? I had planned to submit an update today, but now need to delay it. The length of the Surv (Durv) object above is 8, BTW; the fact that it's representation requires either 16 elements (right censored) or 24 (interval censored) is a footnote. Terry Therneau [[alternative HTML version deleted]]

Background: I run tools::testInstalledPackage on all packages that dependend on survival (605 as of today) before sending a new release to CRAN. It has a few false positives which I then follow up on.? (Mostly packages with as-yet-incomplete tests in their inst directory). ?Issue: testInstalledPackage("mets")? generates an? "Error in checkVignettes(pkg, lib.loc, latex = FALSE,

The addition of significant stars was, in my opinion, one of the worst defaults ever added to R.?? I would be delighted to see it removed, or at least change the default.? It is one of the few overrides that I have argued to add to our site-wide defaults file. My bias comes from 30+ years in a medical statistics career where fighting the disease of "dichotomania" has been an eternal

The all.equal was a side issue for me; I don't have strong opinions one way or the other.? You are welcome to leave me out of the loop on that.? (Or leave me on the cc, whatever is easiest). ?I will update the survival package once the [.terms issues are addressed. ?One debatable issues is the choice of change vs document for the offset() issue.? With my proposed fix or without it,

I had added a vignette to the coxme package and all worked well locally, but it failed at CRAN.???? The issue is that the vignette involves using coxme for pedigree data, it doesn't work without the kinship2 package, and I hadn't put in the necessary "if (require(...." logic. The question is, how do I make the entire vignette conditional? If the package isn't available,

For a new release of survival, I normally run? R CMD check for every one of the packages that depend on survival? (forewarned is forearmed). I updated R-devel on the test machine this morning, and R CMD check --as-cran survival_3.0-9.tar.gz works as desired. When I run the check routine on any other source file, however, downloaded from CRAN, it fails nearly immediately with a message like

...bout a server that one could use for reverse dependency checks, but I forgot to write it down.? (Or I did save the info and forgot where I saved it...)?? I have been doing the checks for survival myself, but the count is getting out of hand (663, not counting bioconductor). Any pointers? Terry Therneau [[alternative HTML version deleted]]

I treat CRAN as the main repository for survival, but I have also had a github (therneau/survival) version for a couple of years.? It has a vignette2 directory, for instance, that contains extra vignettes that either take too long to run or depend on other packages.? It also gets updated more often than CRAN (though those updates mght not be as well tested yet). In any case, sinc...

Yes, that is exactly the problem.? The code found in the "config" script is never run.? But why doesn't it get run? On 9/6/19 5:44 AM, Georgi Boshnakov wrote: > I cloned therneau/survival and the installation failed since there is no definition for exported function survfit(). > A file seems to be missing - there is survfit0() and survfit0.R but, compared to CRAN, no survfit.R. > > Georgi Boshnakov > > > --------------------------------------------------...

I've been fighting a CMD check error for coxme this morning.?? I thought I had it fixed, but instead I had forgotton --as-cran on my last test run.? So the version just submitted to CRAN has warning messages in the log. I think it is an issue with CRAN.?? I've sent a message to R-devel asking for help.?? Since then, as a guess, I renamed my internal "ismat" function to

This is a small heads up for package maintainers.?? Under the more recent R-devel, R CMD check turned up some changes in the *.out files.?? The simple demonstration is to type? "round(51/80, 3)", which gives .638 under the old and .637 under the new.?? (One of my coxph test cases has a concordance of exactly 51/80). In this particular case 51/80 is exactly .63750000, but that value

?I ended up finding the issue by a focused code review. Once in the past, I had a version that would fail under one architecture but not another, in that case some help from Brian Ripley pointed me to the offending line of C code.?? That line read, but did not write, at an invalid memory location.?? Starting with the question of "what C routines have I added or modified most