This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/50734] New: const and pure attributes don't have the effect as in C


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: unassigned@gcc.gnu.org
        ReportedBy: drepper.fsp@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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]