diff mbox

Documentation of LTIME

Message ID B272C514-F1C7-471E-A650-2E126BF51807@lps.ens.fr
State New
Headers show

Commit Message

Dominique d'Humières Nov. 26, 2016, 3:49 p.m. UTC
If there is no objection, I’ll commit the following patch


Dominique

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

Comments

Janus Weil Nov. 26, 2016, 3:54 p.m. UTC | #1
2016-11-26 16:49 GMT+01:00 Dominique d'Humières <dominiq@lps.ens.fr>:
> 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.texi        2016-11-25 22:03:20.000000000 +0100
> +++ gcc/fortran/intrinsic.texi  2016-11-26 16:47:12.000000000 +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 <fran.pena@usc.es> a écrit :
>>
>> Thank you guys,
>>
>> I have reported the documentation bug,
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78545
>
Janus Weil Nov. 26, 2016, 4 p.m. UTC | #2
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 <janus@gcc.gnu.org>:
> 2016-11-26 16:49 GMT+01:00 Dominique d'Humières <dominiq@lps.ens.fr>:
>> 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.texi        2016-11-25 22:03:20.000000000 +0100
>> +++ gcc/fortran/intrinsic.texi  2016-11-26 16:47:12.000000000 +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 <fran.pena@usc.es> a écrit :
>>>
>>> Thank you guys,
>>>
>>> I have reported the documentation bug,
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78545
>>
Francisco Pena Nov. 26, 2016, 4:16 p.m. UTC | #3
Dominique,

your patch sounds good to me.

2016-11-26 16:49 GMT+01:00 Dominique d'Humières <dominiq@lps.ens.fr>:
> If there is no objection, I’ll commit the following patch
>
> --- ../_clean/gcc/fortran/intrinsic.texi        2016-11-25 22:03:20.000000000 +0100
> +++ gcc/fortran/intrinsic.texi  2016-11-26 16:47:12.000000000 +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
Dominique d'Humières Nov. 26, 2016, 4:19 p.m. UTC | #4
> Le 26 nov. 2016 à 16:54, Janus Weil <janus@gcc.gnu.org> a écrit :
> 
> 2016-11-26 16:49 GMT+01:00 Dominique d'Humières <dominiq@lps.ens.fr>:
>> 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
Dominique d'Humières Nov. 26, 2016, 4:28 p.m. UTC | #5
> Le 26 nov. 2016 à 17:00, Janus Weil <janus@gcc.gnu.org> 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
>
Janus Weil Nov. 26, 2016, 4:58 p.m. UTC | #6
>> * 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
Janus Weil Nov. 26, 2016, 5:03 p.m. UTC | #7
2016-11-26 17:58 GMT+01:00 Janus Weil <janus@gcc.gnu.org>:
>>> * 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
Janne Blomqvist Nov. 26, 2016, 5:17 p.m. UTC | #8
On Sat, Nov 26, 2016 at 7:03 PM, Janus Weil <janus@gcc.gnu.org> wrote:
> 2016-11-26 17:58 GMT+01:00 Janus Weil <janus@gcc.gnu.org>:
>>>> * 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.
Janus Weil Nov. 26, 2016, 5:25 p.m. UTC | #9
>>>> 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
Dominique d'Humières Nov. 26, 2016, 6:35 p.m. UTC | #10
> 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
Dominique

> 
> Cheers,
> Janus
Janus Weil Nov. 26, 2016, 8:45 p.m. UTC | #11
>> 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
Janus Weil Dec. 19, 2016, 10:30 a.m. UTC | #12
Hi all,

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

Cheers,
Janus



2016-11-26 21:45 GMT+01:00 Janus Weil <janus@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
diff mbox

Patch

--- ../_clean/gcc/fortran/intrinsic.texi	2016-11-25 22:03:20.000000000 +0100
+++ gcc/fortran/intrinsic.texi	2016-11-26 16:47:12.000000000 +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