Bug 40069 - SIGSEGV in program that uses an inlined operator[] with range checking, only with gcc 2.96 on intel, not on alpha
SIGSEGV in program that uses an inlined operator[] with range checking, only ...
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
7.1
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-10 09:06 EDT by Christoph Karle
Modified: 2007-04-18 12:33 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-05-16 12:44:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
demo source code (1.99 KB, text/plain)
2001-05-10 09:10 EDT, Christoph Karle
no flags Details

  None (edit)
Description Christoph Karle 2001-05-10 09:06:47 EDT
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)
and
  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
intel backend.

How Reproducible:
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
program).

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
     ./inlinebug 

Actual Results:
  0
  Segmentation fault (core dumped)

(the 0 is the index of the vector where the segfault occurs)

Expected Results:
  0
  1
  2
  3
  4

(for a different size of the vector, the result would of course be different)

Additional Information:
Comment 1 Christoph Karle 2001-05-10 09:10:21 EDT
Created attachment 17987 [details]
demo source code
Comment 2 Jakub Jelinek 2001-05-10 10:01:40 EDT
Actually, it seems -fregmove related (-fno-regmove fixes it). Apparently
-fregmove decides to merge a /u register with a changeable one, debugging.
Comment 3 Jakub Jelinek 2001-05-16 12:44:34 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.