Re: Documentation of LTIME

[Janus Weil]

Hi all,

I have just committed some minor additions
(https://gcc.gnu.org/viewcvs?rev=243794=gcc=rev) to
Dominique's patch at
https://gcc.gnu.org/viewcvs/gcc?view=revision=243785, so that
these documentation issued are finally resolved now.

Cheers,
Janus



2016-11-26 21:45 GMT+01:00 Janus Weil <ja...@gcc.gnu.org>:
>>> If not, we definitely need to fix the documentation of LTIME, since
>>> the current version simply does not work with TIME8(), unless one uses
>>> -fdefault-integer-8 (which is not mentioned in the docu).
>>
>> What about the attached patch
>
> Yes, looks good to me. Ok to commit!
>
> One minor nit (optional):
>
> @@ -9635,10 +9650,15 @@ To stat an open file: @ref{FSTAT}, to st
>
>  @table @asis
>  @item @emph{Description}:
> -Given a system time value @var{TIME} (as provided by the @code{TIME8}
> +Given a system time value @var{TIME} (as provided by the @code{TIME}
>  intrinsic), fills @var{VALUES} with values extracted from it appropriate
>  to the local time zone using @code{localtime(3)}.
>
> I would use @ref{TIME} here (there are two places where this occurs).
> Also I would add @ref{DATE_AND_TIME} to the "see also" section.
>
> Thanks,
> Janus

Re: Documentation of LTIME

[Janus Weil]

>> If not, we definitely need to fix the documentation of LTIME, since
>> the current version simply does not work with TIME8(), unless one uses
>> -fdefault-integer-8 (which is not mentioned in the docu).
>
> What about the attached patch

Yes, looks good to me. Ok to commit!

One minor nit (optional):

@@ -9635,10 +9650,15 @@ To stat an open file: @ref{FSTAT}, to st

 @table @asis
 @item @emph{Description}:
-Given a system time value @var{TIME} (as provided by the @code{TIME8}
+Given a system time value @var{TIME} (as provided by the @code{TIME}
 intrinsic), fills @var{VALUES} with values extracted from it appropriate
 to the local time zone using @code{localtime(3)}.

I would use @ref{TIME} here (there are two places where this occurs).
Also I would add @ref{DATE_AND_TIME} to the "see also" section.

Thanks,
Janus

Re: Documentation of LTIME

[Dominique d'Humières]

> Still, since we internally already have both implementations for
> kind=4 and kind=8, we could as well make use of them, I guess.

I let this for people understanding what to do.

> If not, we definitely need to fix the documentation of LTIME, since
> the current version simply does not work with TIME8(), unless one uses
> -fdefault-integer-8 (which is not mentioned in the docu).

What about the attached patch



patch-78545
Description: Binary data


Dominique

> 
> Cheers,
> Janus

Re: Documentation of LTIME

[Janus Weil]

>>>> Well LTIME cannot accept both kind(4) and kind(8) arguments. The reference 
>>>> to TIME8 looks like a mistake, isn’t it?
>>>
>>> Huh, in libgfortran I see two versions with different kinds (ltime_i4
>>> and ltime_i8), but in my tests I never get LTIME to work with kind=8
>>> arguments. I guess that is the real bug here ...
>>
>> I think the origin of the bug is:
>>
>> void
>> gfc_resolve_ltime (gfc_code *c)
>> {
>>   c->resolved_sym
>> = gfc_get_intrinsic_sub_symbol (gfc_get_string (PREFIX ("ltime_i%d"),
>> gfc_default_integer_kind));
>> }
>>
>>
>> This always uses the ITIME version corresponding to
>> gfc_default_integer_kind, disregarding the actual kind of the
>> arguments.
>
> LTIME, ITIME, TIME, TIME8, IDATE are g77 intrinsics, from back before
> newfangled things like kinds. So there are versions for integer kind=4
> and kind=8 due to -fdefault-integer-8.

Ok, I see. Thanks for the comment.

Still, since we internally already have both implementations for
kind=4 and kind=8, we could as well make use of them, I guess.

If not, we definitely need to fix the documentation of LTIME, since
the current version simply does not work with TIME8(), unless one uses
-fdefault-integer-8 (which is not mentioned in the docu).

Cheers,
Janus

Re: Documentation of LTIME

[Janne Blomqvist]

On Sat, Nov 26, 2016 at 7:03 PM, Janus Weil  wrote:
> 2016-11-26 17:58 GMT+01:00 Janus Weil :
 * possibly add some more cross-links to intrinsic.texi
>>>
>>> Could you please elaborate?
>>
>> I just mean it might be useful to add some more links from LTIME to
>> ITIME, IDATE and DATE_AND_DATE (and back?). They are are all very
>> similar.
>
> Sorry, I meant DATE_AND_TIME here.
>
>
>>> Well LTIME cannot accept both kind(4) and kind(8) arguments. The reference 
>>> to TIME8 looks like a mistake, isn’t it?
>>
>> Huh, in libgfortran I see two versions with different kinds (ltime_i4
>> and ltime_i8), but in my tests I never get LTIME to work with kind=8
>> arguments. I guess that is the real bug here ...
>
> I think the origin of the bug is:
>
> void
> gfc_resolve_ltime (gfc_code *c)
> {
>   c->resolved_sym
> = gfc_get_intrinsic_sub_symbol (gfc_get_string (PREFIX ("ltime_i%d"),
> gfc_default_integer_kind));
> }
>
>
> This always uses the ITIME version corresponding to
> gfc_default_integer_kind, disregarding the actual kind of the
> arguments.
>
> Cheers,
> Janus

LTIME, ITIME, TIME, TIME8, IDATE are g77 intrinsics, from back before
newfangled things like kinds. So there are versions for integer kind=4
and kind=8 due to -fdefault-integer-8.

DATE_AND_TIME is different since it's in the current standard and IIRC
is specified to work with any integer kind.

-- 
Janne Blomqvist

Re: Documentation of LTIME

[Janus Weil]

2016-11-26 17:58 GMT+01:00 Janus Weil :
>>> * possibly add some more cross-links to intrinsic.texi
>>
>> Could you please elaborate?
>
> I just mean it might be useful to add some more links from LTIME to
> ITIME, IDATE and DATE_AND_DATE (and back?). They are are all very
> similar.

Sorry, I meant DATE_AND_TIME here.


>> Well LTIME cannot accept both kind(4) and kind(8) arguments. The reference 
>> to TIME8 looks like a mistake, isn’t it?
>
> Huh, in libgfortran I see two versions with different kinds (ltime_i4
> and ltime_i8), but in my tests I never get LTIME to work with kind=8
> arguments. I guess that is the real bug here ...

I think the origin of the bug is:

void
gfc_resolve_ltime (gfc_code *c)
{
  c->resolved_sym
= gfc_get_intrinsic_sub_symbol (gfc_get_string (PREFIX ("ltime_i%d"),
gfc_default_integer_kind));
}


This always uses the ITIME version corresponding to
gfc_default_integer_kind, disregarding the actual kind of the
arguments.

Cheers,
Janus

Re: Documentation of LTIME

[Janus Weil]

>> * possibly add some more cross-links to intrinsic.texi
>
> Could you please elaborate?

I just mean it might be useful to add some more links from LTIME to
ITIME, IDATE and DATE_AND_DATE (and back?). They are are all very
similar.



>> And one last point: The description of LTIME mentions TIME8, but if I try 
>> this:
>>
>>  call ltime(time8(), values)
>>
>> I get:
>>
>> Error: ‘time’ argument of ‘ltime’ intrinsic at (1) must be of kind 4
>
> Well LTIME cannot accept both kind(4) and kind(8) arguments. The reference to 
> TIME8 looks like a mistake, isn’t it?

Huh, in libgfortran I see two versions with different kinds (ltime_i4
and ltime_i8), but in my tests I never get LTIME to work with kind=8
arguments. I guess that is the real bug here ...

Maybe one can at least linkify the TIME8 in the documentation? (Or
mention both intrinsics, TIME and TIME8).

Cheers,
Janus

Re: Documentation of LTIME

[Dominique d'Humières]

> Le 26 nov. 2016 à 17:00, Janus Weil  a écrit :
> 
> And one last point: The description of LTIME mentions TIME8, but if I try 
> this:
> 
>  call ltime(time8(), values)
> 
> I get:
> 
> Error: ‘time’ argument of ‘ltime’ intrinsic at (1) must be of kind 4

Well LTIME cannot accept both kind(4) and kind(8) arguments. The reference to 
TIME8 looks like a mistake, isn’t it?

Dominique
 
> 
> So maybe the reference to TIME8 should be replaced by TIME?
> 
> Cheers,
> Janus
> 

Re: Documentation of LTIME

[Dominique d'Humières]

> Le 26 nov. 2016 à 16:54, Janus Weil  a écrit :
> 
> 2016-11-26 16:49 GMT+01:00 Dominique d'Humières :
>> If there is no objection, I’ll commit the following patch
> 
> Looks good to me!
> 
> If you want, you could also fix the remaining items I mentioned in
> comment 1 in the PR:
> * apply the same fix to GMTIME

Done

> * fix it in the libgfortran sources as well

Done

> * possibly add some more cross-links to intrinsic.texi

Could you please elaborate?

Dominique

> 
> Thanks,
> Janus

Re: Documentation of LTIME

[Francisco Pena]

Dominique,

your patch sounds good to me.

2016-11-26 16:49 GMT+01:00 Dominique d'Humières :
> If there is no objection, I’ll commit the following patch
>
> --- ../_clean/gcc/fortran/intrinsic.texi2016-11-25 22:03:20.0 
> +0100
> +++ gcc/fortran/intrinsic.texi  2016-11-26 16:47:12.0 +0100
> @@ -9663,11 +9663,11 @@ The elements of @var{VALUES} are assigne
>  seconds
>  @item Minutes after the hour, range 0--59
>  @item Hours past midnight, range 0--23
> -@item Day of month, range 0--31
> -@item Number of months since January, range 0--12
> +@item Day of month, range 1--31
> +@item Number of months since January, range 0--11
>  @item Years since 1900
>  @item Number of days since Sunday, range 0--6
> -@item Days since January 1
> +@item Days since January 1, range 0--365
>  @item Daylight savings indicator: positive if daylight savings is in
>  effect, zero if not, and negative if the information is not available.
>  @end enumerate
>
> Dominique

Re: Documentation of LTIME

[Janus Weil]

And one last point: The description of LTIME mentions TIME8, but if I try this:

  call ltime(time8(), values)

I get:

Error: ‘time’ argument of ‘ltime’ intrinsic at (1) must be of kind 4

So maybe the reference to TIME8 should be replaced by TIME?

Cheers,
Janus



2016-11-26 16:54 GMT+01:00 Janus Weil :
> 2016-11-26 16:49 GMT+01:00 Dominique d'Humières :
>> If there is no objection, I’ll commit the following patch
>
> Looks good to me!
>
> If you want, you could also fix the remaining items I mentioned in
> comment 1 in the PR:
> * apply the same fix to GMTIME
> * fix it in the libgfortran sources as well
> * possibly add some more cross-links to intrinsic.texi
>
> Thanks,
> Janus
>
>
>
>> --- ../_clean/gcc/fortran/intrinsic.texi2016-11-25 
>> 22:03:20.0 +0100
>> +++ gcc/fortran/intrinsic.texi  2016-11-26 16:47:12.0 +0100
>> @@ -9663,11 +9663,11 @@ The elements of @var{VALUES} are assigne
>>  seconds
>>  @item Minutes after the hour, range 0--59
>>  @item Hours past midnight, range 0--23
>> -@item Day of month, range 0--31
>> -@item Number of months since January, range 0--12
>> +@item Day of month, range 1--31
>> +@item Number of months since January, range 0--11
>>  @item Years since 1900
>>  @item Number of days since Sunday, range 0--6
>> -@item Days since January 1
>> +@item Days since January 1, range 0--365
>>  @item Daylight savings indicator: positive if daylight savings is in
>>  effect, zero if not, and negative if the information is not available.
>>  @end enumerate
>>
>> Dominique
>>
>>> Le 26 nov. 2016 à 16:02, Francisco Pena  a écrit :
>>>
>>> Thank you guys,
>>>
>>> I have reported the documentation bug,
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78545
>>

Re: Documentation of LTIME

[Janus Weil]

2016-11-26 16:49 GMT+01:00 Dominique d'Humières :
> If there is no objection, I’ll commit the following patch

Looks good to me!

If you want, you could also fix the remaining items I mentioned in
comment 1 in the PR:
* apply the same fix to GMTIME
* fix it in the libgfortran sources as well
* possibly add some more cross-links to intrinsic.texi

Thanks,
Janus



> --- ../_clean/gcc/fortran/intrinsic.texi2016-11-25 22:03:20.0 
> +0100
> +++ gcc/fortran/intrinsic.texi  2016-11-26 16:47:12.0 +0100
> @@ -9663,11 +9663,11 @@ The elements of @var{VALUES} are assigne
>  seconds
>  @item Minutes after the hour, range 0--59
>  @item Hours past midnight, range 0--23
> -@item Day of month, range 0--31
> -@item Number of months since January, range 0--12
> +@item Day of month, range 1--31
> +@item Number of months since January, range 0--11
>  @item Years since 1900
>  @item Number of days since Sunday, range 0--6
> -@item Days since January 1
> +@item Days since January 1, range 0--365
>  @item Daylight savings indicator: positive if daylight savings is in
>  effect, zero if not, and negative if the information is not available.
>  @end enumerate
>
> Dominique
>
>> Le 26 nov. 2016 à 16:02, Francisco Pena  a écrit :
>>
>> Thank you guys,
>>
>> I have reported the documentation bug,
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78545
>

Re: Documentation of LTIME

[Dominique d'Humières]

If there is no objection, I’ll commit the following patch

--- ../_clean/gcc/fortran/intrinsic.texi2016-11-25 22:03:20.0 
+0100
+++ gcc/fortran/intrinsic.texi  2016-11-26 16:47:12.0 +0100
@@ -9663,11 +9663,11 @@ The elements of @var{VALUES} are assigne
 seconds
 @item Minutes after the hour, range 0--59
 @item Hours past midnight, range 0--23
-@item Day of month, range 0--31
-@item Number of months since January, range 0--12
+@item Day of month, range 1--31
+@item Number of months since January, range 0--11
 @item Years since 1900
 @item Number of days since Sunday, range 0--6
-@item Days since January 1
+@item Days since January 1, range 0--365
 @item Daylight savings indicator: positive if daylight savings is in
 effect, zero if not, and negative if the information is not available.
 @end enumerate

Dominique

> Le 26 nov. 2016 à 16:02, Francisco Pena  a écrit :
> 
> Thank you guys,
> 
> I have reported the documentation bug,
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78545