------- Comment #9 from dg dot recrutement31 at gmail dot com 2010-05-27 12:21 ------- (In reply to comment #7) > You are wrong. It is user's responsibility to choose correct constraints for > the inline assembly, the compiler doesn't try to understand what the inline > assembly is doing or even check its semantics, all it does is perform > replacements in it (replacing %0, %1, %2 in this case). > Not every constraint is suitable for every use in the assembly obviously, > otherwise we wouldn't need multiple constraints. > The "g" constraint allows a register, immediate or memory, all must be valid > in > the instruction and it is up to the compiler which one it chooses. > "g" constraint is usable say for mov eax, %2; which can work well with > registers, immediates or memory. But as you use [%2] instead, memory isn't > valid, all that is valid is either a register or register + immediate or > register + X*register2 + immediate (the usual i?86 addressing modes).
Yes, yes, but ... I've (naively) delete [] of deferencing : inline T operator*(void) { T item; __asm__ ( "\ .intel_syntax noprefix; \n\ mov gs, %1; \n\ mov %0, gs:%2; \n\ " :"=q"(item) :"r"(this->segmentSelector), "g"(this->offset) ); return item; } The example works because of static parameter '&main'. But, in some others cases, it tries to generate : mov al, gs:eax ... Argh !! So, the inline assembly can't fully participate to optimization. Should be nice, if it did it. I wonder if inline RTL would be better to use (if it was supported) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44288