Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
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:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-07-30 13:08:35 UTC


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.