Our ArchLinux distribution gives sort of reproducable file system corruption with all kernels built with gcc 4.8.0 (currently at snapshot 20130502). The same kernel built with gcc 4.7.3 is stable. glibc is 2.17, binutils 2.23.2. Architecture is x86_64. I'm testing only stable long term kernel 3.0.xx branch but kernel 3.8 showed the same error. Our default flags: CPPFLAGS="-D_FORTIFY_SOURCE=2" CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro" The kernel builds well with gcc 4.8.0, the bug I'm running into is this: My server running such a bad compiled kernel hosts a NFSv4 share on a XFS formatted partition. On the same drive my dovecot imap server stores all mails. When marking lots of small files on any fast client as read/unread the server currupts the xfs file system with such messages: imap(andyrtr): Error:maildir_file_do(/mnt/share/andyrtr/Mail/.Mailinglisten.Linux-stable/cur/msg.MFVZBC:2,): Filename keeps changing Usually these are ACL related messages. After a reboot the related mail files are sometimes gone and sometimes can be fixed with xfs_repair. Any idea what this could be and how to track this down? It's a pretty nasty bug in gcc it seems to me. I can provide further info if needed.
(In reply to Andreas Radke from comment #0) > Any idea what this could be and how to track this down? It's a pretty > nasty bug in gcc it seems to me. Jumping to conclusions like that isn't helpful (but unfortunately typical for kernel folk): It *may* be a bug in gcc, but it may just as well be a bug in the kernel. Relying on undefined behavior or stuff like that. Have you looked at some of the caveats in the GCC 4.8 relase notes? (See http://gcc.gnu.org/gcc-4.8/changes.html). The problem you're seeing could be related to the aggressive loop optimizations that GCC 4.8 has enabled. You could try -fno-aggressive-loop-optimizations. (IIRC it's enabled by default in recent linux kernel configurations, but I'm not sure.) Another common problem is alias violations. You could try compiling with -Wstrict-aliasing=2 and see if there are any real alias rules violations. If that all fails, you could try compile individual files (or all of XFS, perhaps) with -O1 or even just -O0, try to isolate the file that causes the breakage, and start comparing assembly. All that, assuming you have a file system you can repeatedly wreck, of course :-)
Waiting on a testcase.
I moved away from XFS file system and so can't reproduce it anymore. The bug should be in XFS code probably triggering a change in gcc behavior. Feel free to close this one. note: we had a similar issue in libdrm. maybe it's related or not. this one is now fixed: http://cgit.freedesktop.org/mesa/drm/commit/?id=482abbfafb56cbceaf5355c026434e638cddd0f1
(In reply to Andreas Radke from comment #3) > note: we had a similar issue in libdrm. maybe it's related or not. this one > is now fixed: > http://cgit.freedesktop.org/mesa/drm/commit/ > ?id=482abbfafb56cbceaf5355c026434e638cddd0f1 That is undefined behavior. If that happens to be the same issue in XFS then it is a bug in the source of XFS and not GCC. Closing as invalid.