A literal constant in source code text such as

24615.3838

has the default real type, which is single precision unless you play
with the compiler flags to make the default real type something else.
On most computers[1], single precision means IEEE 754 single precision
which is a 32-bit word containing a sign bit, eight bits of exponent,
and 23 bit significand (sometimes called "mantissa") with an implied
extra leading 1 bit.

We can examine the binary format used to represent this literal
constant with the following test program

subroutine dump_bits(r)
  implicit none
  integer, parameter :: rk = kind(1.0)
  real(kind=rk), intent(in) :: r
  character, dimension(rk) :: bits
  integer :: i

  bits = transfer(r,bits)
  write (6, '(e24.16)', advance='no') r
  write (6, '(1x,24z2.2)', advance='no') (bits(i), i=rk,1,-1) !little-endian
  write (6, *)
end subroutine dump_bits

program literals
  real, parameter :: num = 24615.3838

  call dump_bits(num)
end program literals

When I compile and run this I get

$ ./literals
  0.2461538476562500E+05 46C04EC5

The first number differs significantly from the literal in the source
code text; this has been called "loss of precision" by others in this
forum but for reasons I'll go into below I don't like that term for
this phenomenon.  The second (hexadecimal) number above is the closest
single-precision binary approximation to the literal 24615.3838 in the
source code text and is the constant as it appears in the executable:

$ readelf -x .rodata literals

Hex dump of section '.rodata':
  0x08048a74 6574696c 00000000 00020001 00000003 ............lite
  0x08048a84 2e343265 286f6e00 3039662e 736c6172 rals.f90.no(e24.
  0x08048a94 00002932 2e327a34 322c7831 28293631 16)(1x,24z2.2)..
  0x08048aa4                            46c04ec5 .N.F

(thus for an executable compiled with gfortran; ifort includes lots of
additional text in the .rodata ELF section but you can grep for the
constant).

So, you put the text "24615.3838" in your source code, and the binary
value z'46c04ec5' appears in the read-only data section of the
resulting executable.  Let's break out the bits.  

46c04ec5 is 0100 0110 1100 0000 0100 1110 1100 0101 in binary
            seee eeee emmm mmmm mmmm mmmm mmmm mmmm

In IEEE 754 single precision,

s = 0 (sign is positive)
e = 10001101 = z'8d' (exponent is 14 -- the exponent bias is 127)
m = (1)100 0000 0100 1110 1100 0101 = z'c04ec5'
    (mantissa is 12603077 * 2**(-23))

so we can work out that the constant as stored in the executable is
exactly

12603077 * 2**(-23) * 2**(14) = 12603077 / 512

Note that the internal floating-point representation uses a binary
radix -- the denominator in the fraction above will always be a power
of two.  The decimal value is approximately 24615.3847656.  That was
the closest IEEE 754 single precision number to 24615.3838 that the
compiler could find.  That is the number that is stored in the
read-only data ELF section of your executable when you put
"24615.3838" into the text of your source code.

Note that the IEEE 754 single precision format has a 24 bit mantissa
(the leading 1 bit is implied for non-denormalized numbers), and
2**(-24) is approximately 10**(-7), so you would expect single
precision to correspond to approximately 7 significant decimal
digits.  The number 24615.3838 has nine significant digits, the first
seven of which agree with 24615.3847656.  This is what other posts
have referred to as "loss of precision".  I dislike that term,
however, because the precision was never there in the first place --
the literal constant was always single precision and the compiler has
done an honest job of converting the decimal number to the nearest
binary equivalent.

The number in the executable (12603077 / 512) differs from the number
in the text of the source code (24615.3838) because the radix used to
represent the number in the executable (binary) differs from the radix
used to represent the number in the source code (decimal).  To see
this phenomenon at work choose another number close by and put that in
the example program above:

  real, parameter :: num = 24615.390625

(etc)

$ ./literals
  0.2461539062500000E+05 46C04EC8

Things are looking better according to the first number above, and if
we break out the bits again

46c04ec8 is 0100 0110 1100 0000 0100 1110 1100 1000 in binary
            seee eeee emmm mmmm mmmm mmmm mmmm mmmm

In IEEE 754 single precision,

s = 0 (sign is positive)
e = 10001101 = z'8d' (exponent is 14 -- the exponent bias is 127)
m = (1)100 0000 0100 1110 1100 1000 = z'c04ec8'
    (mantissa is 12603080 * 2**(-23))

so the number is 12603080 / 512 = 24615.390625 *exactly*.  For this
number, we have 11 significant figures, as opposed to the 7
significant figures for 24615.3838.  No "loss of precision" here!

What's the difference?  24615.390625 is representable exactly as a
binary fraction, so in the conversion from decimal to binary radix,
nothing is changed.  24615.3838 isn't representable exactly as a
binary fraction, so the compiler has to choose one nearby and uses
that instead.  I call that "rounding" -- rounding to the nearest
binary fraction.

Why do we tolerate rounding?  For most engineering and scientific
purposes, the decimal literal in your source code is already only an
approximation to some other unknown value.  The decimal radix
conventionally used is, after all, just an accident of evolution -- we
might be a duodecimal society if we had evolved with twelve fingers.
There is really only one area where the decimal values are always the
exact values -- finance.  That is why IBM built decimal floating point
into their mainframes and now the POWER6 processor (that will probably
be the heart of future mainframes).

Finally, a code on "loss of precision".  If I call the radix
conversion phenomenon "rounding", then what is "loss of precision"?  I
consider it a loss of precision when you store a double precision
value into a single precision variable.  That has the potential of
taking a very small normalized number and converting it to a
denormalized number or zero in the narrower format.  So you started
with 53 bits of precision (the number of bits in the mantissa of an
IEEE 754 double precision format) and stuffed it into 24 bits of
precision (the number of bits in the mantissa of single precision).
You have lost precisely 29 bits of precision.  In fact, we could
formally define "loss of precision" using the PRECISION intrinsic in
Fortran -- if the number returned for a value by that intrinsic is
smaller, you have lost precision.

The converse, however, is not generally true -- storing a single
precision value in a double precision variable doesn't gain you back
precision.  To use Richard Maine's phrase: "preicision is like
virginity, once lost it can never be recovered".

Chip