Why GCC option -Os is not used during compilation? - optimization

Clang warns me,
clang: warning: argument unused during compilation: '-Os'
During compile with make. Why it doesn't accept the optimization flag?

-Os isn't a valid optimization option for (most) clang - it's not completely flag-compatible with GCC.
The clang man page is authoritative on what options your particular version accepts (specifically, optimizing by size is not yet a primary concern for LLVM). Apple has pushed back patches for -Os and -Oz, but most packages don't include these updates.

Related

Error in mediactrl_am.cpp while building wxwidgets 3.0.3 with llvm 5.0.0 target x86_64-w64-windows-gnu

I'v recently compiled wxWidgets 3.0.3 with mingw-w64 7.2.0, but due some problems with exception handling now I'm trying recompile them with llvm 5.0.0 (using x86_64-w64-windows-gnu target, standard library from mingw-w64 7.2.0, 64 bit, seh, posix threads) which has not those problems.
I have not find instructions how to build current stable version (3.0.3) of wxWidgets with Clang on Windows. So I'm trying a command like
mingw32-make.exe -f makefile.gcc MONOLITHIC=1 SHARED=1 BUILD=debug CXXFLAGS=" -fexceptions -fasynchronous-unwind-tables -fnon-call-exceptions -std=gnu++11 -pthread " LDFLAGS=" -fexceptions -fasynchronous-unwind-tables -fnon_call_exceptions -pthread " CC="clang -target x86_64-w64-windows-gnu" CXX="clang++ -target x86_64-w64-windows-gnu" COMPILER_PREFIX="clang"
in ..\build\msw subdirectory to build one of the possible configurations.
(With mingw-w64 I used also LDFLAGS=" -Wl,--allow-multiple-definition ", possible here will be problems with multiple symbols too. I've also pathched source code as I had problems with wxPrintf)
The first error I have:
../../src/msw/mediactrl_am.cpp:2234:10: error: case value evaluates to
4294966687, which cannot be narrowed to type 'DISPID' (aka 'long')
[-Wc++11-narrowing]
case 0xfffffd9f: // readystatechange in IActiveMovie2 and IMediaPlayer
^
1 error generated.
My account on wxWidgets forum not activated yet, so I ask here.
May be somebody knows correct way how to repair this issue?
The obvious fix for this particular problem seems to be to replace this value with -609.
However I need to warn you that, to the best of my knowledge, nobody has compiled wxMSW using clang so far (even though clang can be used for compiling wxGTK and wxOSX, of course), so you may well run into other, less trivial, problems later. I'd also recommend trying to compile the latest git master instead of 3.0.3 as any non-trivial changes that might be required for clang build are unlikely to be done in the stable 3.0 branch.

CMake additional Debug Options

When compiling code with debug symbols, I usually also want to enable certain compile-time and run-time checks, like so:
gfortran -c -o hello.o -g -O0 -Wall -fcheck-all -fbacktrace hello.f90
(Yes, it's Fortran, but I assume that it'd work with other languages just the same.)
If I wanted to compile the same with the Intel Fortran Compiler, the command would look like this:
ifort -c -o hello.o -g -O0 -warn all -check all -traceback hello.f90
The only way to compile like this in CMake that I have found so far is something like this:
IF(${CMAKE_Fortran_COMPILER_ID} MATCHES "GNU")
set(CMAKE_Fortran_FLAGS_DEBUG "${CMAKE_Fortran_FLAGS_DEBUG} -Wall -fcheck=all -fbacktrace")
ELSEIF(${CMAKE_Fortran_COMPILER_ID} MATCHES "Intel")
set(CMAKE_Fortran_FLAGS_DEBUG "${CMAKE_Fortran_FLAGS_DEBUG} -warn all -check all -traceback")
ELSE()
message(WARNING "Unable to determine Compiler ID: ${CMAKE_Fortran_COMPILER_ID}")
ENDIF(${CMAKE_Fortran_COMPILER_ID} MATCHES "GNU")
But this introduces all the hardcoded flags that I wanted to avoid when starting to use CMake. Is there a way to add compiler switches based on what they do, like "Enable all Compile time Warnings" or "Enable all Runtime Checks"?
CMake warning API: coming soon.
The discussion proposes commands like add_compile_warnings or target_compile_warnings, following the model of add_compile_options and target_compile_definitions, with warning levels such as:
all (compiler specific "all", e.g. /Wall or -Wall);
default;
none;
everything (all possible warnings for compiler, if there is no such option use maximum level plus some warnings explicitly).
You may study the proposed API and perhaps expose your unsatisfied needs in the discussion.
No, CMakes (in the current version 3.6) does not offer such sets of compiler switches. You have to define them by yourself.
Actually, all compilers offer such a switch like Wall. You are not satisfied with the choice of the compiler programmers, how could the CMake programmers do better?

Superoptimization - gcc

Apparently gcc supports superoptimization, What are the flags necessary to enable it in gcc/g++? Is there really such a thing?

Using Mono mkbundle To Target SGEN Garbage Collector

Is it possible to bundle a Mono executable using mkbundle that uses the sgen GC?
I assume that because the produced bundle requires the libmono-2.0.so.1 instead of the libmonosgen-2.0.so that it is using the standard boehm GC. I have tried using $MONO_OPTIONS=--gc=sgen but the resulting bundle still requires the non-sgen lib.
Am I misunderstanding the use of the libmono and libmonsgen libs?
Thank you for any assistance or guidance
This is a bit tricky, because Mono actually has two separate executables and two separate libraries, one for each garbage collector. For example, if you run mono --gc=sgen ... then mono will actually do an execvp() of mono-sgen ... to switch to a different executable.
Similarly, mkbundle will use pkg-config to select the library and link one or the other (i.e. whichever is the system default). To get the other library, there are two options:
One is to rebuild Mono with sgen being the default. Obviously, that may not be a viable solution.
The alternative is to use pkg-config to override the selection. You'd create a copy of mono-2.pc, replace -lmono-2.0 with -lmonosgen-2.0, update prefix and exec_prefix and use the PKG_CONFIG_PATH environment variable to pick that version.
Note that I've never actually tried the latter, but there is no reason why it shouldn't work, since pkg-config is where mkbundle gets the library path from.
Thanks for this question as it helps me to determine why one of my applications is running too slowly after bundling with the mkbundle. It was because of the Boehm GC engine being used.
To include SGen you just need to invoke mkbundle with --keeptemp flag and then rewrite compiler command (which is printed by mkbundle) to include monosgen-2 instead of mono-2.
Example: (for Mac, but could be easily rewritten for Linux)
export PATH=/Library/Frameworks/Mono.framework/Commands/:$PATH
export AS="as -arch i386"
export CC="cc -arch i386 -framework CoreFoundation -lobjc -liconv"
mkbundle TestApp.exe --deps --static -o TestAppBundleName --keeptemp
cc -arch i386 -framework CoreFoundation -lobjc -liconv -o TestAppBundleName -Wall `pkg-config --cflags monosgen-2` temp.c `pkg-config --libs-only-L monosgen-2` `pkg-config --variable=libdir monosgen-2`/libmonosgen-2.0.a `pkg-config --libs-only-l monosgen-2 | sed -e "s/\-lmonosgen-2.0 //"` temp.o

Objective-C compiler flags

When compiling Objective-C from the command line (gcc), what are some good flags to use? Many of the standard C flags (-Wall, -ansi, etc) don't play well with Objective-C.
I currently just use -lobjc and -frameworkwith various frameworks.
Many of the standard C flags (-Wall, -ansi, etc) don't play well with Objective-C
-Wall works perfectly fine with Objective-C.
The thing to do is build an Objective-C file with Xcode and have a look at the build transcript. I've just done that and here are some highlights:
-x objective-c I guess that means "compile as Objective-C", probably important
-arch x86_64 build for a particular CPU architecture
-std=gnu99 build for C99 + GNU extensions (actually surprised me, I thought Xcode used -std=c99).
-isysroot .... specifies the location of the SDK.
-mmacosx-version-min=10.6 I am compiling for 10.6 and up
-fobjc-gc-only this file was intended to be used with garbage collection and won't work without it, so I compile for GC only.
-Wall the obvious.
If you are compiling from the command line, it's probably a good idea to set the option to treat warnings as errors. I don't from within Xcode because the build results window remembers the uncleared warnings from previous builds.