[Bug fortran/30594] New: Calling inquire (iolength) crashes with -malign-double

[Bug fortran/30594] New: Calling inquire (iolength) crashes with -malign-double

[schnetter at aei dot mpg dot de]

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.


-- 
           Summary: Calling inquire (iolength) crashes with -malign-double
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: schnetter at aei dot mpg dot de
 GCC build triplet: i386-apple-darwin8.8.1
  GCC host triplet: i386-apple-darwin8.8.1
GCC target triplet: i386-apple-darwin8.8.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30594

[Bug fortran/30594] Calling inquire (iolength) crashes with -malign-double

[jvdelisle at gcc dot gnu dot org]

------- Comment #1 from jvdelisle at gcc dot gnu dot org  2007-01-26 03:37 -------
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?


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-01-26 03:37:32
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30594

[Bug fortran/30594] Calling inquire (iolength) crashes with -malign-double

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2007-01-26 03:53 -------
This is not a bug,  -malign-double changes the ABI.  Stop using options that
change the ABI.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30594

[Bug fortran/30594] Calling inquire (iolength) crashes with -malign-double

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2007-01-26 03:54 -------
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. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30594

[Bug fortran/30594] Calling inquire (iolength) crashes with -malign-double

[schnetter at aei dot mpg dot de]

------- Comment #4 from schnetter at aei dot mpg dot de  2007-01-26 14:36 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30594

[Bug fortran/30594] Calling inquire (iolength) crashes with -malign-double

[jvdelisle at gcc dot gnu dot org]

------- Comment #5 from jvdelisle at gcc dot gnu dot org  2007-01-26 16:11 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30594

[Bug fortran/30594] Calling inquire (iolength) crashes with -malign-double

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2007-01-26 17:43 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30594

[Bug fortran/30594] Calling inquire (iolength) crashes with -malign-double

[kargl at gcc dot gnu dot org]

------- Comment #7 from kargl at gcc dot gnu dot org  2007-01-26 18:52 -------
(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. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30594