headers
Daniel Franke | 1 Jan 2009 20:29
Picon

min/max and string arguments


Happy new year, everyone!

Let's start this year with a small puzzle :)

What should be the proper output of this code fragment?

	print *, MIN ("foo", "", "bar")
	end

gfortran answers "bar" while an equivalent C-fragment using strcmp() would 
result in "". gfortran's behavior becomes especially interesting with:

	min("", " ")   ->   " "
	max("", " ")   ->   " "

while one would probably expect "" and " " respectively?!

How do other compilers handle this? Intel 10.1, the only other one I have 
access to, does not accept string arguments.

Thanks!

	Daniel
Permalink | Reply | 2 comments |
headers
Steve Kargl | 1 Jan 2009 21:24
Picon

Re: min/max and string arguments

On Thu, Jan 01, 2009 at 08:29:26PM +0100, Daniel Franke wrote:
> 
> Happy new year, everyone!

Likewise!

> 
> Let's start this year with a small puzzle :)
> 
> What should be the proper output of this code fragment?
> 
> 	print *, MIN ("foo", "", "bar")
> 	end
> 
> gfortran answers "bar" while an equivalent C-fragment using strcmp() would 
> result in "".

Looks like a bug.  MIN/MAX state

   For arguments of character type, the result is the value that would
   be selected by application of intrinsic relational operators; that is,
   the collating sequence for characters ...

I suppose the question becomes:  What is the collating sequence for
the empty string ""?.  Is "" the ASCII NUL character?  Of course,
Fortran strings are not NULL terminated.  Section 4.4.4.3 discusses
the collating sequence, but it does not call out any special handling
of zero length strings.

It is instructive to read the description of LGT(...) and friends.  The
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Franke | 1 Jan 2009 21:43
Picon

Re: min/max and string arguments

On Thursday 01 January 2009 21:24:58 Steve Kargl wrote:
> > Let's start this year with a small puzzle :)
> >
> > What should be the proper output of this code fragment?
> >
> > 	print *, MIN ("foo", "", "bar")
> > 	end
> >
> > gfortran answers "bar" while an equivalent C-fragment using strcmp()
> > would result in "".
>
> Looks like a bug.  MIN/MAX state

Shame on me. It isn't. 
Just tried again with a clean tree. All nice and shiny.

> 13.7.76 MIN(...)
>
>     For arguments of character type, the length of the result is the length
>     of the longest argument.
> ....
>     If the selected argument is shorter than the longest argument, the
>     result is extended with blanks on the right to the length of the
>     longest argument.

That's the piece of information  I lacked to understand what's going on!

Steve, thank you very much!

	Daniel
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Koenig | 1 Jan 2009 22:16
Picon
Favicon

[patch, fortran] Fix PR 38672

Hello world,

first, a happy new year for everybody!

Here is a fix for PR 38672.  As far as I can see, this should do the
right thing, but I'm open to corrections if I should have missed
something.

One part of this patch is actually identical to Mikael's suggestion
for PR 37829, but there are other test cases which aren't fixed by this,
so I'm not mentioning PR 37829 in the ChangeLog entry.

Regression-tested on trunk.

OK?

	Thomas

2009-01-01  Thomas Koenig  <tkoenig <at> gcc.gnu.org>

	PR fortran/38672
	* trans-types.c (gfc_get_derived_type):  Check for the
	presence of derived->ns->proc_name before
	accessing derived->ns->proc_name->attr.flavor .
	* resolve.c (resolve_symbol):  Likewise.

2009-01-01  Thomas Koenig  <tkoenig <at> gcc.gnu.org>

	PR fortran/38672
	* gfortran.dg/host_assoc_blockdata_1.f90:  New test.
(Continue reading)

Permalink | Reply | 4 comments |
headers
FX | 2 Jan 2009 00:15
Picon

Re: min/max and string arguments

> What should be the proper output of this code fragment?
>
> 	print *, MIN ("foo", "", "bar")
> 	end
>
> gfortran answers "bar"

If so, it's a recent change, since the version on my laptop gives the  
right answer (it's dated 20081211):

lumo /tmp $ cat a.f90
   write (*,"('#',A,'#')") MIN ("foo", "", "bar")
   end
lumo /tmp $ gfortran -v
Using built-in specs.
Target: i386-apple-darwin8.10.1
Configured with: /tmp/gfortran-20081211/ibin/../gcc/configure -- 
prefix=/usr/local/gfortran --enable-languages=c,fortran --with-gmp=/ 
tmp/gfortran-20081211/gfortran_libs --enable-bootstrap
Thread model: posix
gcc version 4.4.0 20081211 (experimental) [trunk revision 142675] (GCC)
lumo /tmp $ gfortran a.f90 && ./a.out
#   #

(I remember having thought about it quite a bit when working on  
widechar strings SELECT)

--

-- 
FX
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Richard Thomas | 3 Jan 2009 15:15
Picon

[Patch, fortran] PR38594 - [4.4 Regression] module function name mangled improperly if contained function of same name exists

Dear All,

Happy New Year to you all!

This is a fix for one of the rash of regressions that were reported
before Christmas - it's a pity, since we were down to two, but it does
show that folk out there are using gfortran:-)

The chunk of code in resolve_call that checks host association was
substituting the symbol for the correct procedure and popping it on to
the symtree.  This was OK for generic procedures, such as in
host_assoc_call_3.f90.  This latter was what triggered the
introduction of this bit of code.  I missed the fact that it failed
for specific references.  This patch fixes that by looking for the
symtree and substituting that in the call, except for generic
references.

Bootstrapped and regtested on FC9/x86_i64 - OK for trunk?

Cheers

Paul

2009-01-03  Paul Thomas  <pault <at> gcc.gnu.org>

	PR fortran/35820
	* resolve.c (resolve_call): When searching for proper host
	association, use symtree rather than symbol.  For everything
	except generic subroutines, substitute the symtree in the call
	rather than the symbol.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel Kraft | 3 Jan 2009 15:33
Picon

Re: [Patch, fortran] PR38594 - [4.4 Regression] module function name mangled improperly if contained function of same name exists

Paul Richard Thomas wrote:
> Dear All,
> 
> Happy New Year to you all!
> 
> This is a fix for one of the rash of regressions that were reported
> before Christmas - it's a pity, since we were down to two, but it does
> show that folk out there are using gfortran:-)
> 
> The chunk of code in resolve_call that checks host association was
> substituting the symbol for the correct procedure and popping it on to
> the symtree.  This was OK for generic procedures, such as in
> host_assoc_call_3.f90.  This latter was what triggered the
> introduction of this bit of code.  I missed the fact that it failed
> for specific references.  This patch fixes that by looking for the
> symtree and substituting that in the call, except for generic
> references.
> 
> Bootstrapped and regtested on FC9/x86_i64 - OK for trunk?

Ok.  Thanks!

Daniel

--

-- 
Done:  Arc-Bar-Cav-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri-Ran
Permalink | Reply | 0 comments |
headers
Daniel Kraft | 3 Jan 2009 15:46
Picon

[Patch, Fortran] Another floating point speedup

Hi all,

again a patch to rework libgfortran's read_f for formatted reading of 
floating point numbers.  This one should be equivalent to the old code 
with respect to precision, as we're still using convert_real and 
utimatly strtod for the actual conversion.

This just reworks the way that read_f reformats the string to handle the 
Fortran/format specific issues.  It is not as "good" as the other patch 
posted here, but it still brings down execution times from 33.4s to 25s 
for the test attached on my system.  Profiling shows that most of the 
time (5s) is spent in strtod, about 3s in read_f for the reformatting 
and some 1s and below in other helper routines; so I'd guess that 
there's not much further speed-up possible (at least no dramatic one, 
except we could somehow get rid of this preprocessing completely) with 
still using strtod; but that's just a wild guess.

io/list_read.c contains two other similar routines (parse_float and 
read_float) that sound as if we could do some cleaning up and maybe 
speed-up for those three (like combining common code or at least 
parse_float and read_float for unformatted IO, as I see it), I can work 
on this as a new patch or extension to this one.  What do you think?

Regression-testing at the moment on GNU/Linux-x86-32.  Maybe I've got 
introduced some bugs with BLANK_ZERO/BLANK_NULL again, but those should 
not interfer much with the timing figure.  Ok for 4.5 (at least from the 
main implementation and rather than my other patch)?  I can then work on 
the others, if it is (or we take this one on hold and I work for a 
seperate patch on the rest).
(Continue reading)

Permalink | Reply | 8 comments |
headers
Daniel Kraft | 3 Jan 2009 15:49
Picon

Re: PING [Patch, Fortran] PR fortran/37746: -fbounds-check for string lengths of dummy arguments

Ping.

Daniel Kraft wrote:
> Hi,
> 
> the attached patch implements a runtime check that the string length of 
> an actual argument matches the expected one for a (non-assumed length) 
> character dummy argument, if -fbounds-check is given.  This fixes PR 
> 37746 (the original test case, although it was meant to mean something 
> else by the reporter, now gives the expected error), you may also want 
> to look at the test cases for what this is supposed to catch.
> 
> I had to change two torture-tests because I believe they are wrong and 
> the new check complained about this; please verify the changes are ok, 
> although I'm quite sure I didn't change anything about the meaning of 
> the test.  I'm not an expert about the code touched, so please feel free 
> to find any things I did miss :D
> 
> Regression-testing at the moment on GNU/Linux-x86-32. Ok for trunk if no 
> regressions?  I'm also open to queue this one up for 4.5, but as only 
> behaviour with -fbounds-check active is affected, I think we can also 
> put this in for 4.4, as it's also a bug fix.
> 
> Yours,
> Daniel
> 
> PS: Sorry for that many test cases, but I don't think it is possible to 
> check for multiple runtime errors with just one file; or is it?
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Kraft | 3 Jan 2009 16:01
Picon

Re: [Patch, Fortran] Another floating point speedup

Ok, seems I've not yet fully arrived in 2009...  Of course the 
exponent-writing code screws it all up, but as it is of limited range 
(say, 3 digits should be enough, shouldn't it?) there's of course an 
easy replacement.  So just look at the rest of it :)

BTW, is there an assertion-function to use in libgfortran?  Or shouldn't 
we use those there?

Daniel

Daniel Kraft wrote:
> Hi all,
> 
> again a patch to rework libgfortran's read_f for formatted reading of 
> floating point numbers.  This one should be equivalent to the old code 
> with respect to precision, as we're still using convert_real and 
> utimatly strtod for the actual conversion.
> 
> This just reworks the way that read_f reformats the string to handle the 
> Fortran/format specific issues.  It is not as "good" as the other patch 
> posted here, but it still brings down execution times from 33.4s to 25s 
> for the test attached on my system.  Profiling shows that most of the 
> time (5s) is spent in strtod, about 3s in read_f for the reformatting 
> and some 1s and below in other helper routines; so I'd guess that 
> there's not much further speed-up possible (at least no dramatic one, 
> except we could somehow get rid of this preprocessing completely) with 
> still using strtod; but that's just a wild guess.
> 
> io/list_read.c contains two other similar routines (parse_float and 
> read_float) that sound as if we could do some cleaning up and maybe
(Continue reading)

Permalink | Reply | 0 comments |

Gmane