**gcc version 6.2.1 20160830 [gcc-6-branch revision 239856] (SUSE Linux) **
Using the following source code with that compiler,
-rw-rw-r–. 1 leslie leslie **25535 **Nov 11 19:55 fstabxref.c
-rw-rw-r–. 1 leslie leslie 25535 Nov 11 19:55 lsblkexperimental.c
when compiled
-rwxr-xr-x 1 leslie leslie 36848 Nov 12 08:37 fstabxref
-rwxr-xr-x 1 leslie leslie 40952 Nov 12 08:37 lsblkexperimental
By the way, the second source file is identical to the first.
With another gcc (from Fedora 24) and the identical source code from the identical directories
Why is there 4k and 6k extras in the executable code? I used vi to view the fstabxref executable and that code has much of the commented front end of the /* source code in it’s header. */
I am using Tumbleweed, rolling release, and its current (Yesterday, full update, including kernel). I tried zypper to remove gcc, and then zypper install gcc.
As I mentioned. I have about 100 lines of documentation before my first line of C code. Those lines appear in the executable near the beginning of the executable.
My process is to
a) compile all necessary object files
b) create a library with “AR” and the objects from a)
c) Link the current compile using that library.
Need to check all the GCC 6 compiler options – I suspect that you have tripped over a “new” GCC 6 feature which wasn’t present in the previous releases.
Are OK for “older” (GCC 4.8) compilers – for GCC 6 “-O3” performs optimisation as follows:
Optimize yet more. -O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-loop-vectorize, -ftree-loop-distribute-patterns, -fsplit-paths -ftree-slp-vectorize, -fvect-cost-model, -ftree-partial-pre and -fipa-cp-clone options.
I’m currently installing the KDE Development world (mostly GCC 48 (default) but, with GCC 6 also being installed) into my Leap 42.2 RC2 VM – will check your issues . . .
By the way, I normally use the following GCC compiler options:
Warnings: -Wall -Wextra -Wformat=2
Machine: -m64 -mtune=generic
With YaST: search for gcc6 – remove the GCC 6 packages; search for gcc – install the GCC 4.8 or GCC 5 packages as you need.
[HR][/HR]It’s not a bug, it’s a feature!
test001@linux-o020:~/Projekte/LinuxSystem> l -h GCC-*/
GCC-4.8/:
insgesamt 56K
drwxr-xr-x 2 test001 users 68 14. Nov 17:08 ./
drwxrwx--- 7 test001 users 99 14. Nov 17:07 ../
-rwxr-xr-x 1 test001 users 14K 14. Nov 17:06 posix_perror*
-rwxr-xr-x 1 test001 users 19K 14. Nov 17:06 posix_strerror*
-rwxr-xr-x 1 test001 users 18K 14. Nov 17:06 posix_syslog*
GCC-6/:
insgesamt 56K
drwxr-xr-x 2 test001 users 68 14. Nov 17:01 ./
drwxrwx--- 7 test001 users 99 14. Nov 17:07 ../
-rwxr-xr-x 1 test001 users 15K 14. Nov 16:55 posix_perror*
-rwxr-xr-x 1 test001 users 20K 14. Nov 16:55 posix_strerror*
-rwxr-xr-x 1 test001 users 20K 14. Nov 16:55 posix_syslog*
test001@linux-o020:~/Projekte/LinuxSystem>
Yes, the GCC 6 executables have about 1K more data that the GCC 4.8 executables compiled from the same “C” code.
KDevelop5 – CMake report with GCC 6 active:
/home/test001/Projekte/LinuxSystem/ErrorHandling/build> /usr/bin/cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE=Debug /home/test001/Projekte/LinuxSystem/ErrorHandling
-- CMake Version: 3.5.2
-- Default C Compiler:
-- Default C++ Compiler:
-- Project C Compiler: /usr/bin/gcc-6
-- Project C++ Compiler: /usr/bin/g++-6
-- Host System: Linux-4.4.27-2-default x86_64
-- Top Level Project Name: ErrorHandling
-- Binaries Directory: /home/test001/Projekte/LinuxSystem/ErrorHandling/build
-- Source Directory: /home/test001/Projekte/LinuxSystem/ErrorHandling
-- Build type: Debug
-- C Compiler Debug Flags: -g
-- C++ Compiler Debug Flags: -g
-- Linker Debug Flags:
[HR][/HR]But, neither “od -a” nor “vi” reveal any C-source header text in the ELF 64-bit executables noted below:
test001@linux-o020:~/Projekte/LinuxSystem> file GCC-4.8/posix_perror GCC-6/posix_perror
GCC-4.8/posix_perror: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.0.0, BuildID[sha1]=8eec8f556ae444943ea1a10bad8d24fe3473483e, not stripped
GCC-6/posix_perror: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.0.0, BuildID[sha1]=9832ccac1a8ff23e005564f56241deafe294d48a, not stripped
test001@linux-o020:~/Projekte/LinuxSystem>
[HR][/HR]Conclusion: yes, given the same compiler options, GCC 6 seems to generate marginally larger ELF executable files than those generated by GCC 4.8.
Why, no idea – it does – it’s a feature!!!
[HR][/HR]As far as I can see, there’s also nothing here: <https://gcc.gnu.org/gcc-6/changes.html>
Using either the “-Os” or “-O2” compiler options are the default methods for producing the smallest executable code size.
[HR][/HR]Please be aware that, even a compiler such as GCC cannot perform “magic” – it only a performs (a rather complicated) “best effort” to produce the best possibly runtime executable image from the code supplied by the programmers.
The golden rule is:
“First compile, debug and analyse the runtime behaviour without any compiler optimisations; only when it has been demonstrated that, the code base performs well and behaves as expected, enable the compiler optimisations and check for possible improvements.”
devel:gcc: 6.2.1 (r241818) – committed 12 days ago.
One could switch to the “devel:gcc” repository, which is, as the name suggests, a preview of a future Factory Release. But, in doing so there is no guarantee that, unexpected pre-release issues will occur.
[HR][/HR]BTW: have you taken a look at the following GCC page? <https://gcc.gnu.org/gcc-6/porting_to.html>
