Description of Problem:
SIGSEGV occurs in a programm that uses a selfmade vector class for
complex<double> with an inline index operator with range checking.
the segfault does not occur directly in the index operator, but in
complex<double>::operator *= , which calls a __doaml() function, where
the segfault occurs in the first fldl machine instruction (at least gdb
says so). it seems that the address which fldl wants to access is illegal.
the segfault only occurs with range checking enabled (through a define)
operator inlined, -O2 or -O3
operator not inlined, -O3
and NOT with
operator inlined, -O2/-O3 and -fno-inline
operator not inlined, -O3 -fno-inline or -O2
it only occurs on intel with gcc 2.96 (i tried both rh 7.0 and 7.1).
on an ev67 alpha with rh 7.0 and gcc 2.96 everything is ok,
also with gcc 2.91.66 on intel.
this suggests that the problem is in the inline code generation in the
when the attached source code is compiled with gcc 2.96 on intel and
-O2 or -O3, the resulting program always aborts with a segfault.
slight changes in the operator (for example throwing an exception
instead of a cout/printf), or in the calculation that is done with the
vectors can prevent the segfault (more comments on this in the attached
Steps to Reproduce:
1. make sure VECTOR_DEBUG is defined in the source code
2. compile the program with
g++ -O2 inlinebug.cpp -o inlinebug
3. exectute the program with
Segmentation fault (core dumped)
(the 0 is the index of the vector where the segfault occurs)
(for a different size of the vector, the result would of course be different)
Created attachment 17987 [details]
demo source code
Actually, it seems -fregmove related (-fno-regmove fixes it). Apparently
-fregmove decides to merge a /u register with a changeable one, debugging.
Ouch, forgot to update status here:
I've fixed this with http://gcc.gnu.org/ml/gcc-patches/2001-05/msg00581.html
and it will be included in gcc-2.96-86.