Alistair Lynn
2010-May-26 21:20 UTC
[LLVMdev] [llvm-commits] [llvm] r104737 - /llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
Hello- Shouldn't this catch swapcontext as well? Alistair On 26 May 2010, at 22:14, Dale Johannesen wrote:> > On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: > >> vfork and getcontext have wildly platform-dependent semantics. >> Handling >> them conservatively is reasonable, even if some platforms don't need >> it. >> >> Dan > > Agreed. Also, the performance of code in the area of a vfork call is > not going to be critical. > >> On May 26, 2010, at 1:48 PM, Evan Cheng wrote: >> >>> Definitely not vfork. That's unnecessary. gcc is mistaken, we >>> shouldn't follow it. Also, getcontext is such a generic name. It's >>> a really bad idea to look for it. > _______________________________________________ > llvm-commits mailing list > llvm-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Bill Wendling
2010-May-26 22:02 UTC
[LLVMdev] [llvm-commits] [llvm] r104737 - /llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
I didn't see swapcontext in the list in gcc's special_function_p function... -bw On May 26, 2010, at 2:20 PM, Alistair Lynn wrote:> Hello- > > Shouldn't this catch swapcontext as well? > > Alistair > > On 26 May 2010, at 22:14, Dale Johannesen wrote: > >> >> On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: >> >>> vfork and getcontext have wildly platform-dependent semantics. >>> Handling >>> them conservatively is reasonable, even if some platforms don't need >>> it. >>> >>> Dan >> >> Agreed. Also, the performance of code in the area of a vfork call is >> not going to be critical. >> >>> On May 26, 2010, at 1:48 PM, Evan Cheng wrote: >>> >>>> Definitely not vfork. That's unnecessary. gcc is mistaken, we >>>> shouldn't follow it. Also, getcontext is such a generic name. It's >>>> a really bad idea to look for it. >> _______________________________________________ >> llvm-commits mailing list >> llvm-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Alistair Lynn
2010-May-26 23:02 UTC
[LLVMdev] [llvm-commits] [llvm] r104737 - /llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
Hi- Then that, surely, is a bug in gcc? swapcontext saves the context (via getcontext) in its first argument - there is nothing to prevent subsequently calling setcontext on that first argument more than once, which would result in multiple returns? Alistair On 26 May 2010, at 23:02, Bill Wendling wrote:> I didn't see swapcontext in the list in gcc's special_function_p function... > > -bw > > On May 26, 2010, at 2:20 PM, Alistair Lynn wrote: > >> Hello- >> >> Shouldn't this catch swapcontext as well? >> >> Alistair >> >> On 26 May 2010, at 22:14, Dale Johannesen wrote: >> >>> >>> On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: >>> >>>> vfork and getcontext have wildly platform-dependent semantics. >>>> Handling >>>> them conservatively is reasonable, even if some platforms don't need >>>> it. >>>> >>>> Dan >>> >>> Agreed. Also, the performance of code in the area of a vfork call is >>> not going to be critical. >>> >>>> On May 26, 2010, at 1:48 PM, Evan Cheng wrote: >>>> >>>>> Definitely not vfork. That's unnecessary. gcc is mistaken, we >>>>> shouldn't follow it. Also, getcontext is such a generic name. It's >>>>> a really bad idea to look for it. >>> _______________________________________________ >>> llvm-commits mailing list >>> llvm-commits at cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
Reasonably Related Threads
- [LLVMdev] [llvm-commits] [llvm] r104737 - /llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
- [LLVMdev] Proposal: stack/context switching within a thread
- [LLVMdev] Proposal: stack/context switching within a thread
- [LLVMdev] Proposal: stack/context switching within a thread
- [LLVMdev] Proposal: stack/context switching within a thread