This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Namelist IOSTAT behaviour
- From: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Paul Thomas <Paul dot Thomas at jet dot efda dot org>
- Cc: "'fortran at gcc dot gnu dot org'" <fortran at gcc dot gnu dot org>
- Date: Wed, 15 Jun 2005 19:12:27 -0700
- Subject: Re: Namelist IOSTAT behaviour
- References: <B849B0C2C1873A44A76FA08A26885A367298C8@ntsrv-privmail.jet.uk>
On Thu, Jun 16, 2005 at 01:56:26AM +0100, Paul Thomas wrote:
> Steve,
>
> > looking at a problem with "USE, only : a => z, b => z" where
> > the "b => z" causes an ICE because the "a => z" removes z from
> > the symbols in the module.
>
> I think that I can fix that but is it legal? It's a bit bizarre to tie two
> host symbols to one module variable, isn't it? Is there an associated PR?
>
PR 18878. AFAIK, yes, it's legal. I found the problem because I have
a module that I use to set kinds. The typical
use kinds , only : sp => single, dp => double
one of my programs was acting up and to check that the single
precision part wasn't going unstable, I did
use kinds , only : sp => double, dp => double
Lo and behold, gfortran barfed at every use of dp.
> > I also tried to understand the
> > problem with EQUIVALENCE in modules. I gave up. ;-(
>
> This looks as if it is a problem of logic in trans_decl.c, rather than in
> module.c. The error is generated because the equivalenced variable is found
> to already have a backend_decl by the time gfc_create_module_variable is
> called. I'll have a poke around; the odd thing is that it was a bug that
> appeared.
Hmmm. I never made to trans-decl.c. I was stuck in module.c land.
> In a similar vein, PR19561 seems to have done the opposite and fixed itself
> spontaneously. Is somebody owning up or is this due to Tobi's and my
> rummaging around with dereferencing? Either way, I propose to write a test
> case so that it is nailed to the floor.
Yes, we should generate a test case. Mysterious fixes are better
than mysterious regressions.
--
Steve