GCC Bugzilla has been upgraded from version 4.4.9 to 5.0rc3. If you see any problem, please report it to bug 64968.
Bug 15234 - [4.0 regression] libgfortran doesn't compile on Tru64 UNIX V4.0F
Summary: [4.0 regression] libgfortran doesn't compile on Tru64 UNIX V4.0F
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libfortran (show other bugs)
Version: tree-ssa
: P2 normal
Target Milestone: 4.2.0
Assignee: Rainer Orth
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords: build, patch
: 24391 (view as bug list)
Depends on:
Blocks: 14325 15235 16991 19292 21950
  Show dependency treegraph
 
Reported: 2004-04-30 19:02 UTC by Rainer Orth
Modified: 2006-02-14 17:52 UTC (History)
4 users (show)

See Also:
Host:
Target: alpha-dec-osf4.0f
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-02-14 17:32:15


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Orth 2004-04-30 19:02:36 UTC
Bootstrapping the current tree-ssa branch with gmp 4.1.3 (and thus gfortran
enabled) on Tru64 UNIX V5.1B fails compiling libgfortran/runtime/environ.c:

In file included from /vol/gnu/src/gcc/gcc-tree-ssa-dist/libgfortran/runtime/environ.c:26:
/vol/gnu/src/gcc/gcc-tree-ssa-dist/libgfortran/libgfortran.h:75: error: parse error before "GFC_INTEGER_4"

This happens because there is no definition of int32_t and similar types
anywhere.  While there is one in <inttypes.h> and there's even a configure
test for that header, it isn't used anywere.

Obviously, libgfortran needs to make sure that a definition of those types
is available at configure time and provide one itself if not.

While a trivial patch to use that file in libgfortran.h gets me a little
bit further, I immediately hit another error:

/vol/gnu/src/gcc/gcc-tree-ssa-dist/libgfortran/runtime/../io/io.h:282: error: conflicting types for 'unit_t'
/vol/gcc/obj/gcc-3.5-tree-ssa-20040429/5.1b-gcc/gcc/include/sys/types.h:595: error: previous declaration of 'unit_t' was here

In fact, AFAIK the *_t types are reserved by POSIX.1 and thus cannot be
used without risk of conflict.

Environment:
System: OSF1 bartok V5.1 2650 alpha
Machine: alpha
	
host: alpha-dec-osf5.1b
build: alpha-dec-osf5.1b
target: alpha-dec-osf5.1b
configured with: /vol/gnu/src/gcc/gcc-tree-ssa-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build alpha-dec-osf5.1b --target alpha-dec-osf5.1b --disable-libmudflap --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3

How-To-Repeat:
Try bootstrapping the tree-ssa branch on Tru64 UNIX V5.1B with gmp.
Comment 1 Rainer Orth 2004-04-30 19:02:36 UTC
Fix:
Fri Apr 30 21:01:32 2004  Rainer Orth  <ro@TechFak.Uni-Bielefeld.DE>

	* libgfortran.h [HAVE_INTTYPES_H]: Include <inttypes.h> if
	available.

Index: libgfortran.h
===================================================================
RCS file: /vol/gnu/src/gcc/.gcc-cvs/gcc/libgfortran/Attic/libgfortran.h,v
retrieving revision 1.1.2.7
diff -u -p -r1.1.2.7 libgfortran.h
--- libgfortran.h	30 Nov 2003 17:24:21 -0000	1.1.2.7
+++ libgfortran.h	30 Apr 2004 18:55:47 -0000
@@ -43,6 +43,10 @@ Boston, MA 02111-1307, USA.  */
 #include <stdint.h>
 #endif
 
+#if HAVE_INTTYPES_H
+#include <inttypes.h>
+#endif
+
 #if HAVE_SYS_TYPES_H
 #include <sys/types.h>
 #endif
Comment 2 Andrew Pinski 2004-04-30 19:06:58 UTC
Confirmed.
Comment 3 CVS Commits 2004-05-07 09:02:58 UTC
Subject: Bug 15234

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	tree-ssa-20020619-branch
Changes by:	steven@gcc.gnu.org	2004-05-07 09:02:49

Modified files:
	libgfortran    : ChangeLog libgfortran.h 

Log message:
	PR libfortran/15234
	* libgfortran.h: Include <inttypes.h> if available.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=tree-ssa-20020619-branch&r1=1.1.2.49&r2=1.1.2.50
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/libgfortran.h.diff?cvsroot=gcc&only_with_tag=tree-ssa-20020619-branch&r1=1.1.2.7&r2=1.1.2.8

Comment 4 Steven Bosscher 2004-05-07 09:09:30 UTC
Should be fixed now. 
Comment 5 Steven Bosscher 2004-05-07 09:11:32 UTC
Rainer, the unit_t thing is for post-merge.  
Comment 6 Rainer Orth 2004-05-10 13:58:59 UTC
Subject: Re:  [tree-ssa] libgfortran doesn't compile on Tru64 UNIX

steven at gcc dot gnu dot org writes:

> Rainer, the unit_t thing is for post-merge.  

Ok, but in this case the PR should remain open since this is its main
issue.  (I cannot do this right now since gcc.gnu.org isn't reachable.)

Maybe one can solve this once and for all by a mechanical renaming of the
affected types from <something>_t to gfc_<something>_t?

	Rainer

Comment 7 Rainer Orth 2004-05-10 13:59:25 UTC
Subject: Re:  [tree-ssa] libgfortran doesn't compile on Tru64 UNIX

steven at gcc dot gnu dot org writes:

> Should be fixed now. 

The <inttypes.h> part is indeed, thanks.

	Rainer
Comment 8 Rainer Orth 2004-05-10 14:09:12 UTC
Primariy problem (unit_t conflict with system headers) not fixed yet.
Comment 9 Tobias Schlüter 2004-05-14 19:00:03 UTC
Patch here: http://gcc.gnu.org/ml/fortran/2004-05/msg00158.html
Comment 10 CVS Commits 2004-05-15 20:44:40 UTC
Subject: Bug 15234

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	tobi@gcc.gnu.org	2004-05-15 20:44:38

Modified files:
	libgfortran    : ChangeLog 
	libgfortran/io : backspace.c close.c endfile.c inquire.c io.h 
	                 open.c rewind.c transfer.c unit.c unix.c 

Log message:
	PR fortran/15234
	* io/io.h (unit_t): Rename to ...
	(gfc_unit) ... this.
	(unit_root, current_unit, find_file, find_unit, get_unit): Now
	of type gfc_unit.
	(delete_file, insert_unit, close_unit): Argument now of type
	gfc_unit.
	* backspace.c (st_backspace), close.c (st_close), endfile.c
	(st_endfile), inquire.c (inquire_via_unit, st_inquire), open.c
	(test_endfile, edit_modes, new_unit, already_open, st_open),
	rewind.c (st_rewind), transfer.c (current_unit), unit.c
	(internal_unit, unit_cache, rotate_left, rotate_right, insert,
	insert_unit, delete_root, delete_treap, delete_unit, find_unit,
	get_unit, init_units, close_unit), unix.c (find_file0,
	find_file, delete_file): Replace all occurences of unit_t by
	gfc_unit.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.7&r2=1.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/backspace.c.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/close.c.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/endfile.c.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/inquire.c.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/io.h.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/open.c.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/rewind.c.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unit.c.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcc&r1=1.2&r2=1.3

Comment 11 Tobias Schlüter 2004-05-15 20:47:56 UTC
Can you please verify that your problem is fixed, Rainer? Danke.
Comment 12 Rainer Orth 2004-05-17 13:41:15 UTC
Subject: Re:  [gfortran] libgfortran doesn't compile on Tru64 UNIX

tobi at gcc dot gnu dot org writes:

> Can you please verify that your problem is fixed, Rainer? Danke.

Mainline bootstrap on alpha-dec-osf4.0f in progress ...

	Rainer
Comment 13 Rainer Orth 2004-05-17 16:08:02 UTC
Subject: Re:  [gfortran] libgfortran doesn't compile on Tru64 UNIX

tobi at gcc dot gnu dot org writes:

> Can you please verify that your problem is fixed, Rainer? Danke.

Bootstrap on alpha-dec-osf4.0f still fails, but for the other problem
originally reported in this PR: there's no definition of int64_t
etc. anywhere, and (unlike Tru64 UNIX V5.1B) there's no <inttypes.h> (well,
there's <db.h> for Compaq's version of Berkeley DB, but it doesn't make
sense to include that header just because it happens to define the required
types), so compilation still fails.

I'm now running another bootstrap on alpha-dec-osf5.1b to see if at least
the unit_t problem is fixed there.

	Rainer
Comment 14 Rainer Orth 2004-05-17 19:10:40 UTC
Subject: Re:  [gfortran] libgfortran doesn't compile on Tru64 UNIX

Bootstrap on alpha-dec-osf5.1b doesn't succeed either, but this time it's a
different failure:

/vol/gnu/src/gcc/gcc-dist/libgfortran/intrinsics/associated.c:26: error: parse error before numeric constant

This happens because <sys/types.h> has

#define TRUE 1
#define FALSE 0

so we get

enum { 0 = 0, 1 = 1 };

But even with the obvious patch below, I run into another error:

/vol/gnu/src/gcc/gcc-dist/libgfortran/generated/exp_c4.c:29: error: conflicting types for 'cabsf'
/vol/gcc/obj/gcc-3.5.0-20040517/5.1b-gcc/gcc/include/math.h:315: error: previous declaration of 'cabsf' was here
make[3]: *** [exp_c4.lo] Error 1

I.e.

GFC_REAL_4 cabsf (GFC_COMPLEX_4 z); 

vs.

extern float cabsf ( float, float );

This is similar to PR libfortran/15266, which isn't fixed yet, either.

	Rainer


Mon May 17 20:56:21 2004  Rainer Orth  <ro@TechFak.Uni-Bielefeld.DE>

	* intrinsics/associated.c: Renamed FALSE, TRUE to GFC_FALSE,
	GFC_TRUE.

Index: intrinsics/associated.c
===================================================================
RCS file: /cvs/gcc/gcc/libgfortran/intrinsics/associated.c,v
retrieving revision 1.2
diff -u -p -r1.2 associated.c
--- intrinsics/associated.c	13 May 2004 06:41:02 -0000	1.2
+++ intrinsics/associated.c	17 May 2004 18:59:06 -0000
@@ -23,7 +23,7 @@ Boston, MA 02111-1307, USA.  */
 
 #define associated prefix(associated)
 
-enum { FALSE = 0, TRUE = 1 };
+enum { GFC_FALSE = 0, GFC_TRUE = 1 };
 
 
 GFC_LOGICAL_4
@@ -32,19 +32,19 @@ associated (const gfc_array_void *pointe
   int n, rank;
 
   if (GFC_DESCRIPTOR_DATA (pointer) != GFC_DESCRIPTOR_DATA (target))
-    return FALSE;
+    return GFC_FALSE;
   if (GFC_DESCRIPTOR_DTYPE (pointer) != GFC_DESCRIPTOR_DTYPE (target))
-    return FALSE;
+    return GFC_FALSE;
 
   rank = GFC_DESCRIPTOR_RANK (pointer);
   for (n = 0; n < rank; n++)
     {
       if (pointer->dim[n].stride != target->dim[n].stride)
-        return FALSE;
+        return GFC_FALSE;
       if ((pointer->dim[n].ubound - pointer->dim[n].lbound)
           != (target->dim[n].ubound - target->dim[n].lbound))
-        return FALSE;
+        return GFC_FALSE;
     }
 
-  return  TRUE;
+  return  GFC_TRUE;
 }
Comment 15 Andrew Pinski 2004-05-17 19:32:28 UTC
Yes and IIRC when Tru64 (if ever) gets C99 most of everyone's code gets broken if they used csqrtf.
Comment 16 Rainer Orth 2004-05-18 13:08:55 UTC
Subject: Re:  [gfortran] libgfortran doesn't compile on Tru64 UNIX

pinskia at gcc dot gnu dot org writes:

> Yes and IIRC when Tru64 (if ever) gets C99 most of everyone's code gets broken if they used csqrtf.

As in the SGI/IRIX case, Compaq/HP has already demonstrated that they know
how to deal with source and binary compatility and have mechanisms in place
(see #pragma extern_prefix) that support this.

	Rainer
Comment 17 Tobias Schlüter 2004-05-18 15:48:47 UTC
(In reply to comment #14)
> Subject: Re:  [gfortran] libgfortran doesn't compile on Tru64 UNIX
> 
> Bootstrap on alpha-dec-osf5.1b doesn't succeed either, but this time it's a
> different failure:
> 
> /vol/gnu/src/gcc/gcc-dist/libgfortran/intrinsics/associated.c:26: error: parse
error before numeric constant
> 
> This happens because <sys/types.h> has
> 
> #define TRUE 1
> #define FALSE 0
> 
> so we get
> 
> enum { 0 = 0, 1 = 1 };
> 

I think we can just do away with that enum, in all other places gfortran uses 0
and 1 for true and false. I will submit a patch to that effect.

Doing the right thing with respect to those c* library functions requires a
better knowledge of portability issues and how the compiler interacts with the
library than I have.

I'm changing this bug's status back to new.
Comment 18 CVS Commits 2004-05-27 13:05:31 UTC
Subject: Bug 15234

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	tobi@gcc.gnu.org	2004-05-27 13:05:23

Modified files:
	libgfortran    : ChangeLog 
	libgfortran/intrinsics: associated.c 

Log message:
	PR fortran/15234
	* intrinsics/associated.c: Remove enum.
	(associated): Replace TRUE/FALSE by 1/0.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.19&r2=1.20
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/associated.c.diff?cvsroot=gcc&r1=1.2&r2=1.3

Comment 19 CVS Commits 2004-07-15 14:53:33 UTC
Subject: Bug 15234

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	tobi@gcc.gnu.org	2004-07-15 14:53:29

Modified files:
	gcc/fortran    : ChangeLog trans-array.c 

Log message:
	PR fortran/15234
	* trans-array.c gfc_trans_g77_array,
	gfc_trans_dummy_array_bias): Don't call gfc_trans_string_init
	for assumed length characters.
	(gfc_conv_expr_descriptor): Set se->string_length if dealing
	with a character expression.
	(gfc_cvonv_array_parameter): Pass string length when passing
	character array according to g77 conventions.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.125&r2=1.126
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.10&r2=1.11

Comment 20 Tobias Schlüter 2004-07-15 15:03:10 UTC
(In reply to comment #19)
> Subject: Bug 15234
> 
> CVSROOT:	/cvs/gcc
> Module name:	gcc
> Changes by:	tobi@gcc.gnu.org	2004-07-15 14:53:29

Sorry, wrong PR
Comment 21 Andrew Pinski 2004-08-04 07:20:02 UTC
You can close it as a dup of bug 14325 (if you want) as it is GCC's job to provide a stdint.h anyways 
(which is PR 448).
Comment 22 Paul Thomas 2004-11-18 11:32:28 UTC
gcc-4.0 including gfortran build fine on Tru64 OSF1 V5.1 2650 alpha as long as 
gcc and GNU make are used in the build.

I built GNU Fortran 95 (GCC 4.0.0 20041114 (experimental)) with gcc-3.3.2 
(TWW). It gives no trouble at all, as long as LD_LIBRARY_PATH points to the gcc 
libraries and to gmp/mpfr.
Comment 23 Andrew Pinski 2004-11-18 12:18:21 UTC
5.1 is fixed but 4.0 is still broken.
Comment 24 Andrew Pinski 2004-11-20 15:45:43 UTC
This is __NOT__ fixed by (because alpha is a LP64 target) but it makes it easier to fix:
        * acinclude.m4 (LIBGFOR_TARGET_ILP32): New check.
        * configure.ac: Include LIBGFOR_TARGET_ILP32.
        * configure: Regenerate.
        * config.h.in: Likewise.
        * libgfortran.h: Provide default definitions for C99 types
        on ILP32 targets that don't have them.
Comment 25 Mark Mitchell 2004-12-01 18:15:32 UTC
I don't consider this a regression; libgfortran is new in this release.  So, I
have removed the target milestone.
Comment 26 Francois-Xavier Coudert 2005-06-13 16:03:57 UTC
As I learnt from PR21950, there is a (recent) patch for this one. For the record:
http://gcc.gnu.org/ml/fortran/2005-06/msg00118.html
Comment 27 Francois-Xavier Coudert 2005-07-19 10:30:31 UTC
Do we need to keep this one open? Isn't it fixed the patch for PR21950?
Comment 28 Tobias Schlüter 2005-08-16 19:26:48 UTC
Any news?
Comment 29 Rainer Orth 2005-08-16 19:33:55 UTC
Subject: Re:  libgfortran doesn't compile on Tru64 UNIX V4.0F

tobi at gcc dot gnu dot org writes:

> Any news?

Sorry for the delay: I've been ill for several weeks and am still catching
up on my mail.

My patch for this problem

	http://gcc.gnu.org/ml/fortran/2005-06/msg00118.html

is still required.  I'll address the comments raised on the mailing lists,
but since they all suggest possible cleanups to the way
LIBGFOR_TARGET_ILP32 (and now LIBGFOR_TARGET_LP64) are implemented, I'd
prefer my patch to go in unchanged (as it matches existing practice) and
possibly implement cleanups as followups if deemed worthwhile.

	Rainer
Comment 30 Francois-Xavier Coudert 2005-09-05 10:43:10 UTC
(In reply to comment #29)
> I'll address the comments raised on the mailing lists,
> but since they all suggest possible cleanups to the way
> LIBGFOR_TARGET_ILP32 (and now LIBGFOR_TARGET_LP64) are implemented, I'd
> prefer my patch to go in unchanged (as it matches existing practice) and
> possibly implement cleanups as followups if deemed worthwhile.

I do agree with you. Can you re-submit the patch on the fortran ml for approval?
Comment 31 Francois-Xavier Coudert 2005-09-22 17:50:07 UTC
(In reply to comment #30)
> Can you re-submit the patch on the fortran ml for approval?

ping
Comment 32 Andrew Pinski 2005-10-15 20:22:55 UTC
*** Bug 24391 has been marked as a duplicate of this bug. ***
Comment 33 Francois-Xavier Coudert 2005-10-29 12:57:28 UTC
(In reply to comment #30)
> I do agree with you. Can you re-submit the patch on the fortran ml for approval?

ping*2
Comment 34 Andrew Pinski 2006-01-05 03:21:10 UTC
The only patch left is
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01578.html

The rest was fixed by the patch which fixed PR 25259 which added a stdint.h to include.
Comment 35 Andrew Pinski 2006-01-23 18:20:23 UTC
Fixed by:
2006-01-16  Roger Sayle  <roger@eyesopen.com>

        * configure.ac (CFLAGS): Update to include -std=gnu99 so that
        the configure tests will be run with the same environment as
        used to compile the libgfortran source code.
        * configure: Regenerate.

2006-01-12  Roger Sayle  <roger@eyesopen.com>

        * intrinsics/c99_functions.c: Add function prototypes to avoid
        warnings from -Wstrict-prototypes -Wmissing-prototypes.  On Tru64
        work around a brain-dead libm by redirecting calls to cabs{,f,l}
        to a local __gfc_cabs{,f,l}.
Comment 36 Rainer Orth 2006-02-14 17:28:06 UTC
Subject: Bug 15234

Author: ro
Date: Tue Feb 14 17:28:02 2006
New Revision: 110988

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110988
Log:
	PR libfortran/15234: Backport from mainline
	config:
	2006-01-02  Paolo Bonzini  <bonzini@gnu.org>

        PR target/25259
        * stdint.m4: New.

	libgfortran:
	2006-01-02  Paolo Bonzini  <bonzini@gnu.org>

        PR target/25259
        * configure.ac: Use GCC_HEADER_STDINT.
        * libgfortran.h: Include gstdint.h.
        * aclocal.m4: Regenerate.
        * configure: Regenerate.

Added:
    branches/gcc-4_1-branch/config/stdint.m4
      - copied unchanged from r109241, trunk/config/stdint.m4
Modified:
    branches/gcc-4_1-branch/config/ChangeLog
    branches/gcc-4_1-branch/libgfortran/ChangeLog
    branches/gcc-4_1-branch/libgfortran/aclocal.m4
    branches/gcc-4_1-branch/libgfortran/configure
    branches/gcc-4_1-branch/libgfortran/configure.ac
    branches/gcc-4_1-branch/libgfortran/libgfortran.h

Comment 37 Rainer Orth 2006-02-14 17:31:31 UTC
Still open on the 4.0 branch.
Comment 38 Rainer Orth 2006-02-14 17:51:45 UTC
Subject: Bug 15234

Author: ro
Date: Tue Feb 14 17:51:41 2006
New Revision: 110991

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110991
Log:
	PR libfortran/15234: Backport from mainline
	config:
	2006-01-02  Paolo Bonzini  <bonzini@gnu.org>

        PR target/25259
        * stdint.m4: New.

	libgfortran:
	2006-01-02  Paolo Bonzini  <bonzini@gnu.org>

        PR target/25259
        * configure.ac: Use GCC_HEADER_STDINT.
        * libgfortran.h: Include gstdint.h.
        * aclocal.m4: Regenerate.
        * configure: Regenerate.

Added:
    branches/gcc-4_0-branch/config/stdint.m4
      - copied unchanged from r109241, trunk/config/stdint.m4
Modified:
    branches/gcc-4_0-branch/config/ChangeLog
    branches/gcc-4_0-branch/libgfortran/ChangeLog
    branches/gcc-4_0-branch/libgfortran/aclocal.m4
    branches/gcc-4_0-branch/libgfortran/configure
    branches/gcc-4_0-branch/libgfortran/configure.ac
    branches/gcc-4_0-branch/libgfortran/libgfortran.h

Comment 39 Rainer Orth 2006-02-14 17:52:56 UTC
Fixed for 4.0.3, too.