public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Jim Wilson <jimw@sifive.com>
To: Newlib <newlib@sourceware.org>
Subject: __restrict defined away for C++
Date: Mon, 13 Jul 2020 13:02:07 -0700	[thread overview]
Message-ID: <CAFyWVab4RES_jp5rxcKMO4BRXmFWtxaSjuRSS916=ApxSLifEQ@mail.gmail.com> (raw)

This problem was originally reported on the RISC-V sw-dev mailing list.
https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/b55LI9OSFwo/m/d8-_NGmlAQAJ

I see that newlib/libc/include/sys/cdefs.h has

/*
 * GCC 2.95 provides `__restrict' as an extension to C90 to support the
 * C99-specific `restrict' type qualifier.  We happen to use `__restrict' as
 * a way to define the `restrict' type qualifier without disturbing older
 * software that is unaware of C99 keywords.
 */
#if !(__GNUC__ == 2 && __GNUC_MINOR__ == 95)
#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 199901
#define __restrict
#else
#define __restrict      restrict
#endif
#endif

The flaw here is that C++ compilers don't define __STDC_VERSION so
this always causes __restrict to be defined away, even if the C++
compiler supports it.  This prevents use of the GNU extension
__restrict in C++ code.  The workaround is to use __restrict__ in user
code which GNU C++ also supports, and which newlib doesn't define
away.

I don't have a patch.  I'm hoping someone else writes one.  One
possible solution is to use a different keyword inside newlib, e.g.
__newlib_retrict.  This way we don't conflict with the compiler
__restrict feature.  Though this means newlib functions will be
declared without __restrict.  Another solution would be to check for
C++ compilers with __restrict support and support them.  Or maybe both
of these are appropriate.

We may not need the gcc-2.95 support anymore.

Jim

                 reply	other threads:[~2020-07-13 20:02 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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='CAFyWVab4RES_jp5rxcKMO4BRXmFWtxaSjuRSS916=ApxSLifEQ@mail.gmail.com' \
    --to=jimw@sifive.com \
    --cc=newlib@sourceware.org \
    /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).