[Bug c/83390] valgrind error in lra_eliminate_regs_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83390 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #9 from David Binderman --- (In reply to Vladimir Makarov from comment #8) > Could you confirm that it is still the problem in your environment. I've had another go at reproducing the problem and I cannot see the problem anymore. Either it never existed or it has been fixed. My apologies for the waste of time.
[Bug c/83390] valgrind error in lra_eliminate_regs_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83390 --- Comment #8 from Vladimir Makarov --- (In reply to David Binderman from comment #0) > A build of today's gcc trunk with valgrind produces this: > > ==8995== Conditional jump or move depends on uninitialised value(s) > ==8995==at 0xA39BBE: lra_eliminate_regs_1 (lra-eliminations.c:403) > ==8995==by 0xA39BBE: eliminate_regs_in_insn(rtx_insn*, bool, bool, long) > (lra-eliminations.c:1114) > ==8995==by 0xA3A147: process_insn_for_elimination > (lra-eliminations.c:1396) > ==8995==by 0xA3A147: lra_eliminate(bool, bool) (lra-eliminations.c:1459) > > svn blame gives us > > 23 vmakarov if (CONST_INT_P (XEXP (x, 1)) && INTVAL (XEXP (x, > 1)) == -offset) > > I suspect local variable offset isn't correct. > > Configure lines are > > ../trunk/configure --prefix=/home/dcb/gcc/results.255572.valgrind \ > --disable-bootstrap \ > --disable-multilib \ > --disable-werror \ > --enable-checking=valgrind \ > --enable-languages=c,c++,fortran > > sed 's/-O2/-O3 -funroll-loops -Wtautological-compare/' < Makefile > > Makefile.tmp > mv Makefile.tmp Makefile > > svn info tells us current revision number is 255572. Sorry, I tried to reproduce it according to these instructions (without and with editing the Makefile) but I've failed. Could you confirm that it is still the problem in your environment.
[Bug c/83390] valgrind error in lra_eliminate_regs_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83390 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #7 from David Malcolm --- Can you reproduce it with a specific source file and specific compilation flags? Thanks.
[Bug c/83390] valgrind error in lra_eliminate_regs_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83390 --- Comment #6 from David Binderman --- (In reply to David Binderman from comment #5) > I'll dig deeper with some more debug statements. I couldn't make much sense of the results, so I tried initialising local variable "offset" at it's declaration to zero. That didn't fix the problem. I still get valgrind errors. To make more sense of the results, for valgrind does defined -= undefined produce undefined ? If so, the debug results indicate that this statement is the one where it goes wrong: offset -= lra_get_insn_recog_data (insn)->sp_offset; which seems to indicate that function lra_get_insn_recog_data is going wrong.
[Bug c/83390] valgrind error in lra_eliminate_regs_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83390 David Binderman changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #5 from David Binderman --- (In reply to David Binderman from comment #4) > If I remove the -funroll-loops the problem goes away. And reappears later in the build. I put some debug statements in: if (full_p && insn != NULL_RTX && ep->to_rtx == stack_pointer_rtx) offset -= lra_get_insn_recog_data (insn)->sp_offset; fprintf( stderr, "dcb: 0 %d\n", XEXP (x, 1)); fprintf( stderr, "dcb: 1 %d\n", CONST_INT_P (XEXP (x, 1))); fprintf( stderr, "dcb: 2 %d\n", INTVAL (XEXP (x, 1))); fprintf( stderr, "dcb: 3 %d\n", -offset); if (CONST_INT_P (XEXP (x, 1)) && INTVAL (XEXP (x, 1)) == -offset) and got a match on the last debug statement, so I confirm that it is local variable "offset" that is going wrong. I'll dig deeper with some more debug statements.
[Bug c/83390] valgrind error in lra_eliminate_regs_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83390 --- Comment #4 from David Binderman --- (In reply to David Binderman from comment #3) > Still going wrong. If I remove the -funroll-loops the problem goes away. $ egrep "^==[0-9]|^Config" mk.out ... Configuring in x86_64-pc-linux-gnu/libquadmath Configuring in x86_64-pc-linux-gnu/libstdc++-v3 $
[Bug c/83390] valgrind error in lra_eliminate_regs_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83390 --- Comment #3 from David Binderman --- (In reply to David Binderman from comment #2) > I'll have a build of latest valgrind, latest gcc and report back in a few > hours. Still going wrong. $ egrep "^==[0-9]|^Config" mk.out ... Configuring in x86_64-pc-linux-gnu/libatomic Configuring in x86_64-pc-linux-gnu/libquadmath ==27746== Conditional jump or move depends on uninitialised value(s) ==27746==at 0xA39C0E: lra_eliminate_regs_1 (lra-eliminations.c:403) ==27746==by 0xA39C0E: eliminate_regs_in_insn(rtx_insn*, bool, bool, long) (l ra-eliminations.c:1114) ==27746==by 0xA3A197: process_insn_for_elimination (lra-eliminations.c:1396) ==27746==by 0xA3A197: lra_eliminate(bool, bool) (lra-eliminations.c:1459) Current gcc revision number gone up to 255576. Architecture is x86_64. Valgrind looks up to date. $ valgrind --version valgrind-3.14.0.GIT $
[Bug c/83390] valgrind error in lra_eliminate_regs_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83390 --- Comment #2 from David Binderman --- (In reply to Markus Trippelsdorf from comment #1) > Note that you need to use valgrind trunk for gcc trunk to avoid false > positives. > See: https://bugs.kde.org/show_bug.cgi?id=387766. I thought I was using latest valgrind, but I am not. Their svn development branch is months out of date. valgrind have moved over from svn to git and I didn't notice. I'll have a build of latest valgrind, latest gcc and report back in a few hours.
[Bug c/83390] valgrind error in lra_eliminate_regs_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83390 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf --- Note that you need to use valgrind trunk for gcc trunk to avoid false positives. See: https://bugs.kde.org/show_bug.cgi?id=387766.
