benchmarking is an artform in and of itself, usually easy to manipulate the results to show whatever you want. I would not expect the compilers to generate the same results except for very small test cases, and sometimes in those small test cases their results are either identical or sometimes vastly different as your test has exposed an optimization that one compiler knows/uses and one the other doesnt.

I used to keep track of such things (compiler performance numbers) with dhrystone for example, but in the case of known benchmarks (not that dhrystone means much anymore, but others) you may find that some compilers are tuning themselves to look good under benchmarks perhaps at the expense of something else.

There is no right answer, there is no universal "best", it is all in the eye of the beholder, you. Which tool is easier for you to use, which do you like better be it for the gui or pretty colors or sound card sounds or whatever. And go from there.

The gnu compiler generally for applications I have tested does not produce code as "fast" which is my benchmark, compared to the others, but there are way more people using the free gnu tools so the support for it is considerably wider due to the number of web pages and forums and examples. gnu wont have a size restriction either, but it may require more learning or whatever to get up and running...

The cortex-ms are split into the armv6m and armv7m families, the v6m (cortex-m0) only have a small number of thumb2 extensions, the armv7m have about 150 thumbv2 extensions to thumb, so you need to know what your tools support and not use the wrong stuff on the wrong chip. Then the compilers if they know all of this may and will produce different instruction mixes from the same source code. Further within the same compiler or family using different command line options you can/will get vastly different code. And then beyond that with a cortex-m4 with cache on if you have one with such a thing, depending on how the code lies in the cache lines you may get vastly different performance, so benchmarking is a research project in itself for each blob of C code you want to benchmark. The performance range within a single compiler may shadow another compiler or the overlap may be enough to not matter.

If you have access to the tools you add value to yourself professionally by learning to use the competing tools and being able to walk into a job and or within your job choose what you see as the right tool for the job or walk into a Kiel house and be able to work right away or a gnu house and work right away. Where you might lose a job if you are gnu only and the job is for a Kiel house.

If you only want to compile programs that run on their own on a processor (“bare metal” system), then all that matters is to have a compiler that produces instructions for that particular processor. “For ARM” is almost enough information, but not quite: you would also need to specify the version of the instruction set. Most ARM processors today are based on the same version (ARMv7) but even inside that there are many complications — some features (e.g. floating point, vector instructions) are optional and you need to specify whether to use them, and ARMv7 has in fact two instruction sets (“normal” ARM, and Thumb). Most distributions of GCC for ARM target ARMv7 with optional features and Thumb enabled by options.

If you want to compile programs that interact with other programs, then all the programs involved need to be able to communicate. Making system calls and, even more so, making library calls requires that the caller and the callee agree on the binary representation of data (e.g. endianness) and on how to pass data around (which registers to use for function arguments, how function calls affect the stack, etc.). The specification of how this works is called an ABI (application binary interface).

The general naming convention for GCC cross-compilers is CPU-VENDOR-SYSTEM-gcc (where the part before -gcc matches the system type of configure), but there is some fuzz about the VENDOR-SYSTEM part. Cross-compilers for ARM are usually called arm-VENDOR-OS-LIBC-ABI-gcc with some of the parts omitted. For example, arm-acme-linux-gnu-gnueabi-gcc would be GCC for ARM (v7 by default), for ACME's distribution of Linux, set to link against Glibc, using the gnueabi ABI. arm-linux-gnu-gcc indicates a compiler set to link against Glibc on Linux, with an unspecified ABI. arm-linux-gcc doesn't specify which libc is targeted.

arm-none-eabi-gcc is a cross-compiler for bare-metal ARM. ARM is the target, the host is the machine you run the compiler on - the development host.

In most cases you would use such a compiler for developing for bare-metal (i.e. no fully featured OS) embedded systems, but equally you could be using it to develop bootstrap code for a desktop system, or developing an operating system (though less likely).

In any event, it is not the compiler that determines if the system is embedded. An embedded system is simply a system running software that is not a general-purpose computer. For example many network routers run on embedded Linux such as OpenWRT and in that case you might use arm-linux-eabi-gcc. What distinguishes it is that it is still a cross-compiler; the host on which you build the code, is not the same machine architecture or OS as that which will run it.

Neither does being a cross-compiler make it "embedded" - it is entirely possible to cross compile Linux executables on Windows or vice versa with neither target being embedded.

The point is, there is no "Embedded C" language, it is all "Regular C". What makes it embedded is the intended target. So don't get hung-up on classification of the toolchain. If you are using it to generate code for embedded systems it is embedded, simple as that. Many years ago I worked on a project that used Microsoft C V6 (normally for MS-DOS) in an embedded system with code on ROM and running VRTX RTOS. Microsoft C was by no definition an embedded systems compiler; the "magic" was done by replacing Microsoft's linker to "retarget" it to produce ROM images rather than a .exe.

There are of course some targets that are invariably "embedded", such as 8051, and a cross-compiler for such a target could be said to be exclusively "embedded" I guess, but it is a distinction that serves little purpose.