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 39654 - ABI bug: FTELL intrinsic function not capable of large files
Summary: ABI bug: FTELL intrinsic function not capable of large files
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.5.0
: P3 enhancement
Target Milestone: ---
Assignee: Janne Blomqvist
URL: http://gcc.gnu.org/ml/gcc-patches/201...
Keywords:
Depends on: 37577
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-05 17:17 UTC by Janne Blomqvist
Modified: 2012-06-21 19:53 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-08-27 13:27:43


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Janne Blomqvist 2009-04-05 17:17:39 UTC
The FTELL function in libgfortran/io/intrinsics.c has the prototype

extern size_t PREFIX(ftell) (int *);

where the return value is the file position of the unit given in the int argument. On 32-bit platforms this will not work for files > 4 GB. The return type should be GFC_IO_INT which is a typedef for off_t which is 64-bit on LFS capable systems.
Comment 1 Tobias Burnus 2009-05-27 17:29:02 UTC
See also: http://gcc.gnu.org/wiki/LibgfortranAbiCleanup
Comment 2 Janne Blomqvist 2009-05-27 17:44:14 UTC
(In reply to comment #1)
> See also: http://gcc.gnu.org/wiki/LibgfortranAbiCleanup
> 

Yes, I know; I added the note to the wiki page after I filed this bug. ;-)
Comment 3 Jerry DeLisle 2009-07-22 00:02:10 UTC
Is there a particular reason why we can not change this to off_t with 4.5.?
Comment 4 Janne Blomqvist 2009-07-29 12:46:46 UTC
(In reply to comment #3)
> Is there a particular reason why we can not change this to off_t with 4.5.?
> 

Yes, it would break the ABI. As it's such a minor issue, IMHO it can be postponed until we need to break the ABI for other reasons (e.g. the new array descriptor for 4.6 and so on).

If one really wanted to fix it, we could have a new symbol in the library with the correct prototype, and 4.5 could use that and older releases of gfortran keep using the existing one. That can be done with symbol versioning, or just manually. But I'm not sure it's worth the bother.
Comment 5 Paul Thomas 2009-12-17 21:04:51 UTC
(In reply to comment #4)
> (In reply to comment #3)

Gentlemen,

What is the word on this? A WONTFIX?

Paul
Comment 6 Janne Blomqvist 2009-12-19 11:03:19 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> 
> Gentlemen,
> 
> What is the word on this? A WONTFIX?

Certainly this should be fixed, eventually. Whether it will be fixed for 4.5 or sometime later remains to be seen. Personally, I don't think it's particularly high priority.

Comment 7 Janne Blomqvist 2012-06-20 21:31:54 UTC
Patch here: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01378.html
Comment 8 Janne Blomqvist 2012-06-21 18:47:06 UTC
Author: jb
Date: Thu Jun 21 18:47:01 2012
New Revision: 188858

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188858
Log:
PR 39654 FTELL intrinsic function return type.

frontend ChangeLog:

2012-06-21  Janne Blomqvist  <jb@gcc.gnu.org>

	PR fortran/39654
	* iresolve.c (gfc_resolve_ftell): Fix result kind and use new
	library function.


library ChangeLog:

2012-06-21  Janne Blomqvist  <jb@gcc.gnu.org>

	PR fortran/39654
	* io/intrinsics.c (ftell2): New function.
	* gfortran.map (_gfortran_ftell2): Export function.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/iresolve.c
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/gfortran.map
    trunk/libgfortran/io/intrinsics.c
Comment 9 Janne Blomqvist 2012-06-21 19:53:06 UTC
Fixed, closing.