search for: somety

...oo). 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 "result_type" instead? In the instructions printed by clang++, somety is { i8*, i32 }. 3. What are the allowed values and types passed to catch clause? I see that practically type is i8* and value is bitcast (i8** @<typeinfo> to i8*). Is this targ...

...--------- >> // The 'landingpad' Instruction >> // >> >> The 'landingpad' instruction replaces the current 'llvm.eh.exception' and >> 'llvm.eh.selector' intrinsics. >> >> // Syntax: >> >> %res = landingpad<somety> personality<ty> <pers_fn> <clause>+ >> >> where >> >> <clause> := >> cleanup >> | catch<ty_1>,<ty_2>, ...,<ty_n> >> | filter<ty_1>,<ty_2>, ...,<ty_m> >> >>...

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 >>> >>> <clause> := >>> cleanup >>> | catch<ty_1>,<ty_2>, ...,<ty_n> >>> | filter<ty_1>,<ty_2>, ...,<ty_...

...;t match a clause then the exception continues to be unwound. Note that you can match a catch clause without being equal to the type in the catch clause (for example because the catch clause type represents some class B, and thus will also match a class A if B derives from A). > 2. What is 'somety'? Shouldn't it maybe say "result_type" instead? In > the instructions printed by clang++, somety is { i8*, i32 }. The type is not specified to allow for exotic exception handling schemes in which returning something funky is useful. The code generators only support Dwarf exce...

...y types (specified by the personality function and ABI). //===-------------------------- // The 'landingpad' Instruction // The 'landingpad' instruction replaces the current 'llvm.eh.exception' and 'llvm.eh.selector' intrinsics. // Syntax: %res = landingpad <somety> personality <ty> <pers_fn> <clause>+ where <clause> := cleanup | catch <ty_1>, <ty_2>, ..., <ty_n> | filter <ty_1>, <ty_2>, ..., <ty_m> and the result has the type '<somety>'. The personality functio...

...ee below. > //===-------------------------- > // The 'landingpad' Instruction > // > > The 'landingpad' instruction replaces the current 'llvm.eh.exception' and > 'llvm.eh.selector' intrinsics. > > // Syntax: > > %res = landingpad<somety> personality<ty> <pers_fn> <clause>+ > > where > > <clause> := > cleanup > | catch<ty_1>,<ty_2>, ...,<ty_n> > | filter<ty_1>,<ty_2>, ...,<ty_m> > > and the result has the type '&...

...rote: [...] > //===-------------------------- > // The 'landingpad' Instruction > // > > The 'landingpad' instruction replaces the current 'llvm.eh.exception' and > 'llvm.eh.selector' intrinsics. > > // Syntax: > >  %res = landingpad <somety> personality <ty> <pers_fn> <clause>+ > > where > >  <clause> := >       cleanup >    |  catch <ty_1>, <ty_2>, ..., <ty_n> >    |  filter <ty_1>, <ty_2>, ..., <ty_m> | terminate ? You have an example referencing i...

...gt; cleanup >>>> | catch<ty_1> >>>> | filter<ty_1> > > .. forcing "catch" or "filter" before each entry. If you don't like that, why not make the grammar be something like: > >>>> %res = landingpad<somety> personality<ty> <pers_fn> (catch<ty>+)? (filter<ty>+)? > > Is there anything specific about the ordering of catch or filter clauses that affect semantics? If so, the first alternative seems cleaner. If not, the second does. yes there is something about the...

...gt;>>> | catch<ty_1> >>>>> | filter<ty_1> >> >> .. forcing "catch" or "filter" before each entry. If you don't like that, why not make the grammar be something like: >> >>>>> %res = landingpad<somety> personality<ty> <pers_fn> (catch<ty>+)? (filter<ty>+)? >> >> Is there anything specific about the ordering of catch or filter clauses that affect semantics? If so, the first alternative seems cleaner. If not, the second does. > > yes there is s...

...d, we are either changing the code to cast to FixedVectorType, or we are updating the code to handle scalable vectors correctly. If the call site does not have test coverage with scalable vectors, this test coverage is being added. Even for obviously correct transformations such as `VectorType::get(SomeTy, SomeVecTy->getNumElements())` -> `VectorType::get(SomeTy, SomeVecTy->getElementCount())`, I have been required in code review to provide test coverage. We are taking this seriously. > “Vector” has a traditional and dominant meaning as a fixed-width SIMD type, and the fact that you’ve...

...). > > //===-------------------------- > // The 'landingpad' Instruction > // > > The 'landingpad' instruction replaces the current 'llvm.eh.exception' and > 'llvm.eh.selector' intrinsics. > > // Syntax: > > %res = landingpad <somety> personality <ty> <pers_fn> <clause>+ > > where > > <clause> := > cleanup > | catch <ty_1>, <ty_2>, ..., <ty_n> > | filter <ty_1>, <ty_2>, ..., <ty_m> > > and the result has the type '&lt...

> 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

...a type, and a vector. This overload calls getElementCount() on the given vector and uses that to construct a new VectorType. This is a convenience helper for the cases where "I want a vector with the same shape as this other vector, but a different element type." Calls to VectorType::get(SomeTy, SomeVTy->getNumElements()) that try to implement this case are a very common source of bugs when SomeVTy is scalable, use of this helper will eliminate these bugs while also being more concise. Currently, VectorType still has its getNumElements() function, and this function is...

...d, we are either changing the code to cast to FixedVectorType, or we are updating the code to handle scalable vectors correctly. If the call site does not have test coverage with scalable vectors, this test coverage is being added. Even for obviously correct transformations such as `VectorType::get(SomeTy, SomeVecTy->getNumElements())` -> `VectorType::get(SomeTy, SomeVecTy->getElementCount())`, I have been required in code review to provide test coverage. We are taking this seriously. “Vector” has a traditional and dominant meaning as a fixed-width SIMD type, and the fact that you’ve intro...

...that takes a type, and a vector. This overload calls getElementCount() on the given vector and uses that to construct a new VectorType. This is a convenience helper for the cases where “I want a vector with the same shape as this other vector, but a different element type.” Calls to VectorType::get(SomeTy, SomeVTy->getNumElements()) that try to implement this case are a very common source of bugs when SomeVTy is scalable, use of this helper will eliminate these bugs while also being more concise. > > > > Currently, VectorType still has its getNumElements() function, an...

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.