headers
Paul Richard Thomas | 1 Aug 2009 15:50
Picon

Re: [Patch, fortran] PR40011 - Problems with -fwhole-file

At last, after all sorts of trials and tribulations thatcomefrom
trying to this on  vacation:

Sending        gcc/fortran/ChangeLog
Sending        gcc/fortran/error.c
Sending        gcc/fortran/gfortran.h
Sending        gcc/fortran/options.c
Sending        gcc/fortran/parse.c
Sending        gcc/fortran/resolve.c
Sending        gcc/fortran/trans-decl.c
Sending        gcc/fortran/trans-expr.c
Sending        gcc/fortran/trans-types.c
Sending        gcc/testsuite/ChangeLog
Adding         gcc/testsuite/gfortran.dg/whole_file_10.f90
Adding         gcc/testsuite/gfortran.dg/whole_file_11.f90
Adding         gcc/testsuite/gfortran.dg/whole_file_12.f90
Adding         gcc/testsuite/gfortran.dg/whole_file_13.f90
Adding         gcc/testsuite/gfortran.dg/whole_file_14.f90
Adding         gcc/testsuite/gfortran.dg/whole_file_7.f90
Adding         gcc/testsuite/gfortran.dg/whole_file_8.f90
Adding         gcc/testsuite/gfortran.dg/whole_file_9.f90
Transmitting file data ..................
Committed revision 150333.

It should be noted that gfortran.dg/entry_13.f90 fails at -O2 and
higher.  I am sure that it did not do so with the original version of
the patch, so I have lost something in cleaning it up.  I will
investigate.....

Cheers
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jerry DeLisle | 1 Aug 2009 15:53
Picon

[patch,;ibgfortran] PR40853 I/O: Namelist read error

Hi all,

This patch is trivial, though not obvious.

The error occurred when the current name list object, nl, was set back 
to first_nl with this test case.  The current object was at the end of 
the linked list of objects so there are no further objects to match and 
read.  Checking for NULL catches this.

This changes two test cases as well.  The output error messages for 
those cases, 40 and 47, is adjusted. Honestly, I always thought that 
error message was odd before because it included only the name of the 
first_nl.  I just did not "see" it until now.

Regression tested on x86_64-unknown-linux-gnu.  OK for trunk?  I think 
we should also backport to 4.4. [aside: I see at least some major 
distributions now have moved to 4.4, so there may be less value going to 
4.3, but it is an easy patch]

Regards,

Jerry

2009-08-01  Jerry DeLisle <jvdelisle <at> gcc.gnu.org>

     PR libfortran/40853
     * io/list_read.c (nml_get_obj_data): Do not set nl
     pointer to first_nl if nl->next is NULL.

Index: list_read.c
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jerry DeLisle | 1 Aug 2009 15:58
Picon

Re: [patch,libgfortran] PR40853 I/O: Namelist read error

On 08/01/2009 06:53 AM, Jerry DeLisle wrote:
> Hi all,
>
> This patch is trivial, though not obvious.
>
> The error occurred when the current name list object, nl, was set back 
> to first_nl with this test case.  The current object was at the end of 
> the linked list of objects so there are no further objects to match 
> and read.  Checking for NULL catches this.
>
> This changes two test cases as well.  The output error messages for 
> those cases, 40 and 47, is adjusted. Honestly, I always thought that 
> error message was odd before because it included only the name of the 
> first_nl.  I just did not "see" it until now.
>
> Regression tested on x86_64-unknown-linux-gnu.  OK for trunk?  I think 
> we should also backport to 4.4. [aside: I see at least some major 
> distributions now have moved to 4.4, so there may be less value going 
> to 4.3, but it is an easy patch]
>
> Regards,
>
> Jerry
>
> 2009-08-01  Jerry DeLisle <jvdelisle <at> gcc.gnu.org>
>
>     PR libfortran/40853
>     * io/list_read.c (nml_get_obj_data): Do not set nl
>     pointer to first_nl if nl->next is NULL.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Janus Weil | 1 Aug 2009 18:57
Picon
Favicon
Gravatar

[Patch, Fortran] PR 40881: warn for obsolescent features

Hi all,

the Fortran 90 standard lists nine "obsolescent" f77 features, which
continue to be supported in f90, but may be deleted in the future.
Therefore their usage is discouraged by the standard. Currently, we
only warn about two of them (arithmetic if and assumed length
character functions). This patch adds warnings for four more:

* alternate return
* computed goto
* statement functions
* old-style character lengths ["character*..." instead of "character(...)"]

That leaves three obsolescent features, which are not warned about:

* shared DO termination
* DATA statements among executable statements
* fixed form source

These may be added later.

The patch is technically very simple, but has a rather large impact on
the testsuite, since lots of test cases use old-style character
lengths. For most of them I just added -std=legacy. But some already
use -std=f95, so I had to change the character lengths to f90 style or
add a dg-warning. For the already-implemented obsolescent warnings I
changed the message to unify it with the new ones, so I also had to
change some dg-warnings in the testsuite.

Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
(Continue reading)

Permalink | Reply | 28 comments |
headers
Daniel Kraft | 1 Aug 2009 19:13
Picon

Re: [Patch, Fortran] PR 40881: warn for obsolescent features

Hi Janus,

Janus Weil wrote:
> Hi all,
> 
> the Fortran 90 standard lists nine "obsolescent" f77 features, which
> continue to be supported in f90, but may be deleted in the future.
> Therefore their usage is discouraged by the standard. Currently, we
> only warn about two of them (arithmetic if and assumed length
> character functions). This patch adds warnings for four more:
> 
> * alternate return
> * computed goto
> * statement functions
> * old-style character lengths ["character*..." instead of "character(...)"]
> 
> That leaves three obsolescent features, which are not warned about:
> 
> * shared DO termination
> * DATA statements among executable statements
> * fixed form source
> 
> These may be added later.
> 
> The patch is technically very simple, but has a rather large impact on
> the testsuite, since lots of test cases use old-style character
> lengths. For most of them I just added -std=legacy. But some already
> use -std=f95, so I had to change the character lengths to f90 style or
> add a dg-warning. For the already-implemented obsolescent warnings I
> changed the message to unify it with the new ones, so I also had to
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert Dewar | 1 Aug 2009 19:15
Favicon

Re: [Patch, Fortran] PR 40881: warn for obsolescent features

Janus Weil wrote:
> Hi all,
> 
> the Fortran 90 standard lists nine "obsolescent" f77 features, which
> continue to be supported in f90, but may be deleted in the future.
> Therefore their usage is discouraged by the standard. Currently, we
> only warn about two of them (arithmetic if and assumed length
> character functions). This patch adds warnings for four more:

I assume that these warnings can be controlled as a group? It is
not clear you want to warn unconditionally for such usage. And if
anyone thinks these features might actually be removed, they are
deluding themselves. Think back to the attempt to remove the ALTER
verb in COBOL-90. A major company threatened to sue the members of
the standards committee individually, and they backed down :-)
Permalink | Reply | 10 comments |
headers
Janus Weil | 1 Aug 2009 20:13
Picon
Favicon
Gravatar

Re: [Patch, Fortran] PR 40881: warn for obsolescent features

2009/8/1 Robert Dewar <dewar <at> adacore.com>:
> Janus Weil wrote:
>> the Fortran 90 standard lists nine "obsolescent" f77 features, which
>> continue to be supported in f90, but may be deleted in the future.
>> Therefore their usage is discouraged by the standard. Currently, we
>> only warn about two of them (arithmetic if and assumed length
>> character functions). This patch adds warnings for four more:
>
> I assume that these warnings can be controlled as a group? It is
> not clear you want to warn unconditionally for such usage.

The warnings are present for -std=f95 and above (i.e.
f95/f2003/f2008), while -std=legacy turns them off.
Of course this -std=... flags also controls many other stuff, and one
might think about adding and extra -Wobsolete flag in the future, but
this is not yet included in my patch.

> And if anyone thinks these features might actually be removed, they are
> deluding themselves. Think back to the attempt to remove the ALTER
> verb in COBOL-90. A major company threatened to sue the members of
> the standards committee individually, and they backed down :-)

I personally would not have any problem with them getting deleted, but
this is another question.

I just think gfortran should give the same signals to its users as the
Fortran standard does, namely that these features are
obsolete/redundant and can/should be replaced by other features.

Cheers,
(Continue reading)

Permalink | Reply | 4 comments |
headers
Toon Moene | 1 Aug 2009 22:13

Re: [Patch, Fortran] PR 40881: warn for obsolescent features

Janus Weil wrote:

> 2009/8/1 Robert Dewar <dewar <at> adacore.com>:

>> And if anyone thinks these features might actually be removed, they are
>> deluding themselves. 

Sigh, yes we know that.  Vendors are reminding us of that "fact" every 
meeting (hey, I have one coming up in Las Vegas 10-14th of August :-)

> I just think gfortran should give the same signals to its users as the
> Fortran standard does, namely that these features are
> obsolete/redundant and can/should be replaced by other features.

What it means to ordinary users is that the *language community* thinks 
that a certain construct has outlived its shelf live, so you'd better 
not use it.

This *is* a useful message to send (at least to our constituents).

Cheers,

--

-- 
Toon Moene - e-mail: toon <at> moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html
Permalink | Reply | 2 comments |
headers
Robert Dewar | 1 Aug 2009 22:28
Favicon

Re: [Patch, Fortran] PR 40881: warn for obsolescent features

Toon Moene wrote:

> What it means to ordinary users is that the *language community* thinks 
> that a certain construct has outlived its shelf live, so you'd better 
> not use it.

perhaps, to me either something is or is not in the language, and
it is up to users to decide whether to use it, so you can only urge,
not legislate (the word urge always reminds me of the scene in LA
Story, where Patrick Stewart in reply to Steve Martin saying "but
what about my date? I can't tell her what to have", says "No, but
you could *URGE*". :-))
> 
> This *is* a useful message to send (at least to our constituents).

I think it is fine to have a set of warnings, but they should be
turnable off as a group.

We have the same situation in Ada with obsolescent features (annex J)
and there is a switch -gnatwj to activate warnings of any use of these
features (off by default, but most certainly something that some coding
standards could make mandatory).
Permalink | Reply | 0 comments |
headers
Steven Bosscher | 1 Aug 2009 23:47
Picon

Re: [Patch, Fortran] PR 40881: warn for obsolescent features

On Sat, Aug 1, 2009 at 7:15 PM, Robert Dewar<dewar <at> adacore.com> wrote:
> Janus Weil wrote:
>>
>> Hi all,
>>
>> the Fortran 90 standard lists nine "obsolescent" f77 features, which
>> continue to be supported in f90, but may be deleted in the future.
>> Therefore their usage is discouraged by the standard. Currently, we
>> only warn about two of them (arithmetic if and assumed length
>> character functions). This patch adds warnings for four more:
>
> I assume that these warnings can be controlled as a group? It is
> not clear you want to warn unconditionally for such usage. And if
> anyone thinks these features might actually be removed, they are
> deluding themselves. Think back to the attempt to remove the ALTER
> verb in COBOL-90. A major company threatened to sue the members of
> the standards committee individually, and they backed down :-)

Evil comes in many forms and shapes.

Ciao!
Steven
Permalink | Reply | 2 comments |

Gmane