Bug 30594 - Calling inquire (iolength) crashes with -malign-double
Summary: Calling inquire (iolength) crashes with -malign-double
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-26 01:36 UTC by Erik Schnetter
Modified: 2007-01-26 18:52 UTC (History)
1 user (show)

See Also:
Host: i386-apple-darwin8.8.1
Target: i386-apple-darwin8.8.1
Build: i386-apple-darwin8.8.1
Known to work:
Known to fail:
Last reconfirmed: 2007-01-26 03:37:32


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Schnetter 2007-01-26 01:36:09 UTC
With GNU Fortran 95 (GCC) 4.3.0 20070125 (experimental), the programme

      program main
      integer size
      integer*1 var
      open (10, file="conftestval", status="unknown")
      inquire (iolength=size) var
      write (10, *) size
      close (10)
      end

compiled with the options

/Users/eschnett/gcc/bin/gfortran -o conftest conftest.f -malign-double

leads to a bus error:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00002ff8
0x0025ca38 in *__gfortran_st_iolength (dtp=0xbffff0c0) at /Users/eschnett/src/gcc/libgfortran/io/transfer.c:2630
2630        *dtp->iolength = 0;

The problem seems to be that struct st_parameter_dt changes its layout depending on whether -malign-double is in effect or not, making the compiled programme incompatible with the run-time library.

I see two solutions: Either this struct should be modified so that it is independent of -malign-double, or the compiler should take special measures when building the tree for this structure, making sure to use standard alignments.  Since I don't know how to build trees with non-standard alignments, I will send a patch that permutes the elements st_parameter_dt.
Comment 1 Jerry DeLisle 2007-01-26 03:37:32 UTC
I can reproduce this on non-darwin machine.  Erik you were going to suggest a patch?  If you want, I will review this for you.  I wonder if this is related to changes I made to allow large iolengths, ie 64-bit integers?

Comment 2 Andrew Pinski 2007-01-26 03:53:21 UTC
This is not a bug,  -malign-double changes the ABI.  Stop using options that change the ABI.
Comment 3 Andrew Pinski 2007-01-26 03:54:40 UTC
Please read the documentation about options like this, they explictly warn they change the ABI.

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 and will not be binary compatible with structures in code compiled without that switch. 
Comment 4 Erik Schnetter 2007-01-26 14:36:33 UTC
I have read the documentation, and I understand what the option does.  I compile my complete programme and all its libraries with this option.

It was my assumption that the compiler would create working code with and without this option, that is, that the run-time library could handle both cases.  My patch would change the run-time library so that this is indeed the case for inquire(iolength).

Creating a run-time library that works with -malign-double is certainly possible; the question is whether the additional work is deemed worthwhile.  Looking on the web, most numerical benchmarks use -malign-double on the i386.  At the same time I see many complaints from people who use this option without knowing what it does and reporting spurious errors, which is a maintenance burden.  I realise that any bug report concerning -malign-double must hit a sore spot with you.

If -malign-double is really unsupported, then the documentationcould be changed to include a warning sentence like: "Calling standard library routines is not supported when this option is used.  Your program may segfault randomly or silently produce wrong results."  As it, I honestly interpreted the documentation as saying that one is safe if (a) the whole programme is compiled with this option, and (b) no structure involved in library calls contains double, long double, or long long.
Comment 5 Jerry DeLisle 2007-01-26 16:11:16 UTC
I understand Erik's concern.  -malign-double makes a significant performance difference on some of these machines and is commonly used.

The surest way to handle this is to put compute intensive code in separate files and create libraries that have no I/O involved.  Then the driver routines that have the I/O can be compiled separately without any concern and link the compute routines in.

I am interested to have a look at the patch Erik is proposing to see how intrusive it is.  It may be suitable for '4.3 only' as an enhancement.  I think we have bumped the library version already on 4.3.
Comment 6 Andrew Pinski 2007-01-26 17:43:32 UTC
(In reply to comment #4)
> I have read the documentation, and I understand what the option does.  I
> compile my complete programme and all its libraries with this option.

You did not compile libc or libm with the option or anyother system library so really you will get invalid results there.  You need to compile your whole system including all of GCC's library with the option to get valid results.

> I understand Erik's concern.  -malign-double makes a significant performance
> difference on some of these machines and is commonly used.

Yes but the ABI says doubles can only be aligned word wise.  

I am sorry to that the ABI sucks but guess what complain to AT&T for creating a sucky ABI.  And complain to Intel/AMD for not having hardware that supports loading double aligned only on the word boundry, even IBM makes those now.
Comment 7 kargls 2007-01-26 18:52:55 UTC
(In reply to comment #4)
> I have read the documentation, and I understand what the option does.  I
> compile my complete programme and all its libraries with this option.

You did not compile all of the needed libraries with -malign-double.
You'll need to recompile at least libgfortran with this option and
maybe libgcc, and if you use OpenMP you may need to recompile libgomp.