asmushetzel commented on issue #8338: master branch cannot build on centos 7 with cuda-8.0 URL: https://github.com/apache/incubator-mxnet/issues/8338#issuecomment-343625693 I suppose this is still about this one: home/hanfeng/zyh/mxnet/mshadow/mshadow/././././cuda/tensor_gpu-inl.cuh(75): error: expression preceding parentheses of apparent call must have (pointer-to-) function type I don't have yet a clear explanation, but some suspicion. The thing that looks most likely to be the problem in this line is the term exp.Eval(y, x) Why? Simply because "exp" is the name of a parameter of the encompassing MapPlanProc() function and it is also the name of an arithmetic function (and you modified exactly this arith function by making it a template). So there are some hints, that this may cause a problem. What could go wrong here? Some ideas: The compiler has to figure out at some point what it will do with exp.Eval(). According to this "https://msdn.microsoft.com/en-us/library/19cbwccf.aspx"; there may be the possibility, that "exp" is decided to be a pointer to an external function (i.e. a non-dependent variable) as the function parameter with the same name is a dependent variable (its type is dependent on template parameters). To quote this website: "Nondependent names are looked up according to the usual rules and at the point of definition of the template. These names, being independent of the template arguments, are looked up once for all template specializations". So it could be that the compiler decided one time upfront that "exp.Eval" must be some kind of function pointer and no local variable and then later figures out that this is actually not the case (when it eventually expands the templates). This may be triggered by the fact that the compiler identifies the arithmetic function exp - when analyzing the template MapPlanProc first - as a non-dependent name and so assumes that in "exp.Eval(X,Y)" the "exp" refers to the arithmetic function. At this point, it doesn't perform any analysis of template specializations. So it doesn't figure out that the arithmetic function "exp" has no method "Eval" at all (some compilers may be clever enough, but others may not and nvcc is somewhat "special" anyway). Then later, when it processes the first specialization (instantiation) of template "MapPlanProc", it also will try to instantiate "exp.Eval()". And then figures out that "exp.Eval" is no function or function pointer (in fact that exp.Eval is nowhere defined at all when exp is assumed to be the arithmetic exp) and then bails out (with a not very helpful error message). Your change made "exp" a template. Before it was a non-template function and the compiler could always figure out at the time of analyzing the template definition of MapPlanProc that the "exp" in exp.Eval() can't match that arithmetic function "exp". Now as "exp" is a template, it may not be able to figure that out as there could be some specialization of the "exp" template that actually has an "Eval" member (but specializations are handled after the decision that "exp" is bound to the arithmetic function as this binding results in a preferred matching to a non-dependent name) We certainly can make a philosophical discourse out of that. But I would recommend just to try it out and exchange the parameter "const Plan exp" in MapPlanProc to something like "const Plan plan" and then do plan.Eval() inside and see whether it works. You may ask @zhreshold to try it out as PR8582 is currently failing on exactly this.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
