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!
Related
According to cppreference [[deprecated("message string")]] we should be able to use the symbol but in VS results in error instead.
For example I wan't to issue a warning for ANSI methods in UNICODE builds and vice versa:
#ifdef UNICODE
[[deprecated("This method does not work well in UNICODE builds")]]
#endif // UNICODE
void f() {}
compiler doesn't let me compile, but standard says the attribute should allow usage but issue a warning message.
How to resolve this?, btw. my project is set to maximum conformance with the standard.
What ever the reason for VS going against the standard, is there a better way to issue a warning for above case?
Very much late to the party, but this cost me a couple of hours this morning.
By default, Visual Studio and the sdl (Security Development Lifecycle) compile flag treat
[[deprecated]] as an error. Whether or not you agree with this or not, that's how they do it.
To fix this go to Configuration Properties -> C/C++ -> Command Line and add /sdl /w34996
The /wX part represents the severity of the warning, and the rest is the error you want to report as a warning.
I hope this saves people some time.
I was able to get the compiler to treat [[deprecated]] as a warning by adding
/w34996
to the compiler options, as suggested in the responses in following link
https://developercommunity.visualstudio.com/content/problem/786502/cant-treat-deprecated-warning-as-warning-with-wx.html
is there a better way to issue a warning for above case?
There's no other way of warning about usage of a function than deprecation attribute in standard C++ at least that I know of.
Msvc has other alternatives such as #pragma deprecated(f), but those are not better.
How to resolve this?
Assuming you haven't configured your compiler to treat warnings as errors, you could proceed with writing a bug report to the maintainers.
I haven't tested it with Visual Studio, but in my case the following helped and probably is more generic:
On that error usually warnings are treated as errors with the compiler flag -Werror, that is automatically set in Visual Studio. That is the reason way a class or function marked with [[deprecated]] results in an error. To avoid explicitly that error and output it just as a warning, the compiler flag -Werror -Wno-error=deprecated-declarations can be set. In CMake it would look like:
add_compile_options(-Werror -Wno-error=deprecated-declarations)
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.
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'm on Ubuntu 13.04 32 platform. I'm trying to compile awn with latest vala. I get following error message.
vala-utils.cc: In function 'void awn::vala_array_destroy(gpointer, gint, GDestroyNotify)':
vala-utils.cc:358:6: error: no previous declaration for 'void awn::vala_array_destroy(gpointer, gint, GDestroyNotify)' [-Werror=missing-declarations]
cc1plus: some warnings being treated as errors
How can I fix that error?
At the top of vala-utils.cc insert the function prototype:
void vala_array_destroy(gpointer array, gint array_length, GDestroyNotify destroy_func);
This will silence the warning which is causing the build to fail due to -Werror defined in the Makefile. Consider raising a pull request for the benefit of the maintainers.
Alternatively modify ln.89 in configure.ac and remove the -Werror to stop the warning failing the build.
This actually a warning, and a rather pedantic one at that.
It's saying that the global function awn::vala_array_destroy has not been declared beforehand. Usually this is a sign of a programmer's mistake, but from the source it seems to me that:
this function is only supposed to be used by awn::vala_array_free directly below it (in which case it should really have been given internal linkage), or
a declaration is available in some header elsewhere (in which case it's probably in the wrong header, as it ought to be in vala-utils.h).
The long and short of it is that the code is probably fine, if a little strangely designed. This case is being treated as an error because you have -Werror turned on for this warning, turning it into an error.
I don't know how you're building the library, but you could adjust the compiler flags to avoid this; by default, GCC does not emit this warning, nor turn it into an error. Alternatively, you could add the function declaration into vala-utils.h yourself. You should also take up the issue with the library's maintainers.
Update: I found the culprit on line 89 of AWN's configure.ac. You should definitely take this up with the library maintainers. I'd be amazed if this had not already been reported as a bug; I believe it was introduced in this revision.
Sometimes VS autos/locals/watches break and instead of variables/values all I have is different kinds of:
CXX0029: Error: not struct pointer
CXX0033: Error: error in OMF type information
CXX0072: Error: type information missing or unknown
CXX0025: Error: operator needs class/struct/union
Rebuilding project, cleaning PDB/NCB etc doesn't solve it. What can I do?
Look at this Microsoft support note on: FIX: CXX0033 Error in OMF Type from Forward Class Declaration
Once you fix the PCH problem cited in the support note, I think all your errors will go away.
There is in fact a solution that lets you keep using precompiled headers: check out this more recent KB article and the documentation of the /Yl switch - which seems specifically tailored to this error.
Just add to the stdafx.cpp (or your own custom /Yc file) command line '/Ylxxxx', where xxxx stands for an arbitrary function name in your lib.
I recently faced symptoms identical to yours (in VS2010), and that solved it for me.
Are you trying to debug the "release" build? If so, many local variables will not exist as "debuggable" elements. You can get around this (if you must debug the release build) by debugging at the assembly level and look at the register values (vs. stack values, where auto/local would be in the debug build) and cast them appropriately in the "watch window".
Otherwise, build the Debug build and debug that build version. You'll get assertions where preconditions are not met, relevant/irrelevant stuff dumped to your output window, and more straight-forward debug single stepping.
It helped me to switch from using a program database (/ZI) to "c7 compatible" (/Z7). Switching off precompiled headers did not make a difference. Neither did rebuilding.