I tried, and it looks like Vala is passing the -O3 flag by default to the GCC compiler. Is that true? (my conclusion is based only on the size of the file when defining the-X flag to -O3 and without it)
Related
I would like to report a bug but I cannot make a new account in bugzilla.
I use the gcc-arm-none-eabi-10.3-2021.10 version.
My C Code is auto-generated from Simulink. When I use the pointer *rtu_AngleMecIn then in assembly code the variable is not used and the program is not working.
When I changed the auto generated Code manually, I added the global variable Sig_MechanicalAnlge instead of the pointer. Then the assembly code seems plausible and the global variable Sig_MechanicalAngle is used.
Are you think this is a bug or Matlab Code Generator has generated wrong C Code?
I use the following Compiler options in Cmake.
#compile options add_compile_options(-mcpu=cortex-m4 -std=gnu11 -g -DDEBUG -DUSE_HAL_DRIVER -DSTM32F446xx -Og -ffunction-sections -fdata-sections -Wall -Wextra -fstack-usage --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -ffile-prefix-map=/home/runner/work/Nyx_Simulink/Nyx_Simulink/Code=.)
When trying to compile with flag I get the following error:
Error in dyn.load(dllfile) :
unable to load shared object '/home/Projects/RBOrB/src/RBOrB.so':
/home/Projects/RBOrB/src/RBOrB.so: undefined symbol: __gcov_merge_add
My Makevars looks like this:
CXXFLAGS += -O3 -march=native -fprofile-generate
PKG_CXXFLAGS += -O3 -std=c++11 -march=native -fprofile-generate
PKG_LIBS += $(shell ${R_HOME}/bin/Rscript -e "RcppParallel::RcppParallelLibs()") $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
Does R not support this or am I doing something wrong?
Suggestions:
Use the same -std=c++11 in both CXXFLAGS and PKG_CXXFLAGS
A quick google suggests that -fprofile-generate needs corresponding linkage flags. Can you confirm that -fprofile-generate appears in the link command too?
Confirm that everything works correctly without profile flags.
From memory, I'm not sure that setting CXXFLAGS actually works. I believe your changes here may be overwritten.
I'm trying to compile AODV for ARM linux. I use a SabreLite as a board with kernel version 3.0.35_4.1.0. It's worth mention that i'm using openembedded to create my Linux Distribution for my board.
The AODV source code (http://sourceforge.net/projects/aodvuu/) has a README file which give some indications on how to install it on ARM as stated a bit here.
(http://w3.antd.nist.gov/wctg/aodv_kernel/kaodv_arm.html).
I was able to upgrade the makefile in order to be used with post 2.6 kernel version ( as stated above, i have the 3.0.35_4.1.0 kernel version).
So, basically, what i am trying to do is that i have to create a module (let's say file.ko) and then load it into the ARM (with insmod file.ko command).
To do that, i am using a cross compiler which some values are stated below:
echo $CC :
arm-oe-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-vfp-neon-oe-linux-gnueabi
echo $ARCH=arm
echo $CFLAGS: O2 -pipe -g -feliminate-unused-debug-types
echo $LD :
arm-oe-linux-gnueabi-ld --sysroot=/usr/local/oecore-x86_64/sysroots/cortexa9hf-vfp-neon-oe-linux-gnueabi
echo $LDFLAGS :
-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--as-needed
when i launch "make command", i get the following errors:
LD [M] /home/scof/script_emulation/AODV/aodv-uu/lnx/kaodv.o
arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
arm-oe-linux-gnueabi-ld: use the --help option for usage information
It states that there is something wrong with the linker. This linker comes from the cross compilation tools and i normally shouldn't touch it.
Anyway, to get this above errors fixed, i try to withdraw the LDFLAGS like this:
export LDFLAGS='',
and after this, the make command works and i get the module kaodv.ko. But when i insert it into my ARM to check, it does not work. It actually freeze my terminal
So my question is, do i have to specify the LDFLAGS when compiling ? Does withdrawing LDFLAGS can have impact on the generated kernel module.
Actually, i try to understand where might be the problem and the only thing that come to me is that may be i should not change manually the LDFLAGS. But if i don't change de LDFLAGS, i get the unrecognized option error.
My second question related to that is, what are the possibly value of LDFLAGS
in ARM compilation
Thanks !!
echo $LDFLAGS : -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,--as-needed
There are two common methods of invoking the linker in a GCC-based toolchain. One is to do it directly, but another is to use GCC as a front end to invoke the linker, rather than invoke it directly. When doing this, options intended for the linker are prefixed with -Wl, so that GCC knows to pass them through rather than interpret them itself.
In your case the error message from LD itself
arm-oe-linux-gnueabi-ld: unrecognized option '-Wl,-O1'
Indicates that your build system is passing LDFLAGS directly to the linker, and not by way of GCC.
Therefore, you should remove the -Wl, prefix and your LDFLAGS would instead be
-O1 --hash-style=gnu --as-needed --as-needed
(the duplication of the last argument is probably pointless but benign)
-O1 is an option that tells the linker to optimize. I believe it something new, and your linker may be slightly out of date. Try removing -Wl,-O1, it should still work.
I tried compiling MPI programs with mpicc by passing -O1 -O2 -O3 etc optimization flags. I would like to know whether optimization flags really work with mpicc and also wether mpicc supports all the optimization flags of gcc compiler.
mpicc, mpic++, mpif90, mpif77, etc. are all just wrappers around the actual system compiler. Any option that the wrapper does not recognise as its own gets passed to the actual compiler. You can see what is being invoked behind the scenes by calling mpicc with the -showme option:
$ mpicc -showme
gcc ... <lots of options> ...
absolutely. All flags passed to mpicc, mpic++ and the likes are passed to the "original" compiler.
A quick question. I found both "DLDFLAGS" and "LDFLAGS" in a sample Makefile. The compiler used is gcc. It looks like they are both used for linkers. I'm wondering what's the difference between them.
LDFLAGS is normally set to contain options that are passed through to the linker (so may include required libraries). Together with CFLAGS, these are often set as part of a developers environment variables and make will know about them so will actively look to see if they're set and pass them through to the compiler.
For example, if I set CFLAGS in my environment to -O2 -Wall, then if I type make hello with no Makefile, make will automatically invoke the compiler as gcc -O2 -Wall hello.c -o hello.o. Then it'll invoke the linker in a similar way, adding the flags in LDFLAGS to the command line.
Makefiles can explicitly override both LDFLAGS and CFLAGS.
DLDFLAGS on the other hand is not a well known/defined variable, so it's likely to be specific to that particular Makefile. You'd have to read the Makefile to find out how it's used. It may, for example, define linker flags to use if LDFLAGS is set - read the Makefile to find out for sure.
Isn't DLDFLAGS just a precompiler flag that defines macro named "LDFLAGS"?
From gcc manual:
-D name
Predefine name as a macro, with definition 1