This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to avoid code elimination

Interesting discution, thanx you all :)

Well, as I said I did try asm("nop"), and it looked like it was doing
the job so I stopped there, and I was indeed aware that if I bumped
into a no nop arch, I would be able to find the NOP equiv like
r0=r0|r0 i.e OR r0,r0,r0 etc... on some well beloved and disapeared

I did use -O0 and didn't knew -Og, assumed -g implied no
optimisations, until one would force -g -O2 that would setup the
compiler to genereate DOC (debug optimised code)


On Mon, Nov 27, 2017 at 11:12 PM, Segher Boessenkool
<> wrote:
> On Mon, Nov 27, 2017 at 12:32:28PM +0100, David Brown wrote:
>> > doing an asm("nop") seems to do the job for gcc, and I guess (not
>> > verified) would be portable across architectures, so for gcc/gdb combo
>> > I will do this.
>> Most targets have a "nop" instruction, but not all.
> From gcc/testsuite/gcc.dg/nop.h:
> #if defined (__ia64__) || defined (__s390__) || defined (__s390x__)
> #define NOP "nop 0"
> #elif defined (__MMIX__)
> #define NOP "swym 0"
> #else
> #define NOP "nop"
> #endif
>> I would recommend you use:
>>       asm volatile ("nop" ::: "memory");
>> The "volatile" limits re-ordering somewhat
> No, it doesn't: to start with, this asm *always* is volatile (it has no
> outputs, asms without outputs are always volatile).
> Just use  asm("nop");  unless you really really really need something
> else (and then you *know* you do, instead of cargo-culting something).
>> and ensures it is "executed"
>> at that point in the code.  The memory clobber tells gcc to write out
>> the values of any variables in memory before the instruction, and read
>> them in again after the instruction - this will make your variable view
>> in the debugger more accurate (since the compiler won't move variable
>> changes across the breakpoint).
> That is misleading.  The compiler is perfectly free to keep variables
> in registers (unless those variables are *also* volatile, or have their
> address taken, etc.)
> If you want easier debugging, use -O0 or -Og.
> Segher

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]