public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
To: Tobias Burnus <tobias@codesourcery.com>
Cc: rep.dot.nop@gmail.com,
	Harald Anlauf via Fortran <fortran@gcc.gnu.org>,
	Harald Anlauf <anlauf@gmx.de>
Subject: Re: [PATCH] PR fortran/63797 - Bogus ambiguous reference to 'sqrt'
Date: Fri, 16 Apr 2021 09:57:08 +0200	[thread overview]
Message-ID: <20210416095708.20bdc1f8@nbbrfq> (raw)
In-Reply-To: <c7d75dd9-ad4a-a009-f191-434d2dd5ba10@codesourcery.com>

On Fri, 16 Apr 2021 09:38:27 +0200
Tobias Burnus <tobias@codesourcery.com> wrote:

> On 16.04.21 09:06, Bernhard Reutner-Fischer via Fortran wrote:
> 
> > Does this change the module format in an incompatible way, i.e. does
> > this require a module format version bump?  
> Not having looked it in detail but I doubt it – it is just a symbol
> which is not output.
> > What happens when we read an existing module that names an intrinsic?
> > Without bumping the module version, we'd run into the same issue as
> > before, don't we?  
> ...
> > Even if we'd skip reading existing intrinsic now, we'd break interop
> > with older compiler versions if we would stop writing them without
> > bumping the module format, i think?  
> 
>  From the function name ("write_symtree"), gfortran only skips writing it;
> it still reads all symtrees which are in the .mod file.
> As this is the only change of Harald's patch, it should be:
> 
> * .mod by old compiler → used by new/old compiler: bogus error for 'sqrt'.
> 
> * .mod by new compiler → used by new/old compiler: works after the patch
> 
> Thus, from that side there should be no issue.

So we'd need to skip (intrinsic) when reading existing modules written
by an older compiler to fix the issue for good, as said.
But maybe that's overkill.

> And I see no point in bumping the .mod version to force the recompilation;
> those running into the corner case can still do 'make clean && make' and
> all others can keep using the old version.

That might not always be possible but admittedly that's a corner case,
yes.

  reply	other threads:[~2021-04-16  7:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-15 20:52 Harald Anlauf
2021-04-16  7:06 ` Bernhard Reutner-Fischer
2021-04-16  7:38   ` Tobias Burnus
2021-04-16  7:57     ` Bernhard Reutner-Fischer [this message]
2021-04-16  8:32   ` Paul Richard Thomas
2021-04-16 11:02     ` Paul Richard Thomas
2021-04-16 14:31       ` Harald Anlauf

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=20210416095708.20bdc1f8@nbbrfq \
    --to=rep.dot.nop@gmail.com \
    --cc=anlauf@gmx.de \
    --cc=fortran@gcc.gnu.org \
    --cc=tobias@codesourcery.com \
    /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).