public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rimvydas.jas at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
Date: Sun, 11 Dec 2022 10:29:30 +0000	[thread overview]
Message-ID: <bug-81615-4-PeqpEqMOvX@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-81615-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615

Rimvydas (RJ) <rimvydas.jas at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rimvydas.jas at gmail dot com

--- Comment #16 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
Created attachment 54063
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54063&action=edit
rename intermediate extensions to .fi or .fii

Emitting intermediate files using plain foo.f90 form is a very annoying issue
when trying to modernize archaic codebases to be used in current projects and
it really helps when intermediate files could be saved without disturbing used
native build system habitat.  Consider the following:
$ cat bar.F
       SUBROUTINEABINIT PART 2( ARGU
     x                          MENT)
       E N D S   U   B   R   O   U   T   I   N  E
$ gfortran --save-temps -c bar.F
$ gfortran -c bar.s
$ gfortran -c bar.f90
bar.F:1:8:

    1 |        SUBROUTINEABINIT PART 2( ARGU
      |        1
Error: Unclassifiable statement at (1)

This shows that intermediate Fortran source produced cannot be used again
because of fixed/free form differences while assembly file is fine.  There are
N+K build system variants that do crazy and wonderful things like
filtering/substituting flags, redirecting STDERR/STDOUT for cleaner warning
messages, silently moving sources and objects with strange rules, hiding
compilation lines in python scripts, substituting symbol names in assembly
files and even substituting names in source code on the fly to solve symbol
conflicts between contrib codebases using sed(1) or heavy cpp(1).  So sometimes
it is simply easier to modify the compiler and recompile (after all it does not
take long for gcc).
Attached is a simple diff variant that uses F77/F90+ to emit .fi/.fii
intermediate source files accordingly (inspired by what ObjC/ObjC++ do with
intermediates .mi/.mii files).  Such small change really helped to
double/triple crosscheck very complicated project with mixed F77/F90 using
sometimes crazy cpp(1) macros for the "hooks".  Using .fii extension for all
sources of .F90/.F95/.F03/.F08/.Fyz seems like a logical solution.

  parent reply	other threads:[~2022-12-11 10:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-81615-4@http.gcc.gnu.org/bugzilla/>
2022-12-08 15:58 ` barrowes at alum dot mit.edu
2022-12-08 16:44 ` jakub at gcc dot gnu.org
2022-12-08 17:35 ` barrowes at alum dot mit.edu
2022-12-08 17:38 ` jakub at gcc dot gnu.org
2022-12-08 17:43 ` barrowes at alum dot mit.edu
2022-12-08 22:11 ` kargl at gcc dot gnu.org
2022-12-09  1:50 ` barrowes at alum dot mit.edu
2022-12-09  2:45 ` sgk at troutmask dot apl.washington.edu
2022-12-09 13:25 ` barrowes at alum dot mit.edu
2022-12-09 19:34 ` kargl at gcc dot gnu.org
2022-12-10  1:47 ` barrowes at alum dot mit.edu
2022-12-10  2:04 ` sgk at troutmask dot apl.washington.edu
2022-12-11 10:29 ` rimvydas.jas at gmail dot com [this message]
2023-12-19 13:29 ` acoplan at gcc dot gnu.org
2023-12-19 19:50 ` anlauf at gcc dot gnu.org
2023-12-19 20:04 ` jvdelisle at gcc dot gnu.org
2023-12-19 20:10 ` anlauf at gcc dot gnu.org
2023-12-20 19:24 ` cvs-commit at gcc dot gnu.org
2023-12-28 20:22 ` cvs-commit at gcc dot gnu.org
2023-12-29 20:26 ` anlauf at gcc dot gnu.org
2024-01-02  9:26 ` acoplan at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-81615-4-PeqpEqMOvX@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).