Bug 6669 – Compiler seg fault when using square brackets in inline assembly

This sample program causes DMD 2.055 to seg fault on OSX. If you remove the brackets then it doesn't seg fault. void main() { asm { mov EAX, [EAX]; } } It didn't seg fault on 2.053 (haven't tried 2.054), so this is a regression.

I can't reproduce this with tip of trunk: $ uname -a Darwin nexus 11.1.0 Darwin Kernel Version 11.1.0: Tue Jul 26 16:07:11 PDT 2011; root:xnu-1699.22.81~1/RELEASE_X86_64 x86_64 $ cat bug6669.d void main() { asm { mov EAX, [EAX]; } } $ ./dmd -v ../../bugs/bug6669.d binary ./dmd version v2.056 config dmd.conf parse bug6669 importall bug6669 import object (./../../druntime/import/object.di) semantic bug6669 semantic2 bug6669 semantic3 bug6669 code bug6669 function main gcc bug6669.o -o bug6669 -m32 -Xlinker -L./../../druntime/lib -Xlinker -L./../../phobos/generated/osx/release/32 -lphobos2 -lpthread -lm What's different about your env than mine? I also tried on linux/32 and /64 with no better luck. Assuming you can still reproduce the problem, running dmd under gdb and getting a stack trace might help even if I can't repro.

My environment is: $ uname -a Darwin poita.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 i386 Unfortunately, I don't get any symbols from gdb, even when I rebuild dmd with -ggdb Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xd39bf756 0x000b8188 in ?? () (gdb) bt #0 0x000b8188 in ?? () #1 0x000bb861 in ?? () #2 0x000bc3df in ?? () #3 0x0010d98f in ?? () #4 0x0009e3ac in ?? () #5 0x000cfc92 in ?? () #6 0x000cc7a2 in ?? () #7 0x0000276d in receive_samples () #8 0x0000269c in receive_samples () I'm not very familiar with gdb, so if you have any tips to get a good stack trace then please let me know how. Interestingly, if I get the latest from trunk and build then I don't get this error. Also, even when I checked out tag 2.055 I didn't get the error... strange. Seems to only be the released version. Can you try that?

I would think you need to ensure EAX points to somewhere readable to avoid a seg fault. E.g.: void main() { int i; asm { lea EAX, i; } asm { mov EAX, [EAX]; } }

(In reply to comment #3) > I would think you need to ensure EAX points to somewhere readable to avoid a > seg fault. E.g.: I think you misread the bug report. It's about the compiler crashing, not the resulting code. Yes, it's slightly odd code, in that on x86, the first arg to main is argc, an int and not a pointer. But that's irrelevant.

(In reply to comment #4) > (In reply to comment #3) > > I would think you need to ensure EAX points to somewhere readable to avoid a > > seg fault. E.g.: > > I think you misread the bug report. It's about the compiler crashing, not the > resulting code. Yes, it's slightly odd code, in that on x86, the first arg to > main is argc, an int and not a pointer. But that's irrelevant. That's correct. I have code that uses this is a more correct way, this is just a minimal example of it happening. The compiler should never (with reason) seg fault.

I just tested with the most recent beta, built by Walter rather than hand built on the lion box, and it's working fine. Peter, if you can confirm that it's working for you also, that'd be good. I'm reluctant to mark the bug resolved since it's not clear what the problem was or what fixed it. http://ftp.digitalmars.com/dmd2beta.zip

That dmd2beta works fine for me. It only appears to have been the previous release bundle that broke it for me. I've been building from the master branch on github and it has been working fine.

Ok.. well, I'll mark it resolved. If/when it happens again, we'll have to try to find out what about the build/release process is creating problematic binaries.