bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: bug-gnulib@gnu.org
Cc: "Marc Nieper-Wißkirchen" <marc.nieper+gnu@gmail.com>,
	"Paul Eggert" <eggert@cs.ucla.edu>
Subject: Re: 'const' function attribute
Date: Wed, 14 Oct 2020 03:24:17 +0200	[thread overview]
Message-ID: <6264867.2uO1eQXvy6@omega> (raw)
In-Reply-To: <1894139.Itj1ZGPQdl@omega>

Hi Paul,

I did this:
> 	(gl_tree_iterator_free): Mark as 'const'.

and now GCC gives me this warning:

  In file included from gl_avltree_oset.c:46:
  gl_anytree_oset.h:442:1: warning: 'const' attribute on function returning 'void' [-Wattributes]

for

  static void _GL_ATTRIBUTE_CONST
  gl_tree_iterator_free (gl_oset_iterator_t *iterator _GL_ATTRIBUTE_MAYBE_UNUSED)
  {
  }

The description you added in attribute.h:

  /* It is OK for a compiler to omit duplicate calls with the same arguments.
     This attribute is safe for a function that neither depends on
     nor affects observable state, and always returns exactly once -
     e.g., does not loop forever, and does not call longjmp.
     (This attribute is stricter than ATTRIBUTE_PURE.)  */
  /* Applies to: functions.  */
  #define ATTRIBUTE_CONST _GL_ATTRIBUTE_CONST

makes perfect sense for a function that returns void. However, in view of the
GCC documentation [1] the GCC warning basically means "the 'const' attribute
here does not help me in doing common-subexpression elimination, since the
return type is 'void'".

To me, this is a pointless warning. Would you agree that a bug report to
the GCC people makes sense?

Bruno

[1] https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Common-Function-Attributes.html



  parent reply	other threads:[~2020-10-14  1:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-04 20:23 Unused parameter warnings Marc Nieper-Wißkirchen
2020-10-04 22:08 ` Bruno Haible
2020-10-06  5:58   ` Marc Nieper-Wißkirchen
2020-10-06 21:05     ` Bruno Haible
2020-10-07  6:07       ` Marc Nieper-Wißkirchen
2020-10-10 13:50         ` Bruno Haible
2020-10-10 14:31           ` Marc Nieper-Wißkirchen
2020-10-10 14:39             ` Bruno Haible
2020-10-10 15:00               ` Marc Nieper-Wißkirchen
2020-10-10 18:50                 ` Paul Eggert
2020-10-10 21:00                   ` Bruno Haible
2020-10-11 23:10                     ` Paul Eggert
2020-10-12  2:21                       ` Jeffrey Walton
2020-10-14  1:24                     ` Bruno Haible [this message]
2020-10-14 14:57                       ` 'const' function attribute Paul Eggert
2020-10-18 14:27                         ` Bruno Haible
2020-10-10 20:43             ` Unused parameter warnings Bruno Haible

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

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

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

  git send-email \
    --in-reply-to=6264867.2uO1eQXvy6@omega \
    --to=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=marc.nieper+gnu@gmail.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).