http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50734
Bug #: 50734
Summary: const and pure attributes don't have the effect as in
C
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: drepper....@gmail.com
When the const and pure function attributes are used the compiler doesn't
generate the same code for C++ as for C. Take this code:
extern int *f() __attribute__((pure));
int g(int *a) {
int s = 0;
for (int n = 0; n < 100; ++n)
s += f()[a[n]];
return s;
}
When compiled as C code the call to 'f' is hoisted out of the loop. Similarly
when const instead of pure is used. One can also define 'f' as extern "C"
without changing the result:
0000000000000000 <_Z1gPi>:
0: 41 54 push %r12
2: 49 89 fc mov %rdi,%r12
5: 55 push %rbp
6: 31 ed xor %ebp,%ebp
8: 53 push %rbx
9: 31 db xor %ebx,%ebx
b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
10: e8 00 00 00 00 callq 15 <_Z1gPi+0x15>
11: R_X86_64_PC32 f-0x4
15: 49 63 14 1c movslq (%r12,%rbx,1),%rdx
19: 48 83 c3 04 add $0x4,%rbx
1d: 03 2c 90 add (%rax,%rdx,4),%ebp
20: 48 81 fb 90 01 00 00 cmp $0x190,%rbx
27: 75 e7 jne 10 <_Z1gPi+0x10>
29: 5b pop %rbx
2a: 89 e8 mov %ebp,%eax
2c: 5d pop %rbp
2d: 41 5c pop %r12
2f: c3 retq
Versus the C code:
0000000000000000 <g>:
0: 53 push %rbx
1: 31 c0 xor %eax,%eax
3: 48 89 fb mov %rdi,%rbx
6: e8 00 00 00 00 callq b <g+0xb>
7: R_X86_64_PC32 f-0x4
b: 31 d2 xor %edx,%edx
d: 31 c9 xor %ecx,%ecx
f: 90 nop
10: 48 63 34 13 movslq (%rbx,%rdx,1),%rsi
14: 48 83 c2 04 add $0x4,%rdx
18: 03 0c b0 add (%rax,%rsi,4),%ecx
1b: 48 81 fa 90 01 00 00 cmp $0x190,%rdx
22: 75 ec jne 10 <g+0x10>
24: 89 c8 mov %ecx,%eax
26: 5b pop %rbx
27: c3 retq
When the very same code is compiled with the C++ compiler the call stays in the
loop.
Should there be a reason for this (which I cannot see, these are extensions and
gcc is not limited by a standard) the compiler should issue a warning and there
should be a way to get the behavior we get with the C compiler.
I checked this with the current Fedora x86-64 compiler
gcc version 4.6.1 20110908 (Red Hat 4.6.1-9) (GCC)
This is most probably architecture-independent.
