OpenWatcom v1.2 F77 compiler is being checked against the NIST test suite.  Almost everything
passed, but four tests still are at issue.

Specifically test FM403.FOR tests, among other things, Hollerith stuff.  It looks like
originally it was getting the wrong input file, but the NIST tests are nice in that 
they carry the proper input in comments, so I was able to construct an input file
for use in testing.  

However, I found that the source would not compile properly unless the source file
was saved so as to avoid tab-replacement of repeated blanks.  This makes sense to
me, as Hollerith things are essentially counted strings and tab-replacement changes
the count.  Similarly, the input file needs the same care to avoid some overzealous 
text editor changing whitespace to so-called "equivalent" forms involving tabs.  

With the source file and the input file "changed" to avoid tab replacement, the source
compiles properly and the output seems to be correct, indicating the test is passed.
Before we consider this a PASS and not a FAIL -- are there any other things to check
here?  Any reservations about this?  Caveats?

Kevin G. Rhoads wrote:

> OpenWatcom v1.2 F77 compiler is being checked against the NIST test suite.  Almost everything
> passed, but four tests still are at issue.

> Specifically test FM403.FOR tests, among other things, Hollerith stuff.  It looks like
> originally it was getting the wrong input file, but the NIST tests are nice in that 
> they carry the proper input in comments, so I was able to construct an input file
> for use in testing.  

> However, I found that the source would not compile properly unless the source file
> was saved so as to avoid tab-replacement of repeated blanks.  This makes sense to
> me, as Hollerith things are essentially counted strings and tab-replacement changes
> the count.  Similarly, the input file needs the same care to avoid some overzealous 
> text editor changing whitespace to so-called "equivalent" forms involving tabs.  

Do you mean replacing blanks with tabs in the source?  That sounds like
a very non-standard thing to do in any case, but especially in
Hollerith strings, as you mention.

Or did you mean replacing tabs with blanks, hopefully only in Hollerith
constants?   If this is being done by the OpenWatcom editor then I might
say that it is a bug in the editor but not the compiler.

Now, for an input file being read by the program, I would say that
tabs should not apper there, except inside character constants, and
again that they should not be replaced.

(snip)

-- glen

>Do you mean replacing blanks with tabs in the source?  That sounds like
>a very non-standard thing to do in any case, but especially in
>Hollerith strings, as you mention.

Yes, it appeared that something had replaced blanks with tabs in
both the source and input files before they got to me.  When
I changed tabs back to sequences of blanks, everything started
working correctly.  

I thought that replacing the tabs with series of blanks was
thus just undoing something that had been incorrectly done.
But I wanted to double check with people who are more aware
of language standards issues.

Thanks for your feedback, I'm sorry if my question wasn't
very clear.

On Wed, 25 Feb 2004 11:02:20 -0500, "Kevin G. Rhoads"
<Kevin.Rhoads@Dartmouth.edu> wrote:

>However, I found that the source would not compile properly unless the source file
>was saved so as to avoid tab-replacement of repeated blanks.  This makes sense to
>me, as Hollerith things are essentially counted strings and tab-replacement changes
>the count.  Similarly, the input file needs the same care to avoid some overzealous 
>text editor changing whitespace to so-called "equivalent" forms involving tabs.  
>
>With the source file and the input file "changed" to avoid tab replacement, the source
>compiles properly and the output seems to be correct, indicating the test is passed.
>Before we consider this a PASS and not a FAIL -- are there any other things to check
>here?  Any reservations about this?  Caveats?

Tab is not a part of the FORTRAN (77, remember) character set, so the sources
should not have any tabs.  I can imagine that some text editors may replace
multiple blanks with tabs, but you must turn that off when dealing with strict
F77 sources.


Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
  http://softwareforums.intel.com/
Intel Fortran Support
  http://developer.intel.com/software/products/support/

Kevin G. Rhoads wrote:

>>Do you mean replacing blanks with tabs in the source?  That sounds like
>>a very non-standard thing to do in any case, but especially in
>>Hollerith strings, as you mention.

> Yes, it appeared that something had replaced blanks with tabs in
> both the source and input files before they got to me.  When
> I changed tabs back to sequences of blanks, everything started
> working correctly.  

I think it was very slightly unclear which way you did the
change, so I wanted to be sure.

> I thought that replacing the tabs with series of blanks was
> thus just undoing something that had been incorrectly done.
> But I wanted to double check with people who are more aware
> of language standards issues.

This came up a few weeks ago, including the discussion about
how some DEC compilers treated tabs, and maybe still do.
At least in F77 and earlier, tabs were definitely not part
of the standard, but some compilers did accept them.

> Thanks for your feedback, I'm sorry if my question wasn't
> very clear.

The question was surprising enough that I wanted to be sure.
Files meant as verification should be extra careful to make
sure that they are not corrupted or otherwise non-standard.

-- glen

Steve Lionel wrote:

> 
> Tab is not a part of the FORTRAN (77, remember) character set, so the sources
> should not have any tabs.  I can imagine that some text editors may replace
> multiple blanks with tabs, but you must turn that off when dealing with strict
> F77 sources.

But then neither is Hollerith a required part of Fortran 77.

IMO the use and testing of Hollerith in a Fortran 77 test suite
is a bug in the test suite.  (Though if the NIST suite is the same
as the one use by the British Standards organisation it was pervasive!)

-- 
-- Jim
--
James Cownie	<jcownie@etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com

James Cownie wrote:

(snip)

> But then neither is Hollerith a required part of Fortran 77.

> IMO the use and testing of Hollerith in a Fortran 77 test suite
> is a bug in the test suite.  (Though if the NIST suite is the same
> as the one use by the British Standards organisation it was pervasive!)

It looks to me like the H format descriptor is part of the F77
standard, but otherwise character constants should be apostrophed
strings.

-- glen

glen herrmannsfeldt wrote:

> It looks to me like the H format descriptor is part of the F77
> standard, but otherwise character constants should be apostrophed
> strings.

IIRC In the test suite I used in the late eighties many of the literal
strings in the code were hollerith constants ;-)

-- 
-- Jim
--
James Cownie	<jcownie@etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com

On Thu, 26 Feb 2004 13:49:25 GMT, James Cownie <jcownie@etnus.com> wrote:


>> It looks to me like the H format descriptor is part of the F77
>> standard, but otherwise character constants should be apostrophed
>> strings.
>
>IIRC In the test suite I used in the late eighties many of the literal
>strings in the code were hollerith constants ;-)

FCVS test FM403 uses the H edit descriptor, not Hollerith constants.



Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
  http://softwareforums.intel.com/
Intel Fortran Support
  http://developer.intel.com/software/products/support/

In article <VTi%b.2575$nZ4.21808274@news-text.cableinet.net>,
James Cownie  <jcownie@etnus.com> wrote:

>IMO the use and testing of Hollerith in a Fortran 77 test suite
>is a bug in the test suite.

Compiler vendors have to compile real user programs, and so we welcome
test suites that test relevant stuff.

-- greg

On Thu, 26 Feb 2004 19:10:22 GMT, lindahl@pbm.com (Greg Lindahl) wrote:

>In article <VTi%b.2575$nZ4.21808274@news-text.cableinet.net>,
>James Cownie  <jcownie@etnus.com> wrote:
>
>>IMO the use and testing of Hollerith in a Fortran 77 test suite
>>is a bug in the test suite.
>
>Compiler vendors have to compile real user programs, and so we welcome
>test suites that test relevant stuff.

In this case, it's a non-issue.  The FCVS tests are strict F77 and are what
NIST was using to certify implementations as conforming to FORTRAN-77.  These
tests do not include language features not in F77, such as Hollerith
constants.  They DO include use of H format edit descriptors, which are part
of the F77 standard.


Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
  http://softwareforums.intel.com/
Intel Fortran Support
  http://developer.intel.com/software/products/support/

"Kevin G. Rhoads" <Kevin.Rhoads@Dartmouth.edu> wrote:

>Yes, it appeared that something had replaced blanks with tabs in
>both the source and input files before they got to me.  When
>I changed tabs back to sequences of blanks, everything started
>working correctly.  

As Steve Lionel mentioned, many editors have a setting that
allows you to do this.  Often it is on by default.  The first
thing one must do when using a new editor is to turn it off.

I suppose this option was meant to save disk space. In the age
of the 120 Gb disk available for $120, I heartily wish that
option would go away.  It causes trouble.


-- 
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.

"Kevin G. Rhoads" <Kevin.Rhoads@Dartmouth.edu> wrote:

>Yes, it appeared that something had replaced blanks with tabs in
>both the source and input files before they got to me.  When
>I changed tabs back to sequences of blanks, everything started
>working correctly.  
>
>I thought that replacing the tabs with series of blanks was
>thus just undoing something that had been incorrectly done.
>But I wanted to double check with people who are more aware
>of language standards issues.

Kevin--

As Steve Lionel mentioned, many editors have a setting that
inserts tabs in place of repeated spaces.  Often the option is
on by default. The first thing I do when using a new editor is
to turn it off.

That feature ranks in usefulness near the "feature" of Windows
that by default supresses the file extensions when displaying
filenames.

I suppose the spaces-to-tabs  option was meant to save disk
space. In the age of the 120 Gb disk for $100, I heartily wish
the option would go away, once and for all.


-- 
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.

Thanks to all who responded both in NG and by e-mail.

I also learned by reading the full threads, and
responses to responses.

Thanks
Kevin