public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: about function attributes for functions returning a pointer
       [not found] ` <mcrhbh1g6ku.fsf@google.com>
@ 2011-02-10 13:27   ` Uwe Kleine-König
  2011-02-10 18:45     ` Ian Lance Taylor
  0 siblings, 1 reply; 4+ messages in thread
From: Uwe Kleine-König @ 2011-02-10 13:27 UTC (permalink / raw)
  To: gcc-help

Hello Ian,

On Mon, Oct 04, 2010 at 11:23:45AM -0700, Ian Lance Taylor wrote:
> Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:
> 
> > in the linux kernel I defined a function as follows:
> >
> > 	static struct platform_device *__init __maybe_unused imx_add_imx_dma(void)
> > 	{
> > 		...
> > 	}
> >
> > and the only used was #ifdefed out.
> >
> > With the following defines:
> >
> > 	#define __section(S) __attribute__ ((__section__(#S)))
> > 	#define __cold __attribute__((__cold__))
> > 	#define notrace __attribute__((no_instrument_function))
> > 	#define __init	__section(.init.text) __cold notrace
> > 	#define __maybe_unused                  __attribute__((unused))
> >
> > this still generated the "defined but unused" warning.
> >
> > Then after changing the definition to
> >
> > 	static struct platform_device __init __maybe_unused *imx_add_imx_dma(void)
> >
> > (i.e. move the * after the attribute stuff) the warning is gone.  In
> > both cases (and when the function was used) it is put in the
> > ".init.text" section though.  That is in the first case __init worked,
> > but __maybe_unused did not.  Is this intended?  Do I something wrong?
> > What is the most correct position for function attributes for functions
> > returning a pointer?
> >
> > (I'm using gcc 4.3.2 for arm, OSELAS.Toolchain-1.99.3.6 here.  Could not
> > reproduce with Debian's gcc 4.4.5 for x86 using a minimal example.)
> 
> This message is not appropriate for the mailing list gcc@gcc.gnu.org.
> It would be appropriate for gcc-help@gcc.gnu.org.  Please take any
> followups to gcc-help.  Thanks.
oops, ok, sorry.

> The syntax for attributes is documented at
> http://gcc.gnu.org/onlinedocs/gcc-4.5.1/gcc/Attribute-Syntax.html .
This is heavy reading.  And though I'd claim not to be a novice C
programmer I don't understand it.

For me

	static struct platform_device *__init __maybe_unused imx_add_imx_dma(void)

makes most sense, because the * belongs to struct platform_device and
it's imx_add_imx_dma() that is unused and should live in .init.text, not
*imx_add_imx_dma().

> 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?

Best regards
Uwe

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: about function attributes for functions returning a pointer
  2011-02-10 13:27   ` about function attributes for functions returning a pointer Uwe Kleine-König
@ 2011-02-10 18:45     ` Ian Lance Taylor
  2011-02-10 19:41       ` Uwe Kleine-König
  0 siblings, 1 reply; 4+ messages in thread
From: Ian Lance Taylor @ 2011-02-10 18:45 UTC (permalink / raw)
  To: Uwe Kleine-König; +Cc: gcc-help

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.

Ian

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: about function attributes for functions returning a pointer
  2011-02-10 18:45     ` Ian Lance Taylor
@ 2011-02-10 19:41       ` Uwe Kleine-König
  2011-02-11  4:49         ` Ian Lance Taylor
  0 siblings, 1 reply; 4+ messages in thread
From: Uwe Kleine-König @ 2011-02-10 19:41 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: gcc-help

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/  |

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: about function attributes for functions returning a pointer
  2011-02-10 19:41       ` Uwe Kleine-König
@ 2011-02-11  4:49         ` Ian Lance Taylor
  0 siblings, 0 replies; 4+ messages in thread
From: Ian Lance Taylor @ 2011-02-11  4:49 UTC (permalink / raw)
  To: Uwe Kleine-König; +Cc: gcc-help

Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:

> 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.

As I recall, your original problem was that an attribute that you wanted
to be attached to the declaration was instead being attached to the
type.  The answer is going to have to be to move the attribute clause.
I don't see what other alternative there could be.

Ian

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-02-10 19:41 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20101004090407.GA11737@pengutronix.de>
     [not found] ` <mcrhbh1g6ku.fsf@google.com>
2011-02-10 13:27   ` about function attributes for functions returning a pointer Uwe Kleine-König
2011-02-10 18:45     ` Ian Lance Taylor
2011-02-10 19:41       ` Uwe Kleine-König
2011-02-11  4:49         ` Ian Lance Taylor

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).