--- Comment #7 from milan at cmm dot ki dot si 2007-02-04 22:56 ---
Subject: Re: equivalence modifies common block
> "pault" == pault at gcc dot gnu dot org <[EMAIL PROTECTED]> writes:
pault> --- Comment #6 from pault at gcc dot gnu dot org
pault> 2007-02-04 12:03
--- Comment #6 from pault at gcc dot gnu dot org 2007-02-04 12:03 ---
I think that we can close this one, OK?
I've marked it as "invalid", although that seems a trifle unfair.
Please feel post bugs if you find them - we would rather discuss PRs like this
one than have disatisfied users
--- Comment #5 from kargl at gcc dot gnu dot org 2007-02-04 02:26 ---
(In reply to comment #4)
> OK, maybe gfortran is right.
It isn't that gfortran is right or wrong. :-)
The -fdefault-integer-8 changes the default integer kind to
an 8 byte integer. The default real kind is still 4 b
--- Comment #4 from milan at cmm dot ki dot si 2007-02-04 00:13 ---
OK, maybe gfortran is right. It doesn't make much sense to me, but this is what
I found from wikipedia links in its fortran entry:
"Variables and arrays in common blocks can appear in EQUIVALENCE statements but
this has
--- Comment #3 from milan at cmm dot ki dot si 2007-02-03 23:52 ---
I am sorry for misunderstanding the program. I just took out of something big,
to show some weird behavior of COMMON and EQUIVALENCE. As you can imagine
-fdefault-integer-8 trick is the only solution to make those old 1
--- Comment #2 from kargl at gcc dot gnu dot org 2007-02-03 19:59 ---
This is an invalid bug report. -fdefault-integer-8 doesn't
do what you think it does. If you use this option and equivalence
is present in the code, then you invariably want to use
-fdefault-real-8.
--
kargl at g
--- Comment #1 from pault at gcc dot gnu dot org 2007-02-03 16:11 ---
> Apparently the address of lenstr gets shifted in the subroutine because of the
> equivalence statement. Is this the right behavior?
This is what happens with my amd84:
$ /irun/bin/gfortran --version
GNU Fortran 95
