search for: someti

I am new to the landingpad (which is relatively new too). Documentation http://llvm.org/docs/LangRef.html#i_landingpad leaves some questions open: 1. What happens when actual exception type isn't listed in catch or filter clauses? Does it still return the corresponding structure like if it was listed? Or behavior is undefined? 2. What is 'somety'? Shouldn't it maybe say

On Jul 31, 2011, at 11:06 AM, Duncan Sands wrote: >> //===-------------------------- >> // The 'landingpad' Instruction >> // >> >> The 'landingpad' instruction replaces the current 'llvm.eh.exception' and >> 'llvm.eh.selector' intrinsics. >> >> // Syntax: >> >> %res = landingpad<somety>

On Aug 1, 2011, at 11:13 PM, Bill Wendling wrote: >>> The 'landingpad' instruction replaces the current 'llvm.eh.exception' and >>> 'llvm.eh.selector' intrinsics. >>> >>> // Syntax: >>> >>> %res = landingpad<somety> personality<ty> <pers_fn> <clause>+ >>> >>> where

Hi Yuri, > I am new to the landingpad (which is relatively new too). > Documentation http://llvm.org/docs/LangRef.html#i_landingpad leaves some > questions open: > > 1. What happens when actual exception type isn't listed in catch or > filter clauses? Does it still return the corresponding structure like if > it was listed? Or behavior is undefined? if it doesn't

What? Yet another EH proposal?! This one is different from the others in that I'm planning to start implementing this shortly. But I want your feedback! I've all ready gotten a lot of feedback from Chris, John, Jim, Eric, and many others. Now is your turn! Please read this proposal and send me your comments, suggestions, and concerns. -bw

Hi Bill, > Please read this proposal and send me your comments, suggestions, and concerns. this proposal looks great to me. Thanks for working on it. I have a few minor comments, see below. > //===-------------------------- > // The 'landingpad' Instruction > // > > The 'landingpad' instruction replaces the current 'llvm.eh.exception' and >

On Fri, Jul 22, 2011 at 10:29 PM, Bill Wendling <wendling at apple.com> wrote: [...] > //===-------------------------- > // The 'landingpad' Instruction > // > > The 'landingpad' instruction replaces the current 'llvm.eh.exception' and > 'llvm.eh.selector' intrinsics. > > // Syntax: > >  %res = landingpad <somety>

Hi Chris, >>> Is it intended that "cleanup ty_1, ty_2" potentially be different to >>> "cleanup ty_1 cleanup ty_2"? Perhaps this is useful for funky personality >>> functions. >>> >> Yeah. One can basically interleave the catches and filters. But having two catch or two filter clauses in a row should be semantically the same as the

On Aug 2, 2011, at 10:28 AM, Duncan Sands wrote: >>>> Is it intended that "cleanup ty_1, ty_2" potentially be different to >>>> "cleanup ty_1 cleanup ty_2"? Perhaps this is useful for funky personality >>>> functions. >>>> >>> Yeah. One can basically interleave the catches and filters. But having two catch or two filter

John, > This is not categorically true, no. When we make changes that require large-scale updates for downstream codebases, we do so because there’s a real expected benefit to it. For the most part, we do make some effort to keep existing source interfaces stable. While I’m at a loss to find a documented policy, I recall this thread

Hi Bill, Thanks for working on this. Is there a reference for the function attribute uwtable, or is it to be defined as part of this effort? Thanks in advance Garrison On Jul 23, 2011, at 1:29, Bill Wendling wrote: > What? Yet another EH proposal?! This one is different from the others in that > I'm planning to start implementing this shortly. But I want your feedback! I've

> This isn't an llvm-specific feature, but how exceptions work in general. Ugh, Q2 and Q3 are also not llvm-specific feature? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj

An embedded message was scrubbed... From: unknown sender Subject: no subject Date: no date Size: 3743 Url: http://lists.samba.org/archive/samba/attachments/20010326/e77b6d5e/attachment.eml -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url :

Dear all, I am using R 3.4.3 on Windows 10. I am preparing some teaching materials and I'm having trouble matching the by-hand version with the R code. I have fitted a Cox model - let's use the ovarian data as an example: library(survival) data(ovarian) ova_mod <- coxph(Surv(futime,fustat)~age+rx,data=ovarian) If I want to make predict survival for a new set of individuals at 100

Hi, I just wanted to give an update on the progress of this work. This morning I merged a patch to add the new vector types. I have added a FixedVectorType, as proposed below. I also added a ScalableVectorType. I found during my work that it is useful to be able to query isa<ScalableVectorType>(Ty). Additionally, I was concerned that it would become commonplace to take

John, For the last several months, those of us working on the scalable vectors feature have been examining the codebase, identifying places where llvm::VectorType is used incorrectly, and fixing them. The fact is that there are many places where VectorType is correctly taken to be the generic “any vector” type. getNumElements may be being called, but it’s being called in accordance with the

Nicolai, My plan is to remove getNumElements() as soon as possible. Hopefully within the next few weeks. I just made a patch on my machine that marks it deprecated, and it generates a ton of warnings. Given that some build bots build with -Werror, I don't think we can mark it deprecated unless all the usages are first removed. It occurs to me now that it might be good to mark it

Hi John, I’d like to address some points in your message. > Practically speaking, this is going to break every out-of-tree frontend, backend, or optimization pass that supports SIMD types. My understanding is that the policy in LLVM development is that we do not let considerations for downstream and out-of-tree codebases affect the pace of development. The C++ API is explicitly unstable.