Bug 48693

Summary: -O2 optimization breaks 32 bit wine 3D on 64 bit system
Product: Mesa Reporter: Christoph Haag <haagch>
Component: Drivers/Gallium/r600Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED DUPLICATE QA Contact:
Severity: normal    
Priority: medium CC: alexandre.f.demers, thomas.lindroth
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: furmark crash in wine, mesa compiled with CFLAGS="-O2"

Description Christoph Haag 2012-04-14 10:28:39 UTC
Created attachment 59983 [details]
furmark crash in wine, mesa compiled with CFLAGS="-O2"

So I had this bug across some gcc versions and mesa versions (since about the time llvm 3.0 came out) and I figured I should probably report it since it didn't go away until now.

I'm on a notebook with Redwood, HD 6550M with current libdrm git, mesa git, xf86-video-ati git, gcc (GCC) 4.7.0 20120407.


The problem is this:
If I compile mesa with CFLAGS="-O2" I immedately get a crash in all (32 bit) 3D applications/games I have tested in wine (before even displaying the main window). An example is furmark, see attachment.

It tries to access an apparently invalid address at 0x7cae670a and at this position there is r600_dri.so.


If I compile mesa with CFLAGS="-O1" (or "-Os") this does not happen. In fact, if I install mesa compiled with "-O2" and only replace /usr/lib32/xorg/modules/dri/r600_dri.so with one from a mesa build compiled with "-O1" it also works.

Another curiosity is that when I do this:
 ~/.wine/drive_c/FurMark % WINEDEBUG=+all wine FurMark.exe &> /dev/null
then I get the same crash, as expected.
But when I do this:
 ~/.wine/drive_c/FurMark % WINEDEBUG=+all wine FurMark.exe &> furmarkdebug.txt
it starts fine to the main window. Only later, when clicking on benchmark, I get a very similar crash to the above.


Native 32 bit games work fine with an "-O2" compiled mesa. Internal wine programs like regedit, explorer or wine internet explorer work also.

If you can tell me how I can obtain more information about this obscure bug I will gladly do.
Comment 1 Alexandre Demers 2012-04-14 11:38:05 UTC
It looks similar to what I'm experiencing over here. I'm also available to help. Christoph, was this problem reported under Arch?
Comment 2 Christoph Haag 2012-04-14 12:33:27 UTC
(In reply to comment #1)
> It looks similar to what I'm experiencing over here. I'm also available to
> help. Christoph, was this problem reported under Arch?

I'm on archlinux, yes.

I believe there were several problems at the same time.

1) https://bugs.archlinux.org/task/27645
linked to https://bugs.freedesktop.org/show_bug.cgi?id=44466
Which is NOT the issue I have now.

2) https://bugs.archlinux.org/task/28527
links to http://bugs.winehq.org/show_bug.cgi?id=29982 which then links back to 1) and http://llvm.org/bugs/show_bug.cgi?id=12151
and https://bugs.freedesktop.org/show_bug.cgi?id=41791
and https://bugzilla.novell.com/show_bug.cgi?id=747333
They could all be related but nobody seems to know anything for sure.

It often comes up that DRAW_USE_LLVM=0 may be helping but for me it does definitely not.
Some time ago I even tried compiling mesa with --disable-gallium-llvm didn't make a difference.

So maybe these are too different issues that just look similar.
Comment 3 Michel Dänzer 2012-04-16 01:40:52 UTC
Does it work with -O2 -fno-strict-aliasing? The Mesa tree is known not to be strict aliasing clean. If that's not it, maybe you can isolate the specific optimization enabled by -O2 but not -O1 which triggers the crash.

I suspect this bug may be invalid anyway though: you shouldn't set CFLAGS directly but use OPT_FLAGS and friends.
Comment 4 Christoph Haag 2012-04-16 02:50:15 UTC
(In reply to comment #3)
> Does it work with -O2 -fno-strict-aliasing? The Mesa tree is known not to be
> strict aliasing clean. If that's not it, maybe you can isolate the specific
> optimization enabled by -O2 but not -O1 which triggers the crash.
> 
> I suspect this bug may be invalid anyway though: you shouldn't set CFLAGS
> directly but use OPT_FLAGS and friends.

Well, I set it to -O2 for testing. Archlinux does set the CFLAGS so if this is wrong, Archlinux is doing it wrong?

Archlinux's default CFLAGS are by the way:
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"
(I personally use -march=native)

So I tried setting my CFLAGS to CFLAGS="$CFLAGS -fno-strict-aliasing".

Compiling lib32 mesa looks like this now:

gcc -m32 -c -I. -I../../../src/gallium/include -I../../../src/gallium/auxiliary -I../../../src/gallium/drivers  -march=native -fomit-frame-pointer -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -m32 -march=native -fomit-frame-pointer -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fno-strict-aliasing  -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DIN_DRI_DRIVER -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XEXTPROTO_71 -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0300 -fvisibility=hidden -I/usr/include   -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS util/u_rect.c -o util/u_rect.o



-fno-strict-aliasing does not fix the wine crashes.
Comment 5 Johannes Obermayr 2012-09-15 23:21:09 UTC

*** This bug has been marked as a duplicate of bug 48351 ***

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.