Bug 3261 - C++ with -malign-double SEGVs; egcs-c++-1.1.2, RH6.0
Summary: C++ with -malign-double SEGVs; egcs-c++-1.1.2, RH6.0
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: egcs
Version: 6.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL: http://chico.hm.uc.edu/~jmitchel/linu...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-06-04 04:13 UTC by jason.wm.mitchell
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 1999-07-30 13:08:35 UTC
Embargoed:


Attachments (Terms of Use)

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:

  http://chico.hm.uc.edu/~jmitchel/linux/malign-double/

-jason


------- 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-2.9.1.0.23-1, and
libstdc++-2.9.0-7.

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
386.

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.

-Jason


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