date:20120907

Re: print operand modifiers in the manual

2012-09-07 Thread Georg-Johann Lay


David Daney wrote:

Mike Stump wrote:

David Daney wrote:

Ian Lance Taylor wrote:

Mike Stump wrote:
Where in the manual are the machine specific print operand 
modifiers documented?  I've looked around, and just can seem to 
find them; surely, I can't be the first to document such a modifier.


To the best of my knowledge they are not documented in the manual.
The machine-specific asm constraint characters are documented in the
manual, but I don't think the print operand modifiers are.


Perhaps they should be added to the internals manual.


Only if you move extended asms to the internals manual.  :-(


I got the idea from the Constraints documentation, and for those I 
always looked in the Internals Manual.  But now I see that there is 
similar, but not identical, Constraints documentation in both the GCC 
manual and the Internals Manual.


I am not so fluent in texinfo that I would attempt it, but it seems that 
these sections should be factored into separate files so that the same 
information can appear in both manuals and not have the current 
divergence of content.


I am not sure if that is a good idea.

For example, the X constraint is useful/needed in machine description
but not at all in inline assembler.  It is a bug to use X as inline
assembler constraint, and it is confusing to inline assembler authors
if it is documented.  Other constraint might be p that is useful in
md but not at all in inline assembler.

Similar applies to the asm print modifiers.

Any yes, the common ans useful print modifiers should be documented
in the user manual, IMHO.

Johann

Re: print operand modifiers in the manual

2012-09-07 Thread Georg-Johann Lay


Ian Lance Taylor wrote:

Mike Stump wrote:

Where in the manual are the machine specific print operand
modifiers documented?  I've looked around, and just can seem to
find them; surely, I can't be the first to document such a
modifier.


To the best of my knowledge they are not documented in the manual. 
The machine-specific asm constraint characters are documented in the 
manual, but I don't think the print operand modifiers are.


Often, when I consult the user manual for target specific buts, I get
the impression that the organization of these information is suboptimal
because it is scattered all over the user manual:

- target specific function attributes (even merged up with each other)
- target specific data attributes
- target specific type attributes
- target specific named address spaces
- target specific command options
- target specific built-in defines
- target specific buitt-in functions
- target specific built-in types like __int24 or __int128
- target specific inline assembler constraints
- target specific inline assembler print modififers
- target specific #pragma
- target specific built-in sections
- target specific extension support like ISO/IEC TR 18037
- target specific implementation (int, void*, double, accum, fract, ...)
- target specific restrictions and caveats (like .text  128KiB on avr)
- target specific ABI, at least an outline like register usage, might
  help (inline) assembler programmers to write code that cooperates
  with code from GCC
- target specific defaults: debug-info, frame layout,
  exception model, asm clobbers, SFR usage, ...

All is scattered over the manual.  There is no central place to read
about target specific features and caveats.  If you start with GCC
and/or with a specific target architecture, it is *very* likely you
miss some of these sections and get frustrated by non-functional code.

Some of the above bits I just dropped in the Target Options section
because there is no other canonical place, and the Target Options
is likely to be read by the user, cf. [1] for example.

Johann

--

[1] http://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html

Re: Cgraph Modification Plan

2012-09-07 Thread Jan Hubicka

 Sorry to interrupt here, but please finish the existing partial C++ 
 transitions
 instead of starting to work on new ones.  Current stage1 will not last forever
 (stage1 is usually 6 months, so its natural end would be end of September).
 I'd rather have the current transition to a symbol table finished than having
 that half-way done and half-way done in C++.  Please.

I am focusing on getting the transition finished for 4.8. Some discussion about
C++ transition (I would like to see done for 4.8 at least in the basic and
obvious way) and problems people have with the current design seems good to me.
We do not need to implement everything discussed in this thread immediately,
but it is good to have the discussion.
 
 Btw, I also think the current symtab hierarchy is somewhat flawed.  At
 the core a symtab entry should just be the symbol name and a list
 of entities associated with it (much similar to the LTO symtab stuff).

We do have that. There is list of symtab entries sharing the same symtab hash 
entry
(assembler name). I have WIP patch to make lto-symtab to use these instead of 
its
own hashes. They need more testing and bit of cleanup though.

 Entities then are callgraph nodes, varpool nodes or alias nodes (or other

Having alias nodes separate from callgrap/varpool is difficult thing. The 
problem
is that one realy wants to handle function aliases as functions and variable 
aliases as
variables (i.e. one want to have call to function alias, or read from variable 
alias but
not other ways around). Thus we currently have aliases inherited from 
functions/variables
both on tree declaration level and symbol table level.

I have patches to commonize more the alias handling that is now duplicated over
former cgraph/vaprool in queue though.
 stuff).  Thus, the current symtab_node_base is too fat, and decls,
 instead of having DECL_ASSEMBLER_NAME should have a pointer
 to the (new) symtab node they are associated with.

Yes, it is the longer term goal (or rather getting rid of assembler name in 
favor
of real symbol name + flags that are currently encoded in assembler name)
At the moment it does seem to make sense though when everything is tied to 
declarations
and eclarations have their own assembler name.
I will slowly work on this, but after 4.8.

Honza
 
 Thanks,
 Richard.

gcc-c-api

2012-09-07 Thread David Malcolm

After a hiatus, I've restarted work on an API for GCC plugins -
specifically, a C API (given that my plugin is written in C, I have more
interest in that than a C++ API).

BTW, how many other GCC plugins are written in C?

It's still a work-in-progress, but can be seen here:

http://git.fedorahosted.org/cgit/gcc-python-plugin.git/tree/gcc-c-api?h=proposed-plugin-api

i.e. within the proposed-plugin-api branch of the gcc-python-plugin,
within the gcc-c-api subdirectory. I've been gradually porting the
python plugin to use the proposed API, rather than poking at GCC's
insides itself. I've also tried to follow the GNU coding conventions
within that directory (the plugin itself follows the Python coding
conventions). I haven't done the copyright assignment paperwork yet.

There are no explicit test cases yet, though the python plugin's test
suite passes, exercising the code indirectly.

The API has a build-time dependency on Python (parts of it are
autogenerated, and Python is my natural choice for this work). There
isn't a runtime dep though.

I started thinking about trying to create a patch to merge the API into
the GCC source tree, but I'm running into some high-level issues: how is
a plugin meant to actually use this API without requiring the use of an
in-development version of GCC? Similarly, as a plugin author, I want my
plugin to be usable against GCC 4.6 onwards, but GCC's internal APIs are
gradually changing. I see a lot of #ifs in my future, and it makes
sense to try to isolate the compatibility shims in one place, rather
than having every plugin author maintain them.

Given that, it's most useful, I think, if the API code can somehow be
used independently of GCC: perhaps it's more of a compatibility shim
that hides the differences between GCC versions (e.g. C vs C++ name
mangling, C++ internals in 4.8 onwards etc) and provides a stable ABI
(that way you only have to recompile the API implementation when
recompilng GCC: all plugins built against the API should remain
compatible - that's the goal, after all).

I'm not sure exactly how this is to be structured: external project vs
internal to gcc's source tree, but given that this is a non-trivial
amount of code and that I want it to support gcc 4.6, perhaps external
to the gcc source tree is the way to go.

1 2 3 >

1 - 100 of 217 matches

Mail list logo