------- Comment #6 from dg dot recrutement31 at gmail dot com 2010-05-27 11:18 ------- (In reply to comment #4) > All the tests demonstrate is that you have buggy constraint, in particular > you shouldn't use "g" constraint on something you use in gs:[%2]. > "g" is any register (fine in that case), immediate (not fine) or memory (not > fine either in this case). > mov al, gs:[DWORD PTR [ebp+12]] > is what you get when this->offset is memory at ebp+12, and that of course > doesn't assemble. Just use "r".
OK, thanks for the workaround. Nevertheless, this is a bug because: without -ftree-ter optimization option, -------------------------------------- the rtl-optimization module causes the following code, generated: mov edx, DWORD PTR [esp+24] mov edx, DWORD PTR [edx+4] /APP # 59 "far_pointers.h" 1 .intel_syntax noprefix; mov gs, ax; mov bl, gs:[edx]; with -ftree-ter : --------------- mov edx, DWORD PTR [esp+24] /APP # 59 "far_pointers.h" 1 .intel_syntax noprefix; mov gs, ax; mov bl, gs:[DWORD PTR [edx+4]]; (I don't want to enter in a philosophic debate) Nevertheless, with "g" directive, this is the responsability of the compiler to choose the good addressing mode because the developer can't know how to anticipate regarding code generated before inline assembly. Or, the "g" directive should be deleted from GCC specs. Thank you again for your suggestion. Regards, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44288
