Date: Sat, 16 Mar 1996 14:18:45 +1100 From: Bruce Evans <bde@zeta.org.au> To: current@freebsd.org, nate@sri.MT.net Subject: Re: GCC fix for long long comparisons Message-ID: <199603160318.OAA31131@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>jtc
>Fri Mar 15 17:55:55 EST 1996
>Update of /a/cvsroot/src/gnu/usr.bin/gcc/common
>In directory pain.lcs.mit.edu:/b/tmp/cvs-serv1780
>Modified Files:
> expmed.c
>Log Message:
>Patch from J"orn Rennecke that fixes code generation bugs with long
>long comparisons. As of this date, this change hasn't made it into
>the development sources. We must consider this when it comes time
>to integrate a newer gcc release.
>Thu Mar 7 01:16:23 1996 J"orn Rennecke (amylaar@meolyon.hanse.de)
> * expmed.c (negate_rtx): Don't negate LONG_MIN if mode is wider
> than HOST_WIDE_INT.
I think this bug is invoked in our strtouq.c:
#include <stdlib.h>
#include <stdio.h>
main() { printf("%qu\n", strtouq("12345678901", 0, 0)); }
prints a number completely unrelated to 12345678901.
strtouq.c uses UQUAD_MAX, but the funky expressions for UQUAD_MAX
(which is used to work around bugs in very old versions of gcc) sometimes
invokes the bug.
This seems to be fixed in a different way in gcc-2.7.2. strtouq() works
when compiled by gcc-2.7.2.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603160318.OAA31131>