[Bug c++/46143] New: __attribute__((optimize)) emits wrong code

[Bug c++/46143] New: __attribute__((optimize)) emits wrong code

[scovich at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46143

           Summary: __attribute__((optimize)) emits wrong code
           Product: gcc
           Version: 4.5.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: scovich@gmail.com


Created attachment 22129
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22129
Test case showing wrong code with __attribute__((optimize(0)))

Applying '__attribute__((optimize(0)))' to a function causes it to call the
wrong variant/clone of an optimized callee that returns a struct by value.

The attached test case reproduces the problem when compiled with `g++ -O3 -DBUG
bug.cpp' 

The problem seems to be the way gcc optimizes return-by-value. The statement:

iterator it = v.begin()

becomes

tmp = alloca(sizeof(iterator))
vector::begin(tmp, &v)
iterator it(*(iterator*)tmp)

However, gcc actually calls the wrong variant of vector::begin, with the latter
thinking its first argument is &v._M_impl._M_start (an iterator to be copied)
and which has optimized away the struct completely to return only a pointer. It
therefore allocates a temporary and proceeds to "initialize" it using the
(uninitialized) return-value it was passed, then returns the temporary's
contents to the caller (main). As a result, 'it' points to whatever happened to
be on the stack at the time of the call. 

Note that the test case smashes the stack only to make the symptoms consistent;
the bug remains with or without it.

The relevant disassembly follows:

main:
        # call vector::begin(&rval_ptr, &v)
        subq    $24, %rsp        # allocate hidden tmp1
        movq    v(%rip), %rdx
        movq    %rdx, %rsi       # second arg is &v
        movq    %rsp, %rdi       # first arg is &tmp1
        call    _ZNSt6vectorIP3fooSaIS1_EE5beginEv.clone.1
        ...

_ZNSt6vectorIP3fooSaIS1_EE5beginEv.clone.1:
        subq    $24, %rsp        # allocate hidden tmp2
        movq    %rdi, %rsi       # second arg expects &v but gets &tmp1
        movq    %rsp, %rdi       # first arg is &tmp2
        call   
_ZN9__gnu_cxx17__normal_iteratorIPP3fooSt6vectorIS2_SaIS2_EEEC2ERKS3_.clone.0
        movq    (%rsp), %rax     # return the contents of tmp2
        addq    $24, %rsp
        ret

_ZN9__gnu_cxx17__normal_iteratorIPP3fooSt6vectorIS2_SaIS2_EEEC2ERKS3_.clone.0:
        movq    %rsi, (%rdi)     # tmp2 = tmp1
        ret

[Bug c++/46143] __attribute__((optimize)) emits wrong code

[scovich at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46143

Ryan Johnson <scovich at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #22129|0                           |1
        is obsolete|                            |

--- Comment #1 from Ryan Johnson <scovich at gmail dot com> 2010-10-22 22:18:16 UTC ---
Created attachment 22130
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22130
Test case showing wrong code with __attribute__((optimize(0)))

Oops... the previous version had stray marks from emacs+gdb.

[Bug c++/46143] __attribute__((optimize)) emits wrong code

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46143

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-10-22 22:47:09 UTC ---
that program has two kinds of undefined behaviour I can see

not only do two wrongs not make a right, but attribute((optimize(0))) doesn't
make it right either

do you have a testcase that doesn't rely on dereferencing a non-dereferenceable
iterator?

[Bug c++/46143] __attribute__((optimize)) emits wrong code

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46143

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-10-22 22:53:17 UTC ---
here's one which avoids invalid iterators and stack smashing:


#include <cassert>
#include <vector>

struct foo { };
typedef std::vector<foo*> foov;

foov v(1);

int
#ifdef BUG
__attribute__((optimize(0)))
#endif
main() {
    foov::iterator it = v.begin();
    assert( &*it == &v.front() );
    return 0;
}

[Bug c++/46143] __attribute__((optimize)) emits wrong code

[scovich at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46143

--- Comment #4 from Ryan Johnson <scovich at gmail dot com> 2010-10-22 23:06:53 UTC ---
As I said, the stack smashing was only there to make the behavior consistent.
If the offending stack location happens to contain zero, the bug would go
unnoticed (try adding 'long n[1]' as another local, for me it makes the symptom
go away unless the stack smash exposes it.

In any case, here's a minimal testcase which doesn't do anything evil:

#include <vector>
#include <cassert>

typedef std::vector<int> intv;

int
#ifdef BUG
__attribute__((optimize(0)))
#endif
main() {
    intv v;
    intv::iterator it = v.begin();
    assert(it == v.begin());
    return 0;
}

[Bug c++/46143] __attribute__((optimize)) emits wrong code

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46143

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-10-23 07:15:48 UTC ---
This is likely an interaction of pass_return_slot (always run) and pass_nrv
(run at optimize > 0).  It is probably a latent general bug as well.  Does
it work on trunk?

[Bug c++/46143] __attribute__((optimize)) emits wrong code

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46143

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-10-23 15:14:49 UTC ---
my test in comment 3 passes the assertion on trunk, but fails with 4.5.2

[Bug middle-end/46143] __attribute__((optimize)) emits wrong code

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46143

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |8.1.0, 9.1.0
      Known to fail|                            |7.1.0

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Looks fully fixed in GCC 8.

[Bug middle-end/46143] __attribute__((optimize)) emits wrong code

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46143

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |8.0

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Closing as fixed.

[Bug middle-end/46143] __attribute__((optimize)) emits wrong code

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46143
Bug 46143 depends on bug 37565, which changed state.

Bug 37565 Summary: __optimize__  attribute doesn't work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED