[Bug c/11173] (lseek (0, 0L, SEEK_CUR) < 0) is ALWAYS false, even if lseek IS negative

["hp at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11173


hp@gcc.gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


------- Additional Comments From hp@gcc.gnu.org  2003-06-12 16:01 -------
Note that this code is apparently compiled with the equivalence of
-D_FILE_OFFSET_BITS=64 (defined in bash auto-host.h or equivalent).
Glibc was reported as "a patched glibc-2.3.1" but also that the problem is
repeatable with a much earlier glibc, so that seems a red herring.


Reporter mentioned in private that things work if the lseek call is changed
to (((int)lseek (0, 0L, SEEK_CUR)) < 0) which seemed to indicate a problem with
DImode patterns at the return from the call to lseek64.  However, the assembly
code at call and return from lseek64 looks sane and works.  I'm leaning towards
miscompilation of, or bug in, glibc.

Uwe, you mentioned you wrote a test-program but the problem wasn't
visible there.  Can you reproduce the problem if you compile that program with
"-D_FILE_OFFSET_BITS=64"?  (If so, please attach the test-program to this
report.)  Thanks.