I would like the Arduino IDE to display compiler warnings, and I would rather not have to compile once in the terminal for warnings, and again through Arduino to generate the hex file.
Holding down the shift key while clicking the "Verify" button shows intermediate commands, but none of their output. Is this possible without hacking the Arduino IDE?
Using Arduino IDE 1.6.4 and newer, the warning level can be easily adjusted via menu File → Preferences → Compiler warnings:.
Using Arduino AVR Boards, the compiler flags set via this option are:
"None": -w
"Default":
"More: -Wall
"All": -Wall -Wextra
The default compiler command line options include -w, which suppresses warnings, but you can change that by editing C:\Program Files (x86)\Arduino\hardware\arduino\avr\platform.txt. Since the libraries might contain warnings, but I want -Werror for myself, I removed the -w options, and then added to my source code:
#pragma GCC diagnostic error "-Wall"
#pragma GCC diagnostic error "-Werror"
This feature has been added to the latest Arduino source code, although is not yet in a released version (see Showing compilation warnings when verbose output is enabled).
It's planned to be included in the next major Arduino IDE release (version 1.0) which is currently planned for release at the end of October 2011. The current release candidate has this fix (as of October 25, 2011).
To enable compiler warnings from within the Arduino IDE, open menu File → Preferences, and then tick Show verbose output during: compilation and/or Show verbose output during: upload.
Most answers here seem to be outdated. From Arduino.app 1.5 onwards you must find the file preferences.txt (https://www.arduino.cc/en/Hacking/Preferences) and change the line compiler.warning_level=none to compiler.warning_level=all IMPORTANT: Quit Arduino first, edit, then start the IDE again.
The feature as described by Matthew, not only displays the warnings, but a lot of distracting information on how the compiler was called as well.
See the addendum to my question Have the Arduino IDE set compiler warnings to error. It implements the changes to the Arduino script:
-export PATH="${APPDIR}/java/bin:${PATH}"
+export ORGPATH="${APPDIR}/java/bin:${PATH}"
+export PATH="${APPDIR}/extra:${ORGPATH}"
And make the extra/avr-g++:
#! /usr/bin/env python
import os
import sys
import subprocess
checklibpat = [
'SoftwareSerial',
'GSM_GPRS',
]
werr = '-Werror'
wall = '-Wall'
cmd = ['avr-g++'] + sys.argv[1:]
os.environ['PATH'] = os.environ['ORGPATH']
fname = sys.argv[-2][:]
extend = False
warn = False
if cmd[-2].startswith('/tmp'):
extend = True
warn = True
if not extend:
for l in checklibpat:
if l in cmd[-2]:
warn = True
break
if warn:
#print len(fname), list(fname)
for i, c in enumerate(cmd):
if c == '-w':
cmd[i] = wall
break
if extend:
cmd.insert(1, werr)
## to enable deprecated stuff (Print.cpp) with gcc 4.7.0
#cmd.insert(1, '-D__PROG_TYPES_COMPAT__=1')
subprocess.call(cmd)
Comment out extend = True if you do not want the compiler to interpret warnings in your source as errors.
Related
I'm kinda new to the world of Intel's HPC toolchain and I'm facing some troubles making even simple DPC++ application to work when gtest is used as a testing framework
This is the CMakeLists "structure" I'm following
cmake_minimum_required(VERSION 3.14)
project(foo)
set(CMAKE_CXX_COMPILER "dpcpp")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++17 -O3 -fsycl")
# add executables
# target linked libraries
# ...
option(ENABLE_TESTS ON)
if(ENABLE_TESTS)
FetchContent_Declare(
googletest
GIT_REPOSITORY https://github.com/google/googletest.git
GIT_TAG release-1.11.0
)
set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
FetchContent_MakeAvailable(googletest)
add_subdirectory(tests)
endif()
If I remove the last block, it compiles and runs as expected, otherwise I get the following error:
CMake Error at build/_deps/googletest-src/CMakeLists.txt:10 (project):
The CMAKE_CXX_COMPILER:
dpcpp
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
-- Configuring incomplete, errors occurred!
See also "/home/u141905/foo/build/CMakeFiles/CMakeOutput.log".
See also "/home/u141905/foo/build/CMakeFiles/CMakeError.log".
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_CXX_COMPILER= /usr/bin/c++
-- Generating done
CMake Generate step failed. Build files cannot be regenerated correctly.
make: *** [Makefile:2: all] Error 1
Please notice that dpcpp is correctly set, in fact I'm using Intel's devcloud platform.
Setting CXXto the output of whereis dpcpp produces the same error.
The only "workaround" (I doubt it is one though) I found is using clang++ instead (the version from Intel's llvm). Any help or suggestion is much appreciated, thanks in advance!
EDIT: after some more attempts, I noticed that if I set CMAKE_CXX_COMPILER just after fetching gtest, everything works fine. Anyway I don't understand why this happens and how can be properly fixed.
Use the path for dpcpp binary for setting the CMAKE_CXX_COMPILER instead of using"set(CMAKE_CXX_COMPILER "dpcpp")". After adding the path("/opt/intel/oneapi/compiler/2022.0.1/linux/bin/dpcpp") to the CMAKE_CXX_COMPILER, you can run the program successfully.
Please find the below CMakeLists.txt for setting the CMAKE_CXX_COMPILER:
project(foo)
set(CMAKE_CXX_COMPILER "/opt/intel/oneapi/compiler/2022.0.1/linux/bin/dpcpp")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++17 -O3 -fsycl")
# add executables
# target linked libraries
# ...
set(ENABLE_TESTS ON)
include(FetchContent)
if(ENABLE_TESTS)
FetchContent_Declare(
googletest
GIT_REPOSITORY https://github.com/google/googletest.git
GIT_TAG release-1.11.0
)
set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
FetchContent_MakeAvailable(googletest)
add_subdirectory(tests)
endif()
Thanks & Regards,
Hemanth
Did you run the source /opt/intel/oneapi/setvars.sh intel64 script? I.e. is dpcpp on your path before running cmake?
Several of the Sanitizers (from either GCC or Clang) cannot be combined – i.e. used simultaneously in the same build, but Asan and Ubsan are combinable – i.e. I can build with “-fsanitize=address,undefined -fsanitize-recover=all …” and have an exe that performs the checks from both sanitizers. All good so far.
The LOGGING from the resulting executable seems problematic though.
In all cases, if ‘log_path’ is not set in the options, the defects all get reported on stderr. OK so far. Try to use log_path though, and things get strange:
For an exe built just with Asan, and setting ASAN_OPTIONS to include “log_path=./ASAN”, the Address Saniitizer defects will go into a file named ASAN.
For an exe built just with Ubsan, and setting UBSAN_OPTIONS to include “log_path=./UBSAN”, the Undefined Behavior defects will go into a file named UBSAN.
For an exe built with both Asan and Ubsan
o The Asan output goes to the designated log file, but the ubsan output goes only to stderr
o The above applies even if the log_path is only set via UBSAN_OPTIONS, and ASAN_OPTIONS is unset
o If log_path is set in both ASAN_OPTIONS and UBSAN_OPTIONS, the log_path used is the UBSAN one, yet only contains the ASAN results
Is there some hidden magic that will let both sanitizers write to the same defect log ?
To reproduce, use a simple testcase that has a defect for each sanitizer:
char *hello = "hello";
int main (int argc, char *argv[])
{
int x = 1;
x <<= 32; // Error: (1 << 32) can't be represented in a (32-bit) int
char some_char = hello [argc *10];
}
build and run: (g++ 7.3.0 used here, but other GCC versions, and also clang 7.1.0 have shown the same basic behavior)
Asan only - works as expected
g++ foo.C -fsanitize=address -fsanitize-recover=all -g
setenv ASAN_OPTIONS "log_path=./ASAN:halt_on_error=0:handle_abort=1:exitcode=0"
a.out
File ASAN. 29648 contains defect starting with
==29648==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000400aca at pc 0x0000004009a5 bp 0x7fffffffe090 sp 0x7fffffffe088
READ of size 1 at 0x000000400aca thread T0
0x4009a4 in main /tmp/foo.C:7
Ubsan only - works as expected
g++ foo.C -fsanitize=undefined -fsanitize-recover=all -g
setenv UBSAN_OPTIONS "log_path=./UBSAN:halt_on_error=0:handle_abort=1:exitcode=0”
a.out
File UBSAN.29675 contains
foo.C:6:6: runtime error: shift exponent 32 is too large for 32-bit type 'int'
Asan PLUS Ubsan - strange logging behavior
g++ foo.C -fsanitize=address,undefined -fsanitize-recover=all -g
setenv ASAN_OPTIONS "log_path=./ASAN:halt_on_error=0:handle_abort=1:exitcode=0"
a.out
ASAN_OPTIONS gets ignored, all defects reported on stderr. Now try setting UBSAN_OPTIONS:
setenv UBSAN_OPTIONS "log_path=./UBSAN:halt_on_error=0:handle_abort=1:exitcode=0”
a.out
File UBSAN.30352 contains ONLY the Asan defect:
==30352==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000400aca at pc 0x0000004009a5 bp 0x7fffffffe090 sp 0x7fffffffe088
READ of size 1 at 0x000000400aca thread T0
0x4009a4 in main /tmp/foo.C:7
and the Ubsan defect gets written only to stderr:
foo.C:6:6: runtime error: shift exponent 32 is too large for 32-bit type 'int'
and the Ubsan defect gets written only to stderr:
This sounds like a bug (or at least untested combination of settings).
That said, in general, ASan developers do not consider halt_on_error=0 to be a useful feature -- you should just fix the bugs as you find them, as it is pointless to look for UB after you've already overflown a buffer or used dangling memory. Anything could happen after that point.
So if you do file a bug about this strange logging behavior, I would expect that bug to receive little attention.
Have confirmed that this is actually a bug. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94328 applies
I have been searching for a way to use AddressSantizer with avr-gcc where there is no console to detect that the runtime code has crashed. I still have to experiment with it, but I believe this use case is a counter example to this feature not being useful.
I am trying to load a SPIR binary i created with clang+llvm 6.0.1.
Created a few different files with :
clang -target spir-unknown-unknown -cl-std=CL1.2 -c -emit-llvm -Xclang -finclude-default-header OCLkernel.cl
clang -target amdgcn-amd-amdhsa -cl-std=CL1.2 -c -emit-llvm -Xclang -finclude-default-header OCLkernel.cl
clang -cc1 -emit-llvm-bc -triple spir-unknown-unknown -cl-std=CL1.2 -include "include\opencl-c.h" OCLkernel.cl
This is all happening on windows, installed AMD APP SDK 3 and Adrenalin 18.6.1 drivers.
After this i try to create a program from the binary :
clCreateProgramWithBinary(context, 1, &device, &programSrcSize, (const unsigned char**)&programSrc, 0 , &status)
This all goes OK, i don't get any errors here, but i do when trying to build it afterwards :
clBuildProgram(program, 1, &device, " –x spir -spir-std=1.2", NULL, NULL);
The error i get is :
Error CL_INVALID_COMPILER_OPTIONS when calling clBuildProgram
I tried without the "-x spir..." stuff too, but then i just get a :
error: Invalid value (Producer: 'LLVM6.0.1' Reader: 'LLVM 3.9.0svn')
EDIT:
CL_DEVICE_NAME: gfx900
CL_DEVICE_VERSION: OpenCL 2.0 AMD-APP (2580.6)
CL_DEVICE_OPENCL_C_VERSION: OpenCL C 2.0
CL_DRIVER_VERSION: 2580.6 (PAL,HSAIL)
CL_DEVICE_SPIR_VERSIONS: 1.2
After running clCreateProgramWithBinary i query the device with clGetProgramBuildInfo and get :
CL_PROGRAM_BINARY_TYPE = [CL_PROGRAM_BINARY_TYPE_INTERMEDIATE]
So that should mean the binary is being recognised, else i guess it would return CL_PROGRAM_BINARY_TYPE_NONE
EDIT2:
I think clang isn't creating a 'good' binary, but how to create it then?
Appreciate your help!
Unfortunately the support for SPIR was silently removed from AMD drivers, see dipak answers in this thread of AMD community forum:
https://community.amd.com/thread/232093
Regarding your second question: general clang+LLVM (not the secret version tuned by AMD and included in their proprietary drivers) still cannot produce binaries compatible with general-purpose Windows AMD drivers, however it is possible for Linux: all new AMD’s ROCm, AMD PAL and Mesa 3D runtime are covered.
It is a mystery for me why LLVM AMDGPU backend developers do not prioritize the task to produce binaries for Windows drivers, as there is a couple of GCN assembler projects that provide such a functionality through Windows OpenCL interface, to name a few: CLRadeonExtender, ASM4GCN, HepPas, etc. Moreover I know an undocumented fork of clang+LLVM that (as its author states) produce such OpenCL binaries! "There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy."
Does anyone know if it is possible to have binary code from IR generated with llvmlite? in llvm, we can simply clang -emit-llvm -o foo.bc -c foo.c. What if I am using llvmlite?
As far as I can tell, llvmlite doesn't include a linker. You can write object code with, for example,
target = llvm.Target.from_default_triple()
machine = target.create_target_machine()
with llvm.create_mcjit_compiler(module, target) as mcjit:
def on_compiled(module, objbytes):
open('mymodule.o', 'w').write(objbytes)
mcjit.set_object_cache(on_compiled, lambda m: None)
mcjit.finalize_object()
And then use your standard linker ld, which usually you would have via gcc or clang to link the object file. LLVM 4 seems to ship with its own linker lld which is an option to use manually but llvmlite isn't on version 4 and wouldn't be able to expose that functionality.
On my machine for example, I can run from bash
$ gcc -o llvmapp mymodule.o
$ ./llvmapp
It appears the easiest solution thus far is directly write all your code in python, but it comes at the cost of run time, which I know some people don't care about.
Unfortunately, I would have to agree with #Jimmy. I haven't seen anything yet and it is 2019 which is 2 years later and still nothing.
I'm trying for 3-4 days to set up my debugger in Qt without success.
I have Qt creator 2.7.0 with compiler MINGW and debugger gdb.exe on Windows 7
I'm building on debug mode, the debugger is skipping the breakpoints.
Thank you in advance for any tip
![qt setup][1]
This is how debugger output looks like:
sSetting breakpoints...
dSetting breakpoints...
dATTEMPT BREAKPOINT SYNCHRONIZATION
dTAKING OWNERSHIP OF BREAKPOINT 1 IN STATE 0
<53-break-insert -f "\"onmainwindow.cpp\":333"
dBREAKPOINTS ARE NOT FULLY SYNCHRONIZED
dATTEMPT SYNC
dATTEMPT BREAKPOINT SYNCHRONIZATION
dBREAKPOINTS ARE NOT FULLY SYNCHRONIZED
>&"No source file named onmainwindow.cpp in loaded symbols.\n"
>53^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="\"onmainwindow.cpp\":333",times="0"}
<54-break-delete 1
>54^done
<55-break-insert -f "\"onmainwindow.cpp\":333"
>&"No source file named onmainwindow.cpp in loaded symbols.\n"
>55^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="\"onmainwindow.cpp\":333",times="0"}
dATTEMPT BREAKPOINT SYNCHRONIZATION
dBREAKPOINTS ARE SYNCHRONIZED
dALL COMMANDS DONE; INVOKING CALLBACK
<56maint print msymbols C:/Users/Lucian/AppData/Local/Temp/gdb_ns_.Ae4844
>&"maint print msymbols C:/Users/Lucian/AppData/Local/Temp/gdb_ns_.Ae4844\n"
>56^done
dFOUND NON-NAMESPACED Qt
dNOTE: INFERIOR SETUP OK
dState changed from InferiorSetupRequested(4) to InferiorSetupOk(6) [master]
dState changed from InferiorSetupOk(6) to EngineRunRequested(7) [master]
dQUEUE: RUN ENGINE
dCALL: RUN ENGINE
<57-exec-run
>57^running
dNOTE: ENGINE RUN AND INFERIOR RUN OK
sRunning.
dState changed from EngineRunRequested(7) to InferiorRunOk(11) [master]
dINFERIOR STARTED
sApplication started
>~"[New thread 7144.0x1fdc]\n"
dFOUND PID 7144
dTaking notice of pid 7144
s[New thread 7144.0x1fdc]
>~"(no debugging symbols found)\n"
>~"(no debugging symbols found)\n"
>~"(no debugging symbols found)\n"
I installed also the new gdb debugger and it also doens;t stop ar breakpoints, this new gdb version outputs:
dATTEMPT SYNC
dATTEMPT BREAKPOINT SYNCHRONIZATION
dBREAKPOINTS ARE NOT FULLY SYNCHRONIZED
>&"No symbol table is loaded. Use the \"file\" command.\n"
>200^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="`<PENDING>",pending="\"onmainwindow.cpp\":55",times="0",original-location="\"onmainwindow.cpp\":55"}`
An interesting thing that I noticed is:
Although the debug build have the following configuration:
qmake.exe D:\Elance\X2GoClient\sources_v2.0\x2goclient.pro -r -spec win32-g++ "CONFIG+=debug" "CONFIG+=declarative_debug"
and after that it runs step 2: make:C:\mingw\bin\mingw32-make.exewhere the CINFIG+=debug is mentioned for the debug
the debug output window shows me this:
20:11:11: Configuration unchanged, skipping qmake step.
20:11:11: Starting: "C:\mingw\bin\mingw32-make.exe"
C:/mingw/bin/mingw32-make -f Makefile.Release
is shows:
make -f Makefile.Release..this is very strange
is it ok to show that is building with the makefile from Release?
Thanks
Ok, this might be useful for somebody:
I had the above described problem and solve it with this changes:
Step 1(This problem I think is related to Qt Creator, I think it is build with configure -release instead of configure -debug-and-release flags)
I altered the x2goClient.pro like:
**BEFORE:**
win32-* {
message(building $$TARGET for windows without ldap and cups)
LIBS += -lwinspool -lws2_32
CONFIG += static release
}
**AFTER:**
win32-* {
message(building $$TARGET for windows without ldap and cups)
LIBS += -lwinspool -lws2_32
CONFIG += static debug
}
Step 2(I think due to the fact that Qt might be compiled wrong, the default make.exe step was interpreted as make -f Makefile.release although I selected the Debug build)
In projects->Build Steps->Make arguments
I placed: -f Makefile.Debug
Step 3: After doing these changes, I got several error related to some DLLs. The interesting fact was that Makefile.Debug that was generated by Qt was not generated ok, it contained some dll's like QtCored.dll that wasn't present on Qt, I have changed it as I found the dll's like from QtCored.dll to QtCored4.dll
Step 4: It seemed that the builder and debugger that I had wasn't right. I downloaded the latest MingW and change BOTH builder and debugger. First time I changed only the debugger and got "During startup program exited with code 0xc0000005" Error. When I changed BOTH builder and debugger of the latest MingW it finally worked.
I am working with Qt for 2 weeks now, but I didn't have some much problems with an IDE so far in my life. Qt is good, but it's a bit hardcore to configure.