Recursive parameter definition
James Van Buskirk
program recursive_parameter
implicit none
integer, parameter :: dp = kind(1.0_dp)
write(*,*) dp
end program recursive_parameter
C:\gfortran\clf\recursive_parameter>gfortran
recursive_parameter.f90 -orecursive
_parameter
f951.exe: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Glen Herrmannsfeldt
(snip)
> integer, parameter :: dp = kind(1.0_dp)
(snip)
> f951.exe: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
That is pretty good. I wonder why you decided to even try it?
I used to be pretty good at finding compiler bugs, trying
things that many people would never think of, but I don't
think I would have ever thought about trying that one.
-- glen
paul.rich...@gmail.com
> James Van Buskirk wrote:
This is PR39334 in Bugzilla - I have a fix regression testing.
Thanks for finding that one.
Paul
Arjan
definitions, it was allowed to do:
1 = 0
He always keeps trying to see if a compiler still honours this one...
A.
Gordon Sande
Perhaps a few words got dropped and the real statement is that something
equivalent to "1 = 0" could be done by accident. It was and still is an
nonconforming program. Same error can still be done with some systems if
one tries.
The usual form of this error involves a subroutine call with literals
as arguments and assignment to arguments.
The trouble with these urban legend type statements is that a few details get
lost in the retelling. Invalid programs can do the most bizare things. But then
false premises can be used to provide logical proofs of anything, ;-)
Richard Maine
> On 2009-03-01 16:56:43 -0400, Arjan <arjan.v...@rivm.nl> said:
>
> > I have a colleague who claims that, according to old fortran language
> > definitions, it was allowed to do:
> >
> > 1 = 0
>
> Perhaps a few words got dropped and the real statement is that something
> equivalent to "1 = 0" could be done by accident. It was and still is an
> nonconforming program. Same error can still be done with some systems if
> one tries.
>
> The usual form of this error involves a subroutine call with literals
> as arguments and assignment to arguments.
That would be my guess as to what was being referred to. But if so, as
Gordon suggests, the meaning got twisted enough to completely obscure
the original. At least I (and apparently Gordon) can reconstruct a
plausible path back to what might have originally been said. A true
statement is that invalid Fortran code (with literals as actual
arguments to subroutines, as Gordon mentions) in some compilers could
have the effect of changing the values subsequently used for literal
constants.
One might, I suppose, describe that as being like doing 1=0. But there
has never been any version of Fortran which, under even the most twisted
interpretation, actually allowed assignment statement syntax such as
1=0.
Thus this reading would involve two errors in the above claim. The first
error would be in stating that it was "allowed". The practice was never
allowed, but rather was an undiagnosed error with "unusual" effects on
some compilers. The second error would be that it was not this syntax at
all. One might use this syntax to describe the effect, but the compiler
would not have accepted that as code.
Whether you misunderstood exactly what your colleague said, he in turn
misunderstood what someone else said to him/her, or the misunderstanding
occurred somewhere earlier, I can't say. But I'm pretty confident in
claiming that the end result above is wrong.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Larry Gates
> C:\gfortran\clf\recursive_parameter>type recursive_parameter.f90
> program recursive_parameter
> implicit none
> integer, parameter :: dp = kind(1.0_dp)
>
> write(*,*) dp
> end program recursive_parameter
>
> C:\gfortran\clf\recursive_parameter>gfortran
> recursive_parameter.f90 -orecursive
> _parameter
> f951.exe: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
I notice f951.exe, which is located at the outermost branch of the libexec
directory. Why is it there and what does it do?
--
larry gates
Well, some of that relates to the fact that last year I basically
had to take half a year off to participate in various non-optional
gastric revisions.
-- Larry Wall in <20040226192...@wall.org>
James Van Buskirk
news:2a111630-09f7-4de7...@e18g2000yqo.googlegroups.com...
> > James Van Buskirk wrote:
> This is PR39334 in Bugzilla - I have a fix regression testing.
> Thanks for finding that one.
Thanks for fixing it so quickly. Usually I would write out
something like:
integer, parameter :: dp = selected_real_kind(15,300)
but I was in a hurry, so I should have written:
integer, parameter :: dp = kind(1.0d0)
but I habitually use _dp instead of d0 to specify double precision
so it came out:
integer, parameter :: dp = kind(1.0_dp)
The ICE meant that the compiler wasn't able to inform me what
line out of a couple dozen was in error, so I had to use another
compiler (ifort) to find out, given that I didn't wish to take time
to scan the whole program for syntax errors. Just wanted to show
how this kind of bug can be encountered in the wild.
Jan Vorbrüggen
> directory. Why is it there and what does it do?
That's the executable of the compiler as such - note that in good Unix
tradition, gfortran is a compiler driver, sort of a miniature make with
fixed rules, which then calls (among others) the compiler proper to do
the actual work.
Jan
Larry Gates
Consequently, the /libexec/ path is necessary. g95 doesn't have a
/libexec/ directory.
--
larry gates
Down that path lies madness. On the other hand, the road to hell is
paved with melting snowballs.
-- Larry Wall in <1992Jul2.2...@netlabs.com>
robin
news:goeh00$n6c$1...@news.motzarella.org...
> C:\gfortran\clf\recursive_parameter>type recursive_parameter.f90
> program recursive_parameter
> implicit none
> integer, parameter :: dp = kind(1.0_dp)
>
> write(*,*) dp
> end program recursive_parameter
> C:\gfortran\clf\recursive_parameter>gfortran
> recursive_parameter.f90 -orecursive
> _parameter
> f951.exe: internal compiler error: Segmentation fault
> Please submit a full bug report,
You need to follow the directions from your compiler,
instead of posting here.