Bug 3261 - C++ with -malign-double SEGVs; egcs-c++-1.1.2, RH6.0
C++ with -malign-double SEGVs; egcs-c++-1.1.2, RH6.0
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: egcs (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
http://chico.hm.uc.edu/~jmitchel/linu...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-06-04 00:13 EDT by jason.wm.mitchell
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-07-30 09:08:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description jason.wm.mitchell 1999-06-04 00:13:13 EDT
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 07:55:59 EDT
This issue has been forwarded to a developer for further action.
Comment 2 Cristian Gafton 1999-07-28 02:27:59 EDT
*** This bug has been marked as a duplicate of 3777 ***
Comment 3 Jim Kingdon 1999-07-30 09:06:59 EDT
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 09:08:59 EDT
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 09:31:59 EDT
[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.