Accessing neon intrinsics with Beagleboard GCC - linux

I'm using arm-linux-gnueabihf as my cross compiler under a VmBox Debian 8.1 on Windows 7 to compile for my Beagleboard. I've found much info on NEON/SIMD intrinsics but my compiler doesn't recognize the NEON intrinsics (i.e. uint8x8t). I've seen refernces to arm_neon.h and neon.h but those are not in my tools. Is there a library I need to install?
My compiler command is arm-linux-gnueabihf-g++
with options -O3 -pg -march=arm7-a -mtune=cortex-a8 -mfloat-abi=hard -mfpu=neon -ffast-math -g3 -Wall -c -fmessage-length=0

Related

Error when I compile 'hello-world' example from Contiki

I have installed the Contiki OS sources, and the ARM GCC compiler by doing brew install arm-none-eabi-gcc. However, when I try to run the hello world example in Contiki's example folder using the command make TARGET=srf06-cc26xx BOARD=sensortag/cc2650 hello-world.bin CPU_FAMILY=cc26xx, I get the following error message:
CC ../../cpu/cc26xx-cc13xx/lib/cc26xxware/startup_files/ccfg.c
arm-none-eabi-gcc: error: unrecognized -march target: core2
arm-none-eabi-gcc: note: valid arguments are: armv4 armv4t armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m armv7e-m armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a armv8-m.base armv8-m.main armv8-r iwmmxt iwmmxt2
arm-none-eabi-gcc: error: missing argument to '-march='
arm-none-eabi-gcc: error: unrecognized command line option '-mssse3'
make: *** [obj_srf06-cc26xx/ccfg.o] Error 1
I triple-checked that the ARM GCC compiler is accessible from the terminal by doing arm-none-eabi-gcc --version, and I can see that it is properly installed:
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
So I am really not sure what might be wrong here. Can anyone help?
My operating system is macOS Mojave Version 10.14.6.
UPDATE: The makefile is given in the example folder (from contiki):
CONTIKI_PROJECT = hello-world
all: $(CONTIKI_PROJECT)
CONTIKI = ../..
include $(CONTIKI)/Makefile.include
UPDATE 2: By adding V=1 in the command, my output is:
arm-none-eabi-gcc -march=core2 -mtune=haswell -mssse3 -ftree-vectorize
-fPIC -fPIE -fstack-protector-strong -O2 -pipe -DCONTIKI=1
-DCONTIKI_TARGET_SRF06_CC26XX=1 -DNETSTACK_CONF_WITH_IPV6=1
-DUIP_CONF_IPV6_RPL=1 -DBOARD_SENSORTAG=1 -DBACKDOOR_IOID=0x00000000
-I../../cpu/cc26xx-cc13xx/lib/cc26xxware -I../../cpu/cc26xx-cc13xx
/lib/cc26xxware/driverlib -I../../cpu/cc26xx-cc13xx/lib/cc26xxware/inc
-mcpu=cortex-m3 -mthumb -mlittle-endian -ffunction-sections -fdata-sections
-fshort-enums -fomit-frame-pointer -fno-strict-aliasing -Wall -std=c99 -O2
-I. -I../../platform/srf06-cc26xx/. -I../../platform/srf06-cc26xx
/sensortag/cc2650 -I../../platform/srf06-cc26xx/sensortag -I../../platform
/srf06-cc26xx/common -I../../cpu/cc26xx-cc13xx/. -I../../cpu/cc26xx-cc13xx/dev
-I../../cpu/cc26xx-cc13xx/rf-core -I../../cpu/cc26xx-cc13xx/rf-core/api -I../../cpu/cc26xx-cc13xx/lib/cc26xxware/startup_files -I../..
/cpu/cc26xx-cc13xx/../arm/common/dbg-io -I../../core/dev -I../../core/lib -I../../core/net -I../../core/net/llsec -I../../core/net/mac -I../..
/core/net/rime -I../../core/net/rpl -I../../core/sys -I../../core/cfs
-I../../core/ctk -I../../core/lib/ctk -I../../core/loader -I../../core/. -I../../core/sys -I../../core/dev -I../../core/lib -I../../core/net/ipv6 -I../../core/net/ip -I../../core/net/rpl -I../../cpu/cc26xx-cc13xx
/lib/cc26xxware/driverlib -I../../core/net -I../../core/net/mac -I../..
/core/net/mac/contikimac -I../../core/net/llsec -I../../platform/srf06-
cc26xx/ -I../.. -DCONTIKI_VERSION_STRING=\"Contiki-3.x-3345-g32b5b17\"
-include "contiki-conf.h" -c ../../cpu/cc26xx-cc13xx/lib/cc26xxware
/startup_files/ccfg.c -o obj_srf06-cc26xx/ccfg.o
UPDATE 3: If I do unset CFLAGS, I get a new error message:
/usr/local/Cellar/arm-none-eabi-gcc/9-2019-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: hello-world.elf section `.interp' will not fit in region `FLASH_CCFG'
/usr/local/Cellar/arm-none-eabi-gcc/9-2019-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: region `FLASH_CCFG' overflowed by 9120 bytes
/usr/local/Cellar/arm-none-eabi-gcc/9-2019-q4-major/gcc/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: warning: cannot find entry symbol ad_strip_dylibs; defaulting to 0000000000000000
collect2: error: ld returned 1 exit status
make: *** [hello-world.elf] Error 1
rm obj_srf06-cc26xx/startup_gcc.o hello-world.co obj_srf06-cc26xx/fault-handlers.o
Here's a consolidation of #kfx's solution (which worked like a charm):
unset CFLAGS
unset LDFLAGS
make clean
This is because there may be some other flags which you accidentally set previously, so you have to unset them in order for the compilation to work.

gcc 7.1 parameters not reconized after compile

I built GCC 7.1 successfully and installed it, however when I tried to compile with options like -quiet, -imultiarch x86_64-linux-gnu and/or -auxbase dummy it does not recognize them. do I have to add these on compile somehow? These options are recognized by the compiler when installed though packages.
These flags are recognized by the internal compiler executable, cc1, but not by gcc, which is the compiler driver (the driver is the high level compiler executable which orchestrates the build process, and is responsible for running as and ld, among other things).
For example, gcc foo.c -o foo.o -v results with this cc1 command line on Ubuntu 16.04:
/usr/lib/gcc/x86_64-linux-gnu/5/cc1 -quiet -v -imultiarch x86_64-linux-gnu foo.c -quiet -dumpbase foo.c -mtune=generic -march=x86-64 -auxbase foo -version -fstack-protector-strong -Wformat -Wformat-security -o /tmp/ccds3WIY.s
Note -quiet, -imultiarch and auxbase in the above.

How to compile latest sources using older gcc glibc versions and run them?

I'm able to compile & run the latest "stockfish chess engine" sources using GCC 4.8 or later on Redhat EL 7.X. The latest source code (alongwith README) is available at https://github.com/mcostalba/Stockfish/tree/master
The commands to compile & build are: (goto "src" directory)
gmake build ARCH=x86-64
gmake install
However my requirement is to compile & run the same on Redhat EL 6.7 Server where the latest GCC version available is 4.4.7 (& glibc 2.12) as I can NOT upgrade GCC version without actually migrating to RHEL 7.X
Is it possible to modify the latest source to get it compliled & run on old version of gcc/glibc? if yes, would anyone be able to modify the sources (perhaps just Makefile?) for me please?
I tried changing "C ++ 11" to "C ++ 0x" in the "Makefile" but no luck. Please see the error I'm getting when I try to compile latest SF source with GCC 4.4.7:
[root#test-server src]# ldd --version
ldd (GNU libc) 2.12
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
[root#test-server src]# gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[root#test-server src]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.7 (Santiago)
[root#test-server src]# uname -r
2.6.32-573.12.1.el6.x86_64
[root#test-server src]# gmake build ARCH=x86-64
gmake ARCH=x86-64 COMP=gcc config-sanity
gmake[1]: Entering directory `/root/Stockfish-master/src'
Config:
debug: 'no'
optimize: 'yes'
arch: 'x86_64'
bits: '64'
prefetch: 'yes'
popcnt: 'no'
sse: 'yes'
pext: 'no'
Flags:
CXX: g++
CXXFLAGS: -Wall -Wcast-qual -fno-exceptions -fno-rtti -std=c++11 -pedantic -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto
LDFLAGS: -Wl,--no-as-needed -lpthread -Wall -Wcast-qual -fno-exceptions -fno-rtti -std=c++11 -pedantic -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto
Testing config sanity. If this fails, try 'make help' ...
gmake[1]: Leaving directory `/root/Stockfish-master/src'
gmake ARCH=x86-64 COMP=gcc all
gmake[1]: Entering directory `/root/Stockfish-master/src'
g++ -Wall -Wcast-qual -fno-exceptions -fno-rtti -std=c++11 -pedantic -Wextra -Wshadow -m64 -DNDEBUG -O3 -DIS_64BIT -msse -flto -c -o benchmark.o benchmark.cpp
cc1plus: error: unrecognized command line option "-std=c++11"
cc1plus: error: unrecognized command line option "-flto"
gmake[1]: * [benchmark.o] Error 1
gmake[1]: Leaving directory `/root/Stockfish-master/src'
gmake: * [build] Error 2
[root#test-server src]#
Many thanks in advance!
Is it possible to modify the latest source to get it compliled & run
on old version of gcc/glibc? if yes, would anyone be able to modify
the sources (perhaps just Makefile?) for me please?
Sure it's possible. It will take time and effort though.
I can NOT upgrade GCC version without actually migrating to RHEL 7.X
You can't install the GCC binary from RHEL you mean. But if you have one compiler you can have another.
You have a few options which allow you to manually compile your own GCC and install it to /opt or /usr/local without messing your system.
You can do it manually or use a tool chain like installing gentoo`s portage or bootstrapping pkgsrc which offers gcc-4.8
Although, I am an avid gentoo user, I recommend using pkgsrc on foreign architectures. It's very easy to get started with, and have a vast number of packages.

Unable to compile C program on Mac, but able to compile on Linux

I facing some trouble compiling my programming assignment on my local machine. The program is distribute to us with makefiles and compilation commands that are known to work on the school's Scientific Linux servers. My local machine is Mac OS X El Capitan.
When I compile my program running make on my Mac, I get the following error that prevents compilation from proceeding:
myid-MacBook-Pro:mp6 myid$ make
gcc -g -lm -std=c99 -Wall -Werror -c lodepng.c
clang: error: -lm: 'linker' input unused
make: *** [lodepng.o] Error 1
But when I push that very same code as work in progress to the Linux servers and compile there, everything works fine. The linux servers use gcc and not clang:
[netid#linux-a2 mp6]$ make
gcc -g -lm -std=c99 -Wall -Werror -c functions.c
gcc -g -lm -std=c99 -Wall -Werror main.o lodepng.o imageData.o functions.o -o mp6 -lm
gcc -g -lm -std=c99 -Wall -Werror -c test.c
gcc -g -lm -std=c99 -Wall -Werror test.o lodepng.o imageData.o functions.o solution.o -o test -lm
In the makefile, these are the variable definitions:
CC=gcc
CFLAGS=-g -lm -std=c99 -Wall -Werror
and the target definition for loadpng.o
lodepng.o: lodepng.c
$(CC) $(CFLAGS) -c lodepng.c
I would appreciate any help on understanding this error and overcoming it.
Thank you very much.
Also, on this note, I thought I would say that I've noticed a subtle difference between Clang and GCC. It seems to me that even warnings generated by Clang would prevent the compilation to proceed so the warnings behaves like errors. But for GCC, if it generates warnings, it still compiles the object file. Please correct me if I'm mistaken.
Right now you're getting a compilation error on your Mac because you're trying to pass linker commands (i.e. -lm) into a compilation(i.e. -c). Do not give link flags when you compile (-c flag) your source files.
In the other compilation snippet you provided, the unused linker command seems to pass by unnoticed which isn't a good thing.
For your last question, the flag -Werror should force all compilation warnings to become errors -- which is exactly what you are describing.

Source-built clang-3.7 on Linux not finding Block_copy

I built and installed llvm/clang-3.7 from source on my Ubuntu Linux system (I'm building from source because my development environment at work does not have apt-get available). The gcc version is 4.8.2. I followed the clang build instructions at http://clang.llvm.org/get_started.html, and everything worked fine (mkdir build; cd build; cmake -G "Unix Makefiles" ../llvm; make; make install). However, I'm now finding that a program to test Block_copy fails to compile. The program is auto-generated by autoconf when I try to build gnustep-base. The part that fails is:
int
main ()
{
return _Block_copy ();
;
return 0;
}
My compile command is:
clang -o conftest -m64 -march=opteron -mno-3dnow -ggdb -O2 -Wall -I/home/build/GNUstep/Local/Library/Headers -I/home/build/GNUstep/Local/Library/Headers -I/home/build/GNUstep/System/Library/Headers -fgnu-runtime -x objective-c -m64 -L/home/build/GNUstep/Local/Library/Libraries -L/home/build/GNUstep/Local/Library/Libraries -L/home/build/GNUstep/System/Library/Libraries conftest.c -lrt -ldl -lpthread -rdynamic -m64 -fgnu-runtime -L/home/build/GNUstep/Library/Libraries -L/home/build/GNUstep/Local/Library/Libraries -L/home/build/GNUstep/System/Library/Libraries -lobjc -lm
Do I need to build clang with a special option to enable blocks, or should I be linking with another library?
Do I need to build clang with a special option to enable blocks
No. But you may need -fblocks option using the clang binary.
-fblocks
Enable the "Blocks" language feature.
should I be linking with another library?
AFAIK, Yes.
_Block_copy is a part of BlocksRuntime.
BlocksRuntime Block.h
BlocksRuntime runtime.c
Have you compiled compiler-rt? It includes BlocksRuntime. The document explains how to build compiler-rt.

Resources