| Summary: | valgrind-3.4.0 failure w/ gcc-4.4 -O3 (m_libcassert.c:140: Error: symbol `m_libcassert_get_ip' is already defined) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ryan Hill (RETIRED) <rhill> |
| Component: | [OLD] GCC Porting | Assignee: | Maurice van der Pot (RETIRED) <griffon26> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alexxy, esigra, griffon26, jlp.bugs, sleeperseven |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 249226 | ||
| Attachments: |
m_libcasse.tmp.halo.25754.s
m_libcasse.tmp.halo.26391.fno-ipa-cp-clone.s |
||
|
Description
Ryan Hill (RETIRED)
2009-03-01 23:08:11 UTC
worked around in gcc-porting overlay by always replacing -O3 w/ -O2. leave this bug open until i find a proper fix. The optimization flag that triggers the fail is -fipa-cp-clone, so CFLAGS of -O3 -fno-ipa-cp-clone builds successfully. Confirm that the problem persists in valgrind-3.4.1. Workaround is to put this in the ebuild:
if [ "$(gcc-version)" == "4.4" ]; then
append-flags -fno-ipa-cp-clone
fi
Created attachment 183810 [details]
m_libcasse.tmp.halo.25754.s
Created attachment 183816 [details]
m_libcasse.tmp.halo.26391.fno-ipa-cp-clone.s
Begin forwarded message: Date: Tue, 03 Mar 2009 16:51:58 -0800 From: Ian Lance Taylor <iant@google.com> To: Ryan Hill <dirtyepic@gentoo.org> Cc: gcc-help@gcc.gnu.org Subject: Re: -fipa-cp-clone and valgrind Ryan Hill <dirtyepic@gentoo.org> writes: > I recently hit an error while building valgrind-3.4.0 with -O3 using > trunk (-r144460): > > x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../coregrind -I.. > -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux > -I../include -I../VEX/pub -DVG_PLATFORM="\"x86-linux\"" -DVGA_x86=1 > -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/usr/lib64/valgrind"\" > -m32 -fno-stack-protector -O2 -g -Wmissing-prototypes -Wall -Wshadow > -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations > -Wno-format-zero-length -fno-strict-aliasing -O3 -march=core2 -pipe > -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement > -fno-stack-protector -MT libcoregrind_x86_linux_a-m_libcassert.o -MD > -MP -MF .deps/libcoregrind_x86_linux_a-m_libcassert.Tpo -c -o > libcoregrind_x86_linux_a-m_libcassert.o `test -f 'm_libcassert.c' || > echo > > './'`m_libcassert.c m_libcassert.c: Assembler messages: > m_libcassert.c:140: Error: symbol `m_libcassert_get_ip' is already > defined > make[3]: *** [libcoregrind_x86_linux_a-m_libcassert.o] Error 1 > make[3]: Leaving directory > `/var/tmp/portage/dev-util/valgrind-3.4.0/work/valgrind-3.4.0/coregrind' > > > The error was narrowed down to the use of -fipa-cp-clone. > > The code in question is: > > 48 #if defined(VGP_x86_linux) > 49 # define GET_REAL_PC_SP_AND_FP(pc, sp, fp) \ > 50 asm("call m_libcassert_get_ip;" \ > 51 "m_libcassert_get_ip: popl %0;" \ > 52 "movl %%esp, %1;" \ > 53 "movl %%ebp, %2;" \ > 54 : "=r" (pc),\ > 55 "=r" (sp),\ > 56 "=r" (fp)); > > > My question is, is this expected? Is this a gcc bug, a valgrind bug, > or the natural result of me doing something silly like trying to > compile valgrind w/ -O3? I would say that this is a valgrind bug, a misuse of inline asm. gcc never promises that it will only emit one instance of the asm, especially if, as here, the asm is not volatile. Instead of using a symbol name, the code should use a forward label, as in call 1f; 1: popl %0 Or it should use some other technique to ensure a unique name. Ian I've sent a mail to the valgrind-developers mailing list. Let's see if they are willing to fix issues like these or if I should maintain patches for them. Maurice, I saw the initial replies to your mail on the valgrind list. Was there ever any followup? Needless to say, the problem persists in valgrind-3.4.1-r1. I checked in the fix. -r1 should work now. |