<div dir="ltr">Oops!  Sorry, I forgot about a layer of abstraction here.  It turns out that we have this information on the ExtProtoInfo, but not the ordinary ExtInfo, and we only find it for normal calls by examining the called Decl.<div><br></div><div>Putting an attribute on the Function isn't going to help, unfortunately; you'll need some way to propagate this down to ConstructAttributeList.  I see two options here.</div><div><br></div><div>The first option is just to construct a FunctionDecl with the appropriate FunctionProtoType that includes a noexcept specification or a nothrow attribute or something.  This is probably the easiest thing to do, and if done properly it would solve any potential problems with fetching the global declaration as well.</div><div><br></div><div>The second option — and this is more involved — is that it would generally make sense to have a better abstraction for the abstract callee.  Right now, we're just passing around a Decl*, but that has some significant drawbacks.  First, it glosses over some very important differences, like the difference between a direct call and a virtual call to the same C++ member function.  Second, it means we lose the ability to remember anything interesting about callees that (as here) aren't tied to specific declarations.  An example of the latter issue that's closely related to this one is that you can make a function pointer type in C++ with an exception specification, and it's intended to be illegal (under C++'s weird informal type system around exception specifications; [except.spec]p6) for a call to a value of such a type to violate the specification, but we don't take advantage of that in IRGen because we tie these things purely to calls; whereas we totally could take advantage of it if you could define an abstract callee with just a FunctionProtoType.</div><div><br></div><div>I would prefer to solve this the second way, but I can sympathize if you see that as out-of-scope for your patch.</div><div><br></div><div>John.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 17, 2015 at 5:58 PM, Samuel F Antao <span dir="ltr"><<a href="mailto:sfantao@us.ibm.com" target="_blank">sfantao@us.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><p>Reid, John,<br><br>Thanks for the feedback!<br><br><tt>John McCall <<a href="mailto:rjmccall@gmail.com" target="_blank">rjmccall@gmail.com</a>> wrote on 11/17/2015 08:34:18 PM:<br><br>> From: John McCall <<a href="mailto:rjmccall@gmail.com" target="_blank">rjmccall@gmail.com</a>></tt><br><tt>> To: Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></tt><br><tt>> Cc: Samuel F Antao/Watson/IBM@IBMUS, cfe-dev <cfe-<br>> <a href="mailto:dev@lists.llvm.org" target="_blank">dev@lists.llvm.org</a>>, Alexey Bataev <<a href="mailto:a.bataev@hotmail.com" target="_blank">a.bataev@hotmail.com</a>>, Hal <br>> Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></tt><br><tt>> Date: 11/17/2015 08:34 PM</tt><br><tt>> Subject: Re: [cfe-dev] Fwd: Library calls for complex types and <br>> terminate scopes.</tt><span class=""><br><tt>> <br>> On Tue, Nov 17, 2015 at 4:54 PM, Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:</tt><br><tt>> Maybe you could mark the runtime function nounwind when you get its <br>> declaration here:</tt><br><tt>>   llvm::Constant *Func = CGF.CGM.CreateBuiltinFunction(FTy, <br>> LibCallName /*pass an AttributeSet here*/);</tt><br><tt>> <br>> Then you won't have to call setDoesNotThrow() later.</tt><br><tt>> <br>> The by-design way to do this is to add a noexcept specification to <br>> the ExtInfo being passed to arrangeFreeFunctionCall.</tt><br><br></span><tt>Just to make sure I get it right. You'd like me to add a new bit to ExtInfo and use it instead of the check of the nounwind attribute in EmitCall, right?</tt><br><br><tt>I'd probably keep the check of the attribute anyway as there may be other places that are already relying on the attribute, do you agree?</tt><br><br><tt>Thanks again,</tt><br><tt>Samuel</tt></p><div><div class="h5"><br><br><br><tt>> <br>> John.</tt><br><tt>> <br>> On Tue, Nov 17, 2015 at 4:43 PM, Samuel F Antao via cfe-dev <cfe-<br>> <a href="mailto:dev@lists.llvm.org" target="_blank">dev@lists.llvm.org</a>> wrote:</tt><br><tt>> Hi all,</tt><br><tt>> <br>> I came across an issue that happens to trigger an assertion in clang<br>> if an operation with type type is implemented in a scope that <br>> happens to install a terminate scope in the exceptions stack. I see <br>> the issue while using complex arithmetic in OpenMP regions, but I <br>> believe that could also be a problem for non-openMP codes. </tt><br><tt>> <br>> The problem happens in `ComplexExprEmitter::EmitComplexBinOpLibCall`<br>> and is caused by an assertion in:</tt><br><tt>> <br>> ```</tt><br><tt>>   RValue Res = CGF.EmitCall(FuncInfo, Func, ReturnValueSlot(), Args,</tt><br><tt>>                             nullptr, &Call);</tt><br><tt>>   cast<llvm::CallInst>(Call)->setCallingConv(CGF.CGM.getBuiltinCC());</tt><br><tt>>   cast<llvm::CallInst>(Call)->setDoesNotThrow();</tt><br><tt>> ```</tt><br><tt>> <br>> `EHStack.requiresLandingPad()` is used by `EmitCall` and is true if <br>> we have a scope installed in the exceptions stack. This causes <br>> `EmitCall` to produce an invoke instruction instead of a call instruction. </tt><br><tt>> <br>> One of the ways to tackle the issue is use the proper attributes for<br>> the library function (e.g. no unwind). Is this the right thing to <br>> do? Or can these library calls throw in some cases?</tt><br><tt>> <br>> Any thoughts?</tt><br><tt>> <br>> Here is a simple code that replicates the problem:</tt><br><tt>> ```</tt><br><tt>> int main (int argc, char *argv[]){</tt><br><tt>>   double _Complex dc = (double)argc + 3*I;</tt><br><tt>> <br>>   dc *= dc;</tt><br><tt>>   #pragma omp parallel</tt><br><tt>>   {</tt><br><tt>>     dc *= dc;</tt><br><tt>>   }</tt><br><tt>>   printf("%lf %lf\n",creal(dc),cimag(dc));</tt><br><tt>>   return 0;</tt><br><tt>> }</tt><br><tt>> ``` </tt><br><tt>> <br>> Thanks!</tt><br><tt>> Samuel</tt><br><tt>> <br>> _______________________________________________<br>> cfe-dev mailing list<br>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br></tt><br><tt>> <br>> <br></tt><br><tt>> <br>> -- </tt><br><tt>> I suppose you'd like my real thoughts as well.</tt><br>
</div></div><p></p></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">I suppose you'd like my real thoughts as well.</div>
</div>