On 05/02/2021 06:18, mark_at_yahoo wrote:
> On 2/4/21 1:17 PM, David Brown wrote:
>> You might find it neater to have:
>>
>> #ifdef DEBUG
>> #define DEBUGABLE volatile
>> #else
>> #define DEBUGABLE
>> #endif
>>
>> Then when you make the variable, you only need:
>>
>> DEBUGABLE unsigned some_variable;
>
> Thanks for the suggestion, but in truth I was just trying to illustrate
> the point. My personal usage is to temporarily add:
>
> volatile // DEBUG
>
> on the line before the declaration, and remove it after debugging the
> code in question. See below.
>
Sure, I understand that. In posts on mailing lists and the like, we try
to write code as "perfectly" as we can, and in general ways. But in our
own code - especially for a temporary change for a quick debug session -
we take shortcuts or use our own styles that are somewhat atypical (but
far better, at least in our own opinions!). I wouldn't use the code I
suggested in my own work - I'd be a lot likelier to write it like you did.
>
>> No, it is not an error - it is perfectly fine. The parameter is passed
>> by value - the "volatile unsigned" is read and passed to the function.
>> It is only if the function has a pointer that you have an error :
>>
>> void some_function(unsigned * p);
>>
>> Calling "some_function(&some_variable)" will fail if some_variable is
>> declared "volatile".
>
> You are of course right. My apologies for typing too fast and misstating
> a problem I've hit many times (passing a volatile by pointer or
> reference when a non-volatile is expected).
>
>
>> Here is a trick you might like to try.
>> ...
>> #define establish(v) asm volatile ("" : "+g" (v))
>> ...
>> An alternative formulation for the macro would be:
>>
>> #define establish(v) asm volatile ("" :: "g" (v))
>> ...
>
> Very nice trick(s), thanks. I'll definitely try them. The first declares
> a read/write output operand and the second an input, right?
>
Yes. Because these are marked "volatile", they can't be removed even if
the compiler can see they don't do anything (actually, an input-only
assembly instruction is viewed as "volatile" by default). So that means
the compiler has to evaluate the argument "v" before executing the empty
statement. And for the first version, the compiler has to assume the
assembly changes "v" afterwards.
You might also find it helpful to put a memory clobber in the assembly,
if you want to see other data when you have stopped at a breakpoint.
>
>>>> I wonder if anyone has any thoughts about specific -fno-* settings I
>>>> can add alongside -Og which will preserve either all, or most, or even
>>>> just more, of the local variables rather than optimizing them away.
>
> I still would like to see something like this, as per the original
> poster's request. As I said above, I don't leave any of the #if/#define
> constructs in release code (nullified by #undef, #define <empty>, etc.)
> -- just dynamically add and remove them as needed. Leaving them in
> obscures the code too much. A magic "-no-..." option that could be
> added/enabled to the commandline or Makefile would make life easier.
>
I think requiring the existence and evaluation of temporary variables
would cripple performance - code would quickly be far bigger and slower
than -O1, though not as bad as -O0. But I can't see much benefit in it
- if you are willing to pay a high cost in code efficiency (not all
programs need to be small and fast), then -O0 is available today.
Obviously a flag like this would only be used by those that want to use
it - it has no direct cost to users who don't see it as helpful. But
there is a cost to the gcc developers, and a cost to maintenance of such
flags. They get to decide where their priorities lie. Perhaps the flag
could be implemented easily, perhaps it would be very difficult.
The standard course of action is to file a Bugzilla report asking for
the feature - then anyone else interested in the feature can add their
voice in support, and developers can make comments on their opinions and
the feasibility of implementing it.
