[arch-dev-public] 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
Well done narrowing the issue down. I haven't had the chance to compare the assembly output yet, but does it work if you compile with -fno-aggressive-loop-optimizations? Ref: http://postgresql.1045698.n5.nabble.com/Back-branches-vs-gcc-4-8-0-td5750997... - Alexander / xyproto
Am Sat, 13 Jul 2013 08:45:38 +0200
schrieb Alexander Rødseth
Well done narrowing the issue down. I haven't had the chance to compare the assembly output yet, but does it work if you compile with -fno-aggressive-loop-optimizations? Ref: http://postgresql.1045698.n5.nabble.com/Back-branches-vs-gcc-4-8-0-td5750997...
- Alexander / xyproto
No. I've tried this one already and it doesn't fix it. When built with -O0 all optimization should be turned off and it's still failing. I guess I should build libdrm with gcc 4.7 and 4.8 both with -O0 and compare the full trees with meld. -Andy
Uploaded tarballs with gcc47 and 48 with -O0 and -save-temps: https://docs.google.com/file/d/0B8HSjV2qdYV1VXhmdnlxc29RZDQ/edit?usp=sharing https://docs.google.com/file/d/0B8HSjV2qdYV1aE80NWh4S1Yzdlk/edit?usp=sharing Feel free to run meld over .s files. -Andy
On 13/07/13 17:40, Andreas Radke wrote:
Uploaded tarballs with gcc47 and 48 with -O0 and -save-temps:
https://docs.google.com/file/d/0B8HSjV2qdYV1VXhmdnlxc29RZDQ/edit?usp=sharing https://docs.google.com/file/d/0B8HSjV2qdYV1aE80NWh4S1Yzdlk/edit?usp=sharing
Feel free to run meld over .s files.
The first thing to be done is to limit the issue to a single file. I.e. which file do you need to compile with gcc-4.8 to generate the issue. You could also bisect gcc to find the broken commit. The gcc-git PKGBUILD in the AUR will bisect quite easily (add #commit=xxxxxx at the end of the source) if you uncomment the lines after the "XXX" markers. Building with --nocheck will not take too long to build. Allan
I've bisected gcc and found this commit breaking it for me: http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=32b227ebedc3dde524cdbb3bfa7ccbc... I've sent a mail to the gcc-help list with cc to the gcc commit author and some libdrm and nouveau guys. Let's see if someone can help. -Andy
On Sat, Jul 13, 2013 at 1:21 AM, Andreas Radke
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 (4)
-
Alexander Rødseth
-
Allan McRae
-
Andreas Radke
-
Daniel Micay