This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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: newbie willing to contribute...


> Hi, I've reviewed your patch and here are suggestions and questions
> related to your implementation of complex

Thanks for the reading!

> intrinsic.c
> -I'm not sure what the spec are but in cmplx and dcmplx the second
> argument is optional. I may be fine to do the same for complex.

The reference for this is the g77 documentation, which you can find
online at http://gcc.gnu.org/onlinedocs/

The page for COMPLEX states that the second argument it not optionnal.

> -I had inderstood that complex is a F77 function not a GNU one. ->
> make_generic(,,GFC_STD_F77)

Same doc says the intrinsic group is gnu (otherwise, it would be Fortran 77).

> iresolve.c
> -first if: what if y is of kind complex or char or a shorter real than
> the default one?

X and Y are INTEGER or REAL (but possibly note the same). As for a
shorter real than the default one, I think it's ok. Currently, the
default real kind is used only if both X and Y are INTEGER.

> -is BT_REAL multivalued? I mean you test if (y->ts.type == BT_REAL) .
> Is this tru for all kinds of real?

The typespec has a type field (which is one of BT_REAL, BT_INTEGER,
BT_LOGICAL, BT_CHARACTER, BT_PROCEDURE, BT_COMPLEX, ...) and a kind
field (which is the Fortran kind of the variable). See gfortran.h and
trans-kinds.c for details.

> -Finally you've not tested what happens if x is already of kind
> complex. May be this is hecked elswhere? Yet for cmplx and cmplx it is
> done here.

See above. COMPLEX is different from CMPLX. It's stated in the doc
that COMPLEX X argument is either INTEGER or REAL.

> check.c
> -here other functions uses the "numeric_check function" then prevent
> the complex case. I feel this is safer in the iew of future
> development as no ones knows what the future of numeric kinds is made
> of. :-)

Well, I explicitly check that arguments are either BT_INTEGER or
BT_REAL just after that, so that check isn't actually needed. But we
need a pair of scalar_check()s, which I added to my tree.

> simplify.c
> -is it correct to use the default real kind for any integer? For
> instance on x86 one can represente exactly long int whith long double.
> Can't user await us to use this feature? I mean to have a complex
> whose decimal part count at least as many bytes as the integer.

This is a nice question, which I don't think I can address now. Doing
exactly the right thing is tricky (because integer and real kinds
having just as many bytes doesn't mean you'll be able to store a given
integer into that real kind without loss), so I don't plan to
implement it now. Perhaps a TODO is in order, so that people are aware
of this issue.

> PS: thanks for beeing patient with my questions even if they seems dumb.

It's a nice way to learn.

FX


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