This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [fortran, documentation, patch] document the last set of intrinsics
On Monday 23 April 2007 23:57:23 FX Coudert wrote:
[...]
> with the following changes:
> > +@item @var{DIM} @tab Shall be a scalar of type @code{INTEGER}
> > with a
> > +value in the range from 1 to n, where n equals the rank of @var
> > {ARRAY}.
>
> What about "with a value in the range from 1 to the rank of @var
> {ARRAY}"? It's simpler.
Copy-paste from an earlier change. Probably something to avoid to follow the
standard's text too closely.
> > +If @var{DIM} is absent, a scalar with the sum of all elements in
> > @var{MASK}
> > +is returned.
>
> "product of all elements in @var{ARRAY}", instead? I mean, product
> instead of sum, and ARRAY instead of MASK
>
> > @section @code{SUM} --- Sum of array elements
>
> Same remarks as PRODUCT.
*argl* copy-paste again. There will always be one occurence that slips
through.
> > +Determines the @var{COUNT} of milliseconds of wall clock time since
> > +the Epoch (00:00:00 UTC, January 1, 1970) modulo @var{COUNT_MAX},
> > +@var{COUNT_RATE} determines the number of clock ticks per second.
> > +@var{COUNT_RATE} and @var{COUNT_MAX} are constant and specific to
> > +@command{gfortran}.
>
> If COUNT_RATE and COUNT_MAX are constant across architectures (for
> gfortran), maybe we could include their value in the doc?
>
> Also, nothing here says that all these arguments are intent(out). The
> description above might even be misleading people into thinking that
> COUNT_MAX can be selected by the user, don't you think?
I didn't mention it deliberately to avoid to copy the standard verbatim.
There's nothing else preventing it.
> > +This is also known as @emph{casting} one type to another.
>
> Here, or in a note, I think we should say clearly that it's the
> Fortran 95 way of doing what people often achieve by invalid uses of
> equivalence; it might even be worth putting an example about that.
I have to admit, I'm sort of clueless about TRANSFER in general. I tried to
find a somewhat useful example in bugzilla as there are quite a few reports
about TRANSFER, but none of them was very striking. So I settled for the not
so enlighting NaN example. If there's something specific you want to see
there, let me know.
> Thanks again for working on that. Please post the updated patch when
> you commit it.
I'll go for it one by one, no need to hurry.
Thanks for your reviews. I'll update the patch accordingly.
Regards
Daniel