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: Using the asm suffix

(Resending due to email glitch)

Thanks again for your comments.

On 8/18/2015 2:23 AM, Segher Boessenkool wrote:
On Mon, Aug 17, 2015 at 09:55:48PM -0700, David Wohlferd wrote:
On systems where an underscore is normally prepended to the name of a C
-function or variable, this feature allows you to define names for the
+variable, this feature allows you to define names for the
  linker that do not start with an underscore.
Why remove this?
This doc section (Controlling Names Used in Assembler Code) describes
how the asm suffix affects both data and functions. However, it jumbles
the two descriptions together.
Probably because they are the same thing...

My intent here is to break this clearly into two @subsubheadings:
'Assembler names for data' and 'Assembler names for functions'. Since
data is the first section, I removed the word 'function' here.
I missed that, sorry.  Or, did you forget to add the same text to the
"function" description?

This patch would be much easier to review if you did one change per patch.

I'm not sure what 'one change' might mean in this context. This topic is all a single texi node (ie it all ends up on a single html page). This page isn't that big. Would looking at the output help clarify this:


  It does not make sense to use this feature with a non-static local
variable since such variables do not have assembler names. If you are trying to put the variable in a particular register, see @ref{Explicit
-Reg Vars}.  GCC presently accepts such code with a warning, but will
-probably be changed to issue an error, rather than a warning, in the
+Reg Vars}.
And this?
Vague statements about possible changes that may or not ever be written
are not helpful in docs.  In this case the statement is particularly
unhelpful since even the warning appears to be gone.
I don't agree it is a vague statement about possible future changes; it
is more like a statement of intent.

Saying this will "probably" change at some (unspecified) time "in the future" seems the very definition of vague. Especially when you consider that the docs have been threatening this change for over 15 years now.

It tells the reader "don't write code like this".

If this is intended just for emphasis, how about replacing the existing text ("It does not make sense to use this feature with a non-static local variable since such variables do not have assembler names.") with "Do not use this feature with a non-static local variable." or maybe "It is not supported to use this feature with a non-static local variable since such variables do not have assembler names."

Saying "It does not make sense" to do something doesn't mean the same thing (to me) as "Do not do this" or "It is not supported to..."

And the warning is still there ("ignoring asm-specifier for non-static
local variable").

Huh.  I was unable to get gcc to produce this warning.  Is there a trick?

int main()
   int a asm("asdf");
   a = 13;
   return a;

I have tried 4.9.2 and 5, with -O2 and -O0, and I'm getting no warning (or error) messages.

-Also, you must not use a
-register name; that would produce completely invalid assembler code. GCC -does not as yet have the ability to store static variables in registers.
-Perhaps that will be added.
And why remove these?
Again with the vague statements about possible future changes. Also,
whether or not static variables can be stored in registers has nothing
to do with Asm Labels.  If this is still true, it belongs in Explicit
Reg Vars.
The first part ("must not use a register name") is an important warning.

Clarifying this is a good idea. Although limiting it to only saying "don't use register names" seems a little, well, limiting. Who knows what kind of offsets or asm qualifiers they might try to cram in here? How about:

"Only label names valid for your assembler are permitted within the asm."

This would go right after the warning about conflicts.

The second part (about statics) might well be better moved, but it should
not be _re_moved just like that!  And it is still true (gives an error,
"multiple storage classes").

I have already started work on the changes I think are needed for Explicit Reg Vars (the last section of gcc docs I'm planning on doing). But I want to finish the (relatively easy) Asm Labels stuff first. Should I put this change in there? Or would someone just tell me all the Asm Labels stuff should go in its own patch?

Also, I'm not seeing the multiple storage classes message either:

int main()
   static int a asm("asdf");
   a = 5;
   return a;


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