[arch-general] gcc 4.8 breaking libdrm for me
This is just a heads up notice. I've found gcc 4.8 breaking libdrm on my nouveau nv44 device. When compiled with gcc 4.8 I'm faced with random nouveau related error messages in dmesg. Using new google maps quickly leads to Xorg hanging and finally to Xorg freezing or even crashing. I've seen other Arch people also claiming about random X crashes. Recompiling libdrm with -O0 or other new optimizaions disabled didn't solve it for me so far. But recompiling with a local gcc 4.7.3 makes it stable again. I'm asking for help in tracking this down. We need to find out if a certain part of libdrm has broken code that needs to be fixed. Please everybody with random Xorg crashes try to downgrade to libdrm 2.4.43 (the last one that was built with gcc 4.7) and post your gfx card. And this could also be a gcc 4.8 bug or regression. I've seen almost the same behavior with kernel xfs file system code leading to fs corruption under heavy load: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57436 Then we need to compare assembler code created by gcc 4.7 vs. 4.8. Any suggestion and help is welcome. -Andy
I've built libdrm now with CLANG compiler and so far also no problems. Clean dmesg, no hangs and no glitches over Firefox tabs. I suggest to push a "fixed" package built with clang to testing and report this one to gcc people. Opinions? -Andy
On Sat, Jul 13, 2013 at 1:21 AM, Andreas Radke <andyrtr@archlinux.org> wrote:
I've built libdrm now with CLANG compiler and so far also no problems. Clean dmesg, no hangs and no glitches over Firefox tabs.
I suggest to push a "fixed" package built with clang to testing and report this one to gcc people.
Opinions?
-Andy
Sounds fine to me, we have two production C/C++ compilers in the repositories so there's no need to be blocked by bugs in one. Bisecting gcc and identifying the commit causing the regression would be easier, but also a *huge* time waster :). Comparing the assembly doesn't sound worth doing, if you can't get a nice stack trace to narrow down the problem code.
participants (2)
-
Andreas Radke
-
Daniel Micay