This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/18089] [4.0 regression] Valgrind errors in real.c
- From: "jakub at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 14 Jan 2005 18:35:02 -0000
- Subject: [Bug middle-end/18089] [4.0 regression] Valgrind errors in real.c
- References: <20041020200011.18089.drow@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From jakub at gcc dot gnu dot org 2005-01-14 18:35 -------
Are you sure this is not just a bug in valgrind?
I have verified that with current CVS I get
ERROR SUMMARY: 37 errors from 21 contexts (suppressed: 12 from 1)
while if I rebuild stage1's combine.o with Roger's patch backed out, link new
stage1 cc1, then rebuild stage2's real.o with the new stage1 cc1 and link new
stage2 cc1, I get
ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 1)
I did a binary search on real.s and e.g. one of the valgrind errors is triggered
by following change in real.s:
@@ -6453,8 +6453,8 @@ round_for_format:
.p2align 2,,3
.L997:
movl (%ebp), %eax
+ subl $-2147483648, %eax
shrl $5, %eax
- xorl $67108864, %eax
subl $67108864, %eax
cmpl %eax, 32(%esp)
jge .L979
With the xorl there are no errors, with subl there is one error.
But I don't see any functional difference between these two.
If I replace 28 occurences of these subl $0x80000000, %eax before >> 5 to
xorl $0x4000000, %eax after >> 5 (I left out encoders/decoders of non-ieee
formats), valgrind stops reporting any errors.
So to me this looks like valgrind not handling subl $0x80000000, %eax
instruction correctly.
Do you agree?
I used valgrind 2.2.0.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18089