This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Inline DOT_PRODUCT revisited - to libgfortran/m4 gurus
- From: Paul Thomas <paulthomas2 at wanadoo dot fr>
- To: Janne Blomqvist <jblomqvi at cc dot hut dot fi>
- Cc: Steven Bosscher <stevenb dot gcc at gmail dot com>, gcc-patches at gcc dot gnu dot org, "'fortran at gcc dot gnu dot org'" <fortran at gcc dot gnu dot org>, Dominique Dhumieres <dominiq at lps dot ens dot fr>
- Date: Sun, 26 Feb 2006 19:07:40 +0100
- Subject: Re: Inline DOT_PRODUCT revisited - to libgfortran/m4 gurus
- References: <43730120.7030808@wanadoo.fr> <200602252337.39067.steven@gcc.gnu.org> <4401C6F1.9070306@wanadoo.fr> <20060226162247.GU1854@vipunen.hut.fi>
Janne,
Nice to hear from you....
1) What's the problem with kind > 8? I removed the
if (expr->ts.kind > 8)
+ {
+ gfc_conv_intrinsic_funcall (se, expr);
+ return;
+ }
thing and it seems to work for kind=10 (work, as in your testcase
modified for kind=10 ran without crashing). Tough I didn't make a
testcase to check whether the results were sensible, that should
certainly be made.
Nothing - the later versions of the patch do not have this exclusion.
It works fine with real(10) and real(16).
2) What about dot_product for logicals? The patch doesn't seem to
address this? But I don't think it's worth worrying about the
performance of this, I don't know of any real usage of this (if I'm
wrong please correct me). So the easiest thing would be to use the
existing library implementation.
I just thought of this question myself; I will do an inline version. I
note, though that
logical :: l1(4) = (/.TRUE.,.FALSE.,.TRUE.,.FALSE./)
logical :: l2(4) = (/.FALSE.,.TRUE.,.FALSE.,.TRUE./)
print *, dot_product (l1, l2)
end
gives 4(!) with the gfortran library and F with ifort. I have to say
that the latter seems, well, more reasonable..... If the first element
of l2 changes to .TRUE., the result from gfortran is still 4 but ifort
gives T. I will look at the standard but my preference is ifort's result.
Paul
Paul