Failure in generated op.h in version 1.3.1

[Bumblebee1964]

Note: Providing complete information in the most concise form is the best way to get help. This issue template serves as the checklist for essential information to most of the technical issues and bug reports. For non-technical issues and feature requests, feel free to present the information in what you believe is the best form.

For Q & A and discussion, please start a discussion thread at https://discuss.mxnet.io

Description

When compiling MXNET with CPP package, an op.h header is generated with syntax errors. Compared to version 1.3.0, some operators have been added to have this syntax error (missing type specifier in argument list of inline function)

Environment info (Required)

WINDOWS 10 Pro, X64
MXNET 1.3.1.
VS2017
MKL
OPENCV 3.4.5
CMake 3.13.4
CUDA 9.2
CUDNN 9.2

Build info (Required if built from source)

Compiler: VS2017

MXNet commit hash:
(Paste the output of git rev-parse HEAD here.)

Build config:
1>------ Build started: Project: cpp_package_op_h, Configuration: Release x64 ------
1>"Running: OpWrapperGenerator.py"
1>D:/Projects/MXNet-versions/MxNet1-3-1/build/Release/libmxnet.dll
1>argument "lrs" of operator "multi_sgd_update" has unknown type ", required"
1>argument "wds" of operator "multi_sgd_update" has unknown type ", required"
1>argument "lrs" of operator "multi_sgd_mom_update" has unknown type ", required"
1>argument "wds" of operator "multi_sgd_mom_update" has unknown type ", required"
1>argument "lrs" of operator "multi_mp_sgd_update" has unknown type ", required"
1>argument "wds" of operator "multi_mp_sgd_update" has unknown type ", required"
1>argument "lrs" of operator "multi_mp_sgd_mom_update" has unknown type ", required"
1>argument "wds" of operator "multi_mp_sgd_mom_update" has unknown type ", required"
========== Build: 1 succeeded, 0 failed, 3 up-to-date, 0 skipped ==========

Problem in generated code (the parameters lrs and wds):
inline Symbol multi_sgd_update(const std::string& symbol_name, const std::vector<Symbol>& data, lrs, wds, mx_float rescale_grad = 1, mx_float clip_gradient = -1, int num_weights = 1) { return Operator("multi_sgd_update") .SetParam("lrs", lrs) .SetParam("wds", wds) .SetParam("rescale_grad", rescale_grad) .SetParam("clip_gradient", clip_gradient) .SetParam("num_weights", num_weights) (data) .CreateSymbol(symbol_name); }

The same for the inline functions:
multi_sgd_mom_update
multi_mp_sgd_update
multi_mp_sgd_mom_update
..and overloaded functions

Error Message:

Minimum reproducible example

Steps to reproduce

What have you tried to solve it?

1. op.h generation worked with same system / compiler settings for 1.3.0

[mxnet-label-bot]

Hey, this is the MXNet Label Bot.
Thank you for submitting the issue! I will try and suggest some labels so that the appropriate MXNet community members can help resolve it.
Here are my recommended labels: Bug

[Bumblebee1964]

Suggested labels: build, cpp
@mxnet-label-bot add [build, cpp]

[Bumblebee1964]

dug a bit deeper in the problem. It seems that the new inline functions have an argument type that is not listed as known argument types in OpWrapper.py. I guess the argument type is nnvm::Tuple but not sure.

[smissan]

this is a critical issue that breaks CPP interface. Please fix

[bj5546]

release 1.40 has the same erro

[Bumblebee1964]

Please fix, it is annoying to work around this issue especially when trying to understand cpp samples as these won't build out of the box.

[dbsxdbsx]

@Bumblebee1964 , and is especially annoying when it pops up after 1 hours compiling! I got it when compiling mxnet1.5.

[ausk]

Rebuild more than 5 times, building failed when run OpWrapperGenerator.py, finally locate to this issue ...

[bj5546]

was this bug fixed？

[smissan]

No

…

On Mon., Mar. 25, 2019, 8:56 a.m. bj5546, ***@***.***> wrote: was this bug fixed？ — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#14116 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3wWnekCkMTGJz60hLQvUzkD_Yq1xBYks5vaLmEgaJpZM4az7n5> .

[Bumblebee1964]

It seems fixed in the latest version. I downloaded the code 2 weeks ago, and it seemed to be resolved.

[smissan]

The script did not change in 2 months and is still not working

…

On Tue., Mar. 26, 2019, 5:21 a.m. Fred Hugen, ***@***.***> wrote: It seems fixed in the latest version. I downloaded the code 2 weeks ago, and it seemed to be resolved. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#14116 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3wWgwsOJs7CWwiaFzRHSn_l_hfm0K_ks5vadh1gaJpZM4az7n5> .

[Bumblebee1964]

It looks whether the name of the operator (and probably definition) that caused the problem has been changed. From my current working place I cannot easily check difference between generated op.h from version 1.3.1. (which I had to change manually to get it compiled) and version 1.4.1.

I'' try to check by the end of the week when I am back in the office.

[rocknamx8]

I also have this problem in version 1.4.0, need a fix.

[bj5546]

please fix it

[407257625]

alse have this problem in version 1.5.x, please fix!:

1>argument "lrs" of operator "multi_sgd_update" has unknown type ", required"
1>argument "wds" of operator "multi_sgd_update" has unknown type ", required"
1>argument "lrs" of operator "multi_sgd_mom_update" has unknown type ", required"
1>argument "wds" of operator "multi_sgd_mom_update" has unknown type ", required"
1>argument "lrs" of operator "multi_mp_sgd_update" has unknown type ", required"
1>argument "wds" of operator "multi_mp_sgd_update" has unknown type ", required"
1>argument "lrs" of operator "multi_mp_sgd_mom_update" has unknown type ", required"
1>argument "wds" of operator "multi_mp_sgd_mom_update" has unknown type ", required"

[MikeDai2020]

this problem generates when build the cpp examples using visual studio, e.g Alexnet. I solved this by change the op.h in the install path, generated by execute Running: OpWrapperGenerator.py" ,somewhere like: nnvm::Tuple<mx_float> lrs, nnvm::Tuple<mx_float> wds,.then create another project,copy the examples source file, and include the head files and library again. good luck!

[407257625]

@Mark-Dai can share the generated sh , such as " python OpWrapperGenerator.py xxx"

[Vigilans]

Problem found. Here is my procedures to trace the bug:

• Debug OpWrapperGenerator.py#L364, and view (name, description, argNames, argTypes, argDescs) of multi_sgd_update.
• From argNames and argTypes, we could see that lrs and wds's type is ", required".
• From name, description and argDescs, we could locate the definition of op:
• Definition of MultiSGDParam: src/operator/optimizer_op-inl.h#L85:
• Generic Param Declaration Method: 3rdparty...\dmlc\parameter.h#L231
• lrs and wds's type mxnet::Tuple<float> falls back to FieldsEntryBase<DT=mxnet::Tuple>
• In GetFieldInfo, here is where the evil ", required" comes from.
• We could see that FieldsEntryBase uses os << type_ to fill the content before ", required".
• Then we could see that type_ is inited by dmlc::type_name<DT>().
• Finally we could see that the type name is specified by custom specialization of type_name_helper<T>.

Then, what happened to our mxnet::Tuple<float>?
Here: https://github.com/apache/incubator-mxnet/blob/master/include/mxnet/tuple.h#L744

namespace dmlc {
/*! \brief description for optional TShape */
DMLC_DECLARE_TYPE_NAME(optional<mxnet::TShape>, "Shape or None");
DMLC_DECLARE_TYPE_NAME(optional<mxnet::Tuple<int>>, "Shape or None");
// avoid low version of MSVC
#if !defined(_MSC_VER) // <----------- Here !
template<typename T>
struct type_name_helper<mxnet::Tuple<T> > {
  static inline std::string value() {
    return "tuple of <" + type_name<T>() + ">";
  }
};
#endif
}  // namespace dmlc

So the specialization of mxnet::tuple<T> was disabled for Visual Studio in the first place!

I removed the #if block, recompile, then everything works fine.
@junrushao1994

[smissan]

great, Vigilans , thanks for finally finding the root cause. Is this issue is now fixed in trunk, or is it in code review?

[leleamol]

@mxnet-label-bot add [Windows]

[JiaoPaner]

Facing the same error when compiling 1.5.0.
Now have it fixed?