Bug 40069

Summary: SIGSEGV in program that uses an inlined operator[] with range checking, only with gcc 2.96 on intel, not on alpha
Product: [Retired] Red Hat Linux Reporter: Christoph Karle <karle>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: high Docs Contact:
Priority: medium    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-05-16 16:44:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
demo source code none

Description Christoph Karle 2001-05-10 13:06:47 UTC
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 13:10:21 UTC
Created attachment 17987 [details]
demo source code

Comment 2 Jakub Jelinek 2001-05-10 14:01:40 UTC
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 16:44:34 UTC
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.