http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54405
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |MOVED
--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-09-06
14:07:02 UTC ---
Edouard Canot: Thanks for the bug report!
(In reply to comment #2)
> This is a GDB only reverse-execution bug, filed now as:
> http://sourceware.org/bugzilla/show_bug.cgi?id=14548
Thanks Jan for analyzing this bug - and for creating a draft patch at gdb
bugzilla.
As it is not a GCC bug, I close now this PR.
(In reply to comment #3)
> It happened because gfortran >= 4.6 uses this function and GDB cannot
> reverse-step-over such jmp-only function.
> (gdb) disass _gfortran_transfer_real_write
> Dump of assembler code for function _gfortran_transfer_real_write:
> 0x00007ffff7b9f930 <+0>: jmpq 0x7ffff7ae0a30
> <_gfortran_transfer_real@plt>
Side note: The reason that gfortran uses the function
_gfortran_transfer_real_write which directly calls _gfortran_transfer_real is
that it allows to mark the arguments to the function as only being read and not
modified, which allows for optimizations.
Example:
i = 5
write (*,*) i
if (i /= 5) then ... ! < this conditional block can be removed
while for
read (*,*) i
it couldn't. Previously, read and write called _gfortran_transfer_real, the
former now goes through the wrapper and which has the read-only attributes.
