This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch, fortran] PR30014 INQUIRE (iolength = xx) limited to kind=4


Thomas Koenig wrote:
On Fri, Dec 15, 2006 at 09:30:56PM -0800, Jerry DeLisle wrote:

:REVIEWMAIL:

Hi Jerry,

ping

Also, should I increase size parameter as well? Any opinions?

We already have an incompatible change for 4.2 (the memory allocation interface), so I tend to think we should put this into 4.2 a well.

I think regression-tests on 32-bit systems are necessary for
this, if at all possible also on big- and little endian machines.

I agree on the tests, need to find someone with such machines. However, on back porting to 4.2, we were trying to follow stricter rules on back porting. I see the positive side of keeping 4.2 in sync with 4.3 on the one hand and following the release rules on the other. I will let others decide on this.

Jerry DeLisle wrote:
:ADDPATCH fortran:

The attached patch changes the type to GFC_IO_INT which will either be kind=4 or kind=8 depending on the system. The patch is very straight forward. I don't see any point giving a warning if a user specifies a variable of kind=8 in a -std=f95 situation. If others feel stronger about this I will do it.

If it is something that can be diagnosed easily, I'd be in favor doing the warning.

OK, I will look into it. It should not be too difficult.



A test case for this will require a lot of memory and consumes time. I suggest we go without one for this. I have attached the test case that I used to check this out.

I don't quite understand why it would take so long. Did it actually do so during your testing? Would it do the same for an allocatable array?

I was thinking that We would have to create an output list greater than 2 gbyte so that the IOLENGTH resulting is an integer large enough to require KIND=8, similar to testing the sub-record patch. Doing that, the test may fail on smaller machines. We already have test cases for smaller output lists I believe. The time to allocate the huge array would not be bad, but noticeable.


Thanks for feedback,

Jerry


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]