Bug 3261

Summary: C++ with -malign-double SEGVs; egcs-c++-1.1.2, RH6.0
Product: [Retired] Red Hat Linux Reporter: jason.wm.mitchell
Component: egcsAssignee: Cristian Gafton <gafton>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: jason.wm.mitchell
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
URL: http://chico.hm.uc.edu/~jmitchel/linux/malign-double/
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-07-30 13:08:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description jason.wm.mitchell 1999-06-04 04:13:13 UTC
The -malign-double switch no longer functions correctly with
egcs-c++-1.1.2. C++ code compiled with this switch, then
linked, SEGVs; dying somewhere in the streams library.  This
is demonstrated with a trivial test program:

        #include <cassert>
        #include <fstream>
        #include <iostream>
        #include <string>

        int main()
          using namespace std;
          string name, value;
          ifstream ifs( "input.dat" );
          assert( ifs.good() );
          while( ifs >> value >> name )
            cout << name << "\t" << value << endl;
          return( 0 );

If -O0 is specified, the SEGV generally occurs in the
istream constructor; on the manipulators flush, width or
precision;  or operator<<(). Specifying -Ox, x > 0, usually
causes SEGV from ifstream::~ifstream(). Linking -static may
prevent the SEGV in some instances with optimization, but I
have not tested this extensively. Since the failure is a
SEGV, there is little guarantee that the location of the
signal will provide useful information

The platforms tested were:

  1.  i686 tweaked RH5.2 (to run egcs/pgcc*-1.1.1) upgraded
to RH6.0
  2.  i486 stock RH5.2 upgraded to RH6.0
  3.  i486 clean install of RH6.0
  4.  i586 clean install of RH6.0

The -malign-double option worked with egcs*-1.1.1.

There is no apparent negative effect on plain C code
compiled with the -malign-double switch.

The test program and input data file, a makefile, verbose
assembler with diffs, egcs-c++-1.1.2 -v -a output(make.out),
and this description are available from:



------- Additional Comments From   06/04/99 16:39 -------
I failed to specify that -malign-double option worked with egcs*-1.1.1
on RedHat 5.2 with glibc-2.1-0.990222, binutils-, and

Comment 1 Jay Turner 1999-06-29 11:55:59 UTC
This issue has been forwarded to a developer for further action.

Comment 2 Cristian Gafton 1999-07-28 06:27:59 UTC
*** This bug has been marked as a duplicate of 3777 ***

Comment 3 Jim Kingdon 1999-07-30 13:06:59 UTC
Cristian, did you have any reason for marking this as a duplicate
of 3777?  As nearly as I can tell, the two have nothing to do with
each other.

Comment 4 Jim Kingdon 1999-07-30 13:08:59 UTC
Changing the setting of -malign-double changes the calling
conventions; therefore you must recompile all libraries if
you use this option.  From the manual:

     *Warning:* if you use the `-malign-double' switch, structures
     containing the above types will be aligned differently than the
     published application binary interface specifications for the

Comment 5 Anonymous 1999-07-30 13:31:59 UTC
[Re: alignment differences from pub'ed ABI]

I am/was fully aware of this, but I don't think it makes any
difference to the problem.  The difficulty is that in my original 5.2
configuration, -malign-double worked fine, and provided some
significant performance improvements, since my apps are all FP
intensive.  When I attempted the 6.0 upgrade (several ways), it failed
miserably, even on simple test programs which I provided links to for
any investigator's convenience.

I think a resolution of DISGARD is an ineffective solution based on
assuming that a warning negates use of the option.  For me, it means a
difference of waiting an extra hour or so for each of my runs;
consider that I have about 4 * 64 individual programs that must run
for a complete data set.

I hope you will reconsider this resolution.