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: [PATCH, Fortran] Four small DEC extensions


On 10/13/2016 01:01 PM, Fritz Reese wrote:
On Thu, Oct 13, 2016 at 2:24 PM, Jerry DeLisle <jvdelisle@charter.net> wrote:
On 10/12/2016 05:30 AM, Fritz Reese wrote:

Here I submit for review four small extensions to the GNU Fortran
frontend for compatibility with legacy code. I figure it might be a
nice change of pace from my larger patches. Never fear, for I have
more large patches to come, which I will continue to submit
one-at-a-time.

Each extension is enabled with its own compile flag, and each are
enabled along with -fdec. They are fairly self-explanatory.
...
By the way, you may be thinking of -fdec-all that will grab all these dec
extensions, or maybe just use one for all like -fdec and not have so many flags.

I wonder if we should add a flag called -floose-as-a-goose and just turn off
all checks. ;)

Funny you mention it.... An earlier stage of my extensions contained
(by request) an "-flazy-types" which basically did just that. I'm
pretty sure I ripped out half the resolution phase for it, from errors
in type conversions to argument type mismatches and more... Yuck!
Thankfully I was able to toss that flag in place of some more
reasonable ones eventually.

...
OK for trunk?

Not yet, generally, I don't think we need so many compiler flags. We should
probably think about this as far as the other extensions you have already
committed.

The goal of these extensions is to allow GNU Fortran to compile a
legacy codebase which compiles "fine" with another legacy compiler
(e.g. pfc or ifort). Therefore in my mind the typical use case of the
extensions is just to enable them all, which is why I made "-fdec"
from the beginning. (Not that I encourage such crippling ignorance in
a compiler- rather I am just responding to demands for these
compatibility extensions, where they seem reasonable.)

When I originally proposed the extensions on the mailing list here I
got the impression that some folks were concerned about some
extensions affecting default behavior of the compiler and wanted the
ability to selectively enable them. My gut reaction was to just use a
new flag for every extension to make such people happy - maybe that is
overkill.

I certainly don't mind squashing some flags and rolling them in with
-std=legacy/gnu or even just -fdec if there is a consensus on the
issue. I am curious to see what others think.

---
Fritz Reese


Of the four in this patch, TYPE is the only one that I am uncomfortable with so maybe it should be behind -fdec, The other three seem minor to me, especially the LF, I dont think LF needs a flag.

I am sure others will chime in.

For clarity, so far we have:

flag_dec_intrinsic_ints
flag_dec_structure
flag_dec_static
flag_dec_math
flag_dec

and you were thinking about:

-fdec-feed] Treat form feed characters as whitespace.
-fdec-type-print  Treat TYPE as an alias for PRINT where applicable.
-fdec-loc-rval]
-fdec-logical-xor

I would go with putting latter 3 just under -fdec and no flag for LF whitespace.

Jerry


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