This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Fwd: Question on PR25289]
- From: Jerry DeLisle <jvdelisle at verizon dot net>
- To: Thomas Koenig <Thomas dot Koenig at online dot de>, Fortran List <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- Date: Wed, 12 Jul 2006 20:09:47 -0700
- Subject: Re: [Fwd: Question on PR25289]
- References: <44B45D28.2090106@verizon.net> <20060712102321.GA5440@meiner.onlinehome.de>
Thomas Koenig wrote:
We have one question. What, if any, problems do we have on a
system that does not support GFC_INTEGER_8? Are there any such systems?
I don't think there are any systems without GFC_INTEGER_8. Can somebody
else confirm this?
Do you see any issues with the record_marker size options?
No problem. I just wonder what will happen with large files on
systems where sizeof(off_t) is 4. I can't test this, however.
Right now in the 4.1 branch and trunk, large file attempts yield an error on
record number because the frontend is using GFC_INTEGER_4. The patch simply
extends that to kind=8 where it exists.
--- 129,143 ----
kind = bitsize / 8;
if (kind == 4)
! {
! saw_i4 = true;
! gfc_record_int_kind = 4;
! }
if (kind == 8)
! {
! saw_i8 = true;
! gfc_record_int_kind = 8;
! }
This only works if the code is called with kind=4 first, with kind=8
second. Is this guaranteed?
The following minor update will avoid any concern here.
+ if (saw_i8)
+ gfc_record_int_kind = 8;
+ else
+ gfc_record_int_kind = 4;
If GFC_INTEGER_8 is indeed guaranteed to be present, then I think
we should bother with this. Just put in assert(HAVE_GFC_INTEGER_8)
somewhere.
At this point I propose we commit the patch to 4.2 and allow some exposure to
see if there are any real problems. We can then always fix or revert if
something shows up. Is this not why trunk is not a release yet?
OK to commit to 4.2?
Jerry