public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Ian Lance Taylor <iant@google.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: about function attributes for functions returning a pointer
Date: Thu, 10 Feb 2011 19:41:00 -0000	[thread overview]
Message-ID: <20110210184526.GB27982@pengutronix.de> (raw)
In-Reply-To: <mcr8vxnki76.fsf@google.com>

On Thu, Feb 10, 2011 at 07:44:29AM -0800, Ian Lance Taylor wrote:
> Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:
> 
> >> I think the differences you are seeing are because some attributes can
> >> apply to types and some can only apply to declarations.  Moving the
> >> location of the __attribute__ affects which type it applies to.  In
> >> particular __attribute__ ((unused)) may be used with a type, but
> >> __attribute__ ((section (...))) may only be used with a declaration.
> >
> > As far as I got it both section() and unused are variable/function
> > attributes and not type attributes.  So I think this explanation doesn't
> > match, does it?
> 
> The unused attribute can be used on a type.
> 
> typedef int I1 __attribute__ ((unused));
> typedef int I2 __attribute__ ((section (".sec")));
> 
> foo.c:2: error: section attribute not allowed for ‘I2’
> 
> There is no error for I1.
> 
> What the unused attribute means for a type I decline to speculate.  But
> it is accepted where type attributes are accepted.  Perhaps this is a
> bug.  I'm really not sure.
Ah, found something about unused being a type attribute.  My gcc docs (i.e.
gcc-4.3.info) say:

`unused'
     When attached to a type (including a `union' or a `struct'), this
     attribute means that variables of that type are meant to appear
     possibly unused.  GCC will not produce a warning for any variables
     of that type, even if the variable appears to do nothing.  This is
     often the case with lock or thread classes, which are usually
     defined and then not referenced, but contain constructors and
     destructors that have nontrivial bookkeeping functions.

This doesn't help me on my original problem though.

Best regards
Uwe


-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

  reply	other threads:[~2011-02-10 18:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20101004090407.GA11737@pengutronix.de>
     [not found] ` <mcrhbh1g6ku.fsf@google.com>
2011-02-10 13:27   ` Uwe Kleine-König
2011-02-10 18:45     ` Ian Lance Taylor
2011-02-10 19:41       ` Uwe Kleine-König [this message]
2011-02-11  4:49         ` Ian Lance Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110210184526.GB27982@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=gcc-help@gcc.gnu.org \
    --cc=iant@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).