https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70678
Bug ID: 70678
Summary: Static function compilation behaviour changes with
__attribute__((optimize("O2"))) even if already
compiling with -O2
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lutoma at ohai dot su
Target Milestone: ---
Noticed this while tracking down another issue. I have seen this on GCC 4.6.4
and 5.3.0.
#include <stdio.h>
#include <stdlib.h>
static void test_function() {
printf("Hello world!\n");
}
int main() {
test_function();
return EXIT_SUCCESS;
}
Compiled using "gcc -o test test.c -O2 -save-temps -Wall -Wextra
-fno-strict-aliasing -fwrapv", GCC will optimize the test_function() by
including it into main().
If the function definition is changed to
static void __attribute__((optimize("O2"))) test_function() {
and the file is compiled using the same command, the test_function() will stay
separate, and is not optimized into main(), even though the optimization levels
have not changed.
Intermediate with the additional optimize attribute:
https://gist.githubusercontent.com/lutoma/b36eda746d618c2e5f8b0e28e1478b34/raw/a9ce9f8d23f954a112a911621e3e3c10d3a1f307/test.i
Intermediate without the additional attribute:
https://gist.githubusercontent.com/lutoma/ac300f0349be4e4de15a4709813e17f0/raw/4b193c8d2aca363c26a0241ad6d7a821427593a5/test.i
Generated assembly for the functions:
Without extra optimize attribute:
00000000004003f0 <main>:
4003f0: 48 83 ec 08 sub rsp,0x8
4003f4: bf 94 05 40 00 mov edi,0x400594
4003f9: e8 c2 ff ff ff call 4003c0 <puts@plt>
4003fe: 31 c0 xor eax,eax
400400: 48 83 c4 08 add rsp,0x8
400404: c3 ret
[…]
With the extra attribute:
0000000000400506 <test_function>:
400506: bf 94 05 40 00 mov edi,0x400594
40050b: e9 b0 fe ff ff jmp 4003c0 <puts@plt>
00000000004003f0 <main>:
4003f0: 48 83 ec 08 sub rsp,0x8
4003f4: 31 c0 xor eax,eax
4003f6: e8 0b 01 00 00 call 400506 <test_function>
4003fb: 31 c0 xor eax,eax
4003fd: 48 83 c4 08 add rsp,0x8
400401: c3 ret
[…]
Sorry if this is a duplicate or intended/undefined behaviour in some way.
Cheers,
Lukas
