Re: Target-specific pragmas

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On 20 Jun 2001, Geoff Keating wrote:

> > 1. How should target-specific pragmas be documented?  I notice that
> > there are many existing pragmas in targets, but the manual does not
> > seem to mention any of them anywhere.  Is this deliberate?
> 
> Yes.  I believe that nearly all of the target-specific pragmas are
> only for backwards compatibility with other compilers, and that
> the preferred interface is to use __attribute__.

Every user-visible feature not in the language standards (and the handling
of every case the standards say is implementation defined) should be
documented in the manual.  If the pragma is just for compatibility, the
manual should say so and refer the user to the documentation for the
preferred alternative.

PRs should be submitted for any that are undocumented.  If they are on
targets that will be primary evaluation platforms for 3.1, I think the PRs
should be priority "high".

> > 2. Some of our pragmas exist to provide per-function control over
> > optimization levels and flag_writable_strings.  I vaguely remember
> > some discussion over whether there ought to be some kind of fine
> > grained control over flags via pragmas and/or attributes.  Is there
> > a consensus on what to do here?
> 
> The first, and trickiest part, is to work out what can actually be
> changed, and when it can be changed.  I'm pretty sure you can't switch
> between -O1 and -O0 in one compilation, for instance; I'm not
> convinced that flag_writable_strings can be changed reliably either.

There's also again the matter of justifying why these pragmas are better 
than using separate source files.  It has been proposed that the 
compilation options should be included in the .o file - what would go 
there if they vary from function to function?  What about the information 
output by -fverbose-asm?

If you want to do something useful for strings, implement attributes for
them - both attributes on individual strings (mainly "section", but you
could make -fwritable-strings controllable for individual strings) and on
initialised declarations controlling where strings in the initializer go.  
ISTR that something like this would be useful for the Linux kernel, so
that strings in data used only at bootup can be freed, the same way the
arrays containing pointers to them, and initialization functions, are
freed.

-- 
Joseph S. Myers
jsm28@cam.ac.uk