I was able to temporarily get some legacy Fortran code running (I was able to step through it with the debugger) in Visual Studio 2017 with the Intel Fortran compiler, until it stopped working apparently for no reason.
At the very start I was getting the error below when trying to get the code to run.
error #6633: The type of the actual argument differs from the type of the dummy argument.
That error went away after a post-installation reboot and I was able to test the code for a few weeks, but now it's back.
I don't think I've changed any of the code.
You're using Intel Fortran and it has a feature called "Generated Interface Checking". The way this works is when you compile a source that declares a subroutine or function that isn't in a module, it generates an INTERFACE block and saves a compiled module for it. Then when you compile a source that calls a routine for which you have not provided an explicit interface, it looks to see if there's a generated one and compares it. If you have an argument type mismatch you'll get an error such as this.
However, to work properly the called routine must be compiled before the caller. If this doesn't happen, the interface can't be checked and you'll not get an error. The error is still there, and you may be able to see it if you do a rebuild of the project. Pay attention to the message and fix the problem it describes. A mismatched argument type is a common cause of run-time errors that come and go.
Related
When I compile a project using cross compiler,I come across the following error:
internal compiler error: in decode_addr_const, at varasm.c:2632
Where can I find the varasm.c file?I searched the project directory and cross compiler directory,but I didn't find it.
Thanks for helpping,Light
The compiler maker has that file, and probably won't give it to you.
But as it seems to be an error in the compiler, you can either contact them / file a bug report, or try to avoid the error by changing your code a bit (which is a guessing game, as you don't know how you made it run into the error). Or use another compiler, if there are choices.
I have a __forceinline function that cannot be inlined when compiled as CLI (probably due to the specific restrictions to inlining that apply with .NET).
In debug, it is a warning and does not prevent me from building. But in release, it comes up as an error:
error C4714: function '...' marked as __forceinline not inlined
In the project configuration, Treat Warnings As Errors is set to No (/WX-), Treat Specific Warnings As Errors is empty (no value and no inherited value) and there is no /We option in the Command Line of the C/C++ section.
Thus, I don't understand why this warning comes up as an error.
And as it is an error it prevents me from building the project in release.
Do you have any clue on why this comes up as an error?
Any idea of how I could get rid of it, considering I cannot change the function nor its use (it comes from a library I'm using and I'd like not to alter)?
Thank you very much!
I am converting a MATLAB written function into C by "Matlab coder". After I get the converted files , the converted function always have first input argument as const emlrtStack *sp. Now when I am trying to test it on VC++ 2013, IntelliSense is giving mentioned above error.
I manually tried to locate this identifier in emlrt.h file but no such thing is present there. I tried to convert a simple multiply function with two input arguments[like, c=mul(a,b)] but still the converted function has this extra argument inside the function in addition to a and b.
(which means this argument is not function specific).
If someone has a solution to this or have experienced a problem like this, please share or help.
Moreover If someone know how to simply test these converted functions, it would be a much appreciated additional help .
It is likely that the code that was generated for a MEX function rather than a standalone target. MEX functions are binaries written C, C++ or Fortran that can be called like a normal MATLAB function. Generating code to produce a MEX function allows two things. First, you can test your generated code in MATLAB because you can call the MEX function from MATLAB like any other function. Look for a file named mul_mex.mex* after you do code generation and try to call it: mul_mex(1,2). The other use for generating a MEX function is that it can often be faster than the MATLAB code from which it was generated. MEX functions are only used in the context of MATLAB.
The parameter emlrtStack* that you saw appears in MEX generated code to aid in runtime error reporting. It is not present in standalone code that is designed to be run outside of MATLAB.
If you want to use the generated code in Visual Studio, or outside of MATLAB you should choose one of the standalone targets, LIB, DLL, or EXE. This page shows how to change the output type. To summarize, if using the command line you could say:
cfg = coder.config('lib'); %or 'dll' or 'exe'
codegen mul -config cfg -args {1,2}
If using the project interface, you click on the Build tab and choose static library or shared library in the "Output type" dropdown menu.
I would recommend reading this example that demonstrates how to use a generated DLL in Visual Studio.
I am compiling a project under VS2012 and GCC (CodeBlocks) for Windows.
On VS2012 everything works perfect. Under GCC I am obtaining the following compiling error:
C:\Users\Piotrek\AppData\Local\Temp\ccfdl0Ye.s|164|Error: invalid use of register|
C:\Users\Piotrek\AppData\Local\Temp\ccfdl0Ye.s|166|Error: invalid use of register|
C:\Users\Piotrek\AppData\Local\Temp\ccfdl0Ye.s|221|Error: invalid use of register|
||=== Build finished: 3 errors, 14 warnings (0 minutes, 0 seconds) ===|
I am using the compiler option -fpermissive - It should have nothing to do with the error.
I just can't understand why is it pointing to a temporary file under the Local Temp folder, and saying that I am using a wrong register??
Does anybody have any idea on what's happening?
It looks like you've encountered a bug in the compiler. The
error messages (judging from the "source" file name) are from
the assembler. The only time the assembler should generate an
error message is when there is something illegal in the
assembler, and the C++ compiler should never generate illegal
assembler; if it can't generate legal assembler, it should
output an error message and fail.
The real problem, when you get this sort of message, is to
figure out what in your code is triggering it. g++ has an
option which tells it to not delete any of the intermediate
files. Use this, then try and see what is going on in the
assember files at these lines. (When you ask g++ to output
assembler, it puts nice comments in to help finding the
corresponding source. I don't know if it also does this when
generating assembler as an intermediate file.) And then try
cutting code (if worse comes to worse, using binary search)
until you can get the error for a program of one or two lines.
Try to guess what's special about them, and change them to do
the same thing, in a different way.
And don't fail to report the error to g++.
Thanks to James Kanze's recommendation, I decided to tell to the compiler not to delete temporary files. This is done by the flag:
-save-temps
As James said, the assembler generates some nice comments which inform exactly which line on our C++ code is throwing the error. In my case, it looks like it is not accepting such instruction:
asm
(
".intel_syntax noprefix\n"
"lock dec [DWORD PTR eax]\n"
".att_syntax \n"
:
: "a" (data)
:
);
I don't know why he is not accepting Intel Syntax anymore, since it was working with previous GCC version, and now that I updated it it doesn't anymore.
Anyway, the solution for such problems is the one mentioned by James: Just dont delete intermediate files so that you can spy directly into Assembly code what's wrong.
About the problem of the INTEL syntax, any idea why it doesn't work anymore?
I upgraded today from Ubuntu 12.04 which I think had g++-4.6 to Ubuntu 12.10 with g++-4.7.2. In my code I had a few functions marked as __attribute__((always_inline)). The reason for this was simply that profiling showed me that it increased the performance of the code significantly. It worked fine with g++ 4.6 but now with g++ 4.7 I get the error message:
error: inlining failed in call to always_inline 'void func_name(args)': function body can be overwritten at link time
I can't share my actual code, I've tried to narrow it down but when I change too much the error goes away, so that's not helpful. I'm interested in the root cause of this error message.
It wasn't my intention to answer this myself, but I accidentally found the answer a few minutes after I had posted.
The reason for this (cryptic) error message was that the function was not marked as inline, only __attribute((always_inline)).
For us, the issue was that we failed to also declare the function "static". "attribute((always_inline))" means, in plain text, "inline this and never include a function body" and the error message means "the compiler had to include a function body". In our case, since the function wasn't "static", it needed to be available for an external reference.