How to find and disable specific NVCC warning? - cuda

Where are the NVCC codes for a specific warning listed?
Looking at other questions like this one gives the answer to use -Xcudafe "--diag_suppress=xxx to suppress warning "xxx", and links to a list of possible warnings here.
However, when I have the warnings
/usr/include/eigen3/Eigen/src/Core/util/XprHelper.h(94): warning: __host__ annotation is ignored on a function("no_assignment_operator") that is explicitly defaulted on its first declaration
and
/usr/include/eigen3/Eigen/src/Core/util/XprHelper.h(94): warning: __device__ annotation is ignored on a function("no_assignment_operator") that is explicitly defaulted on its first declaration
I do not find that type in the list. Can someone point me to the page where it is, so I can find the code/name of it? I did not find it in the documentation for NVCC.

Instead of looking for the string code for the warning, you can pass the
--display_error_number flag to NVCC, and get the number of that error. Then you can disable it with:
-Xcudafe --diag_suppress=1234
or whatever the error number was.

This specific warning can be suppressed with the following flag:
-Xcudafe --diag_suppress=esa_on_defaulted_function_ignored

Related

Dymola warning about derivatives of noEvent

In the Dymola translation log of one large model I see several times the warning:
Warning: Can only compute non-scalar gradients of functions specifying derivatives and not for:
noEvent
with no indication of where it comes from. Could someone explain what the warning means, and how to find and fix it?
Any message of that kind should only occur if you have set the flag Advanced.PrintFailureToDifferentiate = true; if you set this flag to false it should not occur.
The likely cause is that you have a non-scalar expression involving noEvent that for some reason needs to be solved using a system of equations; and it just means that Dymola does not yet generate analytic Jacobians for such systems.
The exact cause is difficult to say without the model; you could send that through the normal support-channels.

Warning on prepending variables with $

When I have a selector that I use several times, I like to prepend it with $ So if I'm using $('body') all over my script, I'll make a variable, $body. The warning arises, in this particular case, when I do $anElement.appendTo($body) I get the warning:
Argument type JQuery|jQuery|html element is not assignable to parameter type JQuery|element|string
I was told this is actually pretty common and acceptable practice, so is there a way I can turn this warning off? I couldn't seem to find any particular entry that disabled this in the inspections.
What I'm doing is this:
$('<div>,
{class:"aClass", text: "some text"}
).appendTo($body);
The warning is under Javascript > General > Signature Mismatch.

Using warning ('on', 'Octave:matlab-incompatible')

I recently found out that you can get Octave to warn when you are using features not compatible with Matlab. Due to working with others this feature is appealing.
warning ('on', 'Octave:matlab-incompatible')
However when I use it in even simple scripts
warning ('on', 'Octave:matlab-incompatible');
x = 5;
plot(x);
I get many warning due to the implementation of plot using non-Matlab compatible features. For example
warning: potential Matlab compatibility problem: ! used as operator near line 215 offile /usr/share/octave/3.8.1/m/plot/draw/plot.m
Is there a way to turn off these warnings? I don't care if plot is implemented using non-Matlab features because when I use Matlab its implementation will be fine.
No that is not possible which makes the Octave:matlab-incompatible almost useless. Also, that warning is only printed for syntax so you can still use Octave only functions (such as center or sumsq) without any problem.
I recommend you use a text editor that has separate Matlab and Octave syntax highlight (such as gedit) and avoid things that don't get highlighted.
Here's how it's done in Matlab, which looks to be similar to the Octave case:
warning('on', 'Octave:matlab-incompatible'); % Your Octave warning
x = 5;
WarnState = warning('off', 'Offending_MSGID'); % You'll need to get the specific ID
plot(x);
warning(WarnState); % Restore
Yes, it's a bit clumsy. There's no way to specify that a warning is not enabled within a particular file that I know of.
One thing that can happen is that the code an be interrupted by the user or an error before the warning state is restored. In this case, Your system now is in an unknown warning state. One way to avoid this is to use onCleanup. This function is called when a function exits, even if it exits due to an error. You might rewrite the above as:
warning('on', 'Octave:matlab-incompatible'); % Your Octave warning
x = 5;
WarnState = warning('off', 'Offending_MSGID'); % You'll need to get the specific ID
C = onCleanup(#()warning(WarnState));
plot(x);
...
Note that onCleanup won't be called until the function exits so the warning state won't be restored until then. You should be able to add a warning(WarnState); line to manually restore before if you want. Just be sure that whatever function onCleanup is calling can never return an error itself.

classes imported from conditional compilation not available

I've got some syntax in a project I'm working on that I'm not familiar with:
CONFIG::FLASH_10_1
{
import flash.net.NetStreamAppendBytesAction;
import flash.events.DRMErrorEvent;
import flash.events.DRMStatusEvent;
}
with the following compiler flags
-define CONFIG::LOGGING false -define CONFIG::FLASH_10_1 true -define CONFIG::PLATFORM true -define CONFIG::MOCK false
The class references aren't working when the imports are inside that block and I'm wondering if it's an fb4 vs fb4.5 issue. If I pull them out, all the references work as expected.
This 'peculiar syntax' is referred to as Conditional Compilation, where certain code is compiled only if the Compilation Constant provided is true.
This question shows a different syntax for defining the compilation constants, you may want to try changing that. I will test it and update this answer shortly.
After my testing, I believe that you're doing your compiler flags incorrectly--at least in FB4.5.
-define+=CONFIG::FLASH_10_1,true
or
-define CONFIG::FLASH_10_1,true
The Compilation Constant and its value should be separated by a comma, not a space. The += syntax was shown in some of the examples I saw, and appears to work, I'm not certain what the difference is between the two options.

Remove Runtime Checks compiler flag per-project in CMAKE

I have a CMAKE configuration where all my project configurations include the /RTC1 (Both Runtime Checks) compiler flag. However, I wish to switch to the Default option for only one project, as it also has the /clr compiler flag; which is incompatible with the Runtime Checks flag. I'm relatively new to CMAKE, so this may have an obvious solution, but I've so far been unable to find this.
Any help would be appreciated.
I didn't manage to find a solution whereby I could nicely remove the particular options, but I did find a way of stripping the option from the compiler flags variable using a REGEX REPLACE:
STRING (REGEX REPLACE "/RTC(su|[1su])" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
Where this may not be the most ideal approach, it has worked well in my situation where it is a special-cased scenario.
I'd recently faced with the same problem and found no elegant solution. However this code does the job:
foreach(flag_var
CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_RELEASE
CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_RELWITHDEBINFO)
STRING (REGEX REPLACE "/RTC[^ ]*" "" ${flag_var} "${${flag_var}}")
endforeach(flag_var)
set_property(TARGET necessary_targets_here APPEND_STRING PROPERTY COMPILE_FLAGS " /RTC1")
If you only need to clear /RTC flag for one configuration (ex. Debug) you may try the following approach:
STRING (REGEX REPLACE "/RTC[^ ]*" "" CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG}")
foreach(target_var necessary_targets_here)
target_compile_options(${target_var} PRIVATE $<$<CONFIG:Debug>: /RTC1>)
endforeach()
Please, note using generator expression $<$<CONFIG:Debug>: /RTC1 > which expands to /RTC1 only in Debug.
If you are adding your flags with add_definitions(), then you can remove them with remove_definitions, see documentation.
Also, you can play with COMPILE_DEFINITIONS target property.