http://llvm.org/bugs/show_bug.cgi?id=8652
Summary: -fno-elide-constructors doesn't prevent all elisions
Product: clang
Version: trunk
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P
Component: C++
AssignedTo: [email protected]
ReportedBy: [email protected]
CC: [email protected], [email protected]
I was drafting up a quiz question about C++ copy constructors of the form
"given this program, what does it print?" where the copy ctor keeps a counter
for the number of calls it gets. The point is that copying objects can be
slow, and it's easy to write C++ code that does it if you're not careful.
However, I need to be careful because there are circumstances in which a copy
ctor call can be elided by the standard, even if it has side-effects.
Interestingly, both clang and gcc elide copy constructors regardless of the
optimization level, which is not what I expected. I discovered that gcc has
the -fno-elide-constructors option, which I used to check if my example had
elidable copy constructors by comparing the output of the program with and
without elision. Clang has the same option, but it doesn't seem to work when
applied to my small sample program:
[...@methacholine quiz2]$ cat elision.cpp
#include <iostream>
static int copies = 0;
struct CopyCounter {
CopyCounter() { }
CopyCounter(const CopyCounter &obj) {
copies++;
}
};
CopyCounter foo() {
return CopyCounter();
}
int main(int argc, char **argv) {
CopyCounter a(foo());
std::cout << copies << '\n';
return 0;
}
[...@methacholine quiz2]$ g++ elision.cpp -o elision && ./elision
0
[...@methacholine quiz2]$ g++ -fno-elide-constructors elision.cpp -o elision &&
./elision
2
[...@methacholine quiz2]$ clang++ elision.cpp -o elision && ./elision
0
[...@methacholine quiz2]$ clang++ -fno-elide-constructors elision.cpp -o
elision && ./elision
0
Is this a bug? Is clang missing a check for LangOpts::ElideConstructors
somewhere in CodeGen?
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs