[Bug c++/33599] segfault in program compiled by g++ 4.2, corrupted reference
--- Comment #1 from jacob at math dot jussieu dot fr 2007-09-30 08:57 --- Created an attachment (id=14271) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14271action=view) The archive allowing to reproduce the bug. Of course, I forgot the attachment :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33599
[Bug c++/33599] segfault in program compiled by g++ 4.2, corrupted reference
--- Comment #2 from jacob at math dot jussieu dot fr 2007-09-30 09:16 --- Here are some thoughts about why it is so fast with g++-4.2, perhaps related to why it segfaults. My library is an Expression Templates library. So when you do m1+m2 with matrices m1 and m2, instead of computing the sum of these two matrices, it constructs a new object of type (roughly) SumMatrix,Matrix and passes to its contructor references to m1 and m2. So when you do m3=m1+m2 it (roughly) calls Matrix::operator=(Sum) which calls Sum...::read() to evaluate the entries in the matrix sum. It is very important that the compiler be clever enough to understand that the objects of type Sum... are short-lived, so it doesn't need to emit any code for them in the final binary. g++ 4.1 didn't understand that, so it produced slow code. g++ 4.2 understands that, so it optimizes accordingly. That explains why 4.2 produces 4x faster code in my benchmarks. But I am afraid that I might be hitting a bug in this optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33599
[Bug c++/33599] segfault in program compiled by g++ 4.2, corrupted reference
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-30 11:37 ---
The usual error that happens with expression templates is that you return a
reference to a temporary object, using it after its lifetime ended. What
you then can observe is that if you inline enough the error goes away.
But this is just a wild guess. Instead you need to track this down further
to a smaller testcase (without the complete expression template machinery).
Oh, and the testcase crashes with -O2 for me; with gcc 4.0, 4.1, 4.2 and trunk.
It doesn't build with 3.4, so I didn't verify there. It already crashes with
void matrixOps()
{
EiMatrixint, 2, 3 a, b;
a = a + b;
}
my bet would be a bug in your code.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33599
[Bug c++/33599] segfault in program compiled by g++ 4.2, corrupted reference
--- Comment #4 from jacob at math dot jussieu dot fr 2007-09-30 13:47 --- I had tried to make a shorter testcase but didn't find any that caused a crash. But yes, the shorter testcase that you found indeed causes a crash here. With both 4.1 and 4.2. So indeed, that's probably a bug in my own code, and at least it's not a regression from 4.1 to 4.2. Thanks for your help and sorry for the false alert! While I'm there, I'd like to draw your attention on the following fact. As I said, with my library's benchmark, 4.2 produces much faster code than 4.1. But trunk produces slower code than 4.2 does (almost as slow as 4.1). Is this normal, given that this is a development version? Or is that a regression worth reporting a bug against trunk/4.3 ? More precisely, here are the execution times of our benchmark with various versions of g++: g++-4.1: 21s g++-4.2: 4s g++-4.3: 15s (8s with -fforce-addr) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33599
[Bug c++/33599] segfault in program compiled by g++ 4.2, corrupted reference
--- Comment #5 from jacob at math dot jussieu dot fr 2007-09-30 14:58 --- OK, found it, it was a very stupid error by me. Declared the matrix's array with the wrong size, so some write eventually wrote outside of the matrix's array, thus overwriting a reference. Closing the bug report (but still interested in your thoughts in the 4.3 speed regression, cf. previous comment). -- jacob at math dot jussieu dot fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33599
[Bug c++/33599] segfault in program compiled by g++ 4.2, corrupted reference
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-09-30 16:05 --- Well, the speed regression is certainly not welcome. So, if you have a testcase that shows this you might want to open a new bugreport. A plus, if you can identify the single(?) hot loop that executes slower and compare assembler output for it - maybe there's something obvious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33599
[Bug c++/33599] segfault in program compiled by g++ 4.2, corrupted reference
--- Comment #7 from jacob at math dot jussieu dot fr 2007-09-30 16:41 --- OK, the person who reported the speed regression with g++-4.3 (Michael Olbrich) will open a bug report. I don't actually have g++-4.3 compiled so I'm not the right person to do so. Thanks, Benoit -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33599
