| Summary: | pixman fails to compile with gcc version < 4.7.0 | ||
|---|---|---|---|
| Product: | pixman | Reporter: | U. Artie Eoff <ullysses.a.eoff> |
| Component: | pixman | Assignee: | Søren Sandmann Pedersen <soren.sandmann> |
| Status: | VERIFIED FIXED | QA Contact: | Søren Sandmann Pedersen <soren.sandmann> |
| Severity: | blocker | ||
| Priority: | medium | CC: | darxus, Knut_Petersen, psychon, siarhei.siamashka |
| Version: | git master | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| URL: | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
partially reduced testcase
0001-Workaround-for-FTBS-with-gcc-4.6-http-gcc.gnu.org-PR.patch |
||
|
Description
U. Artie Eoff
2012-10-04 15:30:39 UTC
Created attachment 68094 [details] partially reduced testcase Confirmed with gcc 4.6.3, gcc 4.5 and gcc 4.7 seem to be fine. Tried to reduce the testcase using delta tool (http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction), but reproducibility becomes pretty unstable at some point and even minor changes make the bug go away. This looks like some buggy memory accesses in gcc 4.6.x: $ valgrind gcc-4.6.3 -O1 -c 228.i ==28969== Memcheck, a memory error detector ==28969== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==28969== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==28969== Command: gcc-4.6.3 -O1 -c 228.i ==28969== ==28969== Conditional jump or move depends on uninitialised value(s) ==28969== at 0x4EBA2BB: __GI___strcasecmp_l (strcmp.S:243) ==28969== by 0x4E68F67: bsearch (bsearch.c:38) ==28969== by 0x4E64E1F: _nl_expand_alias (localealias.c:160) ==28969== by 0x4E62F27: _nl_find_domain (finddomain.c:120) ==28969== by 0x4E62765: __dcigettext (dcigettext.c:628) ==28969== by 0x4148E5: gcc_init_libintl (intl.c:63) ==28969== by 0x4028AF: main (gcc.c:6146) ==28969== ==28969== Use of uninitialised value of size 8 ==28969== at 0x4EBC3F4: __GI___strcasecmp_l (strcmp.S:2257) ==28969== by 0x4E68F67: bsearch (bsearch.c:38) ==28969== by 0x4E64E1F: _nl_expand_alias (localealias.c:160) ==28969== by 0x4E62F27: _nl_find_domain (finddomain.c:120) ==28969== by 0x4E62765: __dcigettext (dcigettext.c:628) ==28969== by 0x4148E5: gcc_init_libintl (intl.c:63) ==28969== by 0x4028AF: main (gcc.c:6146) ==28969== ==28969== Use of uninitialised value of size 8 ==28969== at 0x4EBC3F8: __GI___strcasecmp_l (strcmp.S:2258) ==28969== by 0x4E68F67: bsearch (bsearch.c:38) ==28969== by 0x4E64E1F: _nl_expand_alias (localealias.c:160) ==28969== by 0x4E62F27: _nl_find_domain (finddomain.c:120) ==28969== by 0x4E62765: __dcigettext (dcigettext.c:628) ==28969== by 0x4148E5: gcc_init_libintl (intl.c:63) ==28969== by 0x4028AF: main (gcc.c:6146) Before reporting the bug to gcc, it is still needed to also test vanilla gcc 4.6.3 and 4.6 svn branch. But right now I only have a slow Atom netbook which is not very suited for the experiments involving compiling gcc. Will be back home next week to continue with this stuff (unless somebody else takes over). (In reply to comment #1) > This looks like some buggy memory accesses in gcc 4.6.x: > > $ valgrind gcc-4.6.3 -O1 -c 228.i Hmm, or maybe not (valgrind complains for the other gcc versions too and it could be bogus). (In reply to comment #1) > Created attachment 68094 [details] > partially reduced testcase > > Confirmed with gcc 4.6.3, gcc 4.5 and gcc 4.7 seem to be fine. > > Failure confirmed on an opensuse 12.1 system with the distributions gcc 4.6.2 cu, Knut Last good commit is: 7a9c2d586b2349b5e17966a96d7fe8c390abb75a Reported a bug to GCC bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965 So what's the actual plan here to get developers back to the point where they are able to compile pixman on distros that only provide 4.6.x.? Do we wait for GCC to fix the bug in the 4.6.x tree and then hope the distros provide an update package (Fedora 16 and Ubuntu Precise come to mind)? Perhaps we should conditionally work around the issue in pixman for the 4.6.x bug. (In reply to comment #6) > Perhaps we should conditionally work around the issue in pixman for the > 4.6.x bug. I would assume that's the plan. Created attachment 68771 [details] [review] 0001-Workaround-for-FTBS-with-gcc-4.6-http-gcc.gnu.org-PR.patch A possible workaround is attached. Unfortunately (and expectedly) it causes a bunch of functions not to be inlined and indirect calls generated. Running "objdump -d pixman/pixman-combine-float.o | grep call | grep '*'" for GCC 4.6.3 shows indirect call instructions: 1328: ff 54 24 30 callq *0x30(%rsp) 134b: 41 ff d7 callq *%r15 136d: 41 ff d7 callq *%r15 138f: 41 ff d7 callq *%r15 14a5: ff 54 24 30 callq *0x30(%rsp) 14c7: 41 ff d7 callq *%r15 14e8: 41 ff d7 callq *%r15 1509: 41 ff d7 callq *%r15 For clang-3.1, icc-13.0.0, gcc-4.5.4 and gcc 4.7.2 there are no indirect call instructions in this code. Maybe GCC developers can suggest a better solution if we give them a bit of time to look into this issue. (In reply to comment #8) > Created attachment 68771 [details] [review] [review] > 0001-Workaround-for-FTBS-with-gcc-4.6-http-gcc.gnu.org-PR.patch > > A possible workaround is attached. Unfortunately (and expectedly) it causes > a bunch of functions not to be inlined and indirect calls generated. Running > "objdump -d pixman/pixman-combine-float.o | grep call | grep '*'" for GCC > 4.6.3 shows indirect call instructions: > 1328: ff 54 24 30 callq *0x30(%rsp) > 134b: 41 ff d7 callq *%r15 > 136d: 41 ff d7 callq *%r15 > 138f: 41 ff d7 callq *%r15 > 14a5: ff 54 24 30 callq *0x30(%rsp) > 14c7: 41 ff d7 callq *%r15 > 14e8: 41 ff d7 callq *%r15 > 1509: 41 ff d7 callq *%r15 > > For clang-3.1, icc-13.0.0, gcc-4.5.4 and gcc 4.7.2 there are no indirect > call instructions in this code. > > Maybe GCC developers can suggest a better solution if we give them a bit of > time to look into this issue. FWIW, I think this workaround makes sense. The bug seems to be confined to the combination of floating point combiners, which are not used that much yet, and GCC 4.6, which while widespread is only one version of the compiler. I'd prefer a little more information in the commit message though. (In reply to comment #9) > FWIW, I think this workaround makes sense. The bug seems to be confined to > the combination of floating point combiners, which are not used that much > yet, and GCC 4.6, which while widespread is only one version of the compiler. Yes, I just wanted to watch over the progress in the gcc bugtracker a bit longer. Mostly to get a better understanding whether this issue has any chance to be fixed in gcc 4.6.4+ But indeed, the original reporter of this bug might want to have a workaround applied to pixman git sooner. > I'd prefer a little more information in the commit message though. Just replicating the comment "GCC 4.6 has problems with force_inline, so just use normal inline instead" in the commit message and also a link to fdo bug would probably work . (In reply to comment #10) > (In reply to comment #9) > > FWIW, I think this workaround makes sense. The bug seems to be confined to > > the combination of floating point combiners, which are not used that much > > yet, and GCC 4.6, which while widespread is only one version of the compiler. > > Yes, I just wanted to watch over the progress in the gcc bugtracker a bit > longer. Mostly to get a better understanding whether this issue has any > chance to be fixed in gcc 4.6.4+ > > But indeed, the original reporter of this bug might want to have a > workaround applied to pixman git sooner. > Well, after more than two weeks it´s time to include the workaround to the git tree. It is correct, it does not harm anybody, and it can be easily adapted if 4.6.4 would handle force_inline correctly. cu, Knut OK, pushed the workaround patch to pixman git. Thanks for reporting the problem and for your patience while waiting for a solution. Sorry for handling it slower than necessary. Feel free to reopen the bug if the problem persists. Thanks. Fixed in: commit 9df645dfb04b5a790faabe1e9a84fc37287d91b0 Author: Siarhei Siamashka <siarhei.siamashka@gmail.com> Date: Fri Oct 19 01:59:16 2012 +0300 Workaround for FTBFS with gcc 4.6 (http://gcc.gnu.org/PR54965) GCC 4.6 has problems with force_inline, so just use normal inline instead. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=55630 verified fixed |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.