Summary: | __attribute__((optimize)) emits wrong code | ||
---|---|---|---|
Product: | gcc | Reporter: | Ryan Johnson <scovich> |
Component: | middle-end | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | rguenth |
Priority: | P3 | Keywords: | wrong-code |
Version: | 4.5.1 | ||
Target Milestone: | 8.0 | ||
Host: | Target: | ||
Build: | Known to work: | 8.1.0, 9.1.0 | |
Known to fail: | 7.1.0, 7.5.0 | Last reconfirmed: | |
Bug Depends on: | 37565 | ||
Bug Blocks: | |||
Attachments: |
Test case showing wrong code with __attribute__((optimize(0)))
Test case showing wrong code with __attribute__((optimize(0))) |
Created attachment 22130 [details]
Test case showing wrong code with __attribute__((optimize(0)))
Oops... the previous version had stray marks from emacs+gdb.
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? 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; } 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; } 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? my test in comment 3 passes the assertion on trunk, but fails with 4.5.2 Looks fully fixed in GCC 8. Closing as fixed. |
Created attachment 22129 [details] 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